[PATCH] x86: enable hpet=force for AMD SB400

[PATCH] x86: enable hpet=force for AMD SB400

[Andreas Herrmann]

x86: enable hpet=force for ATI SB400

Add quirk to allow forced usage of HPET on ATI SB400.
I stumbled over machines where HPET is enabled but not reported
by BIOS. This patch configures the HPET base address and makes
it known to the OS.

Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
---
 arch/x86/kernel/quirks.c |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index d89a648..5fe6bd5 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -65,6 +65,7 @@ static enum {
 	ICH_FORCE_HPET_RESUME,
 	VT8237_FORCE_HPET_RESUME,
 	NVIDIA_FORCE_HPET_RESUME,
+	ATI_FORCE_HPET_RESUME,
 } force_hpet_resume_type;
 
 static void __iomem *rcba_base;
@@ -330,6 +331,31 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8235,
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
 			 vt8237_force_enable_hpet);
 
+static void ati_force_hpet_resume(void)
+{
+	pci_write_config_dword(cached_dev, 0x14, 0xfed00000);
+	printk(KERN_DEBUG "Force enabled HPET at resume\n");
+}
+
+static void ati_force_enable_hpet(struct pci_dev *dev)
+{
+	u32 uninitialized_var(val);
+
+	if (!hpet_force_user || hpet_address || force_hpet_address)
+		return;
+
+	pci_write_config_dword(dev, 0x14, 0xfed00000);
+	pci_read_config_dword(dev, 0x14, &val);
+	force_hpet_address = val;
+	force_hpet_resume_type = ATI_FORCE_HPET_RESUME;
+	dev_printk(KERN_DEBUG, &dev->dev, "Force enabled HPET at 0x%lx\n",
+		   force_hpet_address);
+	cached_dev = dev;
+	return;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_SMBUS,
+			 ati_force_enable_hpet);
+
 /*
  * Undocumented chipset feature taken from LinuxBIOS.
  */
@@ -397,6 +423,9 @@ void force_hpet_resume(void)
 	case NVIDIA_FORCE_HPET_RESUME:
 		nvidia_force_hpet_resume();
 		return;
+	case ATI_FORCE_HPET_RESUME:
+		ati_force_hpet_resume();
+		return;
 	default:
 		break;
 	}
-- 
1.5.4.5

Re: [PATCH] x86: enable hpet=force for AMD SB400

[Andrew Morton]

On Fri, 9 May 2008 11:49:11 +0200
Andreas Herrmann <andreas.herrmann3@amd.com> wrote:

> x86: enable hpet=force for ATI SB400

Sigh.

> Add quirk to allow forced usage of HPET on ATI SB400.
> I stumbled over machines where HPET is enabled but not reported
> by BIOS.

Is there no way in which we can probe for or identify this condition,
rather than hoping that the user will find out about this boot option?

Re: [PATCH] x86: enable hpet=force for AMD SB400

[Thomas Gleixner]

On Fri, 9 May 2008, Andrew Morton wrote:
> On Fri, 9 May 2008 11:49:11 +0200
> Andreas Herrmann <andreas.herrmann3@amd.com> wrote:
> 
> > x86: enable hpet=force for ATI SB400
> 
> Sigh.
> 
> > Add quirk to allow forced usage of HPET on ATI SB400.
> > I stumbled over machines where HPET is enabled but not reported
> > by BIOS.
> 
> Is there no way in which we can probe for or identify this condition,
> rather than hoping that the user will find out about this boot option?

I'd love to have a sane solution for that, but looking at the rate of
HPET wreckage since we increased the usage of HPET I'm happy to have
this as an opt in thingy.

Thanks,

	tglx

Re: [PATCH] x86: enable hpet=force for AMD SB400

[Andrew Morton]

On Sat, 10 May 2008 01:42:30 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Fri, 9 May 2008, Andrew Morton wrote:
> > On Fri, 9 May 2008 11:49:11 +0200
> > Andreas Herrmann <andreas.herrmann3@amd.com> wrote:
> > 
> > > x86: enable hpet=force for ATI SB400
> > 
> > Sigh.
> > 
> > > Add quirk to allow forced usage of HPET on ATI SB400.
> > > I stumbled over machines where HPET is enabled but not reported
> > > by BIOS.
> > 
> > Is there no way in which we can probe for or identify this condition,
> > rather than hoping that the user will find out about this boot option?
> 
> I'd love to have a sane solution for that, but looking at the rate of
> HPET wreckage since we increased the usage of HPET I'm happy to have
> this as an opt in thingy.
> 

Well we don't have to auto-enable the hpet.  Simply adding a loud "you
should try the hpet=force option" printk would help a lot of people.

Re: [PATCH] x86: enable hpet=force for AMD SB400

[Thomas Gleixner]

On Fri, 9 May 2008, Andrew Morton wrote:
> On Sat, 10 May 2008 01:42:30 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > On Fri, 9 May 2008, Andrew Morton wrote:
> > > On Fri, 9 May 2008 11:49:11 +0200
> > > Andreas Herrmann <andreas.herrmann3@amd.com> wrote:
> > > 
> > > > x86: enable hpet=force for ATI SB400
> > > 
> > > Sigh.
> > > 
> > > > Add quirk to allow forced usage of HPET on ATI SB400.
> > > > I stumbled over machines where HPET is enabled but not reported
> > > > by BIOS.
> > > 
> > > Is there no way in which we can probe for or identify this condition,
> > > rather than hoping that the user will find out about this boot option?
> > 
> > I'd love to have a sane solution for that, but looking at the rate of
> > HPET wreckage since we increased the usage of HPET I'm happy to have
> > this as an opt in thingy.
> > 
> 
> Well we don't have to auto-enable the hpet.  Simply adding a loud "you
> should try the hpet=force option" printk would help a lot of people.

Fair enough. I look into that.

Thanks,
	tglx
 

Re: [PATCH] x86: enable hpet=force for AMD SB400

[Thomas Gleixner]

On Fri, 9 May 2008, Andrew Morton wrote:
> On Sat, 10 May 2008 01:42:30 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > On Fri, 9 May 2008, Andrew Morton wrote:
> > > On Fri, 9 May 2008 11:49:11 +0200
> > > Andreas Herrmann <andreas.herrmann3@amd.com> wrote:
> > > 
> > > > x86: enable hpet=force for ATI SB400
> > > 
> > > Sigh.
> > > 
> > > > Add quirk to allow forced usage of HPET on ATI SB400.
> > > > I stumbled over machines where HPET is enabled but not reported
> > > > by BIOS.
> > > 
> > > Is there no way in which we can probe for or identify this condition,
> > > rather than hoping that the user will find out about this boot option?
> > 
> > I'd love to have a sane solution for that, but looking at the rate of
> > HPET wreckage since we increased the usage of HPET I'm happy to have
> > this as an opt in thingy.
> > 
> 
> Well we don't have to auto-enable the hpet.  Simply adding a loud "you
> should try the hpet=force option" printk would help a lot of people.

Something like this ? That's on top of linus + Andreas SB400 patch

Thanks,
	tglx

------------> 
commit 3d5f406b110b1b1d314805a1a4c1744ff05d7f22
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sat May 10 21:42:14 2008 +0200

    x86: print info about available HPET quirk
    
    We have a lot of HPET quirks available which might force enable HPET
    even when the BIOS does not enable it. Some of those quirks depend on
    the command line option "hpet=force".
    
    Andrew pointed out that hoping that the user will find out about this
    boot option is not really helpful.
    
    Emit a kernel info which informs the user about the "hpet=force" boot
    option when we enter a quirk which depends on this option and the user
    did not provide it.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index 5fe6bd5..ddbf34d 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -175,6 +175,12 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_7,
 
 static struct pci_dev *cached_dev;
 
