Message ID | 20230727171750.633410-1-dianders@chromium.org |
---|---|
Headers | show |
Series | drm/panel and i2c-hid: Allow panels and touchscreens to power sequence together | expand |
On Jul 27 2023, 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 4 of this series adds a new patch that suspends i2c-hid > devices at remove time even for non panel-followers to make things > consistent. It also attempts to isolate the panel follower code a bit > more as per Benjamin's feedback on v3 and adds an item to the DRM todo > list as per Maxime's request. As per Maxime's response to my v3 cover > letter, I added his Reviewed-by tag to all 10 patches that were part > of v3 (but left it off of the new i2c-hid patch in v4). > > Version 3 of this series was a long time coming after v2. Maxime and I > had a very long discussion trying to figure out if there was a beter > way and in the end we didn't find one so he was OK with the series in > general [1]. After that got resolved, I tried to resolve Benjamin's > feedback but got stuck [2]. Eventually I made my best guess. The end > result was a v3 that wasn't that different from v2 but that had a tiny > bit more code split out. > > Version 2 of this patch series didn'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. > > As far as I can tell, as of v4 everyone is on the same page that this > patch series looks like a reasonable solution to the problem and we > just need to get all the nits fixed and figure out how to land it. Thanks a lot for the new version. I like it much more on the HID side: for the HID part: Reviewed-by: Benjamin Tissoires <bentiss@kernel.org> I wouldn't mind having this series taken from the drm tree if that is easier. i2c-hid is a low patch rate driver, so having it updated through DRM should not be an issue. In that case: Acked-by: Benjamin Tissoires <bentiss@kernel.org> Cheers, Benjamin > > [1] https://lore.kernel.org/r/gkwymmfkdy2p2evz22wmbwgw42ii4wnvmvu64m3bghmj2jhv7x@4mbstjxnagxd > [2] https://lore.kernel.org/r/CAD=FV=VbdeomBGbWhppY+5TOSwt64GWBHga68OXFwsnO4gg4UA@mail.gmail.com > > Changes in v4: > - Document further cleanup in the official DRM todo list. > - ("Suspend i2c-hid devices in remove") new for v4. > - Move panel follower alternative checks to wrapper functions. > - Rebase atop ("Suspend i2c-hid devices in remove"). > > Changes in v3: > - Add is_panel_follower() as a convenience for clients. > - Add "depends on DRM || !DRM" to Kconfig to avoid randconfig error. > - Split more of the panel follower code out of the core. > > Changes in v2: > - Move the description to the generic touchscreen.yaml. > - Update the desc to make it clearer it's only for integrated devices. > - Add even more text to the commit message. > - A few comment cleanups. > - ("Add a devlink for panel followers") new for v2. > - i2c_hid_core_initial_power_up() is now static. > - i2c_hid_core_panel_prepared() and ..._unpreparing() are now static. > - ihid_core_panel_prepare_work() is now static. > - Improve documentation for smp_wmb(). > > Douglas Anderson (11): > dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed > touchscreens > drm/panel: Check for already prepared/enabled in drm_panel > drm/panel: Add a way for other devices to follow panel state > of: property: fw_devlink: Add a devlink for panel followers > 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: Suspend i2c-hid devices in remove > 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 | 5 + > .../bindings/input/goodix,gt7375p.yaml | 5 + > .../bindings/input/hid-over-i2c.yaml | 2 + > .../input/touchscreen/touchscreen.yaml | 7 + > Documentation/gpu/todo.rst | 24 ++ > .../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 | 218 ++++++++++- > drivers/hid/i2c-hid/Kconfig | 2 + > drivers/hid/i2c-hid/i2c-hid-core.c | 349 +++++++++++++----- > drivers/of/property.c | 2 + > include/drm/drm_panel.h | 94 +++++ > 16 files changed, 617 insertions(+), 97 deletions(-) > > -- > 2.41.0.487.g6d72f3e995-goog >
Hi, On Fri, Jul 28, 2023 at 8:31 AM Benjamin Tissoires <bentiss@kernel.org> wrote: > > On Jul 27 2023, 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 4 of this series adds a new patch that suspends i2c-hid > > devices at remove time even for non panel-followers to make things > > consistent. It also attempts to isolate the panel follower code a bit > > more as per Benjamin's feedback on v3 and adds an item to the DRM todo > > list as per Maxime's request. As per Maxime's response to my v3 cover > > letter, I added his Reviewed-by tag to all 10 patches that were part > > of v3 (but left it off of the new i2c-hid patch in v4). > > > > Version 3 of this series was a long time coming after v2. Maxime and I > > had a very long discussion trying to figure out if there was a beter > > way and in the end we didn't find one so he was OK with the series in > > general [1]. After that got resolved, I tried to resolve Benjamin's > > feedback but got stuck [2]. Eventually I made my best guess. The end > > result was a v3 that wasn't that different from v2 but that had a tiny > > bit more code split out. > > > > Version 2 of this patch series didn'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. > > > > As far as I can tell, as of v4 everyone is on the same page that this > > patch series looks like a reasonable solution to the problem and we > > just need to get all the nits fixed and figure out how to land it. > > Thanks a lot for the new version. I like it much more on the HID side: > > for the HID part: > Reviewed-by: Benjamin Tissoires <bentiss@kernel.org> > > I wouldn't mind having this series taken from the drm tree if that is > easier. i2c-hid is a low patch rate driver, so having it updated through > DRM should not be an issue. > > In that case: > Acked-by: Benjamin Tissoires <bentiss@kernel.org> Thanks for your reviews and your help getting this whipped into shape. Lading through drm makes sense to me. I'm a drm committer, so with your Ack I believe it should be fine for me to land the series (minus the dts) in drm-misc-next. This series has been around for a while, has been reviewed by relevant folks, and the last few changes haven't fundamentally changed anything about the design, so I'm not going to twiddle my thumbs too long. That being said, I'll still plan to wait until early next week (Tuesday?) before landing to allow for any last minute shouts. Given how drm-misc works [1] and the fact that mainline is currently at v6.5-rc3 (it will be -rc4 when I land it), I'd expect that these commits will find their way into v6.6. [1] https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
Hi, On Fri, Jul 28, 2023 at 10:24 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Fri, Jul 28, 2023 at 8:31 AM Benjamin Tissoires <bentiss@kernel.org> wrote: > > > > On Jul 27 2023, 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 4 of this series adds a new patch that suspends i2c-hid > > > devices at remove time even for non panel-followers to make things > > > consistent. It also attempts to isolate the panel follower code a bit > > > more as per Benjamin's feedback on v3 and adds an item to the DRM todo > > > list as per Maxime's request. As per Maxime's response to my v3 cover > > > letter, I added his Reviewed-by tag to all 10 patches that were part > > > of v3 (but left it off of the new i2c-hid patch in v4). > > > > > > Version 3 of this series was a long time coming after v2. Maxime and I > > > had a very long discussion trying to figure out if there was a beter > > > way and in the end we didn't find one so he was OK with the series in > > > general [1]. After that got resolved, I tried to resolve Benjamin's > > > feedback but got stuck [2]. Eventually I made my best guess. The end > > > result was a v3 that wasn't that different from v2 but that had a tiny > > > bit more code split out. > > > > > > Version 2 of this patch series didn'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. > > > > > > As far as I can tell, as of v4 everyone is on the same page that this > > > patch series looks like a reasonable solution to the problem and we > > > just need to get all the nits fixed and figure out how to land it. > > > > Thanks a lot for the new version. I like it much more on the HID side: > > > > for the HID part: > > Reviewed-by: Benjamin Tissoires <bentiss@kernel.org> > > > > I wouldn't mind having this series taken from the drm tree if that is > > easier. i2c-hid is a low patch rate driver, so having it updated through > > DRM should not be an issue. > > > > In that case: > > Acked-by: Benjamin Tissoires <bentiss@kernel.org> > > Thanks for your reviews and your help getting this whipped into shape. > > Lading through drm makes sense to me. I'm a drm committer, so with > your Ack I believe it should be fine for me to land the series (minus > the dts) in drm-misc-next. This series has been around for a while, > has been reviewed by relevant folks, and the last few changes haven't > fundamentally changed anything about the design, so I'm not going to > twiddle my thumbs too long. That being said, I'll still plan to wait > until early next week (Tuesday?) before landing to allow for any last > minute shouts. > > Given how drm-misc works [1] and the fact that mainline is currently > at v6.5-rc3 (it will be -rc4 when I land it), I'd expect that these > commits will find their way into v6.6. > > [1] https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html Pushed the first 10 patches to drm-misc-next. Bjorn: whenever it's convenient you could land patch #11 (the device tree change) into the Qualcomm tree. 76edfcf430cc HID: i2c-hid: Do panel follower work on the system_wq 96a37bfd232a HID: i2c-hid: Support being a panel follower 5f8838e9405d HID: i2c-hid: Suspend i2c-hid devices in remove d93d28477222 HID: i2c-hid: Make suspend and resume into helper functions 675cd877c952 HID: i2c-hid: Rearrange probe() to power things up later a889ee12d53d HID: i2c-hid: Switch to SYSTEM_SLEEP_PM_OPS() fbf0ea2da3c7 of: property: fw_devlink: Add a devlink for panel followers de0874165b83 drm/panel: Add a way for other devices to follow panel state d2aacaf07395 drm/panel: Check for already prepared/enabled in drm_panel 2ca376ef18f6 dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed touchscreens -Doug
Hi, On Thu, Jul 27, 2023 at 10:19 AM Douglas Anderson <dianders@chromium.org> wrote: > > Let's provide the proper link from the touchscreen to the panel on > trogdor devices where the touchscreen support it. This allows the OS > to power sequence the touchscreen more properly. > > For the most part, this is just expected to marginally improve power > consumption while the screen is off. However, in at least one trogdor > model (wormdingler) it's suspected that this will fix some behavorial > corner cases when the panel power cycles (like for a modeset) without > the touchscreen power cycling. > > NOTE: some trogdor variants use touchscreens that don't (yet) support > linking the touchscreen and the panel. Those variants are left alone. > > Reviewed-by: Maxime Ripard <mripard@kernel.org> > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > > (no changes since v1) > > arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 1 + > arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar.dtsi | 1 + > arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi | 1 + > arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi | 1 + > arch/arm64/boot/dts/qcom/sc7180-trogdor-quackingstick.dtsi | 1 + > arch/arm64/boot/dts/qcom/sc7180-trogdor-wormdingler.dtsi | 1 + > 6 files changed, 6 insertions(+) FWIW, this old patch could land any time. All the earlier patches in the series have landed. -Doug