linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Feng Tang <feng.tang@intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: tglx@linutronix.de, mingo@elte.hu, hpa@zytor.com,
	linux-kernel@vger.kernel.org,
	John Stultz <john.stultz@linaro.org>,
	Clemens Ladisch <clemens@ladisch.de>,
	Andy Lutomirski <luto@amacapital.net>
Subject: Re: [PATCH v2] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64
Date: Fri, 28 Mar 2014 15:37:18 +0800	[thread overview]
Message-ID: <20140328073718.GA12762@feng-snb> (raw)
In-Reply-To: <20140328071716.GC30107@gmail.com>

Hi Ingo,

Thanks for reviewing this

On Fri, Mar 28, 2014 at 08:17:16AM +0100, Ingo Molnar wrote:
> 
> * Feng Tang <feng.tang@intel.com> wrote:
> 
> > On many new phone/tablet platforms like Baytrail/Merrifield etc, the 
> > HPET are either defeatured or has some problem to be used as a 
> > reliable timer. As these platforms also have X86_64, we should not 
> > make HPET_TIMER default y for all X86_64.
> 
> NAK!
> 
> If the HPET is unreliable on a specific platform then any of the 
> following solutions would address the problem (in order of 
> preference):
> 
>  - the hardware should not expose it. Why waste silicon on something 
>    that does not work?
> 
>  - or the firmware should not expose it. Why expose something that 
>    does not work?

Agreed, I've raised problem to BIOS vendor, but the response is very slow,
and those hardware/BIOS may already hit the market as a product.

> 
>  - or the kernel should have a quirk to reliably disable it. Why 
>    should we crash or misbehave if a driver is built into the
>    kernel?

I thought about this before, HPET doesn't have PCI ID like stuff, only
thing I can think of to identify them may be the CPU family/ID. 
Runtime check the reliability of HPET may be difficult, as we don't
know if the 8254 or the TSC are the golden timer to check HPET.

Thanks,
Feng


  reply	other threads:[~2014-03-28  7:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-28  2:55 [PATCH v2] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64 Feng Tang
2014-03-28  7:17 ` Ingo Molnar
2014-03-28  7:37   ` Feng Tang [this message]
2014-03-28  8:08     ` Clemens Ladisch
2014-03-28  8:11       ` Ingo Molnar
2014-03-28  8:20         ` Feng Tang
2014-04-15  7:44         ` Feng Tang
2014-04-15  9:00           ` Ingo Molnar
2014-04-15  9:55             ` Feng Tang
2014-04-15 10:42               ` Ingo Molnar
2014-04-15 14:12                 ` Feng Tang
2014-04-16  6:51                   ` Ingo Molnar
2014-04-18  7:18                     ` Feng Tang
2014-04-18  7:49                     ` [RFC PATCH] x86, hpet: Add quirk to disable HPET for baytrail platform Feng Tang
2014-04-18  8:15                       ` Ingo Molnar

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=20140328073718.GA12762@feng-snb \
    --to=feng.tang@intel.com \
    --cc=clemens@ladisch.de \
    --cc=hpa@zytor.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@elte.hu \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).