Commit Graph

1822 Commits

Author SHA1 Message Date
Stephen Warren
4b92894ee7 spi: core: invert success test in devm_spi_register_master
devres_add() should be called when the action to be undone succeeded,
not when it failed. Fix the inverted test in devm_spi_register_master()
which was doing the opposite.

The user-visible issue without this fix is:
insmod spi-tegra114.ko
  Assume there's an MTD device on that SPI bus, which creates /dev/mtd0.
rmmod spi-tegra114
  Doesn't remove devices on the SPI bus.
insmod spi-tegra114.ko
  Creates a duplicate SPI device which creates /dev/mtd1.
hexdump -C /dev/mtd0
  That's the old device, which uses an SPI bus hosted by a non-existent
  module, which causes the oops below.

Unable to handle kernel paging request at virtual address bf0017c0
pgd = c0004000
[bf0017c0] *pgd=ad51b811, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
...
PC is at 0xbf0017c0
LR is at spi_pump_messages+0x15c/0x204
pc : [<bf0017c0>] lr : [<c02f0af8>] psr: 60000113
...

Fixes: 666d5b4c74 ("spi: core: Add devm_spi_register_master()")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-11-22 00:07:29 +00:00
Mark Brown
344a85117d Merge remote-tracking branch 'spi/topic/txx9' into spi-next 2013-10-25 09:51:41 +01:00
Mark Brown
605d427ccc Merge remote-tracking branch 'spi/topic/topcliff' into spi-next 2013-10-25 09:51:40 +01:00
Mark Brown
176c51c1e4 Merge remote-tracking branch 'spi/topic/tegra114' into spi-next 2013-10-25 09:51:40 +01:00
Mark Brown
f88df3a72c Merge remote-tracking branch 'spi/topic/tegra-slink' into spi-next 2013-10-25 09:51:39 +01:00
Mark Brown
5b380cb152 Merge remote-tracking branch 'spi/topic/tegra' into spi-next 2013-10-25 09:51:39 +01:00
Mark Brown
84b6146564 Merge remote-tracking branch 'spi/topic/s3c64xx' into spi-next 2013-10-25 09:51:38 +01:00
Mark Brown
d448121c4c Merge remote-tracking branch 'spi/topic/s3c24xx' into spi-next 2013-10-25 09:51:38 +01:00
Mark Brown
ad14ad735f Merge remote-tracking branch 'spi/topic/rspi' into spi-next 2013-10-25 09:51:37 +01:00
Mark Brown
b3d6c80050 Merge remote-tracking branch 'spi/topic/qspi' into spi-next 2013-10-25 09:51:36 +01:00
Mark Brown
982d628743 Merge remote-tracking branch 'spi/topic/probe' into spi-next 2013-10-25 09:51:36 +01:00
Mark Brown
7e0ae74090 Merge remote-tracking branch 'spi/topic/pl022' into spi-next 2013-10-25 09:51:35 +01:00
Mark Brown
3135ba82a1 Merge remote-tracking branch 'spi/topic/orion' into spi-next 2013-10-25 09:51:35 +01:00
Mark Brown
6c99db1eb8 Merge remote-tracking branch 'spi/topic/mxs' into spi-next 2013-10-25 09:51:34 +01:00
Mark Brown
8211e6b8fa Merge remote-tracking branch 'spi/topic/loop' into spi-next 2013-10-25 09:51:29 +01:00
Mark Brown
c25b2c9eb3 Merge remote-tracking branch 'spi/topic/imx' into spi-next 2013-10-25 09:51:29 +01:00
Mark Brown
ffd6dd3eaa Merge remote-tracking branch 'spi/topic/hspi' into spi-next 2013-10-25 09:51:28 +01:00
Mark Brown
6e693ff1e3 Merge remote-tracking branch 'spi/topic/gpio' into spi-next 2013-10-25 09:51:28 +01:00
Mark Brown
23e0ad77e1 Merge remote-tracking branch 'spi/topic/efm32' into spi-next 2013-10-25 09:51:27 +01:00
Mark Brown
a59ca9773c Merge remote-tracking branch 'spi/topic/dspi' into spi-next 2013-10-25 09:51:27 +01:00
Mark Brown
a35a1df635 Merge remote-tracking branch 'spi/topic/dev' into spi-next 2013-10-25 09:51:26 +01:00
Mark Brown
4cd667bb68 Merge remote-tracking branch 'spi/topic/designware' into spi-next 2013-10-25 09:51:26 +01:00
Mark Brown
f24b19cb77 Merge remote-tracking branch 'spi/topic/davinci' into spi-next 2013-10-25 09:51:25 +01:00
Mark Brown
8f737d6185 Merge remote-tracking branch 'spi/topic/core' into spi-next 2013-10-25 09:51:25 +01:00
Mark Brown
d42b70f5c7 Merge remote-tracking branch 'spi/topic/clps711x' into spi-next 2013-10-25 09:51:24 +01:00
Mark Brown
1e8081da4d Merge remote-tracking branch 'spi/topic/butterfly' into spi-next 2013-10-25 09:51:23 +01:00
Mark Brown
dd8c26f08e Merge remote-tracking branch 'spi/topic/bitbang' into spi-next 2013-10-25 09:51:23 +01:00
Mark Brown
52d85ebb7b Merge remote-tracking branch 'spi/topic/bfin' into spi-next 2013-10-25 09:51:21 +01:00
Mark Brown
2ef2e60d2f Merge remote-tracking branch 'spi/topic/atmel' into spi-next 2013-10-25 09:51:21 +01:00
Mark Brown
c55b869ac4 Merge remote-tracking branch 'spi/fix/s3c64xx' into spi-linus 2013-10-25 09:51:20 +01:00
Mark Brown
4c4b8da17d Merge remote-tracking branch 'spi/fix/modalias' into spi-linus 2013-10-25 09:51:19 +01:00
Mark Brown
5b66fd1812 Merge remote-tracking branch 'spi/fix/mcspi' into spi-linus 2013-10-25 09:51:19 +01:00
Mark Brown
9270d827de Merge remote-tracking branch 'spi/fix/efm' into spi-linus 2013-10-25 09:51:18 +01:00
Kuninori Morimoto
e5f7825cda spi/hspi: add device tree support
Support for loading the Renesas HSPI driver via devicetree.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-25 09:49:56 +01:00
Wei Yongjun
543c954d68 spi: atmel: fix return value check in atmel_spi_probe()
In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should be
replaced with IS_ERR().

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-23 10:38:46 +01:00
Huang Shijie
9e556dcc55 spi: spi-imx: only enable the clocks when we start to transfer a message
Current code keeps the clocks enabled all the time, it wastes the power
when there is no operaiton on the spi controller.

