Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1302882iob; Fri, 29 Apr 2022 02:18:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJjLlJjppvbIOpd8pijWo9E14iOpgGnwKs/HjIoxVJXnmXRiaUMgVo/mQeqxoWmlJMUnRu X-Received: by 2002:a05:6512:ad4:b0:472:3bf9:8ead with SMTP id n20-20020a0565120ad400b004723bf98eadmr4676224lfu.90.1651223925968; Fri, 29 Apr 2022 02:18:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651223925; cv=none; d=google.com; s=arc-20160816; b=f5CvIT34EU7RI4jD3qeIVVyozGtLnkg6Rh+ztxWfJJZj1aNuz2wa/LEu1e+dgewRSU rkBOsGZp30UwZXsbRLzd6p6Q0XWUTNVF6WjdMlOtAu2ICFYSAci5U22FnKAMF+F+c5Pr hzcYLTOOxPeDXZ5rXC6FZe2Kxo6oGYoNfL2j/tbHJi/+FGIgpLEAwO1PURJ+B8JG5Xqb rEWqPTm2L020gxA8Gmonqx5YHiEKgliOmms26vHJofhRzFxo64+zhLU/ykujRL+fnNcb ri7ioPaMTzbso9KIIs1EURMKM6anMTyK9O6ANBRSSFlPbW6aN8rzmhiSD1FZqGwUSW8m jlOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:user-agent:mime-version:date :message-id:dkim-signature; bh=Q0r841q8Lmj207L3/SuGuqZgNI0g9j5NTczRIpmDaEw=; b=Yb/5VRWauzN5eY4iqJBvxHNUu8IgESPDxxd6IrN7u5NMWQMxuqF3Ni768BOQBShgDV gkRPOF/DbF6KqeuQpiQd1+9BKkdepbjt6SF9tEw07cAaizOePfB6pVu7smxvx9HzdxDH hmgaLar7uPcf1qwEshDD76wsAg2YgR37VcsoI7uA3pLOXRBDQ+gt507puJTpxaHzWht9 jXmekJ6pFdOV8RiQ5GicMFjWacRTgfQnDjNFVsP7beVH8rtCORQw/MWGVCSUncrZjGiZ 34N1ZYYGhxJxx5XMw2GhQdjR2Nce/Qxai+v+yIz9hRKScPxAROAdnrtkE+SmNoyxJcAb g2Fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=R9xSeKE6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b10-20020a0565120b8a00b004711c6957f1si7732490lfv.46.2022.04.29.02.18.11; Fri, 29 Apr 2022 02:18:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=R9xSeKE6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233835AbiD1K0a (ORCPT + 99 others); Thu, 28 Apr 2022 06:26:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233426AbiD1K01 (ORCPT ); Thu, 28 Apr 2022 06:26:27 -0400 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0B23205DA for ; Thu, 28 Apr 2022 03:23:12 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id k23so8628571ejd.3 for ; Thu, 28 Apr 2022 03:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=Q0r841q8Lmj207L3/SuGuqZgNI0g9j5NTczRIpmDaEw=; b=R9xSeKE68VTgVWlDJZSjcG7dyqcla7RWBQrLbvg1sZfaZcgtu0Ud7RtIlTswsdpAos zvu24qu3TOTRdih5EtF3rjKxIznFoFsMaYpvhAysCRx9ybBJiKT6g7sUQktOhZdsVf5L uqpjtxmawQQf9f/1uzw+1JTbt5LGpiTfF/0XH+ySXUXRt+Z/H8PfwpCI9p5fEh0fUMFb L+d67xGvggiCg++e0CfmLbqhSdsxm8gHh1yl7FdN5cr+zZxpEWz26CMXHXQFHAjiypOW 0zDScN5vMElHsiqcYn6ituCJS8Pn2S0/mV1phN4OaXLw+5P+iHpd12bOcruQz1sj2nZx 3/+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=Q0r841q8Lmj207L3/SuGuqZgNI0g9j5NTczRIpmDaEw=; b=ydqW3urinbIsosQie8mz2FmcbWMjlCisTrcsmF9poIR3wqCYCgX+sFpW28DfWSCaOu VAtQ2DynD3YwqJ15bGWHpaw3aUKinT4zVYrXSfEyZzpZDcmeqRiHHqGrZMvm3foOaRZ2 /T0qV4KhibFRj+7bRF/UUioFjApx3SbjGQEsE8G9g0FI+TK+XiUsUf7byY94poeV3QQI 8qJ4SUq2a4aMTruNfAgopnx5+vvyEQKoUOMQpAamPiYex6qjXhGKK8vynal0FJZEheX+ KafJs5S2uJKsHYQ2JOet9mV3TPcRAww4c44ocy87u+pwKIewZTPzCthxrzByQibIxnvd zbmQ== X-Gm-Message-State: AOAM531f+u4uUwz9mcFVP9boEQxcwYexyGq5DIF0pfA9iHhRlSGDSk/x effxh03zyeuHo5NnG5mO3MAMrw== X-Received: by 2002:a17:906:43c2:b0:6e8:47dd:47ed with SMTP id j2-20020a17090643c200b006e847dd47edmr29964740ejn.600.1651141391346; Thu, 28 Apr 2022 03:23:11 -0700 (PDT) Received: from [192.168.0.161] (xdsl-188-155-176-92.adslplus.ch. [188.155.176.92]) by smtp.gmail.com with ESMTPSA id le4-20020a170906ae0400b006f38734cadbsm6355463ejb.136.2022.04.28.03.23.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Apr 2022 03:23:10 -0700 (PDT) Message-ID: Date: Thu, 28 Apr 2022 12:23:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] interconnect: qcom: use icc_sync_state Content-Language: en-US To: Georgi Djakov , Andy Gross , Bjorn Andersson , linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220427145616.523557-1-krzysztof.kozlowski@linaro.org> <4769c796-6edd-c23a-ee2a-ce54495548f7@kernel.org> From: Krzysztof Kozlowski In-Reply-To: <4769c796-6edd-c23a-ee2a-ce54495548f7@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/04/2022 17:34, Georgi Djakov wrote: > On 27.04.22 17:56, Krzysztof Kozlowski wrote: >> Use icc_sync_state for interconnect providers, so that the bandwidth >> request doesn't need to stay on maximum value. > > Did you test this? In general, we should not enable this on boards that > do not have full interconnect scaling support in consumer drivers yet. > Some of the interconnects could be enabled by default by the bootloader > and usually later during boot the consumer drivers request the bandwidth > that they need. But if the requests are missing, the interconnects > without bandwidth users will be disabled when we reach sync state. So > this may (or not) cause issues... I understand, thanks for bringing this up. It does not look like an issue of interconnect provider but instead consumers and DTS. It's not the job of provider driver to know all possible uses and DTS files. The driver should expose itself and if platform is not ready, should not use it by not enabling the interconnect. It's a job for DTS, not for the interconnect provider. Imagine some out of tree DTS which cannot use interconnects because we assume that all users of that provider are missing bandwidth requests. No, instead provider should allow anyone to use it. I understand my change might cause unexpected issues, but it is still technically correct, just maybe should be followed with disabling in DTS the providers without proper consumers? Best regards, Krzysztof