Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp851045ybj; Thu, 7 May 2020 09:02:37 -0700 (PDT) X-Google-Smtp-Source: APiQypIz/d/mHCkep7r1S+dlUFkJq3f2R4tMAQxMy7NKpjy6Az10ZQxNLdEsvS3pyKMVcbk67n5P X-Received: by 2002:aa7:d342:: with SMTP id m2mr12974737edr.341.1588867356933; Thu, 07 May 2020 09:02:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588867356; cv=none; d=google.com; s=arc-20160816; b=zkUIiUPOVIheETlm+WM6p4lOTNcV6B9i2c31631LJMd7MxYillNE84BrJn2lZ6b+an IS3BYsa1/r+qoBGO+Ec0kLST7UWgvv0+99kWXqHLpGvgyXgVjNU/qqGBGpBrz6n0OcKQ KnPaHmFY4kKqSvLlAITJUD2Jufe36DJJ80UxbQJZCPlJYXO73KG81b/HjK/J+R2PdzgM y6rRSHkuwn3NjKnyjZ8MdowIai8GaLerN6VjjgfR28gV7/9OjCr6tYOiI9DqC5X3pePR bzOPapNrW2S/jF+KFkeiQ2v5ykSWK1Ry5P/tif4bMDUel7QVwssfianuxDyavVqyMtan 6VlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=D4EacoqLrks03Ge0RCzM6pu9iVWZ73tmsSunwf83CvA=; b=0BKRKh/vFmUmVeDjoOQCnhX0qr32Q1Plks1N7XtumerVhcxtIXRgdxdEKFORUaEvpv AHhoxJwM5cw9wNcv4rVt+aQXW1dbnFsbtFKV2Y+zhlFahdV6eV9gp8sYLjrA1bKbzPnr JWF1Rn7Vh0jdhrVfhslyI5g8mFKgdK7d9BNRqfAvtQuvRMUz7YuuFRHvmirPNd0fl8qT 0rbRUaJnVE+YkFoigTqAIXZ2BCWTAOsa0D7LV7ocRjzjnMgyADYJvDOdxyXzi/PUDdD3 2IBRLaRUCH6Ak1d+Kt09eEpP8aq7fPW92asB9YeQ+ePX/nUB5McwnMre5NbxRoBPRL1g BrCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=AoTz5sGm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k15si3612737edk.194.2020.05.07.09.01.50; Thu, 07 May 2020 09:02:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=AoTz5sGm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728015AbgEGP5P (ORCPT + 99 others); Thu, 7 May 2020 11:57:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727998AbgEGP5O (ORCPT ); Thu, 7 May 2020 11:57:14 -0400 Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23608C05BD43 for ; Thu, 7 May 2020 08:57:14 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id d184so3202920pfd.4 for ; Thu, 07 May 2020 08:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=D4EacoqLrks03Ge0RCzM6pu9iVWZ73tmsSunwf83CvA=; b=AoTz5sGmagbHHvj2Ukx2Xn0z5zI4ieVjR3BuWxfMXVqkIDVqRpfZzMZ3lr/cT1UCdB Rlr9fsxa01PQZrNoTl088lbebcpciyfdWkOi2/JDtNBm1YhZF3Dxl/gx02be7INEG+oA 6qlGHMwDEbY79blf2uKO+a5CXvf4KdjgtNQJ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=D4EacoqLrks03Ge0RCzM6pu9iVWZ73tmsSunwf83CvA=; b=mlPqj+lwWAT9+oQGNGUihJpIQC4p9tVJb8oQ62fV4VJt8beMg7d8iIfMo2obwbEprG lEm7KmxH/UdtQxs6ffZkbQUwG8N0Y+OMKVfvtgYEZd9bn7+rsFJ1J3EtYLMX6DROYbTc 5dW5iVomH7O22NGDIJddE0V8Y1xpOpyvmW/K0mcH+g2e3e8gRa6AwWpAAmDKmltAFPsy W6tTN+AxP5z+t5VmqArEYm9Loj18uDUeZrxbNGbBsKy11c4VN4mAGjc3m4gwz7Ek9D3L Ql4LrFZ5Mn/uKv3DLi7V6yiAumXwZMpW41PATIUa8NEhvzo+1GAh9+AfRoJR1595zr/A CrWw== X-Gm-Message-State: AGi0PuaBIugPq598HEaGg8xkXlA038ENId0YVQk8aC4cKnGA3Hr86ncZ +V1PGbVao+LTACzILwDbviKPzSXDoAY= X-Received: by 2002:a62:16cb:: with SMTP id 194mr14822510pfw.78.1588867033537; Thu, 07 May 2020 08:57:13 -0700 (PDT) Received: from localhost ([2620:15c:202:1:4fff:7a6b:a335:8fde]) by smtp.gmail.com with ESMTPSA id gd17sm234805pjb.21.2020.05.07.08.57.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2020 08:57:12 -0700 (PDT) Date: Thu, 7 May 2020 08:57:11 -0700 From: Matthias Kaehlcke To: Georgi Djakov Cc: linux-pm@vger.kernel.org, evgreen@chromium.org, bjorn.andersson@linaro.org, akashast@codeaurora.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] interconnect: Add helpers for enabling/disabling a path Message-ID: <20200507155711.GZ4525@google.com> References: <20200507120846.8354-1-georgi.djakov@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200507120846.8354-1-georgi.djakov@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 07, 2020 at 03:08:46PM +0300, Georgi Djakov wrote: > There is a repeated pattern in multiple drivers where they want to switch > the bandwidth between zero and some other value. This is happening often > in the suspend/resume callbacks. Let's add helper functions to enable and > disable the path, so that callers don't have to take care of remembering > the bandwidth values and handle this in the framework instead. > > With this patch the users can call icc_disable() and icc_enable() to lower > their bandwidth request to zero and then restore it back to it's previous > value. > > Suggested-by: Evan Green > Suggested-by: Bjorn Andersson > Signed-off-by: Georgi Djakov > --- > v2: https://lore.kernel.org/r/20200428091650.27669-1-georgi.djakov@linaro.org/ > * Extract the common code into __icc_enable() (Matthias) > > > drivers/interconnect/core.c | 39 ++++++++++++++++++++++++++++++++- > drivers/interconnect/internal.h | 2 ++ > include/linux/interconnect.h | 12 ++++++++++ > 3 files changed, 52 insertions(+), 1 deletion(-) > > diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c > index f5699ed34e43..d5e0f93c942d 100644 > --- a/drivers/interconnect/core.c > +++ b/drivers/interconnect/core.c > @@ -158,6 +158,7 @@ static struct icc_path *path_init(struct device *dev, struct icc_node *dst, > hlist_add_head(&path->reqs[i].req_node, &node->req_list); > path->reqs[i].node = node; > path->reqs[i].dev = dev; > + path->reqs[i].enabled = true; > /* reference to previous node was saved during path traversal */ > node = node->reverse; > } > @@ -249,9 +250,12 @@ static int aggregate_requests(struct icc_node *node) > if (p->pre_aggregate) > p->pre_aggregate(node); > > - hlist_for_each_entry(r, &node->req_list, req_node) > + hlist_for_each_entry(r, &node->req_list, req_node) { > + if (!r->enabled) > + continue; > p->aggregate(node, r->tag, r->avg_bw, r->peak_bw, > &node->avg_bw, &node->peak_bw); > + } > > return 0; > } > @@ -571,6 +575,39 @@ int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw) > } > EXPORT_SYMBOL_GPL(icc_set_bw); > > +static int __icc_enable(struct icc_path *path, bool enable) > +{ > + int i; > + > + if (!path) > + return 0; > + > + if (WARN_ON(IS_ERR(path) || !path->num_nodes)) > + return -EINVAL; > + > + mutex_lock(&icc_lock); > + > + for (i = 0; i < path->num_nodes; i++) > + path->reqs[i].enabled = enable; > + > + mutex_unlock(&icc_lock); > + > + return icc_set_bw(path, path->reqs[0].avg_bw, > + path->reqs[0].peak_bw); > +} > + > +int icc_disable(struct icc_path *path) > +{ > + return __icc_enable(path, false); > +} > +EXPORT_SYMBOL_GPL(icc_disable); > + > +int icc_enable(struct icc_path *path) > +{ > + return __icc_enable(path, true); > +} > +EXPORT_SYMBOL_GPL(icc_enable); > + uber-nit: my brain expects the order enable/disable, just like lock/unlock or true/false instead of vice-versa, but it's certainly not really important :) > /** > * icc_get() - return a handle for path between two endpoints > * @dev: the device requesting the path > diff --git a/drivers/interconnect/internal.h b/drivers/interconnect/internal.h > index bf18cb7239df..f5f82a5c939e 100644 > --- a/drivers/interconnect/internal.h > +++ b/drivers/interconnect/internal.h > @@ -14,6 +14,7 @@ > * @req_node: entry in list of requests for the particular @node > * @node: the interconnect node to which this constraint applies > * @dev: reference to the device that sets the constraints > + * @enabled: indicates whether the path with this request is enabled > * @tag: path tag (optional) > * @avg_bw: an integer describing the average bandwidth in kBps > * @peak_bw: an integer describing the peak bandwidth in kBps > @@ -22,6 +23,7 @@ struct icc_req { > struct hlist_node req_node; > struct icc_node *node; > struct device *dev; > + bool enabled; > u32 tag; > u32 avg_bw; > u32 peak_bw; > diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h > index 770692421f4c..2b7b331c9354 100644 > --- a/include/linux/interconnect.h > +++ b/include/linux/interconnect.h > @@ -30,6 +30,8 @@ struct icc_path *icc_get(struct device *dev, const int src_id, > struct icc_path *of_icc_get(struct device *dev, const char *name); > struct icc_path *devm_of_icc_get(struct device *dev, const char *name); > void icc_put(struct icc_path *path); > +int icc_disable(struct icc_path *path); > +int icc_enable(struct icc_path *path); > int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw); > void icc_set_tag(struct icc_path *path, u32 tag); > > @@ -57,6 +59,16 @@ static inline void icc_put(struct icc_path *path) > { > } > > +static inline int icc_disable(struct icc_path *path) > +{ > + return 0; > +} > + > +static inline int icc_enable(struct icc_path *path) > +{ > + return 0; > +} > + > static inline int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw) > { > return 0; Reviewed-by: Matthias Kaehlcke