Re: [PATCH RFC] x86: hpet: Avoid the readback penalty

From: Anders Larsen
Date: Wed Sep 15 2010 - 10:07:52 EST


On 2010-09-15 15:11:57, Thomas Gleixner wrote:
> - * We need to read back the CMP register on certain HPET
> - * implementations (ATI chipsets) which seem to delay the
> - * transfer of the compare register into the internal compare
> - * logic. With small deltas this might actually be too late as
> - * the counter could already be higher than the compare value
> - * at that point and we would wait for the next hpet interrupt
> - * forever. We found out that reading the CMP register back
> - * forces the transfer so we can rely on the comparison with
> - * the counter register below. If the read back from the
> - * compare register does not match the value we programmed
> - * then we might have a real hardware problem. We can not do
> - * much about it here, but at least alert the user/admin with
> - * a prominent warning.
> - *
> - * An erratum on some chipsets (ICH9,..), results in
> - * comparator read immediately following a write returning old
> - * value. Workaround for this is to read this value second
> - * time, when first read returns old value.
> - *
> - * In fact the write to the comparator register is delayed up
> - * to two HPET cycles so the workaround we tried to restrict
> - * the readback to those known to be borked ATI chipsets
> - * failed miserably. So we give up on optimizations forever
> - * and penalize all HPET incarnations unconditionally.
> + * HPETs are a complete disaster. The compare register is
> + * based on a equal comparison and does provide a less than or

s/does provide/does not provide/

> + * equal functionality (which would require to take the
> + * wraparound into account) and it does not provide a simple
> + * count down event mode. Further the write to the comparator
> + * register is delayed internaly up to two HPET clock cycles

s/internaly/internally/

> + * in certain chipsets (ATI, ICH9,10). We worked around that
> + * by reading back the compare register, but that required
> + * another workaround for ICH9,10 chips where the first
> + * readout after write can return the old stale value. We
> + * already have a minimum delta of 5us enforced, but a NMI or
> + * SMI hitting between the counter readout and the comparator
> + * write can move us behind that point easily. Now instead of
> + * reading the compare register back several times, we make
> + * the ETIME decision based on the following: Return ETIME if
> + * the counter value after the write is less than 8 HPET
> + * cycles away from the event or if the counter is already
> + * ahead of the event.

Cheers
Anders


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