This driver forgets to unregister controller when remove.
Use devm API to unregister it automatically to fix it.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/20191109075517.29988-1-hslester96@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Both omap2_mcspi_tx_dma() and omap2_mcspi_rx_dma() are only called from
omap2_mcspi_txrx_dma() and omap2_mcspi_txrx_dma() is always called after
making sure that mcspi_dma->dma_rx and mcspi_dma->dma_tx are not NULL
(see omap2_mcspi_transfer_one()).
Therefore remove redundant NULL checks for omap2_mcspi->dma_tx and
omap2_mcspi->dma_rx pointers in omap2_mcspi_tx_dma() and
omap2_mcspi_rx_dma() respectively.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20191109041827.26934-1-vigneshr@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Zynq QSPI controller features 2 CS. When the num-cs DT property
is set to 2, the hardware will be initialized to support having two
devices connected over each CS.
In this case, both CS lines are driven by the state of the U_PAGE
(upper page) bit. When unset, the lower page (CS0) is selected,
otherwise it is the upper page (CS1).
Change tested on a custom design featuring two SPI-NORs with different
CS on the Zynq-7000 QSPI bus.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20191108140744.1734-8-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Supporting more than one CS will need some tweaking of the linear
configuration register which is (rightfully) initialized in the
hardware initialization helper. The extra initialization needs the
knowledge of the actual number of CS, which is retrieved by reading
the value of the num-cs DT property.
As the initialization helper is called pretty early and might be
called much later in the probe without side effect, let's delay it a
bit so that the number of CS will be available when running this
helper. This way, adding support for multiple CS lines in a next patch
will be eased.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20191108140744.1734-7-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The code used to assert and de-assert a chip select line is very
complicated for no reason. Simplify the logic by either setting or
resetting the concerned bit, which actually only changes an electrical
state.
Update the comment to reflect that there is no possibility to actually
choose a CS as the default (CS0) will be driven in any case.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20191108140744.1734-6-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Using masks makes sense when manipulating fields of several bits. When
only one bit is involved, it is usual to just use the BIT() macro but
in this case using the term mask is abusive. Fix the #define macros
and their comments.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20191108140744.1734-5-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Most of the bits/bitfields #define'd in this driver are composed with:
1/ the driver prefix
2/ the name of the register they apply to
Keep the naming consistent by applying this rule to the CONFIG register
internals. These definitions will be used in a following change set.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20191108140744.1734-4-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Unlike what the driver is currently advertizing, CS0 only can be used,
CS1 is not supported at all. Prevent people to use CS1.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20191108140744.1734-2-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In this driver (and also in a lot of other drivers in drivers/spi/),
the spi_controller structure is sometimes referred as 'ctlr' and
sometimes as 'ctrl'. Grepping there shows that 'ctlr' seems to be more
common so keep the naming consistent in this driver and s/ctrl/ctlr/.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20191108105920.19014-3-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Devices with chip selects driven via GPIO are not compatible with the
spi-mem operations. Fallback to using standard spi transfers when the
device is connected with a gpio CS.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20191107044235.4864-3-chris.packham@alliedtelesis.co.nz
Signed-off-by: Mark Brown <broonie@kernel.org>
The channels spfi->tx_ch and spfi->rx_ch are not set to NULL after they
are released. As a result, they will be released again, either on the
error handling branch in the same function or in the corresponding
remove function, i.e. img_spfi_remove(). This patch fixes the bug by
setting the two members to NULL.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Link: https://lore.kernel.org/r/1573007769-20131-1-git-send-email-bianpan2016@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This converts the TXX9 SPI driver to use GPIO descriptors
to control the GPIO chip selects.
As the driver was clearly (ab)using the device tree "reg"
property to offset into the global GPIO chip we have to
add a hack to counter the hack: add a 1-to-1 chip select
to GPIO offset mapping for all 16 lines on the TXX9 GPIO
chip. The details are described in a largeish comment
in the patch.
We do not need to set up the GPIO as output any more since
the core will take care of this, as well as it will handle
the polarity inversion semantics.
Cc: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191030073832.24038-1-linus.walleij@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Committed version of the commit b9fc2d207e ("spi: dw: Move runtime PM
enable/disable from common to platform driver part") does not include by
some reason changes to drivers/spi/spi-dw.c that were part of the original
patch sent to the mailing list.
Complete the code move by doing those changes now.
Fixes: b9fc2d207e ("spi: dw: Move runtime PM enable/disable from common to platform driver part")
Cc: Phil Edworthy <phil.edworthy@renesas.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Link: https://lore.kernel.org/r/20191030113137.15459-1-jarkko.nikula@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When rebooting system, the PMIC watchdog time loading may not be loaded
correctly when another system is feeding the PMIC watchdog, since we did
not check the watchdog busy status before loading time values.
Thus we should set the BIT_WDG_NEW bit before loading time values, that
can support multiple loads without checking busy status to make sure the
time values can be loaded successfully to avoid this potential issue.
Signed-off-by: Lingling Xu <ling_ling.xu@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Link: https://lore.kernel.org/r/5655318a7252c9ea518c2f7950a61228ab8f42bf.1572257085.git.baolin.wang@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The current conditional for PCI ID matching is hard to read.
Introduce couple of temporary variables to increase readability
of the code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20191021103625.4250-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This core supports either 8, 16 or 32 bits as word width. This value is only
settable on instantiation, and thus we need to support any of them by means
of the device tree.
Signed-off-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
Link: https://lore.kernel.org/r/20191024110757.25820-3-alvaro.gamez@hazent.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Intel(R) Programmable Services Engine (Intel(R) PSE) SPI controllers in
Intel Elkhart Lake have two Chip Select signals instead of one.
Reported-by: Raymond Tan <raymond.tan@intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Link: https://lore.kernel.org/r/20191018132131.31608-3-jarkko.nikula@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Implement pm_runtime hooks at pci driver.
Signed-off-by: Raymond Tan <raymond.tan@intel.com>
[jarkko.nikula@linux.intel.com: Forward ported on top of
commit 1e69598325 ("spi: dw: Add basic runtime PM support")]
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Link: https://lore.kernel.org/r/20191018132131.31608-2-jarkko.nikula@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Thanks to the recent change in this driver, it is now possible to
prevent using the CS0 with GPIO during setup. It then allows to remove
the special handling of this case in the cs_activate() and
cs_deactivate() functions.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20191017141846.7523-8-gregory.clement@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the previous implementation of this driver, the index of the GPIO
used as CS was linked to the offset of the CS register used to
configure the transfer.
With this new implementation the first CS register not used by
internal CS is associated to all the GPIO CS. It allows to not be
anymore limited to have only 4 CS managed, now it is possible to have
in the same time until 3 internal CS and no more limit for the CS
GPIO.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20191017141846.7523-7-gregory.clement@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the conversion to GPIO descriptor, the GPIO used as chip select,
can be directly access from the spi_device struct. So there is no need
to keep the field npcs_pin.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20191017141846.7523-5-gregory.clement@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of setting up the GPIO configuration for the whole controller,
do it at CS level. It will allow to mix internal CS and GPIO CS, which
is not possible with the current implementation.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20191017141846.7523-4-gregory.clement@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Until a few years ago, this driver was only used with CS GPIO. The
only exception is CS0 on AT91RM9200 which has to use internal CS. A
limitation of the internal CS is that they don't support CS High.
So by using the CS GPIO the CS high configuration was available except
for the particular case CS0 on RM9200.
When the support for the internal chip-select was added, the check of
the CS high support was not updated. Due to this the driver accepts
this configuration for all the SPI controller v2 (used by all SoCs
excepting the AT91RM9200) whereas the hardware doesn't support it for
infernal CS.
This patch fixes the test to match the hardware capabilities.
Fixes: 4820303480 ("spi: atmel: add support for the internal chip-select of the spi controller")
Cc: <stable@vger.kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20191017141846.7523-3-gregory.clement@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since CSAAT functionality support has been added. Some comments become
wrong. Fix them to match the current driver behavior.
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20191017141846.7523-2-gregory.clement@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Convert to use device_get_match_data() instead of open coded variant.
While here, switch of_property_read_bool() to device_property_read_bool().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20191018105429.82782-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no need to keep a pointer to the platform device. Currently there are
no users of it directly, and if there will be in the future we may restore it
from pointer to the struct device.
Convert all users at the same time.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20191018105429.82782-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For many places in the spi drivers, using the new `spi_transfer_delay`
helper is straightforward.
It's just replacing:
```
if (t->delay_usecs)
udelay(t->delay_usecs);
```
with `spi_transfer_delay(t)` which handles both `delay_usecs` and the new
`delay` field.
This change replaces in all places (in the spi drivers) where this change
is simple.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-10-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The AXI SPI engine driver uses the `delay_usecs` field from `spi_transfer`
to configure delays, which the controller will execute.
This change extends the logic to also include the `delay` value, in case it
is used (instead if `delay_usecs`).
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-20-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver errors out if `delay_usecs` is non-zero. This error condition
should be extended to the new `delay` field, to account for when it will be
used.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-19-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The WARN_ON macro prints a warning in syslog if `delay_usecs` is non-zero.
However, with the new intermediate `delay`, the warning should also be
printed.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-18-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The way the max delay is computed for this controller, it looks like it is
searching for the max delay from an SPI message a using that.
No idea if this is valid. But this change should support both `delay_usecs`
and the new `delay` data which is of `spi_delay` type.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-17-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This change implements CS control for setup, hold & inactive delays.
The `cs_setup` delay is completely new, and can help with cases where
asserting the CS, also brings the device out of power-sleep, where there
needs to be a longer (than usual), before transferring data.
The `cs_hold` time can overlap with the `delay` (or `delay_usecs`) from an
SPI transfer. The main difference is that `cs_hold` implies that CS will be
de-asserted.
The `cs_inactive` delay does not have a clear use-case yet. It has been
implemented mostly because the `spi_set_cs_timing()` function implements
it. To some degree, this could overlap or replace `cs_change_delay`, but
this will require more consideration/investigation in the future.
All these delays have been added to the `spi_controller` struct, as they
would typically be configured by calling `spi_set_cs_timing()` after an
`spi_setup()` call.
Software-mode for CS control, implies that the `set_cs_timing()` hook has
not been provided for the `spi_controller` object.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-16-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The initial version of `spi_set_cs_timing()` was implemented with
consideration only for clock-cycles as delay.
For cases like `CS setup` time, it's sometimes needed that micro-seconds
(or nano-seconds) are required, or sometimes even longer delays, for cases
where the device needs a little longer to start transferring that after CS
is asserted.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-15-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The `delay` field has type `struct spi_delay`.
This allows users to specify nano-second or clock-cycle delays (if needed).
Converting to use `delay` is straightforward: it's just assigning the
value to `delay.value` and hard-coding the `delay.unit` to
`SPI_DELAY_UNIT_USECS`.
This keeps the uapi for spidev un-changed. Changing it can be part of
another changeset and discussion.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-14-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This change replaces the use of the `delay_usecs` field with the new
`delay` field. The code/test still uses micro-seconds, but they are now
configured and used via the `struct spi_delay` format of the `delay` field.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-13-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This conversion to the spi_transfer_delay_exec() helper is not
straightforward, as it seems that when a delay is present, the controller
issues a command, and then a delay is followed.
This change adds support for the new `delay` field which is of type
`spi_delay` and keeps backwards compatibility with the old `delay_usecs`
field.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-12-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The tegra114 driver has a weird/separate `tegra_spi_transfer_delay()`
function that does 2 delays: one mdelay() and one udelay().
This was introduced via commit f4fade12d5
("spi/tegra114: Correct support for cs_change").
There doesn't seem to be a mention in that commit message to suggest a
specific need/use-case for having the 2 delay calls.
For the most part, udelay() should be sufficient.
This change replaces it with the new `spi_transfer_delay_exec()`, which
should do the same thing.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-11-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The change introduces the `delay` field to the `spi_transfer` struct as an
`struct spi_delay` type.
This intends to eventually replace `delay_usecs`.
But, since there are many users of `delay_usecs`, this needs some
intermediate work.
A helper called `spi_transfer_delay_exec()` is also added, which maintains
backwards compatibility with `delay_usecs`, by assigning the value to
`delay` if non-zero.
This should maintain backwards compatibility with current users of
`udelay_usecs`.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-9-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This change does a conversion from the `word_delay_usecs` -> `word_delay`
for the `spi_device` struct.
This allows users to specify inter-word delays in other unit types
(nano-seconds or clock cycles), depending on how users want.
The Atmel SPI driver is the only current user of the `word_delay_usecs`
field (from the `spi_device` struct).
So, it needed a slight conversion to use the `word_delay` as an `spi_delay`
struct.
In SPI core, the only required mechanism is to update the `word_delay`
information per `spi_transfer`. This requires a bit more logic than before,
because it needs that both delays be converted to a common unit
(nano-seconds) for comparison.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-8-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The `word_delay` field had it's type changed to `struct spi_delay`.
This allows users to specify nano-second or clock-cycle delays (if needed).
Converting to use `word_delay` is straightforward: it's just assigning the
value to `word_delay.value` and hard-coding the `word_delay.unit` to
`SPI_DELAY_UNIT_USECS`
This keeps the uapi for spidev un-changed. Changing it can be part of
another changeset and discussion.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20190926105147.7839-7-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
