1. 15 Jul, 2008 1 commit
    • Haavard Skinnemoen's avatar
      atmel-mci: Driver for Atmel on-chip MMC controllers · 7d2be074
      Haavard Skinnemoen authored
      This is a driver for the MMC controller on the AP7000 chips from
      Atmel. It should in theory work on AT91 systems too with some
      tweaking, but since the DMA interface is quite different, it's not
      entirely clear if it's worth merging this with the at91_mci driver.
      This driver has been around for a while in BSPs and kernel sources
      provided by Atmel, but this particular version uses the generic DMA
      Engine framework (with the slave extensions) instead of an
      avr32-only DMA controller framework.
      This driver can also use PIO transfers when no DMA channels are
      available, and for transfers where using DMA may be difficult or
      impractical for some reason (e.g. the DMA setup overhead is usually
      not worth it for very short transfers, and badly aligned buffers or
      lengths are difficult to handle.)
      Currently, the driver only support PIO transfers. DMA support has been
      split out to a separate patch to hopefully make it easier to review.
      The driver has been tested using mmc-block and ext3fs on several SD,
      SDHC and MMC+ cards. Reads and writes work fine, with read transfer
      rates up to 3.5 MiB/s on fast cards with debugging disabled.
      The driver has also been tested using the mmc_test module on the same
      cards. All tests except 7, 9, 15 and 17 succeed. The first two are
      unsupported by all the cards I have, so I don't know if the driver
      handles this correctly. The last two fail because the hardware flags a
      Data CRC Error instead of a Data Timeout error. I'm not sure how to deal
      with that.
      Documentation for this controller can be found in many data sheets from
      Atmel, including the AT32AP7000 data sheet which can be found here:
      http://www.atmel.com/dyn/products/datasheets.asp?family_id=682Signed-off-by: default avatarHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
  2. 14 Jul, 2008 24 commits
  3. 13 Jul, 2008 7 commits
    • Mike Travis's avatar
      x86: change _node_to_cpumask_ptr to return const ptr · 11369f35
      Mike Travis authored
        * Strengthen the return type for the _node_to_cpumask_ptr to be
          a const pointer.  This adds compiler checking to insure that
          node_to_cpumask_map[] is not changed inadvertently.
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Acked-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Maciej W. Rozycki's avatar
      x86: I/O APIC: remove an IRQ2-mask hack · ce8b06b9
      Maciej W. Rozycki authored
      Now that IRQ2 is never made available to the I/O APIC, there is no need
      to special-case it and mask as a workaround for broken systems.  Actually,
      because of the former, mask_IO_APIC_irq(2) is a no-op already.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Yinghai Lu's avatar
      x86: fix numaq_tsc_disable calling · 3d88cca7
      Yinghai Lu authored
      got this on a test-system:
       calling  numaq_tsc_disable+0x0/0x39
       NUMAQ: disabling TSC
       initcall numaq_tsc_disable+0x0/0x39 returned 0 after 0 msecs
      that's because we should not be using arch_initcall to call numaq_tsc_disable.
      need to call it in setup_arch before time_init()/tsc_init()
      and call it in init_intel() to make the cpu feature bits right.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Yinghai Lu's avatar
      x86, e820: remove end_user_pfn · 7b479bec
      Yinghai Lu authored
      end_user_pfn used to modify the meaning of the e820 maps.
      Now that all e820 operations are cleaned up, unified, tightened up,
      the e820 map always get updated to reality, we don't need to keep
      this secondary mechanism anymore.
      If you hit this commit in bisection it means something slipped through.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Yinghai Lu's avatar
      x86: max_low_pfn_mapped fix, #3 · 9958e810
      Yinghai Lu authored
      optimization: try to merge the range with same page size in
      init_memory_mapping, to get the best possible linear mappings set up.
      thus when GBpages is not there, we could do 2M pages.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Yinghai Lu's avatar
      x86: max_low_pfn_mapped fix, #2 · 965194c1
      Yinghai Lu authored
      tighten the boundary checks around max_low_pfn_mapped - dont overmap
      nor undermap into holes.
      also print out tseg for AMD cpus, for diagnostic purposes.
      (this is an SMM area, and we split up any big mappings around that area)
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Yinghai Lu's avatar
      x86: max_low_pfn_mapped fix, #1 · 7ab073b6
      Yinghai Lu authored
      fix crash on Ingo's big box:
      calling  pci_iommu_init+0x0/0x17
      PCI-DMA: Disabling AGP.
      PCI-DMA: aperture base @ d0000000 size 65536 KB
      PCI-DMA: using GART IOMMU.
      PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
      BUG: unable to handle kernel paging request at ffff88000003be88
      IP: [<ffffffff8026d377>] __alloc_pages_internal+0xc3/0x3f2
      PGD 202063 PUD 206063 PMD 22fc00163 PTE 3b162
      Oops: 0000 [1] SMP
      and e820 is:
       BIOS-e820: 0000000000000000 - 000000000009ac00 (usable)
       BIOS-e820: 000000000009ac00 - 00000000000a0000 (reserved)
       BIOS-e820: 00000000000ca000 - 0000000000100000 (reserved)
       BIOS-e820: 0000000000100000 - 000000007ff70000 (usable)
       BIOS-e820: 000000007ff70000 - 000000007ff86000 (ACPI data)
       BIOS-e820: 000000007ff86000 - 0000000080000000 (ACPI NVS)
       BIOS-e820: 0000000080000000 - 00000000cfe00000 (usable)
       BIOS-e820: 00000000cfe00000 - 00000000d0000000 (reserved)
       BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
       BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
       BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
       BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
       BIOS-e820: 0000000100000000 - 0000000830000000 (usable)
      system has 32 GB RAM installed.
      max_low_pfn_mapped is 0xcfe00, and GART aperture is not mapped.
      So try to use init_memory_mapping to map that area, because the iommu
      thinks that area is ram ...
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  4. 12 Jul, 2008 1 commit
  5. 11 Jul, 2008 7 commits
    • Roland McGrath's avatar
      x86_64: fix delayed signals · eca91e78
      Roland McGrath authored
      On three of the several paths in entry_64.S that call
      do_notify_resume() on the way back to user mode, we fail to properly
      check again for newly-arrived work that requires another call to
      do_notify_resume() before going to user mode.  These paths set the
      mask to check only _TIF_NEED_RESCHED, but this is wrong.  The other
      paths that lead to do_notify_resume() do this correctly already, and
      entry_32.S does it correctly in all cases.
      All paths back to user mode have to check all the _TIF_WORK_MASK
      flags at the last possible stage, with interrupts disabled.
      Otherwise, we miss any flags (TIF_SIGPENDING for example) that were
      set any time after we entered do_notify_resume().  More work flags
      can be set (or left set) synchronously inside do_notify_resume(), as
      TIF_SIGPENDING can be, or asynchronously by interrupts or other CPUs
      (which then send an asynchronous interrupt).
      There are many different scenarios that could hit this bug, most of
      them races.  The simplest one to demonstrate does not require any
      race: when one signal has done handler setup at the check before
      returning from a syscall, and there is another signal pending that
      should be handled.  The second signal's handler should interrupt the
      first signal handler before it actually starts (so the interrupted PC
      is still at the handler's entry point).  Instead, it runs away until
      the next kernel entry (next syscall, tick, etc).
      This test behaves correctly on 32-bit kernels, and fails on 64-bit
      (either 32-bit or 64-bit test binary).  With this fix, it works.
          #define _GNU_SOURCE
          #include <stdio.h>
          #include <signal.h>
          #include <string.h>
          #include <sys/ucontext.h>
          #ifndef REG_RIP
          #define REG_RIP REG_EIP
          static sig_atomic_t hit1, hit2;
          static void
          handler (int sig, siginfo_t *info, void *ctx)
            ucontext_t *uc = ctx;
            if ((void *) uc->uc_mcontext.gregs[REG_RIP] == &handler)
                if (sig == SIGUSR1)
                  hit1 = 1;
                  hit2 = 1;
            printf ("%s at %#lx\n", strsignal (sig),
          main (void)
            struct sigaction sa;
            sigset_t set;
            sigemptyset (&sa.sa_mask);
            sa.sa_flags = SA_SIGINFO;
            sa.sa_sigaction = &handler;
            if (sigaction (SIGUSR1, &sa, NULL)
                || sigaction (SIGUSR2, &sa, NULL))
              return 2;
            sigemptyset (&set);
            sigaddset (&set, SIGUSR1);
            sigaddset (&set, SIGUSR2);
            if (sigprocmask (SIG_BLOCK, &set, NULL))
              return 3;
            printf ("main at %p, handler at %p\n", &main, &handler);
            raise (SIGUSR1);
            raise (SIGUSR2);
            if (sigprocmask (SIG_UNBLOCK, &set, NULL))
              return 4;
            if (hit1 + hit2 == 1)
                puts ("PASS");
                return 0;
            puts ("FAIL");
            return 1;
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Rafael J. Wysocki's avatar
      x86: remove conflicting nx6325 and nx6125 quirks · da1f29f5
      Rafael J. Wysocki authored
      We have two conflicting DMA-based quirks in there for the same set of
      boxes (HP nx6325 and nx6125) and one of them actually breaks my box.
      So remove the extra code.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: =?iso-8859-1?q?T=F6r=F6k_Edwin?= <edwintorok@gmail.com>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Maciej W. Rozycki's avatar
      x86: Recover timer_ack lost in the merge of the NMI watchdog · 5b4d2386
      Maciej W. Rozycki authored
      In the course of the recent unification of the NMI watchdog an assignment
      to timer_ack to switch off unnecesary POLL commands to the 8259A in the
      case of a watchdog failure has been accidentally removed.  The statement
      used to be limited to the 32-bit variation as since the rewrite of the
      timer code it has been relevant for the 82489DX only.  This change brings
      it back.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Maciej W. Rozycki's avatar
      x86: I/O APIC: Never configure IRQ2 · af174783
      Maciej W. Rozycki authored
      There is no such entity as ISA IRQ2.  The ACPI spec does not make it
      explicitly clear, but does not preclude it either -- all it says is ISA
      legacy interrupts are identity mapped by default (subject to overrides),
      but it does not state whether IRQ2 exists or not.  As a result if there is
      no IRQ0 override, then IRQ2 is normally initialised as an ISA interrupt,
      which implies an edge-triggered line, which is unmasked by default as this
      is what we do for edge-triggered I/O APIC interrupts so as not to miss an
      To the best of my knowledge it is useless, as IRQ2 has not been in use
      since the PC/AT as back then it was taken by the 8259A cascade interrupt
      to the slave, with the line position in the slot rerouted to newly-created
      IRQ9.  No device could thus make use of this line with the pair of 8259A
      chips.  Now in theory INTIN2 of the I/O APIC may be usable, but the
      interrupt of the device wired to it would not be available in the PIC mode
      at all, so I seriously doubt if anybody decided to reuse it for a regular
      However there are two common uses of INTIN2.  One is for IRQ0, with an
      ACPI interrupt override (or its equivalent in the MP table).  But in this
      case IRQ2 is gone entirely with INTIN0 left vacant.  The other one is for
      an 8959A ExtINTA cascade.  In this case IRQ0 goes to INTIN0 and if ACPI is
      used INTIN2 is assumed to be IRQ2 (there is no override and ACPI has no
      way to report ExtINTA interrupts).  This is where a problem happens.
      The problem is INTIN2 is configured as a native APIC interrupt, with a
      vector assigned and the mask cleared.  And the line may indeed get active
      and inject interrupts if the master 8959A has its timer interrupt enabled
      (it might happen for other interrupts too, but they are normally masked in
      the process of rerouting them to the I/O APIC).  There are two cases where
      it will happen:
      * When the I/O APIC NMI watchdog is enabled.  This is actually a misnomer
        as the watchdog pulses are delivered through the 8259A to the LINT0
        inputs of all the local APICs in the system.  The implication is the
        output of the master 8259A goes high and low repeatedly, signalling
        interrupts to INTIN2 which is enabled too!
        [The origin of the name is I think for a brief period during the
        development we had a capability in our code to configure the watchdog to
        use an I/O APIC input; that would be INTIN2 in this scenario.]
      * When the native route of IRQ0 via INTIN0 fails for whatever reason -- as
        it happens with the system considered here.  In this scenario the timer
        pulse is delivered through the 8259A to LINT0 input of the local APIC of
        the bootstrap processor, quite similarly to how is done for the watchdog
        described above.  The result is, again, INTIN2 receives these pulses
        too.  Rafael's system used to escape this scenario, because an incorrect
        IRQ0 override would occupy INTIN2 and prevent it from being unmasked.
      My conclusion is IRQ2 should be excluded from configuration in all the
      cases and the current exception for ACPI systems should be lifted.  The
      reason being the exception not only being useless, but harmful as well.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Maciej W. Rozycki's avatar
      x86: L-APIC: Always fully configure IRQ0 · c88ac1df
      Maciej W. Rozycki authored
      Unlike the 32-bit one, the 64-bit variation of the LVT0 setup code for
      the "8259A Virtual Wire" through the local APIC timer configuration does
      not fully configure the relevant irq_chip structure.  Instead it relies on
      the preceding I/O APIC code to have set it up, which does not happen if
      the I/O APIC variants have not been tried.
      The patch includes corresponding changes to the 32-bit variation too
      which make them both the same, barring a small syntactic difference
      involving sequence of functions in the source.  That should work as an aid
      with the upcoming merge.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Maciej W. Rozycki's avatar
      x86: L-APIC: Set IRQ0 as edge-triggered · 1baea6e2
      Maciej W. Rozycki authored
       IRQ0 is edge-triggered, but the "8259A Virtual Wire" through the local
      APIC configuration in the 32-bit version uses the "fasteoi" handler
      suitable for level-triggered APIC interrupt.  Rewrite code so that the
      "edge" handler is used.  The 64-bit version uses different code and is
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Glauber Costa's avatar
      x86: use matching CFI_ENDPROC · 557d7d4e
      Glauber Costa authored
      The RING0_INT_FRAME macro defines a CFI_STARTPROC.
      So we should really be using CFI_ENDPROC after it.
      Signed-off-by: default avatarGlauber Costa <gcosta@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>