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 F0711C3DA49 for ; Tue, 30 Jul 2024 15:17:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=31C/INhkQ3HPMmc8w7jsUOn6n3AttUla78x63RCnFHE=; b=ORZLumLDHxhufBrVKO7dGXYTzK Ing3a61B/vIikSrY/yPuM3rtT19m1HOnxdSkvg1dHvqTgeAUuu6ZU6ybWzhaN49Fpig+vHztigjjt vpfTAdcyPz003YWJ70o20jCzACcY4+FFLtwGganZd9+vwGdPkAmu/SZ1lzMVJTFlsR/nOw/1JENNS vAcTmHe0sVL9jggdKiziNqsgz8Tkn5gEjyCzd4ugpRKgX4ZduzKuBVbYPeejOQOAtBjK/jnYljQAr LcISU8uUlrCam5q0c3WPse2ujnc9a+haIxeaRIHA8R7fROz9WOgqbJjBdHh0bAJwSSMHFVXdnqbse 3cu7I4XQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sYobT-0000000FdJY-3vn6; Tue, 30 Jul 2024 15:17:31 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sYoWF-0000000Fc3J-057E for linux-arm-kernel@lists.infradead.org; Tue, 30 Jul 2024 15:12:08 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 031C51007; Tue, 30 Jul 2024 08:12:32 -0700 (PDT) Received: from pluto (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C03C73F5A1; Tue, 30 Jul 2024 08:12:04 -0700 (PDT) Date: Tue, 30 Jul 2024 16:12:02 +0100 From: Cristian Marussi To: Etienne Carriere Cc: linux-kernel@vger.kernel.org, Sudeep Holla , Cristian Marussi , Michael Turquette , Stephen Boyd , arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org Subject: Re: [PATCH] firmware: arm_scmi: get only min/max clock rates Message-ID: References: <20240729065306.1210733-1-etienne.carriere@foss.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240729065306.1210733-1-etienne.carriere@foss.st.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240730_081207_135290_997DBAC2 X-CRM114-Status: GOOD ( 12.73 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jul 29, 2024 at 08:53:06AM +0200, Etienne Carriere wrote: > Remove limitation of 16 clock rates max for discrete clock rates > description. > Hi Etienne, > Driver clk-scmi.c in only interested in the min and max clock rates. > Get these by querying the first and last discrete rates with SCMI > clock protocol message ID CLK_DESCRIBE_RATES since the SMCI clock > protocol specification states that rates enumerated by this > command are to be enumerated in "numeric ascending order" [1]. > While I understand the positive optinization of not having to query the full list of clock domains in order to retrieve just min/max (that are the only interesting clocks for CLK framework), and the removal of the artificial 16 clocks limit, I would NOT drop in its entirety the original well tested code used to query the full list (based on iterators), because it will be most probably needed anyway in the future to implement determine_rate via bisection (if I udnerstood correctly what you meant in our offline chat) and because it would be needed anyway for testing purposes. IOW, why dont you do exactly what you did BUT within a new distinct scmi_describe_min_max_rates() helper, WHILE keeping the original code scmi_clock_describe_rates_get() unchanged, and start calling your new method at init to retrieve only max/min ? So that we can attach anyway (now or then) a new 'lazy' ops to the old method and use it to retrieve the full list of clocks when needed (for testing or whatever). Thanks, Cristian