Thread (21 messages) 21 messages, 4 authors, 2018-12-12

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

From: Boris Brezillon <hidden>
Date: 2018-12-10 11:09:39
Also in: linux-devicetree, linux-spi, lkml

On Mon, 10 Dec 2018 10:59:54 +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: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
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.

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help