LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* RE: [PATCH 1/5] RT kernel: force detect HPET from PCI space
@ 2007-03-30 22:09 Mikko Tiihonen
  2007-03-30 22:38 ` Nicolas Mailhot
  0 siblings, 1 reply; 12+ messages in thread
From: Mikko Tiihonen @ 2007-03-30 22:09 UTC (permalink / raw)
  To: nicolas.mailhot; +Cc: linux-kernel


> Anyone got the same thing for CK804? I had my hopes high, and then I saw
> the DECLARE_PCI_FIXUP_HEADER values [and the thread title was misleading]

I have an A8N-E motherboard with AthlonX2 and the ACPI definitions are 
missing the HPET (standard feature of Asus motherboards).

I too got interested to get my motherboard working. Luckily I found this 
http://lkml.org/lkml/2006/12/17/69 from which I generated the following patch:

--- arch/i386/kernel/quirks.c.orig	2007-03-30 23:43:06.000000000 +0300
+++ arch/i386/kernel/quirks.c	2007-03-30 23:26:47.000000000 +0300
@@ -101,5 +101,39 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_I
  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_1,     force_enable_hpet);
  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_31,     force_enable_hpet);
  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH8_1,     force_enable_hpet);
+
+static void __init force_enable_nvidia_hpet(struct pci_dev *dev)
+{
+        u8 enabled;
+	u32 addr;
+
+	if (hpet_address)
+		return;
+
+	pci_read_config_dword(dev, 0x44, &addr);
+	if (addr != 0xfefff000L) {
+		printk(KERN_INFO "Unsafe HPET address 0x%08x. Cannot force enable HPET\n", addr);
+		return;
+	}
+
+	pci_read_config_byte(dev, 0xA3, &enabled);
+	if ((enabled & 4) == 0) {
+	        if (enabled != 0xc1) {
+		  printk(KERN_INFO "Unsafe HPET enable 0x%02x. Cannot force enable HPET\n", enabled);
+		  return;
+		}
+		pci_write_config_byte(dev, 0xA3, enabled | 4);
+		pci_read_config_byte(dev, 0xA3, &enabled);
+		if ((enabled & 4) == 0) {
+			printk(KERN_INFO "Failed to force enable HPET\n");
+			return;
+		}
+	}
+
+	force_hpet_address = addr;
+	printk(KERN_INFO "Force enabled HPET. Base address 0x%08lx\n", force_hpet_address);
+}
+
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA,	0x0050,     force_enable_nvidia_hpet); // NForce4
  #endif

Now Linux seems to detect HPET and it passes at least the basic sanity checks:

Force enabled HPET. Base address 0xfefff000
HPET: hpet_period 40000000, hpet_tick 83333
Successfully registered HPET clocksource

Unfortunately the 2.6.20-mm2 kernel to which I tried to patch the patch series 
seems to hang few seconds later after half way in udev startup event 
processing.

It could either be something totally different in 2.6.20-mm2 that just happens 
to fail or more likely some interrupt setup that still needs to be done.

I have no idea how to continue from here.

-Mikko

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [PATCH 1/5] RT kernel: force detect HPET from PCI space
  2007-03-30 22:09 [PATCH 1/5] RT kernel: force detect HPET from PCI space Mikko Tiihonen
@ 2007-03-30 22:38 ` Nicolas Mailhot
  2007-03-31  8:00   ` Mikko Tiihonen
  2007-03-31 10:37   ` Krzysztof Halasa
  0 siblings, 2 replies; 12+ messages in thread
From: Nicolas Mailhot @ 2007-03-30 22:38 UTC (permalink / raw)
  To: Mikko Tiihonen; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

Le samedi 31 mars 2007 à 01:09 +0300, Mikko Tiihonen a écrit :
> > Anyone got the same thing for CK804? I had my hopes high, and then I saw
> > the DECLARE_PCI_FIXUP_HEADER values [and the thread title was misleading]
> 
> I have an A8N-E motherboard with AthlonX2 and the ACPI definitions are 
> missing the HPET (standard feature of Asus motherboards).
> 
> I too got interested to get my motherboard working. Luckily I found this 
> http://lkml.org/lkml/2006/12/17/69 

Oh, is looks so close to my system

00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
        Subsystem: Giga-byte Technology GA-K8N Ultra-9 Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
00: de 10 50 00 0f 00 a0 00 a3 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 11 0c
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 58 14 11 0c 00 f0 ff fe fa 3e ff 00 fa 3e ff 00
                ^^^^^^^^^^^
                Usual HPET base address
50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff
60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 f9 ff
70: 10 00 ff ff c1 00 00 00 00 00 04 19 18 d2 80 0d
                ^^
                c1 => HPET disabled (according to your reference)

I don't have an HPET toggle in my bios

> from which I generated the following patch:

I'd love to test it, but what kernel baseline did you use?
2.6.21-rc5-mm2?

-- 
Nicolas Mailhot

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [PATCH 1/5] RT kernel: force detect HPET from PCI space
  2007-03-30 22:38 ` Nicolas Mailhot
@ 2007-03-31  8:00   ` Mikko Tiihonen
  2007-03-31 10:37   ` Krzysztof Halasa
  1 sibling, 0 replies; 12+ messages in thread
From: Mikko Tiihonen @ 2007-03-31  8:00 UTC (permalink / raw)
  To: Nicolas Mailhot; +Cc: linux-kernel

On Sat, 31 Mar 2007, Nicolas Mailhot wrote:

> Le samedi 31 mars 2007 à 01:09 +0300, Mikko Tiihonen a écrit :
>>> Anyone got the same thing for CK804? I had my hopes high, and then I saw
>>> the DECLARE_PCI_FIXUP_HEADER values [and the thread title was misleading]
>>
>> I have an A8N-E motherboard with AthlonX2 and the ACPI definitions are
>> missing the HPET (standard feature of Asus motherboards).
>>
>> I too got interested to get my motherboard working. Luckily I found this
>> http://lkml.org/lkml/2006/12/17/69
>
> Oh, is looks so close to my system
>
> 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
>        Subsystem: Giga-byte Technology GA-K8N Ultra-9 Mainboard
>        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
>        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>        Latency: 0
> 00: de 10 50 00 0f 00 a0 00 a3 00 01 06 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 11 0c
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 58 14 11 0c 00 f0 ff fe fa 3e ff 00 fa 3e ff 00
>                ^^^^^^^^^^^
>                Usual HPET base address
> 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff
> 60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 f9 ff
> 70: 10 00 ff ff c1 00 00 00 00 00 04 19 18 d2 80 0d
>                ^^
>                c1 => HPET disabled (according to your reference)
>
> I don't have an HPET toggle in my bios
>
>> from which I generated the following patch:
>
> I'd love to test it, but what kernel baseline did you use?
> 2.6.21-rc5-mm2?

No, I could not get the original patches to apply to any new kernel. They did 
apply to 2.6.20-mm2 with very minimal collisions.

I only applied patches 1/5 and 2/5 of the original series. But now that I look 
into patch 3/5 it seems that it has useful irq allocation things.

Anyway, I think the best way would be to get 2.6.20-rt8 against which the 
original patch series was made. Add all 5 patches from Venkatesh and then try 
with my patch added. I'll try that myself later today.

-Mikko

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
  2007-03-30 22:38 ` Nicolas Mailhot
  2007-03-31  8:00   ` Mikko Tiihonen
@ 2007-03-31 10:37   ` Krzysztof Halasa
  2007-03-31 11:36     ` Nicolas Mailhot
  1 sibling, 1 reply; 12+ messages in thread
From: Krzysztof Halasa @ 2007-03-31 10:37 UTC (permalink / raw)
  To: Nicolas Mailhot; +Cc: Mikko Tiihonen, linux-kernel

Nicolas Mailhot <nicolas.mailhot@laposte.net> writes:

> Oh, is looks so close to my system
>
> 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
> 00: de 10 50 00 0f 00 a0 00 a3 00 01 06 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 11 0c
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 58 14 11 0c 00 f0 ff fe fa 3e ff 00 fa 3e ff 00
>                 ^^^^^^^^^^^
>                 Usual HPET base address
> 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff
> 60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 f9 ff
> 70: 10 00 ff ff c1 00 00 00 00 00 04 19 18 d2 80 0d
>                 ^^
>                 c1 => HPET disabled (according to your reference)
>
> I don't have an HPET toggle in my bios

For reference: HPET enabled in BIOS, MSI K9N platinum board:

dmesg | grep HPET
ACPI: HPET (v001 A M I  OEMHPET0 0x02000701 MSFT 0x00000097)
	@ 0x000000003ffd5480
ACPI: HPET id: 0x10de8201 base: 0xfed00000
time.c: Using 25.000000 MHz WALL HPET GTOD HPET timer.

00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)
        Subsystem: Micro-Star International Co., Ltd. Unknown device 7250
        Flags: bus master, 66MHz, fast devsel, latency 0
        I/O ports at 2f00 [size=128]
00: de 10 62 03 0f 00 a0 00 a2 00 01 06 00 00 80 00
10: 01 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 50 72
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
40: 62 14 50 72 00 00 d0 fe fa 3e ff 00 fa 3e ff 00
                ^^^^^^^^^^^
Dword at 0x44 indeed seems to be the address

50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 fe 3f
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 ff
70: 10 00 ff ff c5 80 00 00 00 00 45 19 00 c6 40 00
                ^^
Enabled = consistent with http://lkml.org/lkml/2006/12/17/69

80: 09 20 00 10 1d 08 00 00 f0 00 00 01 f0 00 00 00
90: 00 08 00 00 00 00 00 00 21 47 95 86 ef cd ab 00
a0: 01 00 00 81 00 00 00 00 00 00 00 00 00 00 00 00
             ^^
Not sure about 0xa3, though.

b0: 00 00 00 00 00 0a 7f 0a 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 44 00 00 fe fd d3 00 a0
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00
-- 
Krzysztof Halasa

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
  2007-03-31 10:37   ` Krzysztof Halasa
