16 Feb, 2011

1 commit

  • The hardware seems to have a race condition when the inactive
    channels are in slave mode. We support master mode only, so
    we can just switch all channels to master mode.

    Signed-off-by: Sascha Hauer
    [ukleinek: add more verbose comment about the race]
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Grant Likely

    Sascha Hauer
     

13 Jan, 2011

1 commit


08 Jan, 2011

1 commit


24 Dec, 2010

1 commit


11 Oct, 2010

1 commit

  • The i.MX51 ECSPI has a fifo size of 64 entries instead of 8 entries as
    found on the other cspi bus devices.

    Cc: Jason Wang
    Signed-off-by: David Jander
    Signed-off-by: Sascha Hauer
    Signed-off-by: Uwe Kleine-König
    Acked-by: Grant Likely
    Signed-off-by: Sascha Hauer

    David Jander
     

01 Oct, 2010

4 commits

  • i.MX51 comes with two eCSPI interfaces (that are quite different from
    what was known before---the tried and tested Freescale way) and a CSPI
    interface that is identical to the devices found on i.MX25 and i.MX35.

    This patch is a merge of two very similar patches (by Jason Wang and Sascha
    Hauer resp.) plus a (now hopefully correct) reimplementation of the
    clock calculation.

    Acked-by: Jason Wang
    Acked-by: Grant Likely
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Sascha Hauer

    Uwe Kleine-König
     
  • This prepares adding support for imx51's eCSPI. This IP has seperate
    control and config bits for all four supported chip selects, so the
    config routine needs to know which chip select is being used even if
    the chipselect is realized by a gpio.

    Acked-by: Jason Wang
    Acked-by: Grant Likely
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Sascha Hauer

    Uwe Kleine-König
     
  • Nearly everything that is needed is provided by the version of the SPI IP.
    Now the only checks left using cpu_is_... are clk divider tuning on mx21/mx27
    and autodetection (which will die soon).

    Acked-by: Jason Wang
    Acked-by: Grant Likely
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Sascha Hauer

    Uwe Kleine-König
     
  • This has the advantage not to need to much cpu_is_... macros. Still more
    when imx51 support is added which has two different spi interfaces which
    would introduce additional checks on the device id.

    With this setup it's not possible for the compiler anymore to detect the
    unused functions, so four additional kconfig symbols are introduced to
    ifdef out the unneeded functions in the callback array and all these
    functions are marked with __maybe_unused to suppress the corresponding
    gcc warnings.

    Comparing the driver footprint with and without the patch for a mx27
    kernel yields:

    add/remove: 2/0 grow/shrink: 2/0 up/down: 280/0 (280)
    function old new delta
    spi_imx_devtype - 192 +192
    spi_imx_probe 980 1032 +52
    spi_imx_devtype_data - 32 +32
    spi_imx_setupxfer 276 280 +4

    Later when the platform code is updated to use the platform ids, the
    autodetection can be removed which will make the driver a bit smaller
    again. (~60 Bytes in my test.)

    Acked-by: Jason Wang
    Acked-by: Grant Likely
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Sascha Hauer

    Uwe Kleine-König
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

21 Jan, 2010

1 commit


13 Dec, 2009

5 commits


09 Dec, 2009

2 commits

  • i.MX35-provided chipselects are represented using negative numbers. If
    gpio_request() fails and the previous chipselect was a negative number,
    the while loop is endless (i is never decremented).

    Also, the error loop would never call gpio_free on chipselect[0].

    And finally, the error message was missing an endline.

    Signed-off-by: John Ogness
    Signed-off-by: Grant Likely

    John Ogness
     
  • On the MX31litekit, the bootloader seems to communicate with the MC13783
    PMIC chip before booting Linux. However, it does not flush all the
    buffers properly after that, which makes the imx-spi driver read
    bogus data when probing the MC13783.

    Fix that by draining the SPI receive buffer on startup.

    Signed-off-by: Daniel Mack
    Acked-by: Uwe Kleine-König
    Signed-off-by: Grant Likely

    Daniel Mack
     

02 Oct, 2009

7 commits


23 Sep, 2009

1 commit

  • This driver is in a non working state at the moment and will be replaced
    by a bitbang driver which can also handle the newer i.MX variants

    Signed-off-by: Sascha Hauer
    Cc: Guennadi Liakhovetski
    Acked-by: David Brownell
    Acked-by: Andrea Paterniani
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sascha Hauer
     

19 Jun, 2009

2 commits

  • Move some common spi_setup() error checks into the SPI framework from the
    spi_master controller drivers:

    - Add a new "mode_bits" field to spi_master

    - Use that in spi_setup to validate the spi->mode value being
    requested. Setting this new field is now mandatory for any
    controller supporting more than vanilla SPI_MODE_0.

    - Update all spi_master drivers to:

    * Initialize that field
    * Remove current spi_setup() checks using that value.

    This is a net minor code shrink.

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

    David Brownell
     
  • Start moving some spi_setup() functionality into the SPI core from the
    various spi_master controller drivers:

    - Make that function stop being an inline;

    - Move two common idioms from drivers into that new function:
    * Default bits_per_word to 8 if that field isn't set
    * Issue a standardized dev_dbg() message

    This is a net minor source code shrink, and supports enhancments found in
    some follow-up patches.

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

    David Brownell
     

07 Apr, 2009

2 commits


25 Mar, 2009

1 commit


02 Dec, 2008

1 commit

  • Corrects spi_imx driver oops during initialization/probing: can't use
    drv_data before it's allocated.

    Signed-off-by: Julien Boibessot
    Acked-by: Sascha Hauer
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Julien Boibessot
     

20 Nov, 2008

1 commit

  • Fix unsafe order in dma mapping operation: always flush data from the
    cache *BEFORE* invalidating it, to allow full duplex transfers where the
    same buffer may be used for both writes and reads.

    Signed-off-by: Andrea Paterniani
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrea Paterniani
     

07 Aug, 2008

2 commits


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
     

10 Jul, 2008

1 commit


05 Jul, 2008

1 commit


03 Jul, 2008

1 commit


28 Apr, 2008

1 commit

  • Updates to the i.MX SPI controller driver:

    1) Some comments changed and/or added.

    2) End of transfers is now managed on TXFIFO empty interrupt after the
    last write to TXFIFO. This speeds interrupt execution by removing
    the wait for TXFIFO to become empty. On TXFIFO empty interrupt the
    handler needs only to poll for the end of the ongoing transaction
    (SPI_CONTROL_XCH) to close the transfer.
    (2.1) Write only transfers are closed flushing RXFIFO.
    (2.2) Read transfers are closed reading trailing bytes from RXFIFO.
    (2.3) Read transfers where RXFIFO overrun occurred are closed by
    flushing RXFIFO and aborting the message.

    3) Fifos are now flushed via SPI disable after the end of ongoing
    transaction.

    Signed-off-by: Andrea Paterniani
    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrea Paterniani