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

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

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. 



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps

On Wed, 2003-07-09 at 19:45, James Simmons wrote:

quoted

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




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps

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



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

On Sat, 2002-01-05 at 12:13, Pavel Machek wrote:

Hi!

quoted

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.




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Hi!

quoted

quoted

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


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1