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 7D671C3DA78 for ; Tue, 17 Jan 2023 18:00:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229830AbjAQSAo (ORCPT ); Tue, 17 Jan 2023 13:00:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231348AbjAQR4Q (ORCPT ); Tue, 17 Jan 2023 12:56:16 -0500 Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63E854F877 for ; Tue, 17 Jan 2023 09:47:15 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id u8so15780310ilg.0 for ; Tue, 17 Jan 2023 09:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8F81q3l/TJktOEcsAAxVIySD1mWyFaZRhl5NfEknlwM=; b=eGBEqUNrEcTTtbihLCI82m3GrMUfa/u1FaeVqcFS1kv0PlNWZ0LI/zPTKTd32cUDxJ omNj8Eowo53XzGkUZj9O/el/um50AteuVwiDOhpLCzK2BJFi8bY2Yag7DOQyeVKEWpw1 dpgG2PtpBNxrAcS9h6K0hLALRH1aMVPYaM/B4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8F81q3l/TJktOEcsAAxVIySD1mWyFaZRhl5NfEknlwM=; b=vVj5oVEzqSNBZLKqu9N8C2fTbQig8d7NGU4q/s6dHk6YtFEPtQ0dQRV4650mAv9R8w 62adNKKCNsDXKLUwktoYS46JRb2grM5k5XpeMlFhDrRWSmp01S8lIHYzgvgs7xmtpcvY IAAXrmlaAzAdR3p5hAOYthM0hm5lMPAF3+mZMFdvrxasuOLuYa0O2oKjCr4tYoo5txg/ QMKPcFIOfq6JfNEf7Fei4WCPdiLGfQYs2/3kXzcnI9yLrHnZcsqUNOTkQhgQpvkcauvg 6yYD+/8aXB9i7gKHEtotlzZZTToyERl9peP+XH2l6zwt4pdPLBiNfvKcM2xT2PsQxEub uIyA== X-Gm-Message-State: AFqh2kq8/oPcX4ci8hn+MHInWn4hnjhC4vgE26aQ5W0kCtIUsEqUcRhW VsbU9P3P/hIgMR7n+afzdiIm3Q== X-Google-Smtp-Source: AMrXdXsMe/3YbShdIn9hNUkJvH+E7o8CrBvenCfXUSgVpSPU/i9zfX7YnJFUlYqZmgIutCKUd3zFIg== X-Received: by 2002:a05:6e02:ecf:b0:30f:159b:3846 with SMTP id i15-20020a056e020ecf00b0030f159b3846mr3402581ilk.20.1673977635000; Tue, 17 Jan 2023 09:47:15 -0800 (PST) Received: from localhost (30.23.70.34.bc.googleusercontent.com. [34.70.23.30]) by smtp.gmail.com with UTF8SMTPSA id r8-20020a92ac08000000b0030c68d38255sm9142749ilh.38.2023.01.17.09.47.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Jan 2023 09:47:14 -0800 (PST) Date: Tue, 17 Jan 2023 17:47:14 +0000 From: Matthias Kaehlcke To: Krzysztof Kozlowski Cc: Rajendra Nayak , Georgi Djakov , agross@kernel.org, andersson@kernel.org, konrad.dybcio@somainline.org, robh+dt@kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, Douglas Anderson , Stephen Boyd Subject: Re: [PATCH v2 4/4] arm64: dts: qcom: sc7280: Add cpu and llcc BWMON (=> interconnect issue) Message-ID: References: <20220902043511.17130-1-quic_rjendra@quicinc.com> <20220902043511.17130-5-quic_rjendra@quicinc.com> <754f8193-09ec-8bbf-e0d4-898525dc242f@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <754f8193-09ec-8bbf-e0d4-898525dc242f@linaro.org> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Jan 17, 2023 at 06:33:41PM +0100, Krzysztof Kozlowski wrote: > On 17/01/2023 18:27, Matthias Kaehlcke wrote: > > > >>> which would set the initially bandwidths to 0 and determine the actually > >>> needed bandwidth. But since the driver isn't probed the initial > >>> bandwidths stay at INT_MAX. > >>> > >>> This isn't actually an issue with this patch, but how the interconnect > >>> framework deals with devices that are registered on the bus, but aren't > >>> probed (yet). Not sure how this would be best fixed. Georgi, do you have > >>> any ideas? > >> > >> Why the device is not probed (yet)? If it is registered, it will come > >> soon during boot up. > > > > Because CONFIG_QCOM_ICC_BWMON is not enabled for the board in question (see > > above). It could be enabled as a short term mitigtion, however we shouldn't > > require drivers to be enabled just because the DT has a corresponding node. > > It's the same case as with all other interconnect leafs/consumers. The > same behavior if you do not have it enabled, right? If not, I wonder > what is here different? Right, this is a general issue. The problem on sc7280 (and probably other Qualcomm SoCs) is that the interconnect link at full throttle prevents the SoC from entering its low power mode (AOSS sleep) during system suspend. On many boards this might go unnoticed, on herobrine the condition is detected by the embedded controller (EC) and considered a failed suspend, which results in waking up the system.