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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C6029C64EC4 for ; Thu, 9 Mar 2023 15:57:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:To:Subject:MIME-Version: Date:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=zjT7e7rn8MSbeE/WGnPyxlERWelwdELfvFe+EtfOVEA=; b=vB8+2q0rIlCUcpWEcG106HlM9q 363QLxAQNZCmMbqADNYffbmrB8WvLgR+ZnrDYpJGjsXD+NQOOHjk4AobM0yai24SwNhAukT3FwUKp m3uuyRA9HwEOpy1wi9j9ofOUG+t7eL9L6mZ2A11sIPP635hO9EgWiB6GrXtIE15Q8vXxzeUertU/M t9oMmffJ/QRuM7emVl3jnBrlV8jenlFYQU7adkbnsi9ccjA5aHj9iPYu3NlQWo6+WcSi3LEVoqtgF 2OsFeUl56j9/kr/c6o7h7v+U7IFBwM9z3kbb9tDcySkBmgh0QzrqiGoO+kzzogtqcda1EWN2mTqMU FC/1YFWA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1paIco-00B4qz-GN; Thu, 09 Mar 2023 15:56:15 +0000 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1paIOH-00Ayde-5F for linux-arm-kernel@lists.infradead.org; Thu, 09 Mar 2023 15:41:16 +0000 Received: by mail-wm1-x32c.google.com with SMTP id m25-20020a7bcb99000000b003e7842b75f2so1504339wmi.3 for ; Thu, 09 Mar 2023 07:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678376469; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=thHKQQTXmNqo7+agzCDK9DfO3aLKYlwKu3AriL3BjPg=; b=gJ2r1RFLFeBfkIT/MugmSb5mkRuueMrpeZW9ljS6WJwcDSNGf609jDWEGhUDaHEezx cZ2rzK8O84Ns9L3RtlsXsMJRPxISQd1EIm/PK9KtKi5sy/DnsXChGUZ+rDKG6diE8pR1 bvqxe64DPNRU+Y3LVE795yrOjPTh/8LMBVj/AFkzsYU6KDhfcV18n1doWjxTyXqEyBrA xdb5EG61TWJtW1P5i7IQkl6EAZy5htVaEvuJJZhD92utvd6odYUZwwcIcRg7H2ZYWCkt sN8F8s+f/2dKAKUwUrpJ19SobSCbYCghvKAu424U1Jj7fh2YzZxH3g7DP6XiW1U2c1T/ LT1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678376469; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=thHKQQTXmNqo7+agzCDK9DfO3aLKYlwKu3AriL3BjPg=; b=g3olW10g2+YeE7trjpN8fKmsRa1WzYxa1ynX/FOY9q8x86jTl4BXk+QFSPORrJ45mY a/2k5AMBk1YeTS0Mf6JYCvnuS+2HNPjUDXTrZJ+sKJ7bmpP9mW2EYPhh71pdJMY81Bu6 CaxeX1LCKqruDLs1M+vsODsK+7K5ivWGfRISvFTB3k3WwquNg5lURe2OiQ8pVf6F4jTC OA9rJJ0TnBPqMpyxqnTZUu2V/JfHGLSKCq7dsOh7Vdt1uAI0+4/TYycHSz5b0OyVFDZc 8LwJKOpflIkBnvDRu7rrevwcPlPdLej5OidI71kPFEdtXfLYk4qJ9VkoF+0eNj1h/Mz0 p/AA== X-Gm-Message-State: AO0yUKU0xnw2D61LLPsXHKIfdj8i6ty5n5Q7fNh+nbiLbmnuWn/jO62Y 5/tU7W124CHhkDxgaF8cu5cfhA== X-Google-Smtp-Source: AK7set85qnSSVIK+/VfxFa63URER6rmyYNQB/XVwahWExbs8/RUsgm9XOIYiq9V5NrA4EQ+yUhQcHA== X-Received: by 2002:a05:600c:4ecf:b0:3eb:399d:ab1a with SMTP id g15-20020a05600c4ecf00b003eb399dab1amr19180672wmq.21.1678376469612; Thu, 09 Mar 2023 07:41:09 -0800 (PST) Received: from [192.168.0.173] ([79.115.63.78]) by smtp.gmail.com with ESMTPSA id 18-20020a05600c229200b003dc4a47605fsm257344wmf.8.2023.03.09.07.41.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Mar 2023 07:41:09 -0800 (PST) Message-ID: <99ff644b-7734-44a4-6b3e-493dab843334@linaro.org> Date: Thu, 9 Mar 2023 17:41:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH] spi: Replace `dummy.nbytes` with `dummy.ncycles` Content-Language: en-US To: Michael Walle References: <20220911174551.653599-1-sergiu.moga@microchip.com> <20220925220304.buk3yuqoh6vszfci@mobilestation> <18e6e8a8-6412-7e31-21e0-6becd4400ac1@microchip.com> <20220926172454.kbpzck7med5bopre@mobilestation> <1766f6ef-d9d8-04f7-a6bf-0ea6bc0b3d23@linaro.org> <1849e2c8-54f5-9e56-4ed8-8b0e4a826d04@linaro.org> <302ecf0421fe4c99fca3eb0ca2f66127@walle.cc> <5183a184-c72d-3acd-70cd-6aa1e31533f5@linaro.org> <03a9f117316ab81f1b5a18100f771e65@walle.cc> <6c2090bf-d102-a333-3a83-03abe81ff70e@linaro.org> <460ef5ff3846b409b322ca53559e2476@walle.cc> From: Tudor Ambarus In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230309_074113_284411_5FE23D59 X-CRM114-Status: GOOD ( 18.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alexandre.belloni@bootlin.com, vigneshr@ti.com, linux-aspeed@lists.ozlabs.org, alexandre.torgue@foss.st.com, tali.perry1@gmail.com, linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com, linux-spi@vger.kernel.org, michal.simek@xilinx.com, tmaimon77@gmail.com, benjaminfair@google.com, kdasu.kdev@gmail.com, richard@nod.at, chin-ting_kuo@aspeedtech.com, Sergiu.Moga@microchip.com, haibo.chen@nxp.com, openbmc@lists.ozlabs.org, yuenn@google.com, bcm-kernel-feedback-list@broadcom.com, joel@jms.id.au, yogeshgaur.83@gmail.com, linux-rockchip@lists.infradead.org, Tudor Ambarus , john.garry@huawei.com, Mark Brown , linux-mediatek@lists.infradead.org, clg@kaod.org, matthias.bgg@gmail.com, han.xu@nxp.com, linux-arm-kernel@lists.infradead.org, andrew@aj.id.au, venture@google.com, linux-stm32@st-md-mailman.stormreply.com, heiko@sntech.de, Serge Semin , linux-kernel@vger.kernel.org, avifishman70@gmail.com, mcoquelin.stm32@gmail.com, Claudiu.Beznea@microchip.com, Pratyush Yadav Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 09.03.2023 16:01, Michael Walle wrote: > Am 2023-03-09 14:54, schrieb Tudor Ambarus: >> On 09.03.2023 15:33, Michael Walle wrote: >>>>>> The controllers that can talk in dummy ncycles don't need the >>>>>> dummy.{buswidth, dtr} fields. >>>>>> >>>>>> The controllers that can't talk in dummy cycles, but only on a "byte" >>>>>> boundary need both buswidth and dtr fields. Assume a flash needs 32 >>>>>> dummy cycles for an op on 8D-8D-8D mode. If the controller does >>>>>> not have >>>>>> the buswidth and dtr info, it can't convert the dummy ncycles to >>>>>> nbytes. >>>>>> If he knows only that buswidth is 8, it will convert ncycles to 4 >>>>>> bytes. >>>>>> If dtr is also specified it converts ncycles to 2 bytes. >>>>> >>>>> No they don't need it. Lets take your semper flash and assume it needs >>>>> 12 latency cycles. SPI-NOR will set ncycles to 12 *regardless of >>>>> the mode >>>>> or dtr setting*. The controller then knows we need 12 clock cycles. >>>>> It has >>>>> then to figure out how that can be achieved. E.g. if it can only do >>>>> the >>>>> "old" byte programming and is in quad mode, good for it. It will >>>>> send 6 >>>>> dummy bytes, which will result in 12 dummy clock cycles, because 1 >>>>> byte >>>>> takes two clock cycles in quad SDR mode. If its in octal mode, send 12 >>>>> bytes. If its in dual mode, send 3 bytes. Obiously, it cannot be in >>>>> single bit mode, because it cannot send 1.5 bytes.. >>>>> >>>> >>>> You miss the fact that you can have 1-1-4. What buswidth do you use >>>> for dummy, the address buswidth or the data buswidth? >>> >>> Doesn't matter, does it? The driver is free to chose, 1, 4, or anything >>> else. You don't sample any data during the dummy phase. >>> To answer your question: single for instruction, single for address, >>> whatever you choose for dummy as long as there are ncycles space between >>> address and data, and quad for data. >> >> Huh? How does the controller chose, based on what? > > Based on its own capabilities. It can choose either way. In the end Okay, I'll go again through all the spi controllers and check if we can determine the dummy nbytes based on controller caps. Thanks! > what matters is how many clock cycles there are between the address > and data phase. And you only need to convey that information to the > SPI controller - your new ncycles. > > -michael > >>> Depending on the capabilites of the hardware it will likely be 1 or 4. >>> >>>> What happens if crazy protocols like 1S-1S-8D appear? What buswidth >>>> and transfer mode are you going to use for dummy? >>> >>> Also doesn't matter. What matters is how many dummy clock cycles you >>> do. Again, they don't depent on the mode. You just have to count >>> the clock cycles between the address and the data phase (and that is >>> what your ncycle parameter will tell the controller). >>> >>>> And please don't tell me that "we're going to assume that >>>> dummy.buswidth = address.buswidth because that's what we currently do >>>> in SPI NOR", because I'm not convinced that the assumption is correct. >>> >>> No, it doesn't matter :) >>> >>> -michael _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel