> > - 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. 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. 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
