On Friday 30 March 2007 03:09:14 David Brownell wrote:
> On Thursday 29 March 2007 4:29 pm, Maxim Levitsky wrote:
> > On Friday 30 March 2007 00:33:35 David Brownell wrote:
> > > On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
>
> > > > So the only way out is to emulate RTC using HPET,
>
On Thursday 29 March 2007 4:29 pm, Maxim Levitsky wrote:
> On Friday 30 March 2007 00:33:35 David Brownell wrote:
> > On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
> > > So the only way out is to emulate RTC using HPET,
> > > It is done this way in old rtc driver, rtc-cmos should do the
On Friday 30 March 2007 00:33:35 David Brownell wrote:
> On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
> > On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
>
> > When HPET is active it eats RTC IRQ,
>
> Only when HPET timers 0 and 1 are set up for "Legacy Replacement Mode".
> In
On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
> On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
> When HPET is active it eats RTC IRQ,
Only when HPET timers 0 and 1 are set up for "Legacy Replacement Mode".
In the more sensible "Standard Mode", they have their own IRQs.
>
On Thu, 29 Mar 2007, Maxim Levitsky wrote:
>
> I agree, and as you said I did exactly that:
Gaah. I'm blind. Sorry. Your patch did indeed do exactly that, I somehow
overlooked it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Thursday 29 March 2007 18:35:21 Linus Torvalds wrote:
>
> On Thu, 29 Mar 2007, Maxim wrote:
>
> > On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
> > >
> > > (Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not
> > > to use the HPET, and set hpet_virt_address to
On Thu, 29 Mar 2007, Maxim wrote:
> On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
> >
> > (Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not
> > to use the HPET, and set hpet_virt_address to NULL?)
>
> This is done here
>
> out_nohpet:
>
On 3/29/07, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Quoting Maxim <[EMAIL PROTECTED]>:
> The patch below is a temporally fix, until
> clock-events and clocksources will get proper suspend/resume
> hooks:
Bingo!
I confirmed that it suspend/resume
On Thursday 29 March 2007 15:20:27 Sergei Shtylyov wrote:
> Hello.
>
> Maxim wrote:
>
> > ---
> > This adds support of suspend/resume on i386 for HPET
>
>The part after usually "---" gets cut off, the patch description and
> signoff should actially *precede* it.
>
> > Signed-off-by: Maxim
Hello.
Maxim wrote:
---
This adds support of suspend/resume on i386 for HPET
The part after usually "---" gets cut off, the patch description and
signoff should actially *precede* it.
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/hpet.c
Hello.
Maxim wrote:
---
This adds support of suspend/resume on i386 for HPET
The part after usually --- gets cut off, the patch description and
signoff should actially *precede* it.
Signed-off-by: Maxim Levitsky [EMAIL PROTECTED]
diff --git a/arch/i386/kernel/hpet.c
On Thursday 29 March 2007 15:20:27 Sergei Shtylyov wrote:
Hello.
Maxim wrote:
---
This adds support of suspend/resume on i386 for HPET
The part after usually --- gets cut off, the patch description and
signoff should actially *precede* it.
Signed-off-by: Maxim Levitsky [EMAIL
On 3/29/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Maxim [EMAIL PROTECTED]:
The patch below is a temporally fix, until
clock-events and clocksources will get proper suspend/resume
hooks:
Bingo!
I confirmed that it suspend/resume disk/ram all
On Thu, 29 Mar 2007, Maxim wrote:
On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
(Or, better yet, shouldn't we set boot_hpet_disable when we decide not
to use the HPET, and set hpet_virt_address to NULL?)
This is done here
out_nohpet:
iounmap(hpet_virt_address);
On Thursday 29 March 2007 18:35:21 Linus Torvalds wrote:
On Thu, 29 Mar 2007, Maxim wrote:
On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
(Or, better yet, shouldn't we set boot_hpet_disable when we decide not
to use the HPET, and set hpet_virt_address to NULL?)
On Thu, 29 Mar 2007, Maxim Levitsky wrote:
I agree, and as you said I did exactly that:
Gaah. I'm blind. Sorry. Your patch did indeed do exactly that, I somehow
overlooked it.
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
When HPET is active it eats RTC IRQ,
Only when HPET timers 0 and 1 are set up for Legacy Replacement Mode.
In the more sensible Standard Mode, they have their own IRQs.
So
On Friday 30 March 2007 00:33:35 David Brownell wrote:
On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
When HPET is active it eats RTC IRQ,
Only when HPET timers 0 and 1 are set up for Legacy Replacement Mode.
In the more
On Thursday 29 March 2007 4:29 pm, Maxim Levitsky wrote:
On Friday 30 March 2007 00:33:35 David Brownell wrote:
On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
So the only way out is to emulate RTC using HPET,
It is done this way in old rtc driver, rtc-cmos should do the same.
On Friday 30 March 2007 03:09:14 David Brownell wrote:
On Thursday 29 March 2007 4:29 pm, Maxim Levitsky wrote:
On Friday 30 March 2007 00:33:35 David Brownell wrote:
On Wednesday 28 March 2007 2:27 pm, Maxim wrote:
So the only way out is to emulate RTC using HPET,
On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
>
> On Thu, 29 Mar 2007, Maxim wrote:
> >
> > I am sending here a patch that as was discussed here adds hpet to list
> > of system devices
> > and adds suspend/resume hooks this way.
> > I tested it and it works fine.
>
> Ok,
On Thu, 29 Mar 2007, Maxim wrote:
>
> I am sending here a patch that as was discussed here adds hpet to list
> of system devices
> and adds suspend/resume hooks this way.
> I tested it and it works fine.
Ok, it certainly looks better, but it *also* looks like it just assumes
On Wednesday 28 March 2007 18:38:48 Linus Torvalds wrote:
>
> On Wed, 28 Mar 2007, Maxim wrote:
> >
> > Now I don't have a clue how to set those bits if only HPET is used as
> > clock source because now clocksources
> > don't have _any_ resume hook.
>
> One thing that drives me wild
On Wednesday 28 March 2007 22:42:00 Linus Torvalds wrote:
>
> On Wed, 28 Mar 2007, David Brownell wrote:
> >
> > On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
> >
> > > It's a *device*, dammit. It should save and resume like one (probably as
> > > a
> > > system device). The
On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
> On Wednesday 28 March 2007 1:19 pm, Maxim wrote:
> > On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
>
> > >
> > > Also, making HPET use the legacy mode seems like a step backwards.
>
> > It is not 'legacy' mode,
> > It
On Wednesday 28 March 2007 1:42 pm, Linus Torvalds wrote:
>
> I won't disagree - it might well be much nicer to just show it in the
> "real" device tree. I'm not 100% sure where in the tree it would go,
> though. It should probably be "inside" the root entry, before any of the
> PCI buses.
On Wednesday 28 March 2007 1:19 pm, Maxim wrote:
> On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
> >
> > Also, making HPET use the legacy mode seems like a step backwards.
> It is not 'legacy' mode,
> It is a legacy replacement mode.
Typo, sorry.
> It this mode HPET takes
On Wed, 28 Mar 2007, David Brownell wrote:
>
> On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
>
> > It's a *device*, dammit. It should save and resume like one (probably as a
> > system device). The "set_mode()" etc stuff is at a completely different
> > (higher) conceptual level.
On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
> On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
>
> > It's a *device*, dammit. It should save and resume like one (probably as a
> > system device). The "set_mode()" etc stuff is at a completely different
> > (higher)
On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
> It's a *device*, dammit. It should save and resume like one (probably as a
> system device). The "set_mode()" etc stuff is at a completely different
> (higher) conceptual level.
Agreed, except about "probably as a system device".
On Wed, 28 Mar 2007 20:04:57 +0200 Michael S. Tsirkin wrote:
> > Subject: first disk access after resume takes several minutes
> > ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> > References : http://lkml.org/lkml/2007/3/8/117
> >
* Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Bingo!
>
> The patch below fixes the two problems (listed above) with resume from
> RAM that I have observed on my T60 with 2.6.21-rc5: with this patch
> applied, and with CONFIG_NO_HZ unset, date advances correctly, X
> functions properly
> Subject: first disk access after resume takes several minutes
> ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> References : http://lkml.org/lkml/2007/3/8/117
> http://lkml.org/lkml/2007/3/25/20
> Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]>
On Wed, 28 Mar 2007, Maxim wrote:
>
> Now I don't have a clue how to set those bits if only HPET is used as
> clock source because now clocksources
> don't have _any_ resume hook.
One thing that drives me wild about that "clocksource resume" thing is
that it seems to think that
On Wednesday 28 March 2007 16:41:48 Ingo Molnar wrote:
>
> * Maxim <[EMAIL PROTECTED]> wrote:
>
> > I almost sure I know why this happens,
>
> cool! Your patch is a definite improvement on my t60 (where
> suspend/resume never worked with hpet enabled). But it does not fix
> everything - for
* Maxim <[EMAIL PROTECTED]> wrote:
> I almost sure I know why this happens,
cool! Your patch is a definite improvement on my t60 (where
suspend/resume never worked with hpet enabled). But it does not fix
everything - for example the timings are way off after resume. Thomas?
Ingo
-
To
On Wednesday 28 March 2007 09:04:28 Thomas Gleixner wrote:
> On Tue, 2007-03-27 at 01:46 +0800, Jeff Chua wrote:
> > On 3/27/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> >
> > > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > > suspend and resume from RAM (s2ram).
On Tue, 2007-03-27 at 01:46 +0800, Jeff Chua wrote:
> On 3/27/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > suspend and resume from RAM (s2ram). Even better, it works
> > > with/without CONFIG_NO_HZ.
> >
> > Does
On Tue, 2007-03-27 at 01:46 +0800, Jeff Chua wrote:
On 3/27/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
suspend and resume from RAM (s2ram). Even better, it works
with/without CONFIG_NO_HZ.
Does the patch below
On Wednesday 28 March 2007 09:04:28 Thomas Gleixner wrote:
On Tue, 2007-03-27 at 01:46 +0800, Jeff Chua wrote:
On 3/27/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
suspend and resume from RAM (s2ram). Even better,
* Maxim [EMAIL PROTECTED] wrote:
I almost sure I know why this happens,
cool! Your patch is a definite improvement on my t60 (where
suspend/resume never worked with hpet enabled). But it does not fix
everything - for example the timings are way off after resume. Thomas?
Ingo
-
To
On Wednesday 28 March 2007 16:41:48 Ingo Molnar wrote:
* Maxim [EMAIL PROTECTED] wrote:
I almost sure I know why this happens,
cool! Your patch is a definite improvement on my t60 (where
suspend/resume never worked with hpet enabled). But it does not fix
everything - for example the
On Wed, 28 Mar 2007, Maxim wrote:
Now I don't have a clue how to set those bits if only HPET is used as
clock source because now clocksources
don't have _any_ resume hook.
One thing that drives me wild about that clocksource resume thing is
that it seems to think that
Subject: first disk access after resume takes several minutes
('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
References : http://lkml.org/lkml/2007/3/8/117
http://lkml.org/lkml/2007/3/25/20
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
...
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Bingo!
The patch below fixes the two problems (listed above) with resume from
RAM that I have observed on my T60 with 2.6.21-rc5: with this patch
applied, and with CONFIG_NO_HZ unset, date advances correctly, X
functions properly and there
On Wed, 28 Mar 2007 20:04:57 +0200 Michael S. Tsirkin wrote:
Subject: first disk access after resume takes several minutes
('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
References : http://lkml.org/lkml/2007/3/8/117
On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
It's a *device*, dammit. It should save and resume like one (probably as a
system device). The set_mode() etc stuff is at a completely different
(higher) conceptual level.
Agreed, except about probably as a system device.
Last I
On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
It's a *device*, dammit. It should save and resume like one (probably as a
system device). The set_mode() etc stuff is at a completely different
(higher) conceptual level.
On Wed, 28 Mar 2007, David Brownell wrote:
On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
It's a *device*, dammit. It should save and resume like one (probably as a
system device). The set_mode() etc stuff is at a completely different
(higher) conceptual level.
Agreed,
On Wednesday 28 March 2007 1:19 pm, Maxim wrote:
On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
Also, making HPET use the legacy mode seems like a step backwards.
It is not 'legacy' mode,
It is a legacy replacement mode.
Typo, sorry.
It this mode HPET takes over IRQ0
On Wednesday 28 March 2007 1:42 pm, Linus Torvalds wrote:
I won't disagree - it might well be much nicer to just show it in the
real device tree. I'm not 100% sure where in the tree it would go,
though. It should probably be inside the root entry, before any of the
PCI buses.
Mixing
On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
On Wednesday 28 March 2007 1:19 pm, Maxim wrote:
On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
Also, making HPET use the legacy mode seems like a step backwards.
It is not 'legacy' mode,
It is a legacy
On Wednesday 28 March 2007 22:42:00 Linus Torvalds wrote:
On Wed, 28 Mar 2007, David Brownell wrote:
On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
It's a *device*, dammit. It should save and resume like one (probably as
a
system device). The set_mode() etc stuff is
On Wednesday 28 March 2007 18:38:48 Linus Torvalds wrote:
On Wed, 28 Mar 2007, Maxim wrote:
Now I don't have a clue how to set those bits if only HPET is used as
clock source because now clocksources
don't have _any_ resume hook.
One thing that drives me wild about that
On Thu, 29 Mar 2007, Maxim wrote:
I am sending here a patch that as was discussed here adds hpet to list
of system devices
and adds suspend/resume hooks this way.
I tested it and it works fine.
Ok, it certainly looks better, but it *also* looks like it just assumes
the
On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
On Thu, 29 Mar 2007, Maxim wrote:
I am sending here a patch that as was discussed here adds hpet to list
of system devices
and adds suspend/resume hooks this way.
I tested it and it works fine.
Ok, it certainly
On 3/27/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> suspend and resume from RAM (s2ram). Even better, it works
> with/without CONFIG_NO_HZ.
Does the patch below fix the HPET_TIMER=y case ?
Thomas, I tried, but it
On Mon, 2007-03-26 at 13:37 +0800, Jeff Chua wrote:
> On 3/26/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > > Resume from RAM (s2ram) still broke (tried with or without
> > > CONFIG_NO_HZ). Suspend to RAM seems ok, but upon resume, the screen
> > > will only display "inu" and only after
On Mon, 2007-03-26 at 13:37 +0800, Jeff Chua wrote:
On 3/26/07, Adrian Bunk [EMAIL PROTECTED] wrote:
Resume from RAM (s2ram) still broke (tried with or without
CONFIG_NO_HZ). Suspend to RAM seems ok, but upon resume, the screen
will only display inu and only after pressing the power
On 3/27/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
suspend and resume from RAM (s2ram). Even better, it works
with/without CONFIG_NO_HZ.
Does the patch below fix the HPET_TIMER=y case ?
Thomas, I tried, but it didn't
On 3/26/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Resume from RAM (s2ram) still broke (tried with or without
> CONFIG_NO_HZ). Suspend to RAM seems ok, but upon resume, the screen
> will only display "inu" and only after pressing the power button will
> the system return to console. But
On Mon, Mar 26, 2007 at 09:25:51AM +0800, Jeff Chua wrote:
> On 3/19/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> >Subject: ThinkPad doesn't resume from suspend to RAM
> >References : http://lkml.org/lkml/2007/2/27/80
> > http://lkml.org/lkml/2007/2/28/348
> >Submitter : Jens
On 3/19/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
Subject: ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80
http://lkml.org/lkml/2007/2/28/348
Submitter : Jens Axboe <[EMAIL PROTECTED]>
Jeff Chua <[EMAIL PROTECTED]>
On 3/19/07, Adrian Bunk [EMAIL PROTECTED] wrote:
Subject: ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80
http://lkml.org/lkml/2007/2/28/348
Submitter : Jens Axboe [EMAIL PROTECTED]
Jeff Chua [EMAIL PROTECTED]
Status
On Mon, Mar 26, 2007 at 09:25:51AM +0800, Jeff Chua wrote:
On 3/19/07, Adrian Bunk [EMAIL PROTECTED] wrote:
Subject: ThinkPad doesn't resume from suspend to RAM
References : http://lkml.org/lkml/2007/2/27/80
http://lkml.org/lkml/2007/2/28/348
Submitter : Jens Axboe [EMAIL
On 3/26/07, Adrian Bunk [EMAIL PROTECTED] wrote:
Resume from RAM (s2ram) still broke (tried with or without
CONFIG_NO_HZ). Suspend to RAM seems ok, but upon resume, the screen
will only display inu and only after pressing the power button will
the system return to console. But date still
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
68 matches
Mail list logo
