Lines Matching +full:stm32 +full:- +full:spi
39 Another case is SPI. Unfortunately, the current SPI API can't be used to handle the host commands
40 communication. The main issues are unknown command size sent by the host (the SPI transaction
41 sends/receives specific number of bytes) and need to constant sending status byte (the SPI module
42 is enabled and disabled per transaction). It forces implementing the SPI driver within a backend,
43 as it is done for SHI. That means a SPI backend has to be implemented per chip family. However, it
44 can be changed in the future once the SPI API is extended to host command needs. Please check `the
45 discussion <https://github.com/zephyrproject-rtos/zephyr/issues/56091>`_.
47 That approach requires configuring the SPI dts node in a special way. The main compatible string of
48 a SPI node has changed to use the Host Command version of a SPI driver. The rest of the properties
49 should be configured as usual. Example of the SPI node for STM32:
51 .. code-block:: devicetree
55 * STM32 SPI driver
57 compatible = "st,stm32-spi-host-cmd";
62 dma-names = "tx", "rx";
64 cs-gpios = <&gpioa 4 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
67 The STM32 SPI host command backend driver supports the :dtcompatible:`st,stm32h7-spi` and
68 :dtcompatible:`st,stm32-spi-fifo` variant implementations. To enable these variants, append the
72 .. code-block:: devicetree
75 compatible = "st,stm32h7-spi", "st,stm32-spi-fifo", "st,stm32-spi-host-cmd";
79 The chip that runs Zephyr is a SPI slave and the ``cs-gpios`` property is used to point our CS pin.
80 For the SPI, it is required to set the backend chosen node ``zephyr,host-cmd-spi-backend``.
85 * SHI - ITE and NPCX
86 * eSPI - any eSPI slave driver that support :kconfig:option:`CONFIG_ESPI_PERIPHERAL_EC_HOST_CMD` and
88 * UART - any UART driver that supports the asynchronous API
89 * SPI - STM32
98 * ``zephyr,host-cmd-espi-backend``
99 * ``zephyr,host-cmd-shi-backend``
100 * ``zephyr,host-cmd-uart-backend``
101 * ``zephyr,host-cmd-spi-backend``