[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New sleep code for ATI M6, M7 and M9

On Don, 2003-03-20 at 21:02, Vincent Strubel wrote:
> On Thursday 20 March 2003 18:11, you wrote:
> > > a gentoo (nobody's perfect...) and running xfree-4.3.0 and gentoo's
> > > xfree-drm (should be same source as debian drm-trunk-modules).
> >
> > I hope not. It would be foolish of Gentoo to use bleeding edge CVS
> > snapshots.
> You're right, I may have spoken too quickly. The current "testing" (as of 
> gentoo) ebuild uses a source archive from the developper's website:
> http://cvs.gentoo.org/~gerk/distfiles/drm-trunk.tar.gz
> But it is the same (according to cmp) as what I get after running dpkg-deb -x 
> on your drm-trunk-module-src_2002.12.05-3_all.deb, from 
> people.debian.org/~daenzer, and once untarred it still has the 
> modules/drm-trunk/debian/changelog.m4 saying:
> drm-trunk-module-KVERS (KDREV+2002.12.05-3) unstable; urgency=low
> Portage only patches the Makefile.linux (most of it is for ease of use with 
> emerge, apparently) before building it, with the patch quoted at the end of 
> this message.
> > As others have pointed out, it must be the AGPMode (it never occurred to
> > me that this could help for sleep because higher AGP transfer rates
> > traditionally tended to be problematic...) because ForcePCIMode defaults
> > to false and you can't use the UniNorth agpgart without
> > http://penguinppc.org/~daenzer/DRI/drm-ioremapagp.diff . Are you using
> > that? If not, that would be interesting because the AGPMode option would
> > seem to have an effect without AGP GART actually being used.
> Indeed, it works with just "AGPMode" "4", no ForcePCIMode nor DRIReinit 
> (except I  get less garbage on the screen on snooze). And I'm not using the 
> drm-ioremapagp.diff, as far as I can tell. 

Yes, you are, because it's included in my drm-trunk.tar.gz. So it does
make sense, *phew* :)

> Just to make sure, I rebuilt my drm modules from drm-trunk-module-src_2002.12.05-3_all.deb, 
> and it works just as fine (or is the patch already included in that?). In both 
> cases I get an (EE) RADEON(0): RADEONDRIResume: CP resume -1007
> on the console but it doesn't seem to have an impact (dri is still okay after 
> resuming).

Looks like Charl P. Botha's DRI resume patch. I suggested to him some
improvements, one of which would eliminate this harmless error message
(which is due to the counterpart in the DRM missing).

Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

Reply to: