lkml.org 
[lkml]   [2004]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Fix Device Power Management States
HI!

> > Can you explain why this class-based quiescing is good idea? It seems
> > to me that "quiesce this tree" is pretty much same as "suspend this
> > tree", and can be handled in the same way.
> >
> > Nigel wanted to do class-based quiescing, but if we make quiescing
> > fast enough, it should be okay to do whole tree, always. (And I
> > believe quiescing *can* be fast enough).
>
> It has nothing to do with speed and everything to do with domains of
> responsibility. Each device belongs to 1 device class. That class and the
> assoicated class device represent the functional interface(s) to the
> physical device. While the physical device controls physical attributes,
> like actual I/O and power states, the class controls the logical
> interface.

I still do not see it... swsusp does not care about logical state of
device. (Actually manipulating logical state of device might make
swsusp less transparent). It cares about device not doing DMA (I also
said "no interrupts", but that is not strictly neccessary: we disable
interrupts for atomic copy. Device should do no NMIs, through).

Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.080 / U:0.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site