Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3077009pxb; Mon, 24 Jan 2022 01:44:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJyXXpv5OBXhZ20w8pC6/dY3Pa8G1KnrLYq2naG+cXoTDACC0MCmA4BQq5JD2xMprsYQhAGc X-Received: by 2002:a17:902:ea0d:b0:14b:4c26:f42f with SMTP id s13-20020a170902ea0d00b0014b4c26f42fmr4094747plg.125.1643017455137; Mon, 24 Jan 2022 01:44:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643017455; cv=none; d=google.com; s=arc-20160816; b=KyPtPxLO5rNqrgHqiOsf92G6aR72x/fduaFm98wkS4NXdeSsRBMCIi2ZBqhm+Ze+qx M3MIliKF7b57WQ3z6zRLFZjpbOk/kRIibizujjxLrw5m2TPqPmu9ql6e+V06rlXXudTj Gt2m8g/0H3o94mIM3P236Rh25mOIEEWRsljx10s62O/Lgl9/0mwBql5eVrKxGxVj+rxS e/TWpw4KrgElsZqE9kmpEp4bxkbWAR0A1KxOJBYKMw+caUqLJMvRwEolAUqXz3gww3dB M6Wx1+EDiFz2K82jIzVRSNOmeSyxGhJtxOF8+5HcB3Tqym9SyG9zsUmdbtV4IumPdlqP 6wzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=BEZDLA38rmz3jKUQhU+SlHZeu6Bm5+FZMa3GzCHJl9Y=; b=uC0kJpTrWhYrFu4ufMAL7ZdhISzubNYTfm6Qv2g32Dt7jzZUrnoE4vCWPMgCUlaITS 7vYGjZUTsalNau1cs5K6gym8TS+ZIm/9vGIRDn5dUHkPxEvaDivva/c5X9r6YM/ERILL WocNLdpOwT8NAXixcgocbOzDWJjtvk6MicrY58Eq9eJQfNwNgfb9ZyLHWiIFzWoT4RBD zi35+DgypNIodS26jOpe6zBBMvxOecq1C/GpSHpRxicgR/12BVZ2TjcJvKkyRg4pcOLH bY9huSDOZwUfbRjbCP8FfB2ZhH/CGZMO7PTTWwKN2y4JOEfBSPKOcYoNdkmwsaBw1qJ0 QGLg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rm9si12731741pjb.26.2022.01.24.01.44.03; Mon, 24 Jan 2022 01:44:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237911AbiAWPjo (ORCPT + 99 others); Sun, 23 Jan 2022 10:39:44 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:56145 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237913AbiAWPjn (ORCPT ); Sun, 23 Jan 2022 10:39:43 -0500 Received: (Authenticated sender: miquel.raynal@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 69B2560003; Sun, 23 Jan 2022 15:39:41 +0000 (UTC) From: Miquel Raynal To: Dario Binacchi , linux-kernel@vger.kernel.org Cc: Miquel Raynal , Michael Trimarchi , Sascha Hauer , Han Xu , Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org Subject: Re: [PATCH 3/4] mtd: rawnand: gpmi: validate controller clock rate Date: Sun, 23 Jan 2022 16:39:41 +0100 Message-Id: <20220123153941.673301-1-miquel.raynal@bootlin.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20220118095434.35081-4-dario.binacchi@amarulasolutions.com> References: MIME-Version: 1.0 X-linux-mtd-patch-notification: thanks X-linux-mtd-patch-commit: b'15e27d197a7ea69b4643791ca2f8467fdd998359' Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2022-01-18 at 09:54:33 UTC, Dario Binacchi wrote: > What to do when the real rate of the gpmi clock is not equal to the > required one? The solutions proposed in [1] did not lead to a conclusion > on how to validate the clock rate, so, inspired by the document [2], I > consider the rate correct only if not lower or equal to the rate of the > previous edo mode. In fact, in chapter 4.16.2 (NV-DDR) of the document [2], > it is written that "If the host selects timing mode n, then its clock > period shall be faster than the clock period of timing mode n-1 and > slower than or equal to the clock period of timing mode n.". I thought > that it could therefore also be used in this case, without therefore > having to define the valid rate ranges empirically. > > For example, suppose that gpmi_nfc_compute_timings() is called to set > edo mode 5 (100MHz) but the rate returned by clk_round_rate() is 80MHz > (edo mode 4). In this case gpmi_nfc_compute_timings() will return error, > and will be called again to set edo mode 4, which this time will be > successful. > > [1] https://lore.kernel.org/r/20210702065350.209646-5-ebiggers@kernel.org > [2] http://www.onfi.org/-/media/client/onfi/specs/onfi_3_0_gold.pdf?la=en > > Co-developed-by: Michael Trimarchi > Signed-off-by: Michael Trimarchi > Signed-off-by: Dario Binacchi > Tested-by: Sascha Hauer > Reviewed-by: Sascha Hauer Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks. Miquel