28 Aug, 2009

1 commit

  • Generic support for remapping HPET MSI's by parsing the HPET timer block
    device scope in the ACPI DRHD tables. This is needed for platforms
    supporting interrupt-remapping and MSI capable HPET timer block.

    Signed-off-by: Suresh Siddha
    Cc: David Woodhouse
    Cc: Jesse Barnes
    Cc: Venkatesh Pallipadi
    Cc: Jay Fenlason
    LKML-Reference:
    Signed-off-by: Thomas Gleixner

    Suresh Siddha
     

01 Aug, 2008

1 commit

  • Minor /dev/hpet updates and bugfixes:

    * Remove dead code, mostly remnants of an incomplete/unusable
    kernel interface ... noted when addressing "sparse" warnings:
    + hpet_unregister() and a routine it calls
    + hpet_task and all references, including hpet_task_lock
    + hpet_data.hd_flags (and HPET_DATA_PLATFORM)

    * Correct and improve boot message:
    + displays *counter* (shared between comparators) bit width,
    not *timer* bit widths (which are often mixed)
    + relabel "timers" as "comparators"; this is less confusing,
    they are not independent like normal timers are (sigh)
    + display MHz not Hz; it's never less than 10 MHz.

    * Tighten and correct the userspace interface code
    + don't accidentally program comparators in 64-bit mode using
    32-bit values ... always force comparators into 32-bit mode
    + provide the correct bit definition flagging comparators with
    periodic capability ... the ABI is unchanged

    * Update Documentation/hpet.txt
    + be more correct and current
    + expand description a bit
    + don't mention that now-gone kernel interface

    Plus, add a FIXME comment for something that could cause big trouble
    on systems with more capable HPETs than at least Intel seems to ship.

    It seems that few folk use this userspace interface; it's not very
    usable given the general lack of HPET IRQ routing. I'm told that
    the only real point of it any more is to mmap for fast timestamps;
    IMO that's handled better through the gettimeofday() vsyscall.

    Signed-off-by: David Brownell
    Acked-by: Clemens Ladisch
    Signed-off-by: Ingo Molnar

    David Brownell
     

02 Jun, 2008

1 commit

  • HPET timer's IRQ is 0 by default. So we have to select which irq
    will be used by these timers. We wait to set the timer's irq until
    we really open it in order to reduce the chance of conflicting with
    other device.

    Signed-off-by: Kevin Hao
    Signed-off-by: Ingo Molnar

    Kevin Hao
     

05 Apr, 2008

1 commit

  • The commits:

    commit 37a47db8d7f0f38dac5acf5a13abbc8f401707fa
    Author: Balaji Rao
    Date: Wed Jan 30 13:30:03 2008 +0100

    x86: assign IRQs to HPET timers, fix

    and

    commit e3f37a54f690d3e64995ea7ecea08c5ab3070faf
    Author: Balaji Rao
    Date: Wed Jan 30 13:30:03 2008 +0100

    x86: assign IRQs to HPET timers

    have been identified to cause a regression on some platforms due to
    the assignement of legacy IRQs which makes the legacy devices
    connected to those IRQs disfunctional.

    Revert them.

    This fixes http://bugzilla.kernel.org/show_bug.cgi?id=10382

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Thomas Gleixner
     

30 Jan, 2008

2 commits

  • No users, just ballast

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar

    Thomas Gleixner
     
  • The userspace API for the HPET (see Documentation/hpet.txt) did not work. The
    HPET_IE_ON ioctl was failing as there was no IRQ assigned to the timer
    device. This patch fixes it by allocating IRQs to timer blocks in the HPET.

    arch/x86/kernel/hpet.c | 13 +++++--------
    drivers/char/hpet.c | 45 ++++++++++++++++++++++++++++++++++++++-------
    include/linux/hpet.h | 2 +-
    3 files changed, 44 insertions(+), 16 deletions(-)

    Signed-off-by: Balaji Rao
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Balaji Rao
     

27 Mar, 2006

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds