1. 22 5月, 2006 3 次提交
  2. 17 5月, 2006 1 次提交
  3. 07 2月, 2006 1 次提交
  4. 14 1月, 2006 4 次提交
    • D
      [PATCH] SPI: add spi_butterfly driver · 2e10c84b
      David Brownell 提交于
      This adds a bitbanging parport based adaptor cable for AVR Butterfly, giving
      SPI links to its DataFlash chip and (eventually) firmware running in the card.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2e10c84b
    • D
      [PATCH] spi: misc fixes · 7111763d
      David Brownell 提交于
      This collects some small SPI patches that seem to be missing from the MM tree:
      
        - spi_butterfly kbuild hooks got dropped somehow; this restores them
        - quick fix for a (theoretical?) m25p80_write() oops noted by Andrew
        - quick fix for a potential config-specific oops for mtd_dataflash()
        - minor doc tweaks
      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>
      7111763d
    • 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
    • D
      [PATCH] spi: simple SPI framework · 8ae12a0d
      David Brownell 提交于
      This is the core of a small SPI framework, implementing the model of a
      queue of messages which complete asynchronously (with thin synchronous
      wrappers on top).
      
        - It's still less than 2KB of ".text" (ARM).  If there's got to be a
          mid-layer for something so simple, that's the right size budget.  :)
      
        - The guts use board-specific SPI device tables to build the driver
          model tree.  (Hardware probing is rarely an option.)
      
        - This version of Kconfig includes no drivers.  At this writing there
          are two known master controller drivers (PXA/SSP, OMAP MicroWire)
          and three protocol drivers (CS8415a, ADS7846, DataFlash) with LKML
          mentions of other drivers in development.
      
        - No userspace API.  There are several implementations to compare.
          Implement them like any other driver, and bind them with sysfs.
      
      The changes from last version posted to LKML (on 11-Nov-2005) are minor,
      and include:
      
        - One bugfix (removes a FIXME), with the visible effect of making device
          names be "spiB.C" where B is the bus number and C is the chipselect.
      
        - The "caller provides DMA mappings" mechanism now has kerneldoc, for
          DMA drivers that want to be fancy.
      
        - Hey, the framework init can be subsys_init.  Even though board init
          logic fires earlier, at arch_init ... since the framework init is
          for driver support, and the board init support uses static init.
      
        - Various additional spec/doc clarifications based on discussions
          with other folk.  It adds a brief "thank you" at the end, for folk
          who've helped nudge this framework into existence.
      
      As I've said before, I think that "protocol tweaking" is the main support
      that this driver framework will need to evolve.
      
      From: Mark Underwood <basicmark@yahoo.com>
      
        Update the SPI framework to remove a potential priority inversion case by
        reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
      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>
      8ae12a0d