From: Doug Anderson <dianders@chromium.org> To: Maxime Ripard <mripard@kernel.org> Cc: 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>, Frank Rowand <frowand.list@gmail.com>, 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>, Thomas Zimmermann <tzimmermann@suse.de>, dri-devel@lists.freedesktop.org, Dmitry Torokhov <dmitry.torokhov@gmail.com>, linux-input@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>, linux-kernel@vger.kernel.org, hsinyi@google.com, cros-qcom-dts-watchers@chromium.org, devicetree@vger.kernel.org, yangcong5@huaqin.corp-partner.google.com, linux-arm-msm@vger.kernel.org, Chris Morgan <macroalpha82@gmail.com> Subject: Re: [PATCH v2 00/10] drm/panel and i2c-hid: Allow panels and touchscreens to power sequence together Date: Thu, 8 Jun 2023 07:38:58 -0700 [thread overview] Message-ID: <CAD=FV=Wr7Xatw1LsofiZ5Xx7WBvAuMMdq4D5Po1yJUC1VdtZdg@mail.gmail.com> (raw) In-Reply-To: <jehxiy3z4aieop5qgzmlon4u76n7gvt3kc6knxhb5yqkiz3rsp@mx27m75sx43r> Hi, On Thu, Jun 8, 2023 at 12:17 AM Maxime Ripard <mripard@kernel.org> wrote: > > Hi Douglas, > > On Wed, Jun 07, 2023 at 02:49:22PM -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. > > > > 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. ;-) > > > > Version 2 of this patch series doesn't change too much. At a high level: > > * I added all the forgotten "static" to functions. > > * I've hopefully made the bindings better. > > * I've integrated into fw_devlink. > > * I cleaned up a few descriptions / comments. > > > > This still needs someone to say that the idea looks OK or to suggest > > an alternative that solves the problems. ;-) > > Thanks for working on this. > > I haven't seen in any of your commit messages how the panels were > actually "packaged" together? > > Do a panel model typically come together with the i2c-hid support, or is > it added at manufacture time? > > If it's the latter, it's indeed a fairly loose connection and we need > your work. > > If it's the former though and we don't expect a given panel reference to > always (or never) come with a touchscreen attached, Thanks for your reply. Let me see what I can do to bring clarity. In at least some of the cases, I believe that the panel and the touchscreen _are_ logically distinct components, even if they've been glued together at some stage in manufacturing. Even on one of the "poster child" boards that I talk about in patch #3, the early versions of "homestar", I believe this to be the case. However, even if the panel and touchscreen are separate components then they still could be connected to the main board in a way that they share power and/or reset signals. In my experience, in every case where they do the EEs expect that the panel is power sequenced first and then the touchscreen is power sequenced second. The EEs look at the power sequencing requirements of the panel and touchscreen, see that there is a valid power sequence protocol where they can share rails, and design the board that way. Even if the touchscreen and panel are logically separate, the moment the board designers hook them up to the same power rails and/or reset signals they become tied. This is well supported by my patch series. The case that really motivated my patch series, though, is the case that Cong Yang recently has been working on. I think most of the discussion is in his original patch series [1]. Cong Yang's patch series is largely focused on supporting the "ILI9882T" chip and some panels that it's used with. I found a datasheet for that, and the title from the first page is illustrative: "In-cell IC Integrates TFT LCD Driver and Capacitive Touch Controller into a Two Chip Cascade". This is an integrated solution that's designed to handle both the LCD and the touchscreen. [1] https://lore.kernel.org/lkml/20230519032316.3464732-1-yangcong5@huaqin.corp-partner.google.com/ > I guess we can have > something much simpler with a bunch of helpers that would register a > i2c-hid device and would be called by the panel driver itself. > > And then, since everything is self-contained managing the power state > becomes easier as well. Can you give me more details about how you think this would work? When you say that the panel would register an i2c-hid device itself, do you mean that we'd do something like give a phandle to the i2c bus to the panel and then the panel would manually instantiate the i2c-hid device on it? ...and I guess it would need to be a "subclass" of i2c-hid that knew about the connection to the panel code? This subclass and the panel code would communicate with each other about power sequencing needs through some private API (like MFD devices usually do?). Assuming I'm understanding correctly, I think that could work. Is it cleaner than my current approach, though? I guess, alternatively, we could put the "panel" directly under the i2c bus in this case. That would probably work for Cong Yang's current needs, but we'd end up in trouble if we ever had a similar situation with an eDP panel since eDP panels need to be under the DP-AUX bus. I guess overall, though, while I think this approach could solve Cong Yang's needs, I still feel like it's worth solving the case where board designers have made panel and touchscreens "coupled" by having them rely on the same power rails and/or reset signals. -Doug
WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@chromium.org> To: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org, Chris Morgan <macroalpha82@gmail.com>, Benjamin Tissoires <benjamin.tissoires@redhat.com>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Sam Ravnborg <sam@ravnborg.org>, Frank Rowand <frowand.list@gmail.com>, linux-input@vger.kernel.org, hsinyi@google.com, devicetree@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>, cros-qcom-dts-watchers@chromium.org, linux-arm-msm@vger.kernel.org, yangcong5@huaqin.corp-partner.google.com, Jiri Kosina <jikos@kernel.org>, Rob Herring <robh+dt@kernel.org>, Neil Armstrong <neil.armstrong@linaro.org>, Bjorn Andersson <andersson@kernel.org>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, linux-kernel@vger.kernel.org, Konrad Dybcio <konrad.dybcio@linaro.org>, Thomas Zimmermann <tzimmermann@suse.de> Subject: Re: [PATCH v2 00/10] drm/panel and i2c-hid: Allow panels and touchscreens to power sequence together Date: Thu, 8 Jun 2023 07:38:58 -0700 [thread overview] Message-ID: <CAD=FV=Wr7Xatw1LsofiZ5Xx7WBvAuMMdq4D5Po1yJUC1VdtZdg@mail.gmail.com> (raw) In-Reply-To: <jehxiy3z4aieop5qgzmlon4u76n7gvt3kc6knxhb5yqkiz3rsp@mx27m75sx43r> Hi, On Thu, Jun 8, 2023 at 12:17 AM Maxime Ripard <mripard@kernel.org> wrote: > > Hi Douglas, > > On Wed, Jun 07, 2023 at 02:49:22PM -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. > > > > 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. ;-) > > > > Version 2 of this patch series doesn't change too much. At a high level: > > * I added all the forgotten "static" to functions. > > * I've hopefully made the bindings better. > > * I've integrated into fw_devlink. > > * I cleaned up a few descriptions / comments. > > > > This still needs someone to say that the idea looks OK or to suggest > > an alternative that solves the problems. ;-) > > Thanks for working on this. > > I haven't seen in any of your commit messages how the panels were > actually "packaged" together? > > Do a panel model typically come together with the i2c-hid support, or is > it added at manufacture time? > > If it's the latter, it's indeed a fairly loose connection and we need > your work. > > If it's the former though and we don't expect a given panel reference to > always (or never) come with a touchscreen attached, Thanks for your reply. Let me see what I can do to bring clarity. In at least some of the cases, I believe that the panel and the touchscreen _are_ logically distinct components, even if they've been glued together at some stage in manufacturing. Even on one of the "poster child" boards that I talk about in patch #3, the early versions of "homestar", I believe this to be the case. However, even if the panel and touchscreen are separate components then they still could be connected to the main board in a way that they share power and/or reset signals. In my experience, in every case where they do the EEs expect that the panel is power sequenced first and then the touchscreen is power sequenced second. The EEs look at the power sequencing requirements of the panel and touchscreen, see that there is a valid power sequence protocol where they can share rails, and design the board that way. Even if the touchscreen and panel are logically separate, the moment the board designers hook them up to the same power rails and/or reset signals they become tied. This is well supported by my patch series. The case that really motivated my patch series, though, is the case that Cong Yang recently has been working on. I think most of the discussion is in his original patch series [1]. Cong Yang's patch series is largely focused on supporting the "ILI9882T" chip and some panels that it's used with. I found a datasheet for that, and the title from the first page is illustrative: "In-cell IC Integrates TFT LCD Driver and Capacitive Touch Controller into a Two Chip Cascade". This is an integrated solution that's designed to handle both the LCD and the touchscreen. [1] https://lore.kernel.org/lkml/20230519032316.3464732-1-yangcong5@huaqin.corp-partner.google.com/ > I guess we can have > something much simpler with a bunch of helpers that would register a > i2c-hid device and would be called by the panel driver itself. > > And then, since everything is self-contained managing the power state > becomes easier as well. Can you give me more details about how you think this would work? When you say that the panel would register an i2c-hid device itself, do you mean that we'd do something like give a phandle to the i2c bus to the panel and then the panel would manually instantiate the i2c-hid device on it? ...and I guess it would need to be a "subclass" of i2c-hid that knew about the connection to the panel code? This subclass and the panel code would communicate with each other about power sequencing needs through some private API (like MFD devices usually do?). Assuming I'm understanding correctly, I think that could work. Is it cleaner than my current approach, though? I guess, alternatively, we could put the "panel" directly under the i2c bus in this case. That would probably work for Cong Yang's current needs, but we'd end up in trouble if we ever had a similar situation with an eDP panel since eDP panels need to be under the DP-AUX bus. I guess overall, though, while I think this approach could solve Cong Yang's needs, I still feel like it's worth solving the case where board designers have made panel and touchscreens "coupled" by having them rely on the same power rails and/or reset signals. -Doug
next prev parent reply other threads:[~2023-06-08 14:39 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-06-07 21:49 [PATCH v2 00/10] drm/panel and i2c-hid: Allow panels and touchscreens to power sequence together Douglas Anderson 2023-06-07 21:49 ` Douglas Anderson 2023-06-07 21:49 ` [PATCH v2 01/10] dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed touchscreens Douglas Anderson 2023-06-07 21:49 ` Douglas Anderson 2023-06-09 15:53 ` Krzysztof Kozlowski 2023-06-09 15:53 ` Krzysztof Kozlowski 2023-06-07 21:49 ` [PATCH v2 02/10] drm/panel: Check for already prepared/enabled in drm_panel Douglas Anderson 2023-06-07 21:49 ` Douglas Anderson 2023-06-07 21:49 ` [PATCH v2 03/10] drm/panel: Add a way for other devices to follow panel state Douglas Anderson 2023-06-07 21:49 ` Douglas Anderson 2023-06-07 21:49 ` [PATCH v2 04/10] of: property: fw_devlink: Add a devlink for panel followers Douglas Anderson 2023-06-07 21:49 ` Douglas Anderson 2023-06-09 16:10 ` Rob Herring 2023-06-09 16:10 ` Rob Herring 2023-06-07 21:49 ` [PATCH v2 05/10] HID: i2c-hid: Switch to SYSTEM_SLEEP_PM_OPS() Douglas Anderson 2023-06-07 21:49 ` Douglas Anderson 2023-06-07 21:49 ` [PATCH v2 06/10] HID: i2c-hid: Rearrange probe() to power things up later Douglas Anderson 2023-06-07 21:49 ` Douglas Anderson 2023-06-07 21:49 ` [PATCH v2 07/10] HID: i2c-hid: Make suspend and resume into helper functions Douglas Anderson 2023-06-07 21:49 ` Douglas Anderson 2023-06-07 21:49 ` [PATCH v2 08/10] HID: i2c-hid: Support being a panel follower Douglas Anderson 2023-06-07 21:49 ` Douglas Anderson 2023-06-08 5:18 ` kernel test robot 2023-06-08 5:18 ` kernel test robot 2023-06-08 7:14 ` kernel test robot 2023-06-08 7:14 ` kernel test robot 2023-06-08 15:10 ` Doug Anderson 2023-06-08 15:10 ` Doug Anderson 2023-06-08 15:36 ` Benjamin Tissoires 2023-06-08 15:36 ` Benjamin Tissoires 2023-06-08 16:42 ` Doug Anderson 2023-06-08 16:42 ` Doug Anderson 2023-06-09 9:27 ` Benjamin Tissoires 2023-06-09 9:27 ` Benjamin Tissoires 2023-06-09 15:01 ` Doug Anderson 2023-06-09 15:01 ` Doug Anderson 2023-06-26 22:49 ` Doug Anderson 2023-06-26 22:49 ` Doug Anderson 2023-07-17 18:15 ` Doug Anderson 2023-07-17 18:15 ` Doug Anderson 2023-07-25 20:41 ` Doug Anderson 2023-07-25 20:41 ` Doug Anderson 2023-07-26 8:07 ` Benjamin Tissoires 2023-07-26 8:07 ` Benjamin Tissoires 2023-06-07 21:49 ` [PATCH v2 09/10] HID: i2c-hid: Do panel follower work on the system_wq Douglas Anderson 2023-06-07 21:49 ` Douglas Anderson 2023-06-07 21:49 ` [PATCH v2 10/10] arm64: dts: qcom: sc7180: Link trogdor touchscreens to the panels Douglas Anderson 2023-06-07 21:49 ` Douglas Anderson 2023-06-08 7:17 ` [PATCH v2 00/10] drm/panel and i2c-hid: Allow panels and touchscreens to power sequence together Maxime Ripard 2023-06-08 7:17 ` Maxime Ripard 2023-06-08 14:38 ` Doug Anderson [this message] 2023-06-08 14:38 ` Doug Anderson 2023-06-12 16:03 ` Maxime Ripard 2023-06-12 16:03 ` Maxime Ripard 2023-06-12 21:13 ` Doug Anderson 2023-06-12 21:13 ` Doug Anderson 2023-06-13 12:06 ` Maxime Ripard 2023-06-13 12:06 ` Maxime Ripard 2023-06-13 15:56 ` Doug Anderson 2023-06-13 15:56 ` Doug Anderson 2023-06-21 16:31 ` Doug Anderson 2023-06-21 16:31 ` Doug Anderson 2023-06-23 9:08 ` Maxime Ripard 2023-06-23 9:08 ` Maxime Ripard
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAD=FV=Wr7Xatw1LsofiZ5Xx7WBvAuMMdq4D5Po1yJUC1VdtZdg@mail.gmail.com' \ --to=dianders@chromium.org \ --cc=andersson@kernel.org \ --cc=benjamin.tissoires@redhat.com \ --cc=conor+dt@kernel.org \ --cc=cros-qcom-dts-watchers@chromium.org \ --cc=daniel@ffwll.ch \ --cc=devicetree@vger.kernel.org \ --cc=dmitry.torokhov@gmail.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=frowand.list@gmail.com \ --cc=hsinyi@google.com \ --cc=jikos@kernel.org \ --cc=konrad.dybcio@linaro.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=maarten.lankhorst@linux.intel.com \ --cc=macroalpha82@gmail.com \ --cc=mripard@kernel.org \ --cc=neil.armstrong@linaro.org \ --cc=robh+dt@kernel.org \ --cc=sam@ravnborg.org \ --cc=tzimmermann@suse.de \ --cc=yangcong5@huaqin.corp-partner.google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.