On Friday 30 March 2007 03:09:14 David Brownell wrote:
quoted text
> 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.
No they don't, 

First patch does that:

                        hd.hd_irq[i] = (timer->hpet_config &
                                        Tn_INT_ROUTE_CNF_MASK) >>                                
					Tn_INT_ROUTE_CNF_SHIFT;

This just reads values assigned by BIOS.


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

Hi,
	I feel that you are right,

	You meant that one of HPET timers will be used as clock source and will be assigned some IRQ (not IRQ0)
	
	Seems fine,

	Only one thing: the kernel must assign IRQs to HPETS , relying on bios is not good,
	Also the IRQ for clocksource should be not shared, but maybe I am wrong here 
	(I am afraid that latencies might be a problem here)

	By the way I never thought about the fact that legacy replacement mode  is a 'virtual legacy'

	I mean that it is intended to simulate RTCs and PITs on systems that don't have them, am I right here ?
	HPET spec says that RTC is still requred to provide all its usial functions except periodic freq.

	Best regards,
		Maxim Levitsky
-
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/