On Mon, 10 Dec 2018 11:25:55 +0000
Yogesh Narayan Gaur [off-list ref] wrote:

Hi Boris,

quoted

-----Original Message-----
From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
Sent: Monday, December 10, 2018 4:39 PM
To: Yogesh Narayan Gaur <redacted>
Cc: Schrempf Frieder <redacted>; linux-
mtd@lists.infradead.org; marek.vasut@gmail.com; broonie@kernel.org; linux-
spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org;
mark.rutland@arm.com; shawnguo@kernel.org; linux-arm-
kernel@lists.infradead.org; computersforpeace@gmail.com; linux-
kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller

On Mon, 10 Dec 2018 10:59:54 +0000
Yogesh Narayan Gaur [off-list ref] wrote:
  

quoted

Hi Boris,
 

quoted

-----Original Message-----
From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
Sent: Monday, December 10, 2018 4:20 PM
To: Yogesh Narayan Gaur <redacted>
Cc: Schrempf Frieder <redacted>; linux-
mtd@lists.infradead.org; marek.vasut@gmail.com; broonie@kernel.org;
linux- spi@vger.kernel.org; devicetree@vger.kernel.org;
robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org;
linux-arm- kernel@lists.infradead.org; computersforpeace@gmail.com;
linux- kernel@vger.kernel.org
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 [off-list ref] wrote:
 

quoted

quoted

quoted

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:  

quoted

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.  

quoted

quoted

quoted

Value of memmap_phy_size is 0x10000000 i.e. 256 MB for my
LX2160ARDB  

target.  

quoted

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.  

quoted

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.  

quoted

quoted

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  

quoted

      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.  

quoted

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.  

quoted

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.  

This would going to be performance hit if I would use non-AHB accesses for ->exec_op().

Not if you implement the dirmap hooks.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel