On Wed, Dec 22, 2021 at 04:27:36PM +0200, Oskari Lemmelä wrote: > On 22.12.2021 14.32, Mark Brown wrote: > > Does this actually materially affect what the hardware does? How much > > data is transferred in an internal loop in the driver is completely > > immaterial, bits per word only matters for formatting of the transferred > > data. > I don't have logic analyzator to verify what hardware actual does. > I tested this with transferring 32bits to ATSAMD20J15 slave. > Running loop in 8bits or 16bits, transfer is done correctly without > any errors. When running loop in 24bits or 32bits directly I got > error from spi_sync_transfer. This doesn't inspire confidence TBH. Given the lack of any change in the interaction with the hardware it doesn't seem likely that the word length is being changed at any point. Possibly there's a bug somewhere that needs fixing but it's been misdiagnosed. Note also that the commit log is not good here, now I look at the code the driver only supports 8 bits per word at the minute and the change adds support for higher word lengths. If you are seeing an issue that might point towards what it is.
Attachment:
signature.asc
Description: PGP signature
