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 988F2C677F1 for ; Fri, 13 Jan 2023 18:25:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231159AbjAMSZN (ORCPT ); Fri, 13 Jan 2023 13:25:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230175AbjAMSYn (ORCPT ); Fri, 13 Jan 2023 13:24:43 -0500 Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 866BE637C for ; Fri, 13 Jan 2023 10:18:50 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id u8so11125974ilq.13 for ; Fri, 13 Jan 2023 10:18:50 -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=GdoZeQNplmRhThp2c6eonI7uoiBCPYO2onFJRhJu/3Q=; b=Nsf8v+2rEoiKtbGI99+zqm6bmU09wTu8gl8eYKZl+OU8LT/wgDIzWNEMFfNdtsN2q7 2e4EAg2iobCGkInNBqko0nuGAZ2CxlPidsNVcVPX87pPywi6z2PIicmW6iuzDmIPGu+f I7FASFi5lbSofOAjJbwaLReNbKfzrh9S02ibE= 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=GdoZeQNplmRhThp2c6eonI7uoiBCPYO2onFJRhJu/3Q=; b=C7kK+jwhmetrkc33GMhZreFiMr1UGcYdFu4UcnFNvYz3Za6yfX0O3P9TNEL75oM0ir ecHcxY4UcRapWaNrBewBkTjL11f+4MLayQoZa5woYI0ueAvPhF8DZIQFyQgasYM+auTe hklNvCusx9P2fYMNx2ecRAt/Hev6l2SVn7cEqxck11ZOmiM7JZTJ14P+3ThjpbypYMag Yuc5KMYRocmUhPAPPU2hHTk7XfUDIrP/08Zl46qki8ltuSGqQyAN5kTtx/tSucPrlQVr vo5rrjTO69A3JA3e9QepdiJWw71I4FhndIyxFMlGYmrpqGP9bO1Y+HD/tPbDilfWJP4h tEfQ== X-Gm-Message-State: AFqh2koghjMPAsT/nJ0kq9VKmZvHqThADVcLvOTIKlO1jlzkKuLvusYW SFRrfL+7WxgwaT0LUGCWriTNhQ== X-Google-Smtp-Source: AMrXdXtnegZsA/OzeztSEBOwZ7uawpvx3yql8nZI7sD6Wwfegt8ck6ntGiUT65918OdLTlSDkFfkRg== X-Received: by 2002:a05:6e02:1307:b0:30e:eb27:2802 with SMTP id g7-20020a056e02130700b0030eeb272802mr174827ilr.7.1673633929894; Fri, 13 Jan 2023 10:18:49 -0800 (PST) Received: from localhost (30.23.70.34.bc.googleusercontent.com. [34.70.23.30]) by smtp.gmail.com with UTF8SMTPSA id x17-20020a029711000000b0039ea3e0a3easm2456796jai.35.2023.01.13.10.18.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Jan 2023 10:18:49 -0800 (PST) Date: Fri, 13 Jan 2023 18:18:47 +0000 From: Matthias Kaehlcke To: Rajendra Nayak , Georgi Djakov Cc: krzysztof.kozlowski@linaro.org, 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220902043511.17130-5-quic_rjendra@quicinc.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi, On Fri, Sep 02, 2022 at 10:05:11AM +0530, Rajendra Nayak wrote: > Add cpu and llcc BWMON nodes and their corresponding > OPP tables for sc7280 SoC. > > Signed-off-by: Rajendra Nayak > Reviewed-by: Krzysztof Kozlowski I found that with a v6.1 kernel AOSS on sc7280 doesn't reach it's low power state during system. This can be observed on herobrine based boards on which the AP_SUSPEND signal should transition to 1 during system suspend. If it doesn't the Embedded Controller (EC) notices it and wakes the system up again. Bisection points to this patch, the issue only occurs when CONFIG_QCOM_ICC_BWMON is *not* set. One might think the patch shouldn't have any impact at all when the driver is not enabled, but it does. Debugging shows that the issue is interconnect related. A bare platform device is created for each bwmon devices, which results in the average and peak bandwidth of the interconnect link to be set 'initially' to INT_MAX. The driver is supposed to call icc_sync_state() during probe, 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? Thanks Matthias