Received: by 2002:a05:7412:251c:b0:e2:908c:2ebd with SMTP id w28csp2632433rda; Wed, 25 Oct 2023 08:10:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHkJ1/icX7SvkDC/S1iNzc4pxCuYw5npue1uqEzkjrJW4C4betxL60jVFTQTIK/d9jeyMTA X-Received: by 2002:a05:6808:144d:b0:3b2:dcff:9e54 with SMTP id x13-20020a056808144d00b003b2dcff9e54mr21471410oiv.24.1698246602730; Wed, 25 Oct 2023 08:10:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698246602; cv=none; d=google.com; s=arc-20160816; b=uqb97IZKMSwNRL6iytn9vGGSyLzZZUXtnZNXDIJNCCJleEiP0wSwmsfZuaP2qBILu4 gFS9ByymkE9K/lxOFRM9/EdyHoTqnM3uks5EgWlZVJe91TJkMoqMLhKhLETp6dZWbyyo SuGXLirfGXRoLAQojh9c/i4M35Mo/YQKwSKSlBXd0r9XXw2Dtd8e42uZohmPHPAGcIwE +MfZxtIvt1Kt6toE5OTQHvGeilgToAV3O0rFJyib5jUY6YcEgTN7v7oNmP/59AcHDB/h 5eB4xDCrRkvd2RBRuXYg2J0E+tS+7CC3tH/RmIrLqQMnxJx/xp6DiGfBygihrv2IrJ3L E/Pg== 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=3i4q/8dh08pTSJ6aN+GctK8CWDUW91sqoqWG/NbmAao=; fh=6cdCmJ4bXgPNW66wND+DDTrdwJtoZLeSQHNsEywQNm4=; b=wyilblU8vpYzXJelgXEMVHPIDpN09Nu7RQAezkbkXPl4mGGgKFz/JsNB6tC+Du+37u EeF2Z16sdJN6zFMBomTW19wNFrKEfzSVLcl+TqAGE/DL6CsAcCQwWYCNX4XDQ7sfisdo 2/9Ks6fNEKNKU7eNaytMWSvh+wHLHK/0Hl/fBdZ3xJxKQ8J0Un14v8b/6Zk6gze24oO3 pomJRUrtzuHSr3Lp8shhv3cAdmEGyAzlpmHhC8PUCznkqVG7IHKhkOXR2JKtCEojIyQg MCkZ6HFwfUOLLYMabi0qpJN3PqkWdy+rE/uXxcXDHNxvOaY9HO1UH2tvQq3uoT0Z0dq0 0kPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=NNicel3A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 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 howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id b199-20020a25cbd0000000b00d9a3bbb7f6fsi11467259ybg.424.2023.10.25.08.09.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Oct 2023 08:10:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=NNicel3A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 380B880597BF; Wed, 25 Oct 2023 08:09:57 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234960AbjJYPJv (ORCPT + 99 others); Wed, 25 Oct 2023 11:09:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234214AbjJYPJu (ORCPT ); Wed, 25 Oct 2023 11:09:50 -0400 Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABCF1138 for ; Wed, 25 Oct 2023 08:09:47 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-1c9bf22fe05so39072035ad.2 for ; Wed, 25 Oct 2023 08:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1698246587; x=1698851387; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3i4q/8dh08pTSJ6aN+GctK8CWDUW91sqoqWG/NbmAao=; b=NNicel3AXdCU+YO/0saf/OlSPvhOe9cpmOFr2wbjF5fRxZuy3mimDgLhPHWTzPJZay yFLo4lu3ljLIlp6PhAEiY2pHhLVISwQVaeE71m1ciqnRdiOtYo3DlGdfK2MjUGgok427 HGMSd2sx+tri2xWiJo01VeUQDMPBd0opabiwvo1+nNYn6eJtsAPkH1YHsBzGFVsan3Rm 2KsxehgdmftOHCmJPWZY8DD0fuBkNq6IGhOh94Kbg6GOMBU1bVOeJKUTT2oMsRifwNHH 8lG+z75P4P6AWVRCZji8TK6krVHg9cKfsw0LJBZE7jWoQnZRHyrfoWMyq2fceuxn0VP9 1FzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698246587; x=1698851387; h=in-reply-to: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=3i4q/8dh08pTSJ6aN+GctK8CWDUW91sqoqWG/NbmAao=; b=qHrKkR6xj+6WAbwZqq/wQb0qG+fgyQ5TGP1f1ZHGCNPu8G+qsDwcQgadtGXDFa2Kej RN7Y2jmiSCjZC+lfoesqAGaU19ykoiEVTdgoIsD9Gfla7Uw7jSc5WCUBC7RUyUClFn6b fqgQWvBcxtVfbKubhYfkhKh0lecGof7YdUH3WTn5BNBr7fg2BpIsPKcRxw9CMf+f/J3a JF/kZWJLD+uS493nyNnRJceuVReh5gqaOmb2fOo6Hc/IrNnFTo8p2ESlHNFK3iXWpenD AraXckcrdq+5nYNZ+Flym/IpweJRz96YmbSgm3x1ZGGaJh6A8xxy+r6Bxk6KKjAxHOUs FY+g== X-Gm-Message-State: AOJu0YyNMB/AH5M2OxfyzkDgpOX8RrIXJXaPxRugHJHRvmBg8V1npXJD d3akbBP4i3Qfka78zLgxDq4/Rw== X-Received: by 2002:a17:903:1246:b0:1c8:7d21:fc63 with SMTP id u6-20020a170903124600b001c87d21fc63mr13200813plh.56.1698246587035; Wed, 25 Oct 2023 08:09:47 -0700 (PDT) Received: from localhost ([122.172.80.14]) by smtp.gmail.com with ESMTPSA id h4-20020a170902eec400b001c9cc885022sm9310654plb.259.2023.10.25.08.09.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Oct 2023 08:09:46 -0700 (PDT) Date: Wed, 25 Oct 2023 20:39:44 +0530 From: Viresh Kumar To: Ulf Hansson Cc: Viresh Kumar , Nishanth Menon , Stephen Boyd , "Rafael J. Wysocki" , linux-pm@vger.kernel.org, Vincent Guittot , Stephan Gerhold , Konrad Dybcio , Manivannan Sadhasivam , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] OPP: Call dev_pm_opp_set_opp() for required OPPs Message-ID: <20231025150944.b2noxaznyqltehhf@vireshk-i7> References: <6de4fcb5bb943a131d0cdf0a858bd35af02a2f88.1697710527.git.viresh.kumar@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Wed, 25 Oct 2023 08:09:57 -0700 (PDT) On 25-10-23, 15:51, Ulf Hansson wrote: > On Thu, 19 Oct 2023 at 12:22, Viresh Kumar wrote: > > -static int _opp_set_required_opps_genpd(struct device *dev, > > - struct opp_table *opp_table, struct dev_pm_opp *opp, bool scaling_down) > > +/* This is only called for PM domain for now */ > > +static int _set_required_opps(struct device *dev, struct opp_table *opp_table, > > + struct dev_pm_opp *opp, bool up) > > { > > - struct device **genpd_virt_devs = opp_table->genpd_virt_devs; > > + struct device **devs = opp_table->required_devs; > > int index, target, delta, ret; > > > > - if (!genpd_virt_devs) > > - return 0; > > Rather than continue the path below, wouldn't it be better to return 0 > "if (!devs)" here? I can add that optimization, moreover it would make the code simpler to read. > > @@ -2429,15 +2374,10 @@ static int _opp_attach_genpd(struct opp_table *opp_table, struct device *dev, > > int index = 0, ret = -EINVAL; > > const char * const *name = names; > > > > - if (opp_table->genpd_virt_devs) > > + /* Checking only the first one is enough ? */ > > + if (opp_table->required_devs[0]) > > The allocation of opp_table->required_devs is being done from > _opp_table_alloc_required_tables(), which doesn't necessarily > allocate/assign the data for it. > > Maybe check "opp_table->required_devs" instead, to make that clear? Hmm, the expectation here is that if someone has called the config routine with genpd option, then required OPPs must be present and so required_devs won't be NULL. What instead we are looking to check here, and later in _opp_set_required_devs(), is if this operation is already done for a group of devices. The OPP table is shared, for example, between CPUs of the same cluster and the OPP core supports the config routine getting called for all of them, in a loop. In that case, we just increase the ref count and return without redoing stuff. That's why we were checking for genpd_virt_devs earlier. Though interfaces and things have changed several times, I may need to check it again to make sure it all works as expected. > > +static void _opp_set_required_devs(struct opp_table *opp_table, > > + struct device **required_devs) > > +{ > > + int i; > > + > > + /* Another CPU that shares the OPP table has set the required devs ? */ > > Not sure I fully understand the above comment. Is this the only > relevant use-case or could there be others too? Answered above, but I shouldn't write CPU here anymore. We support all device types now. > > + if (opp_table->required_devs[0]) > > Maybe check opp_table->required_devs instead? > > > + return; > > + > > + for (i = 0; i < opp_table->required_opp_count; i++) > > + opp_table->required_devs[i] = required_devs[i]; > > To be safe, don't we need to check the in-parameter required_devs? I left it like that intentionally, in case someone wants to skip the required dev for some required OPP, while make all others change. But maybe I will keep it simpler and check it all the time. > Or we should simply rely on the callers of dev_pm_opp_set_config() to > do the right thing? > > [...] > > Besides the minor things above, this looks really great to me! Feel free to add: Thanks. > Reviewed-by: Ulf Hansson -- viresh