@ 2007-03-31 11:36     ` Nicolas Mailhot
  2007-03-31 15:00       ` Mikko Tiihonen
  0 siblings, 1 reply; 12+ messages in thread
From: Nicolas Mailhot @ 2007-03-31 11:36 UTC (permalink / raw)
  To: Krzysztof Halasa; +Cc: Mikko Tiihonen, linux-kernel, ranma, om.turyx

[-- Attachment #1: Type: text/plain, Size: 4013 bytes --]

[adding some people in CC that expressed interest in the problem before]

Le samedi 31 mars 2007 à 12:37 +0200, Krzysztof Halasa a écrit :
> Nicolas Mailhot <nicolas.mailhot@laposte.net> writes:
> 
> > Oh, is looks so close to my system
> >
> > 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
> > 00: de 10 50 00 0f 00 a0 00 a3 00 01 06 00 00 80 00
> > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 11 0c
> > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 40: 58 14 11 0c 00 f0 ff fe fa 3e ff 00 fa 3e ff 00
> >                 ^^^^^^^^^^^
> >                 Usual HPET base address
> > 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff
> > 60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 f9 ff
> > 70: 10 00 ff ff c1 00 00 00 00 00 04 19 18 d2 80 0d
> >                 ^^
> >                 c1 => HPET disabled (according to your reference)
> >
> > I don't have an HPET toggle in my bios
> 
> For reference: HPET enabled in BIOS, MSI K9N platinum board:
> 
> dmesg | grep HPET
> ACPI: HPET (v001 A M I  OEMHPET0 0x02000701 MSFT 0x00000097)
> 	@ 0x000000003ffd5480
> ACPI: HPET id: 0x10de8201 base: 0xfed00000
> time.c: Using 25.000000 MHz WALL HPET GTOD HPET timer.
> 
> 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)
>         Subsystem: Micro-Star International Co., Ltd. Unknown device 7250
>         Flags: bus master, 66MHz, fast devsel, latency 0
>         I/O ports at 2f00 [size=128]
> 00: de 10 62 03 0f 00 a0 00 a2 00 01 06 00 00 80 00
> 10: 01 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 50 72
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
> 40: 62 14 50 72 00 00 d0 fe fa 3e ff 00 fa 3e ff 00
>                 ^^^^^^^^^^^
> Dword at 0x44 indeed seems to be the address
> 
> 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 fe 3f
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 ff
> 70: 10 00 ff ff c5 80 00 00 00 00 45 19 00 c6 40 00
>                 ^^
> Enabled = consistent with http://lkml.org/lkml/2006/12/17/69
> 
> 80: 09 20 00 10 1d 08 00 00 f0 00 00 01 f0 00 00 00
> 90: 00 08 00 00 00 00 00 00 21 47 95 86 ef cd ab 00
> a0: 01 00 00 81 00 00 00 00 00 00 00 00 00 00 00 00
>              ^^
> Not sure about 0xa3, though.
> 
> b0: 00 00 00 00 00 0a 7f 0a 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 44 00 00 fe fd d3 00 a0
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00

Here is the full reference on my system

00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
        Subsystem: Giga-byte Technology GA-K8N Ultra-9 Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
