Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759556AbcJYUAD convert rfc822-to-8bit (ORCPT ); Tue, 25 Oct 2016 16:00:03 -0400 Received: from s159.web-hosting.com ([68.65.120.118]:42595 "EHLO s159.web-hosting.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759345AbcJYUAA (ORCPT ); Tue, 25 Oct 2016 16:00:00 -0400 MIME-Version: 1.0 In-Reply-To: References: <558d668a-69b0-8066-b7da-090517d3161d@atmel.com> <1181d557-c149-8dfd-7fd1-bc83056541cf@atmel.com> From: Jagan Teki Date: Wed, 26 Oct 2016 01:29:52 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/9] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories To: Cyrille Pitchen Cc: Marek Vasut , Brian Norris , "linux-mtd@lists.infradead.org" , nicolas.ferre@atmel.com, boris.brezillon@free-electrons.com, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server159.web-hosting.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - openedev.com X-Get-Message-Sender-Via: server159.web-hosting.com: authenticated_id: jagan@openedev.com X-Authenticated-Sender: server159.web-hosting.com: jagan@openedev.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3559 Lines: 75 Hi Cyrille, On Tue, Oct 25, 2016 at 2:38 PM, Jagan Teki wrote: > On Mon, Oct 24, 2016 at 7:37 PM, Cyrille Pitchen > wrote: >> Le 24/10/2016 à 14:09, Cyrille Pitchen a écrit : >>> Hi Jagan, >>> >>> Le 24/10/2016 à 09:41, Jagan Teki a écrit : >>>> On Sun, Oct 23, 2016 at 2:03 AM, Marek Vasut wrote: >>>>> On 10/22/2016 01:00 PM, Jagan Teki wrote: >>>>>> On Wed, Oct 5, 2016 at 5:30 PM, Cyrille Pitchen >>>>>> wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> This series extends support of SPI protocols to new protocols such as >>>>>>> SPI x-2-2 and SPI x-4-4. Also spi_nor_scan() tries now to select the right >>>>>>> op codes, timing parameters (number of mode and dummy cycles) and erase >>>>>>> sector size by parsing the Serial Flash Discoverable Parameter (SFDP) >>>>>>> tables, when available, as defined in the JEDEC JESD216 specifications. >>>>>>> >>>>>>> When SFDP tables are not available, legacy settings are still used for >>>>>>> backward compatibility (SPI and earlier QSPI memories). >>>>>>> >>>>>>> Support of SPI memories >128Mbits is also improved by using the 4byte >>>>>>> address instruction set, when available. Using those dedicated op codes >>>>>>> is stateless as opposed to enter the 4byte address mode, hence a better >>>>>>> compatibility with some boot loaders which expect to use 3byte address >>>>>>> op codes. >>>>>> >>>>>> The memories which are > 128Mbits should have 4-bytes addressing >>>>>> support based on my experience, do you think BAR is also required >>>>>> atleast from spi-nor side? >>>>> >>>>> Yes, I believe BAR is still required for broken/dumb flash chips. >>>>> Not all chips > 16 MiB support dedicated 4-byte addressing opcodes :-( >>>> >>>> Do you have list for those broken chips? because I never find any >>>> chips which has > 16 MiB with not support of 4-byte address opcodes >>>> and I've seen the controller has dependable with BAR though it can >>>> access > 16MiB ex: zynq qspi/ >>>> >>>> thanks! >>>> >>> >>> Let's take the case of Micron n25q256* memories. Depending of the part number, >>> the 12h op code is associated with either 4-byte address Page Program 1-1-1 >>> or 3-byte address Page Program 1-4-4. >>> Then considering parts where the 12h op code is used for 3-byte address Page >>> Program 1-4-4, there is no op code for a 4-byte address Page Program 1-1-1. >>> >>> Note 15, extracted from the Micron n25q_256mb_3v_65nm.pdf datasheet, about >>> the 3-byte address Page Program 1-4-4 (Extended Quad Input Fast Program): >>> The code 38h is valid only for part numbers N25Q256A83ESF40x, N25Q256A83E1240x >>> and N25Q256A83ESFA0F; the code 12h is valid for the other part numbers. I am trying to understand the conflict more clearly with an example of Micron, so on Table 18 from Micron n25q_256mb_3v_65nm.pdf datasheet, Page program 3-byte has 02h and Quad page program 3-byte has 32h but for 4-byte addressing only quad page program (no support of page program) can be either 02h/32h/12h and indeed these can change based on the n25q256* parts so why can't we rely on Quad page program for 4-byte addressing? and so there is no necessity for BAR here. And also other than the un-supported-controller can't we rely directly on supported page program opcodes for 4-byte addressing? say if it is supporting QPP on 4-byte then use it as it is and no need to take care of PP here. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India.