Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp10649171ybi; Thu, 25 Jul 2019 03:03:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqyExU5An/n/ooS/31TyNEo8kRg/u/O0ymrqq1bLrd6izoUJ2d4fsw0nQ9199pqA4Y+RVifv X-Received: by 2002:a63:4404:: with SMTP id r4mr84337154pga.245.1564048991306; Thu, 25 Jul 2019 03:03:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564048991; cv=none; d=google.com; s=arc-20160816; b=XQptCgaYbDU+zg2O70uS97PET3TBXy8hQ3tvVPzW2LxaYA9QLwoCu/WBKjzQaUjsad 5TlXlIHukd8Mkb4DXveZBNeGuQiMo2EsGfdLW516e+Gca1k1AqozQOrdNH9vFMY8FEZ5 ErlnxKp0WkREupQ1XkwjIhdxTIpNur6/t1NoIAe3zq0Z2pQYZsYukY2gDGt0ShF649zN N90Mg+3AdEUg7hId4ckctIdRfW4GQGuKUIM6WMAHcyRXv3o67+N2daAZh/7pFOqzbfvR sAQHGNHVNTs742HvpvPpoN+hpkUpXZz3l3/m7KSWOM73XOMeF5i3qAu7HyEhITuDei1q gQdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=aMjIeeabzA2glm2FgNQ5GnaE3BxUhRtGgmqv9hcezQY=; b=moFWRaLA6OdmK2wDSMMM3LLXnOyw12SScxT/C6aZPaZacxX3vHEiXYLS/1/XDddhBs nufS5y0naCAmdblrXA20kBE154Gv4YpDEbEUYCIVPlYBUok80qIRg3A+lHPhDPpppPwe 9R2gTRj8ivoEQRNdsDGCh3CZl7sH1PKtoUgNTXzUQCB3YaOhSsLWIdmSENY65ImNrAtF 7PcoOFYoeRkmcgVvtwFxcmq1jtEzRElf9K8trwOYQyrXXb6r+koBf9MjwES1O0ocZFbJ xr78p/BdfWJL4/GAzlRhqbNBWEnkLO0H8wlaEL/y8G0RdH4Z2JZbwlCOmCMW88T2eYs4 CrIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=wHXvEk5o; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 69si16378044pge.101.2019.07.25.03.02.51; Thu, 25 Jul 2019 03:03:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=wHXvEk5o; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390126AbfGYDrT (ORCPT + 99 others); Wed, 24 Jul 2019 23:47:19 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:45083 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389014AbfGYDrS (ORCPT ); Wed, 24 Jul 2019 23:47:18 -0400 Received: by mail-ot1-f68.google.com with SMTP id x21so11735298otq.12 for ; Wed, 24 Jul 2019 20:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aMjIeeabzA2glm2FgNQ5GnaE3BxUhRtGgmqv9hcezQY=; b=wHXvEk5oHzm7Sws7eklMNmrftnJSG+btbxOyjYGAbrQL1qJy6zD4PObA+jWSEgMyRB aRrkrq80Z3SJ2TSDws4Rv5GRprZNDrWDLrJQ0wX3686kQIu2OCLvI9w87d8UHHgOg+0d GTePKHqwPknGA8PHhql/6tyfd3uPOh/2TEWx5qiFganq3CI2HM14/fLyaNDFJPivQgUE AJkjK8XC/qBav++WOcziu3XSxf9dhzyMLjLbq5mM7h/sbnUvptmXH0y5tOUiHyLN72sK xNtG93040FKsaE7cwu4XrwN/9ZyPqAIjdUosovdN6zX4Hoeb7KDzRbZ9hm/ScRQ2CIJ6 NaBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aMjIeeabzA2glm2FgNQ5GnaE3BxUhRtGgmqv9hcezQY=; b=XFuGXmB6fGTcZ+CBUxxkgPBvCUCh5haG27jad0CRd/3r/v8z6FbkfWrvhX84u5Jom6 jttCWWXzP7nhsiNBeG8x9Y8RGKARKgRk0BsoclSjfFPZe6j5lq0Utxopn14Felop3HRI zlqTeZE/B6tnzkKr0WSb8krWzCex5cC+ekAACuo49QBjS2Zx1VEZ2FasrCZjkmc7MPDL hNvm8CNookvy10cQggkGxFS9XBxTYkKfRjTsbPgziETCuGdNtAQ1ei4X7iPPOeTn3u/P qYl545H1QAT+dZ6kxzIAD0mEX43T0SkVaWQJFdqRgT9qAFPh9ooTz9aqhWh6wZSkB439 6l5g== X-Gm-Message-State: APjAAAVctX2aG56U9s/sbfoKRhhxCbBH8b6ggEUOCcP94XmxZ1Caav9t HkuLbFAjTdx9ZsGxDWf8WzVciumN29+qgJFDrnaKVQ== X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr7714792otr.231.1564026437377; Wed, 24 Jul 2019 20:47:17 -0700 (PDT) MIME-Version: 1.0 References: <20190717222340.137578-1-saravanak@google.com> <20190717222340.137578-3-saravanak@google.com> <20190723095316.t5ltprixxd5veuj7@vireshk-i7> <20190725025849.y2xyxmqmgorrny6k@vireshk-i7> In-Reply-To: <20190725025849.y2xyxmqmgorrny6k@vireshk-i7> From: Saravana Kannan Date: Wed, 24 Jul 2019 20:46:41 -0700 Message-ID: Subject: Re: [PATCH v3 2/5] OPP: Add function to look up required OPP's for a given OPP To: Viresh Kumar Cc: MyungJoo Ham , Kyungmin Park , Chanwoo Choi , Viresh Kumar , Nishanth Menon , Stephen Boyd , "Rafael J. Wysocki" , Sibi Sankar , Android Kernel Team , Linux PM , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 24, 2019 at 7:58 PM Viresh Kumar wrote: > > On 23-07-19, 17:23, Saravana Kannan wrote: > > On Tue, Jul 23, 2019 at 2:53 AM Viresh Kumar wrote: > > > > > > On 17-07-19, 15:23, Saravana Kannan wrote: > > > > Add a function that allows looking up required OPPs given a source OPP > > > > table, destination OPP table and the source OPP. > > > > > > > > Signed-off-by: Saravana Kannan > > > > --- > > > > drivers/opp/core.c | 54 ++++++++++++++++++++++++++++++++++++++++++ > > > > include/linux/pm_opp.h | 11 +++++++++ > > > > 2 files changed, 65 insertions(+) > > > > > > > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > > > > index 438fcd134d93..72c055a3f6b7 100644 > > > > --- a/drivers/opp/core.c > > > > +++ b/drivers/opp/core.c > > > > @@ -1883,6 +1883,60 @@ void dev_pm_opp_detach_genpd(struct opp_table *opp_table) > > > > } > > > > EXPORT_SYMBOL_GPL(dev_pm_opp_detach_genpd); > > > > > > > > +/** > > > > + * dev_pm_opp_xlate_opp() - Find required OPP for src_table OPP. > > > > + * @src_table: OPP table which has dst_table as one of its required OPP table. > > > > + * @dst_table: Required OPP table of the src_table. > > > > + * @pstate: OPP of the src_table. > > > > > > You should use @ before parameters in the comments as well ? Just like > > > you did that below. > > > > And I should probably be deleting the @pstate phantom parameter :) > > > > > > + * > > > > + * This function returns the OPP (present in @dst_table) pointed out by the > > > > + * "required-opps" property of the OPP (present in @src_table). > > > > + * > > > > + * The callers are required to call dev_pm_opp_put() for the returned OPP after > > > > + * use. > > > > + * > > > > + * Return: destination table OPP on success, otherwise NULL on errors. > > > > + */ > > > > +struct dev_pm_opp *dev_pm_opp_xlate_opp(struct opp_table *src_table, > > > > > > Please name it dev_pm_opp_xlate_required_opp(). > > > > Ok > > > > > > > > > + struct opp_table *dst_table, > > > > + struct dev_pm_opp *src_opp) > > > > +{ > > > > + struct dev_pm_opp *opp, *dest_opp = NULL; > > > > + int i; > > > > + > > > > + if (!src_table || !dst_table || !src_opp) > > > > + return NULL; > > > > + > > > > + for (i = 0; i < src_table->required_opp_count; i++) { > > > > + if (src_table->required_opp_tables[i]->np == dst_table->np) > > > > > > Why can't we just compare the table pointers instead ? Yeah, I know > > > that's how I wrote that in the other xlate function, but I am confused > > > now :) > > > > I almost said "not sure. Let me just compare pointers". > > I think (not sure) it has to do with the same OPP table being used to > > create multiple OPP table copies if the "shared OPP table" flag isn't > > set? > > Can you confirm if this makes sense? If so, I can add a comment patch > > that adds comments to the existing code and then copies it into this > > function in this patch. > > Right, that was the reason but we also need to fix ... I know I gave that explanation but I'm still a bit confused by the existing logic. If the same DT OPP table is used to create multiple in memory OPP tables, how do you device which in memory OPP table is the right one to point to? > > > > > + break; > > > > + } > > > > + > > > > + if (unlikely(i == src_table->required_opp_count)) { > > > > + pr_err("%s: Couldn't find matching OPP table (%p: %p)\n", > > > > + __func__, src_table, dst_table); > > > > + return NULL; > > > > + } > > > > + > > > > + mutex_lock(&src_table->lock); > > > > + > > > > + list_for_each_entry(opp, &src_table->opp_list, node) { > > > > + if (opp == src_opp) { > > ... this as well. We must be comparing node pointers here as well. Not really, if an in memory OPP entry is not part of an in memory OPP table list, I don't think it should be considered part of the OPP table just because the node pointer is the same. I think that's explicitly wrong and the above code is correct as is. -Saravana