x86/HPET: don't disable interrupt delivery right after setting it up

We shouldn't clear HPET_TN_FSB right after we (indirectly, via
request_irq()) enabled it for the channels we intend to use for
broadcasts.

This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
This fixes the MWAIT idle driver problem on the box that I was able to
(artificially) reproduce it with. Hence I subsequently intend to revert
25960:6bf8b882df8f, but I'm not intending to do this before getting a
push there.

I'm surprised that this didn't hit anyone so far with the ACPI-based
idle driver...

--- 2012-09-21.orig/xen/arch/x86/hpet.c	2012-09-27 16:10:35.000000000 +0200
+++ 2012-09-21/xen/arch/x86/hpet.c	2012-09-27 16:10:07.000000000 +0200
@@ -533,7 +533,7 @@ void __init hpet_broadcast_init(void)
     {
         /* set HPET Tn as oneshot */
         cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
-        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
+        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
         cfg |= HPET_TN_ENABLE | HPET_TN_32BIT;
         hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
 
@@ -590,7 +590,7 @@ void hpet_broadcast_resume(void)
 
         /* set HPET Tn as oneshot */
         cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
-        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
+        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
         cfg |= HPET_TN_ENABLE | HPET_TN_32BIT;
         hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));