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 sam
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 t
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-ide" in
the body of
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:
> iounmap(hpet_vi
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/ra
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 b/arch/i386/k
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, i
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 abo
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_mo
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
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.
Mi
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 ov
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) conceptu
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
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
> > http://lkml.org/lk
* 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
> 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 cl
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 ex
* 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 t
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
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 pressin
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"
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 Ax
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
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 involv
34 matches
Mail list logo
