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@xxxxxxxxxx> > --- One minor nit... With that: Acked-by: Nuno Sa <nuno.sa@xxxxxxxxxx> > 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á
