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 38305C433FE for ; Mon, 25 Oct 2021 19:53:51 +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 AF8A360C4B for ; Mon, 25 Oct 2021 19:53:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AF8A360C4B Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.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 00B3183461; Mon, 25 Oct 2021 21:53:48 +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="C1vCqAu9"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C2EEC83278; Mon, 25 Oct 2021 21:53:46 +0200 (CEST) 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 200038352A for ; Mon, 25 Oct 2021 21:53:43 +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 lelv0265.itg.ti.com ([10.180.67.224]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 19PJrdw8018852; Mon, 25 Oct 2021 14:53:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1635191619; bh=HSTIUkMJSd8nf2s8pi8/GRR+RP5xsMXlyLPcab/Bqkw=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=C1vCqAu9nmLjLbfe7a2pryHmWTns1f2k9G3sOFUvQJ4CsBtpmrjGI1T280+M5xhnF up+eA8wSJ98Ruz8NhYlnDtiC5ljqZEPyGD7K1zL0vW7rSGlcBlNoXob2Jc2HqcVRzm vzR4llt4zCbAmF3AVGZy5zH09x5CgbaSZP2clH5Q= Received: from DLEE108.ent.ti.com (dlee108.ent.ti.com [157.170.170.38]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 19PJrd5i083033 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 25 Oct 2021 14:53:39 -0500 Received: from DLEE112.ent.ti.com (157.170.170.23) by DLEE108.ent.ti.com (157.170.170.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Mon, 25 Oct 2021 14:53:39 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DLEE112.ent.ti.com (157.170.170.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Mon, 25 Oct 2021 14:53:39 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 19PJrcWq116053; Mon, 25 Oct 2021 14:53:38 -0500 Date: Tue, 26 Oct 2021 01:23:37 +0530 From: Pratyush Yadav To: Jagan Teki CC: Marek Vasut , U-Boot-Denx , Vignesh R Subject: Re: [PATCH] mtd: cqspi: Wait for transfer completion Message-ID: <20211025195335.elcg4ujh2sfr7lhx@ti.com> References: <20210914032231.273509-1-marex@denx.de> <20210914174230.ioalzc45yq37krot@ti.com> <47ef9ee8-81f7-da64-bd90-7c282cae354c@denx.de> <20210915082821.gofegwxuagrfee5i@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 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 On 08/10/21 06:06PM, Jagan Teki wrote: > On Wed, Sep 15, 2021 at 2:05 PM Marek Vasut wrote: > > > > On 9/15/21 10:28 AM, Pratyush Yadav wrote: > > > On 14/09/21 08:22PM, Marek Vasut wrote: > > >> On 9/14/21 7:42 PM, Pratyush Yadav wrote: > > >>> On 14/09/21 05:22AM, Marek Vasut wrote: > > >>>> Wait for the read/write transfer finish bit get actually cleared, > > >>>> this does not happen immediately on at least SoCFPGA Gen5. > > >>>> > > >>>> Signed-off-by: Marek Vasut > > >>>> Cc: Jagan Teki > > >>>> Cc: Vignesh R > > >>>> Cc: Pratyush Yadav > > >>>> --- > > >>>> drivers/spi/cadence_qspi_apb.c | 17 +++++++++++++++++ > > >>>> 1 file changed, 17 insertions(+) > > >>>> > > >>>> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c > > >>>> index 429ee335db6..2cdf4c9c9f8 100644 > > >>>> --- a/drivers/spi/cadence_qspi_apb.c > > >>>> +++ b/drivers/spi/cadence_qspi_apb.c > > >>>> @@ -858,6 +858,14 @@ cadence_qspi_apb_indirect_read_execute(struct cadence_spi_plat *plat, > > >>>> writel(CQSPI_REG_INDIRECTRD_DONE, > > >>>> plat->regbase + CQSPI_REG_INDIRECTRD); > > >>>> + /* Check indirect done status */ > > >>>> + ret = wait_for_bit_le32(plat->regbase + CQSPI_REG_INDIRECTRD, > > >>>> + CQSPI_REG_INDIRECTRD_DONE, 0, 10, 0); > > >>>> + if (ret) { > > >>>> + printf("Indirect read clear completion error (%i)\n", ret); > > >>>> + goto failrd; > > >>>> + } > > >>>> + > > >>> > > >>> Huh, this is strange. I would expect the bit to clear immediately since > > >>> it doesn't really do any operation on the flash. How long does it > > >>> usually take to clear? If you don't wait for it to clear does anything > > >>> break? > > >> > > >> Often it does clear immediately, but there were a few odd cases where it did > > >> not happen right away, in which case I had transfer corruption. > > > > > > By "transfer corruption" do you mean the current transfer gets corrupted > > > or the next one? > > > > > > We get here _after_ the transfer is completed and this bit should have > > > little to do with the data received. If the current transfer fails then > > > I suspect something else might be going wrong the this is just a symptom > > > of the problem. > > > > As far as I recall, the problem was triggered when using UBI on the SPI > > NOR, so that could very well be the next transfer. > > Any further decisions here? shall I take it or v2? I think we need more information here. I don't see why checking this bit would interfere with the current transfer since that is already finished by the time we get here. If it is the next transfer then this might just be a symptom and the real problem might be somewhere else. -- Regards, Pratyush Yadav Texas Instruments Inc.