|
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43 |
|
| #
2ca376ef |
| 27-Jul-2023 |
Douglas Anderson <dianders@chromium.org> |
dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed touchscreens
As talked about in the patch ("drm/panel: Add a way for other devices
to follow panel state"), touchscreens that are co
dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed touchscreens
As talked about in the patch ("drm/panel: Add a way for other devices
to follow panel state"), touchscreens that are connected to panels are
generally expected to be power sequenced together with the panel
they're attached to. Today, nothing provides information allowing you
to find out that a touchscreen is connected to a panel. Let's add a
phandle for this.
The proerty is added to the generic touchscreen bindings and then
enabled in the bindings for the i2c-hid backed devices. This can and
should be added for other touchscreens in the future, but for now
let's start small.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Benjamin Tissoires <bentiss@kernel.org>
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.1.Id68e30343bb1e11470582a9078b086176cfec46b@changeid
show more ...
|
|
Revision tags: v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42 |
|
| #
ded3021e |
| 23-May-2022 |
Douglas Anderson <dianders@chromium.org> |
dt-bindings: HID: i2c-hid: elan: Introduce bindings for Elan eKTH6915
Like many i2c-hid touchscreen controllers, the Elan eKTH6915
controller has a reset gpio. For the Goodix GT7375P touchscreen the
dt-bindings: HID: i2c-hid: elan: Introduce bindings for Elan eKTH6915
Like many i2c-hid touchscreen controllers, the Elan eKTH6915
controller has a reset gpio. For the Goodix GT7375P touchscreen the
decision was to add a new binding rather than trying to add a new GPIO
to the existing i2c-hid binding. We'll follow the lead and do it here,
too.
SIDE NOTE: the Elan eKTH6915 is a touchscreen _controller_ that's
included as a part on some touchscreens. The reset line isn't truly
necessary for the functioning of the touchscreen, so it's possible
that some designs won't have it hooked up and will just guarantee the
power sequencing requirements with RLC circuits. Thus, we'll mark the
reset gpio as optional.
Note that if the reset GPIO isn't used there's actually no true need
to use the "elan,ekth6915" compatible instead of the "hid-over-i2c" on
Linux. However:
- Officially using just "hid-over-i2c" for this device violates the
existing "hid-over-i2c" bindings. The bindings say that you're not
supposed to use "post-power-on-delay-ms" without specifying a more
specific compatible. Currently the Linux driver doesn't enforce
this, but it violates the bindings to just use
"hid-over-i2c". ...and if you're going to add a more specific
compatible anyway, might as well do it right.
- Using this compatible means we don't need to specify
"hid-descr-addr" since it's inferred from the compatible.
- Using this compatible means that the regulator names match the names
on the Elan datasheet (vcc33 / vccio) vs the generic hid-over-i2c
(vdd / vddl).
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
show more ...
|