Add devicetree binding documentation for Socionext F_OSPI SPI flash
controller.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221124003351.7792-2-hayashi.kunihiko@socionext.comSigned-off-by: Mark Brown <broonie@kernel.org>

Introduce Socionext F_OSPI controller driver. This controller is used to
communicate with slave devices such as SPI Flash memories. It supports
4 slave devices and up to 8-bit wide bus, but supports master mode only.

This driver uses spi-mem framework for SPI flash memory access, and
can only operate indirect access mode and single data rate mode.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/20221124003351.7792-3-hayashi.kunihiko@socionext.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge branch 'i2c/client_device_id_helper-immutable' of https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux into spi-6.2

so we can use the new API in the I2C cleanup.

The at91 QSPI IP uses a default value of half of the period of the QSPI
clock period for the cs-setup time, which is not always enough, an example
being the sst26vf064b SPI NOR flash which requires a minimum cs-setup time
of 5 ns. It was observed that none of the at91 SoCs can fulfill the
minimum CS setup time for the aforementioned flash, as they operate at
high frequencies and half a period does not suffice for the required CS
setup time. Add support for configuring the CS timing in the controller.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20221117105249.115649-5-tudor.ambarus@microchip.comSigned-off-by: Mark Brown <broonie@kernel.org>

commit 4ccf3598 ("spi: remove spi_set_cs_timing()"), removed the
method as noboby used it. Nobody used it probably because some SPI
controllers use some default large cs-setup time that covers the usual
cs-setup time required by the spi devices. There are though SPI controllers
that have a smaller granularity for the cs-setup time and their default
value can't fulfill the spi device requirements. That's the case for the
at91 QSPI IPs where the default cs-setup time is half of the QSPI clock
period. This was observed when using an sst26vf064b SPI NOR flash which
needs a spi-cs-setup-ns = <7>; in order to be operated close to its maximum
104 MHz frequency.

Call spi_set_cs_timing() in spi_setup() just before calling spi_set_cs(),
as the latter needs the CS timings already set.
If spi->controller->set_cs_timing is not set, the method will return 0.
There's no functional impact expected for the existing drivers. Even if the
spi-mt65xx.c and spi-tegra114.c drivers set the set_cs_timing method,
there's no user for them as of now. The only tested user of this support
will be a SPI NOR flash that comunicates with the Atmel QSPI controller for
which the support follows in the next patches.

One will notice that this support is a bit different from the one that was
removed in commit 4ccf3598 ("spi: remove spi_set_cs_timing()"),
because this patch adapts to the changes done after the removal: the move
of the cs delays to the spi device, the retirement of the lelgacy GPIO
handling. The mutex handling was removed from spi_set_cs_timing() because
we now always call spi_set_cs_timing() in spi_setup(), which already
handles the spi->controller->io_mutex, so use the mutex handling from
spi_setup().
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20221117105249.115649-4-tudor.ambarus@microchip.comSigned-off-by: Mark Brown <broonie@kernel.org>

SPI NOR flashes have specific cs-setup time requirements without which
they can't work at frequencies close to their maximum supported frequency,
as they miss the first bits of the instruction command. Unrecognized
commands are ignored, thus the flash will be unresponsive. Introduce the
spi-cs-setup-ns property to allow spi devices to specify their cs setup
time.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20221117105249.115649-3-tudor.ambarus@microchip.comSigned-off-by: Mark Brown <broonie@kernel.org>

SPI NOR flashes have specific cs-setup time requirements without which
they can't work at frequencies close to their maximum supported frequency,
as they miss the first bits of the instruction command. Unrecognized
commands are ignored, thus the flash will be unresponsive. Introduce the
spi-cs-setup-ns property to allow spi devices to specify their cs setup
time.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20221117105249.115649-2-tudor.ambarus@microchip.comSigned-off-by: Mark Brown <broonie@kernel.org>

Make the driver be able to bit-bang a GPIO for the Chip Select pin of
select peripherals.

The GPIO value is driven by the driver in that case, and none of the
hardware Chip Select bits will be populated in the PUSHR register for
the TX commands constructed for this peripheral.
Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20221111211356.545026-1-vladimir.oltean@nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

Introduces new helper function to aid in .probe_new() refactors. In order
to use existing i2c_get_device_id() on the probe callback, the device
match table needs to be accessible in that function, which would require
bigger refactors in some drivers using the deprecated .probe callback.

This issue was discussed in more detail in the IIO mailing list.

Link: https://lore.kernel.org/all/20221023132302.911644-11-u.kleine-koenig@pengutronix.de/Suggested-by: Nuno Sá <noname.nuno@gmail.com>
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Angel Iglesias <ang.iglesiasg@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>

The timeout value of the current dma read is unreasonable. For example,
If the spi flash clock is 26Mhz, It will takes about 1.3ms to read a
4KB data in spi mode. But the actual measurement exceeds 50s when a
dma read timeout is encountered.

