| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The current implementation of the driver holds a spin lock for the
duration of the transfer, releasing it only to enable interrupts for
short periods of time. As this would prevent any interrupt from
happening, this could cause system performance issues every time a SPI
message is sent. Since the spi core now handles message syncronization
we can reduce the amount of time the spin-lock is held to the regions
where both the calling thread and the interrupt might interract.
Signed-off-by: Dan Sneddon <dan.sneddon@microchip.com>
Link: https://lore.kernel.org/r/20210602160816.4890-2-dan.sneddon@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Switch from using our own transfer_one_message routine to using the one
provided by the SPI core.
Signed-off-by: Dan Sneddon <dan.sneddon@microchip.com>
Link: https://lore.kernel.org/r/20210602160816.4890-1-dan.sneddon@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
STM32 QSPI is able to automatically poll a specified register inside the
memory and relieve the CPU from this task.
As example, when erasing a large memory area, we got cpu load
equal to 50%. This patch allows to perform the same operation
with a cpu load around 2%.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Link: https://lore.kernel.org/r/20210518162754.15940-4-patrice.chotard@foss.st.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
With STM32 QSPI, it is possible to poll the status register of the device.
This could be done to offload the CPU during an operation (erase or
program a SPI NAND for example).
spi_mem_poll_status API has been added to handle this feature.
This new function take care of the offload/non-offload cases.
For the non-offload case, use read_poll_timeout() to poll the status in
order to release CPU during this phase.
For example, previously, when erasing large area, in non-offload case,
CPU load can reach ~50%, now it decrease to ~35%.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/r/20210518162754.15940-2-patrice.chotard@foss.st.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In U-boot side, an issue has been encountered when QSPI source clock is
running at low frequency (24 MHz for example), waiting for TCF bit to be
set didn't ensure that all data has been send out the FIFO, we should also
wait that BUSY bit is cleared.
To prevent similar issue in kernel driver, we implement similar behavior
by always waiting BUSY bit to be cleared.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Link: https://lore.kernel.org/r/20210603073421.8441-1-patrice.chotard@foss.st.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Since commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for
->prepare_message()"), the number of slaves has been limited by a
compile-time constant. This was necessitated by statically-sized
arrays in the driver private data which contain per-slave register
values.
As suggested by Mark, move those register values to a per-slave
controller_state which is allocated on ->setup and freed on ->cleanup.
The limitation on the number of slaves is thus lifted.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Joe Burmeister <joe.burmeister@devtank.co.uk>
Cc: Phil Elwell <phil@raspberrypi.com>
Link: https://lore.kernel.org/r/a847c01f09400801e74e0630bf5a0197591554da.1622150204.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In zynq_qspi_probe function, when enable the device clock is done,
the return of all the functions should goto the clk_dis_all label.
If num_cs is not right then this should return a negative error
code but currently it returns success.
Signed-off-by: zpershuai <zpershuai@gmail.com>
Link: https://lore.kernel.org/r/1622110857-21812-1-git-send-email-zpershuai@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
|
|
Commit c7299fea6769 ("spi: Fix spi device unregister flow") changed the
SPI core's behavior if the ->setup() hook returns an error upon adding
an spi_device: Before, the ->cleanup() hook was invoked to free any
allocations that were made by ->setup(). With the commit, that's no
longer the case, so the ->setup() hook is expected to free the
allocations itself.
I've identified 5 drivers which depend on the old behavior and am fixing
them up hereinafter: spi-bitbang.c spi-fsl-spi.c spi-omap-uwire.c
spi-omap2-mcspi.c spi-pxa2xx.c
Importantly, ->setup() is not only invoked on spi_device *addition*:
It may subsequently be called to *change* SPI parameters. If changing
these SPI parameters fails, freeing memory allocations would be wrong.
That should only be done if the spi_device is finally destroyed.
I am therefore using a bool "initial_setup" in 4 of the affected drivers
to differentiate between the invocation on *adding* the spi_device and
any subsequent invocations: spi-bitbang.c spi-fsl-spi.c spi-omap-uwire.c
spi-omap2-mcspi.c
In spi-pxa2xx.c, it seems the ->setup() hook can only fail on spi_device
addition, not any subsequent calls. It therefore doesn't need the bool.
It's worth noting that 5 other drivers already perform a cleanup if the
->setup() hook fails. Before c7299fea6769, they caused a double-free
if ->setup() failed on spi_device addition. Since the commit, they're
fine. These drivers are: spi-mpc512x-psc.c spi-pl022.c spi-s3c64xx.c
spi-st-ssc4.c spi-tegra114.c
(spi-pxa2xx.c also already performs a cleanup, but only in one of
several error paths.)
Fixes: c7299fea6769 ("spi: Fix spi device unregister flow")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Saravana Kannan <saravanak@google.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # pxa2xx
Link: https://lore.kernel.org/r/f76a0599469f265b69c371538794101fa37b5536.1622149321.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
It is helpful to see what state of CS signal was during one
or another SPI operation. All the same for SPI setup.
Enable tracing of the SPI setup and CS selection.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Message-Id: <20210526195655.75691-1-andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
All chipsets from AR7100 up to QCA9563 have three dedicated chipselect
lines for the integrated SPI controller. Set the number of chipselect
lines available on the controller to this value.
Signed-off-by: David Bauer <mail@david-bauer.net>
Link: https://lore.kernel.org/r/20210522074453.39299-2-mail@david-bauer.net
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The ath79 platform has been converted to pure OF. The platform data is
not needed anymore because of this.
Signed-off-by: David Bauer <mail@david-bauer.net>
Link: https://lore.kernel.org/r/20210522074453.39299-1-mail@david-bauer.net
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for
->prepare_message()") limited the number of slaves to 3 at compile-time.
The limitation was necessitated by a statically-sized array prepare_cs[]
in the driver private data which contains a per-slave register value.
The commit sought to enforce the limitation at run-time by setting the
controller's num_chipselect to 3: Slaves with a higher chipselect are
rejected by spi_add_device().
However the commit neglected that num_chipselect only limits the number
of *native* chipselects. If GPIO chipselects are specified in the
device tree for more than 3 slaves, num_chipselect is silently raised by
of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to
the statically-sized array prepare_cs[].
As a bandaid fix which is backportable to stable, raise the number of
allowed slaves to 24 (which "ought to be enough for anybody"), enforce
the limitation on slave ->setup and revert num_chipselect to 3 (which is
the number of native chipselects supported by the controller).
An upcoming for-next commit will allow an arbitrary number of slaves.
Fixes: 571e31fa60b3 ("spi: bcm2835: Cache CS register value for ->prepare_message()")
Reported-by: Joe Burmeister <joe.burmeister@devtank.co.uk>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v5.4+
Cc: Phil Elwell <phil@raspberrypi.com>
Link: https://lore.kernel.org/r/75854affc1923309fde05e47494263bde73e5592.1621703210.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Eliminate the follow smatch warning:
drivers/spi/spi-pxa2xx-pci.c:260 pxa2xx_spi_pci_probe() warn:
inconsistent indenting.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/1621590465-73594-1-git-send-email-jiapeng.chong@linux.alibaba.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Allow SPI peripherals attached to this controller to know what is the
maximum transfer size and message size, so they can limit their transfer
lengths properly in case they are otherwise capable of larger transfer
sizes. For the sc18is602, this is 200 bytes in both cases, since as far
as I understand, it isn't possible to tell the controller to keep the
chip select asserted after the STOP command is sent.
The controller can support SPI messages larger than 200 bytes if
cs_change is set for individual transfers such that the portions with
chip select asserted are never longer than 200 bytes. What is not
supported is just SPI messages with a continuous chip select larger than
200. I don't think it is possible to express this using the current API,
so drivers which do send SPI messages with cs_change can safely just
look at the max_transfer_size limit.
An example of user for this is sja1105_xfer() in
drivers/net/dsa/sja1105/sja1105_spi.c which sends by default 64 * 4 =
256 byte transfers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20210520131238.2903024-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
For each spi_message, the sc18is602 I2C-to-SPI bridge driver checks the
length of each spi_transfer against 200 (the size of the chip's internal
buffer) minus hw->tlen (the number of bytes transferred so far).
The first byte of the transferred data is the Function ID (the SPI
slave's chip select) and as per the documentation of the chip:
https://www.nxp.com/docs/en/data-sheet/SC18IS602B.pdf
the data buffer is up to 200 bytes deep _without_ accounting for the
Function ID byte.
However, in sc18is602_txrx(), the driver keeps the Function ID as part
of the buffer, and increments hw->tlen from 0 to 1. Combined with the
check in sc18is602_check_transfer, this prevents us from issuing a
transfer that has exactly 200 bytes in size, but only 199.
Adjust the check function to reflect that the Function ID is not part of
the 200 byte deep data buffer.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20210520131238.2903024-2-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patchset fixes missing parentheses of sizeof reported by checkpatch.pl
under drivers/spi/.
Zhiqi Song (7):
spi: lm70llp: add parenthesis for sizeof
spi: mpc512x-psc: add parenthesis for sizeof
spi: mpc52xx: add parenthesis for sizeof
spi: mpc52xx-psc: add parenthesis for sizeof
spi: omap2-mcspi: add parenthesis for sizeof
spi: omap-uwire: add parenthesis for sizeof
spi: ppc4xx: add parenthesis for sizeof
drivers/spi/spi-lm70llp.c | 2 +-
drivers/spi/spi-mpc512x-psc.c | 4 ++--
drivers/spi/spi-mpc52xx-psc.c | 4 ++--
drivers/spi/spi-mpc52xx.c | 2 +-
drivers/spi/spi-omap-uwire.c | 2 +-
drivers/spi/spi-omap2-mcspi.c | 2 +-
drivers/spi/spi-ppc4xx.c | 4 ++--
7 files changed, 10 insertions(+), 10 deletions(-)
--
2.7.4
|
|
Fix missing parenthesis of sizeof reported by checkpatch.pl:
WARNING: sizeof *pp should be sizeof(*pp).
The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: Zhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-8-git-send-email-songzhiqi1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Fix missing parenthesis of sizeof reported by checkpatch.pl:
WARNING: sizeof *pp should be sizeof(*pp).
The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: Zhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-7-git-send-email-songzhiqi1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Fix missing parenthesis of sizeof reported by checkpatch.pl:
WARNING: sizeof *pp should be sizeof(*pp).
The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: Zhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-6-git-send-email-songzhiqi1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Fix missing parenthesis of sizeof reported by checkpatch.pl:
WARNING: sizeof *pp should be sizeof(*pp).
The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: Zhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-5-git-send-email-songzhiqi1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Fix missing parenthesis of sizeof reported by checkpatch.pl:
WARNING: sizeof *pp should be sizeof(*pp).
The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: Zhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-4-git-send-email-songzhiqi1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Fix missing parenthesis of sizeof reported by checkpatch.pl:
WARNING: sizeof *pp should be sizeof(*pp).
The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Signed-off-by: Zhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-3-git-send-email-songzhiqi1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Fix missing parenthesis of sizeof reported by checkpatch.pl:
WARNING: sizeof *pp should be sizeof(*pp).
The kernel coding style suggests thinking of sizeof as a function
and add parenthesis.
Cc: Kaiwan N Billimoria <kaiwan@designergraphix.com>
Signed-off-by: Zhiqi Song <songzhiqi1@huawei.com>
Link: https://lore.kernel.org/r/1621301902-64158-2-git-send-email-songzhiqi1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
One of the author names got an invalid char, probably due to
a bad charset conversion, being replaced by the
REPLACEMENT CHARACTER U+fffd ('�').
Use the author's e-mail has the characters without accents,
as also used at the .mailmap file.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/ff8d296e1fdcc4f1c6df94434a5720bcedcd0ecf.1621412009.git.mchehab+huawei@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Linux 5.13-rc2
|
|
The predefined mask for threshold modification can be used
in case of Intel Merrifield SPI. Replace open-coded value
with predefined mask when programming FIFO thresholds.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-10-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Fix style of the comments and messages along with typos in them.
While at it, update Intel Copyright year.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-8-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Instead of explicit casting use proper specifier in one case,
and fix specifier signness in another.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-7-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In the few places it's redundant to compare against 0.
Drop the unneeded comparisons.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The struct chip_data had been introduced in order to keep the parameters
that may be provided on stack during device allocation. There is no need
to duplicate parameters there, which are carried on by SPI device itself.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
SPI core has been already providing the GPIO CS handling. Use it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
SPI core has been already providing the GPIO CS handling. Use it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
SPI core may utilize properties and resources provided by the parent device.
Propagate firmware node to the child SPI controller device for that.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210517140351.901-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When a spi device is unregistered and triggers a driver unbind, the
driver might need to access the spi device. So, don't have the
controller clean up the spi device before the driver is unbound. Clean
up the spi device after the driver is unbound.
Fixes: c7299fea6769 ("spi: Fix spi device unregister flow")
Reported-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210505164734.175546-1-saravanak@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently GPIO CS handling, when descriptors are in use, doesn't
take into consideration that in ACPI case the default polarity
is Active High and can't be altered. Instead we have to use the
per-chip definition provided by SPISerialBus() resource.
Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
Cc: Liguang Zhang <zhangliguang@linux.alibaba.com>
Cc: Jay Fang <f.fangjian@huawei.com>
Cc: Sven Van Asbroeck <thesven73@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Xin Hao <xhao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20210511140912.30757-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
MODULE_DEVICE_TABLE is used to extract the device information out of the
driver and builds a table when being compiled. If using this macro,
kernel can find the driver if available when the device is plugged in,
and then loads that driver and initializes the device.
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
Link: https://lore.kernel.org/r/20210512093534.243040-1-zhang.lyra@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-7-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use SPI_MODE_X_MASK instead of open coded variant.
While at it, fix format specifier and drop explicit casting.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131217.49357-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Set of cleanups here and there related to the SPI PXA2xx driver.
On top of them, adding the special type for Intel Merrifield.
In v3:
- rebased on top of v5.13-rc1 and/or spi/for-5,14
In v2:
- cover letter (Mark)
- drop moving the header in patch 5 (Mark)
Andy Shevchenko (14):
spi: pxa2xx: Use one point of return when ->probe() fails
spi: pxa2xx: Utilize MMIO and physical base from struct ssp_device
spi: pxa2xx: Utilize struct device from struct ssp_device
spi: pxa2xx: Replace header inclusions by forward declarations
spi: pxa2xx: Unify ifdeffery used in the headers
spi: pxa2xx: Group Intel Quark specific definitions
spi: pxa2xx: Introduce int_stop_and_reset() helper
spi: pxa2xx: Reuse int_error_stop() in pxa2xx_spi_slave_abort()
spi: pxa2xx: Use pxa_ssp_enable()/pxa_ssp_disable() in the driver
spi: pxa2xx: Extract pxa2xx_spi_update() helper
spi: pxa2xx: Extract clear_SSCR1_bits() helper
spi: pxa2xx: Extract read_SSSR_bits() helper
spi: pxa2xx: Constify struct driver_data parameter
spi: pxa2xx: Introduce special type for Merrifield SPIs
drivers/spi/spi-pxa2xx-dma.c | 37 +++----
drivers/spi/spi-pxa2xx-pci.c | 4 +-
drivers/spi/spi-pxa2xx.c | 190 +++++++++++++++++----------------
drivers/spi/spi-pxa2xx.h | 52 ++++-----
include/linux/pxa2xx_ssp.h | 42 +++++++-
include/linux/spi/pxa2xx_spi.h | 9 +-
sound/soc/pxa/pxa-ssp.c | 16 ---
7 files changed, 185 insertions(+), 165 deletions(-)
--
2.30.2
|
|
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1620716922-108572-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We have a lot of hard coded values in nanoseconds or other units.
Use predefined constants to make it more clear.
While at it, add or amend comments in the corresponding functions.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510131120.49253-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Intel Merrifield SPI is actually more closer to PXA3xx. It has extended FIFO
(32 bytes) and additional registers to get or set FIFO thresholds.
Introduce new type for Intel Merrifield SPI host controllers and handle bigger
FIFO size.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510124134.24638-15-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In a couple of functions the contents of struct driver_data are not altered,
hence we may constify the respective function parameter.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510124134.24638-14-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
There are few places that repeat the logic of "read some bits from SSSR".
Extract read_SSSR_bits() helper to deduplicate that.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510124134.24638-13-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
Dan Sneddon
Patrice Chotard
Lukas Wunner
zpershuai
Mark Brown
Andy Shevchenko
David Bauer
Jiapeng Chong
Vladimir Oltean
Zhiqi Song
Mauro Carvalho Chehab
Saravana Kannan
Chunyan Zhang
Zou Wei