Re: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[David Brownell <david-b@pacbell.net>]

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.
> > 
> > No.  Patches like
> > 
> >   http://marc.info/?l=linux-kernel&m=117219531503973&w=2

also:   http://marc.info/?l=linux-kernel&m=117219531526317&w=2

> > should be merged (I hope they're in the 2.6.22 queue!), making
> > HPET run in "Standard Mode" so that HPET can stop sticking its
> > fingers in code where they don't belong.
> >
> > ...
>
> 	It is not that simple,
> 
> 	Only in legacy replacement mode HPET can be put on IRQ0 (and sadly  IRQ8)
> 	At least this is true on some systems, on mine for example

Right, that's the entire point of legacy replacement mode.

But so what?  In standard mode, HPET just uses other IRQs.
Nothing would care about irq0, and irq8 would be used by
the RTC as necessary.


> 	this will make it difficult to use it as a clockevents source

Why?  It's not like the clockevent logic cares what IRQ a given
programmable timer uses.  So long as the HPET driver can receive
its IRQ, it'll make a fine clockevent.  There's no reason to have
HPET prevent other drivers from working, by insisting it use that
nasty "prevent other hardware from issuing IRQs" mode.

The patches from Venkatesh sure seem to have behaved for him.
And while he might have complained about difficulty, I think
that'd be more likely due to the SMP issues he also addressed
than because of some (historical?) attachment to irq0.


> 	Not to mention the fact that current code assumes that BIOS
> 	assigned IRQs to all timers which is not true on my system. 

Getting IRQ routing sorted out is a problem that's been solved
numerous times before.  And again, the patches referenced above
seem to have resolved any such issues.


> 	What is wrong with relying on HPET to provide RTC IRQ ?

For starters, it's not an RTC.  Why in the world would you want to
make the OS think it's an RTC ... unless you're Microsoft, and are
desperate to get another periodic timer (and don't much care about
the other RTC functionality?


... that's all off-topic for 2.6.21 regressions though; it's too
late to merge x86_64 clockevent support, or fix HPET issues like
not using "standard mode".

- Dave