On Mon, Aug 9, 2010 at 8:24 PM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > >> > - transition from offb. If both kms and offb are built-in, the transition >> > leads to panel blooming. Note that it seems broken with nouveau on the G5 >> > as >> > well, I suspect we are passing a crap mode when picking up from offb at >> > boot. >> > >> >> wierd offb->nouveau worked on my G5, handoff doesn't do anything >> technically other than just remove offb from the system, >> and start the driver, so it should be like setting an initial mode. >> Unless the newer early handover messed it up. > > Yeah, not sure what's up, I suspect the driver get passed a bogus mode > in the initial set_par() when doing the handover. I'll see what I can > find out once I dig out my dual G5 which has a serial port :-) > >> > - Power Management. >> > >> > - Sleep/wakeup needs to be ported over from radeonfb (will also >> > be useful for some x86 models). >> >> I've started to port this on the M7 in a thinkpad on my desk, in >> theory it should save battery life as it appears currently the GPU >> doesn't go into D3 properly, >> however I haven't figured out exactly which bits are required, or >> proven its saving battery (the battery is a little old so I can't be >> sure). > > Ok. So there's basically two different things in that code. Merely D2 > sleep and re-POST (aka D3 cold). > > The former is supported on M6, M7 and M9 (at least some of these, the > code might need tweaks to work on non-powerbooks). In this case, we are > dealing with cases where the chip isn't powered down by the motherboard > or firmware. I don't actually know for sure -what- happens to it on the > relevant powerbooks actually, I suspect the clocks might go off, and/or > the VRAM is off. IE. If I don't run that code, I don't come back. > > The code was essentially contributed by ATI btw. > > Then there's code for M10/M11 which re-POSTs the chip. It mostly relies > on saving as much registers as can be and restoring things in the right > order, along with the right magic to restart PLLs, MC, DLLs, ... > > This code was written after analyzing the MacOS driver IO traces. Some > parts however cannot be saved/restored (memory init sequence), so in > that case, I have a "default" sequence, and I have code to retreive a > different one from the OF device-tree when available. For that code to > work more generically/better on x86's, we might want to add code to > extract that from the BIOS tables. >
The drm can already post the chip using the bios tables on x86, so we'd only need that for macs. > Now, I need to figure out how to make all this fit in our driver > architecture. Dave, can I see your patches ? That might give me some > good hints to get started. Hopefully, most of that can be kept safely in > the "r100" files and we can avoid clobbering too much of the core > drivers. > For chip init, you'd want to hook asic init stuff into radeon_combios_asic_init() in radeon_combios.c. That function uses the bios tables to init the chip. For the D2 stuff, you'd want to hook that into the r100_suspend/resume functions in r100.c and r300_suspend/resume in r300.c. Alex > Cheers, > Ben. > >> Dave. >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> -- >> _______________________________________________ >> Dri-devel mailing list >> Dri-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dri-devel > > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
