1. 06 7月, 2015 1 次提交
  2. 07 1月, 2014 1 次提交
  3. 04 1月, 2013 1 次提交
    • G
      X86: drivers: remove __dev* attributes. · a18e3690
      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, __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: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Daniel Drake <dsd@laptop.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a18e3690
  4. 10 3月, 2012 1 次提交
    • T
      x86: Derandom delay_tsc for 64 bit · a7f4255f
      Thomas Gleixner 提交于
      Commit f0fbf0ab ("x86: integrate delay functions") converted
      delay_tsc() into a random delay generator for 64 bit.  The reason is
      that it merged the mostly identical versions of delay_32.c and
      delay_64.c.  Though the subtle difference of the result was:
      
       static void delay_tsc(unsigned long loops)
       {
      -	unsigned bclock, now;
      +	unsigned long bclock, now;
      
      Now the function uses rdtscl() which returns the lower 32bit of the
      TSC. On 32bit that's not problematic as unsigned long is 32bit. On 64
      bit this fails when the lower 32bit are close to wrap around when
      bclock is read, because the following check
      
             if ((now - bclock) >= loops)
             	  	break;
      
      evaluated to true on 64bit for e.g. bclock = 0xffffffff and now = 0
      because the unsigned long (now - bclock) of these values results in
      0xffffffff00000001 which is definitely larger than the loops
      value. That explains Tvortkos observation:
      
      "Because I am seeing udelay(500) (_occasionally_) being short, and
       that by delaying for some duration between 0us (yep) and 491us."
      
      Make those variables explicitely u32 again, so this works for both 32
      and 64 bit.
      Reported-by: NTvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org # >= 2.6.27
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7f4255f
  5. 04 1月, 2011 1 次提交
  6. 26 6月, 2009 1 次提交
    • P
      x86, delay: tsc based udelay should have rdtsc_barrier · e888d7fa
      Pallipadi, Venkatesh 提交于
      delay_tsc needs rdtsc_barrier to provide proper delay.
      
      Output from a test driver using hpet to cross check delay
      provided by udelay().
      
      Before:
      [   86.794363] Expected delay 5us actual 4679ns
      [   87.154362] Expected delay 5us actual 698ns
      [   87.514162] Expected delay 5us actual 4539ns
      [   88.653716] Expected delay 5us actual 4539ns
      [   94.664106] Expected delay 10us actual 9638ns
      [   95.049351] Expected delay 10us actual 10126ns
      [   95.416110] Expected delay 10us actual 9568ns
      [   95.799216] Expected delay 10us actual 9638ns
      [  103.624104] Expected delay 10us actual 9707ns
      [  104.020619] Expected delay 10us actual 768ns
      [  104.419951] Expected delay 10us actual 9707ns
      
      After:
      [   50.983320] Expected delay 5us actual 5587ns
      [   51.261807] Expected delay 5us actual 5587ns
      [   51.565715] Expected delay 5us actual 5657ns
      [   51.861171] Expected delay 5us actual 5587ns
      [   52.164704] Expected delay 5us actual 5726ns
      [   52.487457] Expected delay 5us actual 5657ns
      [   52.789338] Expected delay 5us actual 5726ns
      [   57.119680] Expected delay 10us actual 10755ns
      [   57.893997] Expected delay 10us actual 10615ns
      [   58.261287] Expected delay 10us actual 10755ns
      [   58.620505] Expected delay 10us actual 10825ns
      [   58.941035] Expected delay 10us actual 10755ns
      [   59.320903] Expected delay 10us actual 10615ns
      [   61.306311] Expected delay 10us actual 10755ns
      [   61.520542] Expected delay 10us actual 10615ns
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      e888d7fa
  7. 09 7月, 2008 4 次提交
  8. 17 6月, 2008 1 次提交
    • J
      x86: fix bug in arch/i386/lib/delay.c file, delay_loop function · e01b70ef
      Jiri Hladky 提交于
      when trying to understand how Bogomips are implemented I have found a
      bug in arch/i386/lib/delay.c file, delay_loop function.
      
      The function fails for loops > 2^31+1. It because SF is set when dec
      returns numbers > 2^31.
      
      The fix is to use jnz instruction instead of jns (and add one decl
      instruction to the end to have exactly the same number of loops as in
      original version).
      
      Martin Mares observed:
      
      > It is a long time since I have hacked that file, but you should definitely
      > make sure that the function is never called with a zero argument. In such
      > case, the original version made just a single pass, but your version
      > makes 2^32 of them.
      
      fixed that.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e01b70ef
  9. 04 6月, 2008 1 次提交
    • S
      x86: enable preemption in delay · 5c1ea082
      Steven Rostedt 提交于
      The RT team has been searching for a nasty latency. This latency shows
      up out of the blue and has been seen to be as big as 5ms!
      
      Using ftrace I found the cause of the latency.
      
         pcscd-2995  3dNh1 52360300us : irq_exit (smp_apic_timer_interrupt)
         pcscd-2995  3dN.2 52360301us : idle_cpu (irq_exit)
         pcscd-2995  3dN.2 52360301us : rcu_irq_exit (irq_exit)
         pcscd-2995  3dN.1 52360771us : smp_apic_timer_interrupt (apic_timer_interrupt
      )
         pcscd-2995  3dN.1 52360771us : exit_idle (smp_apic_timer_interrupt)
      
      Here's an example of a 400 us latency. pcscd took a timer interrupt and
      returned with "need resched" enabled, but did not reschedule until after
      the next interrupt came in at 52360771us 400us later!
      
      At first I thought we somehow missed a preemption check in entry.S. But
      I also noticed that this always seemed to happen during a __delay call.
      
         pcscd-2995  3dN.2 52360836us : rcu_irq_exit (irq_exit)
         pcscd-2995  3.N.. 52361265us : preempt_schedule (__delay)
      
      Looking at the x86 delay, I found my problem.
      
      In git commit 35d5d08a, Andrew Morton
      placed preempt_disable around the entire delay due to TSC's not working
      nicely on SMP.  Unfortunately for those that care about latencies this
      is devastating! Especially when we have callers to mdelay(8).
      
      Here I enable preemption during the loop and account for anytime the task
      migrates to a new CPU. The delay asked for may be extended a bit by
      the migration, but delay only guarantees that it will delay for that minimum
      time. Delaying longer should not be an issue.
      
      [
        Thanks to Thomas Gleixner for spotting that cpu wasn't updated,
          and to place the rep_nop between preempt_enabled/disable.
      ]
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Cc: akpm@osdl.org
      Cc: Clark Williams <clark.williams@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: "Luis Claudio R. Goncalves" <lclaudio@uudg.org>
      Cc: Gregory Haskins <ghaskins@novell.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andi Kleen <andi-suse@firstfloor.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      5c1ea082
  10. 07 2月, 2008 1 次提交
    • A
      read_current_timer() cleanups · 941e492b
      Andrew Morton 提交于
      - All implementations can be __devinit
      
      - The function prototypes were in asm/timex.h but they all must be the same,
        so create a single declaration in linux/timex.h.
      
      - uninline the sparc64 version to match the other architectures
      
      - Don't bother #defining ARCH_HAS_READ_CURRENT_TIMER to a particular value.
      
      [ezk@cs.sunysb.edu: fix build]
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      941e492b
  11. 15 11月, 2007 1 次提交
  12. 20 10月, 2007 1 次提交
    • M
      x86: convert cpuinfo_x86 array to a per_cpu array · 92cb7612
      Mike Travis 提交于
      cpu_data is currently an array defined using NR_CPUS.  This means that
      we overallocate since we will rarely really use maximum configured cpus.
      When NR_CPU count is raised to 4096 the size of cpu_data becomes
      3,145,728 bytes.
      
      These changes were adopted from the sparc64 (and ia64) code.  An
      additional field was added to cpuinfo_x86 to be a non-ambiguous cpu
      index.  This corresponds to the index into a cpumask_t as well as the
      per_cpu index.  It's used in various places like show_cpuinfo().
      
      cpu_data is defined to be the boot_cpu_data structure for the NON-SMP
      case.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: Mark M. Hoffman <mhoffman@lightlink.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      92cb7612
  13. 11 10月, 2007 2 次提交
  14. 01 10月, 2006 1 次提交
  15. 27 6月, 2006 1 次提交
  16. 24 6月, 2005 1 次提交
  17. 22 6月, 2005 1 次提交
    • I
      [PATCH] smp_processor_id() cleanup · 39c715b7
      Ingo Molnar 提交于
      This patch implements a number of smp_processor_id() cleanup ideas that
      Arjan van de Ven and I came up with.
      
      The previous __smp_processor_id/_smp_processor_id/smp_processor_id API
      spaghetti was hard to follow both on the implementational and on the
      usage side.
      
      Some of the complexity arose from picking wrong names, some of the
      complexity comes from the fact that not all architectures defined
      __smp_processor_id.
      
      In the new code, there are two externally visible symbols:
      
       - smp_processor_id(): debug variant.
      
       - raw_smp_processor_id(): nondebug variant. Replaces all existing
         uses of _smp_processor_id() and __smp_processor_id(). Defined
         by every SMP architecture in include/asm-*/smp.h.
      
      There is one new internal symbol, dependent on DEBUG_PREEMPT:
      
       - debug_smp_processor_id(): internal debug variant, mapped to
                                   smp_processor_id().
      
      Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new
      lib/smp_processor_id.c file.  All related comments got updated and/or
      clarified.
      
      I have build/boot tested the following 8 .config combinations on x86:
      
       {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT}
      
      I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT.  (Other
      architectures are untested, but should work just fine.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      39c715b7
  18. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4