public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
@ 2010-07-14 15:55 Stephan Wolf
  2010-07-14 16:13 ` Linus Torvalds
  0 siblings, 1 reply; 13+ messages in thread
From: Stephan Wolf @ 2010-07-14 15:55 UTC (permalink / raw)
  To: linux-kernel; +Cc: torvalds, tglx

  After commit 30a564be9d9554c168a654eddc2165869cc0d7bf 
"x86, hpet: Restrict read back to affected ATI chipsets" hpet did not 
work anymore on HP nx6325. The machine hangs on booting until a 
keystroke was taken. After a short time machine hangs again until next 
keystroke. Applying the following patch solves the issue for me.

diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index e72d3fc..8d28924 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -408,6 +408,7 @@ static void ati_force_enable_hpet(struct pci_dev *dev)
      dev_printk(KERN_DEBUG, &dev->dev, "Force enabled HPET at 0x%lx\n",
             force_hpet_address);
      cached_dev = dev;
+    hpet_readback_cmp = 1;
  }
  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, 
PCI_DEVICE_ID_ATI_IXP400_SMBUS,
               ati_force_enable_hpet);

Signed-off-by: Stephan Wolf <stephan@letzte-bankreihe.de>

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

* Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel  2.6.35_rc5
  2010-07-14 15:55 [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5 Stephan Wolf
@ 2010-07-14 16:13 ` Linus Torvalds
  2010-07-14 16:40   ` Stephan Wolf
                     ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Linus Torvalds @ 2010-07-14 16:13 UTC (permalink / raw)
  To: Stephan Wolf; +Cc: linux-kernel, tglx, Andreas Herrmann

On Wed, Jul 14, 2010 at 8:55 AM, Stephan Wolf
<stephan@letzte-bankreihe.de> wrote:
>
>  After commit 30a564be9d9554c168a654eddc2165869cc0d7bf "x86, hpet: Restrict
> read back to affected ATI chipsets" hpet did not work anymore on HP nx6325.
> The machine hangs on booting until a keystroke was taken. After a short time
> machine hangs again until next keystroke. Applying the following patch
> solves the issue for me.

Ok, this makes sense. Bugs in the ATI chipset is why
'hpet_readback_cmp' exists in the first place. HOWEVER, clearly that
commit changed it to be about too few ATI chipsets.

So right now, for

 - PCI_DEVICE_ID_ATI_SBX00_SMBUS:
     force disable HPET MSI
     force HPET readback

 - PCI_DEVICE_ID_ATI_IXP400_SMBU
     force-enable HPET
     ...and than your patch makes it force HPET readback

but that doesn't actually make much sense in the bigger picture,
because there are other ATI chipsets that are related and presumably
also affected. What about IXP[23]00_SMBUS? And what about the IXP7
series (SBX00 is IXP6, afaik)?

So I get the feeling that this is incomplete, or at least needs
thinking about those other ATI chipsets too.

Thomas? And I added Andreas to the cc, maybe he knows what's up.

                        Linus

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

* Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
  2010-07-14 16:13 ` Linus Torvalds
@ 2010-07-14 16:40   ` Stephan Wolf
  2010-07-14 18:11   ` Borislav Petkov
  2010-07-14 19:30   ` Thomas Gleixner
  2 siblings, 0 replies; 13+ messages in thread
From: Stephan Wolf @ 2010-07-14 16:40 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, tglx, Andreas Herrmann

  Am 14.07.2010 18:13, schrieb Linus Torvalds:
> On Wed, Jul 14, 2010 at 8:55 AM, Stephan Wolf
> <stephan@letzte-bankreihe.de>  wrote:
>>   After commit 30a564be9d9554c168a654eddc2165869cc0d7bf "x86, hpet: Restrict
>> read back to affected ATI chipsets" hpet did not work anymore on HP nx6325.
>> The machine hangs on booting until a keystroke was taken. After a short time
>> machine hangs again until next keystroke. Applying the following patch
>> solves the issue for me.
> Ok, this makes sense. Bugs in the ATI chipset is why
> 'hpet_readback_cmp' exists in the first place. HOWEVER, clearly that
> commit changed it to be about too few ATI chipsets.
>
> So right now, for
>
>   - PCI_DEVICE_ID_ATI_SBX00_SMBUS:
>       force disable HPET MSI
>       force HPET readback
>
>   - PCI_DEVICE_ID_ATI_IXP400_SMBU
>       force-enable HPET
>       ...and than your patch makes it force HPET readback
>
> but that doesn't actually make much sense in the bigger picture,
> because there are other ATI chipsets that are related and presumably
> also affected. What about IXP[23]00_SMBUS? And what about the IXP7
> series (SBX00 is IXP6, afaik)?
>
> So I get the feeling that this is incomplete, or at least needs
> thinking about those other ATI chipsets too.
>
> Thomas? And I added Andreas to the cc, maybe he knows what's up.
>
>                          Linus
>
Ok, I did not consider that msi is disabled at all on IXP400. Isn't it? 
Maybe that the reason why it is works for me.

Stephan

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

* Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
  2010-07-14 16:13 ` Linus Torvalds
  2010-07-14 16:40   ` Stephan Wolf
@ 2010-07-14 18:11   ` Borislav Petkov
  2010-07-14 18:17     ` Linus Torvalds
  2010-07-14 19:30   ` Thomas Gleixner
  2 siblings, 1 reply; 13+ messages in thread
From: Borislav Petkov @ 2010-07-14 18:11 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Stephan Wolf, linux-kernel, tglx, Andreas Herrmann

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, Jul 14, 2010 at 09:13:39AM -0700

> On Wed, Jul 14, 2010 at 8:55 AM, Stephan Wolf
> <stephan@letzte-bankreihe.de> wrote:
> >
> >  After commit 30a564be9d9554c168a654eddc2165869cc0d7bf "x86, hpet: Restrict
> > read back to affected ATI chipsets" hpet did not work anymore on HP nx6325.
> > The machine hangs on booting until a keystroke was taken. After a short time
> > machine hangs again until next keystroke. Applying the following patch
> > solves the issue for me.
> 
> Ok, this makes sense. Bugs in the ATI chipset is why
> 'hpet_readback_cmp' exists in the first place. HOWEVER, clearly that
> commit changed it to be about too few ATI chipsets.
> 
> So right now, for
> 
>  - PCI_DEVICE_ID_ATI_SBX00_SMBUS:
>      force disable HPET MSI
>      force HPET readback
> 
>  - PCI_DEVICE_ID_ATI_IXP400_SMBU
>      force-enable HPET
>      ...and than your patch makes it force HPET readback
> 
> but that doesn't actually make much sense in the bigger picture,
> because there are other ATI chipsets that are related and presumably
> also affected. What about IXP[23]00_SMBUS? And what about the IXP7
> series (SBX00 is IXP6, afaik)?

Right, so the original commit introducing the readback did it for all
ATI chipsets: 72d43d9bc9210d24d09202eaf219eac09e17b339. We've been
running fine with it so far modulo the Intel ICH9 issue.

I'll try to find out which chipsets are actually affected but in the
meantime we might want to do a temporary fix by enabling the readback
back(!) on all ATI chipsets so that we don't uncover anymore bugs like
the one above, hmmm?

> And I added Andreas to the cc, maybe he knows what's up.

He'll be back on Mo.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


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

* Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel  2.6.35_rc5
  2010-07-14 18:11   ` Borislav Petkov
@ 2010-07-14 18:17     ` Linus Torvalds
  2010-07-14 18:32       ` Borislav Petkov
  2010-07-14 19:32       ` [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5 Thomas Gleixner
  0 siblings, 2 replies; 13+ messages in thread
From: Linus Torvalds @ 2010-07-14 18:17 UTC (permalink / raw)
  To: Borislav Petkov; +Cc: Stephan Wolf, linux-kernel, tglx, Andreas Herrmann

On Wed, Jul 14, 2010 at 11:11 AM, Borislav Petkov
<borislav.petkov@amd.com> wrote:
>
> I'll try to find out which chipsets are actually affected but in the
> meantime we might want to do a temporary fix by enabling the readback
> back(!) on all ATI chipsets so that we don't uncover anymore bugs like
> the one above, hmmm?

That sounds like the right solution for now, yes.  Rather than make
the readback quirk depend on one particular SMBUS revision, make it
happen unconditionally for an AMD northbridge (or is the HPET in the
SB? I forget - somebody who knows the details and can test it on a
machine or two should do the actual patch).

Thomas?

                Linus

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

* Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
  2010-07-14 18:17     ` Linus Torvalds
@ 2010-07-14 18:32       ` Borislav Petkov
  2010-07-14 21:04         ` Thomas Gleixner
  2010-07-14 19:32       ` [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5 Thomas Gleixner
  1 sibling, 1 reply; 13+ messages in thread
From: Borislav Petkov @ 2010-07-14 18:32 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Stephan Wolf, linux-kernel@vger.kernel.org, tglx@linutronix.de,
	Herrmann3, Andreas

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, Jul 14, 2010 at 02:17:27PM -0400

> > I'll try to find out which chipsets are actually affected but in the
> > meantime we might want to do a temporary fix by enabling the readback
> > back(!) on all ATI chipsets so that we don't uncover anymore bugs like
> > the one above, hmmm?
> 
> That sounds like the right solution for now, yes.  Rather than make
> the readback quirk depend on one particular SMBUS revision, make it
> happen unconditionally for an AMD northbridge (or is the HPET in the
> SB?

Yeah, its in the southbridge which is part of the chipset. Actually
we'll have to somehow match ATI chipsets only since we have also nVidia
chipsets with AMD cpus in them.

/me goes to meditate a little about it.

> I forget - somebody who knows the details and can test it on a
> machine or two should do the actual patch).

I'll try to cook up something unless someone beats me to it.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


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

* Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
  2010-07-14 16:13 ` Linus Torvalds
  2010-07-14 16:40   ` Stephan Wolf
  2010-07-14 18:11   ` Borislav Petkov
@ 2010-07-14 19:30   ` Thomas Gleixner
  2 siblings, 0 replies; 13+ messages in thread
From: Thomas Gleixner @ 2010-07-14 19:30 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Stephan Wolf, linux-kernel, Andreas Herrmann

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1493 bytes --]

On Wed, 14 Jul 2010, Linus Torvalds wrote:

> On Wed, Jul 14, 2010 at 8:55 AM, Stephan Wolf
> <stephan@letzte-bankreihe.de> wrote:
> >
> >  After commit 30a564be9d9554c168a654eddc2165869cc0d7bf "x86, hpet: Restrict
> > read back to affected ATI chipsets" hpet did not work anymore on HP nx6325.
> > The machine hangs on booting until a keystroke was taken. After a short time
> > machine hangs again until next keystroke. Applying the following patch
> > solves the issue for me.
> 
> Ok, this makes sense. Bugs in the ATI chipset is why
> 'hpet_readback_cmp' exists in the first place. HOWEVER, clearly that
> commit changed it to be about too few ATI chipsets.
> 
> So right now, for
> 
>  - PCI_DEVICE_ID_ATI_SBX00_SMBUS:
>      force disable HPET MSI
>      force HPET readback
> 
>  - PCI_DEVICE_ID_ATI_IXP400_SMBU
>      force-enable HPET
>      ...and than your patch makes it force HPET readback
> 
> but that doesn't actually make much sense in the bigger picture,
> because there are other ATI chipsets that are related and presumably
> also affected. What about IXP[23]00_SMBUS? And what about the IXP7
> series (SBX00 is IXP6, afaik)?
> 
> So I get the feeling that this is incomplete, or at least needs
> thinking about those other ATI chipsets too.
> 
> Thomas? And I added Andreas to the cc, maybe he knows what's up.

Hmpf. The only report I ever got was against SBX00 and I can reproduce
on my own machine. My IXP400_SMBUS box works fine without the
readback.

/me is confused

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

* Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
  2010-07-14 18:17     ` Linus Torvalds
  2010-07-14 18:32       ` Borislav Petkov
@ 2010-07-14 19:32       ` Thomas Gleixner
  1 sibling, 0 replies; 13+ messages in thread
From: Thomas Gleixner @ 2010-07-14 19:32 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Borislav Petkov, Stephan Wolf, linux-kernel, Andreas Herrmann

On Wed, 14 Jul 2010, Linus Torvalds wrote:

> On Wed, Jul 14, 2010 at 11:11 AM, Borislav Petkov
> <borislav.petkov@amd.com> wrote:
> >
> > I'll try to find out which chipsets are actually affected but in the
> > meantime we might want to do a temporary fix by enabling the readback
> > back(!) on all ATI chipsets so that we don't uncover anymore bugs like
> > the one above, hmmm?
> 
> That sounds like the right solution for now, yes.  Rather than make

Ack.

> the readback quirk depend on one particular SMBUS revision, make it
> happen unconditionally for an AMD northbridge (or is the HPET in the
> SB? I forget - somebody who knows the details and can test it on a
> machine or two should do the actual patch).

It's in the SB. Need to figure out how to cover all ATI chipsets and
not blindly imposing this on any other chipset which is used with AMD
cpus.

Thanks,

	tglx

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

* Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
  2010-07-14 18:32       ` Borislav Petkov
@ 2010-07-14 21:04         ` Thomas Gleixner
  2010-07-15  7:06           ` Stephan Wolf
  2010-07-15 15:12           ` [tip:x86/urgent] x86: Force HPET readback_cmp for all ATI chipsets tip-bot for Thomas Gleixner
  0 siblings, 2 replies; 13+ messages in thread
From: Thomas Gleixner @ 2010-07-14 21:04 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Linus Torvalds, Stephan Wolf, linux-kernel@vger.kernel.org,
	Herrmann3, Andreas

On Wed, 14 Jul 2010, Borislav Petkov wrote:

> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Wed, Jul 14, 2010 at 02:17:27PM -0400
> 
> > > I'll try to find out which chipsets are actually affected but in the
> > > meantime we might want to do a temporary fix by enabling the readback
> > > back(!) on all ATI chipsets so that we don't uncover anymore bugs like
> > > the one above, hmmm?
> > 
> > That sounds like the right solution for now, yes.  Rather than make
> > the readback quirk depend on one particular SMBUS revision, make it
> > happen unconditionally for an AMD northbridge (or is the HPET in the
> > SB?
> 
> Yeah, its in the southbridge which is part of the chipset. Actually
> we'll have to somehow match ATI chipsets only since we have also nVidia
> chipsets with AMD cpus in them.
> 
> /me goes to meditate a little about it.
> 
> > I forget - somebody who knows the details and can test it on a
> > machine or two should do the actual patch).
> 
> I'll try to cook up something unless someone beats me to it.

The patch below works on my collection of ATI chipset based machines.

Stefan, does it solve your problem too ?

Thanks,

	tglx
-----

Subject: x86-ati-chipsets-hpet-force-readback.patch
From: Thomas Gleixner <tglx@linutronix.de>
Date: Wed, 14 Jul 2010 21:36:27 +0200

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Index: linux-2.6/arch/x86/kernel/early-quirks.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/early-quirks.c
+++ linux-2.6/arch/x86/kernel/early-quirks.c
@@ -18,6 +18,7 @@
 #include <asm/apic.h>
 #include <asm/iommu.h>
 #include <asm/gart.h>
+#include <asm/hpet.h>
 
 static void __init fix_hypertransport_config(int num, int slot, int func)
 {
@@ -191,6 +192,21 @@ static void __init ati_bugs_contd(int nu
 }
 #endif
 
+/*
+ * Force the read back of the CMP register in hpet_next_event()
+ * to work around the problem that the CMP register write seems to be
+ * delayed. See hpet_next_event() for details.
+ *
+ * We do this on all SMBUS incarnations for now until we have more
+ * information about the affected chipsets.
+ */
+static void __init ati_hpet_bugs(int num, int slot, int func)
+{
+#ifdef CONFIG_HPET_TIMER
+	hpet_readback_cmp = 1;
+#endif
+}
+
 #define QFLAG_APPLY_ONCE 	0x1
 #define QFLAG_APPLIED		0x2
 #define QFLAG_DONE		(QFLAG_APPLY_ONCE|QFLAG_APPLIED)
@@ -220,6 +236,8 @@ static struct chipset early_qrk[] __init
 	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs },
 	{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,
 	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs_contd },
+	{ PCI_VENDOR_ID_ATI, PCI_ANY_ID,
+	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_hpet_bugs },
 	{}
 };
 
Index: linux-2.6/arch/x86/kernel/quirks.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/quirks.c
+++ linux-2.6/arch/x86/kernel/quirks.c
@@ -498,15 +498,10 @@ void force_hpet_resume(void)
  * See erratum #27 (Misinterpreted MSI Requests May Result in
  * Corrupted LPC DMA Data) in AMD Publication #46837,
  * "SB700 Family Product Errata", Rev. 1.0, March 2010.
- *
- * Also force the read back of the CMP register in hpet_next_event()
- * to work around the problem that the CMP register write seems to be
- * delayed. See hpet_next_event() for details.
  */
 static void force_disable_hpet_msi(struct pci_dev *unused)
 {
 	hpet_msi_disable = 1;
-	hpet_readback_cmp = 1;
 }
 
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,

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

* Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
  2010-07-14 21:04         ` Thomas Gleixner
@ 2010-07-15  7:06           ` Stephan Wolf
  2010-07-15  8:22             ` Thomas Gleixner
  2010-07-15 15:12           ` [tip:x86/urgent] x86: Force HPET readback_cmp for all ATI chipsets tip-bot for Thomas Gleixner
  1 sibling, 1 reply; 13+ messages in thread
From: Stephan Wolf @ 2010-07-15  7:06 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Borislav Petkov, Linus Torvalds, linux-kernel@vger.kernel.org,
	Herrmann3, Andreas

Am 14.07.2010 23:04, schrieb Thomas Gleixner:
> On Wed, 14 Jul 2010, Borislav Petkov wrote:
>
>    
>> From: Linus Torvalds<torvalds@linux-foundation.org>
>> Date: Wed, Jul 14, 2010 at 02:17:27PM -0400
>>
>>      
>>>> I'll try to find out which chipsets are actually affected but in the
>>>> meantime we might want to do a temporary fix by enabling the readback
>>>> back(!) on all ATI chipsets so that we don't uncover anymore bugs like
>>>> the one above, hmmm?
>>>>          
>>> That sounds like the right solution for now, yes.  Rather than make
>>> the readback quirk depend on one particular SMBUS revision, make it
>>> happen unconditionally for an AMD northbridge (or is the HPET in the
>>> SB?
>>>        
>> Yeah, its in the southbridge which is part of the chipset. Actually
>> we'll have to somehow match ATI chipsets only since we have also nVidia
>> chipsets with AMD cpus in them.
>>
>> /me goes to meditate a little about it.
>>
>>      
>>> I forget - somebody who knows the details and can test it on a
>>> machine or two should do the actual patch).
>>>        
>> I'll try to cook up something unless someone beats me to it.
>>      
> The patch below works on my collection of ATI chipset based machines.
>
> Stefan, does it solve your problem too ?
>
> Thanks,
>
> 	tglx
> -----
>
> Subject: x86-ati-chipsets-hpet-force-readback.patch
> From: Thomas Gleixner<tglx@linutronix.de>
> Date: Wed, 14 Jul 2010 21:36:27 +0200
>
> Signed-off-by: Thomas Gleixner<tglx@linutronix.de>
> Index: linux-2.6/arch/x86/kernel/early-quirks.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/early-quirks.c
> +++ linux-2.6/arch/x86/kernel/early-quirks.c
> @@ -18,6 +18,7 @@
>   #include<asm/apic.h>
>   #include<asm/iommu.h>
>   #include<asm/gart.h>
> +#include<asm/hpet.h>
>
>   static void __init fix_hypertransport_config(int num, int slot, int func)
>   {
> @@ -191,6 +192,21 @@ static void __init ati_bugs_contd(int nu
>   }
>   #endif
>
> +/*
> + * Force the read back of the CMP register in hpet_next_event()
> + * to work around the problem that the CMP register write seems to be
> + * delayed. See hpet_next_event() for details.
> + *
> + * We do this on all SMBUS incarnations for now until we have more
> + * information about the affected chipsets.
> + */
> +static void __init ati_hpet_bugs(int num, int slot, int func)
> +{
> +#ifdef CONFIG_HPET_TIMER
> +	hpet_readback_cmp = 1;
> +#endif
> +}
> +
>   #define QFLAG_APPLY_ONCE 	0x1
>   #define QFLAG_APPLIED		0x2
>   #define QFLAG_DONE		(QFLAG_APPLY_ONCE|QFLAG_APPLIED)
> @@ -220,6 +236,8 @@ static struct chipset early_qrk[] __init
>   	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs },
>   	{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,
>   	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs_contd },
> +	{ PCI_VENDOR_ID_ATI, PCI_ANY_ID,
> +	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_hpet_bugs },
>   	{}
>   };
>
> Index: linux-2.6/arch/x86/kernel/quirks.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/quirks.c
> +++ linux-2.6/arch/x86/kernel/quirks.c
> @@ -498,15 +498,10 @@ void force_hpet_resume(void)
>    * See erratum #27 (Misinterpreted MSI Requests May Result in
>    * Corrupted LPC DMA Data) in AMD Publication #46837,
>    * "SB700 Family Product Errata", Rev. 1.0, March 2010.
> - *
> - * Also force the read back of the CMP register in hpet_next_event()
> - * to work around the problem that the CMP register write seems to be
> - * delayed. See hpet_next_event() for details.
>    */
>   static void force_disable_hpet_msi(struct pci_dev *unused)
>   {
>   	hpet_msi_disable = 1;
> -	hpet_readback_cmp = 1;
>   }
>
>   DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,
>    

Hi, the patch above solves the problem on my machine.

Thanks,
Stephan

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

* Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
  2010-07-15  7:06           ` Stephan Wolf
@ 2010-07-15  8:22             ` Thomas Gleixner
  2010-07-15 10:02               ` Borislav Petkov
  0 siblings, 1 reply; 13+ messages in thread
From: Thomas Gleixner @ 2010-07-15  8:22 UTC (permalink / raw)
  To: Stephan Wolf
  Cc: Borislav Petkov, Linus Torvalds, linux-kernel@vger.kernel.org,
	Herrmann3, Andreas

On Thu, 15 Jul 2010, Stephan Wolf wrote:
> Am 14.07.2010 23:04, schrieb Thomas Gleixner:
> 
> > +static void __init ati_hpet_bugs(int num, int slot, int func)
> > +{
> > +#ifdef CONFIG_HPET_TIMER
> > +	hpet_readback_cmp = 1;
> > +#endif
> > +}
> > +
> >   #define QFLAG_APPLY_ONCE 	0x1
> >   #define QFLAG_APPLIED		0x2
> >   #define QFLAG_DONE		(QFLAG_APPLY_ONCE|QFLAG_APPLIED)
> > @@ -220,6 +236,8 @@ static struct chipset early_qrk[] __init
> >   	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs },
> >   	{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,
> >   	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs_contd },
> > +	{ PCI_VENDOR_ID_ATI, PCI_ANY_ID,
> > +	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_hpet_bugs },
> >   	{}
> 
> Hi, the patch above solves the problem on my machine.

Thanks for testing. 

Borislav, any opinion ?

Thanks,

	tglx

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

* Re: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
  2010-07-15  8:22             ` Thomas Gleixner
@ 2010-07-15 10:02               ` Borislav Petkov
  0 siblings, 0 replies; 13+ messages in thread
From: Borislav Petkov @ 2010-07-15 10:02 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Stephan Wolf, Linus Torvalds, linux-kernel@vger.kernel.org,
	Herrmann3, Andreas

From: Thomas Gleixner <tglx@linutronix.de>
Date: Thu, Jul 15, 2010 at 04:22:14AM -0400

> On Thu, 15 Jul 2010, Stephan Wolf wrote:
> > Am 14.07.2010 23:04, schrieb Thomas Gleixner:
> > 
> > > +static void __init ati_hpet_bugs(int num, int slot, int func)
> > > +{
> > > +#ifdef CONFIG_HPET_TIMER
> > > +	hpet_readback_cmp = 1;
> > > +#endif
> > > +}
> > > +
> > >   #define QFLAG_APPLY_ONCE 	0x1
> > >   #define QFLAG_APPLIED		0x2
> > >   #define QFLAG_DONE		(QFLAG_APPLY_ONCE|QFLAG_APPLIED)
> > > @@ -220,6 +236,8 @@ static struct chipset early_qrk[] __init
> > >   	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs },
> > >   	{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,
> > >   	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs_contd },
> > > +	{ PCI_VENDOR_ID_ATI, PCI_ANY_ID,
> > > +	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_hpet_bugs },
> > >   	{}
> > 
> > Hi, the patch above solves the problem on my machine.
> 
> Thanks for testing. 
> 
> Borislav, any opinion ?