In order to be more accurately, It is necessary to use usecs_to_jiffies,
After modification, the measured timeout value is about 130ms.
Signed-off-by: bayi cheng <bayi.cheng@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221114081327.25750-1-bayi.cheng@mediatek.comSigned-off-by: Mark Brown <broonie@kernel.org>

Mixing SPI slave/target handlers and SPI slave/target controllers using
legacy and modern naming does not work well: there are now two different
callbacks for aborting a slave/target operation, of which only one is
populated, while spi_{slave,target}_abort() check and use only one,
which may be the unpopulated one.

Fix this by merging the slave/target abort callbacks into a single
callback using a union, like is already done for the slave/target flags.

Fixes: b8d3b056 ("spi: introduce new helpers with using modern naming")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/809c82d54b85dd87ef7ee69fc93016085be85cec.1667555967.git.geert+renesas@glider.beSigned-off-by: Mark Brown <broonie@kernel.org>

Simple typo, simple fix.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Link: https://lore.kernel.org/r/20221103190052.915755-1-j.neuschaefer@gmx.netSigned-off-by: Mark Brown <broonie@kernel.org>

Don't populate the const array ls1028a_soc_attr on the stack, instead
make it static. Also makes the object code smaller.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Acked-by: Han Xu <han.xu@nxp.com>
Link: https://lore.kernel.org/r/20221102152904.143423-1-colin.i.king@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

For using modern names host/target to instead of all the legacy names,
I think it takes 3 steps:
  - step1: introduce new helpers with modern naming.
  - step2: switch to use these new helpers in all drivers.
  - step3: remove all legacy helpers and update all legacy names.

This patch is for step1, it introduces new helpers with host/target
naming for drivers using.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221011092204.950288-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

struct spi_master has been renamed to struct spi_controller. Update the
reference in spi.rst to make it clickable again.

Fixes: 8caab75f ("spi: Generalize SPI "master" to "controller"")
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Link: https://lore.kernel.org/r/20221101173252.1069294-1-j.neuschaefer@gmx.netSigned-off-by: Mark Brown <broonie@kernel.org>

The node name for flash memories has been standardized to "flash@...".
Fix the example in nuvoton,npcm-fiu.txt accordingly.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Link: https://lore.kernel.org/r/20221031222559.199509-1-j.neuschaefer@gmx.netSigned-off-by: Mark Brown <broonie@kernel.org>

Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221029071720.3041094-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221029071529.3019626-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now that the 32bit UP oddity is gone and 32bit uses always a sequence
count, there is no need for the fetch_irq() variants anymore.

Convert to the regular interface.

Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20221026122951.331638-1-bigeasy@linutronix.deSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

Currently the SPI PXA2xx devices on Intel platforms can be instantiated
via the following paths:
 1) as ACPI LPSS device on Haswell, Bay Trail and Cherry Trail;
 2) as ACPI LPSS device on the Sky Lake and newer;
 3) as PCI LPSS device on Haswell, Bay Trail and Cherry Trail;
 4) as PCI LPSS device on the Sky Lake and newer;
 5) as PCI device via ID table.

Each of these cases provides some platform related data differently,
i.e.:
 1) via drivers/acpi/acpi_lpss.c and drivers/spi/spi-pxa2xx.c
 2) via drivers/mfd/intel-lpss-acpi.c
 3) via drivers/spi/spi-pxa2xx-pci.c
 4) via drivers/mfd/intel-lpss-pci.c and drivers/spi/spi-pxa2xx.c
 5) via drivers/spi/spi-pxa2xx-pci.c

This approach has two downsides:

a) there is no data propagated in the case #2 because we can't have
   two or more drivers to match the same ACPI ID and hence some cases
   are still not supported (Sky Lake and newer ACPI enabled LPSS);

b) the data is duplicated over two drivers in the cases #1 & #4 and,
   besides to be a bloatware, it is error prone (e.g. Lakefield has
   a wrong data right now due to missed PCI entry in the spi-pxa2xx.c).

This series fixes the downsides, and enables previously unsupported
cases.

There is no code that uses ID tables directly, except the
struct device_driver at the end of the file. Hence, move
tables closer to its user. It's always possible to access
them via pointer to a platform device.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20221021190018.63646-5-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Since the PCI enumerated devices provide a property with SSP type,
there is no more necessity to bear the copy of the ID table here.
Remove it for good.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20221021190018.63646-4-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Allow to set the Intel SSP type by reading the property.
Only apply this to the known MFD enumerated LPSS devices.

The check is done by the looking for the specifically
named IO memory resource provided by upper layer. This
won't be an issue in the future because we strictly
prioritize the order in which we are looking for the SSP
type in the code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20221021190018.63646-3-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Currently we blindly apply the SSP type value from any source of the
information. Increase robustness by validating the value before use.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20221021190018.63646-2-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Use the devm_platform_{get_and_}ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource() separately.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221019092635.1176622-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Amjad Ouled-Ameur <aouledameur@baylibre.com>:

Between SPI transactions, all SPI pins are in HiZ state. When using the SS
signal from the SPICC controller it's not an issue because when the
transaction resumes all pins come back to the right state at the same time
as SS.

The problem is when we use CS as a GPIO. In fact, between the GPIO CS
state change and SPI pins state change from idle, you can have a missing or
spurious clock transition.

Set a bias on the clock depending on the clock polarity requested before CS
goes active, by passing a special "idle-low" and "idle-high" pinctrl state
and setting the right state at a start of a message.

Merge series from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

This series has a couple of cleanups for the pxa2xx driver.

Between SPI transactions, all SPI pins are in HiZ state. When using the SS
signal from the SPICC controller it's not an issue because when the
transaction resumes all pins come back to the right state at the same time
as SS.

The problem is when we use CS as a GPIO. In fact, between the GPIO CS
state change and SPI pins state change from idle, you can have a missing or
spurious clock transition.

Set a bias on the clock depending on the clock polarity requested before CS
goes active, by passing a special "idle-low" and "idle-high" pinctrl state
and setting the right state at a start of a message
Reported-by: Da Xue <da@libre.computer>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
Link: https://lore.kernel.org/r/20221004-up-aml-fix-spi-v4-2-0342d8e10c49@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>

SPI pins of the SPICC Controller in Meson-GX needs to be controlled by
pin biais when idle. Therefore define three pinctrl names:
- default: SPI pins are controlled by spi function.
- idle-high: SCLK pin is pulled-up, but MOSI/MISO are still controlled
by spi function.
- idle-low: SCLK pin is pulled-down, but MOSI/MISO are still controlled
by spi function.
Reported-by: Da Xue <da@libre.computer>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221004-up-aml-fix-spi-v4-1-0342d8e10c49@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>

In commit 7a908832 ("spi: imx: add fallback feature") the last
user of the struct spi_imx_devtype_data::disable_dma callback was
removed. However the disable_dma member of struct spi_imx_devtype_data
and the callback itself was not removed.

Remove struct spi_imx_devtype_data::disable_dma and mx51_disable_dma()
as they are unused.

Cc: Robin Gong <yibin.gong@nxp.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/r/20221021131051.1777984-1-mkl@pengutronix.deSigned-off-by: Mark Brown <broonie@kernel.org>

Cleaning up the driver to use pm_ptr() macro instead of ifdeffery
that makes it simpler and allows the compiler to remove those functions
if built without CONFIG_PM and CONFIG_PM_SLEEP support.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20221020194500.10225-6-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

We have a temporary variable to keep a pointer to a struct device in
the pxa2xx_spi_init_pdata(). Use it consistently there.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20221020194500.10225-5-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The proposed spi_get_device_match_data() helper is for retrieving
a driver data associated with the ID in an ID table. First, it tries
to get driver data of the device enumerated by firmware interface
(usually Device Tree or ACPI). If none is found it falls back to
the SPI ID table matching.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20221020195421.10482-1-andriy.shevchenko@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>:

A bunch of improvements to the driver:

- Fix kernel-doc warnings in GQSPI driver.
- Avoid setting CPOL, CPHA & baud rate multiple times.
- Add Versal platform support in GQSPI driver.
- Add tap delay support in GQSPI driver.

Use the devm_platform_get_and_ioremap_resource() helper instead of calling
platform_get_resource() and devm_ioremap_resource() separately.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221019093318.1183190-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add tap delay support for GQSPI controller on Versal platform.
Signed-off-by: Naga Sureshkumar Relli <nagasure@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Link: https://lore.kernel.org/r/20221011062040.12116-8-amit.kumar-mahapatra@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add new compatible to support QSPI controller on Xilinx Versal SoCs.
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221011062040.12116-7-amit.kumar-mahapatra@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

GQSPI controller uses the internal clock for loopback mode. The loopback
mode is used with the high-speed Quad SPI timing mode, where the memory
interface clock needs to be greater than 40 MHz. Based on the tap delay
value programmed, the internal clock is delayed and used for capturing
the data.
Based upon the frequency of operation set the recommended tap delay
values in GQSPI driver.
Signed-off-by: Naga Sureshkumar Relli <nagasure@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Link: https://lore.kernel.org/r/20221011062040.12116-6-amit.kumar-mahapatra@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add support for QSPI ioctl functions and enums.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Link: https://lore.kernel.org/r/20221011062040.12116-5-amit.kumar-mahapatra@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>

During every transfer the GQSPI driver configures the baud rate value. But
when there is no change in the SPI clock frequency the driver should avoid
rewriting the same baud rate value to the configuration register. Update
GQSPI driver to rewrite the baud rate value if there is any change in SPI
clock frequency.
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Link: https://lore.kernel.org/r/20221011062040.12116-4-amit.kumar-mahapatra@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>