- 15 Dec, 2021 1 commit
-
-
Tudor Ambarus authored
Convert the Atmel QuadSPI controller Device Tree binding documentation to json-schema. Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211209122939.339810-2-tudor.ambarus@microchip.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
- 13 Dec, 2021 1 commit
-
-
Hector Martin authored
Move the cs_setup delay to the end of spi_set_cs. From include/linux/spi/spi.h: * @cs_setup: delay to be introduced by the controller after CS is asserted The cs_setup delay needs to happen *after* CS is asserted, that is, at the end of spi_set_cs, not at the beginning. Otherwise we're just delaying before the SPI transaction starts at all, which isn't very useful. No drivers use this right now, but that is likely to change soon with an upcoming Apple SPI HID transport driver. Fixes: 25093bde ("spi: implement SW control for CS times") Signed-off-by:
Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20211210170534.177139-1-marcan@marcan.stSigned-off-by:
-
- 01 Dec, 2021 3 commits
-
-
Pratyush Yadav authored
The spi-peripheral-props.yaml schema contains peripheral-specific properties for SPI controllers that should be present in the peripheral node. Add a reference to that so its constraints are followed. additionalProperties: false cannot be used since it marks the controller properties as unknown. Use unevaluatedProperties: false instead. This has the side effect of allowing extra properties that are not specified in the schema. The alternative is to list all the controller properties in this schema but that would mean every peripheral binding would have to repeat the same set of properties for each controller. Signed-off-by:
Pratyush Yadav <p.yadav@ti.com> Reviewed-by:
-
Pratyush Yadav authored
The spi-peripheral-props.yaml schema contains peripheral-specific properties for SPI controllers that should be present in the peripheral node. Move peripheral-specific properties to a separate file and refer to it in spi-peripheral-props.yaml. Signed-off-by:
-
Pratyush Yadav authored
Many SPI controllers need to add properties to peripheral devices. This could be the delay in clock or data lines, etc. These properties are controller specific but need to be defined in the peripheral node because they are per-peripheral and there can be multiple peripherals attached to a controller. If these properties are not added to the peripheral binding, then the dtbs check emits a warning. But these properties do not make much sense in the peripheral binding because they are controller-specific and they will just pollute every peripheral binding. So this binding is added to collect all such properties from all such controllers. Peripheral bindings should simply refer to this binding and they should be rid of the warnings. There are some limitations with this approach. Firstly, there is no way to specify required properties. The schema contains properties for all controllers and there is no way to know which controller is being used. Secondly, there is no way to restrict additional properties. Since this schema will be used with an allOf operator, additionalProperties needs to be true. In addition, the peripheral schema will have to set unevaluatedProperties: false. Despite these limitations, this appears to be the best solution to this problem that doesn't involve modifying existing tools or schema specs. Signed-off-by:
-
- 29 Nov, 2021 3 commits
-
-
Andy Shevchenko authored
There is no user of the enable_loopback member in the struct pxa2xx_spi_chip. Remote this legacy member completely. The mentioned in the documentation the testing phase can be performed with spidev_test tool. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211123192723.44537-3-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
Since the last user of the custom ->cs_control() gone, we may get rid of this legacy API completely. Signed-off-by:
-
Andy Shevchenko authored
SPI PXA2xx driver supports GPIO chipselect by querying for known GPIO connection ID. Replace custom ->cs_control() by GPIO table, so the driver will use generic approach on this platform. Signed-off-by:
-
- 26 Nov, 2021 3 commits
-
-
Krishna Yarlagadda authored
Use devm alloc call to allocate memory for spi controller data and remove free calls from cleanup. Signed-off-by:
Krishna Yarlagadda <kyarlagadda@nvidia.com> Link: https://lore.kernel.org/r/1637834152-32093-1-git-send-email-kyarlagadda@nvidia.comSigned-off-by:
-
Tudor Ambarus authored
The 'direction' member of 'struct dma_slave_config' is deprecated. Instead, drivers should use the direction argument to the device_prep_slave_sg and device_prep_dma_cyclic functions or the dir field in the dma_interleaved_template structure. spi-atmel uses the direction argument to dmaengine_prep_slave_sg. slave_config.direction is not used in neither of the DMA controller drivers (at_h/xdmac) that spi-atmel is using, we can just remove the setting of slave_config.direction and live with whatever stack value is there. Signed-off-by:
-
Tudor Ambarus authored
The callers passed a pointer to slave_config as an argument of atmel_spi_dma_slave_config(), but they did not use it afterwards. Use instead a local variable in atmel_spi_dma_slave_config(), and stop passing arguments that are not needed in the callers. Signed-off-by:
-
- 25 Nov, 2021 2 commits
-
-
Kamal Dasu authored
Check if the transfer parameters have changed from previous settings before applying new parameters. Signed-off-by:
Kamal Dasu <kdasu.kdev@gmail.com> Link: https://lore.kernel.org/r/20211124193353.32311-3-kdasu.kdev@gmail.comSigned-off-by:
-
Kamal Dasu authored
Check requested speed for a given transfer before setting 27MHz or 108Mhz sysclk on SoCs that support both. This way for baud rates below 212Khz we can use 27Mhz clock. Signed-off-by:
-
- 24 Nov, 2021 2 commits
-
-
Andy Shevchenko authored
The recent commit 3f076575 ("spi: deduplicate spi_match_id() in __spi_register_driver()") inadvertently inverted a condition that provokes a (harmless) warning: WARNING KERN SPI driver mtd_dataflash has no spi_device_id for atmel,at45 Restore logic to avoid such warning to be issued. Fixes: 3f076575 ("spi: deduplicate spi_match_id() in __spi_register_driver()") Reported-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
-
Javier Martinez Canillas authored
Some Device Trees don't use a real device name in the compatible string for SPI devices nodes, abusing the fact that the spidev driver name is used to match as a fallback when a SPI device ID table is not defined. But since commit 6840615f ("spi: spidev: Add SPI ID table") a table for SPI device IDs was added to the driver breaking the assumption that these DTs were relying on. There has been a warning message for some time since commit 956b200a ("spi: spidev: Warn loudly if instantiated from DT as "spidev""), making quite clear that this case is not really supported by the spidev driver. Since these devices won't match anyways after the mentioned commit, there is no point to continue if an spidev compatible is used. Let's just make the driver probe to fail early. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20211109225920.1158920-1-javierm@redhat.comSigned-off-by:
-
- 23 Nov, 2021 4 commits
-
-
Andy Shevchenko authored
Since the commit 196b0e2c ("spi: pxa2xx: Remove if statement that is always true in pump_transfers()") the ->read() and ->write() methods in the struct driver_data are reconfigured for each transfer. Hence no need to keep the intermediate state in the struct chip_data. The same applies to n_bytes member of the same data structure. Get rid of unneeded storage for good. Signed-off-by:
-
Andy Shevchenko authored
Currently the 16-bit mode is what being used in user space. However assuming that is not fully correct. Instead we should use the respective mask, i.e. SPI_MODE_USER_MASK, which precisely defines what bits are available for user space apps. Signed-off-by:
-
Andy Shevchenko authored
/* * Fix multi-line comment style as in this short example. Pay attention * to the capitalization, period and starting line of the text. */ While at it, split the (supposedly short) description of couple of functions to summary (short description) and (long) description. Signed-off-by:
-
Andy Shevchenko authored
krealloc() as any other kernel memory allocation calls accepts GFP flags, one of which is __GFP_ZERO. Hence, no need to call memset() explicitly on the reallocated buffer. Signed-off-by:
-
- 22 Nov, 2021 4 commits
-
-
Jacky Bai authored
The lpspi on i.MX8ULP is derived from i.MX7ULP, it uses two compatible strings, so update the comaptible string for i.MX8ULP. Signed-off-by:
Jacky Bai <ping.bai@nxp.com> Reviewed-by:
Dong Aisheng <aisheng.dong@nxp.com> Acked-by:
-
Andy Shevchenko authored
The same logic is used in spi_match_id() and in the __spi_register_driver(). By switching the former from taking struct spi_device * to const char * as the second parameter we may deduplicate the code. Signed-off-by:
-
Linus Walleij authored
Some PL022 implementations provide a reset line to the silicon IP block, add a device tree property for this. Cc: devicetree@vger.kernel.org Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211120011715.2630873-1-linus.walleij@linaro.orgSigned-off-by:
-
Javier Martinez Canillas authored
This doc is fairly outdated and only uses legacy device instantiation terminology. Let us update it and also mention the OF and ACPI device tables, to make easier for users to figure out how should be defined. Also, mention that devices bind could be done in user-space now using the "driver_override" sysfs entry. Suggested-by:
Ralph Siemsen <ralph.siemsen@linaro.org> Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20211119121139.2412761-1-javierm@redhat.comSigned-off-by:
-
- 18 Nov, 2021 5 commits
-
-
Mark Brown authored
Merge series from Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>: This patch series adds RSPI driver and dt binding support to RZ/G2L SoC.
-
Vinod Koul authored
Commit b59c1224 ("spi: spi-geni-qcom: Add support for GPI dma") added GPI support but also added unused defines, so remove them Signed-off-by:
Vinod Koul <vkoul@kernel.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20211117133110.2682631-1-vkoul@kernel.orgSigned-off-by:
-
Lad Prabhakar authored
"ret" variable is already declared in qspi_transfer_in() at the beginning of function, drop redeclaring ret in the if block, fixing below: spi-rspi.c: In function ‘qspi_transfer_in’: spi-rspi.c:838:7: warning: declaration of ‘ret’ shadows a previous local 838 | int ret = rspi_dma_transfer(rspi, NULL, &xfer->rx_sg); | ^~~ spi-rspi.c:835:6: note: shadowed declaration is here 835 | int ret; Fixes: db300838 ("spi: rspi: avoid uninitialized variable access") Signed-off-by:Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20211118031041.2312-4-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by:
-
Lad Prabhakar authored
On RZ/G2L SoC we need to explicitly deassert the reset line for the device to work, use this opportunity to deassert/assert reset line in spi-rspi driver. This patch adds support to read the "resets" property (if available) from DT and perform deassert/assert when required. Signed-off-by:
Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by:
-
Lad Prabhakar authored
Add RSPI binding documentation for Renesas RZ/G2L SoC. RSPI block is identical to one found on RZ/A, so no driver changes are required. The fallback compatible string "renesas,rspi-rz" will be used on RZ/G2L. Signed-off-by:
-
- 17 Nov, 2021 1 commit
-
-
oujiefeng authored
Change the debugfs directory name from hisi_spi65535 to hisi_spi0. Fixes: 2b2142f2 ("spi: hisi-kunpeng: Add debugfs support") Signed-off-by:
oujiefeng <oujiefeng@huawei.com> Signed-off-by:
Jay Fang <f.fangjian@huawei.com> Link: https://lore.kernel.org/r/20211117012119.55558-1-f.fangjian@huawei.comSigned-off-by:
-
- 16 Nov, 2021 7 commits
-
-
Serge Semin authored
Since the DW_SPI_CAP_DWC_HSSI capability has just been replaced with using the DW SSI IP-core versions interface, the DW SPI capability flags are now represented with a gap. Let's fix it by redefining the DW_SPI_CAP_DFS32 macro to setting BIT(2) of the capabilities field. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Suggested-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by:
-
Serge Semin authored
Since there is a common IP-core and component versions interface available we can use it to differentiate the DW HSSI device features in the code. Let's remove the corresponding DWC_HSSI capability flag then and use the dw_spi_ip_is() macro instead. Signed-off-by:
-
Serge Semin authored
The driver currently supports two IP-core versions. It's DW APB SSI which is older version of the controller with APB system bus interface, and DW SSI controller with AHB bus interface. The later one is supposed to be a new generation high-speed SSI. Even though both of these IP-cores have got an almost identical registers space there are some differences. The driver differentiates these distinctions by the DW_SPI_CAP_DWC_HSSI capability flag. In addition to that each DW SSI IP-core is equipped with a Synopsys Component version register, which encodes the IP-core release ID the has been synthesized from. Seeing we are going to need the later one to differentiate some controller peculiarities it would be better to have a unified interface for both IP-core line and release versions instead of using each of them separately. Introduced here IP-core versioning interface consists of two parts: 1) IDs of the IP-core (virtual) and component versions. 2) a set of macro helpers to identify current IP-core and component versions. So the platform code is supposed to assign a proper IP-core version based on it's platform -knowledge. The main driver initialization method reads the IP-core release ID from the SSI component version register. That data is used by the helpers to distinguish one IP-core release from another. Thus the rest of the driver can use these macros to implement the conditional code execution based on the specified IP-core and version IDs. Collect the IP-core versions interface and the defined capabilities at the top of the header file since they represent a common device description data and so to immediately available for the driver hackers. Signed-off-by:
-
Serge Semin authored
The driver has been using the offset/bitwise-shift-based approach for the CSR fields R/W operations since it was merged into the kernel. It can be simplified by using the macros defined in the linux/bitfield.h and linux/bit.h header files like BIT(), GENMASK(), FIELD_PREP(), FIELD_GET(), etc where it is required, for instance in the cached cr0 preparation method. Thus in order to have the FIELD_*()-macros utilized we just need to convert the macros with the CSR-fields offsets to the masks with the corresponding registers fields definition. That's where the GENMASK() and BIT() macros come in handy. After that the masks can be used in the FIELD_*()-macros where it's appropriate. We also need to convert the macros with the CRS-bit flags using the manual bitwise shift operations (x << y) to using the BIT() macro. Thus we'll have a more coherent set of the CSR-related macros. Signed-off-by:
-
Serge Semin authored
Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435 ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by:
-
Serge Semin authored
The dw_ssi_type enumeration describes the SPI frame formats the controller supports, like Motorola SPI, Texas Instruments SSP and National Semiconductors Microwire, that is the serial protocol utilized for the SPI-transfers. Depending on the DW SSI IP-core configuration the protocol could be either fixed or selectable. If it is changebale the protocol can be selected by means of the CTRL0.FRF field, which possible values encoded by the dw_ssi_type enumeration. Aside with the denoted enum the field values are also described by a set of SPI_FRF_{SPI,SSP,MICROWIRE} macros. Thus currently the DW SPI driver has got two entities describing the same data. Let's get rid of the enumeration one then, since first it hasn't been used as enumeration-type but merely as a parametrized values set and second that would unify the macro-based CSR read/write interface of the driver. While at it convert the macro names to be more descriptive about the protocols they represent. Signed-off-by: -
Serge Semin authored
The exported from the DW SPI driver core/DMA symbols are only used by the spi-dw-{mmio,pci,bt1}.o objects. Add these symbols to a separate namespace then and make sure the depended modules have it imported. Signed-off-by:
-
- 15 Nov, 2021 4 commits
-
-
Rob Herring authored
Netlogic XLP was removed in commit 95b8a5e0 ("MIPS: Remove NETLOGIC support"). With those gone, the single platform left to support is Cavium ThunderX2. Remove the Netlogic variant and DT support. For simplicity, the existing kconfig name is retained. Cc: Mark Brown <broonie@kernel.org> Cc: linux-spi@vger.kernel.org Signed-off-by:
-
Alexander Stein authored
The requested DMA channels are never released. Do this in .remove as well as in .probe. spi_register_controller() can return -EPROBE_DEFER if cs-gpios are not probed yet. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20211109103134.184216-1-alexander.stein@ew.tq-group.comSigned-off-by:
-
Jonathan Corbet authored
Commit 6acaadc8 ("spi: clps711x: Driver refactor") removed the only use of <linux/platform_data/spi-clps711x.h>, but left the header file behind. This file is unused, delete it. Cc: Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Signed-off-by: Mark Brown <broonie@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Acked-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20211102220203.940290-9-corbet@lwn.netSigned-off-by:
-
Mark Brown authored
-
