Skip to content

L
linux-davinci
Switch branch/tag
  1. 07 Sep, 2008 3 commits
  3. 06 Sep, 2008 7 commits
    • Dominik Brodowski's avatar
      clocksource, acpi_pm.c: check for monotonicity · 4ab6a219
      Dominik Brodowski authored 
      The current check for monotonicity is way too weak: Andreas Mohr reports (
http://lkml.org/lkml/2008/8/10/77 ) that on one of his test systems the
current check only triggers in 50% of all cases, leading to catastrophic
timer behaviour.  To fix this issue, expand the check for monotonicity by
doing ten consecutive tests instead of one.
Signed-off-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4ab6a219
    • Dominik Brodowski's avatar
      clocksource, acpi_pm.c: use proper read function also in errata mode · dfdf748a
      Dominik Brodowski authored 
      On all hardware (some Intel ICH4, PIIX4 and PIIX4E chipsets) affected by a
hardware errata there's about a 4.2% chance that initialization of the
ACPI PMTMR fails.  On those chipsets, we need to read out the timer value
at least three times to get a correct result, for every once in a while
(i.e.  within a 3 ns window every 69.8 ns) the read returns a bogus
result.  During normal operation we work around this issue, but during
initialization reading a bogus value may lead to -EINVAL even though the
hardware is usable.

Thanks to Andreas Mohr for spotting this issue.
Signed-off-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      dfdf748a
    • Maciej W. Rozycki's avatar
      ntp: fix calculation of the next jiffie to trigger RTC sync · 4ff4b9e1
      Maciej W. Rozycki authored 
      We have a bug in the calculation of the next jiffie to trigger the RTC
synchronisation.  The aim here is to run sync_cmos_clock() as close as
possible to the middle of a second.  Which means we want this function to
be called less than or equal to half a jiffie away from when now.tv_nsec
equals 5e8 (500000000).

If this is not the case for a given call to the function, for this purpose
instead of updating the RTC we calculate the offset in nanoseconds to the
next point in time where now.tv_nsec will be equal 5e8.  The calculated
offset is then converted to jiffies as these are the unit used by the
timer.

Hovewer timespec_to_jiffies() used here uses a ceil()-type rounding mode,
where the resulting value is rounded up.  As a result the range of
now.tv_nsec when the timer will trigger is from 5e8 to 5e8 + TICK_NSEC
rather than the desired 5e8 - TICK_NSEC / 2 to 5e8 + TICK_NSEC / 2.

As a result if for example sync_cmos_clock() happens to be called at the
time when now.tv_nsec is between 5e8 + TICK_NSEC / 2 and 5e8 to 5e8 +
TICK_NSEC, it will simply be rescheduled HZ jiffies later, falling in the
same range of now.tv_nsec again.  Similarly for cases offsetted by an
integer multiple of TICK_NSEC.

This change addresses the problem by subtracting TICK_NSEC / 2 from the
nanosecond offset to the next point in time where now.tv_nsec will be
equal 5e8, effectively shifting the following rounding in
timespec_to_jiffies() so that it produces a rounded-to-nearest result.
Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4ff4b9e1
    • Takashi Iwai's avatar
      Fix CONFIG_AC97_BUS dependency · 8a656496
      Takashi Iwai authored 
      CONFIG_AC97_BUS is used from both sound and ucb1400 drivers.
The recent change in Kconfig introduced the exclusive dependency on
CONFIG_SOUND, and disabled the ucb1400 build without sound.
This patch makes CONFIG_AC97_BUS independent.
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Tested-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      8a656496
    • Thomas Gleixner's avatar
      x86: HPET: read back compare register before reading counter · 72d43d9b
      Thomas Gleixner authored 
      After fixing the u32 thinko I sill had occasional hickups on ATI chipsets
with small deltas. There seems to be a delay between writing the compare
register and the transffer to the internal register which triggers the
interrupt. Reading back the value makes sure, that it hit the internal
match register befor we compare against the counter value.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      72d43d9b
    • Thomas Gleixner's avatar
      x86: HPET fix moronic 32/64bit thinko · f7676254
      Thomas Gleixner authored 
      We use the HPET only in 32bit mode because:
1) some HPETs are 32bit only
2) on i386 there is no way to read/write the HPET atomic 64bit wide

The HPET code unification done by the "moron of the year" did
not take into account that unsigned long is different on 32 and
64 bit.

This thinko results in a possible endless loop in the clockevents
code, when the return comparison fails due to the 64bit/332bit
unawareness. 

unsigned long cnt = (u32) hpet_read() + delta can wrap over 32bit.
but the final compare will fail and return -ETIME causing endless
loops.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      f7676254
    • Thomas Gleixner's avatar
      clockevents: broadcast fixup possible waiters · 7300711e
      Thomas Gleixner authored 
      Until the C1E patches arrived there where no users of periodic broadcast
before switching to oneshot mode. Now we need to trigger a possible
waiter for a periodic broadcast when switching to oneshot mode.
Otherwise we can starve them for ever.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      7300711e
  5. 05 Sep, 2008 30 commits