In order to save the power, this patch adds the two hooks:
   spi_imx_prepare_message: enable the clocks for this message
   spi_imx_unprepare_message: disable the clocks.

This patch also disables the clocks in the end of the probe.

Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-23 10:05:05 +01:00
Krzysztof Kozlowski
9d7fd21acb spi/s3c64xx: Fix doubled clock disable on suspend
Fix doubled clock disable and unprepare during PM suspend which triggered
the warnings:

WARNING: at drivers/clk/clk.c:800 clk_disable+0x18/0x24()
Modules linked in:
CPU: 0 PID: 1745 Comm: sh Not tainted 3.10.14-01211-ge2549bb-dirty #62
[<c0015980>] (unwind_backtrace+0x0/0x138) from [<c0012a44>] (show_stack+0x10/0x14)
[<c0012a44>] (show_stack+0x10/0x14) from [<c0022818>] (warn_slowpath_common+0x4c/0x68)
[<c0022818>] (warn_slowpath_common+0x4c/0x68) from [<c0022850>] (warn_slowpath_null+0x1c/0x24)
[<c0022850>] (warn_slowpath_null+0x1c/0x24) from [<c036e274>] (clk_disable+0x18/0x24)
[<c036e274>] (clk_disable+0x18/0x24) from [<c02d5f78>] (s3c64xx_spi_suspend+0x28/0x54)
[<c02d5f78>] (s3c64xx_spi_suspend+0x28/0x54) from [<c02b3a54>] (platform_pm_suspend+0x2c/0x5c)
[<c02b3a54>] (platform_pm_suspend+0x2c/0x5c) from [<c02b8a30>] (dpm_run_callback+0x44/0x7c)
[<c02b8a30>] (dpm_run_callback+0x44/0x7c) from [<c02b8b70>] (__device_suspend+0x108/0x300)
[<c02b8b70>] (__device_suspend+0x108/0x300) from [<c02ba4e0>] (dpm_suspend+0x54/0x208)
[<c02ba4e0>] (dpm_suspend+0x54/0x208) from [<c0066bcc>] (suspend_devices_and_enter+0x98/0x458)
[<c0066bcc>] (suspend_devices_and_enter+0x98/0x458) from [<c0067150>] (pm_suspend+0x1c4/0x25c)
[<c0067150>] (pm_suspend+0x1c4/0x25c) from [<c0066044>] (state_store+0x6c/0xbc)
[<c0066044>] (state_store+0x6c/0xbc) from [<c0203290>] (kobj_attr_store+0x14/0x20)
[<c0203290>] (kobj_attr_store+0x14/0x20) from [<c0157530>] (sysfs_write_file+0xfc/0x164)
[<c0157530>] (sysfs_write_file+0xfc/0x164) from [<c00fd6b0>] (vfs_write+0xbc/0x1bc)
[<c00fd6b0>] (vfs_write+0xbc/0x1bc) from [<c00fdaf0>] (SyS_write+0x40/0x68)
[<c00fdaf0>] (SyS_write+0x40/0x68) from [<c000ea80>] (ret_fast_syscall+0x0/0x3c)

The clocks may be already disabled before suspending. Check PM runtime
suspend status and disable clocks only if device is not suspended.
During resume do not enable the clocks if device is runtime suspended.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-22 09:35:30 +01:00
Krzysztof Kozlowski
347de6bab4 spi/s3c64xx: Do not ignore return value of spi_master_resume/suspend
During PM resume and suspend do not ignore the return value of
spi_master_suspend() or spi_master_resume(). Instead pass it further.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-22 09:34:30 +01:00
Trent Piepho
42e182f862 spi: spi-mxs: Use u32 instead of uint32_t
It's consistent with all the other spi drivers that way.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:32 +01:00
Trent Piepho
a560943ead spi: spi-mxs: Don't set clock for each xfer
mxs_spi_setup_transfer() would set the SSP SCK rate every time it was
called, which is before every transfer.  It is uncommon for the SCK rate to
change between transfers (or at all of that matter) and this causes many
unnecessary reprogrammings of the clock registers.

Code changed to only set the rate when it changes.  This significantly
speeds up short SPI messages, especially messages made up of many transfers,
as the calculation of the clock divisors is rather costly.  On an iMX287,
using spidev with messages that consist of 511 transfers of 4 bytes each at
an SCK of 48 MHz, the effective transfer rate more than doubles from about
290 KB/sec to 600 KB/sec!

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:32 +01:00
Trent Piepho
aa9e0c6feb spi: spi-mxs: Clean up setup_transfer function
It can't be called with a NULL transfer anymore so it can be simplified
to not check for that.

Fix indention of line-wrapped code to Linux standard.

The transfer pointer can be const.

It's not necessary to check if the spi_transfer's speed_hz is zero, as
the spi core also fills it in from the spi_device.  However, the spi
core does not check if spi_device's speed is zero so we have to do
that still.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:32 +01:00
Trent Piepho
d426eadb1e spi: spi-mxs: Remove check of spi mode bits
The spi core already checks for a slave setting mode bits that we
didn't list as supported when the master was registered.  There is no
need to do it again in the master driver.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:31 +01:00
Trent Piepho
9c97e3421f spi: spi-mxs: Fix race in setup method
Despite many warnings in the SPI documentation and code, the spi-mxs
driver sets shared chip registers in the ->setup method.  This method can
be called when transfers are in progress on other slaves controlled by the
master.  Setting registers or any other shared state will corrupt those
transfers.

So fix mxs_spi_setup() to not call mxs_spi_setup_transfer().
mxs_spi_setup_transfer() is already called for each transfer when they
are actually performed in mxs_spi_transfer_one(), so the call in
mxs_spi_setup() isn't necessary to setup anything.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:31 +01:00
Trent Piepho
1a33073fcf spi: spi-mxs: Remove bogus setting of ssp clk rate field
The ssp struct has a clock rate field, to provide the actual value, in Hz,
of the SSP output clock (the rate of SSP_SCK) after mxs_ssp_set_clk_rate()
is called.  It is set by mxs_ssp_set_clk_rate(), for SSP using drivers (like
SPI and MMC) to *read* if they want to know the actual clock rate.  The SPI
driver isn't supposed to *write* to it.

