On Monday 02 April 2007 1:04 pm, Alan Stern wrote:
> On Mon, 2 Apr 2007, David Brownell wrote:
> > This is the kind of thing that the pm_parent relationship was (AFAICT)
> > originally supposed to handle. Of course, it doesn't/can't, given the
> > current implementation ... that relationship is
On Monday 02 April 2007 1:04 pm, Alan Stern wrote:
On Mon, 2 Apr 2007, David Brownell wrote:
This is the kind of thing that the pm_parent relationship was (AFAICT)
originally supposed to handle. Of course, it doesn't/can't, given the
current implementation ... that relationship is never
On Mon, 2007-04-02 at 16:04 -0400, Alan Stern wrote:
> > It's not that simple though, especially with HPET. The BIOS may expect
> > the PIT to work, but Linux currently (and problematically!) uses HPET in
> > "legacy replacement mode". And ISTR the problems are coming up when the
> > system is
On Mon, 2 Apr 2007, David Brownell wrote:
> What the driver model does now is problematic. Even if the clockevent
> stuff gets different fixes, those driver model issues still exist: the
> existence of dependencies that are not part of the device tree.
> No, it's a "just happened to work"
On Monday 02 April 2007 7:16 am, Alan Stern wrote:
> On Saturday March 31, 2007, David Brownell wrote:
>
> > Change how the PM list is constructed, so that devices are added right
> > after their parents (when they have one) rather than at the end of the
> > list. ...
> >
> > This patch has a
On Mon, 2 Apr 2007, Alan Stern wrote:
>
> Would you mind retracting this patch? It will interfere with some work
> I've been doing in USB, work that relies on exactly the sort of multiple
> power dependency you mention.
I agree. We should just make the damn timers be added at the right
On Saturday March 31, 2007, David Brownell wrote:
> I'm about ready to test the appended patch... a "move one device" call
> might be safest at this point in the release cycle though.
>
> - Dave
>
> SNIP!
> Change how the PM list is constructed, so that devices are
On Saturday March 31, 2007, David Brownell wrote:
I'm about ready to test the appended patch... a move one device call
might be safest at this point in the release cycle though.
- Dave
SNIP!
Change how the PM list is constructed, so that devices are added
On Mon, 2 Apr 2007, Alan Stern wrote:
Would you mind retracting this patch? It will interfere with some work
I've been doing in USB, work that relies on exactly the sort of multiple
power dependency you mention.
I agree. We should just make the damn timers be added at the right point.
On Monday 02 April 2007 7:16 am, Alan Stern wrote:
On Saturday March 31, 2007, David Brownell wrote:
Change how the PM list is constructed, so that devices are added right
after their parents (when they have one) rather than at the end of the
list. ...
This patch has a potential
On Mon, 2 Apr 2007, David Brownell wrote:
What the driver model does now is problematic. Even if the clockevent
stuff gets different fixes, those driver model issues still exist: the
existence of dependencies that are not part of the device tree.
No, it's a just happened to work because
On Mon, 2007-04-02 at 16:04 -0400, Alan Stern wrote:
It's not that simple though, especially with HPET. The BIOS may expect
the PIT to work, but Linux currently (and problematically!) uses HPET in
legacy replacement mode. And ISTR the problems are coming up when the
system is already in
On Saturday 31 March 2007 8:13 pm, Jeff Chua wrote:
> On 4/1/07, David Brownell <[EMAIL PROTECTED]> wrote:
> > for those will all get grouped together ... suspended "very late" and
> > resumed "very early", regardless of when they get registered. Pretty
> > much the driver model parts of what
On 4/1/07, David Brownell <[EMAIL PROTECTED]> wrote:
for those will all get grouped together ... suspended "very late" and
resumed "very early", regardless of when they get registered. Pretty
much the driver model parts of what Linus was suggesting; clockevent
bits would still be needed.
I
On Saturday 31 March 2007 11:18 am, David Brownell wrote:
> ( please remove obsolute [EMAIL PROTECTED] from further messages!! )
>
> On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
> >
> > i dont think there's any particular problem here because suspend/resume
> > wont be done during
( please remove obsolute [EMAIL PROTECTED] from further messages!! )
On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
>
> i dont think there's any particular problem here because suspend/resume
> wont be done during bootup - but we might need a way to move a device to
> earlier spots in
On Saturday 31 March 2007 9:53 am, Linus Torvalds wrote:
>
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> >
> > Right, but clock - sources/events need to be extremly late suspended and
> > early resumed. How can we ensure this ?
>
> Make them be at the top of the device tree by adding them
On Saturday 31 March 2007 9:53 am, Linus Torvalds wrote:
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
Right, but clock - sources/events need to be extremly late suspended and
early resumed. How can we ensure this ?
Make them be at the top of the device tree by adding them early. That's
( please remove obsolute [EMAIL PROTECTED] from further messages!! )
On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
i dont think there's any particular problem here because suspend/resume
wont be done during bootup - but we might need a way to move a device to
earlier spots in the
On Saturday 31 March 2007 11:18 am, David Brownell wrote:
( please remove obsolute [EMAIL PROTECTED] from further messages!! )
On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
i dont think there's any particular problem here because suspend/resume
wont be done during bootup -
On 4/1/07, David Brownell [EMAIL PROTECTED] wrote:
for those will all get grouped together ... suspended very late and
resumed very early, regardless of when they get registered. Pretty
much the driver model parts of what Linus was suggesting; clockevent
bits would still be needed.
I tested
On Saturday 31 March 2007 8:13 pm, Jeff Chua wrote:
On 4/1/07, David Brownell [EMAIL PROTECTED] wrote:
for those will all get grouped together ... suspended very late and
resumed very early, regardless of when they get registered. Pretty
much the driver model parts of what Linus was
22 matches
Mail list logo
