1. 07 2月, 2009 2 次提交
  2. 29 1月, 2009 1 次提交
  3. 03 12月, 2008 1 次提交
  4. 23 10月, 2008 2 次提交
  5. 13 10月, 2008 1 次提交
  6. 25 7月, 2008 1 次提交
  7. 23 7月, 2008 1 次提交
    • V
      x86: consolidate header guards · 77ef50a5
      Vegard Nossum 提交于
      This patch is the result of an automatic script that consolidates the
      format of all the headers in include/asm-x86/.
      
      The format:
      
      1. No leading underscore. Names with leading underscores are reserved.
      2. Pathname components are separated by two underscores. So we can
         distinguish between mm_types.h and mm/types.h.
      3. Everything except letters and numbers are turned into single
         underscores.
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      77ef50a5
  8. 22 7月, 2008 1 次提交
  9. 02 6月, 2008 1 次提交
    • L
      x86: MMIO and gcc re-ordering issue · c1f64a58
      Linus Torvalds 提交于
      On Tue, 27 May 2008, Linus Torvalds wrote:
      >
      > Expecting people to fix up all drivers is simply not going to happen. And
      > serializing things shouldn't be *that* expensive. People who cannot take
      > the expense can continue to use the magic __raw_writel() etc stuff.
      
      Of course, for non-x86, you kind of have to expect drivers to be
      well-behaved, so non-x86 can probably avoid this simply because there are
      less relevant drivers involved.
      
      Here's a UNTESTED patch for x86 that may or may not compile and work, and
      which serializes (on a compiler level) the IO accesses against regular
      memory accesses.
      
      __read[bwlq]()/__write[bwlq]() are not serialized with a :"memory"
      barrier, although since they still use "asm volatile" I suspect that i
      practice they are probably serial too. Did not look very closely at any
      generated code (only did a trivial test to see that the code looks
      *roughly* correct).
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c1f64a58
  10. 25 4月, 2008 1 次提交
  11. 17 4月, 2008 1 次提交
  12. 25 3月, 2008 1 次提交
  13. 30 1月, 2008 6 次提交
    • I
      x86: make ioremap() UC by default · 9af993a9
      Ingo Molnar 提交于
      Yes! A mere 120 c_p_a() fixing and rewriting patches later,
      we are now confident that we can enable UC by default for
      ioremap(), on x86 too.
      
      Every other architectures was doing this already. Doing so
      makes Linux more robust against MTRR mixups (which might go
      unnoticed if BIOS writers test other OSs only - where PAT
      might override bad MTRRs defaults).
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9af993a9
    • T
      x86: fix ioremap API · 5f868152
      Thomas Gleixner 提交于
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      5f868152
    • I
      x86: change ioremap() to default to uncached · 6371b495
      Ingo Molnar 提交于
      Prepare ioremap() to default to uncached. This will be the
      safest - but first we have to fix CPA.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      6371b495
    • G
      x86: tweak io_64.h for paravirt. · ba082427
      Glauber de Oliveira Costa 提交于
      We need something here because we can't call in and out instructions
      directly. However, we have to be careful, because no indirections are
      allowed in misc_64.c , and paravirt_ops is a kind of one. So just
      call it directly there
      Signed-off-by: NGlauber de Oliveira Costa <gcosta@redhat.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Acked-by: NJeremy Fitzhardinge <jeremy@xensource.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      ba082427
    • I
      x86: various changes and cleanups to in_p/out_p delay details · 6e7c4025
      Ingo Molnar 提交于
      various changes to the in_p/out_p delay details:
      
      - add the io_delay=none method
      - make each method selectable from the kernel config
      - simplify the delay code a bit by getting rid of an indirect function call
      - add the /proc/sys/kernel/io_delay_type sysctl
      - change 'io_delay=standard|alternate' to io_delay=0x80 and io_delay=0xed
      - make the io delay config not depend on CONFIG_DEBUG_KERNEL
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: N"David P. Reed" <dpreed@reed.com>
      6e7c4025
    • R
      x86: provide a DMI based port 0x80 I/O delay override. · b02aae9c
      Rene Herman 提交于
      x86: provide a DMI based port 0x80 I/O delay override.
      
      Certain (HP) laptops experience trouble from our port 0x80 I/O delay
      writes. This patch provides for a DMI based switch to the "alternate
      diagnostic port" 0xed (as used by some BIOSes as well) for these.
      
      David P. Reed confirmed that port 0xed works for him and provides a
      proper delay. The symptoms of _not_ working are a hanging machine,
      with "hwclock" use being a direct trigger.
      
      Earlier versions of this attempted to simply use udelay(2), with the
      2 being a value tested to be a nicely conservative upper-bound with
      help from many on the linux-kernel mailinglist but that approach has
      two problems.
      
      First, pre-loops_per_jiffy calibration (which is post PIT init while
      some implementations of the PIT are actually one of the historically
      problematic devices that need the delay) udelay() isn't particularly
      well-defined. We could initialise loops_per_jiffy conservatively (and
      based on CPU family so as to not unduly delay old machines) which
      would sort of work, but...
      
      Second, delaying isn't the only effect that a write to port 0x80 has.
      It's also a PCI posting barrier which some devices may be explicitly
      or implicitly relying on. Alan Cox did a survey and found evidence
      that additionally some drivers may be racy on SMP without the bus
      locking outb.
      
      Switching to an inb() makes the timing too unpredictable and as such,
      this DMI based switch should be the safest approach for now. Any more
      invasive changes should get more rigid testing first. It's moreover
      only very few machines with the problem and a DMI based hack seems
      to fit that situation.
      
      This also introduces a command-line parameter "io_delay" to override
      the DMI based choice again:
      
      	io_delay=<standard|alternate>
      
      where "standard" means using the standard port 0x80 and "alternate"
      port 0xed.
      
      This retains the udelay method as a config (CONFIG_UDELAY_IO_DELAY) and
      command-line ("io_delay=udelay") choice for testing purposes as well.
      
      This does not change the io_delay() in the boot code which is using
      the same port 0x80 I/O delay but those do not appear to be a problem
      as David P. Reed reported the problem was already gone after using the
      udelay version. He moreover reported that booting with "acpi=off" also
      fixed things and seeing as how ACPI isn't touched until after this DMI
      based I/O port switch I believe it's safe to leave the ones in the boot
      code be.
      
      The DMI strings from David's HP Pavilion dv9000z are in there already
      and we need to get/verify the DMI info from other machines with the
      problem, notably the HP Pavilion dv6000z.
      
      This patch is partly based on earlier patches from Pavel Machek and
      David P. Reed.
      Signed-off-by: NRene Herman <rene.herman@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      b02aae9c
  14. 17 10月, 2007 1 次提交
  15. 11 10月, 2007 1 次提交
  16. 17 7月, 2007 1 次提交
    • Y
      serial: convert early_uart to earlycon for 8250 · 18a8bd94
      Yinghai Lu 提交于
      Beacuse SERIAL_PORT_DFNS is removed from include/asm-i386/serial.h and
      include/asm-x86_64/serial.h.  the serial8250_ports need to be probed late in
      serial initializing stage.  the console_init=>serial8250_console_init=>
      register_console=>serial8250_console_setup will return -ENDEV, and console
      ttyS0 can not be enabled at that time.  need to wait till uart_add_one_port in
      drivers/serial/serial_core.c to call register_console to get console ttyS0.
      that is too late.
      
      Make early_uart to use early_param, so uart console can be used earlier.  Make
      it to be bootconsole with CON_BOOT flag, so can use console handover feature.
      and it will switch to corresponding normal serial console automatically.
      
      new command line will be:
      	console=uart8250,io,0x3f8,9600n8
      	console=uart8250,mmio,0xff5e0000,115200n8
      or
      	earlycon=uart8250,io,0x3f8,9600n8
      	earlycon=uart8250,mmio,0xff5e0000,115200n8
      
      it will print in very early stage:
      	Early serial console at I/O port 0x3f8 (options '9600n8')
      	console [uart0] enabled
      later for console it will print:
      	console handover: boot [uart0] -> real [ttyS0]
      
      Signed-off-by: <yinghai.lu@sun.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Gerd Hoffmann <kraxel@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      18a8bd94
  17. 13 2月, 2007 1 次提交
  18. 10 2月, 2007 1 次提交
  19. 12 10月, 2006 1 次提交
  20. 26 4月, 2006 1 次提交
  21. 11 4月, 2006 1 次提交
  22. 26 3月, 2006 2 次提交
  23. 24 3月, 2006 1 次提交
  24. 12 1月, 2006 1 次提交
    • A
      [PATCH] x86_64: Generalize DMI and enable for x86-64 · e9928674
      Andi Kleen 提交于
      Some people need it now on 64bit so reuse the i386 code for
      x86-64. This will be also useful for future bug workarounds.
      
      It is a bit simplified there because there is no need
      to do it very early on x86-64. This means it doesn't need
      early ioremap et.al. We run it as a core initcall right now.
      
      I hope it's not needed for early setup.
      
      I added a general CONFIG_DMI symbol in case IA64 or someone
      else wants to reuse the code later too.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e9928674
  25. 13 9月, 2005 1 次提交
  26. 24 6月, 2005 1 次提交
  27. 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