From patchwork Thu Jun 4 12:44:36 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pratyush Yadav X-Patchwork-Id: 1303517 X-Patchwork-Delegate: jagannadh.teki@gmail.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=85.214.62.61; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=ti.com header.i=@ti.com header.a=rsa-sha256 header.s=ti-com-17Q1 header.b=jGavRzPE; dkim-atps=neutral Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 49d5Fm1C3tz9sSc for ; Thu, 4 Jun 2020 22:49:32 +1000 (AEST) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id DDEC081817; Thu, 4 Jun 2020 14:46:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=ti.com header.i=@ti.com header.b="jGavRzPE"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4CF2781CCC; Thu, 4 Jun 2020 14:45:57 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 51EFF81CCF for ; Thu, 4 Jun 2020 14:45:53 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=p.yadav@ti.com Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 054Cji7R099172; Thu, 4 Jun 2020 07:45:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1591274744; bh=gN/8tXEFCcicEpYWIBMoy4o4WHwkrOEumjVoPJwdtAs=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=jGavRzPEuFFBXXBXvffU8xJ+jwkDllSaW//MGTQATaDCO8u3a1ZLhsyM5jfPGZSrh WGvPkJOAqUPpgIuS123bhpByb0Do3SiUuLXpq7Gt0yX8jRxxKueZYsh6RUVfLx6H/t M7FzvTb+Sd65oi7f5okgDyIThfYnD0Y+oFlnq9aI= Received: from DLEE115.ent.ti.com (dlee115.ent.ti.com [157.170.170.26]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 054CjinZ112375 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 4 Jun 2020 07:45:44 -0500 Received: from DLEE104.ent.ti.com (157.170.170.34) by DLEE115.ent.ti.com (157.170.170.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Thu, 4 Jun 2020 07:45:43 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Thu, 4 Jun 2020 07:45:44 -0500 Received: from pratyush-OptiPlex-790.dhcp.ti.com (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 054CicBj004409; Thu, 4 Jun 2020 07:45:41 -0500 From: Pratyush Yadav To: Chris Packham , Jagan Teki , Vignesh R , Ryder Lee , Weijie Gao , GSS_MTK_Uboot_upstream , CC: Pratyush Yadav , Sekhar Nori , "Tan, Ley Foon" Subject: [PATCH v5 19/21] mtd: spi-nor-core: Perform a Soft Reset on boot Date: Thu, 4 Jun 2020 18:14:36 +0530 Message-ID: <20200604124438.16783-20-p.yadav@ti.com> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200604124438.16783-1-p.yadav@ti.com> References: <20200604124438.16783-1-p.yadav@ti.com> MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.30rc1 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.102.2 at phobos.denx.de X-Virus-Status: Clean When the flash is handed to us in a stateful mode like 8D-8D-8D, it is difficult to detect the mode the flash is in. One option is to read SFDP in all modes and see which one gives the correct "SFDP" signature, but not all flashes support SFDP in 8D-8D-8D mode. Further, even if you detect the mode of the flash via SFDP, you still have the problem of actually reading the ID. The Read ID command is not standardized across flash vendors. Flashes can have different dummy cycles needed for reading the ID. Some flashes even expect a 4-byte dummy address with the Read ID command. All this information cannot be obtained from the SFDP table. So, perform a Software Reset sequence before reading the ID and initializing the flash. A Soft Reset will bring back the flash in its default protocol mode assuming no non-volatile configuration was set. This will let us detect the flash even if ROM hands it to us in Octal DTR mode. To accommodate cases where there is more than one flash on a board, and only one of them needs a soft reset, failure to reset is not made fatal, and we still try to read ID if possible. Signed-off-by: Pratyush Yadav --- drivers/mtd/spi/Kconfig | 10 ++++++++++ drivers/mtd/spi/spi-nor-core.c | 27 +++++++++++++++++++++++++++ 2 files changed, 37 insertions(+) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index 765671eaf9..b5b728d050 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -104,6 +104,16 @@ config SPI_FLASH_SOFT_RESET Enable support for xSPI Software Reset. It will be used to switch from Octal DTR mode to legacy mode on shutdown and boot (if enabled). +config SPI_FLASH_SOFT_RESET_ON_BOOT + bool "Perform a Software Reset on boot on flashes that boot in stateful mode" + depends on SPI_FLASH_SOFT_RESET + default n + help + Perform a Software Reset on boot to allow detecting flashes that are + handed to us in Octal DTR mode. Do not enable this config on flashes + that are not supposed to be handed to U-Boot in Octal DTR mode, even + if they _do_ support the Soft Reset sequence. + config SPI_FLASH_BAR bool "SPI flash Bank/Extended address register support" help diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index aa4281d0a2..f9773feaff 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -3055,6 +3055,33 @@ int spi_nor_scan(struct spi_nor *nor) nor->setup = spi_nor_default_setup; +#ifdef CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT + /* + * When the flash is handed to us in a stateful mode like 8D-8D-8D, it + * is difficult to detect the mode the flash is in. One option is to + * read SFDP in all modes and see which one gives the correct "SFDP" + * signature, but not all flashes support SFDP in 8D-8D-8D mode. + * + * Further, even if you detect the mode of the flash via SFDP, you + * still have the problem of actually reading the ID. The Read ID + * command is not standardized across flash vendors. Flashes can have + * different dummy cycles needed for reading the ID. Some flashes even + * expect a 4-byte dummy address with the Read ID command. All this + * information cannot be obtained from the SFDP table. + * + * So, perform a Software Reset sequence before reading the ID and + * initializing the flash. A Soft Reset will bring back the flash in + * its default protocol mode assuming no non-volatile configuration was + * set. This will let us detect the flash even if ROM hands it to us in + * Octal DTR mode. + * + * To accommodate cases where there is more than one flash on a board, + * and only one of them needs a soft reset, failure to reset is not + * made fatal, and we still try to read ID if possible. + */ + spi_nor_soft_reset(nor); +#endif /* CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT */ + info = spi_nor_read_id(nor); if (IS_ERR_OR_NULL(info)) return -ENOENT;