Message ID | 20221208111910.2.I65ac577411b017eff50e7a4fda254e5583ccdc48@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp379391wrr; Thu, 8 Dec 2022 11:23:04 -0800 (PST) X-Google-Smtp-Source: AA0mqf4F/p+9UyFIdHcmW/estpAwCT66OQhwbgcIexr0nsBtYadMJA7+mSMgYRJvhmhZup/MCp61 X-Received: by 2002:a17:902:f641:b0:181:b25e:e7bc with SMTP id m1-20020a170902f64100b00181b25ee7bcmr78848602plg.46.1670527384081; Thu, 08 Dec 2022 11:23:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670527384; cv=none; d=google.com; s=arc-20160816; b=u8uhMMGdLPjSkIQqScpO4/LX08yvhR5KuTBe1E3klm1wuML4fhS1uN3qDRScSZOzpk 0OjXFLYhLy9xaUaZLr0l1a/ba0EBRqsc4hobWOmhZRWoGyfk0zmcyOHq51VsBQr64jv3 5sKdgX6tFx5cdjucZHpquIG4vndihdHhHk1gkcGiKnob+A4CNFlPpJdWdz0QMD785CPq 8KRcg1rk+5RnrDThd5CFGVwT5apVnv6KKW9FS6OCi8XhsYtLvKcT0MUo1ajtC8TWNZ1m URhVb4qwpVlnB1lvPd7LHp5XdMIPMsA5jXO3KHUIDMRUW5/IigIw/OIKd/Oe3cTXOODe 9hsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=RXZFKzf8SEbO5MJF/tbRe/Hy6ddvI0OXNJGHZyfmauA=; b=BWOJbNCZbz2DUd8YrFBMl0KdADRagShK7au1a3vp1wEekAK4IR61998R6aWbOs2SpB voq3JMeIRa7r1Wkzb5fjsU7puMNmDUGTCNSnb8rScYkeL3K2Ve9i8WONjm2mKmRXKYy3 0kGEgQqSOFDGxpQDZu0Z1qKSv0ubYoQRvMg1cmUaV4vlqVk8Q4YhqwH7/AokCWejyGCw 6u4UsJFYfeMrllwQMI+BBp1Ig3b+YvKrixvRQA9pqTofCoVKQrYOFjpMeFAPyMgR7b5b CkROpqXGkMSLmBBHrMQQYkjqffkzfu9ailF+4ENPAvGQzWJXKLvyaXprDGpNRN5RlBMS 8C0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=RtJ6gvU4; 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=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e2-20020a630f02000000b004782dc93af4si23367124pgl.307.2022.12.08.11.22.50; Thu, 08 Dec 2022 11:23:04 -0800 (PST) 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=@chromium.org header.s=google header.b=RtJ6gvU4; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229752AbiLHTUo (ORCPT <rfc822;foxyelen666@gmail.com> + 99 others); Thu, 8 Dec 2022 14:20:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229719AbiLHTUf (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 8 Dec 2022 14:20:35 -0500 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A22F99533 for <linux-kernel@vger.kernel.org>; Thu, 8 Dec 2022 11:20:34 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id 3-20020a17090a098300b00219041dcbe9so2537613pjo.3 for <linux-kernel@vger.kernel.org>; Thu, 08 Dec 2022 11:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RXZFKzf8SEbO5MJF/tbRe/Hy6ddvI0OXNJGHZyfmauA=; b=RtJ6gvU4u20lqWyhOPFyXMpF2NNgS93C/PcBqKyQgBoFU/M+fleiQZVu+iLC5JcJ7M k1BnmfKE+l26w6sOkxNlZblsmHXxnqW6B51hWf7K1Fx8xpIAta67G1itL2XTPNVkTqMF rTDYvm+ygXrkJIXQrKCfRD4GXpt6a3f9bTeSc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RXZFKzf8SEbO5MJF/tbRe/Hy6ddvI0OXNJGHZyfmauA=; b=JaQXfQsAj9LYONy2IyIkV+veu4HEybxQLW8/tn0xIGCyMoosNT+KsY2c94ePEdbdH0 z+1ntE5MYWwpyk6GEuwHdZUHOC5ucCy9g5SV5OdcNS7M7UgKJe1lbBjwUQoSTNVJMcgy xfT29qxbA+ataLrz9vadjkpl4quzAdTCSwPGnX0HMicDBIF5ApD4xV/OZMvAmDm1ALdr 5q9c4kSdxD9zaehYSv3c7kx7wBwYC5j4LVGBXQPu6Zdw7KuG8dS8OwRu9oWwIgNtPxwT CTgtowrp1vgWgD4pvzjTs7bBEcfKG7gbiHR8UvFvjmXZKXxZtE9gOFJRvgYpv6firUfC cUGQ== X-Gm-Message-State: ANoB5pm86hzV0MTnJTyTJdnCwo77mPnoGEc5ZpepOPEODEe2a+TMrmdZ RU7dQ3owsdtVIMXFoxK96n4MSA== X-Received: by 2002:a17:902:ab57:b0:189:4de5:6c7f with SMTP id ij23-20020a170902ab5700b001894de56c7fmr2866574plb.3.1670527233568; Thu, 08 Dec 2022 11:20:33 -0800 (PST) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:3aa1:2c62:9ac:4468]) by smtp.gmail.com with ESMTPSA id u5-20020a170902e5c500b00186a2274382sm17112019plf.76.2022.12.08.11.20.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 11:20:33 -0800 (PST) From: Douglas Anderson <dianders@chromium.org> To: Bjorn Andersson <andersson@kernel.org>, Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: mka@chromium.org, swboyd@chromium.org, linux-arm-msm@vger.kernel.org, linux-input@vger.kernel.org, Yunlong Jia <ecs.beijing2022@gmail.com>, Konrad Dybcio <konrad.dybcio@linaro.org>, Douglas Anderson <dianders@chromium.org>, Andy Gross <agross@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Rob Herring <robh+dt@kernel.org>, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/5] arm64: dts: qcom: sc7180: Add trogdor eDP/touchscreen regulator off-on-time Date: Thu, 8 Dec 2022 11:20:03 -0800 Message-Id: <20221208111910.2.I65ac577411b017eff50e7a4fda254e5583ccdc48@changeid> X-Mailer: git-send-email 2.39.0.rc1.256.g54fd8350bd-goog In-Reply-To: <20221208192006.1070898-1-dianders@chromium.org> References: <20221208192006.1070898-1-dianders@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751674922469835322?= X-GMAIL-MSGID: =?utf-8?q?1751674922469835322?= |
Series |
arm64: dts: qcom: sc7180: Make pazquel360's touchscreen work
|
|
Commit Message
Doug Anderson
Dec. 8, 2022, 7:20 p.m. UTC
In general, the timing diagrams for components specify a minimum time
for power cycling the component. When we remove power from a device we
need to let the device fully discharge and get to a quiescent state
before applying power again. If we power a device on too soon then it
might not have fully powered off and might be in a weird in-between /
invalid state.
eDP panels typically have a time that's at least 500 ms here. You can
see that in Linux's panel-edp driver that nearly every device
specifies a "unprepare" time of at least 500 ms. This is a common
minimum and the 500 ms is even in the example in the eDP spec.
In Linux, the "panel-edp" driver enforces this delay for its own
control of the regulator, but the "panel-edp" driver can't do anything
about other control of the regulator (for instance, by the touchpanel
driver).
Let's add 500 ms as a board constraint for the regulator that's used
for eDP/touchpanel on trogdor boards. If a given trogdor board stuffs
only panels that can use a shorter time or stuff some panels that need
a larger time then they can manually adjust this timing.
We'll only do this minimum delay for trogdor devices with eDP (ones
that use either bridge chip), not for devices with MIPI panels. MIPI
panels could have similar constraints but the 500 ms isn't necessarily
as standard and there are no known cases where this delay is needed.
For most trogdor boards, this doesn't actually seem to affect anything
when testing against shipping Linux. However, with pazqel360 it seems
that this does make a difference. It seems that the touchscreen on
this board _also_ needs some time for the regulator to discharge. That
time is much less than 500 ms, so we'll just put the eDP panel 500 ms
in there since the board constraint should be the "max" of the
components.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
.../boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi | 12 ++++++++++++
.../boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi | 12 ++++++++++++
2 files changed, 24 insertions(+)
Comments
On Thu, Dec 08, 2022 at 11:20:03AM -0800, Douglas Anderson wrote: > In general, the timing diagrams for components specify a minimum time > for power cycling the component. When we remove power from a device we > need to let the device fully discharge and get to a quiescent state > before applying power again. If we power a device on too soon then it > might not have fully powered off and might be in a weird in-between / > invalid state. > > eDP panels typically have a time that's at least 500 ms here. You can > see that in Linux's panel-edp driver that nearly every device nit: s/that nearly/nearly/ no need to re-spin just for this. > specifies a "unprepare" time of at least 500 ms. This is a common > minimum and the 500 ms is even in the example in the eDP spec. > > In Linux, the "panel-edp" driver enforces this delay for its own > control of the regulator, but the "panel-edp" driver can't do anything > about other control of the regulator (for instance, by the touchpanel > driver). > > Let's add 500 ms as a board constraint for the regulator that's used > for eDP/touchpanel on trogdor boards. If a given trogdor board stuffs > only panels that can use a shorter time or stuff some panels that need > a larger time then they can manually adjust this timing. > > We'll only do this minimum delay for trogdor devices with eDP (ones > that use either bridge chip), not for devices with MIPI panels. MIPI > panels could have similar constraints but the 500 ms isn't necessarily > as standard and there are no known cases where this delay is needed. > > For most trogdor boards, this doesn't actually seem to affect anything > when testing against shipping Linux. However, with pazqel360 it seems > that this does make a difference. It seems that the touchscreen on > this board _also_ needs some time for the regulator to discharge. That > time is much less than 500 ms, so we'll just put the eDP panel 500 ms > in there since the board constraint should be the "max" of the > components. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi index ebd6765e2afa..e27a769f8cd4 100644 --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi @@ -26,6 +26,18 @@ pp3300_brij_ps8640: pp3300-brij-ps8640-regulator { }; }; +/* + * ADDITIONS TO FIXED REGULATORS DEFINED IN PARENT DEVICE TREE FILES + * + * Sort order matches the order in the parent files (parents before children). + */ + +&pp3300_dx_edp { + off-on-delay-us = <500000>; +}; + +/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */ + &dsi0_out { remote-endpoint = <&ps8640_in>; }; diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi index 65333709e529..3188788306d0 100644 --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi @@ -7,6 +7,18 @@ #include <dt-bindings/gpio/gpio.h> +/* + * ADDITIONS TO FIXED REGULATORS DEFINED IN PARENT DEVICE TREE FILES + * + * Sort order matches the order in the parent files (parents before children). + */ + +&pp3300_dx_edp { + off-on-delay-us = <500000>; +}; + +/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */ + &dsi0_out { remote-endpoint = <&sn65dsi86_in>; };