summaryrefslogtreecommitdiffstats
path: root/drivers/spi
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'sound-5.7-rc1' of ↵Linus Torvalds2020-04-021-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound updates from Takashi Iwai: "This became again a busy development cycle. There are few ALSA core updates (merely API cleanups and sparse fixes), with the majority of other changes are found in ASoC scene. Here are some highlights: ALSA core: - More helper macros for sparse warning fixes (e.g. bitwise types) - Slight optimization of PCM OSS locks - Make common handling for PCM / compress buffers (for SOF) ASoC: - Lots of code refactoring and modernization for (still ongoing) componentization works - Conversion of SND_SOC_ALL_CODECS to use imply - Continued refactoring and fixing of the Intel SOF/SST support, including the initial (but still incomplete) SoundWire support - SoundWire and more advanced clocking support for Realtek RT5682 - Support for amlogic GX, Meson 8, Meson 8B and T9015 DAC, Broadcom DSL/PON, Ingenic JZ4760 and JZ4770, Realtek RL6231, and TI TAS2563 and TLV320ADCX140 HD-audio: - Optimizations in HDMI jack handling - A few new quirks and fixups for Realtek codecs USB-audio: - Delayed registration support - New quirks for Motu, Kingston, Presonus" * tag 'sound-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (415 commits) ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor Revert "ALSA: uapi: Drop asound.h inclusion from asoc.h" ALSA: hda/realtek - Remove now-unnecessary XPS 13 headphone noise fixups ALSA: hda/realtek - Set principled PC Beep configuration for ALC256 ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256 ALSA: hda/realtek - a fake key event is triggered by running shutup ALSA: hda: default enable CA0132 DSP support ASoC: amd: acp3x-pcm-dma: clean up two indentation issues ASoC: tlv320adcx140: Remove undocumented property ASoC: Intel: sof_sdw: Add Volteer support with RT5682 SNDW helper function ASoC: Intel: common: add match table for TGL RT5682 SoundWire driver ASoC: Intel: boards: add sof_sdw machine driver ASoC: Intel: soc-acpi: update topology and driver name for SoundWire platforms ASoC: rt5682: move DAI clock registry to I2S mode ASoC: pxa: magician: convert to use i2c_new_client_device() ASoC: SOF: Intel: hda-ctrl: add reset cycle before parsing capabilities Asoc: SOF: Intel: hda: check SoundWire wakeen interrupt in irq thread ASoC: SOF: Intel: hda: add WAKEEN interrupt support for SoundWire ASoC: SOF: Intel: hda: add parameter to control SoundWire clock stop quirks ASoC: SOF: Intel: hda: merge IPC, stream and SoundWire interrupt handlers ...
| * Merge tag 'v5.6-rc5' into asoc-5.7Mark Brown2020-03-118-64/+125
| |\ | | | | | | | | | Linux 5.6-rc5
| * | spi: pxa2xx: Enable support for compile-testingGeert Uytterhoeven2020-02-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | m68k/allmodconfig: WARNING: unmet direct dependencies detected for SPI_PXA2XX Depends on [n]: SPI [=y] && SPI_MASTER [=y] && (ARCH_PXA || ARCH_MMP || PCI [=n] || ACPI) Selected by [m]: - SND_SOC_INTEL_BDW_RT5677_MACH [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_SOC_INTEL_MACH [=y] && (SND_SOC_INTEL_HASWELL [=n] || SND_SOC_SOF_BROADWELL [=m]) && I2C [=m] && (I2C_DESIGNWARE_PLATFORM [=m] || COMPILE_TEST [=y]) && (GPIOLIB [=y] || COMPILE_TEST [=y]) && (X86_INTEL_LPSS || COMPILE_TEST [=y]) && SPI_MASTER [=y] This happens because SND_SOC_INTEL_BDW_RT5677_MACH selects SPI_PXA2XX, and the former depends on COMPILE_TEST, while the latter does not. Fix this by enabling compile-testing for SPI_PXA2XX. Fixes: 630db1549356f644 ("ASoC: Intel: bdw-rt5677: fix Kconfig dependencies") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200210093027.6672-1-geert@linux-m68k.org Signed-off-by: Mark Brown <broonie@kernel.org>
* | | Merge tag 'pm-5.7-rc1' of ↵Linus Torvalds2020-03-301-2/+2
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management updates from Rafael Wysocki: "These clean up and rework the PM QoS API, address a suspend-to-idle wakeup regression on some ACPI-based platforms, clean up and extend a few cpuidle drivers, update multiple cpufreq drivers and cpufreq documentation, and fix a number of issues in devfreq and several other things all over. Specifics: - Clean up and rework the PM QoS API to simplify the code and reduce the size of it (Rafael Wysocki). - Fix a suspend-to-idle wakeup regression on Dell XPS13 9370 and similar platforms where the USB plug/unplug events are handled by the EC (Rafael Wysocki). - CLean up the intel_idle and PSCI cpuidle drivers (Rafael Wysocki, Ulf Hansson). - Extend the haltpoll cpuidle driver so that it can be forced to run on some systems where it refused to load (Maciej Szmigiero). - Convert several cpufreq documents to the .rst format and move the legacy driver documentation into one common file (Mauro Carvalho Chehab, Rafael Wysocki). - Update several cpufreq drivers: * Extend and fix the imx-cpufreq-dt driver (Anson Huang). * Improve the -EPROBE_DEFER handling and fix unwanted CPU overclocking on i.MX6ULL in imx6q-cpufreq (Anson Huang, Christoph Niedermaier). * Add support for Krait based SoCs to the qcom driver (Ansuel Smith). * Add support for OPP_PLUS to ti-cpufreq (Lokesh Vutla). * Add platform specific intermediate callbacks support to cpufreq-dt and update the imx6q driver (Peng Fan). * Simplify and consolidate some pieces of the intel_pstate driver and update its documentation (Rafael Wysocki, Alex Hung). - Fix several devfreq issues: * Remove unneeded extern keyword from a devfreq header file and use the DEVFREQ_GOV_UPDATE_INTERNAL event name instead of DEVFREQ_GOV_INTERNAL (Chanwoo Choi). * Fix the handling of dev_pm_qos_remove_request() result (Leonard Crestez). * Use constant name for userspace governor (Pierre Kuo). * Get rid of doc warnings and fix a typo (Christophe JAILLET). - Use built-in RCU list checking in some places in the PM core to avoid false-positive RCU usage warnings (Madhuparna Bhowmik). - Add explicit READ_ONCE()/WRITE_ONCE() annotations to low-level PM QoS routines (Qian Cai). - Fix removal of wakeup sources to avoid NULL pointer dereferences in a corner case (Neeraj Upadhyay). - Clean up the handling of hibernate compat ioctls and fix the related documentation (Eric Biggers). - Update the idle_inject power capping driver to use variable-length arrays instead of zero-length arrays (Gustavo Silva). - Fix list format in a PM QoS document (Randy Dunlap). - Make the cpufreq stats module use scnprintf() to avoid potential buffer overflows (Takashi Iwai). - Add pm_runtime_get_if_active() to PM-runtime API (Sakari Ailus). - Allow no domain-idle-states DT property in generic PM domains (Ulf Hansson). - Fix a broken y-axis scale in the intel_pstate_tracer utility (Doug Smythies)" * tag 'pm-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (78 commits) cpufreq: intel_pstate: Simplify intel_pstate_cpu_init() tools/power/x86/intel_pstate_tracer: fix a broken y-axis scale ACPI: PM: s2idle: Refine active GPEs check ACPICA: Allow acpi_any_gpe_status_set() to skip one GPE PM: sleep: wakeup: Skip wakeup_source_sysfs_remove() if device is not there PM / devfreq: Get rid of some doc warnings PM / devfreq: Fix handling dev_pm_qos_remove_request result PM / devfreq: Fix a typo in a comment PM / devfreq: Change to DEVFREQ_GOV_UPDATE_INTERVAL event name PM / devfreq: Remove unneeded extern keyword PM / devfreq: Use constant name of userspace governor ACPI: PM: s2idle: Fix comment in acpi_s2idle_prepare_late() cpufreq: qcom: Add support for krait based socs cpufreq: imx6q-cpufreq: Improve the logic of -EPROBE_DEFER handling cpufreq: Use scnprintf() for avoiding potential buffer overflow cpuidle: psci: Split psci_dt_cpu_init_idle() PM / Domains: Allow no domain-idle-states DT property in genpd when parsing PM / hibernate: Remove unnecessary compat ioctl overrides PM: hibernate: fix docs for ioctls that return loff_t via pointer Documentation: intel_pstate: update links for references ...
| * \ \ Merge branch 'pm-qos'Rafael J. Wysocki2020-03-301-2/+2
| |\ \ \ | | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * pm-qos: (30 commits) PM: QoS: annotate data races in pm_qos_*_value() Documentation: power: fix pm_qos_interface.rst format warning PM: QoS: Make CPU latency QoS depend on CONFIG_CPU_IDLE Documentation: PM: QoS: Update to reflect previous code changes PM: QoS: Update file information comments PM: QoS: Drop PM_QOS_CPU_DMA_LATENCY and rename related functions sound: Call cpu_latency_qos_*() instead of pm_qos_*() drivers: usb: Call cpu_latency_qos_*() instead of pm_qos_*() drivers: tty: Call cpu_latency_qos_*() instead of pm_qos_*() drivers: spi: Call cpu_latency_qos_*() instead of pm_qos_*() drivers: net: Call cpu_latency_qos_*() instead of pm_qos_*() drivers: mmc: Call cpu_latency_qos_*() instead of pm_qos_*() drivers: media: Call cpu_latency_qos_*() instead of pm_qos_*() drivers: hsi: Call cpu_latency_qos_*() instead of pm_qos_*() drm: i915: Call cpu_latency_qos_*() instead of pm_qos_*() x86: platform: iosf_mbi: Call cpu_latency_qos_*() instead of pm_qos_*() cpuidle: Call cpu_latency_qos_limit() instead of pm_qos_request() PM: QoS: Add CPU latency QoS API wrappers PM: QoS: Adjust pm_qos_request() signature and reorder pm_qos.h PM: QoS: Simplify definitions of CPU latency QoS trace events ...
| | * | drivers: spi: Call cpu_latency_qos_*() instead of pm_qos_*()Rafael J. Wysocki2020-02-141-2/+2
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Call cpu_latency_qos_add/remove_request() instead of pm_qos_add/remove_request(), respectively, because the latter are going to be dropped. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Tested-by: Amit Kucheria <amit.kucheria@linaro.org>
* | | Merge branch 'spi-5.7' into spi-nextMark Brown2020-03-2724-574/+2968
|\ \ \ | |/ / |/| |
| * | spi: efm32: Convert to use GPIO descriptorsLinus Walleij2020-03-271-41/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.org Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-lpspi: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-03-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200320232515.GA24800@embeddedor.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-s3c24xx: Replace zero-length array with flexible-array memberGustavo A. R. Silva2020-03-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Andi Shyti <andi@etezian.org> Link: https://lore.kernel.org/r/20200320232556.GA24989@embeddedor.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: stm32: Fix comments compilation warningsAlain Volmat2020-03-201-17/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: atmel-quadspi: Add verbose debug facilities to monitor register accessesTudor Ambarus2020-03-201-22/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-dspi: Add support for LS1028AVladimir Oltean2020-03-181-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-dspi: Move invariant configs out of dspi_transfer_one_messageVladimir Oltean2020-03-181-26/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-10-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-dspi: Fix interrupt-less DMA mode taking an XSPI code pathVladimir Oltean2020-03-181-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: c55be3059159 ("spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-9-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-dspi: Avoid NULL pointer in dspi_slave_abort for non-DMA modeVladimir Oltean2020-03-181-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver does not create the dspi->dma structure unless operating in DSPI_DMA_MODE, so it makes sense to check for that. Fixes: f4b323905d8b ("spi: Introduce dspi_slave_abort() function for NXP's dspi SPI driver") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-8-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completionVladimir Oltean2020-03-181-13/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform") Reported-by: Michael Walle <michael@walle.cc> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-7-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-dspi: Protect against races on dspi->words_in_flightVladimir Oltean2020-03-181-59/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode") Reported-by: Michael Walle <michael@walle.cc> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-dspi: Avoid reading more data than written in EOQ modeVladimir Oltean2020-03-181-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-5-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-dspi: Fix bits-per-word acceleration in DMA modeVladimir Oltean2020-03-181-54/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 6c1c26ecd9a3 ("spi: spi-fsl-dspi: Accelerate transfers using larger word size if possible") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-4-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATAVladimir Oltean2020-03-181-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCRVladimir Oltean2020-03-181-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-2-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: mxs: Drop GPIO includesLinus Walleij2020-03-171-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.org Signed-off-by: Mark Brown <broonie@kernel.org>
| * | Merge series "spi: meson-spicc: add support for AXG and G12A variants" from ↵Mark Brown2020-03-122-127/+370
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| | * | spi: meson-spicc: add support for Amlogic G12ANeil Armstrong2020-03-121-8/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-10-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: meson-spicc: adapt burst handling for G12A supportNeil Armstrong2020-03-121-79/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-8-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: meson-spicc: setup IO line delayNeil Armstrong2020-03-121-1/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-7-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: meson-spicc: add min sclk for each compatibleNeil Armstrong2020-03-121-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-6-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: meson-spicc: support max 80MHz clockNeil Armstrong2020-03-121-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Neil Armstrong <narmstrong@baylibre.com> 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.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: meson-spicc: add a linear clock divider supportSunny Luo2020-03-122-40/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Neil Armstrong <narmstrong@baylibre.com> 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-4-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: meson-spicc: enhance output enable featureSunny Luo2020-03-121-2/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SPICC controller in Meson-AXG is capable of driving the CLK/MOSI/SS signal lines through the idle state (between two transmission operation), which avoid the signals floating in unexpected state. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> 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-3-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: meson-spicc: remove unused variablesNeil Armstrong2020-03-121-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove unused variables from spicc data struct. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-2-narmstrong@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | spi: acpi: remove superfluous parameter checkWolfram Sang2020-03-121-1/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20200312134507.10000-1-wsa@the-dreams.de Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-nxp-fspi: Fix a NULL vs IS_ERR() check in probeDan Carpenter2020-03-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The platform_get_resource_byname() function returns NULL on error, it doesn't return error pointers. Fixes: d166a73503ef ("spi: fspi: dynamically alloc AHB memory") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200312113154.GC20562@mwanda Signed-off-by: Mark Brown <broonie@kernel.org>
| * | Merge tag 'mtk-mtd-spi-move' of ↵Mark Brown2020-03-114-7/+702
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.7 spi: Rewrite mtk-quadspi spi-nor driver with spi-mem This patchset from Chuanhong Guo <gch981213@gmail.com> adds a spi-mem driver for Mediatek SPI-NOR controller, which already has limited support by mtk-quadspi. This new driver can make use of full quadspi capability of this controller.
| | * | spi: add support for mediatek spi-nor controllerChuanhong Guo2020-03-113-0/+700
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a driver for mtk spi-nor controller using spi-mem interface. The same controller already has limited support provided by mtk-quadspi driver under spi-nor framework and this new driver is a replacement for the old one. Comparing to the old driver, this driver has following advantages: 1. It can handle any full-duplex spi transfer up to 6 bytes, and this is implemented using generic spi interface. 2. It take account into command opcode properly. The reading routine in this controller can only use 0x03 or 0x0b as opcode on 1-1-1 transfers, but old driver doesn't implement this properly. This driver checks supported opcode explicitly and use (1) to perform unmatched operations. 3. It properly handles SFDP reading. Old driver can't read SFDP due to the bug mentioned in (2). 4. It can do 1-2-2 and 1-4-4 fast reading on spi-nor. These two ops requires parsing SFDP, which isn't possible in old driver. And the old driver is only flagged to support 1-1-2 mode. 5. It takes advantage of the DMA feature in this controller for long reads and supports IRQ on DMA requests to free cpu cycles from polling status registers on long DMA reading. It achieves up to 17.5MB/s reading speed (1-4-4 mode) which is way faster than the old one. IRQ is implemented as optional to maintain backward compatibility. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200306085052.28258-3-gch981213@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: make spi-max-frequency optionalChuanhong Guo2020-03-111-7/+2
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We only need a spi-max-frequency when we specifically request a spi frequency lower than the max speed of spi host. This property is already documented as optional property and current host drivers are implemented to operate at highest speed possible when spi->max_speed_hz is 0. This patch makes spi-max-frequency an optional property so that we could just omit it to use max controller speed. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200306085052.28258-2-gch981213@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: Stop selecting MTD_SPI_NOR for SPI_HISI_SFC_V3XXJohn Garry2020-03-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By selecting MTD_SPI_NOR for SPI_HISI_SFC_V3XX, we may introduce unmet dependencies: WARNING: unmet direct dependencies detected for MTD_SPI_NOR Depends on [m]: MTD [=m] && SPI_MASTER [=y] Selected by [y]: - SPI_HISI_SFC_V3XX [=y] && SPI [=y] && SPI_MASTER [=y] && (ARM64 && ACPI [=y] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] Since MTD_SPI_NOR is only selected by SPI_HISI_SFC_V3XX for practical reasons - slave devices use the spi-nor driver, enabled by MTD_SPI_NOR - just drop it. Signed-off-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1583948115-239907-1-git-send-email-john.garry@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-fsl-dspi: fix DMA mappingMichael Walle2020-03-101-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the correct device to request the DMA mapping. Otherwise the IOMMU doesn't get the mapping and it will generate a page fault. The error messages look like: [ 3.008452] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 [ 3.020123] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 This was tested on a custom board with a LS1028A SoC. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200310073313.21277-1-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org>
| * | Merge series "spi: Add FSI-attached SPI controller driver" from Eddie James ↵Mark Brown2020-03-103-0/+566
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <eajames@linux.ibm.com>: This series adds a dts binding and a driver for a new SPI controller that is accessed over FSI bus. Eddie James (2): dt-bindings: fsi: Add FSI2SPI bindings spi: Add FSI-attached SPI controller driver .../devicetree/bindings/fsi/ibm,fsi2spi.yaml | 36 ++ MAINTAINERS | 7 + drivers/spi/Kconfig | 7 + drivers/spi/Makefile | 1 + drivers/spi/spi-fsi.c | 558 ++++++++++++++++++ 5 files changed, 609 insertions(+) create mode 100644 Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml create mode 100644 drivers/spi/spi-fsi.c -- 2.24.0
| | * | spi: Add FSI-attached SPI controller driverEddie James2020-03-103-0/+566
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There exists a set of SPI controllers on some POWER processors that may be accessed through the FSI bus. Add a driver to traverse the FSI CFAM engine that can access and drive the SPI controllers. This driver would typically be used by a baseboard management controller (BMC). The SPI controllers operate by means of programming a sequencing engine which automatically manages the usual SPI protocol buses. The driver programs each transfer into the sequencer as various operations specifying the slave chip and shifting data in and out on the lines. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20200306194118.18581-3-eajames@linux.ibm.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | spi: rspi: Add support for active-high chip selectsGeert Uytterhoeven2020-03-101-4/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All RSPI variants support setting the polarity of the SSL signal. Advertize support for active-high chip selects, and configure polarity according to the state of the flag. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200309171537.21551-1-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | spi: rockchip: add compatible string for px30 rk3308 rk3328Johan Jonker2020-03-101-1/+4
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | The Rockchip spi binding is updated to yaml and new models were added. The spi on px30,rk3308 and rk3328 are the same as other Rockchip based SoCs, so add compatible string for it. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200309151004.7780-1-jbx6244@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: Remove CONFIG_ prefix from Kconfig selectJoe Perches2020-03-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a2ca53b52e00 ("spi: Add HiSilicon v3xx SPI NOR flash controller driver") likely inadvertently used a select statement with a CONFIG_ prefix, remove the prefix. Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Joe Perches <joe@perches.com> Acked-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/f8ac6b32a29b9a05b58a7e58ffe8b780642abbf1.camel@perches.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | Merge series "TCFQ to XSPI migration for NXP DSPI driver" from Vladimir ↵Mark Brown2020-03-052-153/+287
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Oltean <olteanv@gmail.com> Vladimir Oltean <vladimir.oltean@nxp.com>: From: Vladimir Oltean <vladimir.oltean@nxp.com> This series aims to remove the most inefficient transfer method from the NXP DSPI driver. TCFQ (Transfer Complete Flag) mode works by transferring one word, waiting for its TX confirmation interrupt (or polling on the equivalent status bit), sending the next word, etc, until the buffer is complete. The issue with this mode is that it's fundamentally incompatible with any sort of batching such as writing to a FIFO. But actually, due to previous patchset ("Compatible string consolidation for NXP DSPI driver"): https://patchwork.kernel.org/cover/11414593/ all existing users of TCFQ mode today already support a more advanced feature set, in the form of XSPI (extended SPI). XSPI brings 2 extra features: - Word sizes up to 32 bits. This is sub-utilized today, and acceleration of smaller-than-32 bpw values is provided. - "Command cycling", basically the ability to write multiple words in a row and receiving an interrupt only after the completion of the last one. This is what enables us to make use of the full FIFO depth of this controller. Series was tested on the NXP LS1021A-TSN and LS1043A-RDB boards, both functionally as well as from a performance standpoint. The command used to benchmark the increased throughput was: spidev_test --device /dev/spidev1.0 --bpw 8 --size 256 --cpha --iter 10000000 --speed 20000000 where spidev1.0 is a dummy spidev node, using a chip select that no peripheral responds to. On LS1021A, which has a 4-entry-deep FIFO and a less powerful CPU, the performance increase brought by this patchset is from 2700 kbps to 5800 kbps. On LS1043A, which has a 16-entry-deep FIFO and a more powerful CPU, the performance increases from 4100 kbps to 13700 kbps. On average, SPI software timestamping is not adversely affected by the extra batching, due to the extra patches. There is one extra patch which clarifies why the TCFQ users were not converted to the "other" mode in this driver that makes use of the FIFO, which would be EOQ mode. My request to the many people on CC (known users and/or contributors) is to give this series a test to ensure there are no regressions, and for the Coldfire maintainers to clarify whether the EOQ limitation is acceptable for them in the long run. Vladimir Oltean (12): spi: spi-fsl-dspi: Simplify bytes_per_word gymnastics spi: spi-fsl-dspi: Remove unused chip->void_write_data spi: spi-fsl-dspi: Don't mask off undefined bits spi: spi-fsl-dspi: Add comments around dspi_pop_tx and dspi_push_rx functions spi: spi-fsl-dspi: Rename fifo_{read,write} and {tx,cmd}_fifo_write spi: spi-fsl-dspi: Implement .max_message_size method for EOQ mode spi: Do spi_take_timestamp_pre for as many times as necessary spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode spi: spi-fsl-dspi: Accelerate transfers using larger word size if possible spi: spi-fsl-dspi: Optimize dspi_setup_accel for lowest interrupt count spi: spi-fsl-dspi: Use EOQ for last word in buffer even for XSPI mode spi: spi-fsl-dspi: Take software timestamp in dspi_fifo_write drivers/spi/spi-fsl-dspi.c | 421 ++++++++++++++++++++++++------------- drivers/spi/spi.c | 19 +- include/linux/spi/spi.h | 3 +- 3 files changed, 288 insertions(+), 155 deletions(-) -- 2.17.1
| | * | spi: spi-fsl-dspi: Take software timestamp in dspi_fifo_writeVladimir Oltean2020-03-051-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although the SPI system timestamps are supposed to reflect the moment that the peripheral has received a word rather than the moment when the CPU has enqueued that word to the FIFO, in practice it is easier to just record the latter time than the former (with a smaller error). With the recent migration of TCFQ users from poll back to interrupt mode (this time for XSPI FIFO), it's wiser to keep the interrupt latency outside of the measurement of the PTP system timestamp itself. If there proves to be any constant offset that requires static compensation, that can always be added later. So far that does not appear to be the case at least on the LS1021A-TSN board, where testing shows that the phc2sys offset is able to remain within +/- 200 ns even after 68 hours of testing. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-13-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: spi-fsl-dspi: Use EOQ for last word in buffer even for XSPI modeVladimir Oltean2020-03-051-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The EOQ mode has a hardware limitation in that it stops the transmission (including the deassertion of the chip select signal) once the host CPU requests end-of-queue for a particular word in the TX FIFO. And XSPI mode has a limitation in that we need a separate CMD FIFO entry for the last byte in the buffer, where the chip select signal needs to be deasserted. It's not a functional limitation, but it's rather clunky and the fact that we need to halt the pipeline and write a single entry to the TX FIFO whenever a buffer ends brings the throughput down when transmitting small buffers. So the idea here is to use EOQ's limitation in our favor when using XSPI mode. Stop special-casing that final word in the buffer, and just kill the chip select signal by issuing an EOQ for that last word. Now it can be mixed in with all the other words in the current TX FIFO train. A small trick here is that we still keep using the XSPI-specific signaling via the CMDTCFQ interrupt in RSER, and not enabling the EOQ interrupt, in order to avoid hardware weirdness (potential races with separate interrupts being raised for CMDTCFQ and EOQ for what is in fact the end of the same transmission). That is just theoretical, but it's good to be cautious, and the EOQ interrupt isn't needed. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-12-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: spi-fsl-dspi: Optimize dspi_setup_accel for lowest interrupt countVladimir Oltean2020-03-051-11/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, a SPI transfer that is not multiple of the highest supported word width (e.g. 4 bytes) will be transmitted as follows (assume a 30-byte buffer transmitted through a 32-bit wide FIFO that is 32 bytes deep): - First 28 bytes are sent as 7 words of 32 bits each - Last 2 bytes are sent as 1 word of 16 bits size But if the dspi_setup_accel function had decided to use a lower oper_bits_per_word value (16 instead of 32), there would have been enough space in the TX FIFO to fit the entire buffer in one go (15 words of 16 bits each). What we're actually trying to avoid is mixing word sizes within the same run with the TX FIFO, since there is an erratum surrounding this, and invalid data might get transmitted. So this patch adds special cases for when the remaining length of the buffer can be sent in one go as 8-bit or 16-bit words, otherwise it falls back to the standard logic of sending as many bytes as possible at the highest oper_bits_per_word value possible. The benefit is that there will be one less CMDFQ/EOQ interrupt to service when the entire buffer is transmitted during a single go, and that will improve the overall latency of the transfer. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-11-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: spi-fsl-dspi: Accelerate transfers using larger word size if possibleVladimir Oltean2020-03-051-25/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds logic in the driver to transmit SPI buffers that use bits_per_word=8 with a higher bits_per_word count (multiple of 8). Currently the following (most common) modes are implemented: - 8 bits_per_word on 32-bit capable controllers - 8 bits_per_word on 16-bit capable controllers - 16 bits_per_word on 32-bit capable controllers Transfers which are not accelerated are transferred with a hardware bits_per_word value equal to the one of the SPI transfer. The difference from just extending bits_per_word=32 at the spi_device driver level is that endianness is different - the SPI core wants to treat bits_per_word=32 buffers as arrays of u32 (i.e. words in host CPU endianness). So to preserve endianness when clumping 8x4 bits into 32-bit words, one must perform conversion between CPU and standard (big) endianness. All appearances (both on the wire as well as in the buffers presented to the peripheral driver) are preserved, just that accesses to the PUSHR and POPR registers are now more efficient, since the same number of reads/writes can now carry more data (2x more data on TX, 4x more data on RX). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-10-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| | * | spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO modeVladimir Oltean2020-03-051-88/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Transfer Complete Flag (TCF) interrupt gets raised after each write to the TX FIFO (PUSHR) which means that it is not possible to devise a transfer procedure that makes full utilization of the FIFO depth (4 entries on most controllers, 16 entries on some). On the other hand, XSPI mode has a feature called "command cycling", which allows a single TX command to be run for a pre-specified number of TX words. When the command cycle ends, the Command Transfer Complete Flag bit asserts and raises an interrupt. The advantage in this mode is that the TX FIFO can be better utilized (more words can be batched at once). Other changes brought by this patch: - The dspi->rx_end variable has been removed, since now the dspi_fifo_write function sets up dspi->words_in_flight, so dspi_fifo_read knows how much to read without overrunning the RX buffer. - Stop using poll mode unconditionally for TCFQ mode, since XSPI mode is a little less efficient than that, and so, poll mode doesn't bring as many improvements for XSPI. - Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and instead increment the message->actual_length based on the newly introduced dspi->words_in_flight variable. - The CTARE register is now written in the hotpath instead of just at transfer init time, since it contains the DTCP field (transfer preload - the counter indicating how many txdata words will follow), which is a dynamic value. Due to the fact that the Chip Select toggling setting is part of the command written to the TX FIFO, the ending word of each buffer needs to be sent via its own TX command, so that we have a chance to emit a 1-word command with deasserted PCS. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-18 05:24:02 +0000