enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
in [Kernel]
|
From: Thomas Gleixner on 14 Jul 2010 15:40 On Wed, 14 Jul 2010, Linus Torvalds wrote: > On Wed, Jul 14, 2010 at 11:11 AM, Borislav Petkov > <borislav.petkov(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Gleixner on 14 Jul 2010 15:40 On Wed, 14 Jul 2010, Linus Torvalds wrote: > On Wed, Jul 14, 2010 at 8:55 AM, Stephan Wolf > <stephan(a)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
From: Thomas Gleixner on 14 Jul 2010 17:10 On Wed, 14 Jul 2010, Borislav Petkov wrote: > From: Linus Torvalds <torvalds(a)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(a)linutronix.de> Date: Wed, 14 Jul 2010 21:36:27 +0200 Signed-off-by: Thomas Gleixner <tglx(a)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, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stephan Wolf on 15 Jul 2010 03:10 Am 14.07.2010 23:04, schrieb Thomas Gleixner: > On Wed, 14 Jul 2010, Borislav Petkov wrote: > > >> From: Linus Torvalds<torvalds(a)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(a)linutronix.de> > Date: Wed, 14 Jul 2010 21:36:27 +0200 > > Signed-off-by: Thomas Gleixner<tglx(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Gleixner on 15 Jul 2010 04:30 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: Removing dead CASSINI_QGE_DEBUG Next: [PATCH] drm/i810: fixed coding style issues |