Message ID | 20230523193017.4109557-1-dianders@chromium.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2375612vqo; Tue, 23 May 2023 12:38:29 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7b0RzCaIaqiVlXigN9xZUWSUaFZZDUcp84+YjTOrm4CXJZaNe2vwfSS6qJxU5eLAYKODeo X-Received: by 2002:a05:6a20:938f:b0:103:90ab:d79 with SMTP id x15-20020a056a20938f00b0010390ab0d79mr17516125pzh.25.1684870709377; Tue, 23 May 2023 12:38:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684870709; cv=none; d=google.com; s=arc-20160816; b=stX5VuGcydlHNPOcImJAdhYTdb6Y04slqrNI2k1poBZR7BGqzNMvMAQojBv6F3Fb9c Gqmve5gO1S6zozfh1nz6brmVIyEGcFwJVnz8+C69GBVd44yibp4X/BIrdjPMr3tBu+R+ IeiZtFWL/SmC7UrQ9KUhwpKTQlEVxgyfmKZH3yhQo1XcakgqYDhk98K8KNK12VT+pqA7 fRhsUs9ASZKx1i/jgcp13HB0i3nHMNCYPS2WIUGUD94sXCUsX4WVJSId49fRZdRwwgdZ LEJ5l12Am3hsCuTCS6NN+BpzUPF0t9tkzbgq6D0zeTWi6O4TzH3rrm6zBV/oAUvhLwN9 ercg== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=da7xHElmRhs7yLWfdeHx4hSBX9WK1oPzedpFeX43g5E=; b=xEH2Wx8Qk29/Mh0SbrdKvx+LlYOPc3sOn9fl1e2eztcpopEy80NqJ+ak9JndD1fZlc JiUuC9/D/A2sKmlLfAb1IF3R6OxXZaQ3tyyE8oYk+frF9lVwbBciMiL66GFXRtUbr3Wy Go2+frTpMTOFFeKW97t6CobXte7Stj0HczsNq4vzRJrsniXhjuWOycIpxewdFg3v1ar/ I5LgqBiXyEOAsxp+aP+l19DhGH1dCYERaUjj54xiMI9PFe+timMCm5eWMSoMuYcN6lti BSng5HTgem6Jjij2ZlJ7uZ6cpLS8T/Qm1NzbAS6Nx8zHw4vxgxmk6F1S9kfyaU7yB59G KMsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=LzUeez59; 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 w186-20020a6382c3000000b004fb95253a18si6774337pgd.376.2023.05.23.12.38.16; Tue, 23 May 2023 12:38:29 -0700 (PDT) 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=LzUeez59; 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 S237857AbjEWTbb (ORCPT <rfc822;ahmedalshaiji.dev@gmail.com> + 99 others); Tue, 23 May 2023 15:31:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37402 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230027AbjEWTb3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 23 May 2023 15:31:29 -0400 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DAC33E46 for <linux-kernel@vger.kernel.org>; Tue, 23 May 2023 12:31:08 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1ae4c5e12edso243125ad.3 for <linux-kernel@vger.kernel.org>; Tue, 23 May 2023 12:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1684870268; x=1687462268; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=da7xHElmRhs7yLWfdeHx4hSBX9WK1oPzedpFeX43g5E=; b=LzUeez59b5Pg0Ump+sB4OM8jCT2gUu+L3cHDGuYq6KxKNdbWzzUcYfIjiAl9CHb7/y Zd/xCwCoNFjhdzyDFQL7kt91TMpOZffzujd6HC05iDlXlLzNfOfWBkCHqD6ablJniuG1 PQBLx18VMf6dlXe/RbYmWDRnV0qm5puEiOYyw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684870268; x=1687462268; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=da7xHElmRhs7yLWfdeHx4hSBX9WK1oPzedpFeX43g5E=; b=V9XpEbC0iPF9orJiRva2Yl+x9Ctao6vQgqN4DbqEPsraeQ+7cRrcJOBzHQa5Sgi3I+ 3dgjcpFr/Slo55PU7ObPog5HZ6/aHfuF3nFj+vzhmn+51WQhtKO7TCjnZrUgeTBahdHq Eflz0NeFq45+Z4cduYpsfuW4poloc80vL5+qX4fi4eKk2GyHZF17ty+mNkcqh/J76TTf 3K6cc30kmIKLAR/EmrHnrRwp+YkUeYxmXUA6uY0vrRZA8BhvXXqyQKNhG89g0eKaNME9 mcMIwYIoR1Uzd1nx0rKS6m7sKxq3KWDlWT1OM5hm7RShDYR1UKvMcKeqb4FT5CVqYU9H pOUw== X-Gm-Message-State: AC+VfDzntIEDeaYUurkCLy8XKAOJgu0QOyNDvIutkJm9AZCwjXjfIL53 N62x26TWW3cnyJrNOCLXScSLpA== X-Received: by 2002:a17:902:c151:b0:1aa:cf25:41d0 with SMTP id 17-20020a170902c15100b001aacf2541d0mr14164593plj.33.1684870268211; Tue, 23 May 2023 12:31:08 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:af98:af9d:ed15:f8b3]) by smtp.gmail.com with ESMTPSA id y18-20020a170902b49200b001aaef9d0102sm7109947plr.197.2023.05.23.12.31.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 May 2023 12:31:07 -0700 (PDT) From: Douglas Anderson <dianders@chromium.org> To: Jiri Kosina <jikos@kernel.org>, Benjamin Tissoires <benjamin.tissoires@redhat.com>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Neil Armstrong <neil.armstrong@linaro.org>, Sam Ravnborg <sam@ravnborg.org>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de> Cc: dri-devel@lists.freedesktop.org, linux-input@vger.kernel.org, Dmitry Torokhov <dmitry.torokhov@gmail.com>, hsinyi@google.com, devicetree@vger.kernel.org, yangcong5@huaqin.corp-partner.google.com, linux-kernel@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>, linux-arm-msm@vger.kernel.org, cros-qcom-dts-watchers@chromium.org, Douglas Anderson <dianders@chromium.org> Subject: [PATCH 0/9] drm/panel and i2c-hid: Allow panels and touchscreens to power sequence together Date: Tue, 23 May 2023 12:27:54 -0700 Message-ID: <20230523193017.4109557-1-dianders@chromium.org> X-Mailer: git-send-email 2.40.1.698.g37aff9b760-goog 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,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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?1766714988918398652?= X-GMAIL-MSGID: =?utf-8?q?1766714988918398652?= |
Series |
drm/panel and i2c-hid: Allow panels and touchscreens to power sequence together
|
|
Message
Doug Anderson
May 23, 2023, 7:27 p.m. UTC
The big motivation for this patch series is mostly described in the patch ("drm/panel: Add a way for other devices to follow panel state"), but to quickly summarize here: for touchscreens that are connected to a panel we need the ability to power sequence the two device together. This is not a new need, but so far we've managed to get by through a combination of inefficiency, added costs, or perhaps just a little bit of brokenness. It's time to do better. This patch series allows us to do better. Assuming that people think this patch series looks OK, we'll have to figure out the right way to land it. The panel patches and i2c-hid patches will go through very different trees and so either we'll need an Ack from one side or the other or someone to create a tag for the other tree to pull in. This will _probably_ require the true drm-misc maintainers to get involved, not a lowly committer. ;-) Douglas Anderson (9): dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed panels drm/panel: Check for already prepared/enabled in drm_panel drm/panel: Add a way for other devices to follow panel state HID: i2c-hid: Switch to SYSTEM_SLEEP_PM_OPS() HID: i2c-hid: Rearrange probe() to power things up later HID: i2c-hid: Make suspend and resume into helper functions HID: i2c-hid: Support being a panel follower HID: i2c-hid: Do panel follower work on the system_wq arm64: dts: qcom: sc7180: Link trogdor touchscreens to the panels .../bindings/input/elan,ekth6915.yaml | 6 + .../bindings/input/goodix,gt7375p.yaml | 6 + .../bindings/input/hid-over-i2c.yaml | 6 + .../boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 1 + .../dts/qcom/sc7180-trogdor-homestar.dtsi | 1 + .../boot/dts/qcom/sc7180-trogdor-lazor.dtsi | 1 + .../boot/dts/qcom/sc7180-trogdor-pompom.dtsi | 1 + .../qcom/sc7180-trogdor-quackingstick.dtsi | 1 + .../dts/qcom/sc7180-trogdor-wormdingler.dtsi | 1 + drivers/gpu/drm/drm_panel.c | 194 +++++++++- drivers/hid/i2c-hid/i2c-hid-core.c | 330 +++++++++++++----- include/drm/drm_panel.h | 89 +++++ 12 files changed, 542 insertions(+), 95 deletions(-)
Comments
Hi Doug, On Tue, May 23, 2023 at 12:27:54PM -0700, Douglas Anderson wrote: > > The big motivation for this patch series is mostly described in the patch > ("drm/panel: Add a way for other devices to follow panel state"), but to > quickly summarize here: for touchscreens that are connected to a panel we > need the ability to power sequence the two device together. This is not a > new need, but so far we've managed to get by through a combination of > inefficiency, added costs, or perhaps just a little bit of brokenness. > It's time to do better. This patch series allows us to do better. This seems to grow a new way of building relationship between panels and associated devices. Can we make device_link_*() work for us? Thanks.
Hi, On Tue, May 23, 2023 at 2:39 PM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > Hi Doug, > > On Tue, May 23, 2023 at 12:27:54PM -0700, Douglas Anderson wrote: > > > > The big motivation for this patch series is mostly described in the patch > > ("drm/panel: Add a way for other devices to follow panel state"), but to > > quickly summarize here: for touchscreens that are connected to a panel we > > need the ability to power sequence the two device together. This is not a > > new need, but so far we've managed to get by through a combination of > > inefficiency, added costs, or perhaps just a little bit of brokenness. > > It's time to do better. This patch series allows us to do better. > > This seems to grow a new way of building relationship between panels and > associated devices. Can we make device_link_*() work for us? If you know of a way to make it work, that'd be great. ...but I don't _think_ it would be that easy. I haven't spent much time with the device_link APIs, though, so please correct me if I'm wrong. I guess my main issue with device_link would be that that ordering feels backward. Specifically, the device we're acting on (the one we're turning off and on) is the panel. We typically turn the panel off and on at times (during a modeset, when the lid is closed, or just if the system is idle). When this happens we'd like to remove power from both the panel and the touchscreen. Userspace is just not setup to power off touchscreens in tandem with the panel and sometimes (like in the case of a modeset) it might not even know it needs to. With device_link I believe that the "child" device is in charge of powering the parent. I think that would mean that to use device_link we'd need to make the panel be the child of the touchscreen. Then, I guess we'd tell the touchscreen not to power itself on if it had children and just wait for a child to power it on? It feels really awkward partly because the panel doesn't feel like it should be a child of the touchscreen and partially because it seems weird that the touchscreen would somehow need to know not to request power for itself when it has a child. ...if we're willing to accept the backwardness as described above and we can find a hack to keep the touchscreen from powering itself up, then I think things could be made to work OK-ish. I can try to investigate that route if it doesn't feel too ugly. ...oh, except for another problem. The initial power up of the i2c-hid device would also be a problem here. I guess with device_link we'd need to put all the power up work into "runtime resume". The problem is that upon initial power up we create "HID" sub-devices and (as far as I could tell) you can't do that during a runtime resume. :( We could put a special case to power the touchscreen up before the panel at probe time, but that could have other consequences? If we don't go with the backwardness then I think we're a bit stuck with some of the original problems. Specifically it means that unless userspace knows to turn off the touchscreen that the touchscreen would force the panel to never be power cycled. There's at least one panel (the one on sc7180-trogdor-homestar) where that's known to be a problem. It also means that we're back to drawing extra power if the touchscreen is left "on" but the panel power is turned off. Let me know if I'm misunderstanding. -Doug
On 23.05.2023 21:27, Douglas Anderson wrote: > > The big motivation for this patch series is mostly described in the patch > ("drm/panel: Add a way for other devices to follow panel state"), but to > quickly summarize here: for touchscreens that are connected to a panel we > need the ability to power sequence the two device together. This is not a > new need, but so far we've managed to get by through a combination of > inefficiency, added costs, or perhaps just a little bit of brokenness. > It's time to do better. This patch series allows us to do better. Panels with integrated touchscreens have been shipping in mainstream devices since at least 2016. Thanks a lot for looking into this! Konrad > > Assuming that people think this patch series looks OK, we'll have to > figure out the right way to land it. The panel patches and i2c-hid > patches will go through very different trees and so either we'll need > an Ack from one side or the other or someone to create a tag for the > other tree to pull in. This will _probably_ require the true drm-misc > maintainers to get involved, not a lowly committer. ;-) > > > Douglas Anderson (9): > dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed > panels > drm/panel: Check for already prepared/enabled in drm_panel > drm/panel: Add a way for other devices to follow panel state > HID: i2c-hid: Switch to SYSTEM_SLEEP_PM_OPS() > HID: i2c-hid: Rearrange probe() to power things up later > HID: i2c-hid: Make suspend and resume into helper functions > HID: i2c-hid: Support being a panel follower > HID: i2c-hid: Do panel follower work on the system_wq > arm64: dts: qcom: sc7180: Link trogdor touchscreens to the panels > > .../bindings/input/elan,ekth6915.yaml | 6 + > .../bindings/input/goodix,gt7375p.yaml | 6 + > .../bindings/input/hid-over-i2c.yaml | 6 + > .../boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 1 + > .../dts/qcom/sc7180-trogdor-homestar.dtsi | 1 + > .../boot/dts/qcom/sc7180-trogdor-lazor.dtsi | 1 + > .../boot/dts/qcom/sc7180-trogdor-pompom.dtsi | 1 + > .../qcom/sc7180-trogdor-quackingstick.dtsi | 1 + > .../dts/qcom/sc7180-trogdor-wormdingler.dtsi | 1 + > drivers/gpu/drm/drm_panel.c | 194 +++++++++- > drivers/hid/i2c-hid/i2c-hid-core.c | 330 +++++++++++++----- > include/drm/drm_panel.h | 89 +++++ > 12 files changed, 542 insertions(+), 95 deletions(-) >