Skip to contentSkip to conversation

RT kernel: force detect HPET from PCI space

PATCH Andrew Morton 2 participants 2 messages Mar 31, 2007 – Apr 1, 2007 ACPI

lore
Share & tools
lore

Andrew Morton

author
#0 lore raw

I assume this is an acpi table bug.

Is there any way in which we can get a workaround in place to fix this for real?

Begin forwarded message:

Date: Sat, 31 Mar 2007 18:00:34 +0300 (EEST)
From: Mikko Tiihonen <[email protected]>
To: Nicolas Mailhot <[email protected]>
Cc: Krzysztof Halasa <[email protected]>, [email protected], [email protected], [email protected]
Subject: Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space

Quoted 4 lines · Nicolas Mailhot

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

arch/i386/kernel/acpi/boot.c +8 -1
@@ -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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#1 lore raw
Quoted 2 lines · Andrew Morton

I assume this is an acpi table bug.

Yes. BIOS seems to initialise the HPET correctly (or then the HW needs no setup) but just forgets to add the entry to acpi table.

So far I have received report that my hack works on CK804 ISA Bridge 10de:0050
MCP55 LPC Bridge (pci id most likely one of 10de:0360 - 10de:0367)

It seems that for most (all?) nvidia chipsets the hpet address can be read with pci_read_config_dword(dev, 0x44, &addr) from the correct device.

Quoted 1 line

Is there any way in which we can get a workaround in place to fix this for real?

I have been thinking of a way for early quirks that could add fake acpi table entries. The acpi_table_parse function could then be modified to scan also the fake entries, which would just already contain the acpi structs.

Another way is to do as Venkatesh did for intel chipsets. Add a early quirk that exports force_hpet_address and teach hpet driver to try it too. I do not think this will not work properly however, unless the reserving of the hpet iomem resource is moved from i386/kernel/acpi/boot.c to the hpet driver.

Quoted 67 lines

Begin forwarded message:

Date: Sat, 31 Mar 2007 18:00:34 +0300 (EEST)
From: Mikko Tiihonen <[email protected]>
To: Nicolas Mailhot <[email protected]>
Cc: Krzysztof Halasa <[email protected]>, [email protected], [email protected], [email protected]
Subject: Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space

Quoted 4 lines · Nicolas Mailhot

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

arch/i386/kernel/acpi/boot.c +8 -3
@@ -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
-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/