From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82C05C433EF for ; Wed, 3 Nov 2021 23:50:40 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E2FAC611C6 for ; Wed, 3 Nov 2021 23:50:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E2FAC611C6 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=microchip.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3C7E583649; Thu, 4 Nov 2021 00:50:25 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=quarantine dis=none) header.from=microchip.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=microchip.com header.i=@microchip.com header.b="xU2wxUz0"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id EB3278364B; Thu, 4 Nov 2021 00:50:21 +0100 (CET) Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) (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 53274835B9 for ; Thu, 4 Nov 2021 00:50:07 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=microchip.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=Tudor.Ambarus@microchip.com DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1635983407; x=1667519407; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=cnUlwYFJQvQ734G/G4poNAJ14Em1XFAHZoZL6Nw9nu4=; b=xU2wxUz0SBUJepAPiTYfPk8MHnjt1rnfXtICJUb/SB5DSk8307aaEXVL AY18wUsQfjLQexbLrZCDfkzRFb0oazi089/6u/q+a6CqaXXWMksKK5xG2 m0bcDztGolC9ZM9CH//c/lQvC4OGt7D4hrJznnx7s/+bE3uCkGZACHXTP KGsrWdGCqMa1ROyrfqI0g3d+A0QYDAYaOt6XN1HKqtXcPkZalvBYj1MXB j0QgO/Pfj5U6oybCOJV4ibBMB/qU6DrMEiV7/7quR59SVKohagbmJ2dKP I0lpGPGzBt9ZEKklbxsC9SsdBKiBBtMeSVtm/7LMIstITJLr1fgfU328f Q==; IronPort-SDR: xeDrL6g7CdDZwPi796haOVhvgZ4TZkWIadr34ndVk3v59ddF/yvk/AvWg7EvxyM2cnVChnGYrN b/zBBz9ZOmEVc03yWyWFzQubF0FiU2XmNin7XmdocykiZWWHToO0uxPnq+qxXIfjsrIlX5HqNy fYWjTvqc8j1oLa1br3Rvpiwx1nY/62oWy11/rg6BJncW5V33RUqOXyiAvwKbmWA4gnYsScAGux RbS9SRwV5a+hEA1g3xi+IMfaq1HdTwvhzYVJ/oEsoTzPSRLScwiwF+F10/m7qsBOpG/qwaoJrG R7Un966J7xl+al49iFpv+rPI X-IronPort-AV: E=Sophos;i="5.87,207,1631602800"; d="scan'208";a="135408428" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa4.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 03 Nov 2021 16:50:06 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Wed, 3 Nov 2021 16:50:06 -0700 Received: from ROB-ULT-M18064N.mchp-main.com (10.10.115.15) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server id 15.1.2176.14 via Frontend Transport; Wed, 3 Nov 2021 16:50:04 -0700 From: Tudor Ambarus To: , , CC: , , Tudor Ambarus Subject: [PATCH v2 3/4] Revert "mtd: spi-nor-core: Perform a Soft Reset on boot" Date: Thu, 4 Nov 2021 01:49:49 +0200 Message-ID: <20211103234950.202289-4-tudor.ambarus@microchip.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20211103234950.202289-1-tudor.ambarus@microchip.com> References: <20211103234950.202289-1-tudor.ambarus@microchip.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.103.2 at phobos.denx.de X-Virus-Status: Clean This reverts commit 0be8ab1f166844d53477387dc9a1184161ef44ef. There are multiple reset commands and it was used one at guess, see BFPT[dword(16)]. It is preferable to avoid issuing unsupported commands to a flash. Since there's no config in mainline that actually uses SPI_FLASH_SOFT_RESET_ON_BOOT, remove it entirely until proper support is added. One should instead determine the mode in which the flash device is configured, then to parse SFDP to determine the cmd_ext_type and then to issue a READID command if flash identification is really a must. JESD216D-01 proposes an algorithm to try to read the SFDP signature to determine the mode in which the flash is configured: ''' try to read the SFDP signature (see 6.1) in 4-4-4 mode, if that fails try 2-2-2 mode, and if that fails try 1-1-1 mode. For Octal devices, these typically support SFDP read operation in both 1S-1S-1S mode and 8D-8D-8D mode. If the host controller does not know exactly which protocol mode is used for SFDP in 8D-8D-8D mode, this information can be found by reading SFDP in 1S-1S-1S mode first. (To read an unknown device directly in 8D-8D-8D mode, the host controller may read from address 0, and count the number of dummy clocks required before the SFDP signature is received.) ''' If the flash does not support SFDP at all, one should introduce dedicated configs for each reset type and issue just the needed reset command. Signed-off-by: Tudor Ambarus --- drivers/mtd/spi/Kconfig | 9 --------- drivers/mtd/spi/spi-nor-core.c | 27 --------------------------- 2 files changed, 36 deletions(-) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index 2d2b71c52d..14800b5e93 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -103,15 +103,6 @@ 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 - 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 df66a73495..caf764720c 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -3796,33 +3796,6 @@ 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; -- 2.25.1