On Thursday 29 March 2007 4:29 pm, Maxim Levitsky wrote:
quoted text
> On Friday 30 March 2007 00:33:35 David Brownell wrote:
> > On Wednesday 28 March 2007 2:27 pm, Maxim wrote:

quoted text
> > > 	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

quoted text
> > 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.


quoted text
> 	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.


quoted text
> 	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.


quoted text
> 	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

-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/