summaryrefslogtreecommitdiff
path: root/include/linux/spi
AgeCommit message (Collapse)Author
2021-02-22Merge tag 'backlight-next-5.12' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight Pull backlight updates from Lee Jones: "New Functionality: - Convert to GPIO descriptors Fix-ups: - Trivial: fix coding style in sky81452-backlight - Ensure backlight state is known on bring-up in ktd253 - Use common platform API in qcom-wled and fbdev" * tag 'backlight-next-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight: backlight/video: Use Platform getter/setter functions backlight: ktd253: Bring up in a known state backlight: sky81452-backlight: Convert comma to semicolon backlight: lms283gf05: Convert to GPIO descriptors
2021-02-22Merge tag 'spi-v5.12' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi updates from Mark Brown: "The main focus of this release from a framework point of view has been spi-mem where we've acquired support for a few new hardware features which enable better performance on suitable hardware. Otherwise mostly thanks to Arnd's cleanup efforts on old platforms we've removed several obsolete drivers which just about balance out the newer drivers we've added this cycle. Summary: - Allow drivers to flag if they are unidirectional. - Support for DTR mode and hardware acceleration of dummy cycles in spi-mem. - Support for Allwinder H616, Intel Lightning Mountain, nVidia Tegra QuadSPI, Realtek RTL838x and RTL839x. - Removal of obsolete EFM32, Txx9 and SIRF Prima and Atlas drivers" * tag 'spi-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (76 commits) spi: Skip zero-length transfers in spi_transfer_one_message() spi: dw: Avoid stack content exposure spi: cadence-quadspi: Use spi_mem_dtr_supports_op() spi: spi-mem: add spi_mem_dtr_supports_op() spi: atmel-quadspi: Disable the QSPI IP at suspend() spi: pxa2xx: Add IDs for the controllers found on Intel Lynxpoint spi: pxa2xx: Fix the controller numbering for Wildcat Point spi: Change provied to provided in the file spi.h spi: mediatek: add set_cs_timing support spi: support CS timing for HW & SW mode spi: add power control when set_cs_timing spi: stm32: make spurious and overrun interrupts visible spi: stm32h7: replace private SPI_1HZ_NS with NSEC_PER_SEC spi: stm32: defer probe for reset spi: stm32: driver uses reset controller only at init spi: stm32h7: ensure message are smaller than max size spi: stm32: use bitfield macros spi: stm32: do not mandate cs_gpio spi: stm32: properly handle 0 byte transfer spi: clps711xx: remove redundant white-space ...
2021-02-11spi: spi-mem: add spi_mem_dtr_supports_op()Pratyush Yadav
spi_mem_default_supports_op() rejects DTR ops by default to ensure that the controller drivers that haven't been updated with DTR support continue to reject them. It also makes sure that controllers that don't support DTR mode at all (which is most of them at the moment) also reject them. This means that controller drivers that want to support DTR mode can't use spi_mem_default_supports_op(). Driver authors have to roll their own supports_op() function and mimic the buswidth checks. See spi-cadence-quadspi.c for example. Or even worse, driver authors might skip it completely or get it wrong. Add spi_mem_dtr_supports_op(). It provides a basic sanity check for DTR ops and performs the buswidth requirement check. Move the logic for checking buswidth in spi_mem_default_supports_op() to a separate function so the logic is not repeated twice. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210204141218.32229-1-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-08spi: Change provied to provided in the file spi.hBhaskar Chowdhury
s/provied/provided/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Link: https://lore.kernel.org/r/20210208114928.32241-1-unixbhaskar@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-26serial: ifx6x60: Remove driver for deprecated platformAndy Shevchenko
Intel Moorestown and Medfield are quite old Intel Atom based 32-bit platforms, which were in limited use in some Android phones, tablets and consumer electronics more than eight years ago. There are no bugs or problems ever reported outside from Intel for breaking any of that platforms for years. It seems no real users exists who run more or less fresh kernel on it. The commit 05f4434bc130 ("ASoC: Intel: remove mfld_machine") also in align with this theory. Due to above and to reduce a burden of supporting outdated drivers we remove the support of outdated platforms completely. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210125150238.16980-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-20backlight: lms283gf05: Convert to GPIO descriptorsLinus Walleij
This converts the lms283gf05 backlight driver to use GPIO descriptors and switches the single PXA Palm Z2 device over to defining these. Since the platform data was only used to convey GPIO information we can delete the platform data header. Notice that we define the proper active low semantics in the board file GPIO descriptor table (active low) and assert the reset line by bringing it to "1" (asserted). Cc: Marek Vasut <marex@denx.de> Cc: Haojian Zhuang <haojian.zhuang@gmail.com> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Daniel Mack <daniel@zonque.org> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2021-01-06spi: spi-mem: Mark dummy transfers by setting dummy_data bitSowjanya Komatineni
This patch marks dummy transfer by setting dummy_data bit to 1. Controllers supporting dummy transfer by hardware use this bit field to skip software transfer of dummy bytes and use hardware dummy bytes transfer. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1608585459-17250-6-git-send-email-skomatineni@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-28spi: Add SPI_NO_TX/RX supportDragos Bogdan
Transmit/receive only is a valid SPI mode. For example, the MOSI/TX line might be missing from an ADC while for a DAC the MISO/RX line may be optional. This patch adds these two new modes: SPI_NO_TX and SPI_NO_RX. This way, the drivers will be able to identify if any of these two lines is missing and to adjust the transfers accordingly. Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201221152936.53873-2-alexandru.ardelean@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-28spi: uapi: unify SPI modes into a single spi.h headerAlexandru Ardelean
This change moves all the SPI mode bits into a separate 'spi.h' header in uAPI. This is meant to re-use these definitions inside the kernel as well as export them to userspace (via uAPI). The SPI mode definitions have usually been duplicated between between 'include/linux/spi/spi.h' and 'include/uapi/linux/spi/spidev.h', so whenever adding a new entry, this would need to be put in both headers. They've been moved from 'include/linux/spi/spi.h', since that seems a bit more complete; the bits have descriptions and there is the SPI_MODE_X_MASK. This change also does a conversion of these bitfields to _BITUL() macro. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20201221152936.53873-1-alexandru.ardelean@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-27Merge branch 'for-5.10' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.11
2020-11-12spi: Introduce device-managed SPI controller allocationLukas Wunner
SPI driver probing currently comprises two steps, whereas removal comprises only one step: spi_alloc_master() spi_register_controller() spi_unregister_controller() That's because spi_unregister_controller() calls device_unregister() instead of device_del(), thereby releasing the reference on the spi_controller which was obtained by spi_alloc_master(). An SPI driver's private data is contained in the same memory allocation as the spi_controller struct. Thus, once spi_unregister_controller() has been called, the private data is inaccessible. But some drivers need to access it after spi_unregister_controller() to perform further teardown steps. Introduce devm_spi_alloc_master() and devm_spi_alloc_slave(), which release a reference on the spi_controller struct only after the driver has unbound, thereby keeping the memory allocation accessible. Change spi_unregister_controller() to not release a reference if the spi_controller was allocated by one of these new devm functions. The present commit is small enough to be backportable to stable. It allows fixing drivers which use the private data in their ->remove() hook after it's been freed. It also allows fixing drivers which neglect to release a reference on the spi_controller in the probe error path. Long-term, most SPI drivers shall be moved over to the devm functions introduced herein. The few that can't shall be changed in a treewide commit to explicitly release the last reference on the controller. That commit shall amend spi_unregister_controller() to no longer release a reference, thereby completing the migration. As a result, the behaviour will be less surprising and more consistent with subsystems such as IIO, which also includes the private data in the allocation of the generic iio_dev struct, but calls device_del() in iio_device_unregister(). Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/272bae2ef08abd21388c98e23729886663d19192.1605121038.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-11spi: introduce SPI_MODE_X_MASK macroOleksij Rempel
Provide a macro to filter all SPI_MODE_0,1,2,3 mode in one run. The latest SPI framework will parse the devicetree in following call sequence: of_register_spi_device() -> of_spi_parse_dt() So, driver do not need to pars the devicetree and will get prepared flags in the probe. On one hand it is good far most drivers. On other hand some drivers need to filter flags provide by SPI framework and apply know to work flags. This drivers may use SPI_MODE_X_MASK to filter MODE flags and set own, known flags: spi->flags &= ~SPI_MODE_X_MASK; spi->flags |= SPI_MODE_0; Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20201027095724.18654-2-o.rempel@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-24Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds
Pull ARM SoC platform updates from Olof Johansson: "SoC changes, a substantial part of this is cleanup of some of the older platforms that used to have a bunch of board files. In particular: - Remove non-DT i.MX platforms that haven't seen activity in years, it's time to remove them. - A bunch of cleanup and removal of platform data for TI/OMAP platforms, moving over to genpd for power/reset control (yay!) - Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them closer to multiplatform support (not quite there yet, but getting close). There are a few other changes too, smaller fixlets, etc. For new platform support, the primary ones are: - New SoC: Hisilicon SD5203, ARM926EJ-S platform. - Cpufreq support for i.MX7ULP" * tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (121 commits) ARM: mstar: Select MStar intc ARM: stm32: Replace HTTP links with HTTPS ones ARM: debug: add UART early console support for SD5203 ARM: hisi: add support for SD5203 SoC ARM: omap3: enable off mode automatically clk: imx: imx35: Remove mx35_clocks_init() clk: imx: imx31: Remove mx31_clocks_init() clk: imx: imx27: Remove mx27_clocks_init() ARM: imx: Remove unused definitions ARM: imx35: Retrieve the IIM base address from devicetree ARM: imx3: Retrieve the AVIC base address from devicetree ARM: imx3: Retrieve the CCM base address from devicetree ARM: imx31: Retrieve the IIM base address from devicetree ARM: imx27: Retrieve the CCM base address from devicetree ARM: imx27: Retrieve the SYSCTRL base address from devicetree ARM: s3c64xx: bring back notes from removed debug-macro.S ARM: s3c24xx: fix Wunused-variable warning on !MMU ARM: samsung: fix PM debug build with DEBUG_LL but !MMU MAINTAINERS: mark linux-samsung-soc list non-moderated ARM: imx: Remove remnant board file support pieces ...
2020-08-28eeprom: at25: allow page sizes greater than 16 bitChristian Eggers
Storage technologies like FRAM have no "write pages", the whole chip can be written within one SPI transfer. For these chips, the page size can be set equal to the device size. Currently available devices are already bigger than 64 kiB. Signed-off-by: Christian Eggers <ceggers@arri.de> Link: https://lore.kernel.org/r/20200727111218.26926-1-ceggers@arri.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-20ARM: s3c24xx: spi: avoid hardcoding fiq number in driverArnd Bergmann
The IRQ_EINT0 constant is a platform detail that is defined in mach/irqs.h and not visible to drivers once that header is made private. Since the same calculation already happens in s3c24xx_set_fiq, just return the value from there. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200806182059.2431-31-krzk@kernel.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-08-19ARM: s3c24xx: move spi fiq handler into platformArnd Bergmann
The fiq handler needs access to some register definitions that should not be used directly by device drivers. Since this is closely related to the irqchip driver anyway, move it into the same place. Signed-off-by: Arnd Bergmann <arnd@arndb.de> [krzk: Add a header guard in include/linux/spi/s3c24xx-fiq.h, fix SPDX comment style, update maintainer's entry] Co-developed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200806182059.2431-23-krzk%40kernel.org Acked-by: Mark Brown <broonie@kernel.org>
2020-07-27spi: correct kernel-doc inconsistencyColton Lewis
Silence documentation build warnings by correcting kernel-doc comment for spi_transfer struct. Signed-off-by: Colton Lewis <colton.w.lewis@protonmail.com> Link: https://lore.kernel.org/r/20200725050242.279548-1-colton.w.lewis@protonmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-17spi: fix duplicated word in <linux/spi/spi.h>Randy Dunlap
Change doubled word "as" to "as a". Change "Return: Return:" in kernel-doc notation to have only one "Return:". Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Mark Brown <broonie@kernel.org> Cc: linux-spi@vger.kernel.org Link: https://lore.kernel.org/r/40354d64-be71-3952-a980-63a76a278145@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-14Merge series "mtd: spi-nor: add xSPI Octal DTR support" from Pratyush Yadav ↵Mark Brown
<p.yadav@ti.com>: Hi, This series adds support for octal DTR flashes in the spi-nor framework, and then adds hooks for the Cypress Semper and Mircom Xcella flashes to allow running them in octal DTR mode. This series assumes that the flash is handed to the kernel in Legacy SPI mode. Tested on TI J721e EVM with 1-bit ECC on the Cypress flash. Changes in v10: - Rebase on latest linux-next/master. Drop a couple patches that made it in the previous release. - Move the code that sets 20 dummy cycles for MT35XU512ABA to its octal enable function. This way, if the controller doesn't support 8D mode 20 dummy cycles won't be used. Changes in v9: - Do not use '& 0xff' to get the opcode LSB in spi-mxic and spi-zynq-qspi. The cast to u8 will do that anyway. - Do not use if (opcode) as a check for whether the command phase exists in spi-zynq-qspi because the opcode 0 can be valid. Use the new cmd.nbytes instead. Changes in v8: - Move controller changes in spi-mxic to the commit which introduces 2-byte opcodes to avoid problems when bisecting. - Replace usage of sizeof(op->cmd.opcode) with op->cmd.nbytes. - Extract opcode in spi-zynq-qspi instead of using &op->cmd.opcode. Changes in v7: - Reject ops with more than 1 command byte in spi_mem_default_supports_op(). - Reject ops with more than 1 command byte in atmel and mtk controllers. - Reject ops with 0 command bytes in spi_mem_check_op(). - Set cmd.nbytes to 1 when using SPI_MEM_OP_CMD(). - Avoid endianness problems in spi-mxic. Changes in v6: - Instead of hard-coding 8D-8D-8D Fast Read dummy cycles to 20, find them out from the Profile 1.0 table. Changes in v5: - Do not enable stateful X-X-X modes if the reset line is broken. - Instead of setting SNOR_READ_HWCAPS_8_8_8_DTR from Profile 1.0 table parsing, do it in spi_nor_info_init_params() instead based on the SPI_NOR_OCTAL_DTR_READ flag instead. - Set SNOR_HWCAPS_PP_8_8_8_DTR in s28hs post_sfdp hook since this capability is no longer set in Profile 1.0 parsing. - Instead of just checking for spi_nor_get_protocol_width() in spi_nor_octal_dtr_enable(), make sure the protocol is SNOR_PROTO_8_8_8_DTR since get_protocol_width() only cares about data width. - Drop flag SPI_NOR_SOFT_RESET. Instead, discover soft reset capability via BFPT. - Do not make an invalid Quad Enable BFPT field a fatal error. Silently ignore it by assuming no quad enable bit is present. - Set dummy cycles for Cypress Semper flash to 24 instead of 20. This allows for 200MHz operation in 8D mode compared to the 166MHz with 20. - Rename spi_nor_cypress_octal_enable() to spi_nor_cypress_octal_dtr_enable(). - Update spi-mtk-nor.c to reject DTR ops since it doesn't call spi_mem_default_supports_op(). Changes in v4: - Refactor the series to use the new spi-nor framework with the manufacturer-specific bits separated from the core. - Add support for Micron MT35XU512ABA. - Use cmd.nbytes as the criteria of whether the data phase exists or not instead of cmd.buf.in || cmd.buf.out in spi_nor_spimem_setup_op(). - Update Read FSR to use the same dummy cycles and address width as Read SR. - Fix BFPT parsing stopping too early for JESD216 rev B flashes. - Use 2 byte reads for Read SR and FSR commands in DTR mode. Changes in v3: - Drop the DT properties "spi-rx-dtr" and "spi-tx-dtr". Instead, if later a need is felt to disable DTR in case someone has a board with Octal DTR capable flash but does not support DTR transactions for some reason, a property like "spi-no-dtr" can be added. - Remove mode bits SPI_RX_DTR and SPI_TX_DTR. - Remove the Cadence Quadspi controller patch to un-block this series. I will submit it as a separate patch. - Rebase on latest 'master' and fix merge conflicts. - Update read and write dirmap templates to use DTR. - Rename 'is_dtr' to 'dtr'. - Make 'dtr' a bitfield. - Reject DTR ops in spi_mem_default_supports_op(). - Update atmel-quadspi to reject DTR ops. All other controller drivers call spi_mem_default_supports_op() so they will automatically reject DTR ops. - Add support for both enabling and disabling DTR modes. - Perform a Software Reset on flashes that support it when shutting down. - Disable Octal DTR mode on suspend, and re-enable it on resume. - Drop enum 'spi_mem_cmd_ext' and make command opcode u16 instead. Update spi-nor to use the 2-byte command instead of the command extension. Since we still need a "extension type", mode that enum to spi-nor and name it 'spi_nor_cmd_ext'. - Default variable address width to 3 to fix SMPT parsing. - Drop non-volatile change to uniform sector mode and rely on parsing SMPT. Changes in v2: - Add DT properties "spi-rx-dtr" and "spi-tx-dtr" to allow expressing DTR capabilities. - Set the mode bits SPI_RX_DTR and SPI_TX_DTR when we discover the DT properties "spi-rx-dtr" and spi-tx-dtr". - spi_nor_cypress_octal_enable() was updating nor->params.read[] with the intention of setting the correct number of dummy cycles. But this function is called _after_ selecting the read so setting nor->params.read[] will have no effect. So, update nor->read_dummy directly. - Fix spi_nor_spimem_check_readop() and spi_nor_spimem_check_pp() passing nor->read_proto and nor->write_proto to spi_nor_spimem_setup_op() instead of read->proto and pp->proto respectively. - Move the call to cqspi_setup_opcode_ext() inside cqspi_enable_dtr(). This avoids repeating the 'if (f_pdata->is_dtr) cqspi_setup_opcode_ext()...` snippet multiple times. - Call the default 'supports_op()' from cqspi_supports_mem_op(). This makes sure the buswidth requirements are also enforced along with the DTR requirements. - Drop the 'is_dtr' argument from spi_check_dtr_req(). We only call it when a phase is DTR so it is redundant. Pratyush Yadav (17): spi: spi-mem: allow specifying whether an op is DTR or not spi: spi-mem: allow specifying a command's extension spi: atmel-quadspi: reject DTR ops spi: spi-mtk-nor: reject DTR ops mtd: spi-nor: add support for DTR protocol mtd: spi-nor: sfdp: get command opcode extension type from BFPT mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table mtd: spi-nor: core: use dummy cycle and address width info from SFDP mtd: spi-nor: core: do 2 byte reads for SR and FSR in DTR mode mtd: spi-nor: core: enable octal DTR mode when possible mtd: spi-nor: sfdp: do not make invalid quad enable fatal mtd: spi-nor: sfdp: detect Soft Reset sequence support from BFPT mtd: spi-nor: core: perform a Soft Reset on shutdown mtd: spi-nor: core: disable Octal DTR mode on suspend. mtd: spi-nor: core: expose spi_nor_default_setup() in core.h mtd: spi-nor: spansion: add support for Cypress Semper flash mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR mode drivers/mtd/spi-nor/core.c | 446 +++++++++++++++++++++++++++----- drivers/mtd/spi-nor/core.h | 22 ++ drivers/mtd/spi-nor/micron-st.c | 103 +++++++- drivers/mtd/spi-nor/sfdp.c | 131 +++++++++- drivers/mtd/spi-nor/sfdp.h | 8 + drivers/mtd/spi-nor/spansion.c | 166 ++++++++++++ drivers/spi/atmel-quadspi.c | 6 + drivers/spi/spi-mem.c | 16 +- drivers/spi/spi-mtk-nor.c | 10 +- drivers/spi/spi-mxic.c | 3 +- drivers/spi/spi-zynq-qspi.c | 11 +- include/linux/mtd/spi-nor.h | 53 +++- include/linux/spi/spi-mem.h | 14 +- 13 files changed, 889 insertions(+), 100 deletions(-) -- 2.27.0 base-commit: b3a9e3b9622ae10064826dccb4f7a52bd88c7407 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
2020-07-14spi: spi-mem: allow specifying a command's extensionPratyush Yadav
In xSPI mode, flashes expect 2-byte opcodes. The second byte is called the "command extension". There can be 3 types of extensions in xSPI: repeat, invert, and hex. When the extension type is "repeat", the same opcode is sent twice. When it is "invert", the second byte is the inverse of the opcode. When it is "hex" an additional opcode byte based is sent with the command whose value can be anything. So, make opcode a 16-bit value and add a 'nbytes', similar to how multiple address widths are handled. Some places use sizeof(op->cmd.opcode). Replace them with op->cmd.nbytes The spi-mxic and spi-zynq-qspi drivers directly use op->cmd.opcode as a buffer. Now that opcode is a 2-byte field, this can result in different behaviour depending on if the machine is little endian or big endian. Extract the opcode in a local 1-byte variable and use that as the buffer instead. Both these drivers would reject multi-byte opcodes in their supports_op() hook anyway, so we only need to worry about single-byte opcodes for now. The above two changes are put in this commit to keep the series bisectable. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200623183030.26591-3-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-14spi: spi-mem: allow specifying whether an op is DTR or notPratyush Yadav
Each phase is given a separate 'dtr' field so mixed protocols like 4S-4D-4D can be supported. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200623183030.26591-2-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-09spi: use kthread_create_worker() helperMarek Szyprowski
Use kthread_create_worker() helper to simplify the code. It uses the kthread worker API the right way. It will eventually allow to remove the FIXME in kthread_worker_fn() and add more consistency checks in the future. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20200709065007.26896-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-01spi: Avoid setting the chip select if we don't need toDouglas Anderson
On some SPI controllers (like spi-geni-qcom) setting the chip select is a heavy operation. For instance on spi-geni-qcom, with the current code, is was measured as taking upwards of 20 us. Even on SPI controllers that aren't as heavy, setting the chip select is at least something like a MMIO operation over some peripheral bus which isn't as fast as a RAM access. While it would be good to find ways to mitigate problems like this in the drivers for those SPI controllers, it can also be noted that the SPI framework could also help out. Specifically, in some situations, we can see the SPI framework calling the driver's set_cs() with the same parameter several times in a row. This is specifically observed when looking at the way the Chrome OS EC SPI driver (cros_ec_spi) works but other drivers likely trip it to some extent. Let's solve this by caching the chip select state in the core and only calling into the controller if there was a change. We check not only the "enable" state but also the chip select mode (active high or active low) since controllers may care about both the mode and the enable flag in their callback. Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200629164103.1.Ied8e8ad8bbb2df7f947e3bc5ea1c315e041785a2@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-23spi: introduce fallback to pioRobin Gong
Add fallback to pio mode in case dma transfer failed with error status SPI_TRANS_FAIL_NO_START. If spi client driver want to enable this feature please set xfer->error in the proper place such as dmaengine_prep_slave_sg() failure detect(but no any data put into spi bus yet). Besides, add master->fallback checking in its can_dma() so that spi core could switch to pio next time. Please refer to spi-imx.c. Signed-off-by: Robin Gong <yibin.gong@nxp.com> Link: https://lore.kernel.org/r/1592347329-28363-2-git-send-email-yibin.gong@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15spi: altera: add platform data for slave information.Xu Yilun
This patch introduces platform data for slave information, it allows spi-altera to add new spi devices once master registration is done. Signed-off-by: Wu Hao <hao.wu@intel.com> Signed-off-by: Xu Yilun <yilun.xu@intel.com> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> Signed-off-by: Russ Weight <russell.h.weight@intel.com> Reviewed-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/1591845911-10197-4-git-send-email-yilun.xu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15spi: altera: add SPI core parameters support via platform data.Xu Yilun
This patch introduced SPI core parameters in platform data, it allows passing these SPI core parameters via platform data. Signed-off-by: Wu Hao <hao.wu@intel.com> Signed-off-by: Xu Yilun <yilun.xu@intel.com> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> Signed-off-by: Russ Weight <russell.h.weight@intel.com> Reviewed-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/1591845911-10197-3-git-send-email-yilun.xu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-07Merge tag 'pinctrl-v5.8-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control updates from Linus Walleij: "This is the bulk of pin control changes for the v5.8 kernel cycle. It's just really boring this time. Zero core changes. Just linear development, cleanups and misc noncritical fixes. Some new drivers for very new Qualcomm and Intel chips. New drivers: - Intel Jasper Lake support. - NXP Freescale i.MX8DXL support. - Qualcomm SM8250 support. - Renesas R8A7742 SH-PFC support. Driver improvements: - Severe cleanup and modernization of the MCP23s08 driver. - Mediatek driver modularized. - Setting config supported in the Meson driver. - Wakeup support for the Broadcom BCM7211" * tag 'pinctrl-v5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (72 commits) pinctrl: sprd: Fix the incorrect pull-up definition pinctrl: pxa: pxa2xx: Remove 'pxa2xx_pinctrl_exit()' which is unused and broken pinctrl: freescale: imx: Use 'devm_of_iomap()' to avoid a resource leak in case of error in 'imx_pinctrl_probe()' pinctrl: freescale: imx: Fix an error handling path in 'imx_pinctrl_probe()' pinctrl: sirf: add missing put_device() call in sirfsoc_gpio_probe() pinctrl: imxl: Fix an error handling path in 'imx1_pinctrl_core_probe()' pinctrl: bcm2835: Add support for wake-up interrupts pinctrl: bcm2835: Match BCM7211 compatible string dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts dt-bindings: pinctrl: Document 7211 compatible for brcm, bcm2835-gpio.txt dt-bindings: pinctrl: stm32: Add missing interrupts property pinctrl: at91-pio4: Add COMPILE_TEST support pinctrl: Fix return value about devm_platform_ioremap_resource() MAINTAINERS: Renesas Pin Controllers are supported dt-bindings: pinctrl: ocelot: Add Sparx5 SoC support pinctrl: ocelot: Fix GPIO interrupt decoding on Jaguar2 pinctrl: ocelot: Remove instance number from pin functions pinctrl: ocelot: Always register GPIO driver dt-bindings: pinctrl: rockchip: update example pinctrl: amd: Add ACPI dependency ...
2020-06-04Merge tag 'backlight-next-5.8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight Pull backlight updates from Lee Jones: "Core Framework: - Add backlight_device_get_by_name() to the API New Device Support: - Add support for WLED5 to Qualcomm WLED Fix-ups: - Convert to GPIO descriptors in l4f00242t03 - Device Tree fix-ups for qcom-wled Bug Fixes: - Properly disable regulators on .probe() failure" * tag 'backlight-next-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight: backlight: Add backlight_device_get_by_name() backlight: qcom-wled: Add support for WLED5 peripheral that is present on PM8150L PMICs dt-bindings: backlight: qcom-wled: Add WLED5 bindings backlight: qcom-wled: Add callback functions dt-bindings: backlight: qcom-wled: Convert the wled bindings to .yaml format backlight: l4f00242t03: Convert to GPIO descriptors backlight: lp855x: Ensure regulators are disabled on probe failure
2020-04-29backlight: l4f00242t03: Convert to GPIO descriptorsLinus Walleij
This converts the l4f00242t03 backlight driver to use GPIO descriptors and switches the two Freescale i.MX boards over to passing descriptors instead of global GPIO numbers. We use the typical names "enable" and "reset" as found in the device tree bindings for panel GPIOs. This saves a lot of code in the driver and makes it possible to get rid of the platform data header altogether. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Acked-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-04-20docs: spi: spi.h: fix a doc building warningMauro Carvalho Chehab
We need to add a blank line to avoid this warning: ./include/linux/spi/spi.h:401: WARNING: Unexpected indentation. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/1c701b3ac903dc0bc304dca958fbdee53bd38dc3.1586881715.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-04-16pinctrl: mcp23s08: Get rid of legacy platform dataAndy Shevchenko
Platform data is a legacy interface to supply device properties to the driver. In this case we even don't have in-kernel users for it. Just remove it for good. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200407173849.43628-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-04-07Merge tag 'backlight-next-5.7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight Pull backlight updates from Lee Jones: "Switch pwm_bl and corgi_lcd drivers to use GPIO descriptors" * tag 'backlight-next-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight: backlight: corgi: Convert to use GPIO descriptors backlight: pwm_bl: Switch to full GPIO descriptor
2020-03-31Merge tag 'tty-5.7-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial updates from Greg KH: "Here is the big set of TTY / Serial patches for 5.7-rc1 Lots of console fixups and reworking in here, serial core tweaks (doesn't that ever get old, why are we still creating new serial devices?), serial driver updates, line-protocol driver updates, and some vt cleanups and fixes included in here as well. All have been in linux-next with no reported issues" * tag 'tty-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (161 commits) serial: 8250: Optimize irq enable after console write serial: 8250: Fix rs485 delay after console write vt: vt_ioctl: fix use-after-free in vt_in_use() vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use virtual console tty: serial: make SERIAL_SPRD depend on COMMON_CLK tty: serial: fsl_lpuart: fix return value checking tty: serial: fsl_lpuart: move dma_request_chan() ARM: dts: tango4: Make /serial compatible with ns16550a ARM: dts: mmp*: Make the serial ports compatible with xscale-uart ARM: dts: mmp*: Fix serial port names ARM: dts: mmp2-brownstone: Don't redeclare phandle references ARM: dts: pxa*: Make the serial ports compatible with xscale-uart ARM: dts: pxa*: Fix serial port names ARM: dts: pxa*: Don't redeclare phandle references serial: omap: drop unused dt-bindings header serial: 8250: 8250_omap: Add DMA support for UARTs on K3 SoCs serial: 8250: 8250_omap: Work around errata causing spurious IRQs with DMA serial: 8250: 8250_omap: Extend driver data to pass FIFO trigger info serial: 8250: 8250_omap: Move locking out from __dma_rx_do_complete() serial: 8250: 8250_omap: Account for data in flight during DMA teardown ...
2020-03-25backlight: corgi: Convert to use GPIO descriptorsLinus Walleij
The code in the Corgi backlight driver can be considerably simplified by moving to GPIO descriptors and lookup tables from the board files instead of passing GPIO numbers using the old API. Make sure to encode inversion semantics for the Akita and Spitz platforms inside the GPIO lookup table and drop the custom inversion semantics from the driver. All in-tree users are converted in this patch. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-03-12tty: serial: ifx6x60: Convert to GPIO descriptorsLinus Walleij
This driver for the Intel MID never seems to have been properly integrated upstream: the platform data in <linux/spi/ifx_modem.h> is not used anywhere in the kernel and haven't been since it was merged into the kernel in 2010. There might be out-of-tree users, so I don't want to delete the driver, but I will refactor it to use GPIO descriptors, which means that out-of-tree users will need to adapt. There are several examples in the kernel of how to provide the resources necessary for using GPIO descriptors to pass in the GPIO lines, for the MID platform in particular, it will suffice to inspect the code in files like: arch/x86/platform/intel-mid/device_libs/platform_bt.c This refactoring transfers all GPIOs in the driver, including a hard-coded "PMU reset" in the driver to use GPIO descriptors instead. The following named GPIO descriptors need to be supplied: - reset - power - mrdy - srdy - rst_out - pmu_reset Cc: Russ Gorby <russ.gorby@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200311083131.693908-2-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-10spi: update the structure documentationQiujun Huang
some members were not described in documentation. Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Link: https://lore.kernel.org/r/1583774179-30736-1-git-send-email-hqjagain@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05spi: Do spi_take_timestamp_pre for as many times as necessaryVladimir Oltean
When dealing with a SPI controller driver that is sending more than 1 byte at once (or the entire buffer at once), and the SPI peripheral driver has requested timestamping for a byte in the middle of the buffer, we find that spi_take_timestamp_pre never records a "pre" timestamp. This happens because the function currently expects to be called with the "progress" argument >= to what the peripheral has requested to be timestamped. But clearly there are cases when that isn't going to fly. And since we can't change the past when we realize that the opportunity to take a "pre" timestamp has just passed and there isn't going to be another one, the approach taken is to keep recording the "pre" timestamp on each call, overwriting the previously recorded one until the "post" timestamp is also taken. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-8-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-28spi: Allow SPI controller override device buswidthJohn Garry
Currently ACPI firmware description for a SPI device does not have any method to describe the data buswidth on the board. So even through the controller and device may support higher modes than standard SPI, it cannot be assumed that the board does - as such, that device is limited to standard SPI in such a circumstance. As a workaround, allow the controller driver supply buswidth override bits, which are used inform the core code that the controller driver knows the buswidth supported on that board for that device. A host controller driver might know this info from DMI tables, for example. Signed-off-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1582903131-160033-2-git-send-email-john.garry@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-23Merge branch 'spi-5.6' into spi-nextMark Brown
2020-01-07spi: Add generic support for unused native cs with cs-gpiosGeert Uytterhoeven
Some SPI master controllers always drive a native chip select when performing a transfer. Hence when using both native and GPIO chip selects, at least one native chip select must be left unused, to be driven when performing transfers with slave devices using GPIO chip selects. Currently, to find an unused native chip select, SPI controller drivers need to parse and process cs-gpios theirselves. This is not only duplicated in each driver that needs it, but also duplicates part of the work done later at SPI controller registration time. Note that this cannot be done after spi_register_controller() returns, as at that time, slave devices may have been probed already. Hence add generic support to the SPI subsystem for finding an unused native chip select. Optionally, this unused native chip select, and all other in-use native chip selects, can be validated against the maximum number of native chip selects available on the controller hardware. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200102133822.29346-2-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-27spi: Don't look at TX buffer for PTP system timestampingVladimir Oltean
The API for PTP system timestamping (associating a SPI transaction with the system time at which it was transferred) is flawed: it assumes that the xfer->tx_buf pointer will always be present. This is, of course, not always the case. So introduce a "progress" variable that denotes how many word have been transferred. Fix the Freescale DSPI driver, the only user of the API so far, in the same patch. Fixes: b42faeee718c ("spi: Add a PTP system timestamp to the transfer structure") Fixes: d6b71dfaeeba ("spi: spi-fsl-dspi: Implement the PTP system timestamping for TCFQ mode") Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20191227012417.1057-1-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-27spi: oc-tiny: Use GPIO descriptorsLinus Walleij
Switch the OC Tiny driver over to handling CS GPIOs using GPIO descriptors in the core. This driver is entirely relying on GPIOs to be used for chipselect, so let the core pick these out using either device tree or machine descriptors. There are no in-tree users of this driver so no board files need to be patched, out-of-tree boardfiles can use machine descriptor tables, c.f. commit 1dfbf334f123. Cc: Thomas Chou <thomas@wytron.com.tw> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191205092411.64341-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-23spi: document CS setup, hold & inactive times in headerAlexandru Ardelean
This change documents the CS setup, host & inactive times. They were omitted when the fields were added, and were caught by one of the build bots. Fixes: 25093bdeb6bc ("spi: implement SW control for CS times") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20191023070046.12478-1-alexandru.ardelean@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-15spi: spi-fsl-espi: convert transfer delay to `spi_delay` formatAlexandru Ardelean
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>
2019-10-15spi: implement SW control for CS timesAlexandru Ardelean
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>
2019-10-15spi: tegra114: change format for `spi_set_cs_timing()` functionAlexandru Ardelean
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>
2019-10-15spi: introduce `delay` field for `spi_transfer` + spi_transfer_delay_exec()Alexandru Ardelean
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>
2019-10-15spi: core,atmel: convert `word_delay_usecs` -> `word_delay` for spi_deviceAlexandru Ardelean
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>
2019-10-15spi: sprd: convert transfer word delay to spi_delay structAlexandru Ardelean
The Spreadtrum SPI driver is the only user of the `word_delay` field in the `spi_transfer` struct. This change converts the field to use the `spi_delay` struct. This also enforces the users to specify the delay unit to be `SPI_DELAY_UNIT_SCK`. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20190926105147.7839-5-alexandru.ardelean@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-15spi: make `cs_change_delay` the first user of the `spi_delay` logicAlexandru Ardelean
Since the logic for `spi_delay` struct + `spi_delay_exec()` has been copied from the `cs_change_delay` logic, it's natural to make this delay, the first user. The `cs_change_delay` logic requires that the default remain 10 uS, in case it is unspecified/unconfigured. So, there is some special handling needed to do that. The ADIS library is one of the few users of the new `cs_change_delay` parameter for an spi_transfer. The introduction of the `spi_delay` struct, requires that the users of of `cs_change_delay` get an update. This change also updates the ADIS library. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20190926105147.7839-4-alexandru.ardelean@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>