1. 24 8月, 2009 2 次提交
    • S
      sh: Optimise memcpy_to/fromio for SH4 · 5e9377ec
      Stuart Menefy 提交于
      Optimise memcpy_to/fromio. This is used extensivly by MTD, so is a
      worthwhile performance gain. The main savings come from not repeatedly
      calling readl/writel, and doing word instead of byte at a time
      transfers. Also using "movca.l" on SH4 gives a small performance win.
      Signed-off-by: NStuart Menefy <stuart.menefy@st.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      5e9377ec
    • D
      sh: Allow use of GENERIC_IOMAP · 15444a89
      David McKay 提交于
      The synopsys PCI cell used in the later STMicro chips requires code to
      be run in order to do IO cycles, rather than just memory mapping the IO
      space. Rather than extending the existing SH infrastructure to allow
      this, use the GENERIC_IOMAP implmentation to save re-inventing the
      wheel.
      
      This set of changes allows the SH to be built with GENERIC_IOMAP
      enabled, it just ifdef's out the functions provided by the GENERIC_IOMAP
      implementation, and provides a few required missing functions.
      Signed-off-by: NDavid McKay <david.mckay@st.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      15444a89
  2. 20 4月, 2009 1 次提交
  3. 16 4月, 2009 1 次提交
  4. 04 10月, 2008 1 次提交
    • P
      sh: More I/O routine overhauling. · 14866543
      Paul Mundt 提交于
      This tidies up a lot of the PIO/MMIO split. No in-tree platforms were
      making use of the MMIO overloading through the machvec (nor have any of
      them been in some time), so we just kill all of that off. The ISA I/O
      routine wrapping remains unaffected, which remains the only special
      casing outside of the iomap API that boards need to think about.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      14866543
  5. 14 2月, 2008 1 次提交
    • M
      sh: trapped io support V2 · e7cc9a73
      Magnus Damm 提交于
      The idea is that we want to get rid of the in/out/readb/writeb callbacks from
      the machvec and replace that with simple inline read and write operations to
      memory. Fast and simple for most hardware devices (think pci).
      
      Some devices require special treatment though - like 16-bit only CF devices -
      so we need to have some method to hook in callbacks.
      
      This patch makes it possible to add a per-device trap generating filter. This
      way we can get maximum performance of sane hardware - which doesn't need this
      filter - and crappy hardware works but gets punished by a performance hit.
      
      V2 changes things around a bit and replaces io access callbacks with a
      simple minimum_bus_width value. In the future we can add stride as well.
      Signed-off-by: NMagnus Damm <damm@igel.co.jp>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      e7cc9a73
  6. 28 1月, 2008 1 次提交
  7. 27 9月, 2006 1 次提交
  8. 17 1月, 2006 1 次提交
    • P
      [PATCH] sh: I/O routine cleanups and ioremap() overhaul · b66c1a39
      Paul Mundt 提交于
      This introduces a few changes in the way that the I/O routines are defined on
      SH, specifically so that things like the iomap API properly wrap through the
      machvec for board-specific quirks.
      
      In addition to this, the old p3_ioremap() work is converted to a more generic
      __ioremap() that will map through the PMB if it's available, or fall back on
      page tables for everything else.
      
      An alpha-like IO_CONCAT is also added so we can start to clean up the
      board-specific io.h mess, which will be handled in board update patches..
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b66c1a39
  9. 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