* Re: [PATCH v2 1/6] Input: cyttsp5 - fix array length
From: Dmitry Torokhov @ 2023-05-02 0:15 UTC (permalink / raw)
To: Maximilian Weigand
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, linux-input,
linux-kernel, devicetree, Alistair Francis
In-Reply-To: <20230501113010.891786-2-mweigand@mweigand.net>
On Mon, May 01, 2023 at 01:30:05PM +0200, Maximilian Weigand wrote:
> The cmd array should be initialized with the proper command size and not
> with the actual command value that is sent to the touchscreen.
>
> Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
> Reviewed-by: Alistair Francis <alistair@alistair23.me>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 4/6] Input: cyttsp5 - properly initialize the device as a pm wakeup device
From: Dmitry Torokhov @ 2023-05-02 0:14 UTC (permalink / raw)
To: Maximilian Weigand
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, linux-input,
linux-kernel, devicetree, Alistair Francis
In-Reply-To: <20230501113010.891786-5-mweigand@mweigand.net>
Hi Maximilian,
On Mon, May 01, 2023 at 01:30:08PM +0200, Maximilian Weigand wrote:
> When used as a wakeup source the driver should be properly registered
> with the pm system using device_init_wakeup.
This is an I2C device and I2C core already handles setting up a device
as a wakeup source, this patch is not needed as far as I can tell.
>
> Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
> Reviewed-by: Alistair Francis <alistair@alistair23.me>
> ---
> drivers/input/touchscreen/cyttsp5.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/input/touchscreen/cyttsp5.c b/drivers/input/touchscreen/cyttsp5.c
> index 55abf568bdf6..f701125357f0 100644
> --- a/drivers/input/touchscreen/cyttsp5.c
> +++ b/drivers/input/touchscreen/cyttsp5.c
> @@ -830,6 +830,9 @@ static int cyttsp5_probe(struct device *dev, struct regmap *regmap, int irq,
> return error;
> }
>
> + if (device_property_read_bool(dev, "wakeup-source"))
> + device_init_wakeup(dev, true);
> +
> error = cyttsp5_startup(ts);
> if (error) {
> dev_err(ts->dev, "Fail initial startup r=%d\n", error);
> --
> 2.39.2
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v9 3/3] HID: cp2112: Fwnode Support
From: Daniel Kaehn @ 2023-05-01 23:35 UTC (permalink / raw)
To: Andy Shevchenko
Cc: robh+dt, krzysztof.kozlowski+dt, jikos, benjamin.tissoires,
bartosz.golaszewski, dmitry.torokhov, devicetree, linux-input,
ethan.twardy
In-Reply-To: <ZBhoHzTr5l38u/kX@smile.fi.intel.com>
On Mon, Mar 20, 2023 at 9:10 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Mar 20, 2023 at 08:40:07AM -0500, Daniel Kaehn wrote:
> > On Mon, Mar 20, 2023 at 8:00 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Mon, Mar 20, 2023 at 02:58:07PM +0200, Andy Shevchenko wrote:
> > > > On Sun, Mar 19, 2023 at 03:48:02PM -0500, Danny Kaehn wrote:
>
> ...
>
> > > > > + device_for_each_child_node(&hdev->dev, child) {
> > > > > + name = fwnode_get_name(child);
> > > > > + ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> > > > > +
> > > > > + if ((name && strcmp("i2c", name) == 0) || (!ret && addr == 0))
> > > > > + device_set_node(&dev->adap.dev, child);
> > > > > + else if ((name && strcmp("gpio", name)) == 0 ||
> > > > > + (!ret && addr == 1))
> > > > > + dev->gc.fwnode = child;
> > > > > + }
> > > >
> > > > Please, make addresses defined explicitly. You may also do it with node naming
> > > > schema:
> > > >
> > > > #define CP2112_I2C_ADR 0
> > > > #define CP2112_GPIO_ADR 1
> > > >
> > > > static const char * const cp2112_cell_names[] = {
> > > > [CP2112_I2C_ADR] = "i2c",
> > > > [CP2112_GPIO_ADR] = "gpio",
> > > > };
> > > >
> > > > device_for_each_child_node(&hdev->dev, child) {
> > > > name = fwnode_get_name(child);
> > > > if (name) {
> > > > ret = match_string(cp2112_cell_names, ARRAY_SIZE(cp2112_cell_names), name);
> > > > if (ret >= 0)
> > > > addr = ret;
> > > > } else
> > > > ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> > > > if (ret < 0)
> > > > ...error handling if needed...
> > > >
> > > > switch (addr) {
> > > > case CP2112_I2C_ADR:
> > > > device_set_node(&dev->adap.dev, child);
> > > > break;
> > > > case CP2112_GPIO_ADR:
> > > > dev->gc.fwnode = child;
> > > > break;
> > > > default:
> > > > ...error handling...
> > > > }
> > > > }
> > >
> > > Btw, don't you use "reg" property for the child nodes? It would be better from
> > > de facto used patterns (we have a couple of mode drivers that have a common
> > > code to read "reg" or _ADR() and that code can be split into a helper and used
> > > here).
> > >
> >
> > Named nodes _seem_ to be preferred in DT for when there isn't a logical /
> > natural numbering to the child nodes. A.e. for USB, reg is used to specify
> > which port, for I2C, which address on the bus, but for two parallel and
> > independent functions on the same device, it seems named nodes would make
> > more sense in DT. Many examples exist in mainline where named nodes are used
> > in DT in this way.
>
> Okay, I'm not an expert in the DT preferable schemas, so I believe DT people
> should answer on this.
>
Hello,
Thanks for all the time spent reviewing this thus far. Following up to
see what my next steps might be.
It sounds like we might want some DT folks to weigh in on the strategy
used for identifying the child I2C and GPIO nodes for the CP2112
device before moving further toward applying this.
Since the DT list is on this thread (as well as Rob+Krzystof), and
this has sat for a little while, I'm assuming that the ball is in my
court to seek out an answer/opinion here. (I know folks get a lot of
email, so apologies if the correct move would have been to wait a bit
longer before following up! Not intending to be rude.)
Would it be appropriate / expected that I send a separate email thread
to the DT mailing list on their opinion here? Or would that create
more confusion/complexity in adding yet another thread? I did create a
separate email thread for the initial DT vs. ACPI conversation we had
about accessing children by name or index in a unified way due to the
differences in upper/lower case and use-cases, but that
(understandably) didn't seem to gain any traction.
Thanks for any insights!
Thanks,
Danny Kaehn
> > One example is network cards which provide an mdio bus
> > bind through the child "mdio". One example of a specifically a
> > child i2c controller being bound to "i2c" can be found in
> > pine64,pinephone-keyboard.yaml.
> > But it's certainly possible this isn't the desired direction moving forward
> > in DT -- my opinion should definitely be taken with a grain of salt. Maybe
> > this is something I should follow up on with DT folks on that DT vs. ACPI
> > thread made earlier.
> >
> > One thing I did notice when looking at the mfd subsystem is that most DT
> > drivers actually match on the compatible string of the child nodes, a.e.
> > "silabs,cp2112", "silabs,cp2112-gpio". "silabs,cp2112-i2c". We could
> > implement that here, but I think that would make more sense if we were to
> > actually split the cp2112 into mfd & platform drivers, and additionally split
> > the DT binding by function.
>
> IIRC (but might be very well mistaken) the compatible strings for children
> are discouraged.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* [git pull] Input updates for v6.4-rc0
From: Dmitry Torokhov @ 2023-05-01 23:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v6.4-rc0
to receive updates for the input subsystem. You will get:
- a new driver for Novatek touch controllers
- a new driver for power button for NXP BBNSM
- a skeleton KUnit tests for the input core
- improvements to Xpad game controller driver to support more devices
- improvements to edt-ft5x06, hideep and other drivers
Changelog:
---------
Andy Shevchenko (1):
Input: matrix_keypad - replace header inclusions by forward declarations
Benjamin Bara (1):
Input: tsc2007 - enable cansleep pendown GPIO
Daniel Golle (1):
Input: edt-ft5x06 - select REGMAP_I2C
Dario Binacchi (9):
Input: edt-ft5x06 - fix indentation
Input: edt-ft5x06 - remove unnecessary blank lines
Input: edt-ft5x06 - add spaces to ensure format specification
Input: edt-ft5x06 - don't recalculate the CRC
Input: edt-ft5x06 - remove code duplication
Input: edt-ft5x06 - don't print error messages with dev_dbg()
Input: edt-ft5x06 - convert to use regmap API
Input: edt-ft5x06 - unify the crc check
Input: edt-ft5x06 - calculate points data length only once
Dmitry Torokhov (2):
ARM: spitz: include header defining input event codes
Revert "Input: xpad - fix support for some third-party controllers"
Gergo Koteles (1):
Input: gpio-keys - add support for linux,input-value DTS property
Hans de Goede (3):
Input: hideep - silence error in SW_RESET()
Input: hideep - optionally reset controller work mode to native HiDeep protocol
Input: add a new Novatek NVT-ts driver
Jacky Bai (1):
Input: bbnsm_pwrkey - add bbnsm power key support
Javier Martinez Canillas (1):
Input: Add KUnit tests for some of the input core helper functions
Jiapeng Chong (2):
Input: cma3000_d0x - remove unneeded code
Input: synaptics-rmi4 - fix function name in kerneldoc
JungHoon Hyun (1):
Input: melfas_mip4 - report palm touches
Krzysztof Kozlowski (4):
Input: st-keyscan - drop of_match_ptr for ID table
Input: tm2-touchkey - drop of_match_ptr for ID table
Input: sun4i-ts - drop of_match_ptr for ID table
Input: bcm_iproc_tsc - drop of_match_ptr for ID table
Linus Walleij (1):
dt-bindings: google,cros-ec-keyb: Fix spelling error
Miaoqian Lin (1):
Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe
Peng Fan (1):
dt-bindings: input: pwm-beeper: convert to dt schema
Pierre-Loup A. Griffais (1):
Input: xpad - treat Qanba controllers as Xbox360 controllers
Randy Dunlap (1):
Input: hp_sdc_rtc - mark an unused function as __maybe_unused
Rob Herring (3):
Input: Use of_property_read_bool() for boolean properties
Input: zinitix - use of_property_present() for testing DT property presence
dt-bindings: input: Drop unneeded quotes
Uwe Kleine-König (1):
Input: iqs62x-keys - suppress duplicated error message in .remove()
Vicki Pfau (5):
Input: xpad - remove unused field in VID/PID table
Input: xpad - add VID for Turtle Beach controllers
Input: xpad - fix support for some third-party controllers
Input: xpad - add constants for GIP interface numbers
Input: xpad - fix PowerA EnWired Controller guide button
Yang Li (1):
Input: hideep - clean up some inconsistent indenting
Diffstat:
--------
.../bindings/input/google,cros-ec-keyb.yaml | 2 +-
.../devicetree/bindings/input/pwm-beeper.txt | 24 -
.../devicetree/bindings/input/pwm-beeper.yaml | 41 ++
MAINTAINERS | 6 +
arch/arm/mach-pxa/spitz.c | 1 +
drivers/input/Kconfig | 10 +
drivers/input/Makefile | 1 +
drivers/input/joystick/xpad.c | 23 +-
drivers/input/keyboard/gpio_keys.c | 3 +
drivers/input/keyboard/iqs62x-keys.c | 2 +-
drivers/input/keyboard/matrix_keypad.c | 6 +-
drivers/input/keyboard/omap4-keypad.c | 3 +-
drivers/input/keyboard/samsung-keypad.c | 3 +-
drivers/input/keyboard/st-keyscan.c | 2 +-
drivers/input/keyboard/tegra-kbc.c | 3 +-
drivers/input/keyboard/tm2-touchkey.c | 2 +-
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/cma3000_d0x.c | 2 -
drivers/input/misc/hp_sdc_rtc.c | 2 +-
drivers/input/misc/nxp-bbnsm-pwrkey.c | 193 ++++++++
drivers/input/rmi4/rmi_bus.c | 2 +-
drivers/input/tests/.kunitconfig | 3 +
drivers/input/tests/Makefile | 3 +
drivers/input/tests/input_test.c | 150 +++++++
drivers/input/touchscreen/Kconfig | 11 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/bcm_iproc_tsc.c | 2 +-
drivers/input/touchscreen/edt-ft5x06.c | 496 +++++++++++----------
drivers/input/touchscreen/hideep.c | 33 +-
drivers/input/touchscreen/melfas_mip4.c | 19 +-
drivers/input/touchscreen/novatek-nvt-ts.c | 301 +++++++++++++
drivers/input/touchscreen/raspberrypi-ts.c | 3 +-
drivers/input/touchscreen/sun4i-ts.c | 2 +-
drivers/input/touchscreen/tsc2007_core.c | 17 +-
drivers/input/touchscreen/zinitix.c | 2 +-
include/linux/input/matrix_keypad.h | 5 +-
37 files changed, 1067 insertions(+), 324 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.txt
create mode 100644 Documentation/devicetree/bindings/input/pwm-beeper.yaml
create mode 100644 drivers/input/misc/nxp-bbnsm-pwrkey.c
create mode 100644 drivers/input/tests/.kunitconfig
create mode 100644 drivers/input/tests/Makefile
create mode 100644 drivers/input/tests/input_test.c
create mode 100644 drivers/input/touchscreen/novatek-nvt-ts.c
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: xpad - Move Xbox 360 magic packet sending
From: Dmitry Torokhov @ 2023-05-01 22:11 UTC (permalink / raw)
To: Vicki Pfau; +Cc: Dan Carpenter, Dongliang Mu, linux-input
In-Reply-To: <2be8ff85-57d3-fd80-adcd-a7dc50c2e27d@endrift.com>
On Fri, Apr 28, 2023 at 04:15:01PM -0700, Vicki Pfau wrote:
> Hi Dmitry,
>
> On 4/18/23 21:28, Dan Carpenter wrote:
> > On Tue, Apr 18, 2023 at 07:24:14PM -0700, Vicki Pfau wrote:
> >> This moves the sending of the magic packet introduced in db7220c48d8d from
> >> xpad_probe to xpad_start_input to ensure that xpad->dev->dev exists in the
> >> event that an error occurs. This should also fix issues with suspend that may
> >> occur with some controllers.
> >>
> >> Fixes: db7220c48d8d ("Input: xpad - fix support for some third-party controllers")
> >> Signed-off-by: Vicki Pfau <vi@endrift.com>
> >
> > Can you add the syzbot stuff as well and a Reported-by tag for
> > Dongliang Mu as well.
> >
> > Reported-by: syzbot+a3f758b8d8cb7e49afec@syzkaller.appspotmail.com
> > Reported-by: Dongliang Mu <dzm91@hust.edu.cn>
> > Link: https://groups.google.com/g/syzkaller-bugs/c/iMhTgpGuIbM
>
> Do I need to add these to the commit myself and resend, or, barring code revisions, can this be added when you cherry-pick into the tree?
>
This not only have not been tested on hardware, it was not even
compiled:
CC [M] drivers/input/joystick/xpad.o
drivers/input/joystick/xpad.c: In function ‘xpad_start_input’:
drivers/input/joystick/xpad.c:1733:46: error: ‘udev’ undeclared (first use in this function); did you mean ‘cdev’?
1733 | error = usb_control_msg_recv(udev, 0,
| ^~~~
| cdev
At this point I will simply revert the original patch introducing the issue and
we can try landing this again once it is all rested.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC PATCH 0/3] input: gpio-keys - fix pm ordering
From: Saravana Kannan @ 2023-05-01 20:40 UTC (permalink / raw)
To: Doug Berger
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Dmitry Torokhov,
Lad Prabhakar, Gergo Koteles, Jonathan Cameron, Andy Shevchenko,
Dan Williams, Hans de Goede, Thomas Gleixner, Kees Cook,
Kishon Vijay Abraham I, Florian Fainelli, linux-kernel,
linux-input
In-Reply-To: <20230427221625.116050-1-opendmb@gmail.com>
On Thu, Apr 27, 2023 at 3:18 PM Doug Berger <opendmb@gmail.com> wrote:
>
> Commit 52cdbdd49853 ("driver core: correct device's shutdown
> order") allowed for proper sequencing of the gpio-keys device
> shutdown callbacks by moving the device to the end of the
> devices_kset list at probe which was delayed by child
> dependencies.
>
> However, commit 722e5f2b1eec ("driver core: Partially revert
> "driver core: correct device's shutdown order"") removed this
> portion of that commit causing a reversion in the gpio-keys
> behavior which can prevent waking from shutdown.
>
> This RFC is an attempt to find a better solution for properly
> creating gpio-keys device links to ensure its suspend/resume and
> shutdown services are invoked before those of its suppliers.
>
> The first patch here is pretty brute force but simple and has
> the advantage that it should be easily backportable to the
> versions where the regression first occurred.
We really shouldn't be calling device_pm_move_to_tail() in drivers
because device link uses device_pm_move_to_tail() for ordering too.
And it becomes a "race" between device links and when the driver calls
device_pm_move_to_tail() and I'm not sure we'll get the same ordering
every time.
>
> The second patch is perhaps better in spirit though still a bit
> inelegant, but it can only be backported to versions of the
> kernel that contain the commit in its 'Fixes:' tag. That isn't
> really a valid 'Fixes:' tag since that commit did not cause the
> regression, but it does represent how far the patch could be
> backported.
>
> Both commits shouldn't really exist in the same kernel so the
> third patch reverts the first in an attempt to make that clear
> (though it may be a source of confusion for some).
>
> Hopefully someone with a better understanding of device links
> will see a less intrusive way to automatically capture these
> dependencies for parent device drivers that implement the
> functions of child node devices.
Can you give a summary of the issue on a real system? I took a look at
the two commits you've referenced above and it's not clear what's
still broken in the 6.3+
But I'd think that just teaching fw_devlink about some property should
be sufficient. If you are facing a real issue, have you made sure you
have fw_devlink=on (this is the default unless you turned it off in
the commandline when it had issues in the past).
-Saravana
>
> Doug Berger (3):
> input: gpio-keys - use device_pm_move_to_tail
> input: gpio-keys - add device links of children
> Revert "input: gpio-keys - use device_pm_move_to_tail"
>
> drivers/input/keyboard/gpio_keys.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: MFD: Convert STMPE to YAML schema
From: Dmitry Torokhov @ 2023-05-01 16:25 UTC (permalink / raw)
To: Rob Herring
Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
Maxime Coquelin, Alexandre Torgue, Lee Jones, Philippe Schenker,
Stefan Agner, Marek Vasut, Steffen Trumtrar, linux-gpio,
devicetree, linux-stm32, linux-arm-kernel, linux-kernel,
linux-input
In-Reply-To: <20230427161633.GA3112472-robh@kernel.org>
On Thu, Apr 27, 2023 at 11:16:33AM -0500, Rob Herring wrote:
> On Wed, Apr 26, 2023 at 01:21:39PM +0200, Linus Walleij wrote:
> > This converts the STMPE MFD device tree bindings to the YAML
> > schema.
> >
> > Reference the existing schema for the ADC, just define the
> > other subnode schemas directly in the MFD schema.
> >
> > Add two examples so we have examples covering both the simple
> > GPIO expander and the more complex with ADC and touchscreen.
> >
> > Some in-tree users do not follow the naming conventions for nodes
> > so these DTS files need to be augmented to use proper node names
> > like "adc", "pwm", "gpio", "keyboard-controller" etc before the
> > bindings take effect on them.
> >
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > ChangeLog v1->v2:
> > - Split off the GPIO bindings to their own schema, as the old
> > bindings didn't even have any GPIO bindings. Put the GPIO
> > schema before this schema so we can use GPIO in the examples.
> > - Drop nodename and pattern as STMPE is not a generic name.
> > - Add maxItems to the resets.
> > - Make wakeup-source just :true, as it is a generic property.
> > - Move unevaluatedProperties for subnodes right before properties
> > as requested.
> > - Name devices "port-expander" in the examples.
> > - Use lowercase hex in line init.
> > ---
> > .../devicetree/bindings/input/stmpe-keypad.txt | 41 ---
> > .../bindings/input/touchscreen/stmpe.txt | 108 --------
Since Rob is happy with the bindings, for the input bits:
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: Fwd: [PATCH 1/2] dt-bindings: input: microchip,cap11xx: add advanced sensitivity settings
From: Jeff LaBundy @ 2023-05-01 15:49 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: 8a790966-d985-c0fc-498e-c17e69a6622e, devicetree, dmitry.torokhov,
jiriv, linux-input, linux-kernel, robh+dt, u.kleine-koenig
In-Reply-To: <403412d0-18b8-8d2f-e044-0e27b06a2d12@linaro.org>
Hi Krzysztof and Jiri,
On Mon, May 01, 2023 at 08:37:49AM +0200, Krzysztof Kozlowski wrote:
> On 28/04/2023 19:09, Jiri Valek - 2N wrote:
> > Hi Krzysztof,
> > and thanks for the review
> >
> > On 4/15/23 11:10, Krzysztof Kozlowski wrote:
> >> On 15/04/2023 01:38, Jiri Valek - 2N wrote:
> >>> Add support for advanced sensitivity settings and signal guard feature.
> >>>
> >>> Signed-off-by: Jiri Valek - 2N <jiriv@axis.com>
> >>> ---
[...]
> >>> + microchip,input-treshold:
> >>> + minItems: 3
> >>> + maxItems: 8
> >>> + minimum: 0
> >>> + maximum: 127
> >>> + default: 64
> >>> + description: |
> >>> + Optional parameter. Specifies the delta threshold that is used to
> >>> + determine if a touch has been detected.
> >>> + The number of entries must correspond to the number of channels.
> >>> +
> >>> + microchip,calib-sensitivity:
> >>> + minItems: 3
> >>> + maxItems: 8
> >>> + enum: [1, 2, 4]
> >>> + default: 1
> >>> + description: |
> >>> + Optional parameter supported only for CAP129x. Specifies an array of
> >>> + numeric values that controls the gain used by the calibration routine to
> >>> + enable sensor inputs to be more sensitive for proximity detection.
> >>> + The number of entries must correspond to the number of channels.
> >>
> >> Most of these properties do not look like hardware properties. Policies
> >> and runtime configuration should not be put into DT. Explain please why
> >> these are board-specific thus suitable for DT.
> >
> > All these parameters are intended to set HW properties of touch buttons.
>
> I know, but some HW properties are software policies. Consider the
> simplest example - audio volume of a speaker. It's a hardware property,
> but it is not for DT. Software should choose audio volume based on
> user's decisions.
>
> > Each button can have different PCB layout and when you start without
> > setting these parameters in DT, then touches won't be detected or you
> > will get false positive readings.
> > E.g. 'signal-guard' change property of analog input from button to some
> > type of shield.
> > I made all of them optional for backward compatibility.
> > Maybe 'sensitivity-base-shift' is really not necessary to have in DT.
> > I will remove it if you agree.
>
> Keep only ones which are not policies but depend on physical/electrical
> characteristic of boards.
For capacitive sensing devices such as this, the threshold is specified
based on the size of the electrode and properties of the physical overlay.
Unlike speaker volume, it is a static property that is often times advised
by the module vendor.
Based on a quick scan of this patch, all of the properties proposed here
seem appropriate for DT and are in line with the properties exposed for
comparable devices (e.g. azoteq,thresh).
>
> Best regards,
> Krzysztof
>
Kind regards,
Jeff LaBundy
^ permalink raw reply
* Re: [RFC v1 0/4] Input: support virtual objects on touchscreens
From: Linus Walleij @ 2023-05-01 12:32 UTC (permalink / raw)
To: Javier Carrasco
Cc: linux-input, devicetree, linux-kernel, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Henrik Rydberg, Ulf Hansson,
Hans Verkuil, Stephen Boyd, Sebastian Reichel, Jonathan Cameron,
Uwe Kleine-g, Bastian Hecht, Michael Riesch
In-Reply-To: <20230425115049.870003-1-javier.carrasco@wolfvision.net>
On Tue, Apr 25, 2023 at 1:51 PM Javier Carrasco
<javier.carrasco@wolfvision.net> wrote:
> Some touchscreens are shipped with a physical layer on top of them where
> a number of buttons and a resized touchscreen surface might be available.
The APQ8060 DragonBoard even shipped with two different
stickers to be put over the touchscreen: one for Android and
another one for Windows Mobile.
True story!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 6/6] Input: cyttsp5 - implement proper sleep and wakeup procedures
From: Maximilian Weigand @ 2023-05-01 11:30 UTC (permalink / raw)
To: Linus Walleij, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
linux-input, linux-kernel, devicetree
Cc: Maximilian Weigand, Alistair Francis
In-Reply-To: <20230501113010.891786-1-mweigand@mweigand.net>
The touchscreen can be put into a deep sleep state that prevents it from
emitting touch irqs. Put the touchscreen into deep sleep during suspend
if it is not marked as a wakeup source.
This also fixes a problem with the touchscreen getting unresponsive after
system resume because it pulled the interrupt line low during sleep in
response to a touch event, thereby effectively disabling the interrupt
handling (which triggers on the falling edge).
Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
---
drivers/input/touchscreen/cyttsp5.c | 125 +++++++++++++++++++++++++++-
1 file changed, 124 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/cyttsp5.c b/drivers/input/touchscreen/cyttsp5.c
index f701125357f0..54b1c9512e4d 100644
--- a/drivers/input/touchscreen/cyttsp5.c
+++ b/drivers/input/touchscreen/cyttsp5.c
@@ -43,6 +43,7 @@
#define HID_DESC_REG 0x1
#define HID_INPUT_REG 0x3
#define HID_OUTPUT_REG 0x4
+#define HID_COMMAND_REG 0x5
#define REPORT_ID_TOUCH 0x1
#define REPORT_ID_BTN 0x3
@@ -68,6 +69,7 @@
#define HID_APP_OUTPUT_REPORT_ID 0x2F
#define HID_BL_RESPONSE_REPORT_ID 0x30
#define HID_BL_OUTPUT_REPORT_ID 0x40
+#define HID_RESPONSE_REPORT_ID 0xF0
#define HID_OUTPUT_RESPONSE_REPORT_OFFSET 2
#define HID_OUTPUT_RESPONSE_CMD_OFFSET 4
@@ -78,9 +80,15 @@
#define HID_SYSINFO_BTN_MASK GENMASK(7, 0)
#define HID_SYSINFO_MAX_BTN 8
+#define HID_CMD_SET_POWER 0x8
+
+#define HID_POWER_ON 0x0
+#define HID_POWER_SLEEP 0x1
+
#define CY_HID_OUTPUT_TIMEOUT_MS 200
#define CY_HID_OUTPUT_GET_SYSINFO_TIMEOUT_MS 3000
#define CY_HID_GET_HID_DESCRIPTOR_TIMEOUT_MS 4000
+#define CY_HID_SET_POWER_TIMEOUT 500
/* maximum number of concurrent tracks */
#define TOUCH_REPORT_SIZE 10
@@ -100,6 +108,14 @@
#define TOUCH_REPORT_USAGE_PG_MIN 0xFF010063
#define TOUCH_COL_USAGE_PG 0x000D0022
+#define SET_CMD_LOW(byte, bits) \
+ ((byte) = (((byte) & 0xF0) | ((bits) & 0x0F)))
+#define SET_CMD_HIGH(byte, bits)\
+ ((byte) = (((byte) & 0x0F) | ((bits) & 0xF0)))
+#define SET_CMD_OPCODE(byte, opcode) SET_CMD_LOW(byte, opcode)
+#define SET_CMD_REPORT_TYPE(byte, type) SET_CMD_HIGH(byte, ((type) << 4))
+#define SET_CMD_REPORT_ID(byte, id) SET_CMD_LOW(byte, id)
+
/* System Information interface definitions */
struct cyttsp5_sensing_conf_data_dev {
u8 electrodes_x;
@@ -180,6 +196,7 @@ struct cyttsp5_hid_desc {
struct cyttsp5 {
struct device *dev;
struct completion cmd_done;
+ struct completion cmd_command_done;
struct cyttsp5_sysinfo sysinfo;
struct cyttsp5_hid_desc hid_desc;
u8 cmd_buf[CYTTSP5_PREALLOCATED_CMD_BUFFER];
@@ -192,6 +209,7 @@ struct cyttsp5 {
struct regmap *regmap;
struct touchscreen_properties prop;
struct regulator *vdd;
+ bool is_wakeup_source;
};
/*
@@ -557,6 +575,82 @@ static int cyttsp5_hid_output_get_sysinfo(struct cyttsp5 *ts)
return cyttsp5_get_sysinfo_regs(ts);
}
+static int cyttsp5_enter_sleep(struct cyttsp5 *ts)
+{
+ int rc;
+ u8 cmd[2];
+
+ memset(cmd, 0, sizeof(cmd));
+
+ SET_CMD_REPORT_TYPE(cmd[0], 0);
+ SET_CMD_REPORT_ID(cmd[0], HID_POWER_SLEEP);
+ SET_CMD_OPCODE(cmd[1], HID_CMD_SET_POWER);
+
+ rc = cyttsp5_write(ts, HID_COMMAND_REG, cmd, 2);
+ if (rc) {
+ dev_err(ts->dev, "Failed to write command %d", rc);
+ return rc;
+ }
+
+ rc = wait_for_completion_interruptible_timeout(&ts->cmd_command_done,
+ msecs_to_jiffies(CY_HID_SET_POWER_TIMEOUT));
+ if (rc <= 0) {
+ dev_err(ts->dev, "HID output cmd execution timed out\n");
+ rc = -ETIMEDOUT;
+ return rc;
+ }
+
+ /* validate */
+ if ((ts->response_buf[2] != HID_RESPONSE_REPORT_ID)
+ || ((ts->response_buf[3] & 0x3) != HID_POWER_SLEEP)
+ || ((ts->response_buf[4] & 0xF) != HID_CMD_SET_POWER)) {
+ rc = -EINVAL;
+ dev_err(ts->dev, "Validation of the sleep response failed\n");
+ return rc;
+ }
+
+ return 0;
+
+}
+
+static int cyttsp5_wakeup(struct cyttsp5 *ts)
+{
+ int rc;
+ u8 cmd[2];
+
+ memset(cmd, 0, sizeof(cmd));
+
+ SET_CMD_REPORT_TYPE(cmd[0], 0);
+ SET_CMD_REPORT_ID(cmd[0], HID_POWER_ON);
+ SET_CMD_OPCODE(cmd[1], HID_CMD_SET_POWER);
+
+ rc = cyttsp5_write(ts, HID_COMMAND_REG, cmd, 2);
+ if (rc) {
+ dev_err(ts->dev, "Failed to write command %d", rc);
+ return rc;
+ }
+
+ rc = wait_for_completion_interruptible_timeout(&ts->cmd_command_done,
+ msecs_to_jiffies(CY_HID_SET_POWER_TIMEOUT));
+ if (rc <= 0) {
+ dev_err(ts->dev, "HID output cmd execution timed out\n");
+ rc = -ETIMEDOUT;
+ return rc;
+ }
+
+ /* validate */
+ if ((ts->response_buf[2] != HID_RESPONSE_REPORT_ID)
+ || ((ts->response_buf[3] & 0x3) != HID_POWER_ON)
+ || ((ts->response_buf[4] & 0xF) != HID_CMD_SET_POWER)) {
+ rc = -EINVAL;
+ dev_err(ts->dev, "Validation of the sleep response failed\n");
+ return rc;
+ }
+
+ return 0;
+
+}
+
static int cyttsp5_hid_output_bl_launch_app(struct cyttsp5 *ts)
{
int rc;
@@ -670,6 +764,10 @@ static irqreturn_t cyttsp5_handle_irq(int irq, void *handle)
case HID_BTN_REPORT_ID:
cyttsp5_btn_attention(ts->dev);
break;
+ case HID_RESPONSE_REPORT_ID:
+ memcpy(ts->response_buf, ts->input_buf, size);
+ complete(&ts->cmd_command_done);
+ break;
default:
/* It is not an input but a command response */
memcpy(ts->response_buf, ts->input_buf, size);
@@ -784,6 +882,7 @@ static int cyttsp5_probe(struct device *dev, struct regmap *regmap, int irq,
dev_set_drvdata(dev, ts);
init_completion(&ts->cmd_done);
+ init_completion(&ts->cmd_command_done);
/* Power up the device */
ts->vdd = devm_regulator_get(dev, "vdd");
@@ -830,8 +929,11 @@ static int cyttsp5_probe(struct device *dev, struct regmap *regmap, int irq,
return error;
}
- if (device_property_read_bool(dev, "wakeup-source"))
+ if (device_property_read_bool(dev, "wakeup-source")) {
device_init_wakeup(dev, true);
+ ts->is_wakeup_source = true;
+ } else
+ ts->is_wakeup_source = false;
error = cyttsp5_startup(ts);
if (error) {
@@ -884,6 +986,27 @@ static const struct i2c_device_id cyttsp5_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, cyttsp5_i2c_id);
+static int __maybe_unused cyttsp5_suspend(struct device *dev)
+{
+ struct cyttsp5 *ts = dev_get_drvdata(dev);
+
+ if (!ts->is_wakeup_source)
+ cyttsp5_enter_sleep(ts);
+ return 0;
+}
+
+static int __maybe_unused cyttsp5_resume(struct device *dev)
+{
+ struct cyttsp5 *ts = dev_get_drvdata(dev);
+
+ if (!ts->is_wakeup_source)
+ cyttsp5_wakeup(ts);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(cyttsp5_pm, cyttsp5_suspend, cyttsp5_resume);
+
static struct i2c_driver cyttsp5_i2c_driver = {
.driver = {
.name = CYTTSP5_NAME,
--
2.39.2
^ permalink raw reply related
* [PATCH v2 5/6] dt-bindings: input: cypress,tt21000 - add wakeup-source entry to documentation
From: Maximilian Weigand @ 2023-05-01 11:30 UTC (permalink / raw)
To: Linus Walleij, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
linux-input, linux-kernel, devicetree
Cc: Maximilian Weigand, Alistair Francis
In-Reply-To: <20230501113010.891786-1-mweigand@mweigand.net>
The touchscreen can be used to wake up systems from sleep and therefore
the wakeup-source entry should be included in the documentation.
Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
.../devicetree/bindings/input/touchscreen/cypress,tt21000.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml b/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
index a77203c78d6e..e2da13b7991d 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
@@ -40,6 +40,8 @@ properties:
linux,keycodes:
description: EV_ABS specific event code generated by the axis.
+ wakeup-source: true
+
patternProperties:
"^button@[0-9]+$":
type: object
--
2.39.2
^ permalink raw reply related
* [PATCH v2 4/6] Input: cyttsp5 - properly initialize the device as a pm wakeup device
From: Maximilian Weigand @ 2023-05-01 11:30 UTC (permalink / raw)
To: Linus Walleij, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
linux-input, linux-kernel, devicetree
Cc: Maximilian Weigand, Alistair Francis
In-Reply-To: <20230501113010.891786-1-mweigand@mweigand.net>
When used as a wakeup source the driver should be properly registered
with the pm system using device_init_wakeup.
Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
---
drivers/input/touchscreen/cyttsp5.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/touchscreen/cyttsp5.c b/drivers/input/touchscreen/cyttsp5.c
index 55abf568bdf6..f701125357f0 100644
--- a/drivers/input/touchscreen/cyttsp5.c
+++ b/drivers/input/touchscreen/cyttsp5.c
@@ -830,6 +830,9 @@ static int cyttsp5_probe(struct device *dev, struct regmap *regmap, int irq,
return error;
}
+ if (device_property_read_bool(dev, "wakeup-source"))
+ device_init_wakeup(dev, true);
+
error = cyttsp5_startup(ts);
if (error) {
dev_err(ts->dev, "Fail initial startup r=%d\n", error);
--
2.39.2
^ permalink raw reply related
* [PATCH v2 3/6] dt-bindings: input: cypress,tt21000 - fix interrupt type in dts example
From: Maximilian Weigand @ 2023-05-01 11:30 UTC (permalink / raw)
To: Linus Walleij, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
linux-input, linux-kernel, devicetree
Cc: Maximilian Weigand, Alistair Francis
In-Reply-To: <20230501113010.891786-1-mweigand@mweigand.net>
Triggering the interrupt of the IRQ_TYPE_LEVEL_LOW type can lead to
probing issues with the device for the current driver (encountered on
the Pine64 PineNote). Basically the interrupt would be triggered before
certain commands were sent to the device, leading to a race between the
device responding fast enough and the irq handler fetching a data frame
from it. Actually all devices currently using the driver already use a
falling edge trigger.
Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
.../devicetree/bindings/input/touchscreen/cypress,tt21000.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml b/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
index 1959ec394768..a77203c78d6e 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
@@ -83,7 +83,7 @@ examples:
pinctrl-names = "default";
pinctrl-0 = <&tp_reset_ds203>;
interrupt-parent = <&pio>;
- interrupts = <1 5 IRQ_TYPE_LEVEL_LOW>;
+ interrupts = <1 5 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>;
vdd-supply = <®_touch>;
--
2.39.2
^ permalink raw reply related
* [PATCH v2 2/6] Input: cyttsp5 - remove unused code
From: Maximilian Weigand @ 2023-05-01 11:30 UTC (permalink / raw)
To: Linus Walleij, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
linux-input, linux-kernel, devicetree
Cc: Maximilian Weigand, Alistair Francis
In-Reply-To: <20230501113010.891786-1-mweigand@mweigand.net>
The removed lines are remnants of the vendor driver and are not used in
the upstream driver.
Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
---
drivers/input/touchscreen/cyttsp5.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/input/touchscreen/cyttsp5.c b/drivers/input/touchscreen/cyttsp5.c
index 3c9d07218f48..55abf568bdf6 100644
--- a/drivers/input/touchscreen/cyttsp5.c
+++ b/drivers/input/touchscreen/cyttsp5.c
@@ -601,12 +601,7 @@ static int cyttsp5_get_hid_descriptor(struct cyttsp5 *ts,
struct cyttsp5_hid_desc *desc)
{
struct device *dev = ts->dev;
- __le16 hid_desc_register = cpu_to_le16(HID_DESC_REG);
int rc;
- u8 cmd[2];
-
- /* Set HID descriptor register */
- memcpy(cmd, &hid_desc_register, sizeof(hid_desc_register));
rc = cyttsp5_write(ts, HID_DESC_REG, NULL, 0);
if (rc) {
--
2.39.2
^ permalink raw reply related
* [PATCH v2 1/6] Input: cyttsp5 - fix array length
From: Maximilian Weigand @ 2023-05-01 11:30 UTC (permalink / raw)
To: Linus Walleij, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
linux-input, linux-kernel, devicetree
Cc: Maximilian Weigand, Alistair Francis
In-Reply-To: <20230501113010.891786-1-mweigand@mweigand.net>
The cmd array should be initialized with the proper command size and not
with the actual command value that is sent to the touchscreen.
Signed-off-by: Maximilian Weigand <mweigand@mweigand.net>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
---
drivers/input/touchscreen/cyttsp5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/cyttsp5.c b/drivers/input/touchscreen/cyttsp5.c
index 30102cb80fac..3c9d07218f48 100644
--- a/drivers/input/touchscreen/cyttsp5.c
+++ b/drivers/input/touchscreen/cyttsp5.c
@@ -560,7 +560,7 @@ static int cyttsp5_hid_output_get_sysinfo(struct cyttsp5 *ts)
static int cyttsp5_hid_output_bl_launch_app(struct cyttsp5 *ts)
{
int rc;
- u8 cmd[HID_OUTPUT_BL_LAUNCH_APP];
+ u8 cmd[HID_OUTPUT_BL_LAUNCH_APP_SIZE];
u16 crc;
put_unaligned_le16(HID_OUTPUT_BL_LAUNCH_APP_SIZE, cmd);
--
2.39.2
^ permalink raw reply related
* [PATCH v2 0/6] Small fixes to the cyttsp5 touchscreen driver
From: Maximilian Weigand @ 2023-05-01 11:30 UTC (permalink / raw)
To: Linus Walleij, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
linux-input, linux-kernel, devicetree
Cc: Maximilian Weigand, Alistair Francis
While working on some intermittent module-loading problems of the
cyttsp5 module on the Pine64 PineNote it was found that the device tree
example of the cypress,tt21000 was in error regarding the interrupt
type (IRQ_TYPE_EDGE_FALLING should be used instead of IRQ_TYPE_LEVEL_LOW).
This lead to the proper implementation of device sleep states, which is
required to ensure proper functioning of the touchscreen after resume
when the correct interrupt type IRQ_TYPE_FALLING_EDGE is used. Sleep and
wakeup commands to the touchscreen were derived from the GPL-2 android
driver by Cypress Semiconductor (copyright note for Cypress
Semiconductor is already in the current driver).
The first two patches fix small issues with the code found during
development of the suspend functionality.
Changes in v2:
- fix subject lines
- fix 'unused variable' errors reported by the kernel test robot
- clean up commit message of patch 2
Maximilian Weigand (6):
Input: cyttsp5 - fix array length
Input: cyttsp5 - remove unused code
dt-bindings: input: cypress,tt21000 - fix interrupt type in dts
example
Input: cyttsp5 - properly initialize the device as a pm wakeup device
dt-bindings: input: cypress,tt21000 - add wakeup-source entry to
documentation
Input: cyttsp5 - implement proper sleep and wakeup procedures
.../input/touchscreen/cypress,tt21000.yaml | 4 +-
drivers/input/touchscreen/cyttsp5.c | 133 +++++++++++++++++-
2 files changed, 130 insertions(+), 7 deletions(-)
base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
--
2.39.2
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: input: pwm-vibrator: Add enable-gpio
From: Krzysztof Kozlowski @ 2023-05-01 6:48 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Sebastian Reichel, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Brian Masney
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20230427-hammerhead-vibra-v1-1-e87eeb94da51@z3ntu.xyz>
On 27/04/2023 22:34, Luca Weiss wrote:
> Some pwm vibrators have a dedicated enable GPIO that needs to be set
> high so that the vibrator works. Document that.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: Fwd: [PATCH 1/2] dt-bindings: input: microchip,cap11xx: add advanced sensitivity settings
From: Krzysztof Kozlowski @ 2023-05-01 6:37 UTC (permalink / raw)
To: 8a790966-d985-c0fc-498e-c17e69a6622e
Cc: devicetree, dmitry.torokhov, jiriv, linux-input, linux-kernel,
robh+dt, u.kleine-koenig
In-Reply-To: <1511d33b-dab3-cddb-cbf2-7db016678362@axis.com>
On 28/04/2023 19:09, Jiri Valek - 2N wrote:
> Hi Krzysztof,
> and thanks for the review
>
> On 4/15/23 11:10, Krzysztof Kozlowski wrote:
>> On 15/04/2023 01:38, Jiri Valek - 2N wrote:
>>> Add support for advanced sensitivity settings and signal guard feature.
>>>
>>> Signed-off-by: Jiri Valek - 2N <jiriv@axis.com>
>>> ---
>>> .../bindings/input/microchip,cap11xx.yaml | 64 ++++++++++++++++++-
>>> 1 file changed, 61 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
>>> index 5fa625b5c5fb..08e28226a164 100644
>>> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
>>> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
>>> @@ -45,13 +45,13 @@ properties:
>>> Enables the Linux input system's autorepeat feature on the input device.
>>>
>>> linux,keycodes:
>>> - minItems: 6
>>> - maxItems: 6
>>> + minItems: 3
>>> + maxItems: 8
>>> description: |
>>> Specifies an array of numeric keycode values to
>>> be used for the channels. If this property is
>>> omitted, KEY_A, KEY_B, etc are used as defaults.
>>> - The array must have exactly six entries.
>>> + The number of entries must correspond to the number of channels.
>>>
>>> microchip,sensor-gain:
>>> $ref: /schemas/types.yaml#/definitions/uint32
>>> @@ -70,6 +70,58 @@ properties:
>>> open drain. This property allows using the active
>>> high push-pull output.
>>>
>>> + microchip,sensitivity-delta-sense:
>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>> + default: 32
>>> + enum: [1, 2, 4, 8, 16, 32, 64, 128]
>>> + description: |
>>
>> Do not need '|' unless you need to preserve formatting.
>
> OK. Will remove them.
>
>>
>>> + Optional parameter. Controls the sensitivity multiplier of a touch detection.
>>> + At the more sensitive settings, touches are detected for a smaller delta
>>> + capacitance corresponding to a “lighter” touch.
>>> +
>>> + microchip,sensitivity-base-shift:
>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>> + default: 256
>>> + enum: [1, 2, 4, 8, 16, 32, 64, 128, 256]
>>> + description: |
>>> + Optional parameter. Controls data scaling factor.
>>> + The higher the value of these bits, the larger the range and the lower
>>> + the resolution of the data presented. These settings will not affect
>>> + touch detection or sensitivity.
>>> +
>>> + microchip,signal-guard:
>>> + minItems: 3
>>> + maxItems: 8
>>> + enum: [0, 1]
>>> + default: 0
>>
>> This was not really tested. Missing ref, mixing scalar and array
>> properties. You want items with enum. And drop default.
>
> Ack. I will fix it.
>
>>
>>
>>> + description: |
>>> + Optional parameter supported only for CAP129x.
>>
>> Then disallow it for others (allOf:if:then: ...
>> microchip,signal-guard:false)
>
> Ack. I will fix it.
>
>>> + The signal guard isolates the signal from virtual grounds.
>>> + If enabled then the behavior of the channel is changed to signal guard.
>>> + The number of entries must correspond to the number of channels.
>>> +
>>> + microchip,input-treshold:
>>> + minItems: 3
>>> + maxItems: 8
>>> + minimum: 0
>>> + maximum: 127
>>> + default: 64
>>> + description: |
>>> + Optional parameter. Specifies the delta threshold that is used to
>>> + determine if a touch has been detected.
>>> + The number of entries must correspond to the number of channels.
>>> +
>>> + microchip,calib-sensitivity:
>>> + minItems: 3
>>> + maxItems: 8
>>> + enum: [1, 2, 4]
>>> + default: 1
>>> + description: |
>>> + Optional parameter supported only for CAP129x. Specifies an array of
>>> + numeric values that controls the gain used by the calibration routine to
>>> + enable sensor inputs to be more sensitive for proximity detection.
>>> + The number of entries must correspond to the number of channels.
>>
>> Most of these properties do not look like hardware properties. Policies
>> and runtime configuration should not be put into DT. Explain please why
>> these are board-specific thus suitable for DT.
>
> All these parameters are intended to set HW properties of touch buttons.
I know, but some HW properties are software policies. Consider the
simplest example - audio volume of a speaker. It's a hardware property,
but it is not for DT. Software should choose audio volume based on
user's decisions.
> Each button can have different PCB layout and when you start without
> setting these parameters in DT, then touches won't be detected or you
> will get false positive readings.
> E.g. 'signal-guard' change property of analog input from button to some
> type of shield.
> I made all of them optional for backward compatibility.
> Maybe 'sensitivity-base-shift' is really not necessary to have in DT.
> I will remove it if you agree.
Keep only ones which are not policies but depend on physical/electrical
characteristic of boards.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 5/5] ARM: dts: qcom: apq8026-huawei-sturgeon: Add vibrator
From: Luca Weiss @ 2023-04-30 18:20 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Dan Murphy, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Raffaele Tranquillini,
Yassine Oudjana
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree, Luca Weiss
In-Reply-To: <20230430-drv260x-improvements-v1-0-1fb28b4cc698@z3ntu.xyz>
The watch has a DRV2605 for haptics. Add a node for it based on the
values found in the downstream board file.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
arch/arm/boot/dts/qcom-apq8026-huawei-sturgeon.dts | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8026-huawei-sturgeon.dts b/arch/arm/boot/dts/qcom-apq8026-huawei-sturgeon.dts
index d64096028ab1..eb73b992a696 100644
--- a/arch/arm/boot/dts/qcom-apq8026-huawei-sturgeon.dts
+++ b/arch/arm/boot/dts/qcom-apq8026-huawei-sturgeon.dts
@@ -7,6 +7,7 @@
#include "qcom-msm8226.dtsi"
#include "qcom-pm8226.dtsi"
+#include <dt-bindings/input/ti-drv260x.h>
/delete-node/ &adsp_region;
@@ -68,6 +69,26 @@ &adsp {
status = "okay";
};
+&blsp1_i2c2 {
+ clock-frequency = <384000>;
+
+ status = "okay";
+
+ vibrator@5a {
+ compatible = "ti,drv2605";
+ reg = <0x5a>;
+ enable-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
+
+ mode = <DRV260X_ERM_MODE>;
+ library-sel = <DRV260X_ERM_LIB_D>;
+ vib-rated-mv = <2765>;
+ vib-overdrive-mv = <3525>;
+
+ pinctrl-0 = <&vibrator_default_state>;
+ pinctrl-names = "default";
+ };
+};
+
&blsp1_i2c5 {
clock-frequency = <384000>;
@@ -347,6 +368,13 @@ reset-pins {
};
};
+ vibrator_default_state: vibrator-default-state {
+ pins = "gpio59", "gpio60";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
wlan_hostwake_default_state: wlan-hostwake-default-state {
pins = "gpio66";
function = "gpio";
--
2.40.1
^ permalink raw reply related
* [PATCH 3/5] Input: drv260x - remove unused .reg_defaults
From: Luca Weiss @ 2023-04-30 18:20 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Dan Murphy, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Raffaele Tranquillini,
Yassine Oudjana
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree, Luca Weiss
In-Reply-To: <20230430-drv260x-improvements-v1-0-1fb28b4cc698@z3ntu.xyz>
Since the driver has disabled regmap caching with REGCACHE_NONE, it's
warning us that we provide defaults that are not used. Remove them.
[ 0.561159] drv260x-haptics 0-005a: No cache used with register defaults set!
Fixes: 7132fe4f5687 ("Input: drv260x - add TI drv260x haptics driver")
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
drivers/input/misc/drv260x.c | 40 ----------------------------------------
1 file changed, 40 deletions(-)
diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index 884d43eb4b61..a7e3120bdc13 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -193,44 +193,6 @@ struct drv260x_data {
int overdrive_voltage;
};
-static const struct reg_default drv260x_reg_defs[] = {
- { DRV260X_STATUS, 0xe0 },
- { DRV260X_MODE, 0x40 },
- { DRV260X_RT_PB_IN, 0x00 },
- { DRV260X_LIB_SEL, 0x00 },
- { DRV260X_WV_SEQ_1, 0x01 },
- { DRV260X_WV_SEQ_2, 0x00 },
- { DRV260X_WV_SEQ_3, 0x00 },
- { DRV260X_WV_SEQ_4, 0x00 },
- { DRV260X_WV_SEQ_5, 0x00 },
- { DRV260X_WV_SEQ_6, 0x00 },
- { DRV260X_WV_SEQ_7, 0x00 },
- { DRV260X_WV_SEQ_8, 0x00 },
- { DRV260X_GO, 0x00 },
- { DRV260X_OVERDRIVE_OFF, 0x00 },
- { DRV260X_SUSTAIN_P_OFF, 0x00 },
- { DRV260X_SUSTAIN_N_OFF, 0x00 },
- { DRV260X_BRAKE_OFF, 0x00 },
- { DRV260X_A_TO_V_CTRL, 0x05 },
- { DRV260X_A_TO_V_MIN_INPUT, 0x19 },
- { DRV260X_A_TO_V_MAX_INPUT, 0xff },
- { DRV260X_A_TO_V_MIN_OUT, 0x19 },
- { DRV260X_A_TO_V_MAX_OUT, 0xff },
- { DRV260X_RATED_VOLT, 0x3e },
- { DRV260X_OD_CLAMP_VOLT, 0x8c },
- { DRV260X_CAL_COMP, 0x0c },
- { DRV260X_CAL_BACK_EMF, 0x6c },
- { DRV260X_FEEDBACK_CTRL, 0x36 },
- { DRV260X_CTRL1, 0x93 },
- { DRV260X_CTRL2, 0xfa },
- { DRV260X_CTRL3, 0xa0 },
- { DRV260X_CTRL4, 0x20 },
- { DRV260X_CTRL5, 0x80 },
- { DRV260X_LRA_LOOP_PERIOD, 0x33 },
- { DRV260X_VBAT_MON, 0x00 },
- { DRV260X_LRA_RES_PERIOD, 0x00 },
-};
-
#define DRV260X_DEF_RATED_VOLT 0x90
#define DRV260X_DEF_OD_CLAMP_VOLT 0x90
@@ -453,8 +415,6 @@ static const struct regmap_config drv260x_regmap_config = {
.val_bits = 8,
.max_register = DRV260X_MAX_REG,
- .reg_defaults = drv260x_reg_defs,
- .num_reg_defaults = ARRAY_SIZE(drv260x_reg_defs),
.cache_type = REGCACHE_NONE,
};
--
2.40.1
^ permalink raw reply related
* [PATCH 1/5] Input: drv260x - fix typo in register value define
From: Luca Weiss @ 2023-04-30 18:20 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Dan Murphy, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Raffaele Tranquillini,
Yassine Oudjana
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree, Luca Weiss
In-Reply-To: <20230430-drv260x-improvements-v1-0-1fb28b4cc698@z3ntu.xyz>
ANANLOG should be ANALOG. Fix the typo.
Fixes: 7132fe4f5687 ("Input: drv260x - add TI drv260x haptics driver")
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
drivers/input/misc/drv260x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index 8a9ebfc04a2d..e95c4e775b5d 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -149,7 +149,7 @@
/* Control 3 Register */
#define DRV260X_LRA_OPEN_LOOP (1 << 0)
-#define DRV260X_ANANLOG_IN (1 << 1)
+#define DRV260X_ANALOG_IN (1 << 1)
#define DRV260X_LRA_DRV_MODE (1 << 2)
#define DRV260X_RTP_UNSIGNED_DATA (1 << 3)
#define DRV260X_SUPPLY_COMP_DIS (1 << 4)
@@ -322,7 +322,7 @@ static const struct reg_sequence drv260x_lra_init_regs[] = {
DRV260X_BEMF_GAIN_3 },
{ DRV260X_CTRL1, DRV260X_STARTUP_BOOST },
{ DRV260X_CTRL2, DRV260X_SAMP_TIME_250 },
- { DRV260X_CTRL3, DRV260X_NG_THRESH_2 | DRV260X_ANANLOG_IN },
+ { DRV260X_CTRL3, DRV260X_NG_THRESH_2 | DRV260X_ANALOG_IN },
{ DRV260X_CTRL4, DRV260X_AUTOCAL_TIME_500MS },
};
--
2.40.1
^ permalink raw reply related
* [PATCH 0/5] Improvements for drv260x driver and add to Huawei Watch
From: Luca Weiss @ 2023-04-30 18:20 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Dan Murphy, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Raffaele Tranquillini,
Yassine Oudjana
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree, Luca Weiss
Clean up some issues with the driver I've noticed while working on it,
then fix the magnitude handling which previously resulted the driver
discarding the upper 8 bits of the magnitude value, and finally we can
add the drv260x to the APQ8026 Huawei Watch.
While the "fix magnitude handling" commit technically changes behavior
and could change behavior of existing user space applications that deal
with this quirky behavior, it's definitely not correct and results in
very unexpected behavior if the user space doesn't look out for it
(meaning only use 0x00-0xFF magnitude, and also know that the magnitude
was interpreted as signed value, see more details in the commit message
there).
There's currently only one other upstream user of the driver,
qcom/msm8996-xiaomi-gemini where I've added the dts authors to this
patch series (Raffaele & Yassine) and some tests on that device would be
nice since it's operating in LRA mode, mine does in ERM mode.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
Luca Weiss (5):
Input: drv260x - fix typo in register value define
Input: drv260x - sleep between polling GO bit
Input: drv260x - remove unused .reg_defaults
Input: drv260x - fix magnitude handling
ARM: dts: qcom: apq8026-huawei-sturgeon: Add vibrator
arch/arm/boot/dts/qcom-apq8026-huawei-sturgeon.dts | 28 +++++++++++
drivers/input/misc/drv260x.c | 56 ++++------------------
2 files changed, 37 insertions(+), 47 deletions(-)
---
base-commit: fa55d47c433364df7361fd4f9b169b5845b06914
change-id: 20230430-drv260x-improvements-e218894a0c5c
Best regards,
--
Luca Weiss <luca@z3ntu.xyz>
^ permalink raw reply
* [PATCH 4/5] Input: drv260x - fix magnitude handling
From: Luca Weiss @ 2023-04-30 18:20 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Dan Murphy, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Raffaele Tranquillini,
Yassine Oudjana
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree, Luca Weiss
In-Reply-To: <20230430-drv260x-improvements-v1-0-1fb28b4cc698@z3ntu.xyz>
First of all, previously the 16-bit magnitude was written as-is to the
device which actually discarded the upper 8 bits since the device has
8-bit registers only. This meant that a strong_magnitude of 0xFF00 would
result in 0. To correct this shift the strong_magnitude / weak_magnitude
input values so we discard the lower 8 bits and keep the upper bits
instead.
Secondly the RTP mode that is used by default interprets the values as
signed (2s complement), so 0x81 = 0%, 0x00 = 50%, 0x7F = 100%. This
doesn't match the FF_RUMBLE interface at all, so let's tell the device
to interpret the data as unsigned instead which gets us 0x00 = 0% and
0xFF = 100%.
As last change switch ERM to using "Closed-Loop Mode, Unidirectional"
instead of "Open-Loop Mode" since it's recommended by the datasheet
compared to open loop and better matches our use case of 0% - 100%
vibration.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
drivers/input/misc/drv260x.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index a7e3120bdc13..f5e96b36acda 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -186,7 +186,7 @@ struct drv260x_data {
struct work_struct work;
struct gpio_desc *enable_gpio;
struct regulator *regulator;
- u32 magnitude;
+ u8 magnitude;
u32 mode;
u32 library;
int rated_voltage;
@@ -237,10 +237,11 @@ static int drv260x_haptics_play(struct input_dev *input, void *data,
haptics->mode = DRV260X_LRA_NO_CAL_MODE;
+ /* Scale u16 magnitude into u8 register value */
if (effect->u.rumble.strong_magnitude > 0)
- haptics->magnitude = effect->u.rumble.strong_magnitude;
+ haptics->magnitude = effect->u.rumble.strong_magnitude >> 8;
else if (effect->u.rumble.weak_magnitude > 0)
- haptics->magnitude = effect->u.rumble.weak_magnitude;
+ haptics->magnitude = effect->u.rumble.weak_magnitude >> 8;
else
haptics->magnitude = 0;
@@ -266,7 +267,7 @@ static void drv260x_close(struct input_dev *input)
static const struct reg_sequence drv260x_lra_cal_regs[] = {
{ DRV260X_MODE, DRV260X_AUTO_CAL },
- { DRV260X_CTRL3, DRV260X_NG_THRESH_2 },
+ { DRV260X_CTRL3, DRV260X_NG_THRESH_2 | DRV260X_RTP_UNSIGNED_DATA },
{ DRV260X_FEEDBACK_CTRL, DRV260X_FB_REG_LRA_MODE |
DRV260X_BRAKE_FACTOR_4X | DRV260X_LOOP_GAIN_HIGH },
};
@@ -284,7 +285,7 @@ static const struct reg_sequence drv260x_lra_init_regs[] = {
DRV260X_BEMF_GAIN_3 },
{ DRV260X_CTRL1, DRV260X_STARTUP_BOOST },
{ DRV260X_CTRL2, DRV260X_SAMP_TIME_250 },
- { DRV260X_CTRL3, DRV260X_NG_THRESH_2 | DRV260X_ANALOG_IN },
+ { DRV260X_CTRL3, DRV260X_NG_THRESH_2 | DRV260X_RTP_UNSIGNED_DATA | DRV260X_ANALOG_IN },
{ DRV260X_CTRL4, DRV260X_AUTOCAL_TIME_500MS },
};
@@ -299,7 +300,7 @@ static const struct reg_sequence drv260x_erm_cal_regs[] = {
{ DRV260X_CTRL1, DRV260X_STARTUP_BOOST },
{ DRV260X_CTRL2, DRV260X_SAMP_TIME_250 | DRV260X_BLANK_TIME_75 |
DRV260X_IDISS_TIME_75 },
- { DRV260X_CTRL3, DRV260X_NG_THRESH_2 | DRV260X_ERM_OPEN_LOOP },
+ { DRV260X_CTRL3, DRV260X_NG_THRESH_2 | DRV260X_RTP_UNSIGNED_DATA },
{ DRV260X_CTRL4, DRV260X_AUTOCAL_TIME_500MS },
};
--
2.40.1
^ permalink raw reply related
* [PATCH 2/5] Input: drv260x - sleep between polling GO bit
From: Luca Weiss @ 2023-04-30 18:20 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Dan Murphy, Andy Gross, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Raffaele Tranquillini,
Yassine Oudjana
Cc: linux-input, linux-kernel, linux-arm-msm, devicetree, Luca Weiss
In-Reply-To: <20230430-drv260x-improvements-v1-0-1fb28b4cc698@z3ntu.xyz>
When doing the initial startup there's no need to poll without any
delay and spam the I2C bus.
Let's sleep 15ms between each attempt, which is the same time as used
in the vendor driver.
Fixes: 7132fe4f5687 ("Input: drv260x - add TI drv260x haptics driver")
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
drivers/input/misc/drv260x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index e95c4e775b5d..884d43eb4b61 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -435,6 +435,7 @@ static int drv260x_init(struct drv260x_data *haptics)
}
do {
+ usleep_range(15000, 15500);
error = regmap_read(haptics->regmap, DRV260X_GO, &cal_buf);
if (error) {
dev_err(&haptics->client->dev,
--
2.40.1
^ permalink raw reply related
* [PATCH 4/4] ARM: omap1: Fix up the Nokia 770 board device IRQs
From: Linus Walleij @ 2023-04-30 9:22 UTC (permalink / raw)
To: Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Thomas Bogendoerfer,
Dmitry Torokhov, Mark Brown, Bartosz Golaszewski, Andreas Kemnade,
Helge Deller, Ulf Hansson
Cc: linux-omap, linux-arm-kernel, linux-kernel, linux-mips,
linux-input, linux-spi, linux-fbdev, dri-devel, linux-mmc,
Linus Walleij
In-Reply-To: <20230430-nokia770-regression-v1-0-97704e36b094@linaro.org>
The platform devices on the Nokia 770 is using some
board-specific IRQs that get statically assigned to platform
devices in the boardfile.
This does not work with dynamic IRQ chip bases.
Utilize the NULL device to define some board-specific
GPIO lookups and use these to immediately look up the
same GPIOs, convert to IRQ numbers and pass as resources
to the devices. This is ugly but should work.
Fixes: 92bf78b33b0b ("gpio: omap: use dynamic allocation of base")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-omap1/board-nokia770.c | 58 +++++++++++++++++++++++++++---------
1 file changed, 44 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
index 53a4a44d5f4a..18a63c5a3dee 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -6,8 +6,8 @@
*/
#include <linux/clkdev.h>
#include <linux/irq.h>
-#include <linux/gpio.h>
#include <linux/gpio/machine.h>
+#include <linux/gpio/consumer.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/mutex.h>
@@ -227,21 +227,28 @@ static struct i2c_board_info nokia770_i2c_board_info_2[] __initdata = {
static void __init nokia770_cbus_init(void)
{
- const int retu_irq_gpio = 62;
- const int tahvo_irq_gpio = 40;
-
- if (gpio_request_one(retu_irq_gpio, GPIOF_IN, "Retu IRQ"))
- return;
- if (gpio_request_one(tahvo_irq_gpio, GPIOF_IN, "Tahvo IRQ")) {
- gpio_free(retu_irq_gpio);
- return;
+ struct gpio_desc *d;
+ int irq;
+
+ d = gpiod_get(NULL, "retu_irq", GPIOD_IN);
+ if (IS_ERR(d)) {
+ pr_err("Unable to get CBUS Retu IRQ GPIO descriptor\n");
+ } else {
+ irq = gpiod_to_irq(d);
+ irq_set_irq_type(irq, IRQ_TYPE_EDGE_RISING);
+ nokia770_i2c_board_info_2[0].irq = irq;
+ }
+ d = gpiod_get(NULL, "tahvo_irq", GPIOD_IN);
+ if (IS_ERR(d)) {
+ pr_err("Unable to get CBUS Tahvo IRQ GPIO descriptor\n");
+ } else {
+ irq = gpiod_to_irq(d);
+ irq_set_irq_type(irq, IRQ_TYPE_EDGE_RISING);
+ nokia770_i2c_board_info_2[1].irq = irq;
}
- irq_set_irq_type(gpio_to_irq(retu_irq_gpio), IRQ_TYPE_EDGE_RISING);
- irq_set_irq_type(gpio_to_irq(tahvo_irq_gpio), IRQ_TYPE_EDGE_RISING);
- nokia770_i2c_board_info_2[0].irq = gpio_to_irq(retu_irq_gpio);
- nokia770_i2c_board_info_2[1].irq = gpio_to_irq(tahvo_irq_gpio);
i2c_register_board_info(2, nokia770_i2c_board_info_2,
ARRAY_SIZE(nokia770_i2c_board_info_2));
+
gpiod_add_lookup_table(&nokia770_cbus_gpio_table);
platform_device_register(&nokia770_cbus_device);
}
@@ -251,8 +258,25 @@ static void __init nokia770_cbus_init(void)
}
#endif /* CONFIG_I2C_CBUS_GPIO */
+static struct gpiod_lookup_table nokia770_irq_gpio_table = {
+ .dev_id = NULL,
+ .table = {
+ /* GPIO used by SPI device 1 */
+ GPIO_LOOKUP("gpio-0-15", 15, "ads7846_irq",
+ GPIO_ACTIVE_HIGH),
+ /* GPIO used for retu IRQ */
+ GPIO_LOOKUP("gpio-48-63", 15, "retu_irq",
+ GPIO_ACTIVE_HIGH),
+ /* GPIO used for tahvo IRQ */
+ GPIO_LOOKUP("gpio-32-47", 8, "tahvo_irq",
+ GPIO_ACTIVE_HIGH),
+ },
+};
+
static void __init omap_nokia770_init(void)
{
+ struct gpio_desc *d;
+
/* On Nokia 770, the SleepX signal is masked with an
* MPUIO line by default. It has to be unmasked for it
* to become functional */
@@ -262,9 +286,15 @@ static void __init omap_nokia770_init(void)
/* Unmask SleepX signal */
omap_writew((omap_readw(0xfffb5004) & ~2), 0xfffb5004);
+ gpiod_add_lookup_table(&nokia770_irq_gpio_table);
platform_add_devices(nokia770_devices, ARRAY_SIZE(nokia770_devices));
gpiod_add_lookup_table(&nokia770_ads7846_gpio_table);
- nokia770_spi_board_info[1].irq = gpio_to_irq(15);
+
+ d = gpiod_get(NULL, "ads7846_irq", GPIOD_IN);
+ if (IS_ERR(d))
+ pr_err("Unable to get ADS7846 IRQ GPIO descriptor\n");
+ else
+ nokia770_spi_board_info[1].irq = gpiod_to_irq(d);
spi_register_board_info(nokia770_spi_board_info,
ARRAY_SIZE(nokia770_spi_board_info));
omap_serial_init();
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox