14 Sep, 2008

5 commits

  • Fix the section mismatch warning generated by the incorrect naming of
    s3c24xx_spidrv which should be s3c24xx_spi_driver:

    WARNING: drivers/spi/spi_s3c24xx.o(.data+0x4):
    Section mismatch in reference from the variable s3c24xx_spidrv
    to the (unknown reference) .exit.text:(unknown)

    Signed-off-by: Ben Dooks
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ben Dooks
     
  • Fixes two DMA bugs in the pxa2xx_spi driver. The first bug is in all
    versions of this driver; the second was introduced in the 2.6.20 kernel,
    and prevents using the driver with chips like m25p16 flash (which can
    issue large DMA reads).

    1. Zero length transfers are permitted for use to insert timing,
    but pxa2xx_spi.c will fail if this is requested in DMA mode.
    Fixed by using programmed I/O (PIO) mode for such transfers.

    2. Transfers larger than 8191 are not permitted in DMA mode. A
    test for length rejects all large transfers regardless of DMA
    or PIO mode. Worked around by rejecting only large transfers
    with DMA mapped buffers, and forcing all other transfers
    larger than 8191 to use PIO mode. A rate limited warning is
    issued for DMA transfers forced to PIO mode.

    This patch should apply to all kernels back to and including 2.6.20;
    it was test patched against 2.6.20. An additional patch would be
    required for older kernels, but those versions are very buggy anyway.

    Signed-off-by: Ned Forrester
    Cc: Vernon Sauder
    Cc: Eric Miao
    Signed-off-by: David Brownell
    Cc: [2.6.25.x, 2.6.26.x]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ned Forrester
     
  • Fixes several chipselect bugs in the pxa2xx_spi driver. These bugs are in
    all versions of this driver and prevent using it with chips like m25p16
    flash.

    1. The spi_transfer.cs_change flag is handled too early:
    before spi_transfer.delay_usecs applies, thus making the
    delay ineffective at holding chip select.

    2. spi_transfer.delay_usecs is ignored on the last transfer
    of a message (likewise not holding chipselect long enough).

    3. If spi_transfer.cs_change is set on the last transfer, the
    chip select is always disabled, instead of the intended
    meaning: optionally holding chip select enabled for the
    next message.

    Those first three bugs were fixed with a relocation of delays
    and chip select de-assertions.

    4. If a message has the cs_change flag set on the last transfer,
    and had the chip select stayed enabled as requested (see 3,
    above), it would not have been disabled if the next message is
    for a different chip. Fixed by dropping chip select regardless
    of cs_change at end of a message, if there is no next message
    or if the next message is for a different chip.

    This patch should apply to all kernels back to and including 2.6.20;
    it was test patched against 2.6.20. An additional patch would be
    required for older kernels, but those versions are very buggy anyway.

    Signed-off-by: Ned Forrester
    Cc: Vernon Sauder
    Cc: Eric Miao
    Signed-off-by: David Brownell
    Cc: [2.6.25.x, 2.6.26.x]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ned Forrester
     
  • Error out on transfer length != multiple of bytes per word with -EINVAL.
    Fixes a buffer overrun crash if length < bytes per word.

    Signed-off-by: Peter Korsgaard
    Acked-by: Joakim Tjernlund
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Korsgaard
     
  • Commit a61f5345 (spi_mpc83xx clockrate fixes) broke clockrate calculation
    for low speeds. SPMODE_DIV16 should be set if the divider is higher than
    64, not only if the divider gets clipped to 1024.

    Furthermore, the clipping check was off by a factor 16 as well.

    Signed-off-by: Peter Korsgaard
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Korsgaard
     

15 Aug, 2008

1 commit

  • When reviewing a recent patch I noticed a potential trouble spot in the
    registration of new SPI devices. The SPI master driver is told to set
    the device up before adding it to the driver model, so that it's always
    properly set up when probe() is called. (This is important, because in
    the case of inverted chipselects, this device can make the bus misbehave
    until it's properly deselected. It's got to be set up even if no driver
    binds to the device.)

    The trouble spot is that it doesn't first verify that no other device
    has been added using that chipselect. If such a device has been added,
    its configuration gets trashed. (Fortunately this has not been a common
    error!)

    The fix here adds an explicit check, and a mutex to protect the relevant
    critical region.

    [akpm@linux-foundation.org: make the lock local to spi_add_device()]
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

07 Aug, 2008

3 commits


06 Aug, 2008

1 commit

  • This adds an SPI driver for the SPI controller found in various Marvell
    Orion ARM SoCs. It currently supports only one slave, which must use SPI
    mode 0.

    [dbrownell@users.sourceforge.net: cleanups, meet specs, pass "sparse"]
    Signed-off-by: Shadi Ammouri
    Signed-off-by: Saeed Bishara
    Signed-off-by: Lennert Buytenhek
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Shadi Ammouri
     

05 Aug, 2008

2 commits

  • For some time my at91sam9260 board with JFFS2 on serial flash (m25p80)
    would hang when accessing the serial flash and SPI bus. Slowing the SPI
    clock down to 9 MHz reduced the occurrence of the hang from "always"
    during boot to a nuisance level that allowed other SW development to
    continue. Finally had to address this issue when an application stresses
    the I/O to always cause a hang.

    Hang seems to be caused by a missed SPI interrupt, so that the task ends
    up waiting forever after calling spi_sync(). The fix has 2 parts. First
    is to halt the DMA engine before the "current" PDC registers are loaded.
    This ensures that the "next" registers are loaded before the DMA operation
    takes off. The second part of the fix is a kludge that adds a
    "completion" interrupt in case the ENDRX interrupt for the last segment of
    the DMA chaining operation was missed.

    The patch allows the SPI clock for the serial flash to be increased from 9
    MHz to 15 MHz (or more?). No hangs or SPI overruns were encountered.

    Haavard: while this patch does indeed improve things, I still see overruns
    and CRC errors on my NGW100 board when running the DataFlash at 10 MHz.
    However, I think some improvement is better than nothing, so I'm passing
    this on for inclusion in 2.6.27.

    Signed-off-by: Gerard Kam
    Signed-off-by: Haavard Skinnemoen
    Cc: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Gerard Kam
     
  • Fix a bug in the spi_s3c24xx driver where it does not reset the registers
    of the hardware when resuming from suspend (this block has been reset over
    suspend).

    Signed-off-by: Ben Dooks
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ben Dooks
     

29 Jul, 2008

2 commits

  • The original "Pass the bus number we expect the S3C24XX SPI driver to
    attach to via the platform data." [1] patch was mis-sent, and missed two
    important parts of the diff, which was to actually set the bus_num field
    and add the relevant field to the platform data.

    The previous commit 50f426b55d919dd017af35bb6a08753d1f262920 promised to
    add a bus_num field, but failed to include the two hunks that added this
    field to include/asm-arm/arch-s3c2410/spi.h and then pass it to the spi
    core when creating the new master field in drivers/spi/spi_s3c24xx.c.

    [1] git commit 50f426b55d919dd017af35bb6a08753d1f262920

    Signed-off-by: Ben Dooks
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ben Dooks
     
  • The block transfer routine in the mpc52xx psc spi driver misinterpret
    the datasheet. According to the processor datasheet the chipselect is
    held as long as the EOF is not written.

    Theoretically blocks of any sizes can be transferred in this way. The
    old routine however writes an EOF after every word, which has the size
    of size_of_word. This makes the transfer slow.

    Also fixed some duplicate code.

    Signed-off-by: Luotao Fu
    Signed-off-by: David Brownell
    Cc: [2.6.25.x, 2.6.26.x]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Luotao Fu
     

28 Jul, 2008

1 commit


27 Jul, 2008

1 commit

  • Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
    architecture does:

    This enables us to cleanly fix the Calgary IOMMU issue that some devices
    are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).

    I think that per-device dma_mapping_ops support would be also helpful for
    KVM people to support PCI passthrough but Andi thinks that this makes it
    difficult to support the PCI passthrough (see the above thread). So I
    CC'ed this to KVM camp. Comments are appreciated.

    A pointer to dma_mapping_ops to struct dev_archdata is added. If the
    pointer is non NULL, DMA operations in asm/dma-mapping.h use it. If it's
    NULL, the system-wide dma_ops pointer is used as before.

    If it's useful for KVM people, I plan to implement a mechanism to register
    a hook called when a new pci (or dma capable) device is created (it works
    with hot plugging). It enables IOMMUs to set up an appropriate
    dma_mapping_ops per device.

    The major obstacle is that dma_mapping_error doesn't take a pointer to the
    device unlike other DMA operations. So x86 can't have dma_mapping_ops per
    device. Note all the POWER IOMMUs use the same dma_mapping_error function
    so this is not a problem for POWER but x86 IOMMUs use different
    dma_mapping_error functions.

    The first patch adds the device argument to dma_mapping_error. The patch
    is trivial but large since it touches lots of drivers and dma-mapping.h in
    all the architecture.

    This patch:

    dma_mapping_error() doesn't take a pointer to the device unlike other DMA
    operations. So we can't have dma_mapping_ops per device.

    Note that POWER already has dma_mapping_ops per device but all the POWER
    IOMMUs use the same dma_mapping_error function. x86 IOMMUs use device
    argument.

    [akpm@linux-foundation.org: fix sge]
    [akpm@linux-foundation.org: fix svc_rdma]
    [akpm@linux-foundation.org: build fix]
    [akpm@linux-foundation.org: fix bnx2x]
    [akpm@linux-foundation.org: fix s2io]
    [akpm@linux-foundation.org: fix pasemi_mac]
    [akpm@linux-foundation.org: fix sdhci]
    [akpm@linux-foundation.org: build fix]
    [akpm@linux-foundation.org: fix sparc]
    [akpm@linux-foundation.org: fix ibmvscsi]
    Signed-off-by: FUJITA Tomonori
    Cc: Muli Ben-Yehuda
    Cc: Andi Kleen
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: Avi Kivity
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     

26 Jul, 2008

1 commit

  • spi_new_device() allocates and registers an spi device all in one swoop.
    If the driver needs to add extra data to the spi_device before it is
    registered, then this causes problems. This is needed for OF device
    tree support so that the SPI device tree helper can add a pointer to
    the device node after the device is allocated, but before the device
    is registered. OF aware SPI devices can then retrieve data out of the
    device node to populate a platform data structure.

    This patch splits the allocation and registration portions of code out
    of spi_new_device() and creates two new functions; spi_alloc_device()
    and spi_register_device(). spi_new_device() is modified to use the new
    functions for allocation and registration. None of the existing users
    of spi_new_device() should be affected by this change.

    Drivers using the new API can forego the use of spi_board_info
    structure to describe the device layout and populate data into the
    spi_device structure directly.

    This change is in preparation for adding an OF device tree parser to
    generate spi_devices based on data in the device tree.

    Signed-off-by: Grant Likely
    Acked-by: David Brownell

    Grant Likely
     

25 Jul, 2008

7 commits

  • Improve PIO transfer mode of au1550 spi controller by continuing of spi
    transfer, instead of aborting transfer when transmit underflow interrupt
    occurrs.

    Verified by oscilloscope that the spi clock pauses on trasmit underflow,
    so transfer continuation is perfectly valid even though au1550 datasheet
    says that on tx underflow zeroes will be transfered.

    Also make some error messages more specific.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Jan Nikitenko
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Nikitenko
     
  • Remove the Au1550 resource table and instead extract MMIO/IRQ/DMA
    resources from platform resource information like any well-behaved
    platform driver.

    Signed-off-by: Manuel Lauss
    Signed-off-by: Jan Nikitenko
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Manuel Lauss
     
  • Another step to removing ->ioctl and to removing the BKL

    [dbrownell@users.sourceforge.net: take final step; BKL not needed]
    Signed-off-by: Alan Cox
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alan Cox
     
  • Currently, 'modalias' in the spi_device structure is a 'const char *'.
    The spi_new_device() function fills in the modalias value from a passed in
    spi_board_info data block. Since it is a pointer copy, the new spi_device
    remains dependent on the spi_board_info structure after the new spi_device
    is registered (no other fields in spi_device directly depend on the
    spi_board_info structure; all of the other data is copied).

    This causes a problem when dynamically propulating the list of attached
    SPI devices. For example, in arch/powerpc, the list of SPI devices can be
    populated from data in the device tree. With the current code, the device
    tree adapter must kmalloc() a new spi_board_info structure for each new
    SPI device it finds in the device tree, and there is no simple mechanism
    in place for keeping track of these allocations.

    This patch changes modalias from a 'const char *' to a fixed char array.
    By copying the modalias string instead of referencing it, the dependency
    on the spi_board_info structure is eliminated and an outside caller does
    not need to maintain a separate spi_board_info allocation for each device.

    If searched through the code to the best of my ability for any references
    to modalias which may be affected by this change and haven't found
    anything. It has been tested with the lite5200b platform in arch/powerpc.

    [dbrownell@users.sourceforge.net: cope with linux-next changes: KOBJ_NAME_LEN obliterated, etc]
    Signed-off-by: Grant Likely
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Grant Likely
     
  • Use "if SPI_MASTER" to remove numerous dependencies.

    [dbrownell@users.sourceforge.net: remove a couple now-needless EXPERIMENTAL dependencies too]
    Signed-off-by: Robert P. J. Day
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Robert P. J. Day
     
  • xilinx_spi->irq is unsigned, so the test fails

    Signed-off-by: Roel Kluin
    Cc: David Brownell
    Cc: Andrei Konovalov
    Cc: Yuri Frolov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roel Kluin
     
  • This updates the SPI clock rate calculations for the spi_mpc83xx driver.
    Some boundary conditions were wrong, and in several cases divide-by-16
    wasn't always needed

    Signed-off-by: Chen Gong
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Chen Gong
     

22 Jul, 2008

2 commits


15 Jul, 2008

4 commits


13 Jul, 2008

1 commit


10 Jul, 2008

1 commit


05 Jul, 2008

2 commits

  • This patch introduces the clock API for i.MX and converts all
    in-Kernel drivers to use it.

    Signed-off-by: Sascha Hauer

    Sascha Hauer
     
  • This got broken by the recent "fix rmmod $spi_driver while spidev-user is
    active". I tested the rmmod & write path but didn't check the read path.
    I am sorry. The read logic changed and spidev_sync_read() +
    spidev_sync_write() do not return zero on success anymore but the number
    of bytes that has been transfered over the bus. This patch changes the
    logic and copy_to_user() gets called again.

    The write path returns the number of bytes which are written to the
    underlying device what may be less than the requested size. This patch
    makes the same change to the read path or else we request a read of 20
    bytes, get 10, don't call copy to user and report to the user that we read
    10 bytes.

    [akpm@linux-foundation.org: remove test of known-to-be-zero local]
    Signed-off-by: Sebastian Siewior
    Acked-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sebastian Siewior
     

03 Jul, 2008

1 commit


21 Jun, 2008

1 commit


07 Jun, 2008

1 commit

  • This addresses other oopsing paths in "spidev" by changing how it manages
    refcounting. It decouples the lifecycle of the per-device data from the
    class device (not just the spi device):

    - Use class_{create,destroy} not class_{register,unregister}.
    - Use device_{create,destroy} not device_{register,unregister}.
    - Free the per-device data only when TWO conditions are true:
    * Driver is unbound from underlying SPI device, and
    * Device is no longer open (new)

    Also, spi_{get,set}_drvdata not dev_{get,set}_drvdata for simpler code.

    Signed-off-by: David Brownell
    Sebastian Siewior
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

25 May, 2008

1 commit

  • Somehow the spidev code forgot to include a critical mechanism: when the
    underlying device is removed (e.g. spi_master rmmod), open file
    descriptors must be prevented from issuing new I/O requests to that
    device. On penalty of the oopsing reported by Sebastian Siewior
    ...

    This is a partial fix, adding handshaking between the lower level (SPI
    messaging) and the file operations using the spi_dev. (It also fixes an
    issue where reads and writes didn't return the number of bytes sent or
    received.)

    There's still a refcounting issue to be addressed (separately).

    Signed-off-by: David Brownell
    Reported-by: Sebastian Siewior
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

15 May, 2008

1 commit


13 May, 2008

1 commit

  • The current driver may cause glitches on SPI CLK line since one must disable
    the SPI controller before changing any HW settings. Fix this by implementing
    a local spi_transfer function that won't change speed and/or word size while
    CS is active.

    While doing that heavy lifting a few other issues were addressed too:
    - Make word size 16 and 32 work too.
    - Honor bits_per_word and speed_hz in spi transaction.
    - Optimize the common path.

    This also stops using the "bitbang" framework (except for a few constants).

    [Roel Kluin : "irq" needs to be signed]
    Signed-off-by: Joakim Tjernlund
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Joakim Tjernlund