00: de 10 50 00 0f 00 a0 00 a3 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 11 0c
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 58 14 11 0c 00 f0 ff fe fa 3e ff 00 fa 3e ff 00
50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff
60: 01 10 00 00 01 14 00 00 01 18 00 00 00 00 f9 ff
70: 10 00 ff ff c1 00 00 00 00 00 04 19 18 d2 80 0d
80: 09 20 00 d8 01 01 00 00 c0 00 00 01 00 00 00 00
90: 00 00 00 00 00 00 00 00 21 64 87 a9 de bc 00 00
a0: 03 00 30 c1 00 00 00 00 00 00 00 00 00 00 00 00
b0: 95 02 f4 02 00 08 5f 08 00 00 00 00 00 00 00 00
c0: 35 82 80 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 14 10 01 00 00 00 d0 00 80 30 00 20 61 44 44 11
f0: 5a ff 5f bf 00 00 00 c0 10 ff ff ff 00 00 30 07

I'm crazy enough to test a patch if someone cooks it, but I'm way out of
my depth there :)

-- 
Nicolas Mailhot

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
  2007-03-31 11:36     ` Nicolas Mailhot
@ 2007-03-31 15:00       ` Mikko Tiihonen
  0 siblings, 0 replies; 12+ messages in thread
From: Mikko Tiihonen @ 2007-03-31 15:00 UTC (permalink / raw)
  To: Nicolas Mailhot; +Cc: Krzysztof Halasa, linux-kernel, ranma, om.turyx



On Sat, 31 Mar 2007, Nicolas Mailhot wrote:

> [adding some people in CC that expressed interest in the problem before]
>
> I'm crazy enough to test a patch if someone cooks it, but I'm way out of
> my depth there :)

After struggling with totally broken kernels for the whole morning I got the 
HPET to work with my NForce4 with the following hard coded ACPI quirk. My 
machine has been now stable for few hours and I tested that the HPET really 
seems to be working by switching the clock source using

echo hpet|tsc|acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource

Results of a simple benchmark show that the time to execute gettimeofday 
really varies based on the clock source: (performance normalised to tsc)
tsc:      1x
hpet:     4x
acpi_pm: 12x

At least on my motherboard it seems to be enough to just grab the HPET address 
from the lspci output and not bother with any of the other changing bits.

--- linux-2.6.21-rc5-git5/arch/i386/kernel/acpi/boot.c	2007-03-31 17:49:24.000000000 +0300
+++ linux-2.6.21-rc5-git5.hpet/arch/i386/kernel/acpi/boot.c	2007-03-31 17:02:27.000000000 +0300
@@ -1189,6 +1189,8 @@ int __init acpi_boot_table_init(void)

  int __init acpi_boot_init(void)
  {
+        struct acpi_table_hpet hpet_tbl;
+
  	/*
  	 * If acpi_disabled, bail out
  	 * One exception: acpi=ht continues far enough to enumerate LAPICs
@@ -1208,7 +1210,12 @@ int __init acpi_boot_init(void)
  	 */
  	acpi_process_madt();

-	acpi_table_parse(ACPI_SIG_HPET, acpi_parse_hpet);
+	hpet_tbl.address.address = 0xfefff000L;
+	hpet_tbl.address.space_id = ACPI_SPACE_MEM;
+	hpet_tbl.sequence = 0;
+	hpet_tbl.id = 0xbabe;
+        acpi_parse_hpet((struct acpi_table_header *) &hpet_tbl);
+	//	acpi_table_parse(ACPI_SIG_HPET, acpi_parse_hpet);

  	return 0;
  }

-Mikko

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
  2007-03-30 16:59 ` Venki Pallipadi
@ 2007-03-30 17:22   ` Nicolas Mailhot
  0 siblings, 0 replies; 12+ messages in thread
From: Nicolas Mailhot @ 2007-03-30 17:22 UTC (permalink / raw)
  To: Venki Pallipadi; +Cc: linux-kernel

Le vendredi 30 mars 2007 à 09:59 -0700, Venki Pallipadi a écrit :
> On Fri, Mar 30, 2007 at 06:50:19PM +0200, Nicolas Mailhot wrote:
> > Anyone got the same thing for CK804? I had my hopes high, and then I saw
> > the DECLARE_PCI_FIXUP_HEADER values [and the thread title was
> > misleading]
> > 
> 
> Sorry about the wrong subject. It should have had ICH in the subject somewhere.

I think I'll recover :)

> On the brighter side, if you find the chipset document for your chipset,
> It should be as easy as this patch to force enable it :-).

It's only at the rainbow end, right?

-- 
Nicolas Mailhot

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
  2007-03-30 16:50 Nicolas Mailhot
