Re: [PATCH v5 1/7] spi: Enable controllers to extend the SPI protocol with MOSI idle configuration

["Nuno Sá" <noname.nuno@gmail.com>]

On Tue, 2024-06-25 at 18:53 -0300, Marcelo Schmitt wrote:
> The behavior of an SPI controller data output line (SDO or MOSI or COPI
> (Controller Output Peripheral Input) for disambiguation) is usually not
> specified when the controller is not clocking out data on SCLK edges.
> However, there do exist SPI peripherals that require specific MOSI line
> state when data is not being clocked out of the controller.
> 
> Conventional SPI controllers may set the MOSI line on SCLK edges then bring
> it low when no data is going out or leave the line the state of the last
> transfer bit. More elaborated controllers are capable to set the MOSI idle
> state according to different configurable levels and thus are more suitable
> for interfacing with demanding peripherals.
> 
> Add SPI mode bits to allow peripherals to request explicit MOSI idle state
> when needed.
> 
> When supporting a particular MOSI idle configuration, the data output line
> state is expected to remain at the configured level when the controller is
> not clocking out data. When a device that needs a specific MOSI idle state
> is identified, its driver should request the MOSI idle configuration by
> setting the proper SPI mode bit.
> 
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> ---

One minor nit... With that:

Acked-by: Nuno Sa <nuno.sa@analog.com>

>  Documentation/spi/spi-summary.rst | 83 +++++++++++++++++++++++++++++++
>  drivers/spi/spi.c                 |  7 +++
>  include/linux/spi/spi.h           |  6 +++
>  include/uapi/linux/spi/spi.h      |  5 +-
>  4 files changed, 99 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/spi/spi-summary.rst b/Documentation/spi/spi-
> summary.rst
> index 7f8accfae6f9..51dd8a105b7e 100644
> --- a/Documentation/spi/spi-summary.rst
> +++ b/Documentation/spi/spi-summary.rst
> @@ -614,6 +614,89 @@ queue, and then start some asynchronous transfer engine
> (unless it's
>  already running).
>  
>  
> +Extensions to the SPI protocol
> +------------------------------
> +The fact that SPI doesn't have a formal specification or standard permits
> chip
> +manufacturers to implement the SPI protocol in slightly different ways. In
> most
> +cases, SPI protocol implementations from different vendors are compatible
> among
> +each other. For example, in SPI mode 0 (CPOL=0, CPHA=0) the bus lines may
> behave
> +like the following:
> +
> +::
> +
> +  nCSx ___                                                                  
> ___
> +          \_________________________________________________________________/
> +          •                                                                 •
> +          •                                                                 •
> +  SCLK         ___     ___     ___     ___     ___     ___     ___     ___
> +       _______/   \___/   \___/   \___/   \___/   \___/   \___/   \___/  
> \_____
> +          •   :   ;   :   ;   :   ;   :   ;   :   ;   :   ;   :   ;   :   ; •
> +          •   :   ;   :   ;   :   ;   :   ;   :   ;   :   ;   :   ;   :   ; •
> +  MOSI XXX__________         _______                 _______        
> ________XXX
> +  0xA5 XXX__/ 1     \_0_____/ 1     \_0_______0_____/ 1     \_0_____/ 1   
> \_XXX
> +          •       ;       ;       ;       ;       ;       ;       ;       ; •
> +          •       ;       ;       ;       ;       ;       ;       ;       ; •
> +  MISO XXX__________         _______________________          _______       
> XXX
> +  0xBA XXX__/     1 \_____0_/     1       1       1 \_____0__/    1 
> \____0__XXX
> +
> +Legend::
> +
> +  • marks the start/end of transmission;
> +  : marks when data is clocked into the peripheral;
> +  ; marks when data is clocked into the controller;
> +  X marks when line states are not specified.
> +
> +In some few cases, chips extend the SPI protocol by specifying line behaviors
> +that other SPI protocols don't (e.g. data line state for when CS is
> inactive).

Forgot this one... inactive -> deasserted (or not asserted)

- Nuno Sá