On 06/05, Mark Brown wrote: > On Wed, Jun 05, 2024 at 11:37:48AM -0500, David Lechner wrote: > > On 6/5/24 7:24 AM, Mark Brown wrote: > > > On Tue, Jun 04, 2024 at 07:41:47PM -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 not specified > > >> when the controller is not clocking out data on SCLK edges. However, there > > >> exist SPI peripherals that require specific COPI line state when data is > > >> not being clocked out of the controller. > > > I think this description is missing a key detail that the tx data line > > needs to be high just before and also during the CS assertion at the start > > of each message. > > > And it would be helpful to have this more detailed description in the > > source code somewhere and not just in the commit message. > > Yes, there's no way anyone could infer this from any aspect of the > series. I think the properties also need a clearer name since someone > might want the accelerator functionality at some point. So, if I understand correctly, it would be desirable to also have flags and descriptions for the MOSI idle configuration capabilities in include/linux/spi/spi.h. Does the following definitions look good? #define SPI_CONTROLLER_MOSI_IDLE_LOW BIT(8) #define SPI_CONTROLLER_MOSI_IDLE_HIGH BIT(9) Maybe also document the MOSI idle configuration feature in spi-summary.rst? > > > > Even without that we'd need feature detection so that drivers that try > > > to use this aren't just buggy when used with a controller that doesn't > > > implement it, but once you're detecting you may as well just make things > > > work. > > > I could see something like this working for controllers that leave the > > tx data line in the state of the last bit of a write transfer. I.e. do a > > write transfer of 0xff (using the smallest number of bits per word > > supported by the controller) with CS not asserted, then assert CS, then > > do the rest of actual the transfers requested by the peripheral. > > > But it doesn't seem like it would work for controllers that always > > return the tx data line to a low state after a write since this would > > mean that the data line would still be low during the CS assertion > > which is what we need to prevent. > > With the additional requirement it's not emulatable, but we'd still need > the checks in the core.
