From: James S. <jsi...@in...> - 2003-07-08 23:26:38
|
> I'm trying to get the radeon M6 in my new Fujitsu Lifebook to handle > ACPI S3 suspend and resume properly - at the moment, on resume it > fails to do anything. Looking at the driver, the reason is quite > obvious (no .suspend and .resume functions defined), but the driver > file has code to handle these (apparently only for the PowerBooks, > since it's wrapped in a #ifdef CONIG_PMAC_PBOOK). My Lifebook P2120 > is a Crusoe 5800 based setup, with a PCI M6, so it's not even being > built, let alone enabled and used. > > As far as I can tell, if I removed the #ifdef CONFIG_PMAC_PBOOK and > split the current radeon_set_suspend up into suspend and resume > functions to fit the current power management stuff, it might have > some chance of working. Can you tell me if this is a reasonable > first step? > > Alternatively, if you have patches that I could test, I'd be quite > happy to give them a go - being a guinea pig sounds like fun ;-) No patches at this time. I need to learn the new power management code. Where are the docs for them ? |
From: Benjamin H. <be...@ke...> - 2003-07-09 11:37:09
|
> No patches at this time. I need to learn the new power management code. > Where are the docs for them ? The PM code in radeonfb is probably only useful for Mac laptops where we have to manually put the chip in D2 state. I don't think x86 laptops use D2... Note that I have a patch adding some basic PM support to fbdev in 2.5 that I need to send you for review. The PM is always initiated by the low level driver which gets notified of PM events by its parent bus, what I added is a way for the driver to "broadcast" that to clients like fbcon so fbcon can stop touching the framebuffer while the chip is potentially off, and can restore the display on wakeup. I'll send that to you asap. Note: The Power Management isn't well implemented in 2.5 yet. The infrastructure is mostly there, but the driver side semantics are still wrong. Patrick Mochel has a new implementation that is much better, but he didn't merge it upstream yet. I expect this will happen around Kernel Summit / OLS. Ben. |
From: Russell K. <rm...@ar...> - 2003-07-09 14:11:07
|
On Wed, Jul 09, 2003 at 01:35:58PM +0200, Benjamin Herrenschmidt wrote: > Note: The Power Management isn't well implemented in 2.5 yet. The > infrastructure is mostly there, but the driver side semantics are > still wrong. Patrick Mochel has a new implementation that is much > better, but he didn't merge it upstream yet. I expect this will > happen around Kernel Summit / OLS. I'm slightly concerned by this. There are a growing amount of drivers in 2.5 which are being made to work with the existing power management system. This "new" system seems to have been hanging around for about 4 months now with no visible further work, presumably so that a paper can be presented before its release. My concern is that there has been: - 4 months of non-exposure of this work - 4 months of making the current system work - and putting it in will require a fair number of drivers to be re-worked. Apart from driver re-work and that the core interfaces are supposed to be stable, what are the technical arguments against merging it, say, today? -- Russell King (rm...@ar...) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html |
From: James S. <jsi...@in...> - 2003-07-09 17:46:33
|
> My concern is that there has been: > - 4 months of non-exposure of this work > - 4 months of making the current system work > - and putting it in will require a fair number of drivers to be > re-worked. > > Apart from driver re-work and that the core interfaces are supposed to > be stable, what are the technical arguments against merging it, say, > today? This is the reason I have waited. |
From: Benjamin H. <be...@ke...> - 2003-07-09 17:51:41
|
On Wed, 2003-07-09 at 19:45, James Simmons wrote: > > My concern is that there has been: > > - 4 months of non-exposure of this work > > - 4 months of making the current system work > > - and putting it in will require a fair number of drivers to be > > re-worked. > > > > Apart from driver re-work and that the core interfaces are supposed to > > be stable, what are the technical arguments against merging it, say, > > today? > > This is the reason I have waited. Those changes will only affect drivers, there is still need for some mecanism to deal with fbcon. I'll send you a patch before the end of the week hopefully. There may be a better way of doing it than my patch by having fbcon be someway a child of the HW driver in the device-tree, but it's a bit nasty right now, and my patch adds a more generic way to notify "clients" of fbdev's (like fbcon) of events at the low level that could be used for hotplug monitor change notification or whatever... Ben |
From: Pavel M. <pa...@uc...> - 2003-07-14 12:45:31
|
Hi! > I'm slightly concerned by this. There are a growing amount of drivers > in 2.5 which are being made to work with the existing power management > system. This "new" system seems to have been hanging around for about > 4 months now with no visible further work, presumably so that a paper > can be presented before its release. I believe it is bad idea to change driver model again in 2.6.x-pre. I believe current solution is pretty much okay. -- Pavel Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need... |
From: Benjamin H. <be...@ke...> - 2003-07-14 16:35:53
|
On Sat, 2002-01-05 at 12:13, Pavel Machek wrote: > Hi! > > > I'm slightly concerned by this. There are a growing amount of drivers > > in 2.5 which are being made to work with the existing power management > > system. This "new" system seems to have been hanging around for about > > 4 months now with no visible further work, presumably so that a paper > > can be presented before its release. > > I believe it is bad idea to change driver > model again in 2.6.x-pre. I believe current > solution is pretty much okay. Current solution is not okay and actually, the save_state/suspend distinction makes no sense. We have designed a working solution a while ago now, Patrick has it implemented for month, it must get in now or 2.6 will not have proper power management but just "might work" kind of crap Ben. |
From: Pavel M. <pa...@su...> - 2003-07-14 20:12:12
|
Hi! > > > I'm slightly concerned by this. There are a growing amount of drivers > > > in 2.5 which are being made to work with the existing power management > > > system. This "new" system seems to have been hanging around for about > > > 4 months now with no visible further work, presumably so that a paper > > > can be presented before its release. > > > > I believe it is bad idea to change driver > > model again in 2.6.x-pre. I believe current > > solution is pretty much okay. > > Current solution is not okay and actually, the save_state/suspend > distinction makes no sense. > We have designed a working solution > a while ago now, Patrick has it implemented for month, it must > get in now or 2.6 will not have proper power management but just > "might work" kind of crap save_state/suspend distinction may be irrelevant, but I don't see how it makes whole current code "might work" kind of crap. Can you describe some significant problem with current code? I do not think it is good idea to have to touch all drivers in 2.6.0-test time without some *good* reason. Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] |