From mboxrd@z Thu Jan 1 00:00:00 1970 From: Evan Green Subject: Re: [PATCH v1 1/2] interconnect: Add support for path tags Date: Fri, 8 Mar 2019 10:40:40 -0800 Message-ID: References: <20190208172152.1807-1-georgi.djakov@linaro.org> <20190208172152.1807-2-georgi.djakov@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20190208172152.1807-2-georgi.djakov@linaro.org> Sender: linux-kernel-owner@vger.kernel.org To: Georgi Djakov Cc: linux-pm@vger.kernel.org, daidavid1@codeaurora.org, Vincent Guittot , Bjorn Andersson , amit.kucheria@linaro.org, Doug Anderson , Sean Sweeney , Michael Turquette , Alexandre Bailon , Thierry Reding , ksitaraman@nvidia.com, sanjayc@nvidia.com, henryc.chen@mediatek.com, LKML , linux-arm-kernel@lists.infradead.org, linux-arm-msm List-Id: linux-arm-msm@vger.kernel.org On Fri, Feb 8, 2019 at 9:21 AM Georgi Djakov wrote: > > Consumers may have use cases with different bandwidth requirements based > on the system or driver state. The consumer driver can append a specific > tag to the path and pass this information to the interconnect platform > driver to do the aggregation based on this state. > > Introduce icc_set_tag() function that will allow the consumers to append > an optional tag to each path. The aggregation of these tagged paths is > platform specific. > > Signed-off-by: Georgi Djakov > --- > drivers/interconnect/core.c | 27 +++++++++++++++++++++++---- > drivers/interconnect/qcom/sdm845.c | 2 +- > include/linux/interconnect-provider.h | 4 ++-- > include/linux/interconnect.h | 5 +++++ > 4 files changed, 31 insertions(+), 7 deletions(-) > > diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c > index 6005a1c189f6..31eacd0f5349 100644 > --- a/drivers/interconnect/core.c > +++ b/drivers/interconnect/core.c > @@ -42,10 +42,12 @@ struct icc_req { > > /** > * struct icc_path - interconnect path structure > + * @tag: path tag (optional) > * @num_nodes: number of hops (nodes) > * @reqs: array of the requests applicable to this path of nodes > */ > struct icc_path { > + u32 tag; > size_t num_nodes; > struct icc_req reqs[]; > }; > @@ -206,7 +208,7 @@ static struct icc_path *path_find(struct device *dev, struct icc_node *src, > * implementing its own aggregate() function. > */ > > -static int aggregate_requests(struct icc_node *node) > +static int aggregate_requests(struct icc_node *node, u32 tag) > { > struct icc_provider *p = node->provider; > struct icc_req *r; > @@ -215,7 +217,7 @@ static int aggregate_requests(struct icc_node *node) > node->peak_bw = 0; For my suggestion in patch 2, this is where you'd need the callback to reset the SLEEP/WAKE shadow aggregation buckets that the provider is keeping, since the core just reset the values here. I wonder if you'd want to pass the &node->avg_bw and &node->peak_bw in with this callback as well... not sure if that's useful. Something like: if (p->begin_aggregation) p->begin_aggregation(node); > > hlist_for_each_entry(r, &node->req_list, req_node) > - p->aggregate(node, r->avg_bw, r->peak_bw, > + p->aggregate(node, tag, r->avg_bw, r->peak_bw, > &node->avg_bw, &node->peak_bw); Wait I'm confused. The tag is associated with a particular path. But now aren't you looping over all the other requests and coloring them with whatever tag this is? Don't you need to store the tag with the request, and then pass r->tag for each r rather than the tag from whichever request happened to initiate the re-aggregation? > > return 0; > @@ -396,6 +398,23 @@ struct icc_path *of_icc_get(struct device *dev, const char *name) > } > EXPORT_SYMBOL_GPL(of_icc_get); > 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 X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2725C43381 for ; Fri, 8 Mar 2019 18:41:28 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 859ED2085A for ; Fri, 8 Mar 2019 18:41:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="e/e7aIEt"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="m2K8o0lw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 859ED2085A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ODO3hv0Lp8fTw/wlb2jvjjfZ+awcEPsmXSMOusGHA6U=; b=e/e7aIEtXUqhts 9hvaKrexjBM2Q+mN06CjZySZLA9p3XegqS23YtT5zhXirGBbibi8aOyjAQqXlvvVskUxlOG9DKvog ISZSz5+yj2x6c4rhsRTwOCAmW9m8lf/Iqmg2iJjD/2vizTqf7DTTNI9Lr0Ec4pbT2h/5szr3GoQsU kqwbiXQzl0dMjX3weRBymJIL8u/Cvo0ZM5FUkRUQKWk2i4nsaEtP24/fys0H5EdxaEPmNuhQZxbWv vPoRGYXxWXnO+HZkno+R+ImceGhKltxS/5vgXWLQW1VGGiUaUOVr7VWWXMHg0F1zFiMXbAt66MQCb fq2JRZPvT8JwizgNMslQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h2KQt-00044K-8U; Fri, 08 Mar 2019 18:41:23 +0000 Received: from mail-lj1-x244.google.com ([2a00:1450:4864:20::244]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h2KQq-00043U-EE for linux-arm-kernel@lists.infradead.org; Fri, 08 Mar 2019 18:41:22 +0000 Received: by mail-lj1-x244.google.com with SMTP id t13so18276826lji.2 for ; Fri, 08 Mar 2019 10:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ylm4GGs3k69mm0+P+ifUy0mBRCQkvW6nh2imUsERxTE=; b=m2K8o0lwm2cn6XcnlMgeBG4Jjzvuf3HwhgVrodtW0wNnips1msVCcWUZrjHD0WTs1o FQxktq+9GaVktGO7Cksbp6egpjLjb2GVxOwIijKJbWVf8Vitwg9AOC8q/hmSsk6GVt8R UYdPksA45A2I5WTdOtBGHJDrYtbHtroRkpmYk= 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=ylm4GGs3k69mm0+P+ifUy0mBRCQkvW6nh2imUsERxTE=; b=oIGrIKwwa+XyC2V5Q7uaDevyIEe/tmrkBhwkFzm8OOJqO2lXz3gGyLb4O3wFB5zeJ2 y+UOJ92TtISGEuB5M3VixJ3d8Ik7XQpzIUeMXpKDaNwq+Q/RkhhY9LIbKapAtsD/BtAq o4aaJjdGYuz9RPq6ScqSFMmMBq2tXQ2CvSeNGrohtNEGNAbolLasZZk7kc3WJYC03avO 6khwBxghyaqHPOPiCkttlFpgPC4HwCx4cYWZ/gvv1QrpwoCa4AKR26xduq3iaExVb8T9 GTy2TP77+Oj2KY4RrtG0wL7CvMVsjD2LTiQUMPmtc0SRGh7XsCyV7nYJmIlRuYEmipdM l/+Q== X-Gm-Message-State: APjAAAUpLxDpC6SdJGLlnhwUGxUXX63Nl+SduSFa9DsMG/IoYQmR6bMH 8Mc8goTtySlp2TYcFE0IQPKgOf8RYXk= X-Google-Smtp-Source: APXvYqyKExE8NgEYb4foDx5cCAT5EENKlHEZZxOoWhawZ9HHK9csXhmQVoq4KWf8DMPnfjlZqrPrOQ== X-Received: by 2002:a2e:6f08:: with SMTP id k8mr9498109ljc.197.1552070478310; Fri, 08 Mar 2019 10:41:18 -0800 (PST) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id q6sm1611143lfh.52.2019.03.08.10.41.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 10:41:17 -0800 (PST) Received: by mail-lj1-f175.google.com with SMTP id l5so18252217lje.1 for ; Fri, 08 Mar 2019 10:41:16 -0800 (PST) X-Received: by 2002:a2e:9f0b:: with SMTP id u11mr10484072ljk.64.1552070476417; Fri, 08 Mar 2019 10:41:16 -0800 (PST) MIME-Version: 1.0 References: <20190208172152.1807-1-georgi.djakov@linaro.org> <20190208172152.1807-2-georgi.djakov@linaro.org> In-Reply-To: <20190208172152.1807-2-georgi.djakov@linaro.org> From: Evan Green Date: Fri, 8 Mar 2019 10:40:40 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 1/2] interconnect: Add support for path tags To: Georgi Djakov X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190308_104120_499889_EA33C4EB X-CRM114-Status: GOOD ( 22.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Vincent Guittot , sanjayc@nvidia.com, linux-pm@vger.kernel.org, Sean Sweeney , LKML , Michael Turquette , daidavid1@codeaurora.org, Doug Anderson , amit.kucheria@linaro.org, Bjorn Andersson , Thierry Reding , henryc.chen@mediatek.com, Alexandre Bailon , linux-arm-msm , ksitaraman@nvidia.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Feb 8, 2019 at 9:21 AM Georgi Djakov wrote: > > Consumers may have use cases with different bandwidth requirements based > on the system or driver state. The consumer driver can append a specific > tag to the path and pass this information to the interconnect platform > driver to do the aggregation based on this state. > > Introduce icc_set_tag() function that will allow the consumers to append > an optional tag to each path. The aggregation of these tagged paths is > platform specific. > > Signed-off-by: Georgi Djakov > --- > drivers/interconnect/core.c | 27 +++++++++++++++++++++++---- > drivers/interconnect/qcom/sdm845.c | 2 +- > include/linux/interconnect-provider.h | 4 ++-- > include/linux/interconnect.h | 5 +++++ > 4 files changed, 31 insertions(+), 7 deletions(-) > > diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c > index 6005a1c189f6..31eacd0f5349 100644 > --- a/drivers/interconnect/core.c > +++ b/drivers/interconnect/core.c > @@ -42,10 +42,12 @@ struct icc_req { > > /** > * struct icc_path - interconnect path structure > + * @tag: path tag (optional) > * @num_nodes: number of hops (nodes) > * @reqs: array of the requests applicable to this path of nodes > */ > struct icc_path { > + u32 tag; > size_t num_nodes; > struct icc_req reqs[]; > }; > @@ -206,7 +208,7 @@ static struct icc_path *path_find(struct device *dev, struct icc_node *src, > * implementing its own aggregate() function. > */ > > -static int aggregate_requests(struct icc_node *node) > +static int aggregate_requests(struct icc_node *node, u32 tag) > { > struct icc_provider *p = node->provider; > struct icc_req *r; > @@ -215,7 +217,7 @@ static int aggregate_requests(struct icc_node *node) > node->peak_bw = 0; For my suggestion in patch 2, this is where you'd need the callback to reset the SLEEP/WAKE shadow aggregation buckets that the provider is keeping, since the core just reset the values here. I wonder if you'd want to pass the &node->avg_bw and &node->peak_bw in with this callback as well... not sure if that's useful. Something like: if (p->begin_aggregation) p->begin_aggregation(node); > > hlist_for_each_entry(r, &node->req_list, req_node) > - p->aggregate(node, r->avg_bw, r->peak_bw, > + p->aggregate(node, tag, r->avg_bw, r->peak_bw, > &node->avg_bw, &node->peak_bw); Wait I'm confused. The tag is associated with a particular path. But now aren't you looping over all the other requests and coloring them with whatever tag this is? Don't you need to store the tag with the request, and then pass r->tag for each r rather than the tag from whichever request happened to initiate the re-aggregation? > > return 0; > @@ -396,6 +398,23 @@ struct icc_path *of_icc_get(struct device *dev, const char *name) > } > EXPORT_SYMBOL_GPL(of_icc_get); > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel