Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3565270imu; Mon, 10 Dec 2018 04:26:51 -0800 (PST) X-Google-Smtp-Source: AFSGD/UA5crTRGw18JoIhTO1o44wf1WhUmH/6+tIdXf2IbGz4qHbBYPfU3J13mr/xWqczy1Fy8dk X-Received: by 2002:a62:1447:: with SMTP id 68mr12001923pfu.257.1544444811474; Mon, 10 Dec 2018 04:26:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544444811; cv=none; d=google.com; s=arc-20160816; b=l9boC2wjkVf0U05wSslgRoBm49xt+n72Yq25HToGkMzXzfTAhpJXqhy02K51TDElMd +78jHxHoCkFZ8rDHND9YV+sAHNsCxCCcgBRNqROwWRdxrNnceuOKOOg/rpfw4ZYgSzOo OQL9atHyUnpcRKXScVft+HilkYVu+HbP0E7mXtfd9+5MFStT6tCllMLEFQJ7Z89Gsbqj ImXsvbhX0xkT8pMznuelEI5g/TS5ZPJ/Z0lBF3+4Ag15IA3nw/A/l13i44+v6/GnFrSx Q05yDbGwBFJV4rlqQmP0pkN49lessBVAUZB+gYQfSW2Uzwl1fiaiuyiyrUTGsZhtNuXM Jw7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=LSJoHkI/9P9V9RkQWXtJYVR4j0lCvledbM0C3VcgDjM=; b=ZajBGR39fNYVcyZ8HkT8SJL4x5Tp+qMcOQFbEC2q+IVbdGjprZP5YwBkRlsfxHbgwT SQnIh9P8eMe9xx3aJtL0oHvJDuK4F1wjI6BA177PgUtT+haLl5YqQ6z7bPU7w7GPAIz/ zMScmXZpyUaH5c/3cSuamlPS0bBfAOYWbS6EwhXP2A2TPqO99XR0qPXGcZAIiW8tr8Kp jONL0Zvf9zFPyafhjrCLiPceu3iWV9elkF+8O0F8vICy/Seq5Xoo/8jrJYSd8xKjiCve 789Hh6wEvTra2Upsd/1trzpHH1R64VWKys6dVSmcI7bpsp16QSUAMTc6Y3jtYLUFecGT hL1g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b26si9482570pgl.539.2018.12.10.04.26.35; Mon, 10 Dec 2018 04:26:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727324AbeLJLJi (ORCPT + 99 others); Mon, 10 Dec 2018 06:09:38 -0500 Received: from mail.bootlin.com ([62.4.15.54]:56795 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726716AbeLJLJi (ORCPT ); Mon, 10 Dec 2018 06:09:38 -0500 Received: by mail.bootlin.com (Postfix, from userid 110) id D882920D23; Mon, 10 Dec 2018 12:09:35 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.2 Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 8057C20CE3; Mon, 10 Dec 2018 12:09:25 +0100 (CET) Date: Mon, 10 Dec 2018 12:09:25 +0100 From: Boris Brezillon To: Yogesh Narayan Gaur Cc: Schrempf Frieder , "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 Message-ID: <20181210120925.3c6336f6@bbrezillon> In-Reply-To: References: <1542366701-16065-1-git-send-email-yogeshnarayan.gaur@nxp.com> <1542366701-16065-2-git-send-email-yogeshnarayan.gaur@nxp.com> <20181210111909.35384eee@bbrezillon> <20181210115001.6c7af1d7@bbrezillon> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 10 Dec 2018 10:59:54 +0000 Yogesh Narayan Gaur wrote: > Hi Boris, > > > -----Original Message----- > > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] > > Sent: Monday, December 10, 2018 4:20 PM > > To: Yogesh Narayan Gaur > > Cc: Schrempf Frieder ; 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 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.