Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp305554pxm; Wed, 2 Mar 2022 15:57:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJwElg75QF+wHaGaAwt/teHJq3eJgiFMoMx8IT3+/z1oR2Nyiouin5wHpu4SNQ9g/ZuKOkwI X-Received: by 2002:a17:90a:a510:b0:1bc:5887:d957 with SMTP id a16-20020a17090aa51000b001bc5887d957mr2360010pjq.38.1646265441984; Wed, 02 Mar 2022 15:57:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646265441; cv=none; d=google.com; s=arc-20160816; b=OJY191RP3et+75+/lCkdahxuU0ms3XUSkQGFMmRKm6Svm4a83d4td62DGCsFJ5fSkL n0j2i9zP1n3suw4hqIHtaV03RPeu9Jwkb/LhswY+jIOeJDPjrvNM6ZMgnAZc95fKIh9q 1hAJOBLGYQBk3RjTtPP+KeXmCbiL+5HmVWoHSXjz0nPxKosn0PPA6xWMbA/kso3zKQMa JHL/MGH6GdEg4kHfGaClk9/zNNKiDBIY/XOtsk1zX+DpZSlo96yMRiaWI0zBvKemM9KI Wsag2o5a9igZdkwxrSu7U0/on6F719QnTTGJp4Bl4V5euRuaUGp1AKmUO+86sELbb1wT Sy9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=W/OHrbBOSzQoNIMp4yIse8lL5E3OuoeVt5dK0c4ZOz4=; b=oZiEon1ylcEhZ45pfO7pQqJ+p+ng54gPJFFy3OxtZebgGVmRcOAO05LyqyxGyXg9fF a5EgAmEvHFIGU+nB84/XNVEZb0t+JpgC7g4tfSbtYpaZx6URLmudbUrfawXfErsOISHz TEYTy5tCgCyLpOcyjOvm5AERHwHbg/8vsvQf6LNtLTqORkrqI49o91N9QSUIvT494CIJ c29b3doCHm53WVQAhb7nvy0CKyFDxtWDyygOVEj+sIpiqAeRWbTtu1vJAnRTm9XlSVoV XlpNzLd/RAS9AiWaq/x4Vslle9jjk1ie4XVYD2/Yp2GUkQjp94hTFYqfR7Sk/qwfMOKD rrug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Q5NMvvWP; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id nu8-20020a17090b1b0800b001bef4ea0840si4153304pjb.82.2022.03.02.15.57.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 15:57:21 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Q5NMvvWP; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7F837192E12; Wed, 2 Mar 2022 15:17:31 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243314AbiCBQnY (ORCPT + 99 others); Wed, 2 Mar 2022 11:43:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243599AbiCBQnG (ORCPT ); Wed, 2 Mar 2022 11:43:06 -0500 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A893B114F for ; Wed, 2 Mar 2022 08:42:21 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id hw13so4908126ejc.9 for ; Wed, 02 Mar 2022 08:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W/OHrbBOSzQoNIMp4yIse8lL5E3OuoeVt5dK0c4ZOz4=; b=Q5NMvvWPoa1JXTZDJe5s1ZV4XNfqE8mrsFpXI0anaiU2bXxNMjkr2TIusHZrgDAfQg GvuXrd5vGYsRvy+p3jRvKTDcIn5hiRh8sDfrIGZ2tGoTz1MK8bw67hxOF31U0LItDiTr buhlylZrDBKEhmZMQCpKBn48eZeeFDrZSlX1M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W/OHrbBOSzQoNIMp4yIse8lL5E3OuoeVt5dK0c4ZOz4=; b=E1LWmUFAWhvNkxmkuacG7nRcyMarwC5IxkuTnXPWiGma9+rdm2nkiiXw1hPB9JSDLd KKhtzjnW+K6ufke7KcMwFht7QMnhtoNsEcU7z2pio0+hrXgd6DuVXD0BCCAuYQDSlrFO gYPC30ySNfYfgMezfwgCgtmG3fSVtrfjpld5cQ9EtiCoSgiWEIYaEj535Y2Zf8jK9Mwk ef+33KklmQSdOb8JMqDNT3BqUwq/cbVJu81dN50arjygu7PjLlyP8vmw1XxrOBT9TdXh OEsg0+ujuFJNwye1LdReSZGb2+e2uPkXNO0Ugc7YkKUw9pGN2JrU1h60Fe8Qg8fcdiMP 4ajA== X-Gm-Message-State: AOAM532YkyjgBRy1IfyBsCALTUcL5+XuKRgqmSQKaCI7Xi4klE0r2HD1 9usYmdQgzk98J7jmNOA5/XQp+MyI0PB3Y+v1 X-Received: by 2002:a17:906:4cca:b0:6ce:6a06:bf7 with SMTP id q10-20020a1709064cca00b006ce6a060bf7mr24328647ejt.109.1646239339802; Wed, 02 Mar 2022 08:42:19 -0800 (PST) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com. [209.85.221.47]) by smtp.gmail.com with ESMTPSA id g21-20020a056402115500b00413c824e422sm3413293edw.72.2022.03.02.08.42.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Mar 2022 08:42:19 -0800 (PST) Received: by mail-wr1-f47.google.com with SMTP id j17so3770817wrc.0 for ; Wed, 02 Mar 2022 08:42:19 -0800 (PST) X-Received: by 2002:a5d:6543:0:b0:1ef:7194:3efc with SMTP id z3-20020a5d6543000000b001ef71943efcmr19660822wrv.422.1646239338601; Wed, 02 Mar 2022 08:42:18 -0800 (PST) MIME-Version: 1.0 References: <1644843828-20464-1-git-send-email-quic_vnivarth@quicinc.com> In-Reply-To: <1644843828-20464-1-git-send-email-quic_vnivarth@quicinc.com> From: Doug Anderson Date: Wed, 2 Mar 2022 08:42:05 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] arm64: dts: qcom: sc7280: Configure cts sleep pinctrl to bias-disable for sc7280-idp To: Vijaya Krishna Nivarthi Cc: Andy Gross , Bjorn Andersson , Rob Herring , linux-arm-msm , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML , msavaliy@qti.qualcomm.com, Matthias Kaehlcke , Stephen Boyd Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Hi, On Mon, Feb 14, 2022 at 5:04 AM Vijaya Krishna Nivarthi wrote: > > WLAN rail was leaking power during RBSC/sleep even after turning BT off. > Change sleep pinctrl configuration to handle same. > > Signed-off-by: Vijaya Krishna Nivarthi > --- > arch/arm64/boot/dts/qcom/sc7280-idp.dtsi | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi > index d623d71..de18319 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi > @@ -516,10 +516,10 @@ > pins = "gpio28"; > function = "gpio"; > /* > - * Configure a pull-down on CTS to match the pull of > - * the Bluetooth module. > + * Configure a disable on CTS to lower power usage > + * when BT is turned off. > */ > - bias-pull-down; > + bias-disable; Why is sc7280 different from all of the previous devices? Did the Bluetooth firmware change or are we measuring a different case? I know we spent a lot of time carefully choosing each of these pulls before so before changing them we should understand what changed. CTS is an input from the AP's perspective, right? From the AP's perspective then the case we need to be careful of is to prevent this line from every floating while the AP is turned on. Specifically, consider this case: 1. AP is powered on but has no pull on this line 2. The Bluetooth chip is powered off or otherwise configured to not drive this line. In that case the line will be floating. Its voltage will wander around, influenced by other parts of the system. The downside here is that, so I'm told, this will cause power draw on the AP. Each time the voltage on the line floats between trigger points that the AP is watching for it will trigger some logic in the AP and cause power consumption. That's really not ideal. So by disabling this pull you need to be _really_ sure that there's no case where the AP is on and the Bluetooth chip is powered off / not driving the line. In the past I don't think we were convinced of this, which is why we configured a pull but tried to match it with what the Bluetooth chip would do anyway. So... How about using bias-bus-hold instead? That has the advantage of keeping the line from floating but also shouldn't cause a constant power draw. I believe it was created _exactly_ to deal with this type of case. I don't think I was even aware that we supported bias-bus-hold the last time we had this discussion and it seems like it would solve the problem nicely. Does it work for you? -Doug