Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5578343ybl; Sun, 22 Dec 2019 09:10:17 -0800 (PST) X-Google-Smtp-Source: APXvYqxhdIjdONDuROZKQVlPc2rH/cellXmjkT+B+oTUJGQaM4EeXNV6FYA+no8UiO2vP/OZEZmn X-Received: by 2002:a05:6830:3014:: with SMTP id a20mr1539401otn.350.1577034616982; Sun, 22 Dec 2019 09:10:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577034616; cv=none; d=google.com; s=arc-20160816; b=PcuyMTRn1eLYWknF1NCZ7UVRvmLAgZqEkFcVwtT5KKsCV4VfcEHDEe82XQ21d0+VUp l16w2TxFAOAEqJY9/UahezzriKHzEaL4mop1zeXMoEff4tJXvtjmfvOIr+4HSV0z8OrD /945+WJgbUdeHawinrioV/GKTsYJSMc/hg7QI3Io164IWRHtuwbcxJ43um4z+3cUhXkR anKjlzWIZFqMpKW0KURHvCWmnipuCCwvABJDEFqVTJktSECC0wxO8WBHnW+WQdGsOpvP 93WFLUwXJEsivHxVCZ5tNai5yQTO4NL8P4HYZ3EI3mP4LBwWSOBbhBA7hK4z8wIiQnwP PHAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Ytp6gIWJh4XAmoyxjahmHGmJ/5mpYFfViKvuFGbMa2M=; b=QbCNiLcbnve4VfhuN5xTlRQAXDVY6pPKiCgudUsNhJcWl6WjI7kJSw0NLecIevJWEY PHstQUP3xXx6OqlumyHjHzqbmjr+NBKtE7y86hBoWhtEW6y7BiDD0nU9JL+d0UQKJ1tM 6nWUBb71DfzvY4g46RcIuZgQF+On4vIiidN2Hr8xTwrzzL3vMk2uX2SXqO7AiQaDstRt EFJpSAy1eYLSjGVngCmyFX1G/1po0CFBDioR1ZPDwLETzr4EDcSGMVjFKlAF+aFNwXuA z5CaHiziB5zMQfksMfRccqhbjxpc7HD3tPiclOL4bWeASkgP5Q3jOj0GruGq7lshmnHP AQAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=07BQMQ6H; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m26si8829231otn.307.2019.12.22.09.10.03; Sun, 22 Dec 2019 09:10:16 -0800 (PST) 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=@kernel.org header.s=default header.b=07BQMQ6H; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726162AbfLVRJV (ORCPT + 99 others); Sun, 22 Dec 2019 12:09:21 -0500 Received: from mail.kernel.org ([198.145.29.99]:54142 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725919AbfLVRJV (ORCPT ); Sun, 22 Dec 2019 12:09:21 -0500 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 46063206B7; Sun, 22 Dec 2019 17:09:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1577034559; bh=geqtjwNhYhPjKOQTr6T9PrwqzqjPWdQ7WW0r3/weydI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=07BQMQ6Hi57dx/JRXrxf2u1oNEjJQB034YRiconHLdRB0lLKc4Hwfe97RW05Uv/tq AKKDhe6nGpWcF/9npYiw5Fq7zftXQnLc13UPWdC0kF0ifrclA2+d+VZlDC8Ya5r7E8 tfwfwll4JDkG/JDZSwUMYCfglmEytTVVBzC+tQJE= Received: by mail-lf1-f52.google.com with SMTP id 15so10942870lfr.2; Sun, 22 Dec 2019 09:09:19 -0800 (PST) X-Gm-Message-State: APjAAAWdkqqIfYX1GDzTIc5509s+wbpIH7AjL2VBEL49BBdSNBNLGv7+ va06MXGAiwGHQMgbCtUlsZzis6+27yCosBJMzwk= X-Received: by 2002:ac2:5444:: with SMTP id d4mr15264932lfn.49.1577034557468; Sun, 22 Dec 2019 09:09:17 -0800 (PST) MIME-Version: 1.0 References: <20191220115653.6487-1-a.swigon@samsung.com> <20191220115653.6487-4-a.swigon@samsung.com> In-Reply-To: <20191220115653.6487-4-a.swigon@samsung.com> From: Chanwoo Choi Date: Mon, 23 Dec 2019 02:08:41 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v3 3/7] interconnect: Allow inter-provider pairs to be configured To: =?UTF-8?B?QXJ0dXIgxZp3aWdvxYQ=?= Cc: devicetree , linux-arm-kernel , linux-samsung-soc , linux-kernel , Linux PM list , dri-devel , Chanwoo Choi , MyungJoo Ham , inki.dae@samsung.com, Seung-Woo Kim , Georgi Djakov , Leonard Crestez , Marek Szyprowski , Bartlomiej Zolnierkiewicz , Krzysztof Kozlowski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Fri, Dec 20, 2019 at 9:03 PM Artur =C5=9Awigo=C5=84 wrote: > > In the exynos-bus devfreq driver every bus is probed separately and is IMHO, the patch description should specify the more general cause why have to be changed. Actually, almost people might not know the 'exynos-bus'. So, firstly, you have to specify the general cause why this patch is necessary without 'exynos-bus' word and then add the real use-case with 'exynos-bus' example. > assigned a separate interconnect provider. However, the interconnect > framework does not call the '->set' callback for pairs of nodes which > belong to different providers. > > This patch adds support for a new boolean 'inter_set' field in struct > icc_provider. Setting it to 'true' enables calling '->set' for > inter-provider node pairs. All existing users of the interconnect > framework allocate this structure with kzalloc, and are therefore > unaffected. > > Signed-off-by: Artur =C5=9Awigo=C5=84 > --- > drivers/interconnect/core.c | 11 +++++------ > include/linux/interconnect-provider.h | 2 ++ > 2 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c > index 74c68898a350..a28bd0f8a497 100644 > --- a/drivers/interconnect/core.c > +++ b/drivers/interconnect/core.c > @@ -259,23 +259,22 @@ static int aggregate_requests(struct icc_node *node= ) > static int apply_constraints(struct icc_path *path) > { > struct icc_node *next, *prev =3D NULL; > + struct icc_provider *p; > int ret =3D -EINVAL; > int i; > > for (i =3D 0; i < path->num_nodes; i++) { > next =3D path->reqs[i].node; > + p =3D next->provider; > > - /* > - * Both endpoints should be valid master-slave pairs of t= he > - * same interconnect provider that will be configured. > - */ > - if (!prev || next->provider !=3D prev->provider) { > + /* both endpoints should be valid master-slave pairs */ > + if (!prev || (p !=3D prev->provider && !p->inter_set)) { > prev =3D next; > continue; > } > > /* set the constraints */ > - ret =3D next->provider->set(prev, next); > + ret =3D p->set(prev, next); > if (ret) > goto out; > > diff --git a/include/linux/interconnect-provider.h b/include/linux/interc= onnect-provider.h > index cc965b8fab53..b6ae0ee686c5 100644 > --- a/include/linux/interconnect-provider.h > +++ b/include/linux/interconnect-provider.h > @@ -41,6 +41,7 @@ struct icc_node *of_icc_xlate_onecell(struct of_phandle= _args *spec, > * @xlate: provider-specific callback for mapping nodes from phandle arg= uments > * @dev: the device this interconnect provider belongs to > * @users: count of active users > + * @inter_set: whether inter-provider pairs will be configured with @set > * @data: pointer to private data > */ > struct icc_provider { > @@ -53,6 +54,7 @@ struct icc_provider { > struct icc_node* (*xlate)(struct of_phandle_args *spec, void *dat= a); > struct device *dev; > int users; > + bool inter_set; > void *data; > }; > > -- > 2.17.1 > --=20 Best Regards, Chanwoo Choi