* Re: [PATCH v2 1/2] dt-bindings: input: touchscreen: Add ilitek 9882T touchscreen chip
From: Rob Herring @ 2023-06-09 22:03 UTC (permalink / raw)
To: cong yang
Cc: Conor Dooley, krzysztof.kozlowski+dt, conor+dt, dmitry.torokhov,
jikos, benjamin.tissoires, dianders, hsinyi, linux-input,
devicetree, linux-kernel
In-Reply-To: <CAHwB_NK_j1SJ1BBkVqafFM_+fWSyvwjCpMmHQxjLjnz_KHR=KA@mail.gmail.com>
On Tue, Jun 06, 2023 at 10:06:05AM +0800, cong yang wrote:
> Hi,Conor,
>
> On Mon, Jun 5, 2023 at 6:20 PM Conor Dooley <conor@kernel.org> wrote:
> >
> > Hey Cong Yang,
> >
> > On Mon, Jun 05, 2023 at 02:05:23PM +0800, Cong Yang wrote:
> > > Add an ilitek touch screen chip ili9882t.
> >
> > Could you add a comment here mentioning the relationship between these
> > chips?
>
> Okay, I will add in V3 version.
>
> > On Mon, Jun 05, 2023 at 02:05:23PM +0800, Cong Yang wrote:
> >
> > > Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
> > > ---
> > > .../bindings/input/elan,ekth6915.yaml | 23 ++++++++++++++++---
> > > 1 file changed, 20 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> > > index 05e6f2df604c..f0e7ffdce605 100644
> > > --- a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> > > +++ b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> > > @@ -15,11 +15,14 @@ description:
> > >
> > > properties:
> > > compatible:
> > > - items:
> > > - - const: elan,ekth6915
> > > + enum:
> > > + - elan,ekth6915
> > > + - ilitek,ili9882t
> > >
> > > reg:
> > > - const: 0x10
> > > + enum:
> > > + - 0x10
> > > + - 0x41
> >
> > Is 0x10 only valid for the elan,ekth6915 & 0x41 for the ilitek one?
> > If so, please add some enforcement of the values based on the
> > compatible.
>
> I don't think 0x10 is the only address for ekth6915,(nor is 0x41 the
> only address for ili9882t). It depends on the hardware design.
I'd just drop the values as we don't typically enforce 'reg' values.
Rob
^ permalink raw reply
* Re: [PATCH] Input: ads7846 - fix pointer cast warning
From: Linus Walleij @ 2023-06-09 21:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Dmitry Torokhov, Arnd Bergmann, kernel test robot,
Andy Shevchenko, Luca Ellero, Jonathan Cameron, linux-input,
linux-kernel
In-Reply-To: <20230609202722.3634721-1-arnd@kernel.org>
On Fri, Jun 9, 2023 at 10:27 PM Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The previous bugfix caused a warning on 64-bit builds:
>
> drivers/input/touchscreen/ads7846.c:1126:17: warning: cast to smaller integer type 'u32' (aka 'unsigned int') from 'const void *' [-Wvoid-pointer-to-int-cast]
>
> Change the cast back to something that works on both 32-bit and 64-bit
> kernels.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202306100442.jStknDT1-lkp@intel.com/
> Fixes: 8f7913c04f6a7 ("Input: ads7846 - Fix usage of match data")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Excellent fix, thanks! Sorry for not predicting this.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] Input: ads7846 - fix pointer cast warning
From: Arnd Bergmann @ 2023-06-09 20:27 UTC (permalink / raw)
To: Dmitry Torokhov, Linus Walleij, Arnd Bergmann
Cc: kernel test robot, Andy Shevchenko, Luca Ellero, Jonathan Cameron,
linux-input, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
The previous bugfix caused a warning on 64-bit builds:
drivers/input/touchscreen/ads7846.c:1126:17: warning: cast to smaller integer type 'u32' (aka 'unsigned int') from 'const void *' [-Wvoid-pointer-to-int-cast]
Change the cast back to something that works on both 32-bit and 64-bit
kernels.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202306100442.jStknDT1-lkp@intel.com/
Fixes: 8f7913c04f6a7 ("Input: ads7846 - Fix usage of match data")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I got the report and applied this locally to fix it quickly
drivers/input/touchscreen/ads7846.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index fe6fe8acd8a66..faea40dd66d01 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1123,7 +1123,7 @@ static const struct ads7846_platform_data *ads7846_get_props(struct device *dev)
if (!pdata)
return ERR_PTR(-ENOMEM);
- pdata->model = (u32)device_get_match_data(dev);
+ pdata->model = (uintptr_t)device_get_match_data(dev);
device_property_read_u16(dev, "ti,vref-delay-usecs",
&pdata->vref_delay_usecs);
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v5 2/2] HID: i2c-hid: elan: Add ili9882t timing
From: Doug Anderson @ 2023-06-09 16:14 UTC (permalink / raw)
To: Cong Yang
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, dmitry.torokhov, jikos,
benjamin.tissoires, hsinyi, linux-input, devicetree, linux-kernel
In-Reply-To: <CAD=FV=UPSwWpkGN3UyFm1c84gj7iDC7dYrT9CCqWnqkTun-4cg@mail.gmail.com>
Hi,
On Fri, Jun 9, 2023 at 9:14 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Thu, Jun 8, 2023 at 11:36 PM Cong Yang
> <yangcong5@huaqin.corp-partner.google.com> wrote:
> >
> > The ili9882t is a TDDI IC (Touch with Display Driver). The
> > datasheet specifies there should be 60ms between touch SDA
> > sleep and panel RESX. Doug's series[1] allows panels and
> > touchscreens to power on/off together, so we can add the 65 ms
> > delay in i2c_hid_core_suspend before panel_unprepare.
> >
> > Because ili9882t touchscrgeen is a panel follower, and
> > needs to use vccio-supply instead of vcc33-supply, so set
> > it NULL to ili9882t_chip_data, then not use vcc33 regulator.
> >
> > [1]: https://lore.kernel.org/r/20230607215224.2067679-1-dianders@chromium.org
> >
> > Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
> > ---
> > drivers/hid/i2c-hid/i2c-hid-of-elan.c | 50 ++++++++++++++++++++-------
> > 1 file changed, 38 insertions(+), 12 deletions(-)
>
> This seems reasonable to me now, but only makes sense to land if the
> panel follower patch series [1] lands. That series is currently at v2
> and will at least need a v3.
>
> [1] https://lore.kernel.org/r/20230607215224.2067679-1-dianders@chromium.org
Oh, but I should have added:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH v5 2/2] HID: i2c-hid: elan: Add ili9882t timing
From: Doug Anderson @ 2023-06-09 16:14 UTC (permalink / raw)
To: Cong Yang
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, dmitry.torokhov, jikos,
benjamin.tissoires, hsinyi, linux-input, devicetree, linux-kernel
In-Reply-To: <20230609063615.758676-3-yangcong5@huaqin.corp-partner.google.com>
Hi,
On Thu, Jun 8, 2023 at 11:36 PM Cong Yang
<yangcong5@huaqin.corp-partner.google.com> wrote:
>
> The ili9882t is a TDDI IC (Touch with Display Driver). The
> datasheet specifies there should be 60ms between touch SDA
> sleep and panel RESX. Doug's series[1] allows panels and
> touchscreens to power on/off together, so we can add the 65 ms
> delay in i2c_hid_core_suspend before panel_unprepare.
>
> Because ili9882t touchscrgeen is a panel follower, and
> needs to use vccio-supply instead of vcc33-supply, so set
> it NULL to ili9882t_chip_data, then not use vcc33 regulator.
>
> [1]: https://lore.kernel.org/r/20230607215224.2067679-1-dianders@chromium.org
>
> Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
> ---
> drivers/hid/i2c-hid/i2c-hid-of-elan.c | 50 ++++++++++++++++++++-------
> 1 file changed, 38 insertions(+), 12 deletions(-)
This seems reasonable to me now, but only makes sense to land if the
panel follower patch series [1] lands. That series is currently at v2
and will at least need a v3.
[1] https://lore.kernel.org/r/20230607215224.2067679-1-dianders@chromium.org
^ permalink raw reply
* Re: [PATCH v2 04/10] of: property: fw_devlink: Add a devlink for panel followers
From: Rob Herring @ 2023-06-09 16:10 UTC (permalink / raw)
To: Douglas Anderson
Cc: Jiri Kosina, Benjamin Tissoires, Bjorn Andersson, Konrad Dybcio,
Frank Rowand, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Sam Ravnborg, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
dri-devel, Dmitry Torokhov, linux-input, Daniel Vetter,
linux-kernel, hsinyi, cros-qcom-dts-watchers, devicetree,
yangcong5, linux-arm-msm, Chris Morgan
In-Reply-To: <20230607144931.v2.4.Ibf8e1342b5b7906279db2365aca45e6253857bb3@changeid>
On Wed, Jun 07, 2023 at 02:49:26PM -0700, Douglas Anderson wrote:
> Inform fw_devlink of the fact that a panel follower (like a
> touchscreen) is effectively a consumer of the panel from the purposes
> of fw_devlink.
>
> NOTE: this patch isn't required for correctness but instead optimizes
> probe order / helps avoid deferrals.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> Since this is so small, I'd presume it's OK for it to go through a DRM
> tree with the proper Ack. That being said, this patch is just an
> optimization and thus it could land completely separately from the
> rest and they could all meet up in mainline.
>
> Changes in v2:
> - ("Add a devlink for panel followers") new for v2.
>
> drivers/of/property.c | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: HID: i2c-hid: ilitek: Introduce bindings for Ilitek ili9882t
From: Krzysztof Kozlowski @ 2023-06-09 16:00 UTC (permalink / raw)
To: Cong Yang, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.torokhov, jikos, benjamin.tissoires, dianders, hsinyi
Cc: linux-input, devicetree, linux-kernel
In-Reply-To: <20230609063615.758676-2-yangcong5@huaqin.corp-partner.google.com>
On 09/06/2023 08:36, Cong Yang wrote:
> The ili9882t touch screen chip same as Elan eKTH6915 controller
> has a reset gpio. The difference is that ili9882t needs to use
> vccio-supply instead of vcc33-supply. Doug's series[1] allows panels
> and touchscreens to power on/off together, let's add a phandle for this.
>
> [1]: https://lore.kernel.org/r/20230607215224.2067679-1-dianders@chromium.org
>
> Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
If there is going to be new version, then:
A nit, subject: drop second/last, redundant "bindings for". The
"dt-bindings" prefix is already stating that these are bindings.
---
This is an automated instruction, just in case, because many review tags
are being ignored. If you do not know the process, here is a short
explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tools like b4 can help
here. However, there's no need to repost patches *only* to add the tags.
The upstream maintainer will do that for acks received on the version
they apply.
https://elixir.bootlin.com/linux/v5.17/source/Documentation/process/submitting-patches.rst#L540
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: HID: i2c-hid: ilitek: Introduce bindings for Ilitek ili9882t
From: Krzysztof Kozlowski @ 2023-06-09 15:59 UTC (permalink / raw)
To: Doug Anderson
Cc: Cong Yang, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.torokhov, jikos, benjamin.tissoires, hsinyi, linux-input,
devicetree, linux-kernel
In-Reply-To: <CAD=FV=UxQPWm6BNSeTAJWq1Cc8qFL2WTJHFiOrca5mnTEPHMvQ@mail.gmail.com>
On 09/06/2023 17:56, Doug Anderson wrote:
> Hi,
>
> On Fri, Jun 9, 2023 at 8:50 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>>> + vccio-supply:
>>> + description: The 1.8V supply to the touchscreen.
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - interrupts
>>> + - vccio-supply
>>> +
>>> +additionalProperties: false
>>
>> Why do you disallow all properties from toouchscreen.yaml? Aren't they
>> applicable?
>
> This matches what hid-over-i2c.yaml does. It only picks
> `touchscreen-inverted-x` and `touchscreen-inverted-y` from the common
> file, which aren't needed here. I assume that the rest of the things
> from the common file can be probed using the i2c-hid protocol?
OK
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: HID: i2c-hid: ilitek: Introduce bindings for Ilitek ili9882t
From: Doug Anderson @ 2023-06-09 15:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Cong Yang, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.torokhov, jikos, benjamin.tissoires, hsinyi, linux-input,
devicetree, linux-kernel
In-Reply-To: <77dce4ec-89aa-8802-b169-744f6c11b177@linaro.org>
Hi,
On Fri, Jun 9, 2023 at 8:50 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> > + vccio-supply:
> > + description: The 1.8V supply to the touchscreen.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - vccio-supply
> > +
> > +additionalProperties: false
>
> Why do you disallow all properties from toouchscreen.yaml? Aren't they
> applicable?
This matches what hid-over-i2c.yaml does. It only picks
`touchscreen-inverted-x` and `touchscreen-inverted-y` from the common
file, which aren't needed here. I assume that the rest of the things
from the common file can be probed using the i2c-hid protocol?
-Doug
^ permalink raw reply
* Re: [PATCH] HID: HP: add support for 03f0:464a HP Elite Presenter Mouse
From: Jiri Kosina @ 2023-06-09 15:55 UTC (permalink / raw)
To: Marco Morandini; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <eaa51a28-fe4a-a41f-040d-93e7a32d0a1f@polimi.it>
On Tue, 30 May 2023, Marco Morandini wrote:
> HP Elite Presenter Mouse HID Record Descriptor shows
> two mouses (Repord ID 0x1 and 0x2), one keypad (Report ID 0x5),
> two Consumer Controls (Report IDs 0x6 and 0x3).
> Previous to this commit it registers one mouse, one keypad
> and one Consumer Control, and it was usable only as a
> digitl laser pointer (one of the two mouses). This patch defines
> the 464a USB device ID and enables the HID_QUIRK_MULTI_INPUT
> quirk for it, allowing to use the device both as a mouse
> and a digital laser pointer.
>
> Signed-off-by: Marco Morandini <marco.morandini@polimi.it>
Applied, thank you.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH RFC v1 0/3] HID: nvidia-shield: More functionality on top of initial driver
From: Jiri Kosina @ 2023-06-09 15:53 UTC (permalink / raw)
To: Rahul Rameshbabu; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20230529222052.68913-1-rrameshbabu@nvidia.com>
On Mon, 29 May 2023, Rahul Rameshbabu wrote:
> This patch series introduces more functionality on top of the initial
> nvidia-shield HID driver sent to the linux-input mailing list. The android
> media buttons, capacitive slider, and led on the Thunderstrike controller
> are now supported. If possible, would appreciate an acknowledgment of the
> initial driver patch or more feedback if needed.
>
> Link: https://lore.kernel.org/linux-input/20230418203747.24000-1-rrameshbabu@nvidia.com/
>
> Rahul Rameshbabu (3):
> HID: nvidia-shield: Add mappings for consumer HID USAGE buttons
> HID: nvidia-shield: Support LED functionality for Thunderstrike
> HID: nvidia-shield: Remove space prefix from label in
> shield_haptics_create
Applied first 1/3 and 2/3 on top of for-6.5/nvidia; the third one was not
needed, as that branch is based on v4 already.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 01/10] dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed touchscreens
From: Krzysztof Kozlowski @ 2023-06-09 15:53 UTC (permalink / raw)
To: Douglas Anderson, Jiri Kosina, Benjamin Tissoires,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Frank Rowand,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Sam Ravnborg,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann
Cc: dri-devel, Dmitry Torokhov, linux-input, Daniel Vetter,
linux-kernel, hsinyi, cros-qcom-dts-watchers, devicetree,
yangcong5, linux-arm-msm, Chris Morgan
In-Reply-To: <20230607144931.v2.1.Id68e30343bb1e11470582a9078b086176cfec46b@changeid>
On 07/06/2023 23:49, Douglas Anderson wrote:
> 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.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> Changes in v2:
> - Move the description to the generic touchscreen.yaml.
> - Update the desc to make it clearer it's only for integrated devices.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: HID: i2c-hid: ilitek: Introduce bindings for Ilitek ili9882t
From: Krzysztof Kozlowski @ 2023-06-09 15:52 UTC (permalink / raw)
To: Cong Yang, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.torokhov, jikos, benjamin.tissoires, dianders, hsinyi
Cc: linux-input, devicetree, linux-kernel
In-Reply-To: <20230609063615.758676-2-yangcong5@huaqin.corp-partner.google.com>
On 09/06/2023 08:36, Cong Yang wrote:
> The ili9882t touch screen chip same as Elan eKTH6915 controller
> has a reset gpio. The difference is that ili9882t needs to use
> vccio-supply instead of vcc33-supply. Doug's series[1] allows panels
> and touchscreens to power on/off together, let's add a phandle for this.
>
> [1]: https://lore.kernel.org/r/20230607215224.2067679-1-dianders@chromium.org
>
> Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
> +
> + reset-gpios:
> + maxItems: 1
> + description: Reset GPIO.
> +
> + vccio-supply:
> + description: The 1.8V supply to the touchscreen.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - panel
> + - vccio-supply
> +
> +additionalProperties: false
My comment from previous version still applies.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: HID: i2c-hid: ilitek: Introduce bindings for Ilitek ili9882t
From: Krzysztof Kozlowski @ 2023-06-09 15:50 UTC (permalink / raw)
To: Cong Yang, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.torokhov, jikos, benjamin.tissoires, dianders, hsinyi
Cc: linux-input, devicetree, linux-kernel
In-Reply-To: <20230608130147.2835818-2-yangcong5@huaqin.corp-partner.google.com>
On 08/06/2023 15:01, Cong Yang wrote:
> The ili9882t touch screen chip same as Elan eKTH6915 controller
> has a reset gpio. The difference is that ili9882t needs to use
> vccio-supply instead of vcc33-supply. Doug's series[1] allows panels
> and touchscreens to power on/off together, let's add a phandle for this.
>
> [1]: https://lore.kernel.org/r/20230607215224.2067679-1-dianders@chromium.org
>
> Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
> ---
> .../bindings/input/ilitek,ili9882t.yaml | 66 +++++++++++++++++++
> 1 file changed, 66 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
> new file mode 100644
> index 000000000000..89584264d6a2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/ilitek,ili9882t.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ilitek ili9882t touchscreen controller
> +
> +maintainers:
> + - Dmitry Torokhov <dmitry.torokhov@gmail.com>
This usually should not be subsystem maintainer.
> +
> +description:
> + Supports the Ilitek ili9882t touchscreen controller.
> + This touchscreen controller uses the i2c-hid protocol with a reset GPIO.
> +
> +allOf:
> + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> +
> +properties:
> + compatible:
> + const: ilitek,ili9882t
> +
> + reg:
> + const: 0x41
> +
> + interrupts:
> + maxItems: 1
> +
> + panel: true
> +
> + reset-gpios:
> + maxItems: 1
> + description: Reset GPIO.
> +
> +
Just one blank line.
> + vccio-supply:
> + description: The 1.8V supply to the touchscreen.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - vccio-supply
> +
> +additionalProperties: false
Why do you disallow all properties from toouchscreen.yaml? Aren't they
applicable?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RESEND v4 0/1] HID: nvidia-shield
From: Jiri Kosina @ 2023-06-09 15:47 UTC (permalink / raw)
To: Rahul Rameshbabu
Cc: Benjamin Tissoires, linux-input, linux-kernel, Randy Dunlap
In-Reply-To: <20230608143450.12283-1-rrameshbabu@nvidia.com>
On Thu, 8 Jun 2023, Rahul Rameshbabu wrote:
> Hi.
>
> This is an initial driver implementation for supporting NVIDIA SHIELD
> peripherals. Currently supports the following functionality for the
> THUNDERSTRIKE (SHIELD 2017) controller.
>
> - Haptics (ff_memless)
> - Serial number query (sysfs)
> - Hardware information query (sysfs)
> - Firmware version query (sysfs)
>
> Changes:
> v3 -> v4:
> * Follow correct formatting rules for help section in drivers/hid/Kconfig.
> * Refactor configuration names to indicate Kconfig options are for NVIDIA
> devices.
> v2 -> v3:
> * Renamed drivers/hid/hid-shield.c -> drivers/hid/hid-nvidia-shield.c.
> * Added space between braces for terminating element in shield_devices
> array.
> v1 -> v2:
> * Declared thunderstrike_hostcmd_req_work_handler as static.
> Reported-by: kernel test robot <lkp@intel.com>
> Link: https://lore.kernel.org/oe-kbuild-all/202304011342.6Bh3cWhA-lkp@intel.com/
> Link: https://lore.kernel.org/oe-kbuild-all/202304020922.vsngJnBT-lkp@intel.com/
>
> Rahul Rameshbabu (1):
> HID: nvidia-shield: Initial driver implementation with Thunderstrike
> support
Now queued in hid.git#for-6.5/nvidia, sorry for the delay.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: sensor-hub: Allow multi-function sensor devices
From: Jiri Kosina @ 2023-06-09 15:43 UTC (permalink / raw)
To: Daniel Thompson
Cc: Jonathan Cameron, Srinivas Pandruvada, Benjamin Tissoires,
Bjorn Andersson, linux-input, linux-iio, linux-kernel
In-Reply-To: <20230528092427.42332-1-daniel.thompson@linaro.org>
On Sun, 28 May 2023, Daniel Thompson wrote:
> The Lenovo Yoga C630 has a combined keyboard and accelerometer that
> interfaces via i2c-hid. Currently this laptop either has a working
> keyboard (if CONFIG_HID_SENSOR_HUB is disabled) or a working accelerometer.
> only works on kernels. Put another way, most distro kernels enable
> CONFIG_HID_SENSOR_HUB and therefore cannot work on this device since the
> keyboard doesn't work!
>
> Fix this by providing a richer connect mask during the probe. With this
> change both keyboard and screen orientation sensors work correctly.
>
> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Srinivas, are you aware of any multi-function device that this patch might
break?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/1] HID: apple: Option to swap only left side mod keys
From: Jiri Kosina @ 2023-06-09 15:41 UTC (permalink / raw)
To: Lasse Brun; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20230522184013.42621-1-bruners@gmail.com>
On Mon, 22 May 2023, Lasse Brun wrote:
> On the Keychron K8 keyboard, and probably others, the right side keys
> should not be swapped to maintain PC layout.
>
> Swapping the right side keys moves 'Super' before 'Alt gr' which is not
> intended by the default Keychron layout or the ISO layout.
>
> Signed-off-by: Lasse Brun <bruners@gmail.com>
Applied, thanks, and sorry for the delay.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: uclogic: Modular KUnit tests should not depend on KUNIT=y
From: Jiri Kosina @ 2023-06-09 15:40 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Dmitry Torokhov, Benjamin Tissoires, José Expósito,
Brendan Higgins, David Gow, Daniel Latypov, linux-input,
linux-kselftest, kunit-dev
In-Reply-To: <f325bf521f1cdc498dbd48b14191d186bdf7b602.1684854545.git.geert+renesas@glider.be>
On Tue, 23 May 2023, Geert Uytterhoeven wrote:
> While KUnit tests that cannot be built as a loadable module must depend
> on "KUNIT=y", this is not true for modular tests, where it adds an
> unnecessary limitation.
>
> Fix this by relaxing the dependency to "KUNIT".
>
> Fixes: 08809e482a1c44d9 ("HID: uclogic: KUnit best practices and naming conventions")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: David Gow <davidgow@google.com>
> Reviewed-by: José Expósito <jose.exposito89@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 08/10] HID: i2c-hid: Support being a panel follower
From: Doug Anderson @ 2023-06-09 15:01 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Frank Rowand, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Sam Ravnborg, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
dri-devel, Dmitry Torokhov, linux-input, Daniel Vetter,
linux-kernel, hsinyi, cros-qcom-dts-watchers, devicetree,
yangcong5, linux-arm-msm, Chris Morgan
In-Reply-To: <CAO-hwJ+3M1iYgaAFEtf-63U20ccGfdiRoi3197YoZmyvMYsGzQ@mail.gmail.com>
Hi,
On Fri, Jun 9, 2023 at 2:27 AM Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> > I suspect that it's not worth it, but I'll do this if you feel
> > strongly about it.
> >
> > I guess the simplest way I can think of to move this to its own file
> > would be to put the whole private data structure (struct i2c_hid) in a
> > private header file and then add prototypes for i2c_hid_core_resume()
> > and i2c_hid_core_suspend() there. Then I could add something like
> > i2c_hid_core_handle_panel_follower() that would have all the
> > registration logic. I'd still need special cases in the core
> > suspend/resume/remove code unless I add a level of abstraction. While
> > the level of abstraction is more "pure", it also would make the code
> > harder to follow.
> >
> > Unless I hear a strong opinion (or if this series changes
> > significantly), I'll plan to keep things in the same file and just use
> > a Kconfig.
> >
>
> Right, a separate file might not be the best then :(
>
> Do you envision this to be used on the ACPI side of i2c-hid? Because
> if this is OF only, then maybe it would be interesting to put it there
> (in i2c-hid-of.c), instead of having it in the core. IIRC i2c-hid-of
> also has ways to set up/down regulators, so maybe it'll be better
> there?
There is no reason why this problem would be limited to devices using
devicetree. Even if ACPI could somehow magically power sequence the
touchscreen and panel together, doing it behind the back of the kernel
driver would be a bad idea anyway so folks using ACPI would need the
same code. I don't have tons of experience with ACPI nor how to hook
this up there, but I purposely made the API for registering the panel
follower such that the client doesn't pass anything devicetree
specific. If someone could figure out how to detect a link between a
panel and a touchscreen for ACPI and add this code to
drm_panel_add_follower() then it would automatically work for the ACPI
case as well.
-Doug
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: input: Add bindings for Azoteq IQS7210A/7211A/E
From: Rob Herring @ 2023-06-09 14:25 UTC (permalink / raw)
To: Jeff LaBundy; +Cc: dmitry.torokhov, linux-input, devicetree
In-Reply-To: <ZHVEa0yM1LLUJEfO@nixie71>
On Mon, May 29, 2023 at 07:33:47PM -0500, Jeff LaBundy wrote:
> Add bindings for the Azoteq IQS7210A/7211A/E family of trackpad/
> touchscreen controllers.
>
> Signed-off-by: Jeff LaBundy <jeff@labundy.com>
> ---
> Changes in v2:
> - Renamed 'azoteq,default-comms' to 'azoteq,forced-comms-default' and redefined
> 0, 1 and 2 as unspecified, 0 and 1, respectively
> - Defined ATI upon its first occurrence
> - Redefined 'azoteq,gesture-angle' in units of degrees
> - Declared 'azoteq,rx-enable' to depend upon 'azoteq,tx-enable' within the
> 'trackpad' node
>
> Hi Rob,
>
> I attempted to reference existing properties from a common binding [1] as per
> your feedback in [2], however 'make DT_CHECKER_FLAGS=-m dt_binding_check' fails
> with the message 'Vendor specific properties must have a type and description
> unless they have a defined, common suffix.'
Is that because you have differing constraints in each case?
> This seems related to the discussion in [3], where you warned that the tooling
> cannot yet deduce that vendor-specific properties have already been typed in an
> externally $ref'd binding. The only other example of a common vendor schema is
> [4], but in that case the common properties are defined under arbitraily named
> pinmux config nodes. As such, they are part of 'additionalProperties' instead of
> 'properties' and hence exempt from this particular validation.
>
> Please let me know if I am mistaken (surprise!), in which case I will continue
> on this path and send a v3. Otherwise, I would like to suggest that the review
> moves forward under the premise that I will happily consolidate these bindings
> once the tooling supports this idea.
>
> Kind regards,
> Jeff LaBundy
^ permalink raw reply
* Re: [PATCH v2 08/10] HID: i2c-hid: Support being a panel follower
From: Benjamin Tissoires @ 2023-06-09 9:27 UTC (permalink / raw)
To: Doug Anderson
Cc: Jiri Kosina, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Frank Rowand, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Sam Ravnborg, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
dri-devel, Dmitry Torokhov, linux-input, Daniel Vetter,
linux-kernel, hsinyi, cros-qcom-dts-watchers, devicetree,
yangcong5, linux-arm-msm, Chris Morgan
In-Reply-To: <CAD=FV=W-fXpm4JCczrNgAS2M9u2VLd2jAkJvE9XJgQpvoE5rjA@mail.gmail.com>
On Thu, Jun 8, 2023 at 6:43 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Thu, Jun 8, 2023 at 8:37 AM Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> >
> >
> > On Jun 07 2023, Douglas Anderson wrote:
> > >
> > > As talked about in the patch ("drm/panel: Add a way for other devices
> > > to follow panel state"), we really want to keep the power states of a
> > > touchscreen and the panel it's attached to in sync with each other. In
> > > that spirit, add support to i2c-hid to be a panel follower. This will
> > > let the i2c-hid driver get informed when the panel is powered on and
> > > off. From there we can match the i2c-hid device's power state to that
> > > of the panel.
> > >
> > > NOTE: this patch specifically _doesn't_ use pm_runtime to keep track
> > > of / manage the power state of the i2c-hid device, even though my
> > > first instinct said that would be the way to go. Specific problems
> > > with using pm_runtime():
> > > * The initial power up couldn't happen in a runtime resume function
> > > since it create sub-devices and, apparently, that's not good to do
> > > in your resume function.
> > > * Managing our power state with pm_runtime meant fighting to make the
> > > right thing happen at system suspend to prevent the system from
> > > trying to resume us only to suspend us again. While this might be
> > > able to be solved, it added complexity.
> > > Overall the code without pm_runtime() ended up being smaller and
> > > easier to understand.
> >
> > Generally speaking, I'm not that happy when we need to coordinate with
> > other subsystems for bringing up resources...
>
> Yeah, I'd agree that it's not amazingly elegant. Unfortunately, I
> couldn't find any existing clean frameworks that would do what was
> needed, which is (presumably) why this problem hasn't been solved
> before. I could try to come up with a grand abstraction / new
> framework, but that doesn't seem like a great choice either unless we
> expect more users...
>
>
> > Anyway, a remark inlined (at least):
> >
> > >
> > > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > > ---
> > >
> > > Changes in v2:
> > > - i2c_hid_core_panel_prepared() and ..._unpreparing() are now static.
> > >
> > > drivers/hid/i2c-hid/i2c-hid-core.c | 82 +++++++++++++++++++++++++++++-
> > > 1 file changed, 81 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> > > index fa8a1ca43d7f..368db3ae612f 100644
> > > --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> > > +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> > > @@ -38,6 +38,8 @@
> > > #include <linux/mutex.h>
> > > #include <asm/unaligned.h>
> > >
> > > +#include <drm/drm_panel.h>
> > > +
> > > #include "../hid-ids.h"
> > > #include "i2c-hid.h"
> > >
> > > @@ -107,6 +109,8 @@ struct i2c_hid {
> > > struct mutex reset_lock;
> > >
> > > struct i2chid_ops *ops;
> > > + struct drm_panel_follower panel_follower;
> > > + bool is_panel_follower;
> > > };
> > >
> > > static const struct i2c_hid_quirks {
> > > @@ -1058,6 +1062,34 @@ static int i2c_hid_core_initial_power_up(struct i2c_hid *ihid)
> > > return ret;
> > > }
> > >
> > > +static int i2c_hid_core_panel_prepared(struct drm_panel_follower *follower)
> > > +{
> > > + struct i2c_hid *ihid = container_of(follower, struct i2c_hid, panel_follower);
> > > + struct hid_device *hid = ihid->hid;
> > > +
> > > + /*
> > > + * hid->version is set on the first power up. If it's still zero then
> > > + * this is the first power on so we should perform initial power up
> > > + * steps.
> > > + */
> > > + if (!hid->version)
> > > + return i2c_hid_core_initial_power_up(ihid);
> > > +
> > > + return i2c_hid_core_resume(ihid);
> > > +}
> > > +
> > > +static int i2c_hid_core_panel_unpreparing(struct drm_panel_follower *follower)
> > > +{
> > > + struct i2c_hid *ihid = container_of(follower, struct i2c_hid, panel_follower);
> > > +
> > > + return i2c_hid_core_suspend(ihid);
> > > +}
> > > +
> > > +static const struct drm_panel_follower_funcs i2c_hid_core_panel_follower_funcs = {
> > > + .panel_prepared = i2c_hid_core_panel_prepared,
> > > + .panel_unpreparing = i2c_hid_core_panel_unpreparing,
> > > +};
> >
> > Can we make that above block at least behind a Kconfig?
> >
> > i2c-hid is often used for touchpads, and the notion of drm panel has
> > nothing to do with them. So I'd be more confident if we could disable
> > that code if not required.
>
> Happy to put it behind a Kconfig. I'll plan on that for v3. I'll stub
> the functions out if there is no Kconfig, but plan to still leave
> structure members just to avoid uglifying the sources too much.
>
>
> > Actually, I'd be even more happier if it were in a different compilation
> > unit. Not necessary a different module, but at least a different file.
>
> I suspect that it's not worth it, but I'll do this if you feel
> strongly about it.
>
> I guess the simplest way I can think of to move this to its own file
> would be to put the whole private data structure (struct i2c_hid) in a
> private header file and then add prototypes for i2c_hid_core_resume()
> and i2c_hid_core_suspend() there. Then I could add something like
> i2c_hid_core_handle_panel_follower() that would have all the
> registration logic. I'd still need special cases in the core
> suspend/resume/remove code unless I add a level of abstraction. While
> the level of abstraction is more "pure", it also would make the code
> harder to follow.
>
> Unless I hear a strong opinion (or if this series changes
> significantly), I'll plan to keep things in the same file and just use
> a Kconfig.
>
Right, a separate file might not be the best then :(
Do you envision this to be used on the ACPI side of i2c-hid? Because
if this is OF only, then maybe it would be interesting to put it there
(in i2c-hid-of.c), instead of having it in the core. IIRC i2c-hid-of
also has ways to set up/down regulators, so maybe it'll be better
there?
Cheers,
Benjamin
^ permalink raw reply
* [PATCH v5 2/2] HID: i2c-hid: elan: Add ili9882t timing
From: Cong Yang @ 2023-06-09 6:36 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, dmitry.torokhov, jikos,
benjamin.tissoires, dianders, hsinyi
Cc: linux-input, devicetree, linux-kernel, Cong Yang
In-Reply-To: <20230609063615.758676-1-yangcong5@huaqin.corp-partner.google.com>
The ili9882t is a TDDI IC (Touch with Display Driver). The
datasheet specifies there should be 60ms between touch SDA
sleep and panel RESX. Doug's series[1] allows panels and
touchscreens to power on/off together, so we can add the 65 ms
delay in i2c_hid_core_suspend before panel_unprepare.
Because ili9882t touchscrgeen is a panel follower, and
needs to use vccio-supply instead of vcc33-supply, so set
it NULL to ili9882t_chip_data, then not use vcc33 regulator.
[1]: https://lore.kernel.org/r/20230607215224.2067679-1-dianders@chromium.org
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
---
drivers/hid/i2c-hid/i2c-hid-of-elan.c | 50 ++++++++++++++++++++-------
1 file changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-of-elan.c b/drivers/hid/i2c-hid/i2c-hid-of-elan.c
index 76ddc8be1cbb..5e52027ab60a 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of-elan.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of-elan.c
@@ -18,9 +18,11 @@
#include "i2c-hid.h"
struct elan_i2c_hid_chip_data {
- unsigned int post_gpio_reset_delay_ms;
+ unsigned int post_gpio_reset_on_delay_ms;
+ unsigned int post_gpio_reset_off_delay_ms;
unsigned int post_power_delay_ms;
u16 hid_descriptor_address;
+ const char *main_supply_name;
};
struct i2c_hid_of_elan {
@@ -38,9 +40,11 @@ static int elan_i2c_hid_power_up(struct i2chid_ops *ops)
container_of(ops, struct i2c_hid_of_elan, ops);
int ret;
- ret = regulator_enable(ihid_elan->vcc33);
- if (ret)
- return ret;
+ if (ihid_elan->vcc33) {
+ ret = regulator_enable(ihid_elan->vcc33);
+ if (ret)
+ return ret;
+ }
ret = regulator_enable(ihid_elan->vccio);
if (ret) {
@@ -52,8 +56,8 @@ static int elan_i2c_hid_power_up(struct i2chid_ops *ops)
msleep(ihid_elan->chip_data->post_power_delay_ms);
gpiod_set_value_cansleep(ihid_elan->reset_gpio, 0);
- if (ihid_elan->chip_data->post_gpio_reset_delay_ms)
- msleep(ihid_elan->chip_data->post_gpio_reset_delay_ms);
+ if (ihid_elan->chip_data->post_gpio_reset_on_delay_ms)
+ msleep(ihid_elan->chip_data->post_gpio_reset_on_delay_ms);
return 0;
}
@@ -64,8 +68,12 @@ static void elan_i2c_hid_power_down(struct i2chid_ops *ops)
container_of(ops, struct i2c_hid_of_elan, ops);
gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1);
+ if (ihid_elan->chip_data->post_gpio_reset_off_delay_ms)
+ msleep(ihid_elan->chip_data->post_gpio_reset_off_delay_ms);
+
regulator_disable(ihid_elan->vccio);
- regulator_disable(ihid_elan->vcc33);
+ if (ihid_elan->vcc33)
+ regulator_disable(ihid_elan->vcc33);
}
static int i2c_hid_of_elan_probe(struct i2c_client *client)
@@ -89,24 +97,42 @@ static int i2c_hid_of_elan_probe(struct i2c_client *client)
if (IS_ERR(ihid_elan->vccio))
return PTR_ERR(ihid_elan->vccio);
- ihid_elan->vcc33 = devm_regulator_get(&client->dev, "vcc33");
- if (IS_ERR(ihid_elan->vcc33))
- return PTR_ERR(ihid_elan->vcc33);
-
ihid_elan->chip_data = device_get_match_data(&client->dev);
+ if (ihid_elan->chip_data->main_supply_name) {
+ ihid_elan->vcc33 = devm_regulator_get(&client->dev,
+ ihid_elan->chip_data->main_supply_name);
+ if (IS_ERR(ihid_elan->vcc33))
+ return PTR_ERR(ihid_elan->vcc33);
+ }
+
return i2c_hid_core_probe(client, &ihid_elan->ops,
ihid_elan->chip_data->hid_descriptor_address, 0);
}
static const struct elan_i2c_hid_chip_data elan_ekth6915_chip_data = {
.post_power_delay_ms = 1,
- .post_gpio_reset_delay_ms = 300,
+ .post_gpio_reset_on_delay_ms = 300,
+ .hid_descriptor_address = 0x0001,
+ .main_supply_name = "vcc33",
+};
+
+static const struct elan_i2c_hid_chip_data ilitek_ili9882t_chip_data = {
+ .post_power_delay_ms = 1,
+ .post_gpio_reset_on_delay_ms = 200,
+ .post_gpio_reset_off_delay_ms = 65,
.hid_descriptor_address = 0x0001,
+ /*
+ * this touchscreen is tightly integrated with the panel and assumes
+ * that the relevant power rails (other than the IO rail) have already
+ * been turned on by the panel driver because we're a panel follower.
+ */
+ .main_supply_name = NULL,
};
static const struct of_device_id elan_i2c_hid_of_match[] = {
{ .compatible = "elan,ekth6915", .data = &elan_ekth6915_chip_data },
+ { .compatible = "ilitek,ili9882t", .data = &ilitek_ili9882t_chip_data },
{ }
};
MODULE_DEVICE_TABLE(of, elan_i2c_hid_of_match);
--
2.25.1
^ permalink raw reply related
* [PATCH v5 1/2] dt-bindings: HID: i2c-hid: ilitek: Introduce bindings for Ilitek ili9882t
From: Cong Yang @ 2023-06-09 6:36 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, dmitry.torokhov, jikos,
benjamin.tissoires, dianders, hsinyi
Cc: linux-input, devicetree, linux-kernel, Cong Yang
In-Reply-To: <20230609063615.758676-1-yangcong5@huaqin.corp-partner.google.com>
The ili9882t touch screen chip same as Elan eKTH6915 controller
has a reset gpio. The difference is that ili9882t needs to use
vccio-supply instead of vcc33-supply. Doug's series[1] allows panels
and touchscreens to power on/off together, let's add a phandle for this.
[1]: https://lore.kernel.org/r/20230607215224.2067679-1-dianders@chromium.org
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
---
.../bindings/input/ilitek,ili9882t.yaml | 67 +++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
diff --git a/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
new file mode 100644
index 000000000000..c5d9e0e919f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ilitek,ili9882t.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ili9882t touchscreen controller
+
+maintainers:
+ - Cong Yang <yangcong5@huaqin.corp-partner.google.com>
+
+description:
+ Supports the Ilitek ili9882t touchscreen controller.
+ This touchscreen controller uses the i2c-hid protocol with a reset GPIO.
+
+allOf:
+ - $ref: /schemas/input/touchscreen/touchscreen.yaml#
+
+properties:
+ compatible:
+ const: ilitek,ili9882t
+
+ reg:
+ const: 0x41
+
+ interrupts:
+ maxItems: 1
+
+ panel: true
+
+ reset-gpios:
+ maxItems: 1
+ description: Reset GPIO.
+
+ vccio-supply:
+ description: The 1.8V supply to the touchscreen.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - panel
+ - vccio-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen: touchscreen@41 {
+ compatible = "ilitek,ili9882t";
+ reg = <0x41>;
+
+ interrupt-parent = <&pio>;
+ interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+
+ panel = <&panel>;
+ reset-gpios = <&pio 60 GPIO_ACTIVE_LOW>;
+ vccio-supply = <&mt6366_vio18_reg>;
+ };
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH v5 0/2] Add ili9882t bindings and timing
From: Cong Yang @ 2023-06-09 6:36 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, dmitry.torokhov, jikos,
benjamin.tissoires, dianders, hsinyi
Cc: linux-input, devicetree, linux-kernel, Cong Yang
Add bindings for Ilitek. The ili9882t touch screen chip same as
Elan eKTH6915 controller has a reset gpio. The difference is that
ilitek9882 needs to use vccio-supply instead of vcc33-supply.
From Dmitry suggestion, it would make more sense to distinguish the
binging of ili9882 and eKTH6915.
From The datasheet specifies there should be 60ms between touch SDA
sleep and panel RESX. so we can add the 65 ms delay in i2c_hid_core_suspend.
Changes in v5:
- PATCH 1/2: Add panel as a required in property and examples.
- PATCH 2/2: Set a NULL to ili9882t_chip_data for vcc33-supply, then not use vcc33 regulator.
- Link to v4: https://lore.kernel.org/all/20230608130147.2835818-1-yangcong5@huaqin.corp-partner.google.com/
Changes in v4:
- PATCH 1/2: Remove compatible items and add reset maxItems.
- PATCH 1/2: Refer to the panel description in Doug serias[1].
[1] https://lore.kernel.org/all/20230607144931.v2.1.Id68e30343bb1e11470582a9078b086176cfec46b@changeid/
- PATCH 2/2: Set a "null" to ili9882t_chip_data for vcc33-supply, then using dummy regulator.
- Link to v3: https://lore.kernel.org/all/20230607133458.4075667-1-yangcong5@huaqin.corp-partner.google.com/
Changes in v3:
- PATCH 1/2: Introduce bindings for Ilitek.
- Link to v2: https://lore.kernel.org/all/20230605060524.1178164-1-yangcong5@huaqin.corp-partner.google.com/
Changes in v2:
- PATCH 1/2: fix ran make dt_binding_check warnings/errors.
- PATCH 1/2: remove oneOf,just enum.
- Link to v1: https://lore.kernel.org/all/20230602140948.2138668-1-yangcong5@huaqin.corp-partner.google.com/
Cong Yang (2):
dt-bindings: HID: i2c-hid: ilitek: Introduce bindings for Ilitek
ili9882t
HID: i2c-hid: elan: Add ili9882t timing
.../bindings/input/ilitek,ili9882t.yaml | 67 +++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid-of-elan.c | 50 ++++++++++----
2 files changed, 105 insertions(+), 12 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/ilitek,ili9882t.yaml
--
2.25.1
^ permalink raw reply
* [PATCH v2] HID: wacom: Use ktime_t rather than int when dealing with timestamps
From: Jason Gerecke @ 2023-06-08 21:38 UTC (permalink / raw)
To: linux-input, linux-kernel, Benjamin Tissoires, Jiri Kosina
Cc: Ping Cheng, Aaron Armstrong Skomra, Joshua Dickens,
Peter Hutterer, Jason Gerecke, stable
In-Reply-To: <20230607214102.2113-1-jason.gerecke@wacom.com>
Code which interacts with timestamps needs to use the ktime_t type
returned by functions like ktime_get. The int type does not offer
enough space to store these values, and attempting to use it is a
recipe for problems. In this particular case, overflows would occur
when calculating/storing timestamps leading to incorrect values being
reported to userspace. In some cases these bad timestamps cause input
handling in userspace to appear hung.
Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/901
Fixes: 17d793f3ed53 ("HID: wacom: insert timestamp to packed Bluetooth (BT) events")
CC: stable@vger.kernel.org
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
v2: Use div_u64 to perform division to deal with ARC and ARM architectures
(as found by the kernel test robot)
drivers/hid/wacom_wac.c | 6 +++---
drivers/hid/wacom_wac.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 2ccf838371343..174bf03908d7c 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1314,7 +1314,7 @@ static void wacom_intuos_pro2_bt_pen(struct wacom_wac *wacom)
struct input_dev *pen_input = wacom->pen_input;
unsigned char *data = wacom->data;
int number_of_valid_frames = 0;
- int time_interval = 15000000;
+ ktime_t time_interval = 15000000;
ktime_t time_packet_received = ktime_get();
int i;
@@ -1348,7 +1348,7 @@ static void wacom_intuos_pro2_bt_pen(struct wacom_wac *wacom)
if (number_of_valid_frames) {
if (wacom->hid_data.time_delayed)
time_interval = ktime_get() - wacom->hid_data.time_delayed;
- time_interval /= number_of_valid_frames;
+ time_interval = div_u64(time_interval, number_of_valid_frames);
wacom->hid_data.time_delayed = time_packet_received;
}
@@ -1359,7 +1359,7 @@ static void wacom_intuos_pro2_bt_pen(struct wacom_wac *wacom)
bool range = frame[0] & 0x20;
bool invert = frame[0] & 0x10;
int frames_number_reversed = number_of_valid_frames - i - 1;
- int event_timestamp = time_packet_received - frames_number_reversed * time_interval;
+ ktime_t event_timestamp = time_packet_received - frames_number_reversed * time_interval;
if (!valid)
continue;
diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
index 1a40bb8c5810c..ee21bb260f22f 100644
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -324,7 +324,7 @@ struct hid_data {
int ps_connected;
bool pad_input_event_flag;
unsigned short sequence_number;
- int time_delayed;
+ ktime_t time_delayed;
};
struct wacom_remote_data {
--
2.41.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox