- Jan 04, 2022
-
-
Oskari Lemmela authored
If bits_per_word is configured, transfer only word amount of data per iteration. Signed-off-by:
Oskari Lemmela <oskari@lemmela.net> Link: https://lore.kernel.org/r/20211222055958.1383233-2-oskari@lemmela.net Signed-off-by:
Mark Brown <broonie@kernel.org>
-
- Dec 23, 2021
-
-
Andy Shevchenko authored
Propagate firmware node by using a specific API call, i.e. device_set_node(). Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211222155739.7699-3-andriy.shevchenko@linux.intel.com Signed-off-by:
-
Andy Shevchenko authored
Propagate firmware node by using a specific API call, i.e. device_set_node(). Signed-off-by:
Serge Semin <fancer.lancer@gmail.com> Acked-by:
-
Andy Shevchenko authored
Propagate firmware node by using a specific API call, i.e. device_set_node(). Signed-off-by:
-
- Dec 22, 2021
-
-
Oskari Lemmela authored
Add missing delay between transferred messages and words. Signed-off-by:
-
- Dec 21, 2021
-
-
Tinghan Shen authored
Some mtk spi nor has dedicated dma(s) inside. Add a new clock name, axi, for spi nor dma bus clock. Signed-off-by:
Tinghan Shen <tinghan.shen@mediatek.com> Link: https://lore.kernel.org/r/20211220121825.6446-3-tinghan.shen@mediatek.com Signed-off-by:
-
- Dec 16, 2021
-
-
Tudor Ambarus authored
sama7g5 embedds 2 instances of the QSPI controller: 1/ One Octal Serial Peripheral Interface (QSPI0) Supporting up to 200 MHz DDR. Octal, TwinQuad, HyperFlash and OctaFlash Protocols Supported 2/ One Quad Serial Peripheral Interface (QSPI1) Supporting Up to 90 MHz DDR/133 MHz SDR Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211209122939.339810-3-tudor.ambarus@microchip.com Signed-off-by:
-
Tudor Ambarus authored
Convert the Atmel QuadSPI controller Device Tree binding documentation to json-schema. Signed-off-by:
-
- Dec 14, 2021
-
-
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.st Signed-off-by:
-
- Dec 01, 2021
-
-
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:
-
- Nov 29, 2021
-
-
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 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:
-
- Nov 26, 2021
-
-
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.com Signed-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:
-
- Nov 25, 2021
-
-
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.com Signed-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:
-
- Nov 24, 2021
-
-
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.com Signed-off-by:
-
- Nov 23, 2021
-
-
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:
-
- Nov 22, 2021
-
-
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.org Signed-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.com Signed-off-by:
-
- Nov 19, 2021
-
-
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.
-
- Nov 18, 2021
-
-
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.org Signed-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.com Signed-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:
-
- Nov 17, 2021
-
-
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.com Signed-off-by:
-
- Nov 16, 2021
-
-
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:
-