@ 2007-03-30 16:59 ` Venki Pallipadi
  2007-03-30 17:22   ` Nicolas Mailhot
  0 siblings, 1 reply; 12+ messages in thread
From: Venki Pallipadi @ 2007-03-30 16:59 UTC (permalink / raw)
  To: Nicolas Mailhot; +Cc: Venkatesh Pallipadi, linux-kernel

On Fri, Mar 30, 2007 at 06:50:19PM +0200, Nicolas Mailhot wrote:
> Anyone got the same thing for CK804? I had my hopes high, and then I saw
> the DECLARE_PCI_FIXUP_HEADER values [and the thread title was
> misleading]
> 

Sorry about the wrong subject. It should have had ICH in the subject somewhere.
On the brighter side, if you find the chipset document for your chipset,
It should be as easy as this patch to force enable it :-).

Thanks,
Venki

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [PATCH 1/5] RT kernel: force detect HPET from PCI space
@ 2007-03-30 16:50 Nicolas Mailhot
  2007-03-30 16:59 ` Venki Pallipadi
  0 siblings, 1 reply; 12+ messages in thread
From: Nicolas Mailhot @ 2007-03-30 16:50 UTC (permalink / raw)
  To: Venkatesh Pallipadi; +Cc: linux-kernel

Anyone got the same thing for CK804? I had my hopes high, and then I saw
the DECLARE_PCI_FIXUP_HEADER values [and the thread title was
misleading]

-- 
Nicolas Mailhot

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [PATCH 1/5] RT kernel: force detect HPET from PCI space
  2007-03-30  9:46 ` Ingo Molnar
@ 2007-03-30 13:36   ` Pallipadi, Venkatesh
  0 siblings, 0 replies; 12+ messages in thread
From: Pallipadi, Venkatesh @ 2007-03-30 13:36 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, Thomas Gleixner

 

>-----Original Message-----
>From: Ingo Molnar [mailto:mingo@redhat.com] 
>Sent: Friday, March 30, 2007 2:47 AM
>To: Pallipadi, Venkatesh
>Cc: linux-kernel; Thomas Gleixner
>Subject: Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
>
>On Thu, 2007-02-22 at 17:06 -0800, Venkatesh Pallipadi wrote:
>> Patchset enables force detection of HPET, when it is not listed by
>> BIOS.
>> and enables use of HPET as a event source. HPET timers
>> configures in stamdard interrupt mode can be used as dependable per
>> CPU timer
>> on laptops that are known to have LAPIC stoppage with ACPI C3 state.
>
>(sorry about the belated reply)
>
>cool patchset! I suspect the most logical place to start this would be
>on upstream 32-bit, which has the hpet clockevents changes already.
>Plus the i386 and x86_64 hpet code should be unified.
>

Yes. I restarted the work recently with i386 and upstream. I should
have the some patches in couple of weeks time.

Thanks,
Venki

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
  2007-02-23  1:06 Venkatesh Pallipadi
@ 2007-03-30  9:46 ` Ingo Molnar
  2007-03-30 13:36   ` Pallipadi, Venkatesh
  0 siblings, 1 reply; 12+ messages in thread
From: Ingo Molnar @ 2007-03-30  9:46 UTC (permalink / raw)
  To: Venkatesh Pallipadi; +Cc: linux-kernel, Thomas Gleixner

On Thu, 2007-02-22 at 17:06 -0800, Venkatesh Pallipadi wrote:
> Patchset enables force detection of HPET, when it is not listed by
> BIOS.
> and enables use of HPET as a event source. HPET timers
> configures in stamdard interrupt mode can be used as dependable per
> CPU timer
> on laptops that are known to have LAPIC stoppage with ACPI C3 state.

(sorry about the belated reply)

cool patchset! I suspect the most logical place to start this would be
on upstream 32-bit, which has the hpet clockevents changes already.
Plus the i386 and x86_64 hpet code should be unified.

	Ingo


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH 1/5] RT kernel: force detect HPET from PCI space
@ 2007-02-23  1:06 Venkatesh Pallipadi
  2007-03-30  9:46 ` Ingo Molnar
  0 siblings, 1 reply; 12+ messages in thread
From: Venkatesh Pallipadi @ 2007-02-23  1:06 UTC (permalink / raw)
  To: linux-kernel, Thomas Gleixner, Ingo Molnar



Patchset enables force detection of HPET, when it is not listed by BIOS.
and enables use of HPET as a event source. HPET timers
configures in stamdard interrupt mode can be used as dependable per CPU timer
on laptops that are known to have LAPIC stoppage with ACPI C3 state.

