1. 27 8月, 2013 1 次提交
  2. 04 1月, 2013 1 次提交
    • G
      Drivers: clocksource: remove __dev* attributes. · 1850514b
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      __devinitconst, and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: John Stultz <johnstul@us.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1850514b
  3. 14 11月, 2012 1 次提交
  4. 12 4月, 2012 1 次提交
    • T
      Revert "clocksource: Load the ACPI PM clocksource asynchronously" · d48fc63f
      Thomas Gleixner 提交于
      This reverts commit b5195082.
      
      The reason for this revert is that making the frequency verification
      preemptible and interruptible is not working reliably. Michaels
      machine failed to use PM-timer with the message:
      
        PM-Timer running at invalid rate: 113% of normal - aborting.
      
      That's not a surprise as the frequency verification does rely on
      interrupts being disabled. With a async scheduled thread there is no
      guarantee to achieve the same result. Also some driver might fiddle
      with the CTC channel 2 during the verification period, which makes the
      result even more random and unpredictable.
      
      This can be solved by using the same mechanism as we use in the
      deferred TSC validation code, but that only will work if we verified a
      working HPET _BEFORE_ trying to do the PM-Timer lazy validation.
      
      So for now reverting is the safe option.
      Bisected-by: NMichael Witten <mfwitten@gmail.com>
      Cc: Arjan van de Ven <arjanvandeven@gmail.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: John Stultz <johnstul@us.ibm.com>
      Cc: Len Brown <lenb@kernel.org>
      LKML-Reference: <alpine.LFD.2.02.1204112303270.2542@ionos>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      d48fc63f
  5. 02 2月, 2012 1 次提交
    • A
      clocksource: Load the ACPI PM clocksource asynchronously · b5195082
      Arjan van de Ven 提交于
      The ACPI clocksource takes quite some time to initialize,
      and this increases the boot time of the kernel for a
      double digit percentage. This while almost all modern
      systems will be using the HPET already anyway.
      
      This patch turns the clocksource loading into an asynchronous
      operation; which means it won't hold up the boot while
      still becoming available normally.
      
      To make this work well, an udelay() had to be turned into an
      usleep_range() so that on UP systems, we yield the CPU to
      regular boot tasks instead of spinning.
      
      CC: John Stultz <johnstul@us.ibm.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Len Brown <lenb@kernel.org>
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      b5195082
  6. 22 11月, 2011 1 次提交
  7. 22 1月, 2011 1 次提交
  8. 27 7月, 2010 1 次提交
  9. 17 6月, 2009 1 次提交
    • A
      time: move PIT_TICK_RATE to linux/timex.h · 08604bd9
      Arnd Bergmann 提交于
      PIT_TICK_RATE is currently defined in four architectures, but in three
      different places.  While linux/timex.h is not the perfect place for it, it
      is still a reasonable replacement for those drivers that traditionally use
      asm/timex.h to get CLOCK_TICK_RATE and expect it to be the PIT frequency.
      
      Note that for Alpha, the actual value changed from 1193182UL to 1193180UL.
       This is unlikely to make a difference, and probably can only improve
      accuracy.  There was a discussion on the correct value of CLOCK_TICK_RATE
      a few years ago, after which every existing instance was getting changed
      to 1193182.  According to the specification, it should be
      1193181.818181...
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      08604bd9
  10. 22 4月, 2009 1 次提交
  11. 29 1月, 2009 1 次提交
  12. 12 12月, 2008 1 次提交
  13. 11 9月, 2008 1 次提交
  14. 06 9月, 2008 2 次提交
  15. 21 8月, 2008 1 次提交
  16. 16 7月, 2008 1 次提交
  17. 12 7月, 2008 1 次提交
  18. 10 7月, 2008 1 次提交
  19. 22 7月, 2007 1 次提交
  20. 12 7月, 2007 1 次提交
    • A
      PCI: Change all drivers to use pci_device->revision · 44c10138
      Auke Kok 提交于
      Instead of all drivers reading pci config space to get the revision
      ID, they can now use the pci_device->revision member.
      
      This exposes some issues where drivers where reading a word or a dword
      for the revision number, and adding useless error-handling around the
      read. Some drivers even just read it for no purpose of all.
      
      In devices where the revision ID is being copied over and used in what
      appears to be the equivalent of hotpath, I have left the copy code
      and the cached copy as not to influence the driver's performance.
      
      Compile tested with make all{yes,mod}config on x86_64 and i386.
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Acked-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      44c10138
  21. 26 4月, 2007 1 次提交
  22. 28 3月, 2007 1 次提交
  23. 05 3月, 2007 1 次提交
    • J
      [PATCH] clocksource init adjustments (fix bug #7426) · 6bb74df4
      john stultz 提交于
      This patch resolves the issue found here:
      http://bugme.osdl.org/show_bug.cgi?id=7426
      
      The basic summary is:
      Currently we register most of i386/x86_64 clocksources at module_init
      time. Then we enable clocksource selection at late_initcall time. This
      causes some problems for drivers that use gettimeofday for init
      calibration routines (specifically the es1968 driver in this case),
      where durring module_init, the only clocksource available is the low-res
      jiffies clocksource. This may cause slight calibration errors, due to
      the small sampling time used.
      
      It should be noted that drivers that require fine grained time may not
      function on architectures that do not have better then jiffies
      resolution timekeeping (there are a few). However, this does not
      discount the reasonable need for such fine-grained timekeeping at init
      time.
      
      Thus the solution here is to register clocksources earlier (ideally when
      the hardware is being initialized), and then we enable clocksource
      selection at fs_initcall (before device_initcall).
      
      This patch should probably get some testing time in -mm, since
      clocksource selection is one of the most important issues for correct
      timekeeping, and I've only been able to test this on a few of my own
      boxes.
      Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6bb74df4
  24. 17 2月, 2007 2 次提交
  25. 11 12月, 2006 1 次提交
  26. 09 12月, 2006 1 次提交
  27. 22 10月, 2006 1 次提交
  28. 27 6月, 2006 4 次提交