mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>, Andi Kleen <ak@suse.de>
Subject: Re: [RFC][PATCH] X86_64: no legacy HPET fix
Date: Wed, 13 Apr 2005 19:21:04 -0700	[thread overview]
Message-ID: <20050413192103.A27092@unix-os.sc.intel.com> (raw)
In-Reply-To: <1113360197.19541.43.camel@cog.beaverton.ibm.com>; from johnstul@us.ibm.com on Tue, Apr 12, 2005 at 07:43:16PM -0700



This adds another timer combination of PIT/HPET to go with
HPET/HPET, HPET/TSC and PIT/TSC!
This system that has HPET and doesn't have Legacy support, does it support
routing HPET interrupts through IOAPIC in standard routing option? If yes,
then I think adding support to route HPET interrupts in a non-legacy way
(using IRQs other than IRQ 0) is another option here. I looked at that 
when adding initial HPET support on i386, but dropped that idea after looking
at all the changes required and also due to the reason that all HPET capable
systems I had also had Legacy Support.


Some comments on the patch inlined below..

On Tue, Apr 12, 2005 at 07:43:16PM -0700, john stultz wrote:
> 
> Its likely a similar patch will be necessary for i386.
Yes. Pretty much similar change will be required in i386 as well..

> linux-2.6.12-rc2_hpet-nolegacy-fix_A0
> =====================================
> diff -Nru a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
> --- a/arch/x86_64/kernel/time.c	2005-04-12 19:31:50 -07:00
> +++ b/arch/x86_64/kernel/time.c	2005-04-12 19:31:50 -07:00
> @@ -373,8 +374,10 @@
>  
>  	write_seqlock(&xtime_lock);
>  
> -	if (vxtime.hpet_address) {
> -		offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
> +	if (vxtime.hpet_address)
> +		offset = hpet_readl(HPET_COUNTER);
> +
> +	if (hpet_use_timer) {
>  		delay = hpet_readl(HPET_COUNTER) - offset;

Probably this has to change to use HPET_T0_CMP for offset, when hpet_use_timer.
Otherwise we will always have delay close to zero in case of hpet_use_timer,
which is a change in behaviour.

>  	} else {
>  		spin_lock(&i8253_lock);
> @@ -732,7 +735,7 @@
>  	struct hpet_data	hd;
>  	unsigned int 		ntimer;
>  
> -	if (!vxtime.hpet_address)
> +	if (!hpet_use_timer)
>            return -1;

We may need to do some initialization here even in case of !hpet_use_timer.
Like reserving particular HPET timer for timer use. Otherwise, someone
else (/dev/hpet) can overwrite the counter. I think we just need to skip 
setting the interupts part.


Thanks,
Venki

  reply	other threads:[~2005-04-14  2:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-13  2:43 john stultz
2005-04-14  2:21 ` Venkatesh Pallipadi [this message]
2005-04-19  0:59   ` [RFC][PATCH] X86_64: no legacy HPET fix (v. A1) john stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050413192103.A27092@unix-os.sc.intel.com \
    --to=venkatesh.pallipadi@intel.com \
    --cc=ak@suse.de \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome