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 Sat, 2007-03-31 at 19:17 +0200, Ingo Molnar wrote:
> yeah. There's some practical problems that need to be sorted out: much
> of the current GTOD code is irq-driven (and all GTOD locks are
> irq-safe), while the sysfs code needs to run in process-context level.
>
> Clocksources 'arrive'
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
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Umm.. WHy not make the device tree look like this:
>
> -- "clocksource" -- +-- HPET
> |
> +-- TSC
> |
> +-- i8259
>
On Sat, 31 Mar 2007, Maxim Levitsky wrote:
>
> So maybe I was right afrer all,
> Maybe it is better to add a suspend/resume hook to each clock source and call
> it from timekeeping_resume() ?
Umm.. WHy not make the device tree look like this:
-- "clocksource" -- +-- HPET
On Sat, Mar 31, 2007 at 09:53:43AM -0700, Linus Torvalds wrote:
> Make them be at the top of the device tree by adding them early. That's
> the whole point of the device tree after all - we have an ordering that is
> enforced by its topology, and that we sort by when things were added.
>
>
* Linus Torvalds <[EMAIL PROTECTED]> 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 ?
[...]
> So the only thing that needs to be done is to make sure that we add
>
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
the whole point of the device tree after all - we have an
On Saturday 31 March 2007 18:51:11 Thomas Gleixner wrote:
> On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> > Subject: Add suspend/resume for HPET
> > This adds support of suspend/resume on i386 for HPET
> > Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
> >
> > +static struct
On Sat, Mar 31, 2007 at 06:33:20PM +0200, Thomas Gleixner wrote:
> On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
> >
> > On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> > >
> > > While I agree in principle with the patch, I'm a bit uncomfortable. The
> > > sys device suspend / resume
On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
>
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> >
> > While I agree in principle with the patch, I'm a bit uncomfortable. The
> > sys device suspend / resume ordering is not guaranteed and relies on the
> > registering order.
>
> Well,
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
>
> While I agree in principle with the patch, I'm a bit uncomfortable. The
> sys device suspend / resume ordering is not guaranteed and relies on the
> registering order.
Well, this is why we probably should try to get away from the "system
device"
On Sun, 2007-04-01 at 00:01 +0800, Jeff Chua wrote:
> On 3/31/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
> > caused by time keeping / tick management resume happening before the
> > HPET resume.
>
>
> me>Confirmed
On 3/31/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
caused by time keeping / tick management resume happening before the
HPET resume.
me>Confirmed that suspend/resume disk/ram works on X60s with
me>CONFIG_HPET_TIMER=y
On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> Subject: Add suspend/resume for HPET
> This adds support of suspend/resume on i386 for HPET
> Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
>
> +static struct sysdev_class hpet_class = {
> + set_kset_name("hpet"),
> + .suspend
On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky [EMAIL PROTECTED]
+static struct sysdev_class hpet_class = {
+ set_kset_name(hpet),
+ .suspend=
On 3/31/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
caused by time keeping / tick management resume happening before the
HPET resume.
meConfirmed that suspend/resume disk/ram works on X60s with
meCONFIG_HPET_TIMER=y and
On Sun, 2007-04-01 at 00:01 +0800, Jeff Chua wrote:
On 3/31/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
caused by time keeping / tick management resume happening before the
HPET resume.
meConfirmed that
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
While I agree in principle with the patch, I'm a bit uncomfortable. The
sys device suspend / resume ordering is not guaranteed and relies on the
registering order.
Well, this is why we probably should try to get away from the system
device
On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
While I agree in principle with the patch, I'm a bit uncomfortable. The
sys device suspend / resume ordering is not guaranteed and relies on the
registering order.
Well, this is why
On Sat, Mar 31, 2007 at 06:33:20PM +0200, Thomas Gleixner wrote:
On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
While I agree in principle with the patch, I'm a bit uncomfortable. The
sys device suspend / resume ordering is not
On Saturday 31 March 2007 18:51:11 Thomas Gleixner wrote:
On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky [EMAIL PROTECTED]
+static struct sysdev_class
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
the whole point of the device tree after all - we have an
* Linus Torvalds [EMAIL PROTECTED] 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 ?
[...]
So the only thing that needs to be done is to make sure that we add
the timer
On Sat, Mar 31, 2007 at 09:53:43AM -0700, Linus Torvalds wrote:
Make them be at the top of the device tree by adding them early. That's
the whole point of the device tree after all - we have an ordering that is
enforced by its topology, and that we sort by when things were added.
Right now
On Sat, 31 Mar 2007, Maxim Levitsky wrote:
So maybe I was right afrer all,
Maybe it is better to add a suspend/resume hook to each clock source and call
it from timekeeping_resume() ?
Umm.. WHy not make the device tree look like this:
-- clocksource -- +-- HPET
* Linus Torvalds [EMAIL PROTECTED] wrote:
Umm.. WHy not make the device tree look like this:
-- clocksource -- +-- HPET
|
+-- TSC
|
+-- i8259
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
On Sat, 2007-03-31 at 19:17 +0200, Ingo Molnar wrote:
yeah. There's some practical problems that need to be sorted out: much
of the current GTOD code is irq-driven (and all GTOD locks are
irq-safe), while the sysfs code needs to run in process-context level.
Clocksources 'arrive' and
( 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
Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> there's no fundamental reason. x86_64 COW-ed hpet_timer.c and
> time_hpet.c years ago and drifted off into different areas.
Not quite -- x86-64 did HPET long before i386; the only stuff cowed
was the character driver support code. But the core HPET
On 3/29/07, Maxim Levitsky <[EMAIL PROTECTED]> wrote:
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
Confirmed that suspend/resume disk/ram works on X60s with
CONFIG_HPET_TIMER=y and CONFIG_NO_HZ
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Btw, what about arch/x86_64/kernel/hpet.c?
at least wrt. suspend/resume it should be fine, because in
arch/x86_64/kernel/time.c it does this upon resume:
static int timer_resume(struct sys_device *dev)
{
if (hpet_address)
update: i've tested Maxim's v2 patch on both a hpet-capable and a
hpet-less system, and it works fine here.
on a dual-core hpet-capable system, running a NO_HZ+!HIGH_RES_TIMERS
kernel:
europe:~> grep Clock /proc/timer_list
Clock Event Device: hpet
Clock Event Device: lapic
Clock Event
On Thursday 29 March 2007 18:53:37 Linus Torvalds wrote:
>
> On Thu, 29 Mar 2007, Maxim Levitsky wrote:
> >
> > Subject: Add suspend/resume for HPET
> >
> > This adds support of suspend/resume on i386 for HPET
> >
> > Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
> >
> > ---
> >
On Thu, 29 Mar 2007, Maxim Levitsky wrote:
>
> Subject: Add suspend/resume for HPET
>
> This adds support of suspend/resume on i386 for HPET
>
> Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
>
> ---
> arch/i386/kernel/hpet.c | 68
> +++
Btw,
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
---
arch/i386/kernel/hpet.c | 68 +++
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky [EMAIL PROTECTED]
---
arch/i386/kernel/hpet.c | 68 +++
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git
On Thu, 29 Mar 2007, Maxim Levitsky wrote:
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky [EMAIL PROTECTED]
---
arch/i386/kernel/hpet.c | 68
+++
Btw, what about
On Thursday 29 March 2007 18:53:37 Linus Torvalds wrote:
On Thu, 29 Mar 2007, Maxim Levitsky wrote:
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky [EMAIL PROTECTED]
---
arch/i386/kernel/hpet.c | 68
update: i've tested Maxim's v2 patch on both a hpet-capable and a
hpet-less system, and it works fine here.
on a dual-core hpet-capable system, running a NO_HZ+!HIGH_RES_TIMERS
kernel:
europe:~ grep Clock /proc/timer_list
Clock Event Device: hpet
Clock Event Device: lapic
Clock Event
* Linus Torvalds [EMAIL PROTECTED] wrote:
Btw, what about arch/x86_64/kernel/hpet.c?
at least wrt. suspend/resume it should be fine, because in
arch/x86_64/kernel/time.c it does this upon resume:
static int timer_resume(struct sys_device *dev)
{
if (hpet_address)
On 3/29/07, Maxim Levitsky [EMAIL PROTECTED] wrote:
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky [EMAIL PROTECTED]
Confirmed that suspend/resume disk/ram works on X60s with
CONFIG_HPET_TIMER=y and CONFIG_NO_HZ unset.
Ingo Molnar [EMAIL PROTECTED] writes:
there's no fundamental reason. x86_64 COW-ed hpet_timer.c and
time_hpet.c years ago and drifted off into different areas.
Not quite -- x86-64 did HPET long before i386; the only stuff cowed
was the character driver support code. But the core HPET code
62 matches
Mail list logo
