[{"id":1783337,"web_url":"http://patchwork.ozlabs.org/comment/1783337/","msgid":"","list_archive_url":null,"date":"2017-10-10T00:49:54","subject":"Re: [PATCH v2 0/3] Altera ASMI Parallel II IP Core","submitter":{"id":70992,"url":"http://patchwork.ozlabs.org/api/people/70992/","name":"Matthew Gerlach","email":"matthew.gerlach@linux.intel.com"},"content":"Hi Everyone,\n\nThanks to Rob Herring for Acking the device tree bindings part of the \npatch. Does anyone have any feedback for the rest of the patch set?\n\nThanks,\n\nMatthew Gerlach\n\nOn Wed, 20 Sep 2017, matthew.gerlach@linux.intel.com wrote:\n\n> From: Matthew Gerlach \n>\n> This patch set adds a spi-nor flash driver for the Altera ASMI Parallel II\n> IP Core. This driver was created based on feedback from Marek Vasut,\n> Cyrill Pitchen, and Michal Suchanek regarding Version 2 of the Altera\n> Quadspi Controller: https://lkml.org/lkml/2017/6/26/518\n>\n> The overall problem with Version 2 of the Altera Quadspi Controller and\n> its driver was the fact that there was much duplication of code and logic\n> with the spi-nor framework. This new combination of fpga hardware and\n> software \"gets out of the way\" of the spi-nor framework. The result is a\n> much simpler driver with the spi-nor framework performing the bulk of the work.\n>\n> Patch 1 contains the device tree bindings for the driver for\n> the Altera ASMI-Parallel II IP Core.\n>\n> Patch 2 contains the driver code for the Altera ASMI-Parallel II IP Core.\n> This driver supports being configured via a device tree or with platform\n> data. In the later case, the memory for the registers has been remapped.\n>\n> Patch 3 contains a work around for some non-standard behavior of EPCQ flash.\n>\n> Matthew Gerlach (3):\n> dt-bindings: mtd: Altera ASMI Parallel II IP Core\n> mtd: spi-nor: Altera ASMI Parallel II IP Core\n> mtd: spi-nor: add flag for reading dummy cycles from nv cfg reg\n>\n> .../devicetree/bindings/mtd/altera-asmip2.txt | 15 +\n> MAINTAINERS | 7 +\n> drivers/mtd/spi-nor/Kconfig | 6 +\n> drivers/mtd/spi-nor/Makefile | 1 +\n> drivers/mtd/spi-nor/altera-asmip2.c | 478 +++++++++++++++++++++\n> include/linux/mtd/altera-asmip2.h | 27 ++\n> 6 files changed, 534 insertions(+)\n> create mode 100644 Documentation/devicetree/bindings/mtd/altera-asmip2.txt\n> create mode 100644 drivers/mtd/spi-nor/altera-asmip2.c\n> create mode 100644 include/linux/mtd/altera-asmip2.h\n>\n> -- \n> 2.7.4\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe linux-fpga\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y9z6J5THVz9t3B\n\tfor ;\n\tTue, 10 Oct 2017 11:50:00 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755488AbdJJAt6 (ORCPT\n\t);\n\tMon, 9 Oct 2017 20:49:58 -0400","from mga04.intel.com ([192.55.52.120]:63692 \"EHLO mga04.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1755461AbdJJAt6 (ORCPT );\n\tMon, 9 Oct 2017 20:49:58 -0400","from fmsmga002.fm.intel.com ([10.253.24.26])\n\tby fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t09 Oct 2017 17:49:57 -0700","from kcanfiel-mobl1.amr.corp.intel.com (HELO [10.0.2.15])\n\t([10.254.75.6])\n\tby fmsmga002.fm.intel.com with ESMTP; 09 Oct 2017 17:49:55 -0700"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos; i=\"5.42,502,1500966000\"; d=\"scan'208\";\n\ta=\"1228962911\"","Date":"Mon, 9 Oct 2017 17:49:54 -0700 (PDT)","From":"matthew.gerlach@linux.intel.com","X-X-Sender":"mgerlach@mgerlach-VirtualBox","To":"vndao@altera.com, dwmw2@infradead.org, computersforpeace@gmail.com,\n\tboris.brezillon@free-electrons.com, marek.vasut@gmail.com,\n\trichard@nod.at, cyrille.pitchen@wedev4u.fr, robh+dt@kernel.org,\n\tmark.rutland@arm.com, linux-mtd@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tgregkh@linuxfoundation.org, davem@davemloft.net,\n\tmchehab@kernel.org, linux-fpga@vger.kernel.org,\n\ttien.hock.loh@intel.com, hean.loong.ong@intel.com","Subject":"Re: [PATCH v2 0/3] Altera ASMI Parallel II IP Core","In-Reply-To":"<1505932139-2905-1-git-send-email-matthew.gerlach@linux.intel.com>","Message-ID":"","References":"<1505932139-2905-1-git-send-email-matthew.gerlach@linux.intel.com>","User-Agent":"Alpine 2.20 (DEB 67 2015-01-07)","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII; format=flowed","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1783542,"web_url":"http://patchwork.ozlabs.org/comment/1783542/","msgid":"","list_archive_url":null,"date":"2017-10-10T09:24:03","subject":"Re: [PATCH v2 2/3] mtd: spi-nor: Altera ASMI Parallel II IP Core","submitter":{"id":1124,"url":"http://patchwork.ozlabs.org/api/people/1124/","name":"Marek Vasut","email":"marek.vasut@gmail.com"},"content":"On 09/20/2017 08:28 PM, matthew.gerlach@linux.intel.com wrote:\n> From: Matthew Gerlach \n> \n> This patch adds support for a spi-nor, platform driver for the\n> Altera ASMI Parallel II IP Core. The intended use case is to be able\n> to update the flash used to load a FPGA at power up with mtd-utils.\n> \n> Signed-off-by: Matthew Gerlach \n> ---\n> v2:\n> minor checkpatch fixing by Wu Hao \n> Use read_dummy value as suggested by Cyrille Pitchen.\n> Don't assume 4 byte addressing (Cryille Pichecn and Marek Vasut).\n> Fixed #define indenting as suggested by Marek Vasut.\n> Added units to timer values as suggested by Marek Vasut.\n> Use io(read|write)8_rep() as suggested by Marek Vasut.\n> Renamed function prefixed with __ as suggested by Marek Vasut.\n\n[...]\n\n> +#define QSPI_ACTION_REG\t\t\t0\n> +#define QSPI_ACTION_RST\t\t\tBIT(0)\n> +#define QSPI_ACTION_EN\t\t\tBIT(1)\n> +#define QSPI_ACTION_SC\t\t\tBIT(2)\n> +#define QSPI_ACTION_CHIP_SEL_SFT\t4\n> +#define QSPI_ACTION_DUMMY_SFT\t\t8\n> +#define QSPI_ACTION_READ_BACK_SFT\t16\n> +\n> +#define QSPI_FIFO_CNT_REG\t\t4\n> +#define QSPI_FIFO_DEPTH\t\t\t0x200\n> +#define QSPI_FIFO_CNT_MSK\t\t0x3ff\n> +#define QSPI_FIFO_CNT_RX_SFT\t\t0\n> +#define QSPI_FIFO_CNT_TX_SFT\t\t12\n> +\n> +#define QSPI_DATA_REG\t\t\t0x8\n> +\n> +#define QSPI_POLL_TIMEOUT_US\t\t10000000\n\n10 s poll timeout ? :)\n\n> +#define QSPI_POLL_INTERVAL_US\t\t5\n> +\n> +struct altera_asmip2 {\n\n[...]\n\nOtherwise looks good","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"TgUi3cso\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yBBWc5dKSz9t6Y\n\tfor ;\n\tTue, 10 Oct 2017 20:24:12 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1755298AbdJJJYL (ORCPT\n\t);\n\tTue, 10 Oct 2017 05:24:11 -0400","from mail-wm0-f68.google.com ([74.125.82.68]:56966 \"EHLO\n\tmail-wm0-f68.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751420AbdJJJYJ (ORCPT\n\t); Tue, 10 Oct 2017 05:24:09 -0400","by mail-wm0-f68.google.com with SMTP id l68so3301269wmd.5;\n\tTue, 10 Oct 2017 02:24:08 -0700 (PDT)","from [192.168.1.4] (ip-86-49-107-50.net.upcbroadband.cz.\n\t[86.49.107.50]) by smtp.gmail.com with ESMTPSA id\n\to14sm4011376wra.54.2017.10.10.02.24.06\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 10 Oct 2017 02:24:07 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:from:message-id:date:user-agent:mime-version\n\t:in-reply-to:content-language:content-transfer-encoding;\n\tbh=W9YIIPl6KTlBnHVLDXkLjcOtDBp3GD7RvcimrguVdF4=;\n\tb=TgUi3csooIFvsNieh30jBBJOmStaoUML74qV4TAZtxldJHvbxXjRUMs36U4+ifF2Cg\n\tLay7OuEzulVCH6zI42IKwzQuYedD2beOyKXU8PYIi6sAKLWUklf4sWK7KIWFgk9x1NoE\n\tIw2p+NX0AHYhN+uhTfZhmZa3D2tJI74G+ihHp+eUtNK8oB8EPBMRzaV5cH2NMJ2IdDpj\n\tY1MtXecSmjISSsUBpeouaoYsN6aoKUf+bT5oBWZy24y0UBvIO4Rew+x3SzPgFdfhLc57\n\tir3/XoV+Y4eo1nOTEme8nY68oBmpK+NNZ3HUwqoDi2YEKsqldr/yP4enelXkvAMtrmvp\n\tnSWQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=W9YIIPl6KTlBnHVLDXkLjcOtDBp3GD7RvcimrguVdF4=;\n\tb=UJ2uzq0v3+llG5/9nrZBDfydZ0odHhTXEwOWJvxxo4Avpl1q1Hw/30CqKLYHL7xb9j\n\tVpjqEWfcBDdx7Iu80ykWrWhHhcv0CORIWYSe5ASCU7DgB9VkqhAt4nNDEYONqUe7qn++\n\t1il2vmxfER8dY1SzwjsFUS5mg1UwRisUh+zA6vm20qyJ5SrV/7ytXv2pIsLJ2kCS8wrO\n\twcHIQm5R5r0/+0qxd7+5S+wQzkkqJq3bllalbtVBrsNwAx1n+26NxgsdiqGRbyN0tLmp\n\t6shsQ7L03lXdkOF6nWt2ZCWBYG2S7ej0hMeFgN6+gDV6OiqfiuEDQkZZnPjzHqCBXlDm\n\tO8Hw==","X-Gm-Message-State":"AMCzsaXB7or+pmW1cTZU5zxfO+olcFfr/O52QjSb+XlYyXqG61kTtWnZ\n\tXaHnFINM2QgkyvBEyN7Wiiw=","X-Google-Smtp-Source":"AOwi7QBBxC6mZBsg0XNpCYdq6V6O20SRFyNt85zegxBx5WG8gE2/Hcd/HsgYjdOGunxFmGsmn4efAw==","X-Received":"by 10.28.150.195 with SMTP id y186mr11091338wmd.52.1507627448143;\n\tTue, 10 Oct 2017 02:24:08 -0700 (PDT)","Subject":"Re: [PATCH v2 2/3] mtd: spi-nor: Altera ASMI Parallel II IP Core","To":"matthew.gerlach@linux.intel.com, vndao@altera.com,\n\tdwmw2@infradead.org, computersforpeace@gmail.com,\n\tboris.brezillon@free-electrons.com, richard@nod.at,\n\tcyrille.pitchen@wedev4u.fr, robh+dt@kernel.org,\n\tmark.rutland@arm.com, linux-mtd@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tgregkh@linuxfoundation.org, davem@davemloft.net,\n\tmchehab@kernel.org, linux-fpga@vger.kernel.org,\n\ttien.hock.loh@intel.com, hean.loong.ong@intel.com","References":"<1505932139-2905-1-git-send-email-matthew.gerlach@linux.intel.com>\n\t<1505932139-2905-3-git-send-email-matthew.gerlach@linux.intel.com>","From":"Marek Vasut ","Message-ID":"","Date":"Tue, 10 Oct 2017 11:24:03 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<1505932139-2905-3-git-send-email-matthew.gerlach@linux.intel.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1784063,"web_url":"http://patchwork.ozlabs.org/comment/1784063/","msgid":"<28c32a9c-1fd8-3af4-abc6-f4938e138daa@wedev4u.fr>","list_archive_url":null,"date":"2017-10-10T19:23:25","subject":"Re: [PATCH v2 3/3] mtd: spi-nor: add flag for reading dummy cycles\n\tfrom nv cfg reg","submitter":{"id":70551,"url":"http://patchwork.ozlabs.org/api/people/70551/","name":"Cyrille Pitchen","email":"cyrille.pitchen@wedev4u.fr"},"content":"Hi Matthew\n\nNAK for this patch\n\nLe 20/09/2017 à 20:28, matthew.gerlach@linux.intel.com a écrit :\n> From: Matthew Gerlach \n> \n> This patch is a work around for some non-standard behavior\n> of EPCQ flash parts:\n> \n> https://www.altera.com/documentation/wtw1396921531042.html#wtw1396921651224\n>\n\n>From the above documentation:\n\"\"\"\nWrite Non-Volatile Configuration Register Operation\n\nYou need to write the non-volatile configuration registers for EPCQ-L\ndevices for different configuration schemes. If you are using the .jic\nfile, the Quartus® Prime programmer sets the number of dummy clock\ncycles and address bytes. If you are using an external programmer tools\n(3rd party programmer tools), you must set the non-volatile\nconfiguration registers.\n\nTo set the non-volatile configuration register, follow these steps:\n\n Execute the write enable operation.\n Execute the write non-volatile configuration register operation.\n Set the 16-bit register value.\n\nSet the 16-bit register value as b'1110 1110 xxxx 1111 where xxxx is the\ndummy clock value. When the xxxx value is from 0001 to 1110, the dummy\nclock value is from 1 to 14. When xxxx is 0000 or 1111, the dummy clock\nvalue is at the default value, which is 8 for standard fast read (AS x1)\nmode and 10 for extended quad input fast read (AS x4) mode.\n\"\"\"\n\nAFAIU, it is stated that you can set the number of dummy cycle to either\n0000b or 1111b, the default value. There is no valid reason to use any\nother value, like there is no valid reason to tune the number of dummy\nclock cycles. Just keep the default settings, please!\n\nIf we start to play changing the number of dummy cycles it would be real\nmess to maintain.\n\nFirst, should we read the value to be used from some register or should\nwe force this value instead by writing that register ?\nSome would prefer reading whereas other would prefer updating...\n\nMoreover, the method to read or write the number of dummy cycles is not\nstandard and is manufacturer specific:\n\n- Micron uses 2 registers: the Volatile Configuration Register and the\nNon-Volatile configuration Register.\n\n- Macronix uses another register but doesn't store the number of dummy\ncycles directly: instead this manufacturer uses codes. So we would have\nto store tables mapping codes <-> number dummy clock cycles\n\n- Spansion/Cypress also uses code tables and I already know that\ndepending on the memory part number the code is either 2bit or 4bit and\nstored in different registers. Damned!\n\nIf I allow you to tune the number of dummy clock cycles for Micron\nmemory it would be fair that I allow other people to tune this number\nfor other memory manufacturers. However it would be a real pain to\nmaintain because there is no standard for that hence manufacturers just\ndo what they want and change things when they want. Far too\nunpredictable, IMHO.\n\nSo to avoid a messy situation, the rule is simple: SPI-NOR memory MUST\nbe configured in their default factory settings when spi_nor_scan() is\ncalled. Your memory has the very same JEDEC ID as some Micron memory,\nthen it should behave the exact same way: in this case the value for the\nnumber of dummy clock cycles should be set to 0000b or 1111b in the NVCR\n(and VCR too).\n\n\n> These flash parts are generally used to configure Intel/Altera FPGAs\n> on power up. These parts report a JEDEC id of the Micron part at the core,\n> but have a different number of dummy cycles than specified in the Micron\n> data sheet. The number of required dummy cycles can be read from the\n> Non-Volatile Configuration register.\n> \n> Signed-off-by: Matthew Gerlach \n> ---\n> drivers/mtd/spi-nor/altera-asmip2.c | 31 ++++++++++++++++++++++++++-----\n> include/linux/mtd/altera-asmip2.h | 3 +++\n> 2 files changed, 29 insertions(+), 5 deletions(-)\n> \n> diff --git a/drivers/mtd/spi-nor/altera-asmip2.c b/drivers/mtd/spi-nor/altera-asmip2.c\n> index a977765..d9cd807 100644\n> --- a/drivers/mtd/spi-nor/altera-asmip2.c\n> +++ b/drivers/mtd/spi-nor/altera-asmip2.c\n> @@ -40,6 +40,10 @@\n> #define QSPI_POLL_TIMEOUT_US\t\t10000000\n> #define QSPI_POLL_INTERVAL_US\t\t5\n> \n> +#define SPINOR_OP_RD_NVCFG\t\t0xb5\n> +#define NVCFG_DUMMY_SFT\t\t\t12\n> +#define NVCFG_DUMMY_MASK\t\t0xf\n> +\n> struct altera_asmip2 {\n> \tvoid __iomem *csr_base;\n> \tu32 num_flashes;\n> @@ -231,7 +235,8 @@ static void altera_asmip2_unprep(struct spi_nor *nor, enum spi_nor_ops ops)\n> }\n> \n> static int altera_asmip2_setup_banks(struct device *dev,\n> -\t\t\t\t u32 bank, struct device_node *np)\n> +\t\t\t\t u32 bank, struct device_node *np,\n> +\t\t\t\t u32 flags)\n> {\n> \tconst struct spi_nor_hwcaps hwcaps = {\n> \t\t.mask = SNOR_HWCAPS_READ |\n> @@ -241,6 +246,7 @@ static int altera_asmip2_setup_banks(struct device *dev,\n> \tstruct altera_asmip2 *q = dev_get_drvdata(dev);\n> \tstruct altera_asmip2_flash *flash;\n> \tstruct spi_nor *nor;\n> +\tu16 nvcfg;\n> \tint ret = 0;\n> \n> \tif (bank > q->num_flashes - 1)\n> @@ -273,6 +279,20 @@ static int altera_asmip2_setup_banks(struct device *dev,\n> \t\treturn ret;\n> \t}\n> \n> +\tif (flags & ALTERA_ASMIP2_FLASH_FLG_RD_NVCFG) {\n> +\t\tret = altera_asmip2_read_reg(nor, SPINOR_OP_RD_NVCFG,\n> +\t\t \t\t\t (u8*)&nvcfg, sizeof(nvcfg));\n> +\n> +\t\tif (ret) {\n> +\t\t\tdev_err(nor->dev,\n> +\t\t\t\t\"failed to read NV Configuration register\\n\");\n> +\t\t\treturn ret;\n> +\t\t}\n> +\n> +\t\tnor->read_dummy = (nvcfg >> NVCFG_DUMMY_SFT) & NVCFG_DUMMY_MASK;\n> +\t\tdev_info(nor->dev, \"%s dummy %d\\n\", __func__, nor->read_dummy);\n> +\t}\n> +\n\nYou have forgotten the special case for values 0000b and 1111b (default\nsettings). For those 2 values, the actual number of dummy clock cycles is:\n- 0 for Read (03h/13h)\n- 8 for Fast Read 1-1-1 (0Bh/0Ch)\n- 8 for Fast Read 1-1-2 (3Bh/3Ch)\n- 8 for Fast Read 1-2-2 (BBh/BCh)\n- 8 for Fast Read 1-1-4 (6Bh/6Ch)\n- 10 for Fast Read 1-4-4 (EBh/ECh)\n\nBesides, the value read from the Non-Volatile Configuration Register is\nthe value loaded into the Volatile Configuration Register at power-up.\nThe actual number of dummy clock cycles to be used by Fast Read commands\nshould be read from the Volatile Configuration Register.\n\nAnyway, this not the way to go.\n\nBest regards,\n\nCyrille\n\n> \tret = mtd_device_register(&nor->mtd, NULL, 0);\n> \n> \treturn ret;\n> @@ -308,7 +328,7 @@ static int altera_asmip2_create(struct device *dev, void __iomem *csr_base)\n> }\n> \n> static int altera_asmip2_add_bank(struct device *dev,\n> -\t\t\t u32 bank, struct device_node *np)\n> +\t\t\t u32 bank, struct device_node *np, u32 flags)\n> {\n> \tstruct altera_asmip2 *q = dev_get_drvdata(dev);\n> \n> @@ -317,7 +337,7 @@ static int altera_asmip2_add_bank(struct device *dev,\n> \n> \tq->num_flashes++;\n> \n> -\treturn altera_asmip2_setup_banks(dev, bank, np);\n> +\treturn altera_asmip2_setup_banks(dev, bank, np, flags);\n> }\n> \n> static int altera_asmip2_remove_banks(struct device *dev)\n> @@ -361,7 +381,8 @@ static int altera_asmip2_probe_with_pdata(struct platform_device *pdev,\n> \t}\n> \n> \tfor (i = 0; i < qdata->num_chip_sel; i++) {\n> -\t\tret = altera_asmip2_add_bank(dev, i, NULL);\n> +\t\tret = altera_asmip2_add_bank(dev, i, NULL,\n> +\t\t\t\t\t qdata->flash_flags[i]);\n> \t\tif (ret) {\n> \t\t\tdev_err(dev, \"failed to add qspi bank %d\\n\", ret);\n> \t\t\tbreak;\n> @@ -414,7 +435,7 @@ static int altera_asmip2_probe(struct platform_device *pdev)\n> \t\t\tgoto error;\n> \t\t}\n> \n> -\t\tif (altera_asmip2_add_bank(dev, bank, pp)) {\n> +\t\tif (altera_asmip2_add_bank(dev, bank, pp, 0)) {\n> \t\t\tdev_err(dev, \"failed to add bank %u\\n\", bank);\n> \t\t\tgoto error;\n> \t\t}\n> diff --git a/include/linux/mtd/altera-asmip2.h b/include/linux/mtd/altera-asmip2.h\n> index 580c43c..185a9b2 100644\n> --- a/include/linux/mtd/altera-asmip2.h\n> +++ b/include/linux/mtd/altera-asmip2.h\n> @@ -16,9 +16,12 @@\n> #define ALTERA_ASMIP2_MAX_NUM_FLASH_CHIP 3\n> #define ALTERA_ASMIP2_RESOURCE_SIZE 0x10\n> \n> +#define ALTERA_ASMIP2_FLASH_FLG_RD_NVCFG\tBIT(0)\n> +\n> struct altera_asmip2_plat_data {\n> \tvoid __iomem *csr_base;\n> \tu32 num_chip_sel;\n> +\tu32 flash_flags[ALTERA_ASMIP2_MAX_NUM_FLASH_CHIP];\n> };\n> \n> #endif\n> \n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yBRq95sRzz9t6M\n\tfor ;\n\tWed, 11 Oct 2017 06:23:33 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751544AbdJJTXb (ORCPT\n\t);\n\tTue, 10 Oct 2017 15:23:31 -0400","from smtp3-g21.free.fr ([212.27.42.3]:17450 \"EHLO\n\tsmtp3-g21.free.fr\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751156AbdJJTXa (ORCPT );\n\tTue, 10 Oct 2017 15:23:30 -0400","from mountainer.wedev4u.int (unknown [82.232.94.13])\n\tby smtp3-g21.free.fr (Postfix) with ESMTP id BCD9F13F89D;\n\tTue, 10 Oct 2017 21:23:25 +0200 (CEST)"],"Subject":"Re: [PATCH v2 3/3] mtd: spi-nor: add flag for reading dummy cycles\n\tfrom nv cfg reg","To":"matthew.gerlach@linux.intel.com, vndao@altera.com,\n\tdwmw2@infradead.org, computersforpeace@gmail.com,\n\tboris.brezillon@free-electrons.com, marek.vasut@gmail.com,\n\trichard@nod.at, robh+dt@kernel.org, mark.rutland@arm.com,\n\tlinux-mtd@lists.infradead.org, devicetree@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,\n\tdavem@davemloft.net, mchehab@kernel.org,\n\tlinux-fpga@vger.kernel.org, tien.hock.loh@intel.com,\n\thean.loong.ong@intel.com","References":"<1505932139-2905-1-git-send-email-matthew.gerlach@linux.intel.com>\n\t<1505932139-2905-4-git-send-email-matthew.gerlach@linux.intel.com>","From":"Cyrille Pitchen ","Message-ID":"<28c32a9c-1fd8-3af4-abc6-f4938e138daa@wedev4u.fr>","Date":"Tue, 10 Oct 2017 21:23:25 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<1505932139-2905-4-git-send-email-matthew.gerlach@linux.intel.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1784820,"web_url":"http://patchwork.ozlabs.org/comment/1784820/","msgid":"","list_archive_url":null,"date":"2017-10-11T17:00:37","subject":"Re: [PATCH v2 2/3] mtd: spi-nor: Altera ASMI Parallel II IP Core","submitter":{"id":70992,"url":"http://patchwork.ozlabs.org/api/people/70992/","name":"Matthew Gerlach","email":"matthew.gerlach@linux.intel.com"},"content":"On Tue, 10 Oct 2017, Marek Vasut wrote:\n\n> On 09/20/2017 08:28 PM, matthew.gerlach@linux.intel.com wrote:\n>> From: Matthew Gerlach \n>>\n>> This patch adds support for a spi-nor, platform driver for the\n>> Altera ASMI Parallel II IP Core. The intended use case is to be able\n>> to update the flash used to load a FPGA at power up with mtd-utils.\n>>\n>> Signed-off-by: Matthew Gerlach \n>> ---\n>> v2:\n>> minor checkpatch fixing by Wu Hao \n>> Use read_dummy value as suggested by Cyrille Pitchen.\n>> Don't assume 4 byte addressing (Cryille Pichecn and Marek Vasut).\n>> Fixed #define indenting as suggested by Marek Vasut.\n>> Added units to timer values as suggested by Marek Vasut.\n>> Use io(read|write)8_rep() as suggested by Marek Vasut.\n>> Renamed function prefixed with __ as suggested by Marek Vasut.\n>\n> [...]\n>\n>> +#define QSPI_ACTION_REG\t\t\t0\n>> +#define QSPI_ACTION_RST\t\t\tBIT(0)\n>> +#define QSPI_ACTION_EN\t\t\tBIT(1)\n>> +#define QSPI_ACTION_SC\t\t\tBIT(2)\n>> +#define QSPI_ACTION_CHIP_SEL_SFT\t4\n>> +#define QSPI_ACTION_DUMMY_SFT\t\t8\n>> +#define QSPI_ACTION_READ_BACK_SFT\t16\n>> +\n>> +#define QSPI_FIFO_CNT_REG\t\t4\n>> +#define QSPI_FIFO_DEPTH\t\t\t0x200\n>> +#define QSPI_FIFO_CNT_MSK\t\t0x3ff\n>> +#define QSPI_FIFO_CNT_RX_SFT\t\t0\n>> +#define QSPI_FIFO_CNT_TX_SFT\t\t12\n>> +\n>> +#define QSPI_DATA_REG\t\t\t0x8\n>> +\n>> +#define QSPI_POLL_TIMEOUT_US\t\t10000000\n>\n> 10 s poll timeout ? :)\n\nHi Marek,\n\nThe 10s timeout is fairly arbitrary. In other words, I pulled it out of \nthin air. Can you suggest a better timeout? From a practical standpoint 10s \nseemed to be much better than no timeout when I was debugging bad FPGA \nimages. Without a timeout I was hanging the system when the FPGA image \nfailed. With this timeout, we get a nice message and Linux keeps running \nhappily.\n\nThanks for the feedback,\n\nMatthew Gerlach\n\n>\n>> +#define QSPI_POLL_INTERVAL_US\t\t 5 >> + >> +struct \naltera_asmip2 { >\n> [...]\n>\n> Otherwise looks good\n>\n> -- \n> Best regards,\n> Marek Vasut\n>\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yC0cc1NZzz9sBZ\n\tfor ;\n\tThu, 12 Oct 2017 04:01:20 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752529AbdJKRBH (ORCPT\n\t);\n\tWed, 11 Oct 2017 13:01:07 -0400","from mga07.intel.com ([134.134.136.100]:41438 \"EHLO\n\tmga07.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752246AbdJKRA6 (ORCPT );\n\tWed, 11 Oct 2017 13:00:58 -0400","from orsmga004.jf.intel.com ([10.7.209.38])\n\tby orsmga105.jf.intel.com with ESMTP; 11 Oct 2017 10:00:41 -0700","from mgerlach-mobl.amr.corp.intel.com (HELO [10.0.2.15])\n\t([10.254.126.215])\n\tby orsmga004.jf.intel.com with ESMTP; 11 Oct 2017 10:00:39 -0700"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.43,362,1503385200\"; d=\"scan'208\";a=\"137512805\"","Date":"Wed, 11 Oct 2017 10:00:37 -0700 (PDT)","From":"matthew.gerlach@linux.intel.com","X-X-Sender":"mgerlach@mgerlach-VirtualBox","To":"Marek Vasut ","cc":"vndao@altera.com, dwmw2@infradead.org, computersforpeace@gmail.com,\n\tboris.brezillon@free-electrons.com, richard@nod.at,\n\tcyrille.pitchen@wedev4u.fr, robh+dt@kernel.org,\n\tmark.rutland@arm.com, linux-mtd@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tgregkh@linuxfoundation.org, davem@davemloft.net,\n\tmchehab@kernel.org, linux-fpga@vger.kernel.org,\n\ttien.hock.loh@intel.com, hean.loong.ong@intel.com","Subject":"Re: [PATCH v2 2/3] mtd: spi-nor: Altera ASMI Parallel II IP Core","In-Reply-To":"","Message-ID":"","References":"<1505932139-2905-1-git-send-email-matthew.gerlach@linux.intel.com>\n\t<1505932139-2905-3-git-send-email-matthew.gerlach@linux.intel.com>\n\t","User-Agent":"Alpine 2.20 (DEB 67 2015-01-07)","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII; format=flowed","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1784970,"web_url":"http://patchwork.ozlabs.org/comment/1784970/","msgid":"","list_archive_url":null,"date":"2017-10-11T21:06:02","subject":"Re: [PATCH v2 2/3] mtd: spi-nor: Altera ASMI Parallel II IP Core","submitter":{"id":1124,"url":"http://patchwork.ozlabs.org/api/people/1124/","name":"Marek Vasut","email":"marek.vasut@gmail.com"},"content":"On 10/11/2017 07:00 PM, matthew.gerlach@linux.intel.com wrote:\n> \n> \n> On Tue, 10 Oct 2017, Marek Vasut wrote:\n> \n>> On 09/20/2017 08:28 PM, matthew.gerlach@linux.intel.com wrote:\n>>> From: Matthew Gerlach \n>>>\n>>> This patch adds support for a spi-nor, platform driver for the\n>>> Altera ASMI Parallel II IP Core.  The intended use case is to be able\n>>> to update the flash used to load a FPGA at power up with mtd-utils.\n>>>\n>>> Signed-off-by: Matthew Gerlach \n>>> ---\n>>> v2:\n>>>     minor checkpatch fixing by Wu Hao \n>>>     Use read_dummy value as suggested by Cyrille Pitchen.\n>>>     Don't assume 4 byte addressing (Cryille Pichecn and Marek Vasut).\n>>>     Fixed #define indenting as suggested by Marek Vasut.\n>>>     Added units to timer values as suggested by Marek Vasut.\n>>>     Use io(read|write)8_rep() as suggested by Marek Vasut.\n>>>     Renamed function prefixed with __ as suggested by Marek Vasut.\n>>\n>> [...]\n>>\n>>> +#define QSPI_ACTION_REG            0\n>>> +#define QSPI_ACTION_RST            BIT(0)\n>>> +#define QSPI_ACTION_EN            BIT(1)\n>>> +#define QSPI_ACTION_SC            BIT(2)\n>>> +#define QSPI_ACTION_CHIP_SEL_SFT    4\n>>> +#define QSPI_ACTION_DUMMY_SFT        8\n>>> +#define QSPI_ACTION_READ_BACK_SFT    16\n>>> +\n>>> +#define QSPI_FIFO_CNT_REG        4\n>>> +#define QSPI_FIFO_DEPTH            0x200\n>>> +#define QSPI_FIFO_CNT_MSK        0x3ff\n>>> +#define QSPI_FIFO_CNT_RX_SFT        0\n>>> +#define QSPI_FIFO_CNT_TX_SFT        12\n>>> +\n>>> +#define QSPI_DATA_REG            0x8\n>>> +\n>>> +#define QSPI_POLL_TIMEOUT_US        10000000\n>>\n>> 10 s poll timeout ? :)\n> \n> Hi Marek,\n> \n> The 10s timeout is fairly arbitrary.  In other words, I pulled it out of\n> thin air.  Can you suggest a better timeout?  From a practical\n> standpoint 10s seemed to be much better than no timeout when I was\n> debugging bad FPGA images.  Without a timeout I was hanging the system\n> when the FPGA image failed.  With this timeout, we get a nice message\n> and Linux keeps running happily.\nAFAIK the SPI subsystem has a timeout which is adaptive to the bus\nclock, maybe that's what you want to use here ?","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"rF3cz5fO\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yC63545Wfz9sNw\n\tfor ;\n\tThu, 12 Oct 2017 08:06:09 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752670AbdJKVGH (ORCPT\n\t);\n\tWed, 11 Oct 2017 17:06:07 -0400","from mail-wm0-f48.google.com ([74.125.82.48]:44670 \"EHLO\n\tmail-wm0-f48.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752236AbdJKVGG (ORCPT\n\t); Wed, 11 Oct 2017 17:06:06 -0400","by mail-wm0-f48.google.com with SMTP id 196so21403105wma.1;\n\tWed, 11 Oct 2017 14:06:05 -0700 (PDT)","from [192.168.1.4] (ip-86-49-107-50.net.upcbroadband.cz.\n\t[86.49.107.50]) by smtp.gmail.com with ESMTPSA id\n\tc37sm33047638wra.73.2017.10.11.14.06.02\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 11 Oct 2017 14:06:03 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=Kse5GkseBYMVCxZkwML4m765E9TJmQQ7albYTlXfRRs=;\n\tb=rF3cz5fOCqHUpvYFoavBb51KeFljbMxyY6zyyeZsIGN40bNuvrKRmDrvqBymvFL930\n\tw4JqcNi2pwMjfO2g4+6b2Bf2XHiCo29OSnmLST6C1jytOBlpKAH3oRFZ7XX+7lnbHFvZ\n\t+a22reWx2DOx2UO/26g9xNK/AwqRlhFSdkZsuJOIimnn0/NLcj21kCLFmQ8MgyCcKSZ3\n\tZSgRduL5BB/ZjY2/SsGn3cWR5NjJOogQ+ElQSTUisabUtza6e7/mKVhKXvo+U4JA+3P3\n\taHCITq0vLAKVWHXBdgxgd7YX7YY4JmQt8snI37YpPctt/BNncjpWWQkFARcfMUDuLjfN\n\ty2AQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=Kse5GkseBYMVCxZkwML4m765E9TJmQQ7albYTlXfRRs=;\n\tb=UFun8ODtCbPHUMZsHRyeH/BJC88g9p1xlqj/8Two1Dfi0rAxSHz8+68Ztnso+vCRm3\n\tY44onCk1HrSdQCwsYALUXfb2ta82QaN+WUhCdJ2WxF6PlGhlYpRSxN7qi0YKLnRyCpV+\n\t049RDsQV3rQd6mYhQPRvWwXklNjaYLDpaUbkCE7at6dvSr7QXklCyZe80Sz+AHOvEl9E\n\t2syINn2XqtMLObAMH+zSn9iqNUAN0i7b3k2/zEf2YJg4l/SafscJu3pPI6JrfEjE8iBU\n\tvJMXrSXgFDleGLzigZ14VB+kaGMRmC+4ZeU6LIPba5d2MA185BFiWgzOm482OWkRTvqG\n\tRHFA==","X-Gm-Message-State":"AMCzsaWY1k3CEc3WPag6cky/awQeK6ajw5FvCuo6FGBeg0aHX6z6EHZB\n\tQu35v51JCDAWWZDtTRRp5OURlIsx","X-Google-Smtp-Source":"AOwi7QBqnIQsX+BuQZh3VA2ugx0gN8C3L5ABG3pCjjx10nxXHJ5CXkpXua051VR572kfxVR+ZP5tOw==","X-Received":"by 10.28.209.200 with SMTP id i191mr146392wmg.156.1507755964419; \n\tWed, 11 Oct 2017 14:06:04 -0700 (PDT)","Subject":"Re: [PATCH v2 2/3] mtd: spi-nor: Altera ASMI Parallel II IP Core","To":"matthew.gerlach@linux.intel.com","Cc":"vndao@altera.com, dwmw2@infradead.org, computersforpeace@gmail.com,\n\tboris.brezillon@free-electrons.com, richard@nod.at,\n\tcyrille.pitchen@wedev4u.fr, robh+dt@kernel.org,\n\tmark.rutland@arm.com, linux-mtd@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tgregkh@linuxfoundation.org, davem@davemloft.net,\n\tmchehab@kernel.org, linux-fpga@vger.kernel.org,\n\ttien.hock.loh@intel.com, hean.loong.ong@intel.com","References":"<1505932139-2905-1-git-send-email-matthew.gerlach@linux.intel.com>\n\t<1505932139-2905-3-git-send-email-matthew.gerlach@linux.intel.com>\n\t\n\t","From":"Marek Vasut ","Message-ID":"","Date":"Wed, 11 Oct 2017 23:06:02 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1786593,"web_url":"http://patchwork.ozlabs.org/comment/1786593/","msgid":"","list_archive_url":null,"date":"2017-10-13T19:24:29","subject":"Re: [PATCH v2 2/3] mtd: spi-nor: Altera ASMI Parallel II IP Core","submitter":{"id":70992,"url":"http://patchwork.ozlabs.org/api/people/70992/","name":"Matthew Gerlach","email":"matthew.gerlach@linux.intel.com"},"content":"On Wed, 11 Oct 2017, Marek Vasut wrote:\n\n> On 10/11/2017 07:00 PM, matthew.gerlach@linux.intel.com wrote:\n>>\n>>\n>> On Tue, 10 Oct 2017, Marek Vasut wrote:\n>>\n>>> On 09/20/2017 08:28 PM, matthew.gerlach@linux.intel.com wrote:\n>>>> From: Matthew Gerlach \n>>>>\n>>>> This patch adds support for a spi-nor, platform driver for the\n>>>> Altera ASMI Parallel II IP Core.  The intended use case is to be able\n>>>> to update the flash used to load a FPGA at power up with mtd-utils.\n>>>>\n>>>> Signed-off-by: Matthew Gerlach \n>>>> ---\n>>>> v2:\n>>>>     minor checkpatch fixing by Wu Hao \n>>>>     Use read_dummy value as suggested by Cyrille Pitchen.\n>>>>     Don't assume 4 byte addressing (Cryille Pichecn and Marek Vasut).\n>>>>     Fixed #define indenting as suggested by Marek Vasut.\n>>>>     Added units to timer values as suggested by Marek Vasut.\n>>>>     Use io(read|write)8_rep() as suggested by Marek Vasut.\n>>>>     Renamed function prefixed with __ as suggested by Marek Vasut.\n>>>\n>>> [...]\n>>>\n>>>> +#define QSPI_ACTION_REG            0\n>>>> +#define QSPI_ACTION_RST            BIT(0)\n>>>> +#define QSPI_ACTION_EN            BIT(1)\n>>>> +#define QSPI_ACTION_SC            BIT(2)\n>>>> +#define QSPI_ACTION_CHIP_SEL_SFT    4\n>>>> +#define QSPI_ACTION_DUMMY_SFT        8\n>>>> +#define QSPI_ACTION_READ_BACK_SFT    16\n>>>> +\n>>>> +#define QSPI_FIFO_CNT_REG        4\n>>>> +#define QSPI_FIFO_DEPTH            0x200\n>>>> +#define QSPI_FIFO_CNT_MSK        0x3ff\n>>>> +#define QSPI_FIFO_CNT_RX_SFT        0\n>>>> +#define QSPI_FIFO_CNT_TX_SFT        12\n>>>> +\n>>>> +#define QSPI_DATA_REG            0x8\n>>>> +\n>>>> +#define QSPI_POLL_TIMEOUT_US        10000000\n>>>\n>>> 10 s poll timeout ? :)\n>>\n>> Hi Marek,\n>>\n>> The 10s timeout is fairly arbitrary.  In other words, I pulled it out of\n>> thin air.  Can you suggest a better timeout?  From a practical\n>> standpoint 10s seemed to be much better than no timeout when I was\n>> debugging bad FPGA images.  Without a timeout I was hanging the system\n>> when the FPGA image failed.  With this timeout, we get a nice message\n>> and Linux keeps running happily.\n> AFAIK the SPI subsystem has a timeout which is adaptive to the bus\n> clock, maybe that's what you want to use here ?\n\nHi Marek,\n\nI looked in spi-nor.c, and I see the following two macros:\n#define DEFAULT_READY_WAIT_JIFFIES\t\t(40UL * HZ)\n#define CHIP_ERASE_2MB_READY_WAIT_JIFFIES\t(40UL * HZ)\n\nThese timers values are used at the spi-nor layer for waiting for an\noperation to complete. It is the time spent waiting for Work In Progress\nto clear.\n\nThe timer value I'm using, QSPI_POLL_TIMEOUT_US, is used at a lower layer.\nThis timer value is used for the time it takes to send the opcode and tx \ndata and receive any bytes from the flash. While 10 seconds may seem \nlong, I am just trying to avoid a system hang when there is a catastrophic\nfailure with the flash controller in the FPGA or the flash part itself.\n\nI certainly could be missing something with regards to the timeouts, but I \nthink 10s for QSPI_POLL_TIMEOUT_US doesn't hurt, and it definately helps \nwhen something goes wrong.\n\nThanks for the feedback,\nMatthew Gerlach\n\n>\n> -- \n> Best regards,\n> Marek Vasut\n>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yDHhz3hVvz9s3T\n\tfor ;\n\tSat, 14 Oct 2017 06:24:35 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751541AbdJMTYe (ORCPT\n\t);\n\tFri, 13 Oct 2017 15:24:34 -0400","from mga06.intel.com ([134.134.136.31]:43287 \"EHLO mga06.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751138AbdJMTYd (ORCPT );\n\tFri, 13 Oct 2017 15:24:33 -0400","from orsmga003.jf.intel.com ([10.7.209.27])\n\tby orsmga104.jf.intel.com with ESMTP; 13 Oct 2017 12:24:32 -0700","from mgerlach-mobl.amr.corp.intel.com (HELO [10.0.2.15])\n\t([10.254.126.215])\n\tby orsmga003.jf.intel.com with ESMTP; 13 Oct 2017 12:24:30 -0700"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos; i=\"5.43,372,1503385200\"; d=\"scan'208\";\n\ta=\"1024963784\"","Date":"Fri, 13 Oct 2017 12:24:29 -0700 (PDT)","From":"matthew.gerlach@linux.intel.com","X-X-Sender":"mgerlach@mgerlach-VirtualBox","To":"Marek Vasut ","cc":"vndao@altera.com, dwmw2@infradead.org, computersforpeace@gmail.com,\n\tboris.brezillon@free-electrons.com, richard@nod.at,\n\tcyrille.pitchen@wedev4u.fr, robh+dt@kernel.org,\n\tmark.rutland@arm.com, linux-mtd@lists.infradead.org,\n\tdevicetree@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tgregkh@linuxfoundation.org, davem@davemloft.net,\n\tmchehab@kernel.org, linux-fpga@vger.kernel.org,\n\ttien.hock.loh@intel.com, hean.loong.ong@intel.com","Subject":"Re: [PATCH v2 2/3] mtd: spi-nor: Altera ASMI Parallel II IP Core","In-Reply-To":"","Message-ID":"","References":"<1505932139-2905-1-git-send-email-matthew.gerlach@linux.intel.com>\n\t<1505932139-2905-3-git-send-email-matthew.gerlach@linux.intel.com>\n\t\n\t\n\t","User-Agent":"Alpine 2.20 (DEB 67 2015-01-07)","MIME-Version":"1.0","Content-Type":"multipart/mixed; BOUNDARY=\"8323329-241464664-1507922672=:1541\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1786647,"web_url":"http://patchwork.ozlabs.org/comment/1786647/","msgid":"<089bb472-f824-26d7-0d72-66e64c2f24c4@gmail.com>","list_archive_url":null,"date":"2017-10-13T20:34:27","subject":"Re: [PATCH v2 2/3] mtd: spi-nor: Altera ASMI Parallel II IP Core","submitter":{"id":1124,"url":"http://patchwork.ozlabs.org/api/people/1124/","name":"Marek Vasut","email":"marek.vasut@gmail.com"},"content":"On 10/13/2017 09:24 PM, matthew.gerlach@linux.intel.com wrote:\n\n[ culling the ridiculous cc list ]\n\n> On Wed, 11 Oct 2017, Marek Vasut wrote:\n> \n>> On 10/11/2017 07:00 PM, matthew.gerlach@linux.intel.com wrote:\n>>>\n>>>\n>>> On Tue, 10 Oct 2017, Marek Vasut wrote:\n>>>\n>>>> On 09/20/2017 08:28 PM, matthew.gerlach@linux.intel.com wrote:\n>>>>> From: Matthew Gerlach \n>>>>>\n>>>>> This patch adds support for a spi-nor, platform driver for the\n>>>>> Altera ASMI Parallel II IP Core.  The intended use case is to be able\n>>>>> to update the flash used to load a FPGA at power up with mtd-utils.\n>>>>>\n>>>>> Signed-off-by: Matthew Gerlach \n>>>>> ---\n>>>>> v2:\n>>>>>     minor checkpatch fixing by Wu Hao \n>>>>>     Use read_dummy value as suggested by Cyrille Pitchen.\n>>>>>     Don't assume 4 byte addressing (Cryille Pichecn and Marek Vasut).\n>>>>>     Fixed #define indenting as suggested by Marek Vasut.\n>>>>>     Added units to timer values as suggested by Marek Vasut.\n>>>>>     Use io(read|write)8_rep() as suggested by Marek Vasut.\n>>>>>     Renamed function prefixed with __ as suggested by Marek Vasut.\n>>>>\n>>>> [...]\n>>>>\n>>>>> +#define QSPI_ACTION_REG            0\n>>>>> +#define QSPI_ACTION_RST            BIT(0)\n>>>>> +#define QSPI_ACTION_EN            BIT(1)\n>>>>> +#define QSPI_ACTION_SC            BIT(2)\n>>>>> +#define QSPI_ACTION_CHIP_SEL_SFT    4\n>>>>> +#define QSPI_ACTION_DUMMY_SFT        8\n>>>>> +#define QSPI_ACTION_READ_BACK_SFT    16\n>>>>> +\n>>>>> +#define QSPI_FIFO_CNT_REG        4\n>>>>> +#define QSPI_FIFO_DEPTH            0x200\n>>>>> +#define QSPI_FIFO_CNT_MSK        0x3ff\n>>>>> +#define QSPI_FIFO_CNT_RX_SFT        0\n>>>>> +#define QSPI_FIFO_CNT_TX_SFT        12\n>>>>> +\n>>>>> +#define QSPI_DATA_REG            0x8\n>>>>> +\n>>>>> +#define QSPI_POLL_TIMEOUT_US        10000000\n>>>>\n>>>> 10 s poll timeout ? :)\n>>>\n>>> Hi Marek,\n>>>\n>>> The 10s timeout is fairly arbitrary.  In other words, I pulled it out of\n>>> thin air.  Can you suggest a better timeout?  From a practical\n>>> standpoint 10s seemed to be much better than no timeout when I was\n>>> debugging bad FPGA images.  Without a timeout I was hanging the system\n>>> when the FPGA image failed.  With this timeout, we get a nice message\n>>> and Linux keeps running happily.\n>> AFAIK the SPI subsystem has a timeout which is adaptive to the bus\n>> clock, maybe that's what you want to use here ?\n> \n> Hi Marek,\n> \n> I looked in spi-nor.c, and I see the following two macros:\n> #define DEFAULT_READY_WAIT_JIFFIES        (40UL * HZ)\n> #define CHIP_ERASE_2MB_READY_WAIT_JIFFIES    (40UL * HZ)\n> \n> These timers values are used at the spi-nor layer for waiting for an\n> operation to complete.  It is the time spent waiting for Work In Progress\n> to clear.\n> \n> The timer value I'm using, QSPI_POLL_TIMEOUT_US, is used at a lower layer.\n> This timer value is used for the time it takes to send the opcode and tx\n> data and receive any bytes from the flash.  While 10 seconds may seem\n> long, I am just trying to avoid a system hang when there is a catastrophic\n> failure with the flash controller in the FPGA or the flash part itself.\n\nIt takes 10s to detect catastrophic failure ? I'd expect you can scale\nthat timeout value by the bus clock speed.\n\nWe have ie. this in drivers/spi/spi.c:\n\n9 ret = 0;\n1040 ms = 8LL * 1000LL * xfer->len;\n1041 do_div(ms, xfer->speed_hz);\n1042 ms += ms + 200; /* some tolerance */\n1043\n1044 if (ms > UINT_MAX)\n1045 ms = UINT_MAX;\n1046\n1047 ms =\nwait_for_completion_timeout(&master->xfer_completion,\n1048\nmsecs_to_jiffies(ms));\n\n> I certainly could be missing something with regards to the timeouts, but\n> I think 10s for QSPI_POLL_TIMEOUT_US doesn't hurt, and it definately\n> helps when something goes wrong.\n> \n> Thanks for the feedback,\n> Matthew Gerlach\n> \n>>\n>> -- \n>> Best regards,\n>> Marek Vasut\n>>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"m6pxufLr\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yDKFh3vTMz9sRm\n\tfor ;\n\tSat, 14 Oct 2017 07:34:32 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751451AbdJMUeb (ORCPT\n\t);\n\tFri, 13 Oct 2017 16:34:31 -0400","from mail-wm0-f50.google.com ([74.125.82.50]:44644 \"EHLO\n\tmail-wm0-f50.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751081AbdJMUea (ORCPT\n\t); Fri, 13 Oct 2017 16:34:30 -0400","by mail-wm0-f50.google.com with SMTP id 196so29198628wma.1\n\tfor ;\n\tFri, 13 Oct 2017 13:34:29 -0700 (PDT)","from [192.168.1.4] (ip-86-49-107-50.net.upcbroadband.cz.\n\t[86.49.107.50]) by smtp.gmail.com with ESMTPSA id\n\td82sm1231243wmd.14.2017.10.13.13.34.27\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 13 Oct 2017 13:34:28 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=GgBmqoi25LF2MqEgQe6VM/rBpmFKSiN5UkYCCZFfXiE=;\n\tb=m6pxufLr5LfowHD1gcBDfwtLweH4rWhTylN0djaW0b0zWl0yNsdn0XAomsOpfMaeEQ\n\tXIsBLrJKyCmiF6cl3XxrOMVOBkQ9HpAqoPhStNkf+e/bVwU3wZD7PJ17xQtFuqJjmaxn\n\tjYLwJtNVtkwCkWfUZvUVlk9F58WH+jzEngoC41HUXmBx6BqmpBuZdB0WHwi/VIQfuFED\n\tlSqWrDyoyQKLdr8Aw3BeA70DFRZdA5hrAeZQiX8ABQqO/ZdH7UbebIEwGlmOzwCKnwWq\n\t+jkpqpWLkSPBTHZj+NEvajB+FnlzTbkaIFbOIjCDDoenQ4U54DHM3Nsyx3gghUjvZnaj\n\tQjDQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=GgBmqoi25LF2MqEgQe6VM/rBpmFKSiN5UkYCCZFfXiE=;\n\tb=NPku0mVjsGMv8/g+R0rXP7wtNPV1K8w45YRPhezx8NwirS51o2tGq4pi5C8Vpb5U/7\n\tWB19HJAlm8E1qLgDHLlH4C53UtYpiF1mbRq+QAgq3QihPU6eD/rEglg9JK1iozqOrGEx\n\taJUjuepRVb6Y4KgjF8AFT6t593bpmNHfh/DdHy3Tt0hYMKTDary38rP1fB12h5oGGI7P\n\tgI9oi5ca/mUB42G569uOW5NlNnidkayc8qECj3yICZsKQJvTAjAOpHiTbCzxiezyE2Ni\n\tT2WQwPGvqgcotfg1eGXcFM8pLypJlSuHhzVOkxI3tk9Yq1NU+0CUH2zzA/w8xGs7+8AR\n\tKbuw==","X-Gm-Message-State":"AMCzsaVLd5ugE01XDCaW6NkvjT0DywITVW5BI0wEPetwnaLV4wAUa5yI\n\tUJ9q0IBru7Fiw275uoFprCy3Uvdf","X-Google-Smtp-Source":"ABhQp+R6QQC0K6Ykf0BR7Qu0q31kxGudhbD9Hyi/ryX8uSf2UVzVXxVZ/mlQtp6LYmYXwiH8gsDWYA==","X-Received":"by 10.28.66.16 with SMTP id p16mr2535466wma.11.1507926868831;\n\tFri, 13 Oct 2017 13:34:28 -0700 (PDT)","Subject":"Re: [PATCH v2 2/3] mtd: spi-nor: Altera ASMI Parallel II IP Core","To":"matthew.gerlach@linux.intel.com","Cc":"vndao@altera.com, computersforpeace@gmail.com,\n\tboris.brezillon@free-electrons.com, richard@nod.at,\n\tCyrille Pitchen ,\n\tlinux-mtd@lists.infradead.org, devicetree@vger.kernel.org","References":"<1505932139-2905-1-git-send-email-matthew.gerlach@linux.intel.com>\n\t<1505932139-2905-3-git-send-email-matthew.gerlach@linux.intel.com>\n\t\n\t\n\t\n\t","From":"Marek Vasut ","Message-ID":"<089bb472-f824-26d7-0d72-66e64c2f24c4@gmail.com>","Date":"Fri, 13 Oct 2017 22:34:27 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1787647,"web_url":"http://patchwork.ozlabs.org/comment/1787647/","msgid":"","list_archive_url":null,"date":"2017-10-16T18:41:31","subject":"Re: [PATCH v2 3/3] mtd: spi-nor: add flag for reading dummy cycles\n\tfrom nv cfg reg","submitter":{"id":70992,"url":"http://patchwork.ozlabs.org/api/people/70992/","name":"Matthew Gerlach","email":"matthew.gerlach@linux.intel.com"},"content":"Hi Cyrille,\n\nThanks for the feedback. See my comments in line below.\n\nMatthew Gerlach\n\n\nOn Tue, 10 Oct 2017, Cyrille Pitchen wrote:\n\n> Hi Matthew\n>\n> NAK for this patch\n>\n> Le 20/09/2017 à 20:28, matthew.gerlach@linux.intel.com a écrit :\n>> From: Matthew Gerlach \n>>\n>> This patch is a work around for some non-standard behavior\n>> of EPCQ flash parts:\n>>\n>> https://www.altera.com/documentation/wtw1396921531042.html#wtw1396921651224\n>>\n>\n> From the above documentation:\n> \"\"\"\n> Write Non-Volatile Configuration Register Operation\n>\n> You need to write the non-volatile configuration registers for EPCQ-L\n> devices for different configuration schemes. If you are using the .jic\n> file, the Quartus® Prime programmer sets the number of dummy clock\n> cycles and address bytes. If you are using an external programmer tools\n> (3rd party programmer tools), you must set the non-volatile\n> configuration registers.\n>\n> To set the non-volatile configuration register, follow these steps:\n>\n> Execute the write enable operation.\n> Execute the write non-volatile configuration register operation.\n> Set the 16-bit register value.\n>\n\nThis documentation does not match my experience with the flash. No where\nam I setting the non-volatile configuration register. After power up, I \njust read the register and observe 10 dummy clock cycles, which is the \nonly value that results in successfully reading correct data from the \nflash. I suspect the FPGA is doing the same at power up.\n\n> Set the 16-bit register value as b'1110 1110 xxxx 1111 where xxxx is the\n> dummy clock value. When the xxxx value is from 0001 to 1110, the dummy\n> clock value is from 1 to 14. When xxxx is 0000 or 1111, the dummy clock\n> value is at the default value, which is 8 for standard fast read (AS x1)\n> mode and 10 for extended quad input fast read (AS x4) mode.\n> \"\"\"\n>\n> AFAIU, it is stated that you can set the number of dummy cycle to either\n> 0000b or 1111b, the default value. There is no valid reason to use any\n> other value, like there is no valid reason to tune the number of dummy\n> clock cycles. Just keep the default settings, please!\n\nThe default Micron setting simply does not work.\n\n>\n> If we start to play changing the number of dummy cycles it would be real\n> mess to maintain.\n\nI completely understand the maintainance issue.\n\n>\n> First, should we read the value to be used from some register or should\n> we force this value instead by writing that register ?\n> Some would prefer reading whereas other would prefer updating...\n>\n> Moreover, the method to read or write the number of dummy cycles is not\n> standard and is manufacturer specific:\n\nYes I get it that is manufacturer specific, and this would be another \nexample of yet a different manufacturer's approach.\n\n>\n> - Micron uses 2 registers: the Volatile Configuration Register and the\n> Non-Volatile configuration Register.\n>\n> - Macronix uses another register but doesn't store the number of dummy\n> cycles directly: instead this manufacturer uses codes. So we would have\n> to store tables mapping codes <-> number dummy clock cycles\n>\n> - Spansion/Cypress also uses code tables and I already know that\n> depending on the memory part number the code is either 2bit or 4bit and\n> stored in different registers. Damned!\n>\n> If I allow you to tune the number of dummy clock cycles for Micron\n> memory it would be fair that I allow other people to tune this number\n> for other memory manufacturers. However it would be a real pain to\n> maintain because there is no standard for that hence manufacturers just\n> do what they want and change things when they want. Far too\n> unpredictable, IMHO.\n>\n> So to avoid a messy situation, the rule is simple: SPI-NOR memory MUST\n> be configured in their default factory settings when spi_nor_scan() is\n> called. Your memory has the very same JEDEC ID as some Micron memory,\n> then it should behave the exact same way: in this case the value for the\n> number of dummy clock cycles should be set to 0000b or 1111b in the NVCR\n> (and VCR too).\n\nI think this is crux of the problem. The flash chip is essentially lying \nabout what kind of chip it is. It says it is a Micron memory, but it \ncertainly is not behaving like a Micron chip. I believe the purpose of \nthese EPCQ chips is somehow make it easier for the FPGA to configure \nitself on power up, but it is doing it in a very non-standard and \nnon-maintainable way. I believe the FPGA is reading dummy cycles from the\nNVCR on power up. How else would it know how many dummy cycles to use?\n\n\nThe good news is that these chips are on path to \nend of life, and moving forward we will be using standard flash parts. \nThe bad news is that there are a lot of these chips already in the wild, \nand I suspect more are in the pipeline.\n\nAt this point I see no path forward to being able to upstream support for \nthese EPCQ chips.\n\n>\n>\n>> These flash parts are generally used to configure Intel/Altera FPGAs\n>> on power up. These parts report a JEDEC id of the Micron part at the core,\n>> but have a different number of dummy cycles than specified in the Micron\n>> data sheet. The number of required dummy cycles can be read from the\n>> Non-Volatile Configuration register.\n>>\n>> Signed-off-by: Matthew Gerlach \n>> ---\n>> drivers/mtd/spi-nor/altera-asmip2.c | 31 ++++++++++++++++++++++++++-----\n>> include/linux/mtd/altera-asmip2.h | 3 +++\n>> 2 files changed, 29 insertions(+), 5 deletions(-)\n>>\n>> diff --git a/drivers/mtd/spi-nor/altera-asmip2.c b/drivers/mtd/spi-nor/altera-asmip2.c\n>> index a977765..d9cd807 100644\n>> --- a/drivers/mtd/spi-nor/altera-asmip2.c\n>> +++ b/drivers/mtd/spi-nor/altera-asmip2.c\n>> @@ -40,6 +40,10 @@\n>> #define QSPI_POLL_TIMEOUT_US\t\t10000000\n>> #define QSPI_POLL_INTERVAL_US\t\t5\n>>\n>> +#define SPINOR_OP_RD_NVCFG\t\t0xb5\n>> +#define NVCFG_DUMMY_SFT\t\t\t12\n>> +#define NVCFG_DUMMY_MASK\t\t0xf\n>> +\n>> struct altera_asmip2 {\n>> \tvoid __iomem *csr_base;\n>> \tu32 num_flashes;\n>> @@ -231,7 +235,8 @@ static void altera_asmip2_unprep(struct spi_nor *nor, enum spi_nor_ops ops)\n>> }\n>>\n>> static int altera_asmip2_setup_banks(struct device *dev,\n>> -\t\t\t\t u32 bank, struct device_node *np)\n>> +\t\t\t\t u32 bank, struct device_node *np,\n>> +\t\t\t\t u32 flags)\n>> {\n>> \tconst struct spi_nor_hwcaps hwcaps = {\n>> \t\t.mask = SNOR_HWCAPS_READ |\n>> @@ -241,6 +246,7 @@ static int altera_asmip2_setup_banks(struct device *dev,\n>> \tstruct altera_asmip2 *q = dev_get_drvdata(dev);\n>> \tstruct altera_asmip2_flash *flash;\n>> \tstruct spi_nor *nor;\n>> +\tu16 nvcfg;\n>> \tint ret = 0;\n>>\n>> \tif (bank > q->num_flashes - 1)\n>> @@ -273,6 +279,20 @@ static int altera_asmip2_setup_banks(struct device *dev,\n>> \t\treturn ret;\n>> \t}\n>>\n>> +\tif (flags & ALTERA_ASMIP2_FLASH_FLG_RD_NVCFG) {\n>> +\t\tret = altera_asmip2_read_reg(nor, SPINOR_OP_RD_NVCFG,\n>> +\t\t \t\t\t (u8*)&nvcfg, sizeof(nvcfg));\n>> +\n>> +\t\tif (ret) {\n>> +\t\t\tdev_err(nor->dev,\n>> +\t\t\t\t\"failed to read NV Configuration register\\n\");\n>> +\t\t\treturn ret;\n>> +\t\t}\n>> +\n>> +\t\tnor->read_dummy = (nvcfg >> NVCFG_DUMMY_SFT) & NVCFG_DUMMY_MASK;\n>> +\t\tdev_info(nor->dev, \"%s dummy %d\\n\", __func__, nor->read_dummy);\n>> +\t}\n>> +\n>\n> You have forgotten the special case for values 0000b and 1111b (default\n> settings). For those 2 values, the actual number of dummy clock cycles is:\n> - 0 for Read (03h/13h)\n> - 8 for Fast Read 1-1-1 (0Bh/0Ch)\n> - 8 for Fast Read 1-1-2 (3Bh/3Ch)\n> - 8 for Fast Read 1-2-2 (BBh/BCh)\n> - 8 for Fast Read 1-1-4 (6Bh/6Ch)\n> - 10 for Fast Read 1-4-4 (EBh/ECh)\n>\n> Besides, the value read from the Non-Volatile Configuration Register is\n> the value loaded into the Volatile Configuration Register at power-up.\n> The actual number of dummy clock cycles to be used by Fast Read commands\n> should be read from the Volatile Configuration Register.\n>\n> Anyway, this not the way to go.\n>\n> Best regards,\n>\n> Cyrille\n>\n>> \tret = mtd_device_register(&nor->mtd, NULL, 0);\n>>\n>> \treturn ret;\n>> @@ -308,7 +328,7 @@ static int altera_asmip2_create(struct device *dev, void __iomem *csr_base)\n>> }\n>>\n>> static int altera_asmip2_add_bank(struct device *dev,\n>> -\t\t\t u32 bank, struct device_node *np)\n>> +\t\t\t u32 bank, struct device_node *np, u32 flags)\n>> {\n>> \tstruct altera_asmip2 *q = dev_get_drvdata(dev);\n>>\n>> @@ -317,7 +337,7 @@ static int altera_asmip2_add_bank(struct device *dev,\n>>\n>> \tq->num_flashes++;\n>>\n>> -\treturn altera_asmip2_setup_banks(dev, bank, np);\n>> +\treturn altera_asmip2_setup_banks(dev, bank, np, flags);\n>> }\n>>\n>> static int altera_asmip2_remove_banks(struct device *dev)\n>> @@ -361,7 +381,8 @@ static int altera_asmip2_probe_with_pdata(struct platform_device *pdev,\n>> \t}\n>>\n>> \tfor (i = 0; i < qdata->num_chip_sel; i++) {\n>> -\t\tret = altera_asmip2_add_bank(dev, i, NULL);\n>> +\t\tret = altera_asmip2_add_bank(dev, i, NULL,\n>> +\t\t\t\t\t qdata->flash_flags[i]);\n>> \t\tif (ret) {\n>> \t\t\tdev_err(dev, \"failed to add qspi bank %d\\n\", ret);\n>> \t\t\tbreak;\n>> @@ -414,7 +435,7 @@ static int altera_asmip2_probe(struct platform_device *pdev)\n>> \t\t\tgoto error;\n>> \t\t}\n>>\n>> -\t\tif (altera_asmip2_add_bank(dev, bank, pp)) {\n>> +\t\tif (altera_asmip2_add_bank(dev, bank, pp, 0)) {\n>> \t\t\tdev_err(dev, \"failed to add bank %u\\n\", bank);\n>> \t\t\tgoto error;\n>> \t\t}\n>> diff --git a/include/linux/mtd/altera-asmip2.h b/include/linux/mtd/altera-asmip2.h\n>> index 580c43c..185a9b2 100644\n>> --- a/include/linux/mtd/altera-asmip2.h\n>> +++ b/include/linux/mtd/altera-asmip2.h\n>> @@ -16,9 +16,12 @@\n>> #define ALTERA_ASMIP2_MAX_NUM_FLASH_CHIP 3\n>> #define ALTERA_ASMIP2_RESOURCE_SIZE 0x10\n>>\n>> +#define ALTERA_ASMIP2_FLASH_FLG_RD_NVCFG\tBIT(0)\n>> +\n>> struct altera_asmip2_plat_data {\n>> \tvoid __iomem *csr_base;\n>> \tu32 num_chip_sel;\n>> +\tu32 flash_flags[ALTERA_ASMIP2_MAX_NUM_FLASH_CHIP];\n>> };\n>>\n>> #endif\n>>\n>\n>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yG6c20Kd9z9sBZ\n\tfor ;\n\tTue, 17 Oct 2017 05:41:38 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932242AbdJPSlg (ORCPT );\n\tMon, 16 Oct 2017 14:41:36 -0400","from mga06.intel.com ([134.134.136.31]:18913 \"EHLO mga06.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S932145AbdJPSlf (ORCPT );\n\tMon, 16 Oct 2017 14:41:35 -0400","from fmsmga005.fm.intel.com ([10.253.24.32])\n\tby orsmga104.jf.intel.com with ESMTP; 16 Oct 2017 11:41:33 -0700","from mgerlach-mobl.amr.corp.intel.com (HELO [10.0.2.15])\n\t([10.254.40.96])\n\tby fmsmga005.fm.intel.com with ESMTP; 16 Oct 2017 11:41:31 -0700"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.43,387,1503385200\"; d=\"scan'208\";a=\"163275489\"","Date":"Mon, 16 Oct 2017 11:41:31 -0700 (PDT)","From":"matthew.gerlach@linux.intel.com","X-X-Sender":"mgerlach@mgerlach-VirtualBox","To":"Cyrille Pitchen ","cc":"vndao@altera.com, dwmw2@infradead.org, computersforpeace@gmail.com,\n\tboris.brezillon@free-electrons.com, marek.vasut@gmail.com,\n\trichard@nod.at, robh+dt@kernel.org, mark.rutland@arm.com,\n\tlinux-mtd@lists.infradead.org, devicetree@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,\n\tdavem@davemloft.net, mchehab@kernel.org,\n\tlinux-fpga@vger.kernel.org, tien.hock.loh@intel.com,\n\thean.loong.ong@intel.com","Subject":"Re: [PATCH v2 3/3] mtd: spi-nor: add flag for reading dummy cycles\n\tfrom nv cfg reg","In-Reply-To":"<28c32a9c-1fd8-3af4-abc6-f4938e138daa@wedev4u.fr>","Message-ID":"","References":"<1505932139-2905-1-git-send-email-matthew.gerlach@linux.intel.com>\n\t<1505932139-2905-4-git-send-email-matthew.gerlach@linux.intel.com>\n\t<28c32a9c-1fd8-3af4-abc6-f4938e138daa@wedev4u.fr>","User-Agent":"Alpine 2.20 (DEB 67 2015-01-07)","MIME-Version":"1.0","Content-Type":"multipart/mixed; BOUNDARY=\"8323329-231588532-1508179293=:19479\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]