Re: [PATCH 3/6] spi: add multi_bus_mode field to struct spi_transfer

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

On Thu, 2025-10-16 at 10:25 -0500, David Lechner wrote:
> On 10/16/25 4:08 AM, Nuno Sá wrote:
> > On Wed, 2025-10-15 at 13:38 -0500, David Lechner wrote:
> > > On 10/15/25 11:43 AM, Nuno Sá wrote:
> > > > On Wed, 2025-10-15 at 11:15 -0500, David Lechner wrote:
> > > > > On 10/15/25 10:18 AM, Mark Brown wrote:
> > > > > > On Wed, Oct 15, 2025 at 03:43:09PM +0100, Nuno Sá wrote:
> > > > > > > On Wed, 2025-10-15 at 13:01 +0100, Mark Brown wrote:
> > > > > > > > On Wed, Oct 15, 2025 at 11:16:01AM +0100, Nuno Sá wrote:
> > > > > > > > > On Tue, 2025-10-14 at 17:02 -0500, David Lechner wrote:
> 
> ...
> 
> > > 
> > > The AXI SPI Engine doesn't know how to do the quad SPI part yet though, so
> > > it isn't something we could implement right now.
> > > 
> > > If we tried to do it with spi-buses = <8>; then we would end up with the
> > > "interleaved" bits (or nibbles depending on the wiring) that requires the
> > > extra IP block to sort out when using SPI offloading. Technically, we
> > > could
> > 
> > I think that extra block already exists today. I was thinking the idea was
> > just:
> > 
> > // the case where we just have one channel with eg: 32 bits words (eg: test
> > patterns) 
> > struct spi_transfer example = {
> > 	rx_buf = rx_buf;
> > 	len = 1; /* 1 32bit words */
> 
> This would still need to be len = 4; since there are 4 bytes in a
> 32-bit word. (If this was tx with SPI_MULTI_BUS_MODE_MIRROR, then
> len = 1 would be correct, but for striping, it is still the length
> of all data combined).

Right, I was still thinking in the old stuff where the spi engine would always
have len = 1 (which is nok)

> 
> > 	/* 4 lanes which is actually quadspi */
> > 	multi_bus_mode = SPI_MULTI_BUS_MODE_STRIPE; 
> > };
> 
> This will work with the caveat that for non-offload case, the software 
> will need to rearrange the bits in rx_buf into the correct order after
> the spi_sync().
> 
> For example, u8 *rx_buf will contain bits of the 32-bit word in the
> following order:
> 
> rx_buf[0] = b28 b24 b20 b16 b12 b8 b4 b0
> rx_buf[1] = b29 b25 b21 b17 b13 b9 b5 b1
> rx_buf[2] = b30 b26 b22 b18 b14 b10 b6 b2
> rx_buf[3] = b31 b27 b23 b19 b15 b11 b7 b3
> 
> The correct order of course would be (assuming little endian):
> 
> 
> rx_buf[0] = b7 b6 b5 b4 b3 b2 b1 b0

I know, that's what the ad4030 driver has to do.


- Nuno Sá