Re: [Linux-fbdev-devel] fbdev and power management

Re: [Linux-fbdev-devel] fbdev and power management

[Pavel Machek]

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

fbdev and power management

[James Simmons]

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

Re: [Linux-fbdev-devel] fbdev and power management

[Benjamin Herrenschmidt]

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

Re: [Linux-fbdev-devel] fbdev and power management

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [Linux-fbdev-devel] fbdev and power management

[James Simmons]

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

Re: [Linux-fbdev-devel] fbdev and power management

[Benjamin Herrenschmidt]

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

Re: [Linux-fbdev-devel] fbdev and power management

[Benjamin Herrenschmidt]

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.

Re: [Linux-fbdev-devel] fbdev and power management

[Pavel Machek]

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?]