1. 03 2月, 2011 1 次提交
  2. 22 12月, 2010 1 次提交
  3. 16 7月, 2010 1 次提交
  4. 13 1月, 2010 1 次提交
  5. 28 11月, 2009 1 次提交
  6. 25 11月, 2009 1 次提交
  7. 03 10月, 2009 1 次提交
  8. 25 3月, 2009 1 次提交
  9. 23 3月, 2009 1 次提交
    • E
      [ARM] pxa: add base support for Marvell's PXA168 processor line · 49cbe786
      Eric Miao 提交于
      """The Marvell® PXA168 processor is the first in a family of application
      processors targeted at mass market opportunities in computing and consumer
      devices. It balances high computing and multimedia performance with low
      power consumption to support extended battery life, and includes a wealth
      of integrated peripherals to reduce overall BOM cost .... """
      
      See http://www.marvell.com/featured/pxa168.jsp for more information.
      
        1. Marvell Mohawk core is a hybrid of xscale3 and its own ARM core,
           there are many enhancements like instructions for flushing the
           whole D-cache, and so on
      
        2. Clock reuses Russell's common clkdev, and added the basic support
           for UART1/2.
      
        3. Devices are a bit different from the 'mach-pxa' way, the platform
           devices are now dynamically allocated only when necessary (i.e.
           when pxa_register_device() is called). Description for each device
           are stored in an array of 'struct pxa_device_desc'. Now that:
      
           a. this array of device description is marked with __initdata and
              can be freed up system is fully up
      
           b. which means board code has to add all needed devices early in
              his initializing function
      
           c. platform specific data can now be marked as __initdata since
              they are allocated and copied by platform_device_add_data()
      
        4. only the basic UART1/2/3 are added, more devices will come later.
      Signed-off-by: NJason Chagas <chagas@marvell.com>
      Signed-off-by: NEric Miao <eric.miao@marvell.com>
      49cbe786
  10. 16 3月, 2009 1 次提交
    • N
      [ARM] kmap support · d73cd428
      Nicolas Pitre 提交于
      The kmap virtual area borrows a 2MB range at the top of the 16MB area
      below PAGE_OFFSET currently reserved for kernel modules and/or the
      XIP kernel.  This 2MB corresponds to the range covered by 2 consecutive
      second-level page tables, or a single pmd entry as seen by the Linux
      page table abstraction.  Because XIP kernels are unlikely to be seen
      on systems needing highmem support, there shouldn't be any shortage of
      VM space for modules (14 MB for modules is still way more than twice the
      typical usage).
      
      Because the virtual mapping of highmem pages can go away at any moment
      after kunmap() is called on them, we need to bypass the delayed cache
      flushing provided by flush_dcache_page() in that case.
      
      The atomic kmap versions are based on fixmaps, and
      __cpuc_flush_dcache_page() is used directly in that case.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      d73cd428
  11. 25 9月, 2008 1 次提交
  12. 10 7月, 2008 1 次提交
    • E
      [ARM] pxa: add support for L2 outer cache on XScale3 · 20072fd0
      Eric Miao 提交于
      The initial patch from Lothar, and Lennert make it into a cleaner
      one, modified and tested on PXA320 by Eric Miao.
      
      This patch moves the L2 cache operations out of proc-xsc3.S into
      dedicated outer cache support code.
      
      CACHE_XSC3L2 can be deselected so no L2 cache specific code will be
      linked in, and that L2 enable bit will not be set, this applies to
      the following cases:
      
          a. _only_ PXA300/PXA310 support included and no L2 cache wanted
          b. PXA320 support included, but want L2 be disabled
      
      So the enabling of L2 depends on two things:
      
          - CACHE_XSC3L2 is selected
          - and L2 cache is present
      
      Where the latter is only a safeguard (previous testing shows it works
      OK even when this bit is turned on).
      
      IXP series of processors with XScale3 cannot disable L2 cache for the
      moment since they depend on the L2 cache for its coherent memory, so
      IXP may always select CACHE_XSC3L2.
      
      Other L2 relevant bits are always turned on (i.e. the original code
      enclosed by #if L2_CACHE_ENABLED .. #endif), as they showed no side
      effects. Specifically, these bits are:
      
         - OC bits in TTBASE register (table walk outer cache attributes)
         - LLR Outer Cache Attributes (OC) in Auxiliary Control Register
      Signed-off-by: NLothar WaÃ&lt;9f&gt;mann <LW@KARO-electronics.de>
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NEric Miao <eric.miao@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      20072fd0
  13. 23 6月, 2008 1 次提交
    • L
      [ARM] Feroceon: L2 cache support · 99c6dc11
      Lennert Buytenhek 提交于
      This patch adds support for the unified Feroceon L2 cache controller
      as found in e.g. the Marvell Kirkwood and Marvell Discovery Duo
      families of ARM SoCs.
      
      Note that:
      
      - Page table walks are outer uncacheable on Kirkwood and Discovery
        Duo, since the ARMv5 spec provides no way to indicate outer
        cacheability of page table walks (specifying it in TTBR[4:3] is
        an ARMv6+ feature).
      
        This requires adding L2 cache clean instructions to
        proc-feroceon.S (dcache_clean_area(), set_pte()) as well as to
        tlbflush.h ({flush,clean}_pmd_entry()).  The latter case is handled
        by defining a new TLB type (TLB_FEROCEON) which is almost identical
        to the v4wbi one but provides a TLB_L2CLEAN_FR flag.
      
      - The Feroceon L2 cache controller supports L2 range (i.e. 'clean L2
        range by MVA' and 'invalidate L2 range by MVA') operations, and this
        patch uses those range operations for all Linux outer cache
        operations, as they are faster than the regular per-line operations.
      
        L2 range operations are not interruptible on this hardware, which
        avoids potential livelock issues, but can be bad for interrupt
        latency, so there is a compile-time tunable (MAX_RANGE_SIZE) which
        allows you to select the maximum range size to operate on at once.
        (Valid range is between one cache line and one 4KiB page, and must
        be a multiple of the line size.)
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      99c6dc11
  14. 29 4月, 2008 1 次提交
  15. 26 1月, 2008 1 次提交
  16. 30 5月, 2007 1 次提交
  17. 09 5月, 2007 1 次提交
  18. 12 2月, 2007 1 次提交
  19. 29 9月, 2006 1 次提交
  20. 28 9月, 2006 5 次提交
  21. 27 9月, 2006 2 次提交
  22. 20 9月, 2006 1 次提交
  23. 29 6月, 2006 3 次提交
  24. 29 3月, 2006 1 次提交
    • L
      [ARM] 3377/2: add support for intel xsc3 core · 23bdf86a
      Lennert Buytenhek 提交于
      Patch from Lennert Buytenhek
      
      This patch adds support for the new XScale v3 core.  This is an
      ARMv5 ISA core with the following additions:
      
      - L2 cache
      - I/O coherency support (on select chipsets)
      - Low-Locality Reference cache attributes (replaces mini-cache)
      - Supersections (v6 compatible)
      - 36-bit addressing (v6 compatible)
      - Single instruction cache line clean/invalidate
      - LRU cache replacement (vs round-robin)
      
      I attempted to merge the XSC3 support into proc-xscale.S, but XSC3
      cores have separate errata and have to handle things like L2, so it
      is simpler to keep it separate.
      
      L2 cache support is currently a build option because the L2 enable
      bit must be set before we enable the MMU and there is no easy way to
      capture command line parameters at this point.
      
      There are still optimizations that can be done such as using LLR for
      copypage (in theory using the exisiting mini-cache code) but those
      can be addressed down the road.
      Signed-off-by: NDeepak Saxena <dsaxena@plexity.net>
      Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      23bdf86a
  25. 19 11月, 2005 1 次提交
    • D
      [ARM] 3168/1: Update ARM signal delivery and masking · a6c61e9d
      Daniel Jacobowitz 提交于
      Patch from Daniel Jacobowitz
      
      After delivering a signal (creating its stack frame) we must check for
      additional pending unblocked signals before returning to userspace.
      Otherwise signals may be delayed past the next syscall or reschedule.
      
      Once that was fixed it became obvious that the ARM signal mask manipulation
      was broken.  It was a little bit broken before the recent SA_NODEFER
      changes, and then very broken after them.  We must block the requested
      signals before starting the handler or the same signal can be delivered
      again before the handler even gets a chance to run.
      Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a6c61e9d
  26. 08 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