- 18 Mar, 2020 1 commit
-
-
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: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200318001603.9650-2-olteanv@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 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: Mark Brown <broonie@kernel.org>
-
- 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: Mark Brown <broonie@kernel.org>
-
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: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200306085038.8111-2-geert+renesas@glider.beSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 12 Mar, 2020 12 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: 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.deSigned-off-by: Mark Brown <broonie@kernel.org>
-
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: Mark Brown <broonie@kernel.org>
-
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 <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-10-narmstrong@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
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 <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-8-narmstrong@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
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 <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-7-narmstrong@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
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 <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200312133131.26430-6-narmstrong@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
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: 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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
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: 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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Sunny Luo authored
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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Neil Armstrong authored
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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Dan Carpenter authored
The platform_get_resource_byname() function returns NULL on error, it doesn't return error pointers. Fixes: d166a735 ("spi: fspi: dynamically alloc AHB memory") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200312113154.GC20562@mwandaSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 11 Mar, 2020 6 commits
-
-
Mark Brown authored
Merge tag 'mtk-mtd-spi-move' of 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.
-
Chuanhong Guo authored
This driver is superseded by the new spi-mtk-nor driver. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Acked-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200306085052.28258-5-gch981213@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Chuanhong Guo authored
spi-mtk-nor is a driver to replace mtk-quadspi and they have almost the same device-tree bindings. Reuse this binding documentation and convert it for new driver: 1. "Mediatek SoCs" -> "Mediatek ARM SoCs" because MTK MIPS SoCs use different controllers. 2. document "interrupts" as a required property because it's available on all SoCs with this controller and new driver takes advantages of it. It's implemented as optional only to maintain backward compatibility. 3. add a dummy interrupt binding in example. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200306085052.28258-4-gch981213@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Chuanhong Guo authored
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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Chuanhong Guo authored
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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
John Garry authored
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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 10 Mar, 2020 7 commits
-
-
Michael Walle authored
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.ccSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
Merge series "spi: Add FSI-attached SPI controller driver" from Eddie James <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
-
Qiujun Huang authored
some members were not described in documentation. Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Link: https://lore.kernel.org/r/1583774179-30736-1-git-send-email-hqjagain@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Geert Uytterhoeven authored
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.beSigned-off-by: Mark Brown <broonie@kernel.org>
-
Johan Jonker authored
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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Eddie James authored
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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Eddie James authored
Add documentation for the FSI2SPI CFAM engine, which provides access to a number of SPI controllers. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20200306194118.18581-2-eajames@linux.ibm.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 06 Mar, 2020 1 commit
-
-
Joe Perches authored
commit a2ca53b5 ("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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 05 Mar, 2020 10 commits
-
-
Mark Brown authored
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
-
Johan Jonker authored
The description below is already in use for rk3328.dtsi, but was somehow never added to a document, so add "rockchip,rk3328-spi", "rockchip,rk3066-spi" for spi nodes on a rk3328 platform to spi-rockchip.yaml. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200304184203.9548-3-jbx6244@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Johan Jonker authored
The description below is already in use for rk3308.dtsi, but was somehow never added to a document, so add "rockchip,rk3308-spi", "rockchip,rk3066-spi" for spi nodes on a rk3308 platform to spi-rockchip.yaml. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200304184203.9548-2-jbx6244@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Johan Jonker authored
Current dts files with 'spi' nodes are manually verified. In order to automate this process spi-rockchip.txt has to be converted to yaml. In the new setup spi-rockchip.yaml will inherit properties from spi-controller.yaml. Add document to MAINTAINERS. Also rk3188.dtsi, rk3288.dtsi, rk3368.dtsi and rk3399.dtsi use an extra fallback string, so change this in the documentation. Changed: "rockchip,rk3188-spi", "rockchip,rk3066-spi" "rockchip,rk3288-spi", "rockchip,rk3066-spi" "rockchip,rk3368-spi", "rockchip,rk3066-spi" "rockchip,rk3399-spi", "rockchip,rk3066-spi" Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200304184203.9548-1-jbx6244@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Sascha Hauer authored
The SPI bus number is completely optional to Linux, so make the corresponding device tree property optional as well. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20200305115546.31814-1-s.hauer@pengutronix.deSigned-off-by: Mark Brown <broonie@kernel.org>
-
Adam Ford authored
Add support for nxp,imx8qxp-fspi and nxp,imx8mm-fspi do the bindings document. Signed-off-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/20200126140913.2139260-4-aford173@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Han Xu authored
Apply patch from NXP upstream repo to Enable the octal combination mode in MCR0 Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20200126140913.2139260-3-aford173@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Han Xu authored
Apply patch from NXP upstream repo to dynamically allocate AHB memory as needed. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20200126140913.2139260-2-aford173@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Han Xu authored
Pull in this patch from NXP's upstream repo to enable fspi on imx8qxp and imx8mm Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20200126140913.2139260-1-aford173@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Vladimir Oltean authored
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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-