- 26 May, 2020 1 commit
-
-
Lukas Wunner authored
The Designware SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes dw_spi_remove_host() before unregistering the SPI controller via devres_release_all(). This order is incorrect: dw_spi_remove_host() shuts down the chip, rendering the SPI bus inaccessible even though the SPI controller is still registered. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. Because their drivers cannot access the SPI bus, e.g. to quiesce interrupts, the slave devices may be left in an improper state. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unregistering the controller and specifically after unbinding of slaves. Fix by reverting to the non-devm variant of spi_register_controller(). An alternative approach would be to use device-managed functions for all steps in dw_spi_remove_host(), e.g. by calling devm_add_action_or_reset() on probe. However that approach would add more LoC to the driver and it wouldn't lend itself as well to backporting to stable. Fixes: 04f421e7 ("spi: dw: use managed resources") Signed-off-by:
Lukas Wunner <lukas@wunner.de> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable@vger.kernel.org # v3.14+ Cc: Baruch Siach <baruch@tkos.co.il> Link: https://lore.kernel.org/r/3fff8cb8ae44a9893840d0688be15bb88c090a14.1590408496.git.lukas@wunner.deSigned-off-by:
Mark Brown <broonie@kernel.org>
-
- 25 May, 2020 1 commit
-
-
Peter Rosin authored
It is not valid to cache/short out selection of the mux. mux_control_select() only locks the mux until mux_control_deselect() is called. mux_control_deselect() may put the mux in some low power state or some other user of the mux might select it for other purposes. These things are probably not happening in the original setting where this driver was developed, but it is said to be a generic SPI mux. Also, the mux framework will short out the actual low level muxing operation when/if that is possible. Fixes: e9e40543 ("spi: Add generic SPI multiplexer") Signed-off-by:
Peter Rosin <peda@axentia.se> Link: https://lore.kernel.org/r/20200525104352.26807-1-peda@axentia.seSigned-off-by:
-
- 20 May, 2020 3 commits
-
-
Lukas Wunner authored
The BCM2835aux SPI driver uses devm_spi_register_master() on bind. As a consequence, on unbind, __device_release_driver() first invokes bcm2835aux_spi_remove() before unregistering the SPI controller via devres_release_all(). This order is incorrect: bcm2835aux_spi_remove() turns off the SPI controller, including its interrupts and clock. The SPI controller is thus no longer usable. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. If their drivers need to access the SPI bus, e.g. to quiesce their interrupts, unbinding will fail. As a rule, devm_spi_register_master() must not be used if the ->remove() hook performs teardown steps which shall be performed after unbinding of slaves. Fix by using the non-devm variant spi_register_master(). Note that the struct spi_master as well as the driver-private data are not freed until after bcm2835aux_spi_remove() has finished, so accessing them is safe. Fixes: 1ea29b39 ("spi: bcm2835aux: add bcm2835 auxiliary spi device driver") Signed-off-by:
-
Lukas Wunner authored
The BCM2835 SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes bcm2835_spi_remove() before unregistering the SPI controller via devres_release_all(). This order is incorrect: bcm2835_spi_remove() tears down the DMA channels and turns off the SPI controller, including its interrupts and clock. The SPI controller is thus no longer usable. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. If their drivers need to access the SPI bus, e.g. to quiesce their interrupts, unbinding will fail. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unbinding of slaves. Fix by using the non-devm variant spi_register_controller(). Note that the struct spi_controller as well as the driver-private data are not freed until after bcm2835_spi_remove() has finished, so accessing them is safe. Fixes: 247263db ("spi: bcm2835: use devm_spi_register_master()") Signed-off-by:
-
Lukas Wunner authored
When an SPI controller unregisters, it unbinds all its slave devices. For this, their drivers may need to access the SPI bus, e.g. to quiesce interrupts. However since commit ffbbdd21 ("spi: create a message queueing infrastructure"), spi_destroy_queue() is executed before unbinding the slaves. It sets ctlr->running = false, thereby preventing SPI bus access and causing unbinding of slave devices to fail. Fix by unbinding slaves before calling spi_destroy_queue(). Fixes: ffbbdd21 ("spi: create a message queueing infrastructure") Signed-off-by:
-
- 21 Apr, 2020 4 commits
-
-
Florian Fainelli authored
The clock provider may not be ready by the time spi-bcm-qspi gets probed, handle probe deferral using devm_clk_get_optional(). Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Kamal Dasu <kdasu.kdev@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200420190853.45614-2-kdasu.kdev@gmail.comSigned-off-by:
-
Justin Chen authored
Currently we set the tx/rx buffer to 0xff when NULL. This causes problems with some spi slaves where 0xff is a valid command. Looking at other drivers, the tx/rx buffer is usually set to 0x00 when NULL. Following this convention solves the issue. Fixes: fa236a7e ("spi: bcm-qspi: Add Broadcom MSPI driver") Signed-off-by:
Justin Chen <justinpopo6@gmail.com> Signed-off-by:
-
Kamal Dasu authored
SCMI only passes clk_prepare_enable() and clk_disable_unprepare(), made changes to suspend/resume ops to use the appropriate calls so that PM works for ARM and ARM64 platforms. Signed-off-by:
-
Kamal Dasu authored
As per the spi core implementation for MSPI devices when the transfer is the last one in the message, the chip may stay selected until the next transfer. On multi-device SPI busses with nothing blocking messages going to other devices, this is just a performance hint; starting a message to another device deselects this one. But in other cases, this can be used to ensure correctness. Some devices need protocol transactions to be built from a series of spi_message submissions, where the content of one message is determined by the results of previous messages and where the whole transaction ends when the chipselect goes intactive. On CS change after completing the last serial transfer, the MSPI driver drives SSb pin CDRAM register correctly according comments in core spi.h as shown below: case 1) EOM =1, cs_change =0: SSb inactive case 2) EOM =1, cs_change =1: SSb active case 3) EOM =0, cs_change =0: SSb active case 4) EOM =0, cs_change =1: SSb inactive Signed-off-by:
-
- 14 Apr, 2020 2 commits
-
-
Andy Shevchenko authored
By unknown reason the commit 64bee4d2 ("spi / ACPI: add ACPI enumeration support") missed the DataBitLength property to encounter when parse SPI slave device data from ACPI. Fill the gap here. Fixes: 64bee4d2 ("spi / ACPI: add ACPI enumeration support") Signed-off-by:
-
Christophe JAILLET authored
This should be 'SC18IS602', not 'SC18IC602' Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/20200413154043.23064-1-christophe.jaillet@wanadoo.frSigned-off-by:
-
- 09 Apr, 2020 1 commit
-
-
Rafał Hibner authored
Move register access after clock initialization. Clock "s_axi_aclk" is needed for register access. Without the clock running AXI bus hangs and causes kernel freeze. Signed-off-by:
Rafał Hibner <rafal.hibner@secom.com.pl> Reviewed-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200409155621.12174-1-rafal.hibner@secom.com.plSigned-off-by:
-
- 03 Apr, 2020 1 commit
-
-
Jungseung Lee authored
The mode bits on control register 0 are in a different order compared to the spi mode define values. Thus, in the current code, it fails to set the correct SPI mode selection. Fix it. Signed-off-by:
Jungseung Lee <js07.lee@samsung.com> Link: https://lore.kernel.org/r/20200402121022.9976-1-js07.lee@samsung.comSigned-off-by:
-
- 27 Mar, 2020 1 commit
-
-
Linus Walleij authored
This switches the EFM32 driver over to use the GPIO descriptor handling in the core. The GPIO handling in this driver is pretty simplistic so this should just work. Drop the GPIO headers and insert the implicitly included <linux/of.h> header. Signed-off-by:
Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Cc: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> Link: https://lore.kernel.org/r/20200317094914.331932-1-linus.walleij@linaro.orgSigned-off-by:
-
- 23 Mar, 2020 2 commits
-
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200320232515.GA24800@embeddedor.comSigned-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Andi Shyti <andi@etezian.org> Link: https://lore.kernel.org/r/20200320232556.GA24989@embeddedor.comSigned-off-by:
-
- 20 Mar, 2020 2 commits
-
-
Alain Volmat authored
Fix all functions and structure descriptions to have the driver warning free when built with W=1. Signed-off-by:
Alain Volmat <alain.volmat@st.com> Reviewed-by:
Amelie Delaunay <amelie.delaunay@st.com> Link: https://lore.kernel.org/r/1584711857-9162-1-git-send-email-alain.volmat@st.comSigned-off-by:
-
Tudor Ambarus authored
This feature should not be enabled in release but can be useful for developers who need to monitor register accesses at some specific places. Helped me identify a bug in u-boot, by comparing the register accesses from the linux driver with the ones from its u-boot variant. Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200320065058.891221-1-tudor.ambarus@microchip.comSigned-off-by:
-
- 18 Mar, 2020 10 commits
-
-
Vladimir Oltean authored
This is similar to the DSPI instantiation on LS1028A, except that: - The A-011218 erratum has been fixed, so DMA works - The endianness is different, which has implications on XSPI mode Some benchmarking with the following command: spidev_test --device /dev/spidev2.0 --bpw 8 --size 256 --cpha --iter 10000000 --speed 20000000 shows that in DMA mode, it can achieve around 2400 kbps, and in XSPI mode, the same command goes up to 4700 kbps. This is somewhat to be expected, since the DMA buffer size is extremely small at 8 bytes, the winner becomes whomever can prepare the buffers for transmission quicker, and DMA mode has higher overhead there. So XSPI FIFO mode has been chosen as the operating mode for this chip. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by:
Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-11-olteanv@gmail.comSigned-off-by:
-
Vladimir Oltean authored
The operating mode (DMA, XSPI, EOQ) is not going to change across the lifetime of the device. So it makes no sense to keep writing to SPI_RSER on each message. Move this configuration to dspi_init instead. Signed-off-by:
-
Vladimir Oltean authored
Interrupts are not necessary for DMA functionality, since the completion event is provided by the DMA driver. But if the driver fails to request the IRQ defined in the device tree, it will call dspi_poll which would make the driver hang waiting for data to become available in the RX FIFO. Fixes: c55be305 ("spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing") Signed-off-by:
-
Vladimir Oltean authored
The driver does not create the dspi->dma structure unless operating in DSPI_DMA_MODE, so it makes sense to check for that. Fixes: f4b32390 ("spi: Introduce dspi_slave_abort() function for NXP's dspi SPI driver") Signed-off-by:
-
Vladimir Oltean authored
Currently the driver puts the process in interruptible sleep waiting for the interrupt train to finish transfer to/from the tx_buf and rx_buf. But exiting the process with ctrl-c may make the kernel panic: the wait_event_interruptible call will return -ERESTARTSYS, which a proper driver implementation is perhaps supposed to handle, but nonetheless this one doesn't, and aborts the transfer altogether. Actually when the task is interrupted, there is still a high chance that the dspi_interrupt is still triggering. And if dspi_transfer_one_message returns execution all the way to the spi_device driver, that can free the spi_message and spi_transfer structures, leaving the interrupts to access a freed tx_buf and rx_buf. hexdump -C /dev/mtd0 00000000 00 75 68 75 0a ff ff ff ff ff ff ff ff ff ff ff |.uhu............| 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * ^C[ 38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete failed! [ 38.503097] spi_master spi2: failed to transfer one message from queue [ 38.509729] Unable to handle kernel paging request at virtual address ffff800095ab3377 [ 38.517676] Mem abort info: [ 38.520474] ESR = 0x96000045 [ 38.523533] EC = 0x25: DABT (current EL), IL = 32 bits [ 38.528861] SET = 0, FnV = 0 [ 38.531921] EA = 0, S1PTW = 0 [ 38.535067] Data abort info: [ 38.537952] ISV = 0, ISS = 0x00000045 [ 38.541797] CM = 0, WnR = 1 [ 38.544771] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082621000 [ 38.551494] [ffff800095ab3377] pgd=00000020fffff003, p4d=00000020fffff003, pud=0000000000000000 [ 38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP [ 38.565819] Modules linked in: [ 38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted 5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193 [ 38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT) [ 38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO) [ 38.591941] pc : ktime_get_real_ts64+0x3c/0x110 [ 38.596487] lr : spi_take_timestamp_pre+0x40/0x90 [ 38.601203] sp : ffff800010003d90 [ 38.604525] x29: ffff800010003d90 x28: ffff80001200e000 [ 38.609854] x27: ffff800011da9000 x26: ffff002079c40400 [ 38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0 [ 38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377 [ 38.625841] x21: 000000000000146e x20: ffff8000120c3000 [ 38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948 [ 38.636498] x17: 0000000000000000 x16: 0000000000000000 [ 38.641826] x15: ffff800095ab3377 x14: 0720072007200720 [ 38.647155] x13: 0720072007200765 x12: 0775076507750771 [ 38.652483] x11: 0720076d076f0772 x10: 0000000000000040 [ 38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8 [ 38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60 [ 38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377 [ 38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0 [ 38.679125] x1 : ffff800011daa000 x0 : 0000000000000026 [ 38.684454] Call trace: [ 38.686905] ktime_get_real_ts64+0x3c/0x110 [ 38.691100] spi_take_timestamp_pre+0x40/0x90 [ 38.695470] dspi_fifo_write+0x58/0x2c0 [ 38.699315] dspi_interrupt+0xbc/0xd0 [ 38.702987] __handle_irq_event_percpu+0x78/0x2c0 [ 38.707706] handle_irq_event_percpu+0x3c/0x90 [ 38.712161] handle_irq_event+0x4c/0xd0 [ 38.716008] handle_fasteoi_irq+0xbc/0x170 [ 38.720115] generic_handle_irq+0x2c/0x40 [ 38.724135] __handle_domain_irq+0x68/0xc0 [ 38.728243] gic_handle_irq+0xc8/0x160 [ 38.732000] el1_irq+0xb8/0x180 [ 38.735149] spi_nor_spimem_read_data+0xe0/0x140 [ 38.739779] spi_nor_read+0xc4/0x120 [ 38.743364] mtd_read_oob+0xa8/0xc0 [ 38.746860] mtd_read+0x4c/0x80 [ 38.750007] mtdchar_read+0x108/0x2a0 [ 38.753679] __vfs_read+0x20/0x50 [ 38.757002] vfs_read+0xa4/0x190 [ 38.760237] ksys_read+0x6c/0xf0 [ 38.763471] __arm64_sys_read+0x20/0x30 [ 38.767319] el0_svc_common.constprop.3+0x90/0x160 [ 38.772125] do_el0_svc+0x28/0x90 [ 38.775449] el0_sync_handler+0x118/0x190 [ 38.779468] el0_sync+0x140/0x180 [ 38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0) [ 38.788910] ---[ end trace 55da560db4d6bef7 ]--- [ 38.793540] Kernel panic - not syncing: Fatal exception in interrupt [ 38.799914] SMP: stopping secondary CPUs [ 38.803849] Kernel Offset: disabled [ 38.807344] CPU features: 0x10002,20006008 [ 38.811451] Memory Limit: none [ 38.814513] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- So it is clear that the "interruptible" part isn't handled correctly. When the process receives a signal, one could either attempt a clean abort (which appears to be difficult with this hardware) or just keep restarting the sleep until the wait queue really completes. But checking in a loop for -ERESTARTSYS is a bit too complicated for this driver, so just make the sleep uninterruptible, to avoid all that nonsense. The wait queue was actually restructured as a completion, after polling other drivers for the most "popular" approach. Fixes: 349ad66c ("spi:Add Freescale DSPI driver for Vybrid VF610 platform") Reported-by:
-
Vladimir Oltean authored
dspi->words_in_flight is a variable populated in the *_write functions and used in the dspi_fifo_read function. It is also used in dspi_fifo_write, immediately after transmission, to update the message->actual_length variable used by higher layers such as spi-mem for integrity checking. But it may happen that the IRQ which calls dspi_fifo_read to be triggered before the updating of message->actual_length takes place. In that case, dspi_fifo_read will decrement dspi->words_in_flight to -1, and that will cause an invalid modification of message->actual_length. For that, we make the simplest fix possible: to not decrement the actual shared variable in dspi->words_in_flight from dspi_fifo_read, but actually a copy of it which is on stack. But even if dspi_fifo_read from the next IRQ does not interfere with the dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still can. So we must assume that everything after the last write to the TX FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write function must be safe against that. This means refactoring the 2 flavours of FIFO writes (for EOQ and XSPI) such that the calculation of the number of words to be written is common and happens a priori. This way, the code for updating the message->actual_length variable works with a copy and not with the volatile dspi->words_in_flight. After some interior debate, the dspi->progress variable used for software timestamping was *not* backed up against preemption in a copy on stack. Because if preemption does occur between spi_take_timestamp_pre and spi_take_timestamp_post, there's really no point in trying to save anything. The first-in-time spi_take_timestamp_post call with a dspi->progress higher than the requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true anyway and will close the deal. To understand the above a bit better, consider a transfer with xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI controller timestamps in chunks of 4 bytes at a time, and preemption occurs in the middle of timestamping the first chunk: spi_take_timestamp_pre(0) . . (preemption) . . spi_take_timestamp_pre(4) . . spi_take_timestamp_post(7) . spi_take_timestamp_post(3) So the reason I'm not bothering to back up dspi->progress for that spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going to (a) be more honest, (b) provide better accuracy and (c) already render the spi_take_timestamp_post(3) into a noop by setting xfer->timestamped = true anyway. Fixes: d59c90a2 ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode") Reported-by: -
Vladimir Oltean authored
If dspi->words_in_flight is populated with the hardware FIFO size, then in dspi_fifo_read it will attempt to read more data at the end of a buffer that is not a multiple of 16 bytes in length. It will probably time out attempting to do so. So limit the num_fifo_entries variable to the actual number of FIFO entries that is going to be used. Fixes: d59c90a2 ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode") Signed-off-by:
-
Vladimir Oltean authored
In DMA mode, dspi_setup_accel does not get called, which results in the dspi->oper_word_size variable (which is used by dspi_dma_xfer) to not be initialized properly. Because oper_word_size is zero, a few calculations end up being incorrect, and the DMA transfer eventually times out instead of sending anything on the wire. Set up native transfers (or 8-on-16 acceleration) using dspi_setup_accel for DMA mode too. Also take the opportunity and simplify the DMA buffer handling a little bit. Fixes: 6c1c26ec ("spi: spi-fsl-dspi: Accelerate transfers using larger word size if possible") Signed-off-by:
-
Vladimir Oltean authored
In XSPI mode, the 32-bit PUSHR register can be written to separately: the higher 16 bits are for commands and the lower 16 bits are for data. This has nicely been hacked around, by defining a second regmap with a width of 16 bits, and effectively splitting a 32-bit register into 2 16-bit ones, from the perspective of this regmap_pushr. The problem is the assumption about the controller's endianness. If the controller is little endian (such as anything post-LS1046A), then the first 2 bytes, in the order imposed by memory layout, will actually hold the TXDATA, and the last 2 bytes will hold the CMD. So take the controller's endianness into account when performing split writes to PUSHR. The obvious and simple solution would have been to call regmap_get_val_endian(), but that is an internal regmap function and we don't want to change regmap just for this. Therefore, we just re-read the "big-endian" device tree property. Fixes: 58ba07ec ("spi: spi-fsl-dspi: Add support for XSPI mode registers") Signed-off-by:
-
Vladimir Oltean authored
The SPI_MCR_PCSIS macro assumes that the controller has a number of chip select signals equal to 6. That is not always the case, but actually is described through the driver-specific "spi-num-chipselects" device tree binding. LS1028A for example only has 4 chip selects. Don't write to the upper bits of the PCSIS field, which are reserved in the reference manual. Fixes: 349ad66c ("spi:Add Freescale DSPI driver for Vybrid VF610 platform") Signed-off-by:
-
- 17 Mar, 2020 1 commit
-
-
Linus Walleij authored
This driver is not using any symbols from the GPIO .h files so drop them. It was however implicitly using <linux/pinctrl/consumer.h> so include that instead. Cc: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200317092457.264055-1-linus.walleij@linaro.orgSigned-off-by:
-
- 13 Mar, 2020 2 commits
-
-
Geert Uytterhoeven authored
The descriptions for the spi-rx-bus-width and spi-tx-bus-width properties refer to "MISO" and "MOSI", which are not explained in the document. While these abbreviations are fairly common when talking about SPI, and thus may not need an explanation, they are not entirely correct in this context, as the SPI controller may be used in slave mode instead of master mode. Fix this by replacing them by "read transfers" resp. "write transfers", like is done for the spi-rx-delay-us and spi-tx-delay-us properties. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200306085038.8111-3-geert+renesas@glider.beSigned-off-by:
-
Geert Uytterhoeven authored
Currently, the DT bindings for an SPI controller specify that "#address-cells" must be fixed to one. However, that applies to an SPI controller in master mode only. When running in SPI slave mode, "#address-cells" should not be specified. Fix this making "#address-cells" mutually-exclusive with "spi-slave". Fixes: 0a1b9293 ("spi: Add YAML schemas for the generic SPI options") Reported-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
- 12 Mar, 2020 9 commits
-
-
Mark Brown authored
Merge series "spi: meson-spicc: add support for AXG and G12A variants" from Neil Armstrong <narmstrong@baylibre.com>: The SPICC controller in Amlogic AXG & G12A is capable of driving the CLK/MOSI/SS signal lines through the idle state which avoid the signals floating in unexpected state, is capable of using linear clock divider to reach a much fine tuned range of clocks, while the old controller only uses a power of two clock divider, result at a more coarse clock range and finally is capable of running at 80M clock. The SPICC controller in Amlogic G12A takes the source clock from a specific clock instead of the bus clock and has a different FIFO size and doesn't handle the RX Half interrupt the same way as GXL & AXG variants. Thus the burst management is simplified and takes in account a variable FIFO size. Now the controller can support frequencies higher than 30MHz, we need the setup the I/O line delays in regard of the SPI clock frequency. Neil Armstrong (7): spi: meson-spicc: remove unused variables spi: meson-spicc: support max 80MHz clock spi: meson-spicc: add min sclk for each compatible spi: meson-spicc: setup IO line delay spi: meson-spicc: adapt burst handling for G12A support dt-bindings: spi: amlogic,meson-gx-spicc: add Amlogic G12A compatible spi: meson-spicc: add support for Amlogic G12A Sunny Luo (2): spi: meson-spicc: enhance output enable feature spi: meson-spicc: add a linear clock divider support .../bindings/spi/amlogic,meson-gx-spicc.yaml | 22 + drivers/spi/Kconfig | 1 + drivers/spi/spi-meson-spicc.c | 496 +++++++++++++----- 3 files changed, 392 insertions(+), 127 deletions(-) -- 2.22.0 _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic
-
Wolfram Sang authored
to_spi_device() already checks 'dev'. No need to do it before calling it. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20200312134507.10000-1-wsa@the-dreams.deSigned-off-by:
-
Neil Armstrong authored
The Amlogic G12A SPICC controllers uses a secondary clock used to feed the baud rate generator and the delay control logic. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-9-narmstrong@baylibre.comSigned-off-by:
-
Neil Armstrong authored
Add support for the SPICC controllers on the Amlogic G12A SoCs family. The G12A SPICC controllers inherit from the AXG enhanced registers but takes an external pclk for the baud rate generator and can achieve up to 166MHz SCLK. Signed-off-by:
-
Neil Armstrong authored
The G12A SPICC controller variant has a different FIFO size and doesn't handle the RX Half interrupt the same way as GXL & AXG variants. Thus simplify the burst management and take in account a variable FIFO size. Signed-off-by:
-
Neil Armstrong authored
Now the controller can support frequencies higher than 30MHz, we need the setup the I/O line delays in regard of the SPI clock frequency. Signed-off-by:
-
Neil Armstrong authored
The G12A SPICC controller variant takes the source clock from a specific clock instead of the bus clock. The minimal clock calculus won't work with the G12A support, thus add the minimal supported clock for each variant and pass this to the SPI core. Signed-off-by:
-
Neil Armstrong authored
The SPICC controller in Meson-AXG is capable of running at 80M clock. The ASIC IP is improved and the clock is actually running higher than previous old SoCs. Signed-off-by:
Yixun Lan <yixun.lan@amlogic.com> Signed-off-by:
Sunny Luo <sunny.luo@amlogic.com> Link: https://lore.kernel.org/r/20200312133131.26430-5-narmstrong@baylibre.comSigned-off-by:
-
Sunny Luo authored
The SPICC controller in Meson-AXG SoC is capable of using a linear clock divider to reach a much fine tuned range of clocks, while the old controller only use a power of two clock divider, result at a more coarse clock range. Also convert the clock registration into Common Clock Framework. Signed-off-by:
-
