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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26369C001DD for ; Thu, 13 Jul 2023 05:53:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233836AbjGMFxv (ORCPT ); Thu, 13 Jul 2023 01:53:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233761AbjGMFxv (ORCPT ); Thu, 13 Jul 2023 01:53:51 -0400 Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61BDF1FD6 for ; Wed, 12 Jul 2023 22:53:49 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-3a3b7fafd61so339918b6e.2 for ; Wed, 12 Jul 2023 22:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689227628; x=1691819628; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=G9WcmhiPaDbhClEKCeWjVz4d9o3HB8tMobRvLpjiDVg=; b=B5YypG0ak4I6Rre7Vqs3E1Pr4Ekj9PUrVbecN4P8RA4VkXvK7AVN4d7Bl0r0LXBkrC 7UFLElNs0AxAziZt7hH98hh3DZM2pLvypWlCwmD16dwYLHM49KNGaFVGQ6+fM/OY2Uk0 TP57kZ+3OhRvgZPry5T13l9pRaPdOA47Hbmp7yzhc2pwDixLqJJSeAXwolDl7LCO3R/L JWXN0kgKaL3+aFNity2FUAGMpq7aV7lN8QzH5F7IKTHpO1jBgCpQrjfQxDidf1rCTQqH YPtM7osnmbwykT0fnqqXaq/IkR3z8G0cJYW0hPoB50TcCAZTe6nsbhvOaHiojkxZRfp4 N+nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689227628; x=1691819628; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=G9WcmhiPaDbhClEKCeWjVz4d9o3HB8tMobRvLpjiDVg=; b=F4VIsFfmOy4XUULtjdRmV5zOvpOYa6Qq0yTf1UEFyTFIhQ3C5BOQZyPTYv3STH9Ggn +6nHMoH6pLMafPOC9G51bEtsE+CYEkBMdmZAPnz2ix4fXp4BaVb7oimG6PROadfn0ati TRT5bkgFgj649Rvtu5rDlm6rsNG42h5KmiieSgqmsN17vGZRfmEp4RfE7tkK7uYLAUza /U7fN+ENIMVjM1u2ysyAf/p+4HUcvyM7DozzFKtjR/7L/TAR3WPumqfRisP8IVbfbnhb azzFOPPzXg5vOk3qDz20wpkV3bXIpYd0zh4TUttskExvD0AqxX4az7BlIJgHWaQDq1Ey gJYg== X-Gm-Message-State: ABy/qLb6UBLc+S0Tj8iMpP9wXXa6YJ0GVfnDnsmAMhXwwNoEImTeYxXq oOrAwOHVRg0vgkKNSwSZW0X4 X-Google-Smtp-Source: APBJJlEtSDOcLFFSsaVra3MhJEI2q1v/jqoFG4/1vf56Y3Q/69961njV+QB/qijFLB5voGRWjtEFWg== X-Received: by 2002:a05:6808:1153:b0:3a0:3a17:a146 with SMTP id u19-20020a056808115300b003a03a17a146mr839218oiu.57.1689227628648; Wed, 12 Jul 2023 22:53:48 -0700 (PDT) Received: from thinkpad ([117.207.27.112]) by smtp.gmail.com with ESMTPSA id c2-20020aa78c02000000b00673e652985bsm4552692pfd.118.2023.07.12.22.53.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Jul 2023 22:53:48 -0700 (PDT) Date: Thu, 13 Jul 2023 11:23:29 +0530 From: Manivannan Sadhasivam To: Viresh Kumar Cc: Dmitry Baryshkov , vireshk@kernel.org, nm@ti.com, sboyd@kernel.org, myungjoo.ham@samsung.com, kyungmin.park@samsung.com, cw00.choi@samsung.com, andersson@kernel.org, konrad.dybcio@linaro.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, quic_asutoshd@quicinc.com, quic_cang@quicinc.com, quic_nitirawa@quicinc.com, quic_narepall@quicinc.com, quic_bhaskarv@quicinc.com, quic_richardp@quicinc.com, quic_nguyenb@quicinc.com, quic_ziqichen@quicinc.com, bmasney@redhat.com, krzysztof.kozlowski@linaro.org Subject: Re: [PATCH 11/14] scsi: ufs: host: Add support for parsing OPP Message-ID: <20230713055329.GF3047@thinkpad> References: <20230712103213.101770-1-manivannan.sadhasivam@linaro.org> <20230712103213.101770-14-manivannan.sadhasivam@linaro.org> <20230712163406.GG102757@thinkpad> <20230713040918.jnf5oqiwymrdnrmq@vireshk-i7> <20230713050550.GB3047@thinkpad> <20230713051235.ob5z3li3lz52xtzm@vireshk-i7> <20230713052843.GE3047@thinkpad> <20230713054302.tu6fgd3meb5krsx5@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230713054302.tu6fgd3meb5krsx5@vireshk-i7> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, Jul 13, 2023 at 11:13:02AM +0530, Viresh Kumar wrote: > Okay, sorry about missing one point first. I thought we are adding the > clk config callback (which neglects 0 frequencies) to a Qcom only > driver and so was okay-ish with that. But now that I realize that this > is a generic driver instead (my mistake here), I wonder if it is the > right thing to do anymore. > That's the pre-opp behavior as well. Reason is, most of the platforms have only gate clocks supplied to the ufs controller and cannot change the frequency. Only Qcom requires changing the frequency of _some_ clocks, so that's why we have to use this hack of skipping 0 freq clocks. > On 13-07-23, 10:58, Manivannan Sadhasivam wrote: > > On Thu, Jul 13, 2023 at 10:42:35AM +0530, Viresh Kumar wrote: > > > On 13-07-23, 10:35, Manivannan Sadhasivam wrote: > > > > We can settle with this custom callback for now. If there are drivers in the > > > > future trying to do the same (skipping 0 freq) then we can generalize. > > > > > > Just for completeness, there isn't much to generalize here apart from > > > changing the DT order of clocks. Isn't it ? > > > > > > > Even with changing the order, driver has to know the "interesting" clocks > > beforehand. But that varies between platforms (this is a generic driver for > > ufshc platforms). > > > > And I do not know if clocks have any dependency between them, atleast not in > > Qcom platforms. But not sure about others. > > Maybe this requires some sort of callback, per-platform, which gets > you these details or the struct dev_pm_opp_config itself (so platforms > can choose the callback too, in case order is important). > Yeah but that seems overkill since the current config_clks helper satisfies the requirement. - Mani > > > The change require for the OPP core makes sense, I will probably just > > > push it anyway. > > I tried to look at this code and I think it is doing the right thing > currently, i.e. it matches clk-count with the number of frequencies in > opp-hz, which should turn out to be the same in your case. So nothing > to change here I guess. > > -- > viresh -- மணிவண்ணன் சதாசிவம்