[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YcM9Ug3JhaxynLt0@sirena.org.uk>
Date: Wed, 22 Dec 2021 14:59:30 +0000
From: Mark Brown <broonie@...nel.org>
To: Oskari Lemmelä <oskari@...mela.net>
Cc: linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] spi: ar934x: fix transfer size
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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists