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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8245C433EF for ; Thu, 28 Apr 2022 10:23:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232791AbiD1K03 (ORCPT ); Thu, 28 Apr 2022 06:26:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233358AbiD1K01 (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 C0CAA20F59 for ; Thu, 28 Apr 2022 03:23:12 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id i19so8573268eja.11 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=rq6IoU4QoUK0crq+zd1aLM+x7+hqtn/WcLNtefAyGvO2HWNYw0zQrwFw2sUjo0tIlm Rhp9cBupfHMNU1GZ/tNCV/yK/5NIGQl95+WluopbEIKuY/4GBXd6DcYM+2WEChK059uk TTYlPbTczPDD8PkcXVRhB0xGjeQ9CfMN3ca/um0gYgd3H5YRUhkvJX7crWwlqh5XMTb6 dLbXGBp6O8sH3gLVJNXkCPypgbJOT+ZGAvbgWq5GjonWlhMZwXdQwUV1N7xhydHfSmI6 binyO6NJteZoUL0ZMYmQ65L+q2iOvAfrwjDzYBRMuiTuRxKokI9kMTgNKkGQAH1UuBpW ybzQ== X-Gm-Message-State: AOAM5303uzyaY+gv/CSPLjTn6BA360JIM/veqCgxt/xvfB5sefX8BjoV WWVUV6o3o4xDXk39TR1P1moTWA== X-Google-Smtp-Source: ABdhPJz/LCaM1IEwSnXb6OQ38sLpgLyZHrqkqQfaA3KS4ii7yW32/U8imRnZA6jMMsEd59dFqG45oA== 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 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@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