Re: [RFC] Fix Device Power Management States

[Pavel Machek]

Hi!

> > Well, "no DMA" needs to be part of definition, too, because some
> > devices (USB) do DMA only if they have nothing to do.
> 
> I don't understand; that doesn't sound healthy.

It is not healthy. It is basicaly misdesigned piece of hardware called
UHCI. It simply does DMA all the time :-(.

> > if something like this gets merged, it will immediately break swsusp
> > because initially no drivers will have "stop" methods.
> >
> > Passing system state down to drivers and having special "quiesce"
> > (as discussed in rather long thread) state has advantage of
> > automagicaly working on drivers that ignore u32 parameter of suspend
> > callback (and that's most of them). David's patches do not bring us
> > runtime suspend capabilities, but do not force us to go through all
> > the drivers, either...
> 
> Nothing is free. ;)
> 
> We've been talking about creating and merging a sane power management
> model for 3+ years now. It's always been known that the drivers will have
> to be modified to support a sane model. It's a fact of life. At some
> point, we have to bite the bullet and do the work. I see that time rapidly
> approaching.
> 
> I do not intend to merge a patch that will break swsusp in a stable
> kernel. However, we do have this wonderful thing called the -mm tree in
> which we can a) evolve the model, b) get large testing coverage and c)
> solicit driver fixes.
> 
> Once the swsusp consolidation is merged upstream, I will merge a new
> device power model in -mm, and we can start working on the drivers. How
> does that sound?

It sounds like an acceptable plan. I see no real disadvantage in
"suspend with parameter X means quiesce", and I think we'd get smaller
patch that way, but if you go through -mm like this, we can do it.

								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/