1. 17 5月, 2006 2 次提交
  2. 14 1月, 2006 2 次提交
    • V
      [PATCH] spi: use linked lists rather than an array · 8275c642
      Vitaly Wool 提交于
      This makes the SPI core and its users access transfers in the SPI message
      structure as linked list not as an array, as discussed on LKML.
      
      From: David Brownell <dbrownell@users.sourceforge.net>
      
        Updates including doc, bugfixes to the list code, add
        spi_message_add_tail().  Plus, initialize things _before_ grabbing the
        locks in some cases (in case it grows more expensive).  This also merges
        some bitbang updates of mine that didn't yet make it into the mm tree.
      Signed-off-by: NVitaly Wool <vwool@ru.mvista.com>
      Signed-off-by: NDmitry Pervushin <dpervushin@gmail.com>
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8275c642
    • D
      [PATCH] spi: add spi_bitbang driver · 9904f22a
      David Brownell 提交于
      This adds a bitbanging spi master, hooking up to board/adapter-specific glue
      code which knows how to set and read the signals (gpios etc).
      
      This code kicks in after the glue code creates a platform_device with the
      right platform_data.  That data includes I/O loops, which will usually
      come from expanding an inline function (provided in the header).  One goal
      is that the I/O loops should be easily optimized down to a few GPIO register
      accesses, in common cases, for speed and minimized overhead.
      
      This understands all the currently defined protocol tweaking options in the
      SPI framework, and might eventually serve as as reference implementation.
      
        - different word sizes (1..32 bits)
        - differing clock rates
        - SPI modes differing by CPOL (affecting chip select and I/O loops)
        - SPI modes differing by CPHA (affecting I/O loops)
        - delays (usecs) after transfers
        - temporarily deselecting chips in mid-transfer
      
      A lot of hardware could work with this framework, though common types of
      controller can't reach peak performance without switching to a driver
      structure that supports pipelining of transfers (e.g.  DMA queues) and maybe
      controllers (e.g.  IRQ driven).
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9904f22a