Message ID | 20230206184744.5.Ia77a96c6c5564f9cc25e6220b5a9171d5c2639e8@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2607978wrn; Mon, 6 Feb 2023 18:53:00 -0800 (PST) X-Google-Smtp-Source: AK7set8q0y5QX9E2125XADYClInLutxtf4i63yX40mTRy/onB/vXKZmKrf2T6cM6mnPtogV1QkT4 X-Received: by 2002:a05:6a20:8426:b0:be:b137:9d1c with SMTP id c38-20020a056a20842600b000beb1379d1cmr2075402pzd.37.1675738380202; Mon, 06 Feb 2023 18:53:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675738380; cv=none; d=google.com; s=arc-20160816; b=heFFdORCmr4+PQH7EqaWuBt0S+UNDDwjGrDJ6dk+GeRF6nX3CQRvFJlCM1hiRYZo6x UdDcEt6sR9SM51Vy82LAxmYp48tz8vIqosSywmnYjWrDQRS4oJY43/2dEvUXYVqXYJBy d6G3xLpq6BQ1XUI6q2tBpnfHC4VwROJzKhDGM+7f6+6SSFfXxvMqejLaPSLojFD6SYDk 6v2BelEcGxenAfoUieMaPiPo0FfUR6NRadbOqHW3kxzFcEx51WQ35sgwb2YBXyKN+kyq 7D9GDUjTSXMnRrlUzsmyd/5fi0s3LPKQwfFOdzjF+qnlMaCxH2GBq+vrFndbHMMwCLZ4 5J2g== 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=oAnZqwf1tmgF/Ssjms0XjO2WrbdQH0082JXWCubZ7GA=; b=Z5A12qFV0MKuAzOX3BZnv1weHgGxkPEeDuic/h+Qv37J5r3RWczflutdmFGxbMVoQ5 YD+hwYuUm1FOIrYfP5+Z8BCosKc7kGvX9P1HewjcTY0iQoTb9fFHjTnFOiUi0EWhCHSS 47sxHuyIhwYVtztEiANyLwalWoBustsoc5xPIey197FkldNcFgFxLJowk+q2M5HAOea7 VaC7zr52ebvN+SQSt4Kdt1txzwPUaRjT67zm1Phb9XBCu+lelkPlnMnGvX4yKaPsGUQa bQM/+KgyIzU1+ByIxE9GdsiPgK1DFlZwQwzySJzIdPYAwqkhWX9Fb4mhtja7zgxrptZ4 Cp9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=gwnCBpHC; 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 o5-20020a656a45000000b004f1ee7825fesi17352234pgu.469.2023.02.06.18.52.47; Mon, 06 Feb 2023 18:53:00 -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=gwnCBpHC; 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 S230136AbjBGCta (ORCPT <rfc822;kmanaouilinux@gmail.com> + 99 others); Mon, 6 Feb 2023 21:49:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230041AbjBGCtW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Feb 2023 21:49:22 -0500 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3E80366A7 for <linux-kernel@vger.kernel.org>; Mon, 6 Feb 2023 18:48:54 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id h15so6890036plk.12 for <linux-kernel@vger.kernel.org>; Mon, 06 Feb 2023 18:48:54 -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=oAnZqwf1tmgF/Ssjms0XjO2WrbdQH0082JXWCubZ7GA=; b=gwnCBpHCBDwOtQoT/Xv+4JH01cTWKaRzALTEjRtfr/lkLw+nV9Aokjd5EWM9AiBqh/ bZPfhy8IBVPjNhXUESF6U1wHXte5oBSZSEINYQsMNiQ9dXYhNOSITiYhh4R0QfVMbH8z htR46L+KtpRlEwzuJAaidtqQxrmPHBtQxTy5A= 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=oAnZqwf1tmgF/Ssjms0XjO2WrbdQH0082JXWCubZ7GA=; b=DljWNqiVpNmdaURD1rUcowRsn5fmPuTfvN3wlb5RNmgpJVi9/FxmZ1InAnR8B+EDlp R6LmqN4zkeI/aVHjAGxQLzf3/X6AMsp/VU6haCfs6mGnFsuztcVzsE1JvPr11NfjqGeT MQdH3dzzt7MNl5cCavXDGWCULgHGVCOidkMndMBAvAmA6Thv5Cyo7l9n2+Sx6QdQl9ce orReYm6k3q0voTqcy7jQFBJ09cr0XeoLrZf3N9goMvewByGV8UkZ0ixcufLqS3b3MK/n G0s1GbDa4CjxrDmlciPcaFYcCXSR1SD1kxHXnqJ4jGswjOn6mOr75/7+yxbVDA/2ESV6 3xug== X-Gm-Message-State: AO0yUKWkSPVJmAg3GTVX9G2zmFBt7xaJz+Nkob4U3ASbSTMaa7/r0bHx Y5O4wnMiIMMO/rE84730usVjZw== X-Received: by 2002:a05:6a20:a5a8:b0:bc:e82a:5c73 with SMTP id bc40-20020a056a20a5a800b000bce82a5c73mr1580561pzb.9.1675738134171; Mon, 06 Feb 2023 18:48:54 -0800 (PST) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:29fb:a635:f0df:f45a]) by smtp.gmail.com with ESMTPSA id s17-20020a63a311000000b0045dc85c4a5fsm6882430pge.44.2023.02.06.18.48.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Feb 2023 18:48:53 -0800 (PST) From: Douglas Anderson <dianders@chromium.org> To: Bjorn Andersson <andersson@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Jiri Kosina <jikos@kernel.org>, Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org, linux-arm-msm@vger.kernel.org, Dmitry Torokhov <dmitry.torokhov@gmail.com>, devicetree@vger.kernel.org, Stephen Kitt <steve@sk2.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Douglas Anderson <dianders@chromium.org>, linux-kernel@vger.kernel.org Subject: [PATCH 5/7] dt-bindings: HID: i2c-hid: goodix: Add mainboard-vddio-supply Date: Mon, 6 Feb 2023 18:48:14 -0800 Message-Id: <20230206184744.5.Ia77a96c6c5564f9cc25e6220b5a9171d5c2639e8@changeid> X-Mailer: git-send-email 2.39.1.519.gcb327c4b5f-goog In-Reply-To: <20230207024816.525938-1-dianders@chromium.org> References: <20230207024816.525938-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?1757139047504956478?= X-GMAIL-MSGID: =?utf-8?q?1757139047504956478?= |
Series |
arm: qcom: Fix touchscreen voltage for sc7280-herobrine boards
|
|
Commit Message
Doug Anderson
Feb. 7, 2023, 2:48 a.m. UTC
The goodix i2c-hid bindings currently support two models of
touchscreen: GT7375P and GT7986U. The datasheets of both touchscreens
show the following things:
* The mainboard that the touchscreen is connected to is only expected
to supply one voltage to the touchscreen: 3.3V.
* The touchscreen, depending on stuffing options, can accept IO to the
touchscreen as either 3.3V or 1.8V. Presumably this means that the
touchscreen has its own way internally to make or deal with 1.8V
signals when it's configured for 1.8V IO.
NOTE: you've got to look very carefully at the datasheet for the
touchscreen to see that the above bullets are true. Specifically, the
datasheet shows a signal called VDDIO and one might think that this is
where a mainboard would provide VDDIO to the touchscreen. Upon closer
inspection, however, a footnote can be found that says "When VDDIO is
left floating, the logic level is 1.8V [...]; when VDDIO is connected
to AVDD, the logic level is AVDD.". Thus the VDDIO pin on the
touchscreen IC is actually a selector and not a pin whre the mainboard
would pass a reference voltage.
The fact that the touchscreen isn't supplied 1.8V by the mainboard
means that when I originally submitted bindings for these touchscreens
I only listed the 3.3V rail in the bindings. It can be noted that the
original bindings and driver were added for sc7180-trogdor boards and
these boards all use 3.3V IO via a level shifter on the mainboard.
It turns out that with sc7280-herobrine-evoker, we've got a bit of a
strange monkey on our hands. Due to some very interesting but
(unfortunately) set-in-stone hardware design, we are doing 1.8V IO to
the touchscreen but we _also_ have some extra buffers on the mainboard
that need to be powered up to make the IO lines work. After much
pondering about this, it seems like the best way to handle this is to
add an optional "mainboard-vddio" rail to the bindings that is used to
power up the buffers. Specifically, the fact that the touchscreen
datasheet documents that its IOs can be at a different voltage level
than its main power rail means that there truly are two voltage rails
associated with the touchscreen, even if we don't actually provide the
IO rail to it. Thus it doesn't feel absurd for the DT node on the host
to have a 1.8V rail to power up anything related to its 1.8V logic.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
.../devicetree/bindings/input/goodix,gt7375p.yaml | 7 +++++++
1 file changed, 7 insertions(+)
Comments
On Mon, Feb 06, 2023 at 06:48:14PM -0800, Douglas Anderson wrote: > The goodix i2c-hid bindings currently support two models of > touchscreen: GT7375P and GT7986U. The datasheets of both touchscreens > show the following things: > * The mainboard that the touchscreen is connected to is only expected > to supply one voltage to the touchscreen: 3.3V. > * The touchscreen, depending on stuffing options, can accept IO to the > touchscreen as either 3.3V or 1.8V. Presumably this means that the > touchscreen has its own way internally to make or deal with 1.8V > signals when it's configured for 1.8V IO. > > NOTE: you've got to look very carefully at the datasheet for the > touchscreen to see that the above bullets are true. Specifically, the > datasheet shows a signal called VDDIO and one might think that this is > where a mainboard would provide VDDIO to the touchscreen. Upon closer > inspection, however, a footnote can be found that says "When VDDIO is > left floating, the logic level is 1.8V [...]; when VDDIO is connected > to AVDD, the logic level is AVDD.". Thus the VDDIO pin on the > touchscreen IC is actually a selector and not a pin whre the mainboard > would pass a reference voltage. > > The fact that the touchscreen isn't supplied 1.8V by the mainboard > means that when I originally submitted bindings for these touchscreens > I only listed the 3.3V rail in the bindings. It can be noted that the > original bindings and driver were added for sc7180-trogdor boards and > these boards all use 3.3V IO via a level shifter on the mainboard. > > It turns out that with sc7280-herobrine-evoker, we've got a bit of a > strange monkey on our hands. Due to some very interesting but > (unfortunately) set-in-stone hardware design, we are doing 1.8V IO to > the touchscreen but we _also_ have some extra buffers on the mainboard > that need to be powered up to make the IO lines work. After much > pondering about this, it seems like the best way to handle this is to > add an optional "mainboard-vddio" rail to the bindings that is used to > power up the buffers. Specifically, the fact that the touchscreen > datasheet documents that its IOs can be at a different voltage level > than its main power rail means that there truly are two voltage rails > associated with the touchscreen, even if we don't actually provide the > IO rail to it. Thus it doesn't feel absurd for the DT node on the host > to have a 1.8V rail to power up anything related to its 1.8V logic. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> We went over this with Doug offline, and after re-reading the spec sheet this does make sense to me. Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> > --- > > .../devicetree/bindings/input/goodix,gt7375p.yaml | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml > index 1c191bc5a178..ce18d7dadae2 100644 > --- a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml > +++ b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml > @@ -36,6 +36,13 @@ properties: > vdd-supply: > description: The 3.3V supply to the touchscreen. > > + mainboard-vddio-supply: > + description: > + The supply on the main board needed to power up IO signals going > + to the touchscreen. This supply need not go to the touchscreen > + itself as long as it allows the main board to make signals compatible > + with what the touchscreen is expecting for its IO rails. > + > required: > - compatible > - reg > -- > 2.39.1.519.gcb327c4b5f-goog >
On Mon, 06 Feb 2023 18:48:14 -0800, Douglas Anderson wrote: > The goodix i2c-hid bindings currently support two models of > touchscreen: GT7375P and GT7986U. The datasheets of both touchscreens > show the following things: > * The mainboard that the touchscreen is connected to is only expected > to supply one voltage to the touchscreen: 3.3V. > * The touchscreen, depending on stuffing options, can accept IO to the > touchscreen as either 3.3V or 1.8V. Presumably this means that the > touchscreen has its own way internally to make or deal with 1.8V > signals when it's configured for 1.8V IO. > > NOTE: you've got to look very carefully at the datasheet for the > touchscreen to see that the above bullets are true. Specifically, the > datasheet shows a signal called VDDIO and one might think that this is > where a mainboard would provide VDDIO to the touchscreen. Upon closer > inspection, however, a footnote can be found that says "When VDDIO is > left floating, the logic level is 1.8V [...]; when VDDIO is connected > to AVDD, the logic level is AVDD.". Thus the VDDIO pin on the > touchscreen IC is actually a selector and not a pin whre the mainboard > would pass a reference voltage. > > The fact that the touchscreen isn't supplied 1.8V by the mainboard > means that when I originally submitted bindings for these touchscreens > I only listed the 3.3V rail in the bindings. It can be noted that the > original bindings and driver were added for sc7180-trogdor boards and > these boards all use 3.3V IO via a level shifter on the mainboard. > > It turns out that with sc7280-herobrine-evoker, we've got a bit of a > strange monkey on our hands. Due to some very interesting but > (unfortunately) set-in-stone hardware design, we are doing 1.8V IO to > the touchscreen but we _also_ have some extra buffers on the mainboard > that need to be powered up to make the IO lines work. After much > pondering about this, it seems like the best way to handle this is to > add an optional "mainboard-vddio" rail to the bindings that is used to > power up the buffers. Specifically, the fact that the touchscreen > datasheet documents that its IOs can be at a different voltage level > than its main power rail means that there truly are two voltage rails > associated with the touchscreen, even if we don't actually provide the > IO rail to it. Thus it doesn't feel absurd for the DT node on the host > to have a 1.8V rail to power up anything related to its 1.8V logic. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > > .../devicetree/bindings/input/goodix,gt7375p.yaml | 7 +++++++ > 1 file changed, 7 insertions(+) > Acked-by: Rob Herring <robh@kernel.org>
diff --git a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml index 1c191bc5a178..ce18d7dadae2 100644 --- a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml +++ b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml @@ -36,6 +36,13 @@ properties: vdd-supply: description: The 3.3V supply to the touchscreen. + mainboard-vddio-supply: + description: + The supply on the main board needed to power up IO signals going + to the touchscreen. This supply need not go to the touchscreen + itself as long as it allows the main board to make signals compatible + with what the touchscreen is expecting for its IO rails. + required: - compatible - reg