RE: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw function

[Chuanhua Han <chuanhua.han@xxxxxxx>]

> -----Original Message-----
> From: Boris Brezillon <boris.brezillon@xxxxxxxxxxx>
> Sent: 2018年10月9日 18:05
> To: Chuanhua Han <chuanhua.han@xxxxxxx>
> Cc: broonie@xxxxxxxxxx; linux-spi@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; eha@xxxxxxxx
> Subject: Re: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw function
> 
> On Tue, 9 Oct 2018 09:52:23 +0000
> Chuanhua Han <chuanhua.han@xxxxxxx> wrote:
> 
> > 1. In the dspi driver (spi controller), bits_per_word
> > (dspi->bits_per_word = transfer->bits_per_word) passed from the upper
> > layer (spi-mem.c) is used. In this way, I can only assign the
> > appropriate value of transfer->bits_per_word before passing to the
> > controller, that is, the controller driver does not know the value of
> > bits_per_word, and it will use this value when the upper level sets
> > what value is passed.
> 
> I think you're missing my point: ->bits_per_word is not what you're looking for
> if what you're trying to do is use 32-bits accesses when things are properly
> aligned.
> 
In the dspi driver (spi controller driver), it is based on whether ->bits_per_word is 
larger than 16 to decide whether to use the XSPI mode (32bit) to transfer data.
If ->bits_per_word is not set and the default bits_per_word =8 is passed to the 
dspi driver, the XSPI mode (32bit) is not used for data transfer in the dspi driver
> > 2. As I understand, bits_per_word does not exist for non-byte
> > alignment, but for the need to reserve non-byte transmission mode that
> > meets the controller.
> 
> Exactly. It's an optimization you have to take care of inside your driver. The core
> cannot help you with that.
> 
The core layer is the upper layer. If you don't set ->bits_per_word, bits_per_word
 will use the default value of 8, so that the controller's specific mode for transferring
 data cannot be used (eg: XSPI mode).
> > 3. In addition, now the
> > XSPI of dspi cannot transfer data normally, so this problem needs to
> > be solved.
> 
> I still don't understand what the problem is.
> 
The problem is that I tested the XSPI mode and could not work, that is, the data could
not be transmitted normally. I used spi flash connected on dspi to conduct the test. 
In any case, the controller is independent of connected slave devices, and the data should
be transmitted by spi-flash devices and other spi devices.

> > As for the DMA transfer mode, some colleagues will study it.