Re: [PATCH v5 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller

[Boris Brezillon <boris.brezillon@xxxxxxxxxxx>]

On Mon, 10 Dec 2018 10:59:54 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@xxxxxxx> wrote:

> Hi Boris,
> 
> > -----Original Message-----
> > From: Boris Brezillon [mailto:boris.brezillon@xxxxxxxxxxx]
> > Sent: Monday, December 10, 2018 4:20 PM
> > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@xxxxxxx>
> > Cc: Schrempf Frieder <frieder.schrempf@xxxxxxxxxx>; linux-
> > mtd@xxxxxxxxxxxxxxxxxxx; marek.vasut@xxxxxxxxx; broonie@xxxxxxxxxx; linux-
> > spi@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; robh@xxxxxxxxxx;
> > mark.rutland@xxxxxxx; shawnguo@xxxxxxxxxx; linux-arm-
> > kernel@xxxxxxxxxxxxxxxxxxx; computersforpeace@xxxxxxxxx; linux-
> > kernel@xxxxxxxxxxxxxxx
> > Subject: Re: [PATCH v5 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
> > 
> > On Mon, 10 Dec 2018 10:43:56 +0000
> > Yogesh Narayan Gaur <yogeshnarayan.gaur@xxxxxxx> wrote:
> >   
> > > > > Thus, in LUT preparation we have assigned only the base address.
> > > > > Now if I have assigned ahb_buf_size to FSPI_FLSHXXCR0 register
> > > > > then for  
> > > > read/write data beyond limit of ahb_buf_size offset I get data corruption.
> > > >
> > > > Why would you do that? We have the ->adjust_op_size() exactly for
> > > > this reason, so, if someone tries to do a spi_mem_op with
> > > > data.nbytes > ahb_buf_size you should return an error.
> > > >  
> > > Let me explain my implementation with example. If I have to write data of size  
> > 0x100 bytes at offset 0x1200 for CS1, I would program as below:  
> > > In func nxp_fspi_select_mem(), would set value of controller address space  
> > size, memmap_phy_size, to FSPI_FLSHA2CR0 and rest all FSPI_FLSHXXCR0 as 0.  
> > > Value of memmap_phy_size is 0x10000000 i.e. 256 MB for my LX2160ARDB  
> > target.  
> > > Then in nxp_fspi_prepare_lut(), I would prepare LUT ADDR with address length  
> > requirement 3/4 byte for NOR or 1/2/3/4 bytes for NAND flash.  
> > > Also for LUT_NXP_WRITE would program data bytes as 0.
> > >
> > > Then inside func nxp_fspi_do_op(), set register FSPI_IPCR0 as the
> > > address offset i.e. 0x1200 and in register FSPI_IPCR1 program the data
> > > size to write i.e. 0x100
> > >
> > > If, as suggested if I tries to mark value of register FSPI_FLSHA2CR0 equal to  
> > ahb_buf_size (0x800), then access for address 0x1200 gives me wrong data. This
> > is because as per the controller specification access to flash connected at CS1
> > can be performed under range of FSPI_ FLSHA1CR0 and FSPI_ FLSHA2CR0.
> > 
> > Don't you have a way to set an offset to apply to the address accessed through
> > the AHB? And if you don't, how will it work if your mapping is smaller than the
> > flash size?  
> 
> Write operations are triggered using IP commands instead of AHB command.
> For Read AHB command is used and in this we are adding the offset when performing memcpy_fromIO operation
>       memcpy_fromio(op->data.buf.in, (f->ahb_addr + op->addr.val), len);
> 
> AHB/IP operations are independent of the way how CS got selected. CS selection depends, e.g. CS1 on the value of register FSPI_FLSHA1CR0 and FSPI_FLSHA2CR0.
> 
> Mapping can never going to be smaller than the connected flash size as per discussion with the Board design team and if it's possible by user manually changes the non-soldered part then flash area beyond complete mapping is not accessible.
> On LX2160ARDB, with mapping of 256MB, for now we are having 4 flash devices connected with size as 64 MB. If user wants he can have only one single flash with flash size of 256MB.

Given that the dirmap interface has now been merged and the MTD side of
things is soon to be merged, I'd recommend you to implement it in your
v6 and only use non-AHB accesses for the ->exec_op() implementation.