Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp2114585imw; Tue, 5 Jul 2022 23:42:35 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uzei7yHebxLXr842VYcMPRNEEO9ko8xwrvTF6e+JebvHQpM8oJ71S9zxUJLGThPf6K+YLX X-Received: by 2002:a05:6a00:80d:b0:525:520a:1736 with SMTP id m13-20020a056a00080d00b00525520a1736mr44470430pfk.36.1657089754932; Tue, 05 Jul 2022 23:42:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657089754; cv=none; d=google.com; s=arc-20160816; b=0K0kMPFiQA4Y/aIa0TDMHvXnSY6k/6YZ6HZT4O48qDq/UHiD+GTEmymhNd9ehedeeg YGJPZU/G/jnpjzQpRbDXlenY16SeDSnTiSx++gXnXEKMtacanReJ2dwH1G69ZsLbr2T7 o2kIELcVy+QWQaRKXX3OhyUTV9c5a1FruMGRxB08T91U3crzkLnZPAajaEyPHHEzZ/sI tiapd+MKFipo2IepZ95wsQiCpn5kLkw/zymHK9ot+G41ELuKNLOdcRt/ppbFzkzSVP9B PVPcoHVSWZHOqmmtKQ9sQjNufuTTuQI3ghS71tMeCO8ywRJi4Alpa+LIyhgGYYz9Ble2 icBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=vRmDjPpc1ypdcneiWKEOt2A9rTdMJLx78Cgy5W5981I=; b=JArg0TnFPNt2gyeUF2WMsojGF9GzapyfdpAMOcOIGTzew40YH4AdBz7Yir/qFB+l3w u/rHoZ343CovlzIZmkZmJYdSIAXEEpKwG+cyUXG6/2SFaBzW3UZRnr1hgBz2z6rfdnYB 65oJHtB6AkJShOI7o4MNf003RwSi7CMwgRKlvE1xAHuKBQe4dI3c3U0qjwCGJ02ISN+p ec7+MYzpMKJUkEacrO3tQEWjo7qu0Kzxx28ry8n/4ohg7RwrluMyMfpmLATsSGjFDwT+ LxV/HqwsvpSQs+dn8GydwQyHePGDUc0GgBMBAK9qhScZRoKhwXBZc0ZkipzL7292OkXZ qcZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=n2H4gCde; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q84-20020a632a57000000b003c1725602b4si47450693pgq.627.2022.07.05.23.42.22; Tue, 05 Jul 2022 23:42:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=n2H4gCde; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229949AbiGFGjw (ORCPT + 99 others); Wed, 6 Jul 2022 02:39:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229793AbiGFGju (ORCPT ); Wed, 6 Jul 2022 02:39:50 -0400 Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74837167CA for ; Tue, 5 Jul 2022 23:39:49 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id y141so13524483pfb.7 for ; Tue, 05 Jul 2022 23:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vRmDjPpc1ypdcneiWKEOt2A9rTdMJLx78Cgy5W5981I=; b=n2H4gCdeHo2gNaIplHcteu9pNdBzHjiMsZ3HktbeujIfTSTHZOIp8M6i9KFOS/7tGo AGG0KWlbosrHRn6oXOB/3NXtAS+fw9ucxy3MMKMh7JmCZg+NF4fPZmECERwUugcbmlDG Q7qY6Y+kcP11LhpO5z553sCkV53YQkExlJ11RGhbVaIQoVwnWCVogdPDpK9YDveaJ2B8 QBlZx1dToQ1uDdrjAXV9eEueKGMNKaDenn9rpgJBPtPCdF3X4cobBb7piYAfPKkYQIS6 LW+2XO6gTYgy77S3O/VFScec0XhN8bNR6S24/06C49uV0i/xvXtEO2cLsZ0TikvoYaWd HUoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vRmDjPpc1ypdcneiWKEOt2A9rTdMJLx78Cgy5W5981I=; b=B1dXg/EoGO0S89Wbi8UoEe04CzspOSTQJ64Vl5MKfmYfvQs4XXc9fA89e+znEvHznQ wcfcPSaaLaBr0xxrfrctGy6iEzqIZ2m7UIbRMKxlaSHdAdP7c4xXUE+vnvrZIfn1tqUI m2NElU6AcE90xTXltfkjzEezSxhj6b12fTphXFV86sWIc+C34RRp+sGbFVkmaEuyuCkF wbZQbDeAZQS7u5U6sXaYznfI6huM57vP6BHg+DynGWib0xwrXsc9zKYiXmXxTk83FngF Rjm4buGIo7caEwIaPZR43n3gMvDsX6lkMuH4dqFOeC1+gcJeNAexUvXsupqVw4NaaA22 Ih1A== X-Gm-Message-State: AJIora8lP0cLb27LMTSizSXHvf0sV2dAzefRDw3HJGIbPRA80d6/g0/7 KlsiVw0ONS2MWSCrAT8RVSg7SQ== X-Received: by 2002:a65:42cc:0:b0:3a9:f71f:33f9 with SMTP id l12-20020a6542cc000000b003a9f71f33f9mr32966547pgp.391.1657089588947; Tue, 05 Jul 2022 23:39:48 -0700 (PDT) Received: from localhost ([122.171.18.80]) by smtp.gmail.com with ESMTPSA id br10-20020a056a00440a00b0051c2fc79aa8sm24619356pfb.91.2022.07.05.23.39.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Jul 2022 23:39:48 -0700 (PDT) Date: Wed, 6 Jul 2022 12:09:46 +0530 From: Viresh Kumar To: Krzysztof Kozlowski Cc: Viresh Kumar , Nishanth Menon , Stephen Boyd , linux-pm@vger.kernel.org, Vincent Guittot , "Rafael J. Wysocki" , Dmitry Osipenko , linux-kernel@vger.kernel.org Subject: Re: [PATCH V2 09/13] OPP: Assert clk_count == 1 for single clk helpers Message-ID: <20220706063946.pmtkwiyfzxx5ka7h@vireshk-i7> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05-07-22, 19:21, Krzysztof Kozlowski wrote: > Where is the safety problem with multiple-clocks case? All these APIs, which I have added the assert to now, are designed with a single clk/freq in mind. They simply take a clock frequency value as input and do something based on it. It only works fine with single clk case, as more information is required for multiple clock case, a freq value isn't sufficient here. In order to avoid abuse or accidental use of the wrong API, these WARNs were required. > And how users of PM OPP API are supposed to iterate/find OPPs they > want if the API now throws WARN? We need to provide new APIs for that, as I mentioned in the cover letter and the other mail I sent you yesterday. Specifically, if we want to have OPP finder API based on freq value, then it needs to either have index + freq as input, or an array of frequencies (one for each clk) as input. Though I am not sure what you would need at the moment, as you can also use opp-level for OPPs as they match UFS gears, that was my understanding from earlier discussion. -- viresh