linux-toradex.git/drivers/spi, branch v2.6.28.9

spi: fix spi_s3c24xx_gpio num_chipselect

2008-12-02T03:55:24+00:00

The spi master driver must have num_chipselect set to allow the bus to
initialise.  Pass this through the platform data.

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

spi: fix spi_s3c24xx_gpio device handle lookup

2008-12-02T03:55:24+00:00

The spidev_to_sg() call in spi_s3c24xx_gpio.c was using the wrong method
to convert the spi device into the private data for the driver.  Fix this
by using spi_master_get_devdata.

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

spi: au1550_spi full duplex dma fix

2008-12-02T03:55:24+00:00

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.  Tested with mmc-spi.

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

spi: fix spi_imx probe oopsing

2008-12-02T03:55:24+00:00

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

spi: mpc52xx_psc_spi chipselect bugfix

2008-12-02T03:55:24+00:00

According to the manual the "tdfOnExit" flag must be set on the last byte
we want to send.  The PSC controller holds SS low until the flag is set.

However, the flag was set always on the last byte of the FIFO,
independently if it is the last byte of the transfer.  This generates
spurious toggling of the SS signals that breaks the protocol of some
peripherals.  Fix.

Signed-off-by: Stefano Babic 
Acked-by: Grant Likely 
Signed-off-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

spi: avoid spidev crash when device is removed

2008-12-02T03:55:24+00:00

I saw a kernel oops in spidev_remove() when a spidev device was registered
and I unloaded the SPI master driver:

Unable to handle kernel paging request for data at address 0x00000004
Faulting instruction address: 0xc01c0c50
Oops: Kernel access of bad area, sig: 11 [#1]
CDSPR
Modules linked in: spi_ppc4xx(-)
NIP: c01c0c50 LR: c01bf9e4 CTR: c01c0c34
REGS: cec89c30 TRAP: 0300   Not tainted  (2.6.27.3izt)
MSR: 00021000   CR: 24000228  XER: 20000007
DEAR: 00000004, ESR: 00800000
TASK = cf889040[2070] 'rmmod' THREAD: cec88000
GPR00: 00000000 cec89ce0 cf889040 cec8e000 00000004 cec8e000 ffffffff 00000000
GPR08: 0000001c c0336380 00000000 c01c0c34 00000001 1001a338 100e0000 100df49c
GPR16: 100b54c0 100df49c 100ddd20 100f05a8 100b5340 100efd68 00000000 00000000
GPR24: 100ec008 100f0428 c0327788 c0327794 cec8e0ac cec8e000 c0336380 00000000
NIP [c01c0c50] spidev_remove+0x1c/0xe4
LR [c01bf9e4] spi_drv_remove+0x2c/0x3c
Call Trace:
[cec89d00] [c01bf9e4] spi_drv_remove+0x2c/0x3c
[cec89d10] [c01859a0] __device_release_driver+0x78/0xb4
[cec89d20] [c0185ab0] device_release_driver+0x28/0x44
[cec89d40] [c0184be8] bus_remove_device+0xac/0xd8
[cec89d60] [c0183094] device_del+0x100/0x194
[cec89d80] [c0183140] device_unregister+0x18/0x30
[cec89da0] [c01bf30c] __unregister+0x20/0x34
[cec89db0] [c0182778] device_for_each_child+0x38/0x74
[cec89de0] [c01bf2d0] spi_unregister_master+0x28/0x44
[cec89e00] [c01bfeac] spi_bitbang_stop+0x1c/0x58
[cec89e20] [d908a5e0] spi_ppc4xx_of_remove+0x24/0x7c [spi_ppc4xx]
[...]

IMHO a call to spi_set_drvdata() is missing in spidev_probe(). The patch
below helped.

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

spi_imx: full duplex dma corruption bugfix

2008-11-20T02:49:58+00:00

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

pxa2xx_spi: bugfix full duplex dma data corruption

2008-11-20T02:49:58+00:00

Fixes a data corruption bug in pxa2xx_spi.c when operating in full duplex
mode with DMA and using buffers that overlap.

SPI transmit and receive buffers are allowed to be the same or to overlap.
 However, this driver fails if such overlap is attempted in DMA mode
because it maps the rx and tx buffers in the wrong order.  By mapping
DMA_FROM_DEVICE (read) before DMA_TO_DEVICE (write), it invalidates the
cache before flushing it, thus discarding data which should have been
transmitted.

The patch corrects the order of mapping.  This bug exists in all versions
of pxa2xx_spi.c; similar bugs are in the drivers for two other SPI
controllers (au1500, imx).

A version of this patch has been tested on kernel 2.6.20 using
verification of loopback data with: random transfer length, random
bits-per-word, random positive offsets (both larger and smaller than
transfer length) between the start of the rx and tx buffers, and varying
clock rates.

Signed-off-by: Ned Forrester 
Cc: Vernon Sauder 
Cc: J. Scott Merritt 
Signed-off-by: David Brownell 
Cc: 		[2.6.27.x]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

atmel_spi: work-around required for new HW bug in AT91SAM9263 Rev.B SPI controller

2008-11-13T01:17:17+00:00

We're working with an AT91SAM9263 Rev B in our design and I experienced
some inconsistency in spi-based touchscreen usage between our board and
the Atmel evaluation kit we have that runs on a Rev A chip.

The data was apparently delayed by 1 byte and got ridiculous data out of
the touchscreen driver, very strange.  As everything looked normal in
the spi, touchscreen and dma logs, I contacted the Atmel support and
they triggered me on a new HW bug that appeared in the Rev B SPI
controller.

The problem is that the SPI controller on the Rev B needs that the
software reset is performed two times so that it's performed correctly.

Applying the patch below solves the issue on my Rev B board.  I've tested
it as well on my Rev A evaluation kit and it has apparently no unwanted
side effect, things continue to work as expected.

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

Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6

2008-10-16T19:40:26+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6: (46 commits)
  UIO: Fix mapping of logical and virtual memory
  UIO: add automata sercos3 pci card support
  UIO: Change driver name of uio_pdrv
  UIO: Add alignment warnings for uio-mem
  Driver core: add bus_sort_breadthfirst() function
  NET: convert the phy_device file to use bus_find_device_by_name
  kobject: Cleanup kobject_rename and !CONFIG_SYSFS
  kobject: Fix kobject_rename and !CONFIG_SYSFS
  sysfs: Make dir and name args to sysfs_notify() const
  platform: add new device registration helper
  sysfs: use ilookup5() instead of ilookup5_nowait()
  PNP: create device attributes via default device attributes
  Driver core: make bus_find_device_by_name() more robust
  usb: turn dev_warn+WARN_ON combos into dev_WARN
  debug: use dev_WARN() rather than WARN_ON() in device_pm_add()
  debug: Introduce a dev_WARN() function
  sysfs: fix deadlock
  device model: Do a quickcheck for driver binding before doing an expensive check
  Driver core: Fix cleanup in device_create_vargs().
  Driver core: Clarify device cleanup.
  ...