Drop the fifo_lvl_mask and rx_lvl_offset and switch to the new port
config data.
Advantages of the change:
- drop dependency on the OF alias ID.
- FIFO depth is inferred from the compatible. GS101 integrates 16 SPI
IPs, all with 64 bytes FIFO depths.
- use full mask for SPI_STATUS.{RX, TX}_FIFO_LVL fields. Using partial
masks is misleading and can hide problems of the driver logic.
S3C64XX_SPI_ST_TX_FIFO_RDY_V2 was defined based on the USI's
SPI_VERSION.USI_IP_VERSION register field, which has value 2 at reset.
MAX_SPI_PORTS is updated to reflect the maximum number of ports for the
rest of the compatibles.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216070555.2483977-12-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Deprecate fifo_lvl_mask, rx_lvl_offset and port_id. One shall use
{rx, tx}_fifomask instead. Add messages to each port configuration.
Suggested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216070555.2483977-11-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Compatibles that set ``port_conf->{rx, tx}_fifomask`` are now safe to
get rid of the OF alias ID dependency. Let the driver probe even without
the alias for these.
With this we also protect the FIFO_LVL_MASK calls from
s3c64xx_spi_set_fifomask().
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216070555.2483977-10-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare driver to get rid of the of alias ID dependency. Split the
port_id logic into a dedicated method.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216070555.2483977-9-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Let the core determine the bus number, either by getting the alias ID
(as the driver forces now), or by allocating a dynamic bus number when
the alias is absent. Prepare the driver to allow dt aliases to be
absent.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216070555.2483977-8-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
There are SoCs that use the same FIFO depth for all the instances of the
SPI IP. See the fifo_lvl_mask defined for gs101 for example:
.fifo_lvl_mask = { 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f,
0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f},
Instead of specifying the FIFO depth with the same value for all 16
nodes in this case, allow such SoCs to infer the FIFO depth from the
compatible. There are other SoCs than can benefit of this, see:
{gs101, fsd, exynos850, s3c641, s3c2443}_spi_port_config.
The FIFO depth inferred from the compatible has a higher precedence than
the one that might be specified via device tree, the driver shall know
better.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216070555.2483977-7-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
There are SoCs that configure different FIFO depths for their instances
of the SPI IP. See the fifo_lvl_mask defined for exynos4_spi_port_config
for example:
.fifo_lvl_mask = { 0x1ff, 0x7F, 0x7F },
The first instance of the IP is configured with 256 bytes FIFOs, whereas
the last two are configured with 64 bytes FIFOs.
Instead of mangling with the .fifo_lvl_mask and its dependency of the DT
alias ID, allow such SoCs to determine the FIFO depth via the
``fifo-depth`` DT property.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216070555.2483977-6-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Determine the FIFO depth only once, at probe time.
``sdd->fifo_depth`` can be set later on with the FIFO depth
specified in the device tree.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216070555.2483977-5-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver is wrong because is using partial register field masks for the
SPI_STATUS.{RX, TX}_FIFO_LVL register fields.
We see s3c64xx_spi_port_config.fifo_lvl_mask with different values for
different instances of the same IP. Take s5pv210_spi_port_config for
example, it defines:
.fifo_lvl_mask = { 0x1ff, 0x7F },
fifo_lvl_mask is used to determine the FIFO depth of the instance of the
IP. In this case, the integrator uses a 256 bytes FIFO for the first SPI
instance of the IP, and a 64 bytes FIFO for the second instance. While
the first mask reflects the SPI_STATUS.{RX, TX}_FIFO_LVL register
fields, the second one is two bits short. Using partial field masks is
misleading and can hide problems of the driver's logic.
Allow platforms to specify the full FIFO mask, regardless of the FIFO
depth.
Introduce {rx, tx}_fifomask to represent the SPI_STATUS.{RX, TX}_FIFO_LVL
register fields. It's a shifted mask defining the field's length and
position. We'll be able to deprecate the use of @rx_lvl_offset, as the
shift value can be determined from the mask. The existing compatibles
shall start using {rx, tx}_fifomask so that they use the full field mask
and to avoid shifting the mask to position, and then shifting it back to
zero in the {TX, RX}_FIFO_LVL macros.
@rx_lvl_offset will be deprecated in a further patch, after we have the
infrastructure to deprecate @fifo_lvl_mask as well.
No functional change intended.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216070555.2483977-4-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
There are SPI IPs that can be configured by the integrator with a
specific FIFO depth depending on the system's capabilities. For example,
the samsung USI SPI IP can be configured by the integrator with a TX/RX
FIFO from 8 byte to 256 bytes.
Introduce the ``fifo-depth`` property for such instances of IPs where the
same FIFO depth is used for both RX and TX. Introduce ``rx-fifo-depth``
and ``tx-fifo-depth`` properties for cases where the RX FIFO depth is
different from the TX FIFO depth.
Make the dedicated RX/TX properties dependent on each other and mutual
exclusive with the other.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://msgid.link/r/20240216070555.2483977-2-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from David Lechner <dlechner@baylibre.com>:
This series contains a few small cleanups to the axi-spi-engine driver,
mostly suggested from previous reviews.
This makes use of the struct_size() macro to calculate the size of the
struct axi_spi_engine when allocating it.
Suggested-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://msgid.link/r/20240304-mainline-axi-spi-engine-small-cleanups-v2-3-5b14ed729a31@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds the __counted_by() attribute to the flex array at the end of
struct spi_engine_program in the AXI SPI Engine controller driver.
The assignment of the length field has to be reordered to be before
the access to the flex array in order to avoid potential compiler
warnings/errors due to adding the __counted_by() attribute.
Suggested-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://msgid.link/r/20240304-mainline-axi-spi-engine-small-cleanups-v2-2-5b14ed729a31@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The program pointer p in struct spi_engine_message_state in the AXI SPI
Engine controller driver was assigned but never read so it can be
removed.
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://msgid.link/r/20240304-mainline-axi-spi-engine-small-cleanups-v2-1-5b14ed729a31@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the addition of the driver in 2009, the driver selects between DMA
and polling mode depending on the transfer length - DMA mode for
transfers bigger than the FIFO depth, polling mode otherwise. All
versions of the IP support polling mode, make the dma properties not
required.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240301115546.2266676-1-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
of_gpio.h is deprecated and subject to remove.
The driver doesn't use it directly, replace it
with what is really being used.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240228194632.3606563-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
of_gpio.h is deprecated and subject to remove.
The driver doesn't use it directly, replace it
with what is really being used.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20240228194818.3606841-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove microchip,sam9x60-spi compatible from the list as the driver used
has the compatible atmel,at91rm9200-spi and sam9x60 devices also use the
same compatible as fallback. So removing the microchip,sam9x60-spi
compatible from the list since it is not needed.
Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240223172638.672366-1-varshini.rajendran@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from David Lechner <dlechner@baylibre.com>:
This is a follow-up to [1] where it was suggested to break down the
proposed SPI offload support into smaller series.
This takes on the first suggested task of introducing an API to
"pre-cook" SPI messages. This idea was first discussed extensively in
2013 [2][3] and revisited more briefly 2022 [4].
The goal here is to be able to improve performance (higher throughput,
and reduced CPU usage) by allowing peripheral drivers that use the
same struct spi_message repeatedly to "pre-cook" the message once to
avoid repeating the same validation, and possibly other operations each
time the message is sent.
This series includes __spi_validate() and the automatic splitting of
xfers in the optimizations. Another frequently suggested optimization
is doing DMA mapping only once. This is not included in this series, but
can be added later (preferably by someone with a real use case for it).
To show how this all works and get some real-world measurements, this
series includes the core changes, optimization of a SPI controller
driver, and optimization of an ADC driver. This test case was only able
to take advantage of the single validation optimization, since it didn't
require splitting transfers. With these changes, CPU usage of the
threaded interrupt handler, which calls spi_sync(), was reduced from
83% to 73% while at the same time the sample rate (frequency of SPI
xfers) was increased from 20kHz to 25kHz.
[1]: https://lore.kernel.org/linux-spi/20240109-axi-spi-engine-series-3-v1-1-e42c6a986580@baylibre.com/T/
[2]: https://lore.kernel.org/linux-spi/E81F4810-48DD-41EE-B110-D0D848B8A510@martin.sperl.org/T/
[3]: https://lore.kernel.org/linux-spi/39DEC004-10A1-47EF-9D77-276188D2580C@martin.sperl.org/T/
[4]: https://lore.kernel.org/linux-spi/20220525163946.48ea40c9@erd992/T/
Current behavior is that spi-mem operations do not increment statistics,
neither per-controller nor per-device, if ->exec_op() is used. For
operations that do NOT use ->exec_op(), stats are increased as the
usual spi_sync() is called.
The newly implemented spi_mem_add_op_stats() function is strongly
inspired by spi_statistics_add_transfer_stats(); locking logic and
l2len computation comes from there.
Statistics that are being filled: bytes{,_rx,_tx}, messages, transfers,
errors, timedout, transfer_bytes_histo_*.
Note about messages & transfers counters: in the fallback to spi_sync()
case, there are from 1 to 4 transfers per message. We only register one
big transfer in the ->exec_op() case as that is closer to reality.
This patch is NOT touching:
- spi_async, spi_sync, spi_sync_immediate: those counters describe
precise function calls, incrementing them would be lying. I believe
comparing the messages counter to spi_async+spi_sync is a good way
to detect ->exec_op() calls, but I might be missing edge cases
knowledge.
- transfers_split_maxsize: splitting cannot happen if ->exec_op() is
provided.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216-spi-mem-stats-v2-1-9256dfe4887d@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the AXI SPI Engine driver, compiling the message is an expensive
operation. Previously, it was done per message transfer in the
prepare_message hook. This patch moves the message compile to the
optimize_message hook so that it is only done once per message in
cases where the peripheral driver calls spi_optimize_message().
This can be a significant performance improvement for some peripherals.
For example, the ad7380 driver saw a 13% improvement in throughput
when using the AXI SPI Engine driver with this patch.
Since we now need two message states, one for the optimization stage
that doesn't change for the lifetime of the message and one that is
reset on each transfer for managing the current transfer state, the old
msg->state is split into msg->opt_state and spi_engine->msg_state. The
latter is included in the driver struct now since there is only one
current message at a time that can ever use it and it is in a hot path
so avoiding allocating a new one on each message transfer saves a few
cpu cycles and lets us get rid of the prepare_message callback.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://msgid.link/r/20240219-mainline-spi-precook-message-v2-4-4a762c6701b9@baylibre.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since splitting transfers was moved to spi_optimize_message() in the
core SPI code, we now need to use the optimize_message callback in the
STM32 SPI driver to ensure that the operation is only performed once
when spi_optimize_message() is used by peripheral drivers explicitly.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://msgid.link/r/20240219-mainline-spi-precook-message-v2-3-4a762c6701b9@baylibre.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Splitting transfers is an expensive operation so we can potentially
optimize it by doing it only once per optimization of the message
instead of repeating each time the message is transferred.
The transfer splitting functions are currently the only user of
spi_res_alloc() so spi_res_release() can be safely moved at this time
from spi_finalize_current_message() to spi_unoptimize_message().
The doc comments of the public functions for splitting transfers are
also updated so that callers will know when it is safe to call them
to ensure proper resource management.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://msgid.link/r/20240219-mainline-spi-precook-message-v2-2-4a762c6701b9@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds a new spi_optimize_message() function that can be used to
optimize SPI messages that are used more than once. Peripheral drivers
that use the same message multiple times can use this API to perform SPI
message validation and controller-specific optimizations once and then
reuse the message while avoiding the overhead of revalidating the
message on each spi_(a)sync() call.
Internally, the SPI core will also call this function for each message
if the peripheral driver did not explicitly call it. This is done to so
that controller drivers don't have to have multiple code paths for
optimized and non-optimized messages.
A hook is provided for controller drivers to perform controller-specific
optimizations.
Suggested-by: Martin Sperl <kernel@martin.sperl.org>
Link: https://lore.kernel.org/linux-spi/39DEC004-10A1-47EF-9D77-276188D2580C@martin.sperl.org/
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://msgid.link/r/20240219-mainline-spi-precook-message-v2-1-4a762c6701b9@baylibre.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Set the ->num_chipselect field in struct cqspi_st and struct
spi_controller to the current number of chip-select. The value is
dependent on declared flashes in devicetree.
Previously, the num-cs property from devicetree or the maximum value was
being reported.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://msgid.link/r/20240209-cdns-qspi-cs-v1-3-a4f9dfed9ab4@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Change the maximum chip-select count in cadence-qspi to 4 instead of 16.
The value gets used as default ->num_chipselect when the num-cs DT
property isn't received from devicetree. It also determines the
cqspi->f_pdata array size.
Hardware only supports values up to 4; see cqspi_chipselect() that sets
CS using a one-bit-per-CS 4-bit register field.
Add a static_assert() call as a defensive measure to ensure we stay
under the SPI subsystem limit. It got set to 4 when introduced in
4d8ff6b099 ("spi: Add multi-cs memories support in SPI core") and
later increased to 16 in 2f8c7c3715 ("spi: Raise limit on number of
chip selects").
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://msgid.link/r/20240209-cdns-qspi-cs-v1-2-a4f9dfed9ab4@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Check each flash CS against the num-cs property from devicetree.
Fallback to the driver max supported value (CQSPI_MAX_CHIPSELECT) if
num-cs isn't present.
cqspi->num_chipselect is set in cqspi_of_get_pdata() to the num-cs
devicetree property, or to CQSPI_MAX_CHIPSELECT if num-cs is not set.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://msgid.link/r/20240209-cdns-qspi-cs-v1-1-a4f9dfed9ab4@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The change to use "target" requires an underline to be extended by
one more character to fix a documentation build warning:
Documentation/spi/spi-summary.rst:274: WARNING: Title underline too short.
Declare target Devices
^^^^^^^^^^^^^^^^^^^^^
Fixes: hash ("spi: Update the "master/slave" terminology in documentation")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Dhruva Gole <d-gole@ti.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://msgid.link/r/20240216051637.10920-1-rdunlap@infradead.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Update the master/slave terminology wherever possible to adopt usage of
the controller/host/target. Some parts have been left untouched because
they were sysfs entries and will probably end up being inaccurate if
simply replaced here.
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Link: https://msgid.link/r/20240215085404.1711976-1-d-gole@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The variable id len being initialized with a value that is never read,
it is being re-assigned later on in a for-loop. The initialization is
redundant and can be removed.
Cleans up clang scan build warning:
drivers/spi/spi-dw-dma.c:580:17: warning: Although the value stored
to 'len' is used in the enclosing expression, the value is never
actually read from 'len' [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://msgid.link/r/20240215131603.2062332-1-colin.i.king@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In commit 8caab75fd2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. Recent work by Uwe
completes this renaming. However, there are plenty of leftovers in
the comments and in-code documentation. Update them as well.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240209165423.2305493-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
This series finishes off the removal of some of the legacy names for
SPI controllers and devices.
pci1xxxx_spi_transfer_with_dma adds DMA support to copy the data between
host cpu buffer and SPI IO Buffer.
On DMA Completion interrupt, the next SPI transaction is initiated in isr.
Helper functions pci1xxxx_spi_setup, pci1xxxx_spi_setup_dma_from_io,
pci1xxxx_spi_setup_dma_to_io and pci1xxxx_start_spi_xfer are added for
setting up spi, setting up dma operations, and to start spi transfer
respectively. In the existing implementation, codes are replaced with
helper functions wherever applicable.
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Link: https://lore.kernel.org/r/20240207080621.30742-3-thangaraj.s@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In PCI1xxxx C0, support for DMA in PCIe endpoint is added
to enhance the SPI performance. With this support, the
performance is improved from 6Mbps to 17Mbps with 20Mhz clock.
- DMA Supports two Channels, 0 and 1
- SPI Instance 0 uses chan 0 and SPI Instance 1 uses chan 1
- DMA can be used only if SPI is mapped to PF0 in the multi
function endpoint and the MSI interrupt is supported
- MSI interrupt of one of the SPI instance is assigned to the DMA
and both channels 0 and 1 share the same irq, the MSI address and
MSI Data of the irq is obtained and stored in DMA registers to
generate interrupt
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Link: https://lore.kernel.org/r/20240207080621.30742-2-thangaraj.s@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for GS101 SPI. GS101 integrates 16 SPI nodes, all with 64
bytes FIFOs. GS101 allows just 32 bit register accesses, otherwise a
Serror Interrupt is raised. Do the write reg accesses in 32 bits.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20240207111516.2563218-5-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Allow SoCs that require 32 bits register accesses to write data in
chunks of 8 or 16 bits. One SoC that requires 32 bit register accesses
is the google gs101. The operation is rare, thus open code it in the
driver rather than making it generic (through asm-generic/io.h).
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20240207111516.2563218-4-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
There are SoCs (gs101) that allow only 32 bit register accesses. As the
requirement is rare enough, for those SoCs we'll open code in the driver
some s3c64xx_iowrite{8,16}_32_rep() accessors. Prepare for such addition.
Suggested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20240207111516.2563218-3-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add "google,gs101-spi" dedicated compatible for representing SPI of
Google GS101 SoC.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20240207111516.2563218-2-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
val &= ~mask;
val |= mask;
is equivalent to:
val |= mask;
Drop the superfluous bitwise NOT operation.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20240207120431.2766269-18-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
S3C64XX_SPI_TRAILCNT brings no benefit in terms of name over
S3C64XX_SPI_MAX_TRAILCNT. Remove the duplicated definition.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20240207120431.2766269-17-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
"samsung,spi-src-clk" and "num-cs" are optional dt properties. Downgrade
the message from warning to debug message.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20240207120431.2766269-16-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Drop the blank line and move the logical operation in the body of the
function rather than in initialization list.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20240207120431.2766269-15-tudor.ambarus@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