For some reason the spi-mxs driver decides to write to this field on init,
and sets it to the value of the SSP input clock (clk_sspN, from the MXS
clocking block) in kHz.  It shouldn't be setting the value, and certainly
shouldn't be setting it with the wrong clock in the wrong units.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:31 +01:00
Trent Piepho
210f65fedf spi: spi-mxs: Remove full duplex check, spi core already does it
Because the driver sets the SPI_MASTER_HALF_DUPLEX flag, the spi core
will check transfers to insure they are not full duplex.  It's not
necessary to check that in the spi-mxs driver as well.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:30 +01:00
Trent Piepho
0b782f70b5 spi: spi-mxs: Fix chip select control bits in DMA mode
In DMA mode the chip select control bits would be ORed into the CTRL0
register without first clearing the bits.  This means that after
addressing slave 1, the CTRL0 bit to address slave 1 would be still be
set when addressing slave 0, resulting in slave 1 continuing to be
addressed.

The message handling function would pass the CS value to the txrx
function, which would re-program the bits on each transfer in the
message.  The selected CS does not change during a message so this is
inefficient.  It also means there are two different sets of code for
selecting the CS, one for PIO that worked and one for DMA that didn't.

Change the code to set the CS bits in the message handling function
once.  Now the DMA and PIO txrx functions don't need to care about CS
at all.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:30 +01:00
Trent Piepho
df23286e57 spi: spi-mxs: Fix extra CS pulses and read mode in multi-transfer messages
There are two bits which control the CS line in the CTRL0 register:
LOCK_CS and IGNORE_CRC.  The latter would be better named DEASSERT_CS
in SPI mode.

Setting DEASSERT_CS causes CS to be de-asserted at the end of the transfer.
It should normally be set only for the final segment of the final transfer.
The DMA code explicitly sets it in this case, but because it never clears
the bit from the ctrl0 register, it will remain set for all transfers in
subsequent messages.  This results in a CS pulse between transfers.

There is a similar problem with the read mode bit never being cleared
in DMA mode.

This patch fixes DEASSERT_CS and READ being left on in DMA mode.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:30 +01:00
Trent Piepho
28cad12588 spi: spi-mxs: Change flag arguments in txrx functions to bit flags
There are three flag arguments to the PIO and DMA txrx functions.  Two
are passed as pointers to integers, even though they are input only
and not modified, which makes no sense to do.  The third is passed as
an integer.

The compiler must use an argument register or stack variable for each
flag this way.  Using bitflags in a single flag argument is more
efficient and produces smaller code, since all the flags can fit in a
single register.  And all the flag arguments get cumbersome,
especially when more are added for things like GPIO chipselects.

The "first" flag is never used, so can just be deleted.

The "last" flag is renamed to DEASSERT_CS, since that's really what it
does.  The spi_transfer cs_change flag means that CS might be
de-asserted on a transfer which is not last and not de-assert on the
last transfer, so it is not which transfer is the last we need to know
but rather the transfers after which CS should be de-asserted.

This also extends the driver to not ignore cs_change when setting the
DEASSERT_CS nee "last" flag.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:29 +01:00
Trent Piepho
75e73fa248 spi: spi-mxs: Always clear INGORE_CRC, to keep CS asserted
INGORE_CRC, better named DEASSERT_CS, should be cleared on all tranfers
except the last.  So instead of only clearing it on the first transfer, we
can just always clear it.  It will set on the last transfer.

This removes the only use of the "first" flag in the transfer functions, so
that flag can be then be removed.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:29 +01:00
Trent Piepho
f5bc7384dc spi: spi-mxs: Remove mxs_spi_enable and mxs_spi_disable
These functions consist of nothing but one single writel call and are
only called once.  And the names really aren't accurate or clear,
since they don't enable or disble SPI.  Rather they set the bit that
controls the state of CS at the end of transfer.  It easier to follow
the code to just set this bit with a writel() along with all the other
bits being set in the same function.

Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-10-18 01:00:29 +01:00