+static void hpet_print_force_info(void)
+{
+	printk(KERN_INFO "HPET not enabled in BIOS. "
+	       "You might try hpet=force boot option\n");
+}
+
 static void old_ich_force_hpet_resume(void)
 {
 	u32 val;
@@ -254,6 +260,8 @@ static void old_ich_force_enable_hpet_user(struct pci_dev *dev)
 {
 	if (hpet_force_user)
 		old_ich_force_enable_hpet(dev);
+	else
+		hpet_print_force_info();
 }
 
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_0,
@@ -291,8 +299,13 @@ static void vt8237_force_enable_hpet(struct pci_dev *dev)
 {
 	u32 uninitialized_var(val);
 
-	if (!hpet_force_user || hpet_address || force_hpet_address)
+	if (hpet_address || force_hpet_address)
+		return;
+
+	if (!hpet_force_user) {
+		hpet_print_force_info();
 		return;
+	}
 
 	pci_read_config_dword(dev, 0x68, &val);
 	/*
@@ -341,8 +354,13 @@ static void ati_force_enable_hpet(struct pci_dev *dev)
 {
 	u32 uninitialized_var(val);
 
-	if (!hpet_force_user || hpet_address || force_hpet_address)
+	if (hpet_address || force_hpet_address)
+		return;
+
+	if (!hpet_force_user) {
+		hpet_print_force_info();
 		return;
+	}
 
 	pci_write_config_dword(dev, 0x14, 0xfed00000);
 	pci_read_config_dword(dev, 0x14, &val);
@@ -369,8 +387,13 @@ static void nvidia_force_enable_hpet(struct pci_dev *dev)
 {
 	u32 uninitialized_var(val);
 
-	if (!hpet_force_user || hpet_address || force_hpet_address)
+	if (hpet_address || force_hpet_address)
+		return;
+
+	if (!hpet_force_user) {
+		hpet_print_force_info();
 		return;
+	}
 
 	pci_write_config_dword(dev, 0x44, 0xfed00001);
 	pci_read_config_dword(dev, 0x44, &val);

Re: [PATCH] x86: enable hpet=force for AMD SB400

[Alistair John Strachan]

On Saturday 10 May 2008 00:55:01 Andrew Morton wrote:
> On Sat, 10 May 2008 01:42:30 +0200 (CEST)
>
> Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Fri, 9 May 2008, Andrew Morton wrote:
> > > On Fri, 9 May 2008 11:49:11 +0200
> > >
> > > Andreas Herrmann <andreas.herrmann3@amd.com> wrote:
> > > > x86: enable hpet=force for ATI SB400
> > >
> > > Sigh.
> > >
> > > > Add quirk to allow forced usage of HPET on ATI SB400.
> > > > I stumbled over machines where HPET is enabled but not reported
> > > > by BIOS.
> > >
> > > Is there no way in which we can probe for or identify this condition,
> > > rather than hoping that the user will find out about this boot option?
> >
> > I'd love to have a sane solution for that, but looking at the rate of
> > HPET wreckage since we increased the usage of HPET I'm happy to have
> > this as an opt in thingy.
>
> Well we don't have to auto-enable the hpet.  Simply adding a loud "you
> should try the hpet=force option" printk would help a lot of people.

I'm a bit confused about the policy here: if we look at the Intel chipset 
overrides for HPET, they conditionally enable the HPET _without_ the 
hpet=force option if you have a chipset on the whitelist.

If Intel can do this on their chipsets, why is this not being done for the ATI 
chipsets for which (presumably) AMD have specs?

One thing I'd considered was that HPET isn't actually used very often on Intel 
chipsets because on most recent Intel CPUs the TSC is stable, but I think 
either the Intel quirk should be consistent with the hpet=force usage, 
or "known correct" HPET overrides should just always be applied.

-- 
Cheers,
Alistair.

137/1 Warrender Park Road, Edinburgh, UK.

Re: [PATCH] x86: enable hpet=force for AMD SB400

[Thomas Gleixner]

On Sun, 11 May 2008, Alistair John Strachan wrote:
> > Well we don't have to auto-enable the hpet.  Simply adding a loud "you
> > should try the hpet=force option" printk would help a lot of people.
> 
> I'm a bit confused about the policy here: if we look at the Intel chipset 
> overrides for HPET, they conditionally enable the HPET _without_ the 
> hpet=force option if you have a chipset on the whitelist.
> 
> If Intel can do this on their chipsets, why is this not being done for the ATI 
> chipsets for which (presumably) AMD have specs?

Well, we have no confirmation for the correctness of the non Intel
quirks so far. I'm happy to move them into unconditional mode once
AMD/ATI/NVidia tell us that the HPET is indeed discoverable this way.
 
> One thing I'd considered was that HPET isn't actually used very often on Intel 
> chipsets because on most recent Intel CPUs the TSC is stable, but I think 

Well, stable except for the C-States. We still need a backup clock
source as TSC is stopping in C3.

> either the Intel quirk should be consistent with the hpet=force usage, 
> or "known correct" HPET overrides should just always be applied.

That's what we do. We have "known correct" for Intel and those which
work on the patch submitters box w/o confirmation of the
correctness. I guess the SB400 one can move into the "is correct"
category, Andreas ???

Thanks,

	tglx

Re: [PATCH] x86: enable hpet=force for AMD SB400

[Andreas Herrmann]

On Sun, May 11, 2008 at 11:03:16AM +0200, Thomas Gleixner wrote:
> On Sun, 11 May 2008, Alistair John Strachan wrote:
> > > Well we don't have to auto-enable the hpet.  Simply adding a loud "you
> > > should try the hpet=force option" printk would help a lot of people.
> > 
> > I'm a bit confused about the policy here: if we look at the Intel chipset 
> > overrides for HPET, they conditionally enable the HPET _without_ the 
> > hpet=force option if you have a chipset on the whitelist.
> > 
> > If Intel can do this on their chipsets, why is this not being done for the ATI 
> > chipsets for which (presumably) AMD have specs?
> 
> Well, we have no confirmation for the correctness of the non Intel
> quirks so far. I'm happy to move them into unconditional mode once
> AMD/ATI/NVidia tell us that the HPET is indeed discoverable this way.
>  
> > One thing I'd considered was that HPET isn't actually used very often on Intel 
> > chipsets because on most recent Intel CPUs the TSC is stable, but I think 
> 
> Well, stable except for the C-States. We still need a backup clock
> source as TSC is stopping in C3.
> 
> > either the Intel quirk should be consistent with the hpet=force usage, 
> > or "known correct" HPET overrides should just always be applied.
> 
> That's what we do. We have "known correct" for Intel and those which
> work on the patch submitters box w/o confirmation of the
> correctness. I guess the SB400 one can move into the "is correct"
> category, Andreas ???

Sorry for the late reply, but I had to look for the spec in the first
place ;-) and I have done some coding and testing since then.
(Well, the patch was written as a quick hack to get HPET working on my
private laptop.)

The point is that at least some revisions of IXP400/IXP450 have indeed
hardware issues regarding HPET. Thus HPET works only for certain
chip revisions.

Currently I am internally discussing whether it makes sense to enable
(and properly configure) HPET for those chipset revisions.

BTW, if outcome of this discussion is that HPET on IXP400/IXP450
shouldn't be used then IMHO a quirk is needed to reliably disable it.
I.e. disable it even if a system provides an ACPI HPET table.

Thanks for your patience.


Regards,

Andreas

Re: [PATCH] x86: enable hpet=force for AMD SB400

[Andreas Herrmann]

On Sun, May 11, 2008 at 11:03:16AM +0200, Thomas Gleixner wrote:
> On Sun, 11 May 2008, Alistair John Strachan wrote:
> > either the Intel quirk should be consistent with the hpet=force usage, 
> > or "known correct" HPET overrides should just always be applied.
> 
> That's what we do. We have "known correct" for Intel and those which
> work on the patch submitters box w/o confirmation of the
> correctness. I guess the SB400 one can move into the "is correct"
> category, Andreas ???

Seems that I was too quick with the submission of my patch.  I have
done some testing in the past few weeks and there are severe problems
with HPET on IXP400/IXP450 which I was not aware of before.

The HPET on that chipset is usually not activated because it is not
fully compliant to the HPET spec. Using HPET on older revisions of
that chipset does not make sense at all.

For newer chipset revisions I found a working configuration, but ...

The only reliable configuration that worked in periodic _and_ one-shot
mode was to configure it such that HPET interrupt is delivered to INT2
of IOAPIC.

This means to force usage of HPET on IXP400/IXP450 needs a "manual"
IRQ0/INT2 override and some more chipset configuration to ensure that
the HPET interrupt is routed to INT2 of IOAPIC.

So this all is a big mess. And it probably explains why most (almost
all?) IXP400/IXP450 based systems do not provide an ACPI HPET table.

Said that, the question is, why would it still be worthwhile to force
usage of HPET on such systems. This is what sprang to my mind:

(1) availability of /dev/hpet for users

(2) faster timer programming

    From what I've seen setting up a timer in Linux' one-shot mode on
    SB400 (and also on SB600) is more than twice as fast when using
    HPET in comparison to PIT (on average).

(3) faster clocksource than acpi_pm

    E.g. on dual core K8 systems Linux cannot use TSC as clocksource.
    So usually it falls back to acpi_pm. IMHO access to HPET main
    counter is faster than using acpi_pm as clocksource. But I didn't
    determine exact numbers fot that.

(4) Viewer interrupts when Linux is running in NOHZ mode

    ... on systems where AMD C1E is enabled. If there is no HPET the
    Kernel falls back to PIT, but that one as just a 16-bit counter and
    overflows at least every 0.055 seconds.

(5) HPET is more accurate than PIT - as it has a smaller minimum delta
    (Examples for minimum delta according to /proc/timer_list are
    HPET:  3352 ns, PIT: 12571 ns.)

So far I have thought that (2) and (4) were helpful to save power on
my Turion X2 Laptop in NOHZ mode. But I recently did some evaluation
of that and it's rather negligible.

So there remain (1), (3) and (5) and I really tend to ignore HPET on
SB400 in the future. ;-(

It might even be worthwhile to disable it on systems where it's
advertised by an ACPI HPET table.

Any opinion about that last point?

In any case, please revert commit e8aa4667baf74dfd85fbaab86861465acb811085
The quirk is useless without doing more chipset an IOAPIC
configuration to ensure proper interrupt routing.


Thanks,

Andreas