From patchwork Wed Jun 19 13:04:32 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schaefer X-Patchwork-Id: 1118707 X-Patchwork-Delegate: sbabic@denx.de Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.denx.de (client-ip=81.169.180.215; helo=lists.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=kontron.com Received: from lists.denx.de (dione.denx.de [81.169.180.215]) by ozlabs.org (Postfix) with ESMTP id 45TQCK4sJqz9sNC for ; Wed, 19 Jun 2019 23:04:43 +1000 (AEST) Received: by lists.denx.de (Postfix, from userid 105) id EDF5FC21EBF; Wed, 19 Jun 2019 13:04:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lists.denx.de (localhost [IPv6:::1]) by lists.denx.de (Postfix) with ESMTP id E699BC21DD3; Wed, 19 Jun 2019 13:04:36 +0000 (UTC) Received: by lists.denx.de (Postfix, from userid 105) id 114D8C21D8E; Wed, 19 Jun 2019 13:04:35 +0000 (UTC) Received: from skedge03.snt-world.com (skedge03.snt-world.com [91.208.41.68]) by lists.denx.de (Postfix) with ESMTPS id 9969FC21CB6 for ; Wed, 19 Jun 2019 13:04:34 +0000 (UTC) Received: from sntmail14r.snt-is.com (unknown [10.203.32.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by skedge03.snt-world.com (Postfix) with ESMTPS id 687AC67A90F; Wed, 19 Jun 2019 15:04:33 +0200 (CEST) Received: from sntmail14r.snt-is.com (10.203.32.184) by sntmail14r.snt-is.com (10.203.32.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 19 Jun 2019 15:04:33 +0200 Received: from sntmail14r.snt-is.com ([fe80::c8f3:eae9:52c2:11a8]) by sntmail14r.snt-is.com ([fe80::c8f3:eae9:52c2:11a8%3]) with mapi id 15.01.1713.004; Wed, 19 Jun 2019 15:04:33 +0200 From: Thomas Schaefer To: "sbabic@denx.de" , "rajat.srivastava@nxp.com" , "uboot-imx@nxp.com" Thread-Topic: QSPI support on i.MX7D Sabre Eval Board Thread-Index: AdUmnVwl65fkiBUnR5SvF3viKqC8UA== Date: Wed, 19 Jun 2019 13:04:32 +0000 Message-ID: <25a89a15fd1344c2a31fd0d535ccc0cc@kontron.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.228.0.137] x-c2processedorg: 51b406b7-48a2-4d03-b652-521f56ac89f3 MIME-Version: 1.0 X-SnT-MailScanner-Information: Please contact the ISP for more information X-SnT-MailScanner-ID: 687AC67A90F.AAFC3 X-SnT-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SnT-MailScanner-SpamCheck: X-SnT-MailScanner-From: thomas.schaefer@kontron.com X-SnT-MailScanner-To: rajat.srivastava@nxp.com, sbabic@denx.de, u-boot@lists.denx.de, uboot-imx@nxp.com Cc: "'u-boot@lists.denx.de'" Subject: [U-Boot] QSPI support on i.MX7D Sabre Eval Board X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.18 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" Hi all, I've built current u-boot (v2019.07-rc4) with QSPI support for our i.MX7D Sabre eval system. I am using mx7dsabresd_qspi_defconfig. The resulting u-boot fails to read from QSPI, i.e. the data read is not the same than that written before with a previous (v2018) version. After some investigation I found that the 'is_controller_busy' function comes back with -ETIMEDOUT during read operation, because the retry count of 5 is too low. To figure out how many retries are needed, I added some debug code as part of a while(1) loop to the is_controller_busy function: On my MX7 eval system I found that a retry count between 73 and 147 is necessary to make sure that the controller will be ready before the next operation. So from my point of view we have 2 options to fix this issue: - increase retry from 5 to 200 - wait in an endless loop (while (1) ) and return only when the controller is ready (which means that the board will hang if the controller doesn't come back for some other reason. What do you think? Best regards, Thomas Schäfer SW Design Engineer Kontron - An S&T Company Heinrich-Barth-Straße 1-1a | 66115 Saarbrücken | Germany thomas.schaefer@kontron.com http://www.kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Europe GmbH Die gesetzlichen Pflichtangaben finden Sie hier. Please find our mandatory legal statements here. Mit dem Öffnen dieses E-Mails stimmen Sie Kontrons Richtlinien zur elektronischen Kommunikation zu. By opening this email you are agreeing to Kontron's Electronic Communications Policy. Signed-off-by: Thomas Schaefer diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index 1598c4f698..fa5b7a29f2 100644 --- a/drivers/spi/fsl_qspi.c +++ b/drivers/spi/fsl_qspi.c @@ -152,16 +152,20 @@ static inline int is_controller_busy(const struct fsl_qspi_priv *priv) u32 val; const u32 mask = QSPI_SR_BUSY_MASK | QSPI_SR_AHB_ACC_MASK | QSPI_SR_IP_ACC_MASK; - unsigned int retry = 5; + unsigned int retry = 0; do { val = qspi_read32(priv->flags, &priv->regs->sr); - if ((~val & mask) == mask) + if ((~val & mask) == mask) { + if (retry > 5) + printf("%s: timeout! retry = %d\n", __func__, retry); return 0; + } udelay(1); - } while (--retry); + retry++; + } while (1); return -ETIMEDOUT; }