Yep, good idea to match SMBus device class on ATI, cool. Quickly tested
on my SB700.

Acked-by: Borislav Petkov <borislav.petkov@amd.com>

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


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

* [tip:x86/urgent] x86: Force HPET readback_cmp for all ATI chipsets
  2010-07-14 21:04         ` Thomas Gleixner
  2010-07-15  7:06           ` Stephan Wolf
@ 2010-07-15 15:12           ` tip-bot for Thomas Gleixner
  1 sibling, 0 replies; 13+ messages in thread
From: tip-bot for Thomas Gleixner @ 2010-07-15 15:12 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: linux-kernel, hpa, mingo, stephan, tglx, borislav.petkov

Commit-ID:  08be97962bf338161325d4901642f956ce8c1adb
Gitweb:     http://git.kernel.org/tip/08be97962bf338161325d4901642f956ce8c1adb
Author:     Thomas Gleixner <tglx@linutronix.de>
AuthorDate: Wed, 14 Jul 2010 21:36:27 +0200
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Thu, 15 Jul 2010 17:10:02 +0200

x86: Force HPET readback_cmp for all ATI chipsets

commit 30a564be (x86, hpet: Restrict read back to affected ATI
chipset) restricted the workaround for the HPET bug to SMX00
chipsets. This was reasonable as those were the only ones against
which we ever got a bug report.

Stephan Wolf reported now that this patch breaks his IXP400 based
machine. Though it's confirmed to work on other IXP400 based systems.

To error out on the safe side, we force the HPET readback workaround
for all ATI SMbus class chipsets.

Reported-by: Stephan Wolf <stephan@letzte-bankreihe.de>
LKML-Reference: <alpine.LFD.2.00.1007142134140.3321@localhost.localdomain>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Stephan Wolf <stephan@letzte-bankreihe.de>
Acked-by: Borislav Petkov <borislav.petkov@amd.com>
---
 arch/x86/kernel/early-quirks.c |   18 ++++++++++++++++++
 arch/x86/kernel/quirks.c       |    5 -----
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index ebdb85c..e5cc7e8 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -18,6 +18,7 @@
 #include <asm/apic.h>
 #include <asm/iommu.h>
 #include <asm/gart.h>
+#include <asm/hpet.h>
 
 static void __init fix_hypertransport_config(int num, int slot, int func)
 {
@@ -191,6 +192,21 @@ static void __init ati_bugs_contd(int num, int slot, int func)
 }
 #endif
 
+/*
+ * Force the read back of the CMP register in hpet_next_event()
+ * to work around the problem that the CMP register write seems to be
+ * delayed. See hpet_next_event() for details.
+ *
+ * We do this on all SMBUS incarnations for now until we have more
+ * information about the affected chipsets.
+ */
+static void __init ati_hpet_bugs(int num, int slot, int func)
+{
+#ifdef CONFIG_HPET_TIMER
+	hpet_readback_cmp = 1;
+#endif
+}
+
 #define QFLAG_APPLY_ONCE 	0x1
 #define QFLAG_APPLIED		0x2
 #define QFLAG_DONE		(QFLAG_APPLY_ONCE|QFLAG_APPLIED)
@@ -220,6 +236,8 @@ static struct chipset early_qrk[] __initdata = {
 	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs },
 	{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,
 	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs_contd },
+	{ PCI_VENDOR_ID_ATI, PCI_ANY_ID,
+	  PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_hpet_bugs },
 	{}
 };
 
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index e72d3fc..939b9e9 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -498,15 +498,10 @@ void force_hpet_resume(void)
  * See erratum #27 (Misinterpreted MSI Requests May Result in
  * Corrupted LPC DMA Data) in AMD Publication #46837,
  * "SB700 Family Product Errata", Rev. 1.0, March 2010.
- *
- * Also force the read back of the CMP register in hpet_next_event()
- * to work around the problem that the CMP register write seems to be
- * delayed. See hpet_next_event() for details.
  */
 static void force_disable_hpet_msi(struct pci_dev *unused)
 {
 	hpet_msi_disable = 1;
-	hpet_readback_cmp = 1;
 }
 
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS,

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

end of thread, other threads:[~2010-07-15 15:13 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-14 15:55 [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5 Stephan Wolf
2010-07-14 16:13 ` Linus Torvalds
2010-07-14 16:40   ` Stephan Wolf
2010-07-14 18:11   ` Borislav Petkov
2010-07-14 18:17     ` Linus Torvalds
2010-07-14 18:32       ` Borislav Petkov
2010-07-14 21:04         ` Thomas Gleixner
2010-07-15  7:06           ` Stephan Wolf
2010-07-15  8:22             ` Thomas Gleixner
2010-07-15 10:02               ` Borislav Petkov
2010-07-15 15:12           ` [tip:x86/urgent] x86: Force HPET readback_cmp for all ATI chipsets tip-bot for Thomas Gleixner
2010-07-14 19:32       ` [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5 Thomas Gleixner
2010-07-14 19:30   ` Thomas Gleixner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox