* Re: [PATCH 2/2] Input: uinput - Release mutex while unregistering input device
From: Dmitry Torokhov @ 2023-12-08 19:58 UTC (permalink / raw)
To: Vicki Pfau; +Cc: linux-input
In-Reply-To: <20231207063406.556770-3-vi@endrift.com>
Hi Vicki,
On Wed, Dec 06, 2023 at 10:34:06PM -0800, Vicki Pfau wrote:
> Any pending requests may be holding a mutex from its own subsystem, e.g.
> evdev, while waiting to be able to claim the uinput device mutex.
> However, unregistering the device may try to claim that mutex, leading
> to a deadlock. To prevent this from happening, we need to temporarily
> give up the lock before calling input_unregister_device.
I do not think we can simply give up the lock, the whole thing with
UI_DEV_DESTROY allowing reusing connection to create a new input device
was a huge mistake because if you try to do UI_DEV_CREATE again on
the same fd you'll end up reusing whatever is in udev instance,
including the state and the mutex, and will make a huge mess.
I think the only reasonable way forward is change the driver so that no
ioctls are accepted after UI_DEV_DESTROY and then start untangling the
locking issues (possibly by dropping the lock on destroy after setting
the status - I think you will not observe the lockups you mention if
your application will stop using UI_DEV_DESTROY and simply closes the
fd).
>
> Fixes: e8b95728f724 ("Input: uinput - avoid FF flush when destroying device")
This is not the commit that introduced the problem, it has been there
since forever.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 5/5] input/touchscreen: imagis: add support for IST3032C
From: Karel Balej @ 2023-12-08 21:59 UTC (permalink / raw)
To: Markuss Broks, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Henrik Rydberg, linux-input, devicetree,
linux-kernel
Cc: Duje Mihanović, ~postmarketos/upstreaming, phone-devel,
Karel Balej
In-Reply-To: <89f7e7de-c574-49ab-885d-c6d4427fe64f@gmail.com>
Markuss,
thank you for the review.
> > diff --git a/drivers/input/touchscreen/imagis.c b/drivers/input/touchscreen/imagis.c
> > index 84a02672ac47..41f28e6e9cb1 100644
> > --- a/drivers/input/touchscreen/imagis.c
> > +++ b/drivers/input/touchscreen/imagis.c
> > @@ -35,6 +35,8 @@
> > #define IST3038B_REG_CHIPID 0x30
> > #define IST3038B_WHOAMI 0x30380b
> >
> > +#define IST3032C_WHOAMI 0x32c
> > +
> Perhaps it should be ordered in alphabetic/alphanumeric order,
> alternatively, the chip ID values could be grouped.
Here I followed suit and just started a new section for the new chip,
except there is only one entry. I do agree that it would be better to
sort the chips alphanumerically and I am actually surprised that I
didn't do that - but now I see that the chips that you added are not
sorted either, so it might be because of that.
I propose to definitely swap the order of the sections, putting 32C
first, then 38B and 38C at the end (from top to bottom). The chip ID
values could then still be grouped in a new section, but I think I would
actually prefer to keep them as parts of the respective sections as it
is now, although it is in no way a strong preference.
Please let me know whether you agree with this or have a different
preference. And if the former, please confirm that I can add your
Reviewed-by trailer to the patch modified in such a way.
Best regards,
K. B.
^ permalink raw reply
* Re: [PATCH v1] dt-bindings: input: convert gpio-mouse to json-schema
From: Dmitry Torokhov @ 2023-12-08 23:23 UTC (permalink / raw)
To: Anshul Dalal
Cc: linux-input, devicetree, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Linus Walleij, linux-kernel, linux-kernel-mentees,
Krzysztof Kozlowski
In-Reply-To: <20231208075037.114598-1-anshulusr@gmail.com>
On Fri, Dec 08, 2023 at 01:20:35PM +0530, Anshul Dalal wrote:
> Convert device tree binding documentation for GPIO attached mouse to
> json-schema.
>
> Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add poweroff-in-suspend property
From: Dmitry Torokhov @ 2023-12-08 23:37 UTC (permalink / raw)
To: Linus Walleij
Cc: Stefan Eichenberger, nick, robh+dt, krzysztof.kozlowski+dt,
conor+dt, nicolas.ferre, alexandre.belloni, claudiu.beznea,
linux-input, devicetree, linux-arm-kernel, linux-kernel,
Stefan Eichenberger
In-Reply-To: <CACRpkdbSs-vebvchxx-Tg+O5CUF5M3vZf-iytuW=ZECnHb2anA@mail.gmail.com>
Hi Linus, Krzysztof,
On Fri, Dec 08, 2023 at 01:54:21PM +0100, Linus Walleij wrote:
> On Thu, Dec 7, 2023 at 12:13 PM Stefan Eichenberger <eichest@gmail.com> wrote:
>
> > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> >
> > Add a new property to indicate that the device should be powered off in
> > suspend mode.
> >
> > Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> (...)
> > + atmel,poweroff-in-suspend:
> > + description: |
> > + When this property is set, all supplies are turned off when the system is
> > + going to suspend.
> > + type: boolean
> wakeup-source:
> type: boolean
>
> As Krzysztof says it seems you are describing an operating system feature.
It appears to be an OS feature, but I would argue that it is also a
property of a board. It is tempting to say that if DTS defines supplies
for the controller we should use them to power off the controller in
suspend, otherwise we should use the deep sleep functionality of the
controller. But a mere presence of regulators does not indicate if they
can actually be powered off in suspend (i.e. if controllers shares power
rails with another device that can be a wakeup source), so we need to
have additional hints on how OS should behave on a given device.
On top of that we have regulator framework supplying dummy regulators...
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input/vmmouse: Fix device name copies
From: Dmitry Torokhov @ 2023-12-08 23:45 UTC (permalink / raw)
To: David Laight
Cc: 'Arnd Bergmann', Zack Rusin, linux-kernel@vger.kernel.org,
VMware Graphics Reviewers, Robert Jarzmik, Raul Rangel,
linux-input@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <f3e6cab719c646bf91265b6fd2887061@AcuMS.aculab.com>
On Sun, Dec 03, 2023 at 09:14:49PM +0000, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 03 December 2023 20:51
> > On Sun, Dec 3, 2023, at 19:41, Dmitry Torokhov wrote:
> > > On Mon, Nov 27, 2023 at 03:42:06PM -0500, Zack Rusin wrote:
> > >> From: Zack Rusin <zackr@vmware.com>
> > >>
> > >> Make sure vmmouse_data::phys can hold serio::phys (which is 32 bytes)
> > >> plus an extra string, extend it to 64.
> > >>
> > >> Fixes gcc13 warnings:
> > >> drivers/input/mouse/vmmouse.c: In function ‘vmmouse_init’:
> > >> drivers/input/mouse/vmmouse.c:455:53: warning: ‘/input1’ directive output may be truncated writing
> > 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
> > >> 455 | snprintf(priv->phys, sizeof(priv->phys), "%s/input1",
> > >> | ^~~~~~~
> > >> drivers/input/mouse/vmmouse.c:455:9: note: ‘snprintf’ output between 8 and 39 bytes into a
> > destination of size 32
> > >> 455 | snprintf(priv->phys, sizeof(priv->phys), "%s/input1",
> > >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >> 456 | psmouse->ps2dev.serio->phys);
> > >> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > This simply wastes 32 bytes. It is perfectly fine to truncate phys
> > > (which does not happen in real life).
> > >
> > > -Wformat-truncation is disabled in normal builds, folks should stop
> > > using it with W=1 as well.
> >
> > It does find real bugs, and we are fairly close to being able
> > to enable it by default once the remaining warnings are all
> > fixed.
> >
> > It also doesn't waste any memory
... at this time ...
> > in this specific case since
> > vmmouse_data is currently at 168 bytes, which gets rounded
> > up to either 192 or 256 bytes anyway. I'd suggest using
> > the minimum size that is large enough though, in this case
> > 39 bytes for the string I guess.
This assumes we never change how our allocators work to provide better
memory packing.
>
> That rather depends on whether any of the earlier char[] lengths
> have been rounded up to a 'nice' value.
>
> I'd also have thought that dangerous overflows would come from
> unbounded %s formats, not fixed size strings or integers that are
> always small.
>
> There really ought to be a sane method of telling gcc not to bleat
> about snprintf() potentially overflowing the target.
Yes, that would be my preference before we enable this warning globally.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: uinput - Allow uinput_request_submit wait interrupting
From: Vicki Pfau @ 2023-12-09 3:24 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
In-Reply-To: <ZXNvQCFxPoH0-i-P@google.com>
Hi Dmitry,
On 12/8/23 11:32, Dmitry Torokhov wrote:
> Hi Vicki,
>
> On Wed, Dec 06, 2023 at 10:34:05PM -0800, Vicki Pfau wrote:
>> Currently, uinput_request_submit will only fail if the request wait times out.
>> However, in other places this wait is interruptable, and in this specific
>> location it can lead to issues, such as causing system suspend to hang until
>> the request times out.
>
> Could you please explain how a sleeping process can cause suspend to
> hang?
While I'm not 100% sure how it happens, given I found this by reproducing it before I came up with a theory for why it happened, my guess is that as it's trying to suspend all of userspace programs, it suspends the process that owns the uinput handle, so it can't continue to service requests, while the other process hangs in the uninterruptable call, blocking suspend for 30 seconds until the call times out.
>
>> Since the timeout is so long, this can cause the
>> appearance of a total system freeze. Making the wait interruptable resolves
>> this and possibly further issues.
>
> I think you are trying to find a justification too hard and it does not
> make sense, however I agree that allowing to kill the process issuing
> the request without waiting for the timeout to expire if the other side
> is stuck might be desirable.
This isn't reaching. As I said above, I discovered the patched line of code *after* observing suspend hanging for 30 seconds while trying to reproduce another bug. I wrote this patch, retested, and found that it now suspended immediately, leading to a visible -ERESTARTSYS in strace on coming back from suspend.
I can post the reproduction case somewhere, but the test program is only the evdev client end, with the uinput side being Steam, which I don't have source code for.
>
> I think the best way to use wait_for_completion_killable_timeout()
> so that stray signals do not disturb userspace, but the processes can
> still be terminated.
There's already a mutex_lock_interruptable in uinput_request_send that could cause this to fall back to userspace under similar circumstances. The only difference I can find, which is admittedly a bug in this patch now that I look at it again, is that uinput_dev_event would get called twice, leading to the request getting duplicated.
If there's a better way to handle the suspend case let me know, but this is not a hypothetical issue.
>
> Thanks.
>
Vicki
^ permalink raw reply
* Re: [PATCH 2/2] Input: uinput - Release mutex while unregistering input device
From: Vicki Pfau @ 2023-12-09 3:24 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
In-Reply-To: <ZXN1ZFYZBekXryha@google.com>
Hi Dmitry,
On 12/8/23 11:58, Dmitry Torokhov wrote:
> Hi Vicki,
>
> On Wed, Dec 06, 2023 at 10:34:06PM -0800, Vicki Pfau wrote:
>> Any pending requests may be holding a mutex from its own subsystem, e.g.
>> evdev, while waiting to be able to claim the uinput device mutex.
>> However, unregistering the device may try to claim that mutex, leading
>> to a deadlock. To prevent this from happening, we need to temporarily
>> give up the lock before calling input_unregister_device.
>
> I do not think we can simply give up the lock, the whole thing with
> UI_DEV_DESTROY allowing reusing connection to create a new input device
> was a huge mistake because if you try to do UI_DEV_CREATE again on
> the same fd you'll end up reusing whatever is in udev instance,
> including the state and the mutex, and will make a huge mess.
Yeah, I was curious why this was possible in the first place. It seemed overcomplicated compared to just opening a new fd. I suppose that that makes more sense, though it's a bit involved for this.
>
> I think the only reasonable way forward is change the driver so that no
> ioctls are accepted after UI_DEV_DESTROY and then start untangling the
> locking issues (possibly by dropping the lock on destroy after setting
> the status - I think you will not observe the lockups you mention if
> your application will stop using UI_DEV_DESTROY and simply closes the
> fd).
This does sound like a reasonable way forward. Unfortunately, I don't have access to the uinput-side application code, but I have been trying to work with them to flatten out bugs in it. I can pass this suggestion along, though there is still a reproducible deadlock that could theoretically happen with other programs in the meantime (though the likelihood of it being hit without actively trying for it is low).
>
>>
>> Fixes: e8b95728f724 ("Input: uinput - avoid FF flush when destroying device")
>
> This is not the commit that introduced the problem, it has been there
> since forever.
My mistake. If I prepare a v2, which I may not, I'll drop the line.
>
> Thanks.
>
Vicki
^ permalink raw reply
* [PATCH v12 0/4] Input: add initial support for Goodix Berlin touchscreen IC
From: Neil Armstrong @ 2023-12-09 7:33 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bastien Nocera,
Hans de Goede, Henrik Rydberg, Jeff LaBundy, linux-arm-msm,
devicetree, linux-kernel, Neil Armstrong, Rob Herring
These touchscreen ICs support SPI, I2C and I3C interface, up to
10 finger touch, stylus and gestures events.
This initial driver is derived from the Goodix goodix_ts_berlin
available at [1] and [2] and only supports the GT9916 IC
present on the Qualcomm SM8550/SM8650 MTP & QRD touch panel.
The current implementation only supports BerlinD, aka GT9916.
Support for advanced features like:
- Firmware & config update
- Stylus events
- Gestures events
- Previous revisions support (BerlinA or BerlinB)
is not included in current version.
The current support will work with currently flashed firmware
and config, and bail out if firmware or config aren't flashed yet.
[1] https://github.com/goodix/goodix_ts_berlin
[2] https://git.codelinaro.org/clo/la/platform/vendor/opensource/touch-drivers
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Changes in v12:
- Rebased on next-20231208
- Link to v11: https://lore.kernel.org/r/20231106-topic-goodix-berlin-upstream-initial-v11-0-5c47e9707c03@linaro.org
Changes in v11:
- Fixes according to Jeff's review:
- s/dev_info/dev_err/ in goodix_berlin_get_ic_info()
- remove spurious return instead of goto in goodix_berlin_get_ic_info()
- added back dropped msleep() in goodix_berlin_request_handle_reset()
- Link to v10: https://lore.kernel.org/r/20231023-topic-goodix-berlin-upstream-initial-v10-0-88eec2e51c0b@linaro.org
Changes in v10:
- Fix according to Dmitry's review:
- move goodix_berlin_get_ic_info() afe_data to heap
- merge the goodix_berlin_parse_finger() loops and skip invalid fingers instead of returning
- remove unwanted goodix_berlin_touch_handler() "static" for buffer
- only call goodix_berlin_request_handle_reset() if gpio was provided
- use "error = func(); if(error) return error;" instead of "return func()" when function handles multiple error cases
- Link to v9: https://lore.kernel.org/r/20231021-topic-goodix-berlin-upstream-initial-v9-0-13fb4e887156@linaro.org
Changes in v9:
- Rebased on next-20231020
- Link to v8: https://lore.kernel.org/r/20231003-topic-goodix-berlin-upstream-initial-v8-0-171606102ed6@linaro.org
Changes in v8:
- Add missing bitfield.h include in core
- Link to v7: https://lore.kernel.org/r/20231002-topic-goodix-berlin-upstream-initial-v7-0-792fb91f5e88@linaro.org
Changes in v7:
- rebased on v6.6-rc3
- Link to v6: https://lore.kernel.org/r/20230912-topic-goodix-berlin-upstream-initial-v6-0-b4ecfa49fb9d@linaro.org
Changes in v6:
- rebased on v6.6-rc1
- changed commit message prefix to match the other Input commits
- Link to v5: https://lore.kernel.org/r/20230801-topic-goodix-berlin-upstream-initial-v5-0-079252935593@linaro.org
Changes in v5:
- rebased on next-20230801
- Link to v4: https://lore.kernel.org/r/20230606-topic-goodix-berlin-upstream-initial-v4-0-0947c489be17@linaro.org
Changes in v4:
- Core updates:
- drop kconfig depends, deps will be handled by _SPI and _I2C
- change power_on() error labels
- print errors on all dev_err() prints
- remove useless default variable initialization
- switch irq touch checksum error to dev_err()
- add Jeff's review tag
- I2C changes
- change REGMAP_I2C Kconfig from depends to select
- add Jeff's review tag
- SPI changes
- add select REGMAP to Kconfig
- added GOODIX_BERLIN_ prefix to defines
- switched from ret to error
- add Jeff's review tag
- Link to v3: https://lore.kernel.org/r/20230606-topic-goodix-berlin-upstream-initial-v3-0-f0577cead709@linaro.org
Changes in v3:
- Another guge cleanups after Jeff's review:
- appended goodix_berlin_ before all defines
- removed some unused defines
- removed retries on most of read functions, can be added back later
- added __le to ic_info structures
- reworked and simplified irq handling, dropped enum and ts_event structs
- added struct for touch data
- simplified and cleaned goodix_berlin_check_checksum & goodix_berlin_is_dummy_data
- moved touch_data_addr to the end of the main code_data
- reworked probe to get_irq last and right before setip input device
- cleaned probe by removing the "cd->dev"
- added short paragraph to justify new driver for berlin devices
- defined all offsets & masks
- Added bindings review tag
- Link to v2: https://lore.kernel.org/r/20230606-topic-goodix-berlin-upstream-initial-v2-0-26bc8fe1e90e@linaro.org
Changes in v2:
- Huge cleanups after Jeff's review:
- switch to error instead of ret
- drop dummy vendor/product ids
- drop unused defined/enums
- drop unused ic_info and only keep needes values
- cleanup namings and use goodix_berlin_ everywhere
- fix regulator setup
- fix default variables value when assigned afterwars
- removed indirections
- dropped debugfs
- cleaned input_dev setup
- dropped _remove()
- sync'ed i2c and spi drivers
- fixed yaml bindings
- Link to v1: https://lore.kernel.org/r/20230606-topic-goodix-berlin-upstream-initial-v1-0-4a0741b8aefd@linaro.org
---
Neil Armstrong (4):
dt-bindings: input: document Goodix Berlin Touchscreen IC
Input: add core support for Goodix Berlin Touchscreen IC
Input: goodix-berlin - add I2C support for Goodix Berlin Touchscreen IC
Input: goodix-berlin - add SPI support for Goodix Berlin Touchscreen IC
.../bindings/input/touchscreen/goodix,gt9916.yaml | 95 ++++
drivers/input/touchscreen/Kconfig | 31 ++
drivers/input/touchscreen/Makefile | 3 +
drivers/input/touchscreen/goodix_berlin.h | 159 ++++++
drivers/input/touchscreen/goodix_berlin_core.c | 595 +++++++++++++++++++++
drivers/input/touchscreen/goodix_berlin_i2c.c | 74 +++
drivers/input/touchscreen/goodix_berlin_spi.c | 177 ++++++
7 files changed, 1134 insertions(+)
---
base-commit: bc63de6e6ba0b16652c5fb4b9c9916b9e7ca1f23
change-id: 20230606-topic-goodix-berlin-upstream-initial-ba97e8ec8f4c
Best regards,
--
Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* [PATCH v12 1/4] dt-bindings: input: document Goodix Berlin Touchscreen IC
From: Neil Armstrong @ 2023-12-09 7:33 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bastien Nocera,
Hans de Goede, Henrik Rydberg, Jeff LaBundy, linux-arm-msm,
devicetree, linux-kernel, Neil Armstrong, Rob Herring
In-Reply-To: <20231209-topic-goodix-berlin-upstream-initial-v12-0-eaffaeb53fb5@linaro.org>
Document the Goodix GT9916 wich is part of the "Berlin" serie
of Touchscreen controllers IC from Goodix.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
.../bindings/input/touchscreen/goodix,gt9916.yaml | 95 ++++++++++++++++++++++
1 file changed, 95 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml
new file mode 100644
index 000000000000..d90f045ac06c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/touchscreen/goodix,gt9916.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Goodix Berlin series touchscreen controller
+
+description: The Goodix Berlin series of touchscreen controllers
+ be connected to either I2C or SPI buses.
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+allOf:
+ - $ref: touchscreen.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ enum:
+ - goodix,gt9916
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+
+ avdd-supply:
+ description: Analog power supply regulator on AVDD pin
+
+ vddio-supply:
+ description: power supply regulator on VDDIO pin
+
+ spi-max-frequency: true
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-swapped-x-y: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - avdd-supply
+ - touchscreen-size-x
+ - touchscreen-size-y
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ touchscreen@5d {
+ compatible = "goodix,gt9916";
+ reg = <0x5d>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ avdd-supply = <&ts_avdd>;
+ touchscreen-size-x = <1024>;
+ touchscreen-size-y = <768>;
+ };
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ num-cs = <1>;
+ cs-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
+ touchscreen@0 {
+ compatible = "goodix,gt9916";
+ reg = <0>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ avdd-supply = <&ts_avdd>;
+ spi-max-frequency = <1000000>;
+ touchscreen-size-x = <1024>;
+ touchscreen-size-y = <768>;
+ };
+ };
+
+...
--
2.34.1
^ permalink raw reply related
* [PATCH v12 2/4] Input: add core support for Goodix Berlin Touchscreen IC
From: Neil Armstrong @ 2023-12-09 7:33 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bastien Nocera,
Hans de Goede, Henrik Rydberg, Jeff LaBundy, linux-arm-msm,
devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20231209-topic-goodix-berlin-upstream-initial-v12-0-eaffaeb53fb5@linaro.org>
Add initial support for the new Goodix "Berlin" touchscreen ICs.
These touchscreen ICs support SPI, I2C and I3C interface, up to
10 finger touch, stylus and gestures events.
This initial driver is derived from the Goodix goodix_ts_berlin
available at [1] and [2] and only supports the GT9916 IC
present on the Qualcomm SM8550 MTP & QRD touch panel.
The current implementation only supports BerlinD, aka GT9916.
Support for advanced features like:
- Firmware & config update
- Stylus events
- Gestures events
- Previous revisions support (BerlinA or BerlinB)
is not included in current version.
The current support will work with currently flashed firmware
and config, and bail out if firmware or config aren't flashed yet.
[1] https://github.com/goodix/goodix_ts_berlin
[2] https://git.codelinaro.org/clo/la/platform/vendor/opensource/touch-drivers
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/input/touchscreen/Kconfig | 3 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/goodix_berlin.h | 159 +++++++
drivers/input/touchscreen/goodix_berlin_core.c | 595 +++++++++++++++++++++++++
4 files changed, 758 insertions(+)
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index e3e2324547b9..950da599ae1a 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -416,6 +416,9 @@ config TOUCHSCREEN_GOODIX
To compile this driver as a module, choose M here: the
module will be called goodix.
+config TOUCHSCREEN_GOODIX_BERLIN_CORE
+ tristate
+
config TOUCHSCREEN_HIDEEP
tristate "HiDeep Touch IC"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 62bd24f3ac8e..2e2f3e70cd2c 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_TOUCHSCREEN_EGALAX_SERIAL) += egalax_ts_serial.o
obj-$(CONFIG_TOUCHSCREEN_EXC3000) += exc3000.o
obj-$(CONFIG_TOUCHSCREEN_FUJITSU) += fujitsu_ts.o
obj-$(CONFIG_TOUCHSCREEN_GOODIX) += goodix_ts.o
+obj-$(CONFIG_TOUCHSCREEN_GOODIX_BERLIN_CORE) += goodix_berlin_core.o
obj-$(CONFIG_TOUCHSCREEN_HIDEEP) += hideep.o
obj-$(CONFIG_TOUCHSCREEN_HYNITRON_CSTXXX) += hynitron_cstxxx.o
obj-$(CONFIG_TOUCHSCREEN_ILI210X) += ili210x.o
diff --git a/drivers/input/touchscreen/goodix_berlin.h b/drivers/input/touchscreen/goodix_berlin.h
new file mode 100644
index 000000000000..235f44947a28
--- /dev/null
+++ b/drivers/input/touchscreen/goodix_berlin.h
@@ -0,0 +1,159 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Goodix Touchscreen Driver
+ * Copyright (C) 2020 - 2021 Goodix, Inc.
+ * Copyright (C) 2023 Linaro Ltd.
+ *
+ * Based on goodix_berlin_berlin driver.
+ */
+
+#ifndef __GOODIX_BERLIN_H_
+#define __GOODIX_BERLIN_H_
+
+#include <linux/gpio/consumer.h>
+#include <linux/input.h>
+#include <linux/input/touchscreen.h>
+#include <linux/regulator/consumer.h>
+#include <linux/sizes.h>
+
+#define GOODIX_BERLIN_MAX_TOUCH 10
+
+#define GOODIX_BERLIN_NORMAL_RESET_DELAY_MS 100
+
+#define GOODIX_BERLIN_IRQ_EVENT_HEAD_LEN 8
+#define GOODIX_BERLIN_STATUS_OFFSET 0
+#define GOODIX_BERLIN_REQUEST_TYPE_OFFSET 2
+
+#define GOODIX_BERLIN_BYTES_PER_POINT 8
+#define GOODIX_BERLIN_COOR_DATA_CHECKSUM_SIZE 2
+#define GOODIX_BERLIN_COOR_DATA_CHECKSUM_MASK GENMASK(15, 0)
+
+/* Read n finger events */
+#define GOODIX_BERLIN_IRQ_READ_LEN(n) (GOODIX_BERLIN_IRQ_EVENT_HEAD_LEN + \
+ (GOODIX_BERLIN_BYTES_PER_POINT * (n)) + \
+ GOODIX_BERLIN_COOR_DATA_CHECKSUM_SIZE)
+
+#define GOODIX_BERLIN_TOUCH_EVENT BIT(7)
+#define GOODIX_BERLIN_REQUEST_EVENT BIT(6)
+#define GOODIX_BERLIN_TOUCH_COUNT_MASK GENMASK(3, 0)
+
+#define GOODIX_BERLIN_REQUEST_CODE_RESET 3
+
+#define GOODIX_BERLIN_POINT_TYPE_MASK GENMASK(3, 0)
+#define GOODIX_BERLIN_POINT_TYPE_STYLUS_HOVER 1
+#define GOODIX_BERLIN_POINT_TYPE_STYLUS 3
+
+#define GOODIX_BERLIN_TOUCH_ID_MASK GENMASK(7, 4)
+
+#define GOODIX_BERLIN_DEV_CONFIRM_VAL 0xAA
+#define GOODIX_BERLIN_BOOTOPTION_ADDR 0x10000
+#define GOODIX_BERLIN_FW_VERSION_INFO_ADDR 0x10014
+
+#define GOODIX_BERLIN_IC_INFO_MAX_LEN SZ_1K
+#define GOODIX_BERLIN_IC_INFO_ADDR 0x10070
+
+struct goodix_berlin_fw_version {
+ u8 rom_pid[6];
+ u8 rom_vid[3];
+ u8 rom_vid_reserved;
+ u8 patch_pid[8];
+ u8 patch_vid[4];
+ u8 patch_vid_reserved;
+ u8 sensor_id;
+ u8 reserved[2];
+ __le16 checksum;
+} __packed;
+
+struct goodix_berlin_ic_info_version {
+ u8 info_customer_id;
+ u8 info_version_id;
+ u8 ic_die_id;
+ u8 ic_version_id;
+ __le32 config_id;
+ u8 config_version;
+ u8 frame_data_customer_id;
+ u8 frame_data_version_id;
+ u8 touch_data_customer_id;
+ u8 touch_data_version_id;
+ u8 reserved[3];
+} __packed;
+
+struct goodix_berlin_ic_info_feature {
+ __le16 freqhop_feature;
+ __le16 calibration_feature;
+ __le16 gesture_feature;
+ __le16 side_touch_feature;
+ __le16 stylus_feature;
+} __packed;
+
+struct goodix_berlin_ic_info_misc {
+ __le32 cmd_addr;
+ __le16 cmd_max_len;
+ __le32 cmd_reply_addr;
+ __le16 cmd_reply_len;
+ __le32 fw_state_addr;
+ __le16 fw_state_len;
+ __le32 fw_buffer_addr;
+ __le16 fw_buffer_max_len;
+ __le32 frame_data_addr;
+ __le16 frame_data_head_len;
+ __le16 fw_attr_len;
+ __le16 fw_log_len;
+ u8 pack_max_num;
+ u8 pack_compress_version;
+ __le16 stylus_struct_len;
+ __le16 mutual_struct_len;
+ __le16 self_struct_len;
+ __le16 noise_struct_len;
+ __le32 touch_data_addr;
+ __le16 touch_data_head_len;
+ __le16 point_struct_len;
+ __le16 reserved1;
+ __le16 reserved2;
+ __le32 mutual_rawdata_addr;
+ __le32 mutual_diffdata_addr;
+ __le32 mutual_refdata_addr;
+ __le32 self_rawdata_addr;
+ __le32 self_diffdata_addr;
+ __le32 self_refdata_addr;
+ __le32 iq_rawdata_addr;
+ __le32 iq_refdata_addr;
+ __le32 im_rawdata_addr;
+ __le16 im_readata_len;
+ __le32 noise_rawdata_addr;
+ __le16 noise_rawdata_len;
+ __le32 stylus_rawdata_addr;
+ __le16 stylus_rawdata_len;
+ __le32 noise_data_addr;
+ __le32 esd_addr;
+} __packed;
+
+struct goodix_berlin_touch_data {
+ u8 id;
+ u8 unused;
+ __le16 x;
+ __le16 y;
+ __le16 w;
+} __packed;
+
+struct goodix_berlin_core {
+ struct device *dev;
+ struct regmap *regmap;
+ struct regulator *avdd;
+ struct regulator *iovdd;
+ struct gpio_desc *reset_gpio;
+ struct touchscreen_properties props;
+ struct goodix_berlin_fw_version fw_version;
+ struct input_dev *input_dev;
+ int irq;
+
+ /* Runtime parameters extracted from IC_INFO buffer */
+ u32 touch_data_addr;
+};
+
+int goodix_berlin_probe(struct device *dev, int irq, const struct input_id *id,
+ struct regmap *regmap);
+
+extern const struct dev_pm_ops goodix_berlin_pm_ops;
+
+#endif
diff --git a/drivers/input/touchscreen/goodix_berlin_core.c b/drivers/input/touchscreen/goodix_berlin_core.c
new file mode 100644
index 000000000000..c66e2f0c6529
--- /dev/null
+++ b/drivers/input/touchscreen/goodix_berlin_core.c
@@ -0,0 +1,595 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Goodix Touchscreen Driver
+ * Copyright (C) 2020 - 2021 Goodix, Inc.
+ * Copyright (C) 2023 Linaro Ltd.
+ *
+ * Based on goodix_ts_berlin driver.
+ */
+#include <asm/unaligned.h>
+#include <linux/bitfield.h>
+#include <linux/input/mt.h>
+#include <linux/input/touchscreen.h>
+#include <linux/regmap.h>
+
+#include "goodix_berlin.h"
+
+/*
+ * Goodix "Berlin" Touchscreen IC driver
+ *
+ * This driver is distinct from goodix.c since hardware interface
+ * is different enough to require a new driver.
+ * None of the register address or data structure are close enough
+ * to the previous generations.
+ *
+ * Currently only handles Multitouch events with already
+ * programmed firmware and "config" for "Revision D" Berlin IC.
+ *
+ * Support is missing for:
+ * - ESD Management
+ * - Firmware update/flashing
+ * - "Config" update/flashing
+ * - Stylus Events
+ * - Gesture Events
+ * - Support for older revisions (A & B)
+ */
+
+static bool goodix_berlin_checksum_valid(const u8 *data, int size)
+{
+ u32 cal_checksum = 0;
+ u16 r_checksum;
+ u32 i;
+
+ if (size < GOODIX_BERLIN_COOR_DATA_CHECKSUM_SIZE)
+ return false;
+
+ for (i = 0; i < size - GOODIX_BERLIN_COOR_DATA_CHECKSUM_SIZE; i++)
+ cal_checksum += data[i];
+
+ r_checksum = get_unaligned_le16(&data[i]);
+
+ return FIELD_GET(GOODIX_BERLIN_COOR_DATA_CHECKSUM_MASK, cal_checksum) == r_checksum;
+}
+
+static bool goodix_berlin_is_dummy_data(struct goodix_berlin_core *cd,
+ const u8 *data, int size)
+{
+ int i;
+
+ /*
+ * If the device is missing or doesn't respond the buffer
+ * could be filled with bus default line state, 0x00 or 0xff,
+ * so declare success the first time we encounter neither.
+ */
+ for (i = 0; i < size; i++)
+ if (data[i] > 0 && data[i] < 0xff)
+ return false;
+
+ return true;
+}
+
+static int goodix_berlin_dev_confirm(struct goodix_berlin_core *cd)
+{
+ u8 tx_buf[8], rx_buf[8];
+ int retry = 3;
+ int error;
+
+ memset(tx_buf, GOODIX_BERLIN_DEV_CONFIRM_VAL, sizeof(tx_buf));
+ while (retry--) {
+ error = regmap_raw_write(cd->regmap, GOODIX_BERLIN_BOOTOPTION_ADDR, tx_buf,
+ sizeof(tx_buf));
+ if (error)
+ return error;
+
+ error = regmap_raw_read(cd->regmap, GOODIX_BERLIN_BOOTOPTION_ADDR, rx_buf,
+ sizeof(rx_buf));
+ if (error)
+ return error;
+
+ if (!memcmp(tx_buf, rx_buf, sizeof(tx_buf)))
+ return 0;
+
+ usleep_range(5000, 5100);
+ }
+
+ dev_err(cd->dev, "device confirm failed, rx_buf: %*ph\n", 8, rx_buf);
+
+ return -EINVAL;
+}
+
+static int goodix_berlin_power_on(struct goodix_berlin_core *cd, bool on)
+{
+ int error = 0;
+
+ if (on) {
+ error = regulator_enable(cd->iovdd);
+ if (error) {
+ dev_err(cd->dev, "Failed to enable iovdd: %d\n", error);
+ return error;
+ }
+
+ /* Vendor waits 3ms for IOVDD to settle */
+ usleep_range(3000, 3100);
+
+ error = regulator_enable(cd->avdd);
+ if (error) {
+ dev_err(cd->dev, "Failed to enable avdd: %d\n", error);
+ goto err_iovdd_disable;
+ }
+
+ /* Vendor waits 15ms for IOVDD to settle */
+ usleep_range(15000, 15100);
+
+ gpiod_set_value(cd->reset_gpio, 0);
+
+ /* Vendor waits 4ms for Firmware to initialize */
+ usleep_range(4000, 4100);
+
+ error = goodix_berlin_dev_confirm(cd);
+ if (error)
+ goto err_dev_reset;
+
+ /* Vendor waits 100ms for Firmware to fully boot */
+ msleep(GOODIX_BERLIN_NORMAL_RESET_DELAY_MS);
+
+ return 0;
+ }
+
+err_dev_reset:
+ gpiod_set_value(cd->reset_gpio, 1);
+
+ regulator_disable(cd->avdd);
+
+err_iovdd_disable:
+ regulator_disable(cd->iovdd);
+
+ return error;
+}
+
+static int goodix_berlin_read_version(struct goodix_berlin_core *cd)
+{
+ u8 buf[sizeof(struct goodix_berlin_fw_version)];
+ int error;
+
+ error = regmap_raw_read(cd->regmap, GOODIX_BERLIN_FW_VERSION_INFO_ADDR, buf, sizeof(buf));
+ if (error) {
+ dev_err(cd->dev, "error reading fw version, %d\n", error);
+ return error;
+ }
+
+ if (!goodix_berlin_checksum_valid(buf, sizeof(buf))) {
+ dev_err(cd->dev, "invalid fw version: checksum error\n");
+ return -EINVAL;
+ }
+
+ memcpy(&cd->fw_version, buf, sizeof(cd->fw_version));
+
+ return 0;
+}
+
+/* Only extract necessary data for runtime */
+static int goodix_berlin_convert_ic_info(struct goodix_berlin_core *cd,
+ const u8 *data, u16 length)
+{
+ struct goodix_berlin_ic_info_misc misc;
+ unsigned int offset = 0;
+ u8 param_num;
+
+ offset += sizeof(__le16); /* length */
+ offset += sizeof(struct goodix_berlin_ic_info_version);
+ offset += sizeof(struct goodix_berlin_ic_info_feature);
+
+ /* IC_INFO Parameters, variable width structure */
+ offset += 4 * sizeof(u8); /* drv_num, sen_num, button_num, force_num */
+
+ if (offset >= length)
+ goto invalid_offset;
+
+ param_num = data[offset++]; /* active_scan_rate_num */
+
+ offset += param_num * sizeof(__le16);
+
+ if (offset >= length)
+ goto invalid_offset;
+
+ param_num = data[offset++]; /* mutual_freq_num*/
+
+ offset += param_num * sizeof(__le16);
+
+ if (offset >= length)
+ goto invalid_offset;
+
+ param_num = data[offset++]; /* self_tx_freq_num */
+
+ offset += param_num * sizeof(__le16);
+
+ if (offset >= length)
+ goto invalid_offset;
+
+ param_num = data[offset++]; /* self_rx_freq_num */
+
+ offset += param_num * sizeof(__le16);
+
+ if (offset >= length)
+ goto invalid_offset;
+
+ param_num = data[offset++]; /* stylus_freq_num */
+
+ offset += param_num * sizeof(__le16);
+
+ if (offset + sizeof(misc) > length)
+ goto invalid_offset;
+
+ /* goodix_berlin_ic_info_misc */
+ memcpy(&misc, &data[offset], sizeof(misc));
+
+ cd->touch_data_addr = le32_to_cpu(misc.touch_data_addr);
+
+ return 0;
+
+invalid_offset:
+ dev_err(cd->dev, "ic_info length is invalid (offset %d length %d)\n",
+ offset, length);
+ return -EINVAL;
+}
+
+static int goodix_berlin_get_ic_info(struct goodix_berlin_core *cd)
+{
+ __le16 length_raw;
+ u8 *afe_data;
+ u16 length;
+ int error;
+
+ afe_data = kzalloc(GOODIX_BERLIN_IC_INFO_MAX_LEN, GFP_KERNEL);
+ if (!afe_data)
+ return -ENOMEM;
+
+ error = regmap_raw_read(cd->regmap, GOODIX_BERLIN_IC_INFO_ADDR,
+ &length_raw, sizeof(length_raw));
+ if (error) {
+ dev_err(cd->dev, "failed get ic info length, %d\n", error);
+ goto free_afe_data;
+ }
+
+ length = le16_to_cpu(length_raw);
+ if (length >= GOODIX_BERLIN_IC_INFO_MAX_LEN) {
+ dev_err(cd->dev, "invalid ic info length %d\n", length);
+ error = -EINVAL;
+ goto free_afe_data;
+ }
+
+ error = regmap_raw_read(cd->regmap, GOODIX_BERLIN_IC_INFO_ADDR,
+ afe_data, length);
+ if (error) {
+ dev_err(cd->dev, "failed get ic info data, %d\n", error);
+ goto free_afe_data;
+ }
+
+ /* check whether the data is valid (ex. bus default values) */
+ if (goodix_berlin_is_dummy_data(cd, afe_data, length)) {
+ dev_err(cd->dev, "fw info data invalid\n");
+ error = -EINVAL;
+ goto free_afe_data;
+ }
+
+ if (!goodix_berlin_checksum_valid(afe_data, length)) {
+ dev_err(cd->dev, "fw info checksum error\n");
+ error = -EINVAL;
+ goto free_afe_data;
+ }
+
+ error = goodix_berlin_convert_ic_info(cd, afe_data, length);
+ if (error)
+ goto free_afe_data;
+
+ /* check some key info */
+ if (!cd->touch_data_addr) {
+ dev_err(cd->dev, "touch_data_addr is null\n");
+ error = -EINVAL;
+ goto free_afe_data;
+ }
+
+ return 0;
+
+free_afe_data:
+ kfree(afe_data);
+
+ return error;
+}
+
+static void goodix_berlin_parse_finger(struct goodix_berlin_core *cd,
+ const void *buf, int touch_num)
+{
+ const struct goodix_berlin_touch_data *touch_data = buf;
+ int i;
+
+ /* Report finger touches */
+ for (i = 0; i < touch_num; i++) {
+ unsigned int id;
+
+ id = FIELD_GET(GOODIX_BERLIN_TOUCH_ID_MASK, touch_data[i].id);
+
+ if (id >= GOODIX_BERLIN_MAX_TOUCH) {
+ dev_warn_ratelimited(cd->dev, "invalid finger id %d\n", id);
+ continue;
+ }
+
+ input_mt_slot(cd->input_dev, id);
+ input_mt_report_slot_state(cd->input_dev, MT_TOOL_FINGER, true);
+
+ touchscreen_report_pos(cd->input_dev, &cd->props,
+ __le16_to_cpu(touch_data[i].x),
+ __le16_to_cpu(touch_data[i].y),
+ true);
+ input_report_abs(cd->input_dev, ABS_MT_TOUCH_MAJOR,
+ __le16_to_cpu(touch_data[i].w));
+ }
+
+ input_mt_sync_frame(cd->input_dev);
+ input_sync(cd->input_dev);
+}
+
+static void goodix_berlin_touch_handler(struct goodix_berlin_core *cd,
+ const void *pre_buf, u32 pre_buf_len)
+{
+ u8 buffer[GOODIX_BERLIN_IRQ_READ_LEN(GOODIX_BERLIN_MAX_TOUCH)];
+ u8 point_type, touch_num;
+ int error;
+
+ /* copy pre-data to buffer */
+ memcpy(buffer, pre_buf, pre_buf_len);
+
+ touch_num = FIELD_GET(GOODIX_BERLIN_TOUCH_COUNT_MASK,
+ buffer[GOODIX_BERLIN_REQUEST_TYPE_OFFSET]);
+
+ if (touch_num > GOODIX_BERLIN_MAX_TOUCH) {
+ dev_warn(cd->dev, "invalid touch num %d\n", touch_num);
+ return;
+ }
+
+ if (touch_num) {
+ /* read more data if more than 2 touch events */
+ if (unlikely(touch_num > 2)) {
+ error = regmap_raw_read(cd->regmap,
+ cd->touch_data_addr + pre_buf_len,
+ &buffer[pre_buf_len],
+ (touch_num - 2) * GOODIX_BERLIN_BYTES_PER_POINT);
+ if (error) {
+ dev_err_ratelimited(cd->dev, "failed to get touch data, %d\n",
+ error);
+ return;
+ }
+ }
+
+ point_type = FIELD_GET(GOODIX_BERLIN_POINT_TYPE_MASK,
+ buffer[GOODIX_BERLIN_IRQ_EVENT_HEAD_LEN]);
+
+ if (point_type == GOODIX_BERLIN_POINT_TYPE_STYLUS ||
+ point_type == GOODIX_BERLIN_POINT_TYPE_STYLUS_HOVER) {
+ dev_warn_once(cd->dev, "Stylus event type not handled\n");
+ return;
+ }
+
+ if (!goodix_berlin_checksum_valid(&buffer[GOODIX_BERLIN_IRQ_EVENT_HEAD_LEN],
+ touch_num * GOODIX_BERLIN_BYTES_PER_POINT + 2)) {
+ dev_err(cd->dev, "touch data checksum error, data: %*ph\n",
+ touch_num * GOODIX_BERLIN_BYTES_PER_POINT + 2,
+ &buffer[GOODIX_BERLIN_IRQ_EVENT_HEAD_LEN]);
+ return;
+ }
+ }
+
+ goodix_berlin_parse_finger(cd, &buffer[GOODIX_BERLIN_IRQ_EVENT_HEAD_LEN],
+ touch_num);
+}
+
+static int goodix_berlin_request_handle_reset(struct goodix_berlin_core *cd)
+{
+ gpiod_set_value(cd->reset_gpio, 1);
+ usleep_range(2000, 2100);
+ gpiod_set_value(cd->reset_gpio, 0);
+
+ msleep(GOODIX_BERLIN_NORMAL_RESET_DELAY_MS);
+
+ return 0;
+}
+
+static irqreturn_t goodix_berlin_threadirq_func(int irq, void *data)
+{
+ struct goodix_berlin_core *cd = data;
+ u8 buf[GOODIX_BERLIN_IRQ_READ_LEN(2)];
+ u8 event_status;
+ int error;
+
+ /* First, read buffer with space for 2 touch events */
+ error = regmap_raw_read(cd->regmap, cd->touch_data_addr, buf,
+ GOODIX_BERLIN_IRQ_READ_LEN(2));
+ if (error) {
+ dev_err_ratelimited(cd->dev, "failed get event head data, %d\n", error);
+ return IRQ_HANDLED;
+ }
+
+ if (buf[GOODIX_BERLIN_STATUS_OFFSET] == 0)
+ return IRQ_HANDLED;
+
+ if (!goodix_berlin_checksum_valid(buf, GOODIX_BERLIN_IRQ_EVENT_HEAD_LEN)) {
+ dev_warn_ratelimited(cd->dev, "touch head checksum err : %*ph\n",
+ GOODIX_BERLIN_IRQ_EVENT_HEAD_LEN, buf);
+ return IRQ_HANDLED;
+ }
+
+ event_status = buf[GOODIX_BERLIN_STATUS_OFFSET];
+
+ if (event_status & GOODIX_BERLIN_TOUCH_EVENT)
+ goodix_berlin_touch_handler(cd, buf, GOODIX_BERLIN_IRQ_READ_LEN(2));
+
+ if (event_status & GOODIX_BERLIN_REQUEST_EVENT) {
+ switch (buf[GOODIX_BERLIN_REQUEST_TYPE_OFFSET]) {
+ case GOODIX_BERLIN_REQUEST_CODE_RESET:
+ if (cd->reset_gpio)
+ goodix_berlin_request_handle_reset(cd);
+ break;
+
+ default:
+ dev_warn(cd->dev, "unsupported request code 0x%x\n",
+ buf[GOODIX_BERLIN_REQUEST_TYPE_OFFSET]);
+ }
+ }
+
+ /* Clear up status field */
+ regmap_write(cd->regmap, cd->touch_data_addr, 0);
+
+ return IRQ_HANDLED;
+}
+
+static int goodix_berlin_input_dev_config(struct goodix_berlin_core *cd,
+ const struct input_id *id)
+{
+ struct input_dev *input_dev;
+ int error;
+
+ input_dev = devm_input_allocate_device(cd->dev);
+ if (!input_dev)
+ return -ENOMEM;
+
+ cd->input_dev = input_dev;
+ input_set_drvdata(input_dev, cd);
+
+ input_dev->name = "Goodix Berlin Capacitive TouchScreen";
+ input_dev->phys = "input/ts";
+
+ input_dev->id = *id;
+
+ input_set_abs_params(cd->input_dev, ABS_MT_POSITION_X, 0, SZ_64K - 1, 0, 0);
+ input_set_abs_params(cd->input_dev, ABS_MT_POSITION_Y, 0, SZ_64K - 1, 0, 0);
+ input_set_abs_params(cd->input_dev, ABS_MT_TOUCH_MAJOR, 0, 255, 0, 0);
+
+ touchscreen_parse_properties(cd->input_dev, true, &cd->props);
+
+ error = input_mt_init_slots(cd->input_dev, GOODIX_BERLIN_MAX_TOUCH,
+ INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
+ if (error)
+ return error;
+
+ error = input_register_device(cd->input_dev);
+ if (error)
+ return error;
+
+ return 0;
+}
+
+static int goodix_berlin_pm_suspend(struct device *dev)
+{
+ struct goodix_berlin_core *cd = dev_get_drvdata(dev);
+
+ disable_irq(cd->irq);
+
+ return goodix_berlin_power_on(cd, false);
+}
+
+static int goodix_berlin_pm_resume(struct device *dev)
+{
+ struct goodix_berlin_core *cd = dev_get_drvdata(dev);
+ int error;
+
+ error = goodix_berlin_power_on(cd, true);
+ if (error)
+ return error;
+
+ enable_irq(cd->irq);
+
+ return 0;
+}
+
+EXPORT_GPL_SIMPLE_DEV_PM_OPS(goodix_berlin_pm_ops,
+ goodix_berlin_pm_suspend,
+ goodix_berlin_pm_resume);
+
+static void goodix_berlin_power_off(void *data)
+{
+ struct goodix_berlin_core *cd = data;
+
+ goodix_berlin_power_on(cd, false);
+}
+
+int goodix_berlin_probe(struct device *dev, int irq, const struct input_id *id,
+ struct regmap *regmap)
+{
+ struct goodix_berlin_core *cd;
+ int error;
+
+ if (irq <= 0) {
+ dev_err(dev, "Missing interrupt number\n");
+ return -EINVAL;
+ }
+
+ cd = devm_kzalloc(dev, sizeof(*cd), GFP_KERNEL);
+ if (!cd)
+ return -ENOMEM;
+
+ cd->dev = dev;
+ cd->regmap = regmap;
+ cd->irq = irq;
+
+ cd->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(cd->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(cd->reset_gpio),
+ "Failed to request reset gpio\n");
+
+ cd->avdd = devm_regulator_get(dev, "avdd");
+ if (IS_ERR(cd->avdd))
+ return dev_err_probe(dev, PTR_ERR(cd->avdd),
+ "Failed to request avdd regulator\n");
+
+ cd->iovdd = devm_regulator_get(dev, "iovdd");
+ if (IS_ERR(cd->iovdd))
+ return dev_err_probe(dev, PTR_ERR(cd->iovdd),
+ "Failed to request iovdd regulator\n");
+
+ error = goodix_berlin_power_on(cd, true);
+ if (error) {
+ dev_err(dev, "failed power on");
+ return error;
+ }
+
+ error = devm_add_action_or_reset(dev, goodix_berlin_power_off, cd);
+ if (error)
+ return error;
+
+ error = goodix_berlin_read_version(cd);
+ if (error) {
+ dev_err(dev, "failed to get version info");
+ return error;
+ }
+
+ error = goodix_berlin_get_ic_info(cd);
+ if (error) {
+ dev_err(dev, "invalid ic info, abort");
+ return error;
+ }
+
+ error = goodix_berlin_input_dev_config(cd, id);
+ if (error) {
+ dev_err(dev, "failed set input device");
+ return error;
+ }
+
+ error = devm_request_threaded_irq(dev, irq, NULL,
+ goodix_berlin_threadirq_func,
+ IRQF_ONESHOT, "goodix-berlin", cd);
+ if (error) {
+ dev_err(dev, "request threaded irq failed: %d\n", error);
+ return error;
+ }
+
+ dev_set_drvdata(dev, cd);
+
+ dev_dbg(dev, "Goodix Berlin %s Touchscreen Controller", cd->fw_version.patch_pid);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(goodix_berlin_probe);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Goodix Berlin Core Touchscreen driver");
+MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
--
2.34.1
^ permalink raw reply related
* [PATCH v12 3/4] Input: goodix-berlin - add I2C support for Goodix Berlin Touchscreen IC
From: Neil Armstrong @ 2023-12-09 7:33 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bastien Nocera,
Hans de Goede, Henrik Rydberg, Jeff LaBundy, linux-arm-msm,
devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20231209-topic-goodix-berlin-upstream-initial-v12-0-eaffaeb53fb5@linaro.org>
Add initial support for the new Goodix "Berlin" touchscreen ICs
over the I2C interface.
This initial driver is derived from the Goodix goodix_ts_berlin
available at [1] and [2] and only supports the GT9916 IC
present on the Qualcomm SM8550 MTP & QRD touch panel.
The current implementation only supports BerlinD, aka GT9916.
[1] https://github.com/goodix/goodix_ts_berlin
[2] https://git.codelinaro.org/clo/la/platform/vendor/opensource/touch-drivers
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/input/touchscreen/Kconfig | 14 +++++
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/goodix_berlin_i2c.c | 74 +++++++++++++++++++++++++++
3 files changed, 89 insertions(+)
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 950da599ae1a..cc7b88118158 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -419,6 +419,20 @@ config TOUCHSCREEN_GOODIX
config TOUCHSCREEN_GOODIX_BERLIN_CORE
tristate
+config TOUCHSCREEN_GOODIX_BERLIN_I2C
+ tristate "Goodix Berlin I2C touchscreen"
+ depends on I2C
+ select REGMAP_I2C
+ select TOUCHSCREEN_GOODIX_BERLIN_CORE
+ help
+ Say Y here if you have a Goodix Berlin IC connected to
+ your system via I2C.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called goodix_berlin_i2c.
+
config TOUCHSCREEN_HIDEEP
tristate "HiDeep Touch IC"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 2e2f3e70cd2c..7ef677cf7a10 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_TOUCHSCREEN_EXC3000) += exc3000.o
obj-$(CONFIG_TOUCHSCREEN_FUJITSU) += fujitsu_ts.o
obj-$(CONFIG_TOUCHSCREEN_GOODIX) += goodix_ts.o
obj-$(CONFIG_TOUCHSCREEN_GOODIX_BERLIN_CORE) += goodix_berlin_core.o
+obj-$(CONFIG_TOUCHSCREEN_GOODIX_BERLIN_I2C) += goodix_berlin_i2c.o
obj-$(CONFIG_TOUCHSCREEN_HIDEEP) += hideep.o
obj-$(CONFIG_TOUCHSCREEN_HYNITRON_CSTXXX) += hynitron_cstxxx.o
obj-$(CONFIG_TOUCHSCREEN_ILI210X) += ili210x.o
diff --git a/drivers/input/touchscreen/goodix_berlin_i2c.c b/drivers/input/touchscreen/goodix_berlin_i2c.c
new file mode 100644
index 000000000000..4d5bcc101569
--- /dev/null
+++ b/drivers/input/touchscreen/goodix_berlin_i2c.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Goodix Berlin Touchscreen Driver
+ *
+ * Copyright (C) 2020 - 2021 Goodix, Inc.
+ * Copyright (C) 2023 Linaro Ltd.
+ *
+ * Based on goodix_ts_berlin driver.
+ */
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+
+#include "goodix_berlin.h"
+
+#define I2C_MAX_TRANSFER_SIZE 256
+
+static const struct regmap_config goodix_berlin_i2c_regmap_conf = {
+ .reg_bits = 32,
+ .val_bits = 8,
+ .max_raw_read = I2C_MAX_TRANSFER_SIZE,
+ .max_raw_write = I2C_MAX_TRANSFER_SIZE,
+};
+
+/* vendor & product left unassigned here, should probably be updated from fw info */
+static const struct input_id goodix_berlin_i2c_input_id = {
+ .bustype = BUS_I2C,
+};
+
+static int goodix_berlin_i2c_probe(struct i2c_client *client)
+{
+ struct regmap *regmap;
+ int error;
+
+ regmap = devm_regmap_init_i2c(client, &goodix_berlin_i2c_regmap_conf);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ error = goodix_berlin_probe(&client->dev, client->irq,
+ &goodix_berlin_i2c_input_id, regmap);
+ if (error)
+ return error;
+
+ return 0;
+}
+
+static const struct i2c_device_id goodix_berlin_i2c_id[] = {
+ { "gt9916", 0 },
+ { }
+};
+
+MODULE_DEVICE_TABLE(i2c, goodix_berlin_i2c_id);
+
+static const struct of_device_id goodix_berlin_i2c_of_match[] = {
+ { .compatible = "goodix,gt9916", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, goodix_berlin_i2c_of_match);
+
+static struct i2c_driver goodix_berlin_i2c_driver = {
+ .driver = {
+ .name = "goodix-berlin-i2c",
+ .of_match_table = goodix_berlin_i2c_of_match,
+ .pm = pm_sleep_ptr(&goodix_berlin_pm_ops),
+ },
+ .probe = goodix_berlin_i2c_probe,
+ .id_table = goodix_berlin_i2c_id,
+};
+module_i2c_driver(goodix_berlin_i2c_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Goodix Berlin I2C Touchscreen driver");
+MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
--
2.34.1
^ permalink raw reply related
* [PATCH v12 4/4] Input: goodix-berlin - add SPI support for Goodix Berlin Touchscreen IC
From: Neil Armstrong @ 2023-12-09 7:33 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bastien Nocera,
Hans de Goede, Henrik Rydberg, Jeff LaBundy, linux-arm-msm,
devicetree, linux-kernel, Neil Armstrong
In-Reply-To: <20231209-topic-goodix-berlin-upstream-initial-v12-0-eaffaeb53fb5@linaro.org>
Add initial support for the new Goodix "Berlin" touchscreen ICs
over the SPI interface.
The driver doesn't use the regmap_spi code since the SPI messages
needs to be prefixed, thus this custom regmap code.
This initial driver is derived from the Goodix goodix_ts_berlin
available at [1] and [2] and only supports the GT9916 IC
present on the Qualcomm SM8550 MTP & QRD touch panel.
The current implementation only supports BerlinD, aka GT9916.
[1] https://github.com/goodix/goodix_ts_berlin
[2] https://git.codelinaro.org/clo/la/platform/vendor/opensource/touch-drivers
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/input/touchscreen/Kconfig | 14 ++
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/goodix_berlin_spi.c | 177 ++++++++++++++++++++++++++
3 files changed, 192 insertions(+)
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index cc7b88118158..c821fe3ee794 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -433,6 +433,20 @@ config TOUCHSCREEN_GOODIX_BERLIN_I2C
To compile this driver as a module, choose M here: the
module will be called goodix_berlin_i2c.
+config TOUCHSCREEN_GOODIX_BERLIN_SPI
+ tristate "Goodix Berlin SPI touchscreen"
+ depends on SPI_MASTER
+ select REGMAP
+ select TOUCHSCREEN_GOODIX_BERLIN_CORE
+ help
+ Say Y here if you have a Goodix Berlin IC connected to
+ your system via SPI.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called goodix_berlin_spi.
+
config TOUCHSCREEN_HIDEEP
tristate "HiDeep Touch IC"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 7ef677cf7a10..a81cb5aa21a5 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_TOUCHSCREEN_FUJITSU) += fujitsu_ts.o
obj-$(CONFIG_TOUCHSCREEN_GOODIX) += goodix_ts.o
obj-$(CONFIG_TOUCHSCREEN_GOODIX_BERLIN_CORE) += goodix_berlin_core.o
obj-$(CONFIG_TOUCHSCREEN_GOODIX_BERLIN_I2C) += goodix_berlin_i2c.o
+obj-$(CONFIG_TOUCHSCREEN_GOODIX_BERLIN_SPI) += goodix_berlin_spi.o
obj-$(CONFIG_TOUCHSCREEN_HIDEEP) += hideep.o
obj-$(CONFIG_TOUCHSCREEN_HYNITRON_CSTXXX) += hynitron_cstxxx.o
obj-$(CONFIG_TOUCHSCREEN_ILI210X) += ili210x.o
diff --git a/drivers/input/touchscreen/goodix_berlin_spi.c b/drivers/input/touchscreen/goodix_berlin_spi.c
new file mode 100644
index 000000000000..502b143e9e05
--- /dev/null
+++ b/drivers/input/touchscreen/goodix_berlin_spi.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Goodix Berlin Touchscreen Driver
+ *
+ * Copyright (C) 2020 - 2021 Goodix, Inc.
+ * Copyright (C) 2023 Linaro Ltd.
+ *
+ * Based on goodix_ts_berlin driver.
+ */
+#include <asm/unaligned.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/spi/spi.h>
+
+#include "goodix_berlin.h"
+
+#define GOODIX_BERLIN_SPI_TRANS_PREFIX_LEN 1
+#define GOODIX_BERLIN_REGISTER_WIDTH 4
+#define GOODIX_BERLIN_SPI_READ_DUMMY_LEN 3
+#define GOODIX_BERLIN_SPI_READ_PREFIX_LEN (GOODIX_BERLIN_SPI_TRANS_PREFIX_LEN + \
+ GOODIX_BERLIN_REGISTER_WIDTH + \
+ GOODIX_BERLIN_SPI_READ_DUMMY_LEN)
+#define GOODIX_BERLIN_SPI_WRITE_PREFIX_LEN (GOODIX_BERLIN_SPI_TRANS_PREFIX_LEN + \
+ GOODIX_BERLIN_REGISTER_WIDTH)
+
+#define GOODIX_BERLIN_SPI_WRITE_FLAG 0xF0
+#define GOODIX_BERLIN_SPI_READ_FLAG 0xF1
+
+static int goodix_berlin_spi_read(void *context, const void *reg_buf,
+ size_t reg_size, void *val_buf,
+ size_t val_size)
+{
+ struct spi_device *spi = context;
+ struct spi_transfer xfers;
+ struct spi_message spi_msg;
+ const u32 *reg = reg_buf; /* reg is stored as native u32 at start of buffer */
+ u8 *buf;
+ int error;
+
+ if (reg_size != GOODIX_BERLIN_REGISTER_WIDTH)
+ return -EINVAL;
+
+ buf = kzalloc(GOODIX_BERLIN_SPI_READ_PREFIX_LEN + val_size, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ spi_message_init(&spi_msg);
+ memset(&xfers, 0, sizeof(xfers));
+
+ /* buffer format: 0xF1 + addr(4bytes) + dummy(3bytes) + data */
+ buf[0] = GOODIX_BERLIN_SPI_READ_FLAG;
+ put_unaligned_be32(*reg, buf + GOODIX_BERLIN_SPI_TRANS_PREFIX_LEN);
+ memset(buf + GOODIX_BERLIN_SPI_TRANS_PREFIX_LEN + GOODIX_BERLIN_REGISTER_WIDTH,
+ 0xff, GOODIX_BERLIN_SPI_READ_DUMMY_LEN);
+
+ xfers.tx_buf = buf;
+ xfers.rx_buf = buf;
+ xfers.len = GOODIX_BERLIN_SPI_READ_PREFIX_LEN + val_size;
+ xfers.cs_change = 0;
+ spi_message_add_tail(&xfers, &spi_msg);
+
+ error = spi_sync(spi, &spi_msg);
+ if (error < 0)
+ dev_err(&spi->dev, "spi transfer error, %d", error);
+ else
+ memcpy(val_buf, buf + GOODIX_BERLIN_SPI_READ_PREFIX_LEN, val_size);
+
+ kfree(buf);
+ return error;
+}
+
+static int goodix_berlin_spi_write(void *context, const void *data,
+ size_t count)
+{
+ unsigned int len = count - GOODIX_BERLIN_REGISTER_WIDTH;
+ struct spi_device *spi = context;
+ struct spi_transfer xfers;
+ struct spi_message spi_msg;
+ const u32 *reg = data; /* reg is stored as native u32 at start of buffer */
+ u8 *buf;
+ int error;
+
+ buf = kzalloc(GOODIX_BERLIN_SPI_WRITE_PREFIX_LEN + len, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ spi_message_init(&spi_msg);
+ memset(&xfers, 0, sizeof(xfers));
+
+ buf[0] = GOODIX_BERLIN_SPI_WRITE_FLAG;
+ put_unaligned_be32(*reg, buf + GOODIX_BERLIN_SPI_TRANS_PREFIX_LEN);
+ memcpy(buf + GOODIX_BERLIN_SPI_WRITE_PREFIX_LEN,
+ data + GOODIX_BERLIN_REGISTER_WIDTH, len);
+
+ xfers.tx_buf = buf;
+ xfers.len = GOODIX_BERLIN_SPI_WRITE_PREFIX_LEN + len;
+ xfers.cs_change = 0;
+ spi_message_add_tail(&xfers, &spi_msg);
+
+ error = spi_sync(spi, &spi_msg);
+ if (error < 0)
+ dev_err(&spi->dev, "spi transfer error, %d", error);
+
+ kfree(buf);
+ return error;
+}
+
+static const struct regmap_config goodix_berlin_spi_regmap_conf = {
+ .reg_bits = 32,
+ .val_bits = 8,
+ .read = goodix_berlin_spi_read,
+ .write = goodix_berlin_spi_write,
+};
+
+/* vendor & product left unassigned here, should probably be updated from fw info */
+static const struct input_id goodix_berlin_spi_input_id = {
+ .bustype = BUS_SPI,
+};
+
+static int goodix_berlin_spi_probe(struct spi_device *spi)
+{
+ struct regmap_config regmap_config;
+ struct regmap *regmap;
+ size_t max_size;
+ int error = 0;
+
+ spi->mode = SPI_MODE_0;
+ spi->bits_per_word = 8;
+ error = spi_setup(spi);
+ if (error)
+ return error;
+
+ max_size = spi_max_transfer_size(spi);
+
+ regmap_config = goodix_berlin_spi_regmap_conf;
+ regmap_config.max_raw_read = max_size - GOODIX_BERLIN_SPI_READ_PREFIX_LEN;
+ regmap_config.max_raw_write = max_size - GOODIX_BERLIN_SPI_WRITE_PREFIX_LEN;
+
+ regmap = devm_regmap_init(&spi->dev, NULL, spi, ®map_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ error = goodix_berlin_probe(&spi->dev, spi->irq,
+ &goodix_berlin_spi_input_id, regmap);
+ if (error)
+ return error;
+
+ return 0;
+}
+
+static const struct spi_device_id goodix_berlin_spi_ids[] = {
+ { "gt9916" },
+ { },
+};
+MODULE_DEVICE_TABLE(spi, goodix_berlin_spi_ids);
+
+static const struct of_device_id goodix_berlin_spi_of_match[] = {
+ { .compatible = "goodix,gt9916", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, goodix_berlin_spi_of_match);
+
+static struct spi_driver goodix_berlin_spi_driver = {
+ .driver = {
+ .name = "goodix-berlin-spi",
+ .of_match_table = goodix_berlin_spi_of_match,
+ .pm = pm_sleep_ptr(&goodix_berlin_pm_ops),
+ },
+ .probe = goodix_berlin_spi_probe,
+ .id_table = goodix_berlin_spi_ids,
+};
+module_spi_driver(goodix_berlin_spi_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Goodix Berlin SPI Touchscreen driver");
+MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 2/5] dt-bindings: input/touchscreen: Add compatible for IST3038B
From: Karel Balej @ 2023-12-09 9:05 UTC (permalink / raw)
To: Conor Dooley, Markuss Broks
Cc: Conor Dooley, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Henrik Rydberg, linux-input, devicetree,
linux-kernel, Duje Mihanović, ~postmarketos/upstreaming,
phone-devel, Karel Balej
In-Reply-To: <20231204-stooge-impotent-fe8d2d9177e4@wendy>
On Mon Dec 4, 2023 at 1:52 PM CET, Conor Dooley wrote:
> On Mon, Dec 04, 2023 at 02:40:44PM +0200, Markuss Broks wrote:
> > On 12/3/23 13:20, Conor Dooley wrote:
> > > On Sat, Dec 02, 2023 at 01:48:33PM +0100, Karel Balej wrote:
> > > > From: Markuss Broks <markuss.broks@gmail.com>
> > > >
> > > > Imagis IST3038B is a variant (firmware?) of Imagis IST3038 IC,
> > > > add the compatible for it to the IST3038C bindings.
> > > This one is better, but would be well served by mentioning what
> > > specifically is different (register addresses or firmware commands?)
> >
> > I don't think anyone knows this other than Imagis itself. I would guess it's
> > different hardware, since register addresses are indeed different, but on
> > the other hand, there is a possibility that firmware on the MCU could be
> > responding to those commands. I suppose "... IST3038B is a hardware variant
> > of ... IST3038" would be more correct.
>
> Only Imagis might know the specifics, but you (plural) have made driver
> changes so you know what is different in terms of the programming model.
> I'm just asking for you to mention how the programming model varies in
> the commit message. Otherwise I can't know whether you should have added
> a fallback compatible, without going and reading your driver change. The
> commit message for the bindings should stand on its own merit in that
> regard.
> "Variant" alone does not suffice, as many variants of devices have a
> compatible programming model, be that for a subset of features or
> complete compatibility.
>
> > The reason why I think it could be firmware-defined is because we have a lot
> > of variants (30xxA, 30xxB, 30xxC, plain 30xx), and the numbers usually mean
> > feature level/completeness, e.g. some don't support the touch pressure or
> > touchkeys, and we don't know what A/B/C/none means.
>
> Ultimately whether it is due to firmware or the hardware isn't
> particular important, just mention what is incompatibly different.
I propose to update the commit description as such:
Imagis IST3038B is a variant (firmware?) of Imagis IST3038 IC
differing from IST3038C in its register interface. Add the
compatible for it to the IST3038C bindings.
>
> Cheers,
> Conor.
>
>
> > > > Signed-off-by: Markuss Broks <markuss.broks@gmail.com>
> > > > Signed-off-by: Karel Balej <balejk@matfyz.cz>
> > > > ---
> > > > .../devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
> > > > index 0d6b033fd5fb..b5372c4eae56 100644
> > > > --- a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
> > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml
> > > > @@ -18,6 +18,7 @@ properties:
> > > > compatible:
> > > > enum:
> > > > + - imagis,ist3038b
> > > > - imagis,ist3038c
> > > > reg:
> > > > --
> > > > 2.43.0
> > > >
> > - Markuss
Kind regards,
K. B.
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add poweroff-in-suspend property
From: Conor Dooley @ 2023-12-09 10:57 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linus Walleij, Stefan Eichenberger, nick, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux-input, devicetree,
linux-arm-kernel, linux-kernel, Stefan Eichenberger
In-Reply-To: <ZXOoy8mFdhUQsZAu@google.com>
[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]
On Fri, Dec 08, 2023 at 11:37:47PM +0000, Dmitry Torokhov wrote:
> Hi Linus, Krzysztof,
>
> On Fri, Dec 08, 2023 at 01:54:21PM +0100, Linus Walleij wrote:
> > On Thu, Dec 7, 2023 at 12:13 PM Stefan Eichenberger <eichest@gmail.com> wrote:
> >
> > > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > >
> > > Add a new property to indicate that the device should be powered off in
> > > suspend mode.
> > >
> > > Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > (...)
> > > + atmel,poweroff-in-suspend:
> > > + description: |
> > > + When this property is set, all supplies are turned off when the system is
> > > + going to suspend.
> > > + type: boolean
> > wakeup-source:
> > type: boolean
> >
> > As Krzysztof says it seems you are describing an operating system feature.
>
> It appears to be an OS feature, but I would argue that it is also a
> property of a board. It is tempting to say that if DTS defines supplies
> for the controller we should use them to power off the controller in
> suspend, otherwise we should use the deep sleep functionality of the
> controller. But a mere presence of regulators does not indicate if they
> can actually be powered off in suspend (i.e. if controllers shares power
> rails with another device that can be a wakeup source), so we need to
> have additional hints on how OS should behave on a given device.
>
> On top of that we have regulator framework supplying dummy regulators...
Simply rephrasing the property might be sufficient? The current one
sounds making policy decisions with the "should be". Reframing the
commit message and property description etc in terms of what aspect of
the hardware the ability to turn off all supplies in suspend comes from
would make it more acceptable. Pretty much answering the question "why
can't we try and turn off all supplies on all systems with this device"
should get things rolling.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/5] dt-bindings: input/touchscreen: Add compatible for IST3038B
From: Conor Dooley @ 2023-12-09 10:58 UTC (permalink / raw)
To: Karel Balej
Cc: Conor Dooley, Markuss Broks, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Henrik Rydberg, linux-input,
devicetree, linux-kernel, Duje Mihanović,
~postmarketos/upstreaming, phone-devel, Karel Balej
In-Reply-To: <CXJOLS2I8WH7.1IMVJGPUNG4VB@gimli.ms.mff.cuni.cz>
[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]
On Sat, Dec 09, 2023 at 10:05:27AM +0100, Karel Balej wrote:
> On Mon Dec 4, 2023 at 1:52 PM CET, Conor Dooley wrote:
> > On Mon, Dec 04, 2023 at 02:40:44PM +0200, Markuss Broks wrote:
> > > On 12/3/23 13:20, Conor Dooley wrote:
> > > > On Sat, Dec 02, 2023 at 01:48:33PM +0100, Karel Balej wrote:
> > > > > From: Markuss Broks <markuss.broks@gmail.com>
> > > > >
> > > > > Imagis IST3038B is a variant (firmware?) of Imagis IST3038 IC,
> > > > > add the compatible for it to the IST3038C bindings.
> > > > This one is better, but would be well served by mentioning what
> > > > specifically is different (register addresses or firmware commands?)
> > >
> > > I don't think anyone knows this other than Imagis itself. I would guess it's
> > > different hardware, since register addresses are indeed different, but on
> > > the other hand, there is a possibility that firmware on the MCU could be
> > > responding to those commands. I suppose "... IST3038B is a hardware variant
> > > of ... IST3038" would be more correct.
> >
> > Only Imagis might know the specifics, but you (plural) have made driver
> > changes so you know what is different in terms of the programming model.
> > I'm just asking for you to mention how the programming model varies in
> > the commit message. Otherwise I can't know whether you should have added
> > a fallback compatible, without going and reading your driver change. The
> > commit message for the bindings should stand on its own merit in that
> > regard.
> > "Variant" alone does not suffice, as many variants of devices have a
> > compatible programming model, be that for a subset of features or
> > complete compatibility.
> >
> > > The reason why I think it could be firmware-defined is because we have a lot
> > > of variants (30xxA, 30xxB, 30xxC, plain 30xx), and the numbers usually mean
> > > feature level/completeness, e.g. some don't support the touch pressure or
> > > touchkeys, and we don't know what A/B/C/none means.
> >
> > Ultimately whether it is due to firmware or the hardware isn't
> > particular important, just mention what is incompatibly different.
>
> I propose to update the commit description as such:
>
> Imagis IST3038B is a variant (firmware?) of Imagis IST3038 IC
> differing from IST3038C in its register interface. Add the
> compatible for it to the IST3038C bindings.
SGTM. You can add
Acked-by: Conor Dooley <conor.dooley@microchip.com>
with that commit message update.
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH RESEND] Input: omap4-keypad: react on keypresses if device is runtime-suspended
From: Andreas Kemnade @ 2023-12-09 11:20 UTC (permalink / raw)
To: dmitry.torokhov, tony, frank.li, u.kleine-koenig,
Jonathan.Cameron, robh, andreas, linux-input, linux-kernel
According to SWPU235AB, table 26-6, fclk is required to generate events
at least on OMAP4460, so keep fclk enabled all the time the device
is opened.
Suggested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Reviewed-by: Tony Lindgren <tony@atomide.com>
---
Changes since RFC:
- add R-by:
drivers/input/keyboard/omap4-keypad.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
index d3f8688fdd9c3..7d83aff95617f 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -11,6 +11,7 @@
#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
+#include <linux/clk.h>
#include <linux/errno.h>
#include <linux/io.h>
#include <linux/of.h>
@@ -83,6 +84,7 @@ struct omap4_keypad {
bool no_autorepeat;
u64 keys;
unsigned short *keymap;
+ struct clk *fck;
};
static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
@@ -211,6 +213,8 @@ static int omap4_keypad_open(struct input_dev *input)
disable_irq(keypad_data->irq);
+ clk_prepare_enable(keypad_data->fck);
+
kbd_writel(keypad_data, OMAP4_KBD_CTRL,
OMAP4_DEF_CTRL_NOSOFTMODE |
(OMAP4_KEYPAD_PTV_DIV_128 << OMAP4_DEF_CTRL_PTV_SHIFT));
@@ -258,6 +262,7 @@ static void omap4_keypad_close(struct input_dev *input)
disable_irq(keypad_data->irq);
omap4_keypad_stop(keypad_data);
enable_irq(keypad_data->irq);
+ clk_disable_unprepare(keypad_data->fck);
pm_runtime_mark_last_busy(dev);
pm_runtime_put_autosuspend(dev);
@@ -356,6 +361,11 @@ static int omap4_keypad_probe(struct platform_device *pdev)
}
keypad_data->irq = irq;
+ keypad_data->fck = devm_clk_get(&pdev->dev, "fck");
+ if (IS_ERR(keypad_data->fck))
+ return dev_err_probe(&pdev->dev, PTR_ERR(keypad_data->fck),
+ "unable to get fck");
+
mutex_init(&keypad_data->lock);
platform_set_drvdata(pdev, keypad_data);
--
2.39.2
^ permalink raw reply related
* Re: [PATCH] HID: lenovo: Detect quirk-free fw on cptkbd and stop applying workaround
From: Yauhen Kharuzhy @ 2023-12-09 12:50 UTC (permalink / raw)
To: Mikhail Khvainitski
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel,
ValdikSS
In-Reply-To: <20230923231522.94060-2-me@khvoinitsky.org>
On Sun, Sep 24, 2023 at 01:58:30AM +0300, Mikhail Khvainitski wrote:
> Built-in firmware of cptkbd handles scrolling by itself (when middle
> button is pressed) but with issues: it does not support horizontal and
> hi-res scrolling and upon middle button release it sends middle button
> click even if there was a scrolling event. Commit 3cb5ff0220e3 ("HID:
> lenovo: Hide middle-button press until release") workarounds last
> issue but it's impossible to workaround scrolling-related issues
> without firmware modification.
>
> Likely, Dennis Schneider has reverse engineered the firmware and
> provided an instruction on how to patch it [1]. However,
> aforementioned workaround prevents userspace (libinput) from knowing
> exact moment when middle button has been pressed down and performing
> "On-Button scrolling". This commit detects correctly-behaving patched
> firmware if cursor movement events has been received during middle
> button being pressed and stops applying workaround for this device.
>
> Link: https://hohlerde.org/rauch/en/elektronik/projekte/tpkbd-fix/ [1]
This patch breaks a scrolling at my ThinkPad TrackPoint Keyboard II: it
starts to report middle-button push/release events with scrolling events
between. A support for this keyboard was added in
24401f291dcc4f2c18b9e2f65763cbaadc7a1528 "HID: lenovo: Add support for
ThinkPad TrackPoint Keyboard II" commit.
There is an evtest output below:
Without of commit:
Middle-button click:
Event: time 1702122290.593300, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
Event: time 1702122290.593300, -------------- SYN_REPORT ------------
Event: time 1702122290.593312, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
Event: time 1702122290.593312, -------------- SYN_REPORT ------------
Vertical scrolling:
Event: time 1702122300.441627, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1702122300.441627, -------------- SYN_REPORT ------------
Event: time 1702122300.565663, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1702122300.565663, -------------- SYN_REPORT ------------
Horizontal scrolling:
Event: time 1702122307.845969, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
Event: time 1702122307.845969, -------------- SYN_REPORT ------------
Event: time 1702122307.981954, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
Event: time 1702122307.981954, -------------- SYN_REPORT ------------
After commit:
Middle-button click:
Event: time 1702125091.290045, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
Event: time 1702125091.290045, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
Event: time 1702125091.290045, -------------- SYN_REPORT ------------
Event: time 1702125092.626118, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
Event: time 1702125092.626118, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
Event: time 1702125092.626118, -------------- SYN_REPORT ------------
Vscroll:
Event: time 1702125286.653639, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
Event: time 1702125286.653639, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
Event: time 1702125286.653639, -------------- SYN_REPORT ------------
Event: time 1702125287.929689, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1702125287.929689, -------------- SYN_REPORT ------------
Event: time 1702125288.037688, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1702125288.037688, -------------- SYN_REPORT ------------
Event: time 1702125290.481787, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
Event: time 1702125290.481787, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
Event: time 1702125290.481787, -------------- SYN_REPORT ------------
Hscroll:
Event: time 1702125293.841920, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
Event: time 1702125293.841920, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
Event: time 1702125293.841920, -------------- SYN_REPORT ------------
Event: time 1702125294.761952, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
Event: time 1702125294.761952, -------------- SYN_REPORT ------------
Event: time 1702125294.893967, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
Event: time 1702125294.893967, -------------- SYN_REPORT ------------
Event: time 1702125296.134006, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
Event: time 1702125296.134006, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
Event: time 1702125296.134006, -------------- SYN_REPORT ------------
--
Yauhen Kharuzhy
^ permalink raw reply
* Re: [PATCH v6 1/4] pwm: rename pwm_apply_state() to pwm_apply_might_sleep()
From: Uwe Kleine-König @ 2023-12-09 13:57 UTC (permalink / raw)
To: Sean Young
Cc: linux-media, linux-pwm, Ivaylo Dimitrov, Thierry Reding,
Jonathan Corbet, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Daniel Vetter,
Javier Martinez Canillas, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jean Delvare, Guenter Roeck,
Support Opensource, Dmitry Torokhov, Pavel Machek, Lee Jones,
Mauro Carvalho Chehab, Hans de Goede, Ilpo Järvinen,
Mark Gross, Liam Girdwood, Mark Brown, Daniel Thompson,
Jingoo Han, Helge Deller, Jani Nikula, linux-doc, linux-kernel,
intel-gfx, dri-devel, linux-hwmon, linux-input, linux-leds,
platform-driver-x86, linux-arm-kernel, linux-fbdev
In-Reply-To: <37090c1d8d8f42f1e12fa84942027d995189a99e.1701248996.git.sean@mess.org>
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
On Wed, Nov 29, 2023 at 09:13:34AM +0000, Sean Young wrote:
> In order to introduce a pwm api which can be used from atomic context,
> we will need two functions for applying pwm changes:
>
> int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
> int pwm_apply_atomic(struct pwm *, struct pwm_state *);
>
> This commit just deals with renaming pwm_apply_state(), a following
> commit will introduce the pwm_apply_atomic() function.
>
> Acked-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Acked-by: Lee Jones <lee@kernel.org>
> Signed-off-by: Sean Young <sean@mess.org>
Not a in-detail-review, but I just noticed again, that we have
K: pwm_(config|apply_state|ops)
in MAINTAINERS. That one needs adaption, too.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [PATCH v4 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
From: Biju Das @ 2023-12-09 15:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Support Opensource, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Steve Twiss, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven, Prabhakar Mahadev Lad, biju.das.au,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <11ec89a8-5fdd-456c-b070-988bbf8f312d@linaro.org>
Hi Krzysztof Kozlowski,
Thanks for the feedback.
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Friday, December 8, 2023 7:56 AM
> Subject: Re: [PATCH v4 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062
> to json-schema
>
> On 07/12/2023 18:03, Biju Das wrote:
>
> Trim the quote from irrelevant context, especially if your email client
> malforms replies... (because it does)
>
> >>> @@ -35,6 +42,19 @@ properties:
> >>> "#interrupt-cells":
> >>> const: 2
> >>>
> >>> + gpio:
> >>
> >> Old binding did not have such node and nothing in commit msg
> >> explained changes from pure conversion.
> >
> > OK will update the commit message. Check patch complained about
> undocumented compatible.
> >
> >>
> >>> + type: object
> >>> + $ref: /schemas/gpio/gpio.yaml#
> >>
> >> ?!? Why? First: It's always selected. Second, so you have two gpio
> >> controllers? And original binding had 0? Why this is not explained at
> all?
> >> Open the binding and look at its properties.
> >
> >
> > I have referred[1] and [2] to add gpio controller property.
> >
>
> But does it make sense? Don't just blindly copy things, but actually
> investigate whether this is correct DTS.
It is indeed incorrect.
I have tested GPIO on my board. The gpio controller must be defined in parent node.
Otherwise gpio probe will fail.
the dt example is as below
da9062: pmic@58 {
compatible = "dlg,da9062";
reg = <0x58>;
gpio-controller;
#gpio-cells = <2>;
sd0-pwr-sel {
gpio-hog;
gpios = <1 0>;
input;
line-name = "SD0_PWR_SEL";
};
sd1-pwr-sel {
gpio-hog;
gpios = <2 0>;
input;
line-name = "SD1_PWR_SEL";
};
sw-et0-en {
gpio-hog;
gpios = <3 0>;
input;
line-name = "SW_ET0_EN#";
};
pmic-good {
gpio-hog;
gpios = <4 0>;
output-high;
line-name = "PMIC_PGOOD";
};
da9062_rtc: rtc {
compatible = "dlg,da9062-rtc";
};
da9062_onkey: onkey {
compatible = "dlg,da9062-onkey";
status = "disabled";
};
watchdog {
compatible = "dlg,da9062-watchdog";
status = "disabled";
};
thermal {
compatible = "dlg,da9062-thermal";
status = "disabled";
};
gpio {
compatible = "dlg,da9062-gpio";
};
};
>
> >
> >>
> >>
> >>> + unevaluatedProperties: false
> >>> + properties:
> >>> + compatible:
> >>> + const: dlg,da9062-gpio
> >>> +
> >>> + gpio-controller: true
> >>
> >> And here is the second gpio-controller...
> >
> > So you mean it is redundant as $ref: /schemas/gpio/gpio.yaml has
> > already defined gpio-controller for this object??
>
> I meant this would mean you have two GPIO controllers. Why one device
> would have two GPIO controllers? Please answer to this in commit msg, so
> there will be no questions/concerns. You have entire commit msg to explain
> all weird and unexpected things with this binding.
This is correct. gpio-controller should be defined in the parent node.
Otherwise gpio probe will fail.
>
> ...
>
> >>> + #include <dt-bindings/interrupt-controller/irq.h>
> >>> + #include <dt-bindings/regulator/dlg,da9063-regulator.h>
> >>> + i2c {
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> + pmic@58 {
> >>> + compatible = "dlg,da9062";
> >>> + reg = <0x58>;
> >>> + #interrupt-cells = <2>;
> >>> + interrupt-parent = <&gpio1>;
> >>> + interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> >>> + interrupt-controller;
> >>> +
> >>> + gpio {
> >>> + compatible = "dlg,da9062-gpio";
> >>> + status = "disabled";
> >>
> >> Why?
>
> Why disabling? Drop all statuses from all your binding examples.
>
> >> Where are gpio-controller and cells? For this node and for parent?
> >> Why this example is incomplete?
> >
> > Currently I don't see any driver is using this compatible other than
> MFD.
>
> Open the MFD so you will see it...
Actually, found the driver and tested GPIOs,
For input gpio, I can see the sd1_pwr_sel values are
toggled during card insert/removal.
For outout gpio,
System is entering into reset mode, if I set output-low in DT. So set
Init state as output-high to avoid reset.
drivers/pinctrl/pinctrl-da9062.c
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v4 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
From: Krzysztof Kozlowski @ 2023-12-09 16:07 UTC (permalink / raw)
To: Biju Das, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones
Cc: Support Opensource, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Steve Twiss, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven, Prabhakar Mahadev Lad, biju.das.au,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <TYCPR01MB11269F887AE07FDA09F19112D8689A@TYCPR01MB11269.jpnprd01.prod.outlook.com>
On 09/12/2023 16:41, Biju Das wrote:
>>
>> Why disabling? Drop all statuses from all your binding examples.
>>
>>>> Where are gpio-controller and cells? For this node and for parent?
>>>> Why this example is incomplete?
>>>
>>> Currently I don't see any driver is using this compatible other than
>> MFD.
>>
>> Open the MFD so you will see it...
>
> Actually, found the driver and tested GPIOs,
> For input gpio, I can see the sd1_pwr_sel values are
> toggled during card insert/removal.
> For outout gpio,
> System is entering into reset mode, if I set output-low in DT. So set
> Init state as output-high to avoid reset.
>
> drivers/pinctrl/pinctrl-da9062.c
Anyway there is a GPIO child node and driver which binds to it. What's
its purpose in such case?
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
From: Biju Das @ 2023-12-09 16:38 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Support Opensource, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Steve Twiss, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven, Prabhakar Mahadev Lad, biju.das.au,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <d9ede094-10db-4789-8157-4145faa03f53@linaro.org>
Hi Krzysztof Kozlowski,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Saturday, December 9, 2023 4:08 PM
> Subject: Re: [PATCH v4 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062
> to json-schema
>
> On 09/12/2023 16:41, Biju Das wrote:
> >>
> >> Why disabling? Drop all statuses from all your binding examples.
> >>
> >>>> Where are gpio-controller and cells? For this node and for parent?
> >>>> Why this example is incomplete?
> >>>
> >>> Currently I don't see any driver is using this compatible other than
> >> MFD.
> >>
> >> Open the MFD so you will see it...
> >
> > Actually, found the driver and tested GPIOs, For input gpio, I can see
> > the sd1_pwr_sel values are toggled during card insert/removal.
> > For outout gpio,
> > System is entering into reset mode, if I set output-low in DT. So set
> > Init state as output-high to avoid reset.
> >
> > drivers/pinctrl/pinctrl-da9062.c
>
> Anyway there is a GPIO child node and driver which binds to it. What's its
> purpose in such case?
The pinctrl-da9062driver is instantiated from the parent, since there is a
GPIO child node with matching compatible.
MFD_CELL_OF("da9062-gpio", da9062_gpio_resources, NULL, 0, 0,
"dlg,da9062-gpio"),
root@smarc-rzg2ul:~# cat /sys/kernel/debug/gpio | grep da9062 -A5
gpiochip1: GPIOs 664-668, parent: platform/da9062-gpio, da9062-gpio, can sleep:
gpio-665 ( |SD0_PWR_SEL ) in lo
gpio-666 ( |SD1_PWR_SEL ) in lo
gpio-667 ( |SW_ET0_EN# ) in hi
gpio-668 ( |PMIC_PGOOD ) out hi
root@smarc-rzg2ul:~#
^ permalink raw reply
* Re: [PATCH] HID: lenovo: Detect quirk-free fw on cptkbd and stop applying workaround
From: Yauhen Kharuzhy @ 2023-12-09 16:56 UTC (permalink / raw)
To: Mikhail Khvainitski
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel,
ValdikSS
In-Reply-To: <ZXRiiPsBKNasioqH@jekhomev>
On Sat, Dec 09, 2023 at 02:50:16PM +0200, Yauhen Kharuzhy wrote:
> On Sun, Sep 24, 2023 at 01:58:30AM +0300, Mikhail Khvainitski wrote:
> > Built-in firmware of cptkbd handles scrolling by itself (when middle
> > button is pressed) but with issues: it does not support horizontal and
> > hi-res scrolling and upon middle button release it sends middle button
> > click even if there was a scrolling event. Commit 3cb5ff0220e3 ("HID:
> > lenovo: Hide middle-button press until release") workarounds last
> > issue but it's impossible to workaround scrolling-related issues
> > without firmware modification.
> >
> > Likely, Dennis Schneider has reverse engineered the firmware and
> > provided an instruction on how to patch it [1]. However,
> > aforementioned workaround prevents userspace (libinput) from knowing
> > exact moment when middle button has been pressed down and performing
> > "On-Button scrolling". This commit detects correctly-behaving patched
> > firmware if cursor movement events has been received during middle
> > button being pressed and stops applying workaround for this device.
> >
> > Link: https://hohlerde.org/rauch/en/elektronik/projekte/tpkbd-fix/ [1]
>
> This patch breaks a scrolling at my ThinkPad TrackPoint Keyboard II: it
> starts to report middle-button push/release events with scrolling events
> between. A support for this keyboard was added in
> 24401f291dcc4f2c18b9e2f65763cbaadc7a1528 "HID: lenovo: Add support for
> ThinkPad TrackPoint Keyboard II" commit.
I figured this out.
This keyboard can emit REL_Y/REL_X events between of middle-button
events (if user was moving a cursor and press middle button without of
stopping this), so this algorithm does a false-positive detection and switches
the workaround off like for patched firmware:
Event: time 1702140625.854777, type 2 (EV_REL), code 1 (REL_Y), value 2
Event: time 1702140625.854777, -------------- SYN_REPORT ------------
Event: time 1702140625.870769, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
Event: time 1702140625.870769, -------------- SYN_REPORT ------------
Event: time 1702140625.870771, type 2 (EV_REL), code 1 (REL_Y), value 2
Event: time 1702140625.870771, -------------- SYN_REPORT ------------
Event: time 1702140625.970780, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1702140625.970780, -------------- SYN_REPORT ------------
Event: time 1702140626.058800, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1702140626.058800, -------------- SYN_REPORT ------------
Event: time 1702140630.462974, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
Event: time 1702140630.462974, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
Event: time 1702140630.462974, -------------- SYN_REPORT ------------
>
> There is an evtest output below:
>
> Without of commit:
>
> Middle-button click:
> Event: time 1702122290.593300, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> Event: time 1702122290.593300, -------------- SYN_REPORT ------------
> Event: time 1702122290.593312, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> Event: time 1702122290.593312, -------------- SYN_REPORT ------------
>
> Vertical scrolling:
> Event: time 1702122300.441627, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
> Event: time 1702122300.441627, -------------- SYN_REPORT ------------
> Event: time 1702122300.565663, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
> Event: time 1702122300.565663, -------------- SYN_REPORT ------------
>
> Horizontal scrolling:
> Event: time 1702122307.845969, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
> Event: time 1702122307.845969, -------------- SYN_REPORT ------------
> Event: time 1702122307.981954, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
> Event: time 1702122307.981954, -------------- SYN_REPORT ------------
>
>
>
> After commit:
>
> Middle-button click:
> Event: time 1702125091.290045, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> Event: time 1702125091.290045, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> Event: time 1702125091.290045, -------------- SYN_REPORT ------------
> Event: time 1702125092.626118, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> Event: time 1702125092.626118, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> Event: time 1702125092.626118, -------------- SYN_REPORT ------------
>
>
> Vscroll:
> Event: time 1702125286.653639, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> Event: time 1702125286.653639, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> Event: time 1702125286.653639, -------------- SYN_REPORT ------------
> Event: time 1702125287.929689, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
> Event: time 1702125287.929689, -------------- SYN_REPORT ------------
> Event: time 1702125288.037688, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
> Event: time 1702125288.037688, -------------- SYN_REPORT ------------
> Event: time 1702125290.481787, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> Event: time 1702125290.481787, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> Event: time 1702125290.481787, -------------- SYN_REPORT ------------
>
> Hscroll:
> Event: time 1702125293.841920, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> Event: time 1702125293.841920, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> Event: time 1702125293.841920, -------------- SYN_REPORT ------------
> Event: time 1702125294.761952, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
> Event: time 1702125294.761952, -------------- SYN_REPORT ------------
> Event: time 1702125294.893967, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
> Event: time 1702125294.893967, -------------- SYN_REPORT ------------
> Event: time 1702125296.134006, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> Event: time 1702125296.134006, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> Event: time 1702125296.134006, -------------- SYN_REPORT ------------
--
Yauhen Kharuzhy
^ permalink raw reply
* Re: [PATCH] HID: lenovo: Detect quirk-free fw on cptkbd and stop applying workaround
From: Yauhen Kharuzhy @ 2023-12-09 18:21 UTC (permalink / raw)
To: Mikhail Khvainitski
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel,
ValdikSS
In-Reply-To: <20231209165648.4rfe4gxubaajrl2z@jekhomev>
On Sat, Dec 09, 2023 at 06:56:48PM +0200, Yauhen Kharuzhy wrote:
> On Sat, Dec 09, 2023 at 02:50:16PM +0200, Yauhen Kharuzhy wrote:
> > On Sun, Sep 24, 2023 at 01:58:30AM +0300, Mikhail Khvainitski wrote:
> > > Built-in firmware of cptkbd handles scrolling by itself (when middle
> > > button is pressed) but with issues: it does not support horizontal and
> > > hi-res scrolling and upon middle button release it sends middle button
> > > click even if there was a scrolling event. Commit 3cb5ff0220e3 ("HID:
> > > lenovo: Hide middle-button press until release") workarounds last
> > > issue but it's impossible to workaround scrolling-related issues
> > > without firmware modification.
> > >
> > > Likely, Dennis Schneider has reverse engineered the firmware and
> > > provided an instruction on how to patch it [1]. However,
> > > aforementioned workaround prevents userspace (libinput) from knowing
> > > exact moment when middle button has been pressed down and performing
> > > "On-Button scrolling". This commit detects correctly-behaving patched
> > > firmware if cursor movement events has been received during middle
> > > button being pressed and stops applying workaround for this device.
> > >
> > > Link: https://hohlerde.org/rauch/en/elektronik/projekte/tpkbd-fix/ [1]
> >
> > This patch breaks a scrolling at my ThinkPad TrackPoint Keyboard II: it
> > starts to report middle-button push/release events with scrolling events
> > between. A support for this keyboard was added in
> > 24401f291dcc4f2c18b9e2f65763cbaadc7a1528 "HID: lenovo: Add support for
> > ThinkPad TrackPoint Keyboard II" commit.
>
> I figured this out.
>
> This keyboard can emit REL_Y/REL_X events between of middle-button
> events (if user was moving a cursor and press middle button without of
> stopping this), so this algorithm does a false-positive detection and switches
> the workaround off like for patched firmware:
>
> Event: time 1702140625.854777, type 2 (EV_REL), code 1 (REL_Y), value 2
> Event: time 1702140625.854777, -------------- SYN_REPORT ------------
> Event: time 1702140625.870769, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> Event: time 1702140625.870769, -------------- SYN_REPORT ------------
> Event: time 1702140625.870771, type 2 (EV_REL), code 1 (REL_Y), value 2
> Event: time 1702140625.870771, -------------- SYN_REPORT ------------
> Event: time 1702140625.970780, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
> Event: time 1702140625.970780, -------------- SYN_REPORT ------------
> Event: time 1702140626.058800, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
> Event: time 1702140626.058800, -------------- SYN_REPORT ------------
> Event: time 1702140630.462974, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> Event: time 1702140630.462974, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> Event: time 1702140630.462974, -------------- SYN_REPORT ------------
Maybe we should map the wheel HID reports to REL_Y/REL_X in
lenovo_input_mapping_tpIIkbd() to allow libinput to do its wheel emulation job?
I tried this but I am not familiar with HID drivers and had no success.
>
>
> >
> > There is an evtest output below:
> >
> > Without of commit:
> >
> > Middle-button click:
> > Event: time 1702122290.593300, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> > Event: time 1702122290.593300, -------------- SYN_REPORT ------------
> > Event: time 1702122290.593312, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> > Event: time 1702122290.593312, -------------- SYN_REPORT ------------
> >
> > Vertical scrolling:
> > Event: time 1702122300.441627, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
> > Event: time 1702122300.441627, -------------- SYN_REPORT ------------
> > Event: time 1702122300.565663, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
> > Event: time 1702122300.565663, -------------- SYN_REPORT ------------
> >
> > Horizontal scrolling:
> > Event: time 1702122307.845969, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
> > Event: time 1702122307.845969, -------------- SYN_REPORT ------------
> > Event: time 1702122307.981954, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
> > Event: time 1702122307.981954, -------------- SYN_REPORT ------------
> >
> >
> >
> > After commit:
> >
> > Middle-button click:
> > Event: time 1702125091.290045, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> > Event: time 1702125091.290045, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> > Event: time 1702125091.290045, -------------- SYN_REPORT ------------
> > Event: time 1702125092.626118, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> > Event: time 1702125092.626118, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> > Event: time 1702125092.626118, -------------- SYN_REPORT ------------
> >
> >
> > Vscroll:
> > Event: time 1702125286.653639, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> > Event: time 1702125286.653639, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> > Event: time 1702125286.653639, -------------- SYN_REPORT ------------
> > Event: time 1702125287.929689, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
> > Event: time 1702125287.929689, -------------- SYN_REPORT ------------
> > Event: time 1702125288.037688, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
> > Event: time 1702125288.037688, -------------- SYN_REPORT ------------
> > Event: time 1702125290.481787, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> > Event: time 1702125290.481787, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> > Event: time 1702125290.481787, -------------- SYN_REPORT ------------
> >
> > Hscroll:
> > Event: time 1702125293.841920, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> > Event: time 1702125293.841920, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> > Event: time 1702125293.841920, -------------- SYN_REPORT ------------
> > Event: time 1702125294.761952, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
> > Event: time 1702125294.761952, -------------- SYN_REPORT ------------
> > Event: time 1702125294.893967, type 2 (EV_REL), code 6 (REL_HWHEEL), value -1
> > Event: time 1702125294.893967, -------------- SYN_REPORT ------------
> > Event: time 1702125296.134006, type 4 (EV_MSC), code 4 (MSC_SCAN), value ffa000fb
> > Event: time 1702125296.134006, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> > Event: time 1702125296.134006, -------------- SYN_REPORT ------------
>
> --
> Yauhen Kharuzhy
--
Yauhen Kharuzhy
^ permalink raw reply
* Re: [PATCH v3 5/5] input/touchscreen: imagis: add support for IST3032C
From: Markuss Broks @ 2023-12-09 20:50 UTC (permalink / raw)
To: Karel Balej, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Henrik Rydberg, linux-input, devicetree,
linux-kernel
Cc: Duje Mihanović, ~postmarketos/upstreaming, phone-devel,
Karel Balej
In-Reply-To: <CXJAG826ZTNA.2F8WOGVNYADKP@gimli.ms.mff.cuni.cz>
Hi Karel,
On 12/8/23 23:59, Karel Balej wrote:
> Markuss,
>
> thank you for the review.
>
>>> diff --git a/drivers/input/touchscreen/imagis.c b/drivers/input/touchscreen/imagis.c
>>> index 84a02672ac47..41f28e6e9cb1 100644
>>> --- a/drivers/input/touchscreen/imagis.c
>>> +++ b/drivers/input/touchscreen/imagis.c
>>> @@ -35,6 +35,8 @@
>>> #define IST3038B_REG_CHIPID 0x30
>>> #define IST3038B_WHOAMI 0x30380b
>>>
>>> +#define IST3032C_WHOAMI 0x32c
>>> +
>> Perhaps it should be ordered in alphabetic/alphanumeric order,
>> alternatively, the chip ID values could be grouped.
> Here I followed suit and just started a new section for the new chip,
> except there is only one entry. I do agree that it would be better to
> sort the chips alphanumerically and I am actually surprised that I
> didn't do that - but now I see that the chips that you added are not
> sorted either, so it might be because of that.
>
> I propose to definitely swap the order of the sections, putting 32C
> first, then 38B and 38C at the end (from top to bottom). The chip ID
> values could then still be grouped in a new section, but I think I would
> actually prefer to keep them as parts of the respective sections as it
> is now, although it is in no way a strong preference.
We could do that, yeah. It is not a problem right now since there's only
3 models supported, but it would maker sense and set some order for when
we'd have more supported devices.
>
> Please let me know whether you agree with this or have a different
> preference. And if the former, please confirm that I can add your
> Reviewed-by trailer to the patch modified in such a way.
Yeah, it's fine.
>
> Best regards,
> K. B.
- Markuss
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS d3e09f57345f86cf5c47a89fc216f6c98f9a4a7a
From: kernel test robot @ 2023-12-10 0:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: d3e09f57345f86cf5c47a89fc216f6c98f9a4a7a dt-bindings: input: gpio-mouse: Convert to json-schema
elapsed time: 1463m
configs tested: 110
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha defconfig gcc
arc allnoconfig gcc
arc defconfig gcc
arc randconfig-001-20231210 gcc
arc randconfig-002-20231210 gcc
arm allnoconfig gcc
arm at91_dt_defconfig gcc
arm defconfig clang
arm randconfig-001-20231210 gcc
arm randconfig-002-20231210 gcc
arm randconfig-003-20231210 gcc
arm randconfig-004-20231210 gcc
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20231210 gcc
arm64 randconfig-002-20231210 gcc
arm64 randconfig-003-20231210 gcc
arm64 randconfig-004-20231210 gcc
csky allnoconfig gcc
csky defconfig gcc
csky randconfig-001-20231210 gcc
csky randconfig-002-20231210 gcc
hexagon allnoconfig clang
hexagon defconfig clang
hexagon randconfig-001-20231210 clang
hexagon randconfig-002-20231210 clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 buildonly-randconfig-001-20231209 gcc
i386 buildonly-randconfig-002-20231209 gcc
i386 buildonly-randconfig-003-20231209 gcc
i386 buildonly-randconfig-004-20231209 gcc
i386 buildonly-randconfig-005-20231209 gcc
i386 buildonly-randconfig-006-20231209 gcc
i386 defconfig gcc
i386 randconfig-001-20231209 gcc
i386 randconfig-002-20231209 gcc
i386 randconfig-003-20231209 gcc
i386 randconfig-004-20231209 gcc
i386 randconfig-005-20231209 gcc
i386 randconfig-006-20231209 gcc
i386 randconfig-011-20231209 clang
i386 randconfig-012-20231209 clang
i386 randconfig-013-20231209 clang
i386 randconfig-014-20231209 clang
i386 randconfig-015-20231209 clang
i386 randconfig-016-20231209 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20231210 gcc
loongarch randconfig-002-20231210 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze defconfig gcc
mips allnoconfig clang
nios2 allnoconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20231210 gcc
nios2 randconfig-002-20231210 gcc
openrisc allnoconfig gcc
openrisc defconfig gcc
parisc allnoconfig gcc
parisc defconfig gcc
parisc randconfig-001-20231210 gcc
parisc randconfig-002-20231210 gcc
parisc64 defconfig gcc
powerpc allnoconfig gcc
powerpc randconfig-001-20231210 gcc
powerpc randconfig-002-20231210 gcc
powerpc randconfig-003-20231210 gcc
powerpc64 randconfig-001-20231210 gcc
powerpc64 randconfig-002-20231210 gcc
powerpc64 randconfig-003-20231210 gcc
riscv allnoconfig clang
riscv defconfig gcc
riscv randconfig-001-20231210 gcc
riscv randconfig-002-20231210 gcc
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-001-20231210 clang
s390 randconfig-002-20231210 clang
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh randconfig-001-20231210 gcc
sh randconfig-002-20231210 gcc
sparc allmodconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 randconfig-001-20231210 gcc
sparc64 randconfig-002-20231210 gcc
um allmodconfig clang
um allyesconfig clang
um randconfig-001-20231210 gcc
um randconfig-002-20231210 gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig clang
x86_64 defconfig gcc
x86_64 rhel-8.3-rust clang
xtensa randconfig-001-20231210 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
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