u-boot.git/drivers/spi, branch v2022.10

renesas: Fix RPC-IF compatible values

2022-09-02T11:25:01Z

The compatible values used for device nodes representing Renesas Reduced Pin Count Interfaces were based on preliminary versions of the Device Tree Bindings. Correct them in both DTSi files and drivers, to match the final DT Bindings. Note that there are no DT bindings for RPC-IF on RZ/A1 yet, hence the most logical SoC-specific value is used, without specifying a family-specific value. Signed-off-by: Geert Uytterhoeven

spi: zynq_qspi: Fix programming qspi speed

2022-07-26T07:34:21Z

When programming qspi flash speed we need to check the requested flash speed not to exceed the spi max frequency. In the current implementation we are checking qspi ref clk instead. This commit fixes the issue by checking the requested speed and programs the specified max frequency. Signed-off-by: Ashok Reddy Soma Link: https://lore.kernel.org/r/1657893679-20039-5-git-send-email-ashok.reddy.soma@xilinx.com Signed-off-by: Michal Simek

spi: zynq_qspi: Add support for zynq_qspi_mem_exec_op

2022-07-26T07:34:21Z

Add support_ops function zynq_qspi_mem_exec_op to check controller supported operations by spi-mem framework. Current default support ops function does not allow dummy buswidth no more than 1, unless we are using buswidth is 4 for TX. Signed-off-by: Ashok Reddy Soma Link: https://lore.kernel.org/r/1657893679-20039-4-git-send-email-ashok.reddy.soma@xilinx.com Signed-off-by: Michal Simek

spi: zynq_qspi: Use dummy buswidth in dummy byte calculation

2022-07-26T07:34:21Z

Fix dummy bytes calculation incase of valid dummy bytes when dummy buswidth is > 1. Current dummy bytes calculation does not provide correct dummy values for dummy buswidth > 1. Signed-off-by: T Karthik Reddy Signed-off-by: Ashok Reddy Soma Link: https://lore.kernel.org/r/1657893679-20039-3-git-send-email-ashok.reddy.soma@xilinx.com Signed-off-by: Michal Simek

spi: zynq_qspi: Add child pre probe function

2022-07-26T07:34:21Z

Add child pre probe function in the driver. Update max_hz of priv from spi_slave structure. Signed-off-by: Siva Durga Prasad Paladugu Signed-off-by: Ashok Reddy Soma Link: https://lore.kernel.org/r/1657893679-20039-2-git-send-email-ashok.reddy.soma@xilinx.com Signed-off-by: Michal Simek

spi: xilinx_spi: Add support ops to axi qspi driver

2022-07-26T07:34:21Z

Add support_ops function to check controller supported operations by spi-mem framework. Current default support ops function does not allow dummy buswidth no more than 1, unless we are using buswidth is 4 for TX. In order to support dummy buswidth > 1 by spi-nor framework we are adding explicit support_ops to check controller supported operations. Fix dummy bytes calculation incase of valid dummy bytes when dummy buswidth is > 1. Current dummy bytes calculation does not provide correct dummy values for dummy buswidth > 1. Signed-off-by: T Karthik Reddy Signed-off-by: Ashok Reddy Soma Link: https://lore.kernel.org/r/1657954727-31972-3-git-send-email-ashok.reddy.soma@xilinx.com Signed-off-by: Michal Simek

spi: xilinx_spi: Add support for spi memory operations

2022-07-26T07:34:21Z

Add support for spi memory operations for xilinx AXI qspi driver. This provides an high-level interface to execute SPI memory operations by the controller. Remove existing spi transfer based implementation and use spi memory based exec_op() implementation for qspi IO operations. Simplified existing startup_block implementation. Signed-off-by: T Karthik Reddy Signed-off-by: Ashok Reddy Soma Link: https://lore.kernel.org/r/1657954727-31972-2-git-send-email-ashok.reddy.soma@xilinx.com Signed-off-by: Michal Simek

spi: sunxi: Add support for F1C100s SPI controller

2022-07-18T10:34:22Z

The SPI controllers in the Allwinner F1Cx00 series of SoCs are compatible to the H3 IP. The only difference in the integration is the missing mod clock in the F1C100, instead the SPI clock is directly derived from the AHB clock. We *should* be able to model this through the DT, but the addition of get_rate() requires quite some refactoring, so it's not really worth in this simple case: We programmed both the PLL_PERIPH to 600 MHz and the PLL/AHB divider to 3 in the SPL, so we know the SPI base clock is 200 MHz. Since we used a hard coded fixed clock rate of 24 MHz for all the other SoCs so far, we can as well do the same for the F1C100. Define the SPI input clock and maximum frequency differently when compiling for the F1C100 SoC. Also adjust the power-of-2 divider programming, because that uses a "minus one" encoding, compared to the other SoCs. This allows to enable SPI flash support for the F1C100 boards. Signed-off-by: Andre Przywara

spi: sunxi: improve SPI clock calculation

2022-07-18T10:27:59Z

The current SPI clock divider calculation has two problems: - We use a normal round-down division, which results in a divider typically being too small, resulting in a too high frequency on the bus. - The calculaction for the power-of-two divider is very inaccurate, and again rounds down, which might lead to wild bus frequencies. This wasn't a real problem so far, since most chips can handle slightly higher bus frequencies just fine. Also the actual speed was mostly lost anyway, due to release_bus() reseting the device. And the power-of-2 calculation was probably never used, because it only applies to frequencies below 47 KHz. However this will become a problem for the F1C100s support, due to its much higher base frequency. Calculate a safe divider correctly (using round-up), and re-use that value when calculating the power-of-2 value. We also separate the maximum frequency and the input clock on the way, since they will be different for the F1C100s. Signed-off-by: Andre Przywara

spi: sunxi: refactor SPI speed/mode programming

2022-07-18T10:27:58Z

As George rightfully pointed out [1], the spi-sunxi driver programs the speed and mode settings only when the respective functions are called, but this gets lost over a call to release_bus(). That asserts the reset line, thus forces each SPI register back to its default value. Adding to that, trying to program SPI_CCR and SPI_TCR might be pointless in the first place, when the reset line is still asserted (before claim_bus()), so those setting won't apply most of the time. In reality I see two nested claim_bus() calls for the first use, so settings between the two would work (for instance for the initial "sf probe"). However later on the speed setting is not programmed into the hardware anymore. So far we get away with that default frequency, because that is a rather tame 24 MHz, which most SPI flash chips can handle just fine. Move the actual register programming into a separate function, and use .set_speed and .set_mode just to set the variables in our priv structure. Then we only call this new function in claim_bus(), when we are sure that register accesses actually work and are preserved. [1] https://lore.kernel.org/u-boot/20210725231636.879913-17-me@yifangu.com/ Signed-off-by: Andre Przywara Reported-by: George Hilliard