On Sun, 2005-01-30 at 01:48 +0200, Simo Melenius wrote: > Vincent Bernat wrote: > > >>Since the PBG4 has a nVidia graphic chip it will not sleep (AFAIK)... at > >>least until BenH gets one and goes one step forward in becoming a > >>saint. > > Benh will not be able to find out how to make it to sleep without some > > specs. It is the same story with ATI based one: the sleep started > > working when the specs have been submitted by ATI. > > Well, you can reverse-engineer or you can read the specs. I'm not a > hardware hacker but could the former not even be an option in this case?
Well, the sleep support for the latest models has been obtained by examining IO accesses done by the MacOS driver (Paulus did most of this work). We do have some specs, including register specs, but that's not enough. The actual bootstrap procedure of the chip is complex and beyond what is documented by specs, however, at least, having some specs and some knowledge of the chip (I've been tweaking ATI chips for some time now) did help very significantly. I don't have that knowledge of nVidia chips and don't even have a register spec, so why a similar thing is possible, it's not something I would do (and I don't have an nVidia based machine anyway). Also, it's amusing how people always talk about "reverse engineering" as it was the simplest thing to do... and could easily replace proper HW specs from vandors. It can be extremely complex and time consuming, especially with chips as convoluted as modern graphic chips, and I simply cannot spare the time for doing it, nor can pretty much anybody I know who would eventually be able to do it. > When I tried Debian GNU/Linux on my PB and stumbled upon the sleep > problem, I googled that IIRC the problem was related to waking up the > chip after sleep. Furthermore, someone had noticed the GeForce's .kext > even had symbols in it and, out of curiosity, I disassembled the kext. I > could find functions and assembly code that _seemed_ to be related to > waking up or resetting the chip, I'm not sure on how high/low level > though. I could imagine a seasoned guru could understand the relevant > code (or lack of it...) better, but since this was months ago I conclude > it can't be that simple. Therefore, I'm wondering what is it actually > with the nVidia chip that makes the trouble? Reading disassembled code, even when you are a seasoned guru, isn't like reading a clear explanation on what has to be done, especially when you do know what the various bits & pieces the code is peeking at/poking to are related to. The symbol names are definitely useful tho. I suspect somebody with HW access and enough time on his/her hands could obtain some reasults. Note that we _do_ have already some bits for nVidia chips, but not enough yet to revive the chip's output afaik. > > br, > S > > -- Benjamin Herrenschmidt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