Patch is against rt kernel (2.6.20-rt8) and patch enables only x86-64
right now.

This patch:

Detect HPET by looking at PCI space, even when BIOS does not list HPET
device. This is useful to use HPET as dependable per CPU timer with tickless
kernels.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

Index: linux-2.6.21-rc-mm/arch/i386/kernel/quirks.c
===================================================================
--- linux-2.6.21-rc-mm.orig/arch/i386/kernel/quirks.c
+++ linux-2.6.21-rc-mm/arch/i386/kernel/quirks.c
@@ -48,3 +48,58 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_E7525_MCH,	quirk_intel_irqbalance);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_E7520_MCH,	quirk_intel_irqbalance);
 #endif
+
+#if defined(CONFIG_HPET_TIMER)
+unsigned long force_hpet_address;
+
+static void __init force_enable_hpet(struct pci_dev *dev)
+{
+	u32 val, rcba;
+	void __iomem *base;
+
+	if (hpet_address)
+		return;
+
+	pci_read_config_dword(dev, 0xF0, &rcba);
+	rcba &= 0xFFFFC000;
+	if (rcba == 0) {
+		printk(KERN_DEBUG "RCBA disabled. Cannot force enable HPET\n");
+		return;
+	}
+
+	/* use bits 31:14, 16 kB aligned */
+	base = ioremap_nocache(rcba, 0x4000);
+	if (base == NULL) {
+		printk(KERN_DEBUG "ioremap failed. Cannot force enable HPET\n");
+		return;
+	}
+
+	/* read the Function Disable register, dword mode only */
+	val = readl(base + 0x3404);
+
+	if (!(val & 0x80)) {
+		/* HPET disabled in HPTC. Trying to enable */
+		writel(val | 0x80, base + 0x3404);
+	}
+
+	val = readl(base + 0x3404);
+
+	if (!(val & 0x80)) {
+		printk(KERN_DEBUG "Failed to force enable HPET\n");
+	} else {
+		val = val & 0x3;
+		force_hpet_address = 0xFED00000 | (val << 12);
+		printk(KERN_DEBUG "Force enabled HPET. Base address 0x%x\n",
+			       force_hpet_address);
+	}
+
+	iounmap(base);
+}
+
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ESB2_0,     force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH6_1,     force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_1,     force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_31,     force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH8_1,     force_enable_hpet);
+#endif
+
Index: linux-2.6.21-rc-mm/include/asm-i386/hpet.h
===================================================================
--- linux-2.6.21-rc-mm.orig/include/asm-i386/hpet.h
+++ linux-2.6.21-rc-mm/include/asm-i386/hpet.h
@@ -91,6 +91,7 @@
 #define HPET_TICK_RATE  (HZ * 100000UL)
 
 extern unsigned long hpet_address;	/* hpet memory map physical address */
+extern unsigned long force_hpet_address;/* hpet memory detected by quirk */
 extern int is_hpet_enabled(void);
 
 #ifdef CONFIG_X86_64
Index: linux-2.6.21-rc-mm/include/asm-x86_64/hpet.h
===================================================================
--- linux-2.6.21-rc-mm.orig/include/asm-x86_64/hpet.h
+++ linux-2.6.21-rc-mm/include/asm-x86_64/hpet.h
@@ -63,6 +63,7 @@ extern unsigned int hpet_calibrate_tsc(v
 
 extern int hpet_use_timer;
 extern unsigned long hpet_address;
+extern unsigned long force_hpet_address;
 extern unsigned long hpet_period;
 extern unsigned long hpet_tick;
 

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2007-03-31 15:01 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-30 22:09 [PATCH 1/5] RT kernel: force detect HPET from PCI space Mikko Tiihonen
2007-03-30 22:38 ` Nicolas Mailhot
2007-03-31  8:00   ` Mikko Tiihonen
2007-03-31 10:37   ` Krzysztof Halasa
2007-03-31 11:36     ` Nicolas Mailhot
2007-03-31 15:00       ` Mikko Tiihonen
  -- strict thread matches above, loose matches on Subject: below --
2007-03-30 16:50 Nicolas Mailhot
2007-03-30 16:59 ` Venki Pallipadi
2007-03-30 17:22   ` Nicolas Mailhot
2007-02-23  1:06 Venkatesh Pallipadi
2007-03-30  9:46 ` Ingo Molnar
2007-03-30 13:36   ` Pallipadi, Venkatesh

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