* Re: [PATCH 3/4] Input: pwm-vibra - add support for enable GPIO
From: Luca Weiss @ 2023-04-28 16:06 UTC (permalink / raw)
To: Brian Masney
Cc: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Sebastian Reichel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Brian Masney, linux-input,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <ZEsFV6F4CEh2/av8@x1>
On Freitag, 28. April 2023 01:29:27 CEST Brian Masney wrote:
> On Thu, Apr 27, 2023 at 10:34:28PM +0200, Luca Weiss wrote:
> > Some pwm vibrators have a dedicated enable GPIO that needs to be set
> > high so that the vibrator works. Add support for that optionally.
> >
> > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
>
> Hi Luca,
>
> Thank you for picking up this work!
>
> > + vibrator->enable_gpio = devm_gpiod_get_optional(&pdev->dev,
"enable",
> > +
GPIOD_OUT_LOW);
> > + err = PTR_ERR_OR_ZERO(vibrator->enable_gpio);
> > + if (err) {
> > + if (err != -EPROBE_DEFER)
> > + dev_err(&pdev->dev, "Failed to request enable
gpio: %d\n",
> > + err);
> > + return err;
> > + }
> > +
>
> Take a look at dev_err_probe() to remove the -EPROBE_DEFER check.
The input subsystem doesn't like dev_err_probe for some reason, you should
quickly find examples of that being rejected on the mailing list (or see
"git grep dev_err_probe drivers/input/")
>
> With that fixed:
>
> Reviewed-by: Brian Masney <bmasney@redhat.com>
Thanks for the reviews!
^ permalink raw reply
* Re: [PATCH v3 13/38] Input: add HAS_IOPORT dependencies
From: Niklas Schnelle @ 2023-04-28 14:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Dmitry Torokhov, Greg Kroah-Hartman, Bjorn Helgaas,
Uwe Kleine-König, Mauro Carvalho Chehab, Alan Stern,
Rafael J. Wysocki, Paul Walmsley, Palmer Dabbelt, Albert Ou,
linux-kernel, linux-arch, linux-pci, Arnd Bergmann, linux-input
In-Reply-To: <CAMuHMdUbaFhb3HURhSfrkDyq_cz6z=S3TtTr0-5f6svho9MftQ@mail.gmail.com>
On Wed, 2023-03-15 at 09:22 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Tue, Mar 14, 2023 at 1:12 PM Niklas Schnelle <schnelle@linux.ibm.com> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. We thus need to add HAS_IOPORT as dependency for
> > those drivers using them.
> >
> > Co-developed-by: Arnd Bergmann <arnd@kernel.org>
> > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
>
> Thanks for your patch!
>
> > --- a/drivers/input/serio/Kconfig
> > +++ b/drivers/input/serio/Kconfig
> > @@ -75,6 +75,7 @@ config SERIO_Q40KBD
> > config SERIO_PARKBD
> > tristate "Parallel port keyboard adapter"
> > depends on PARPORT
> > + depends on HAS_IOPORT
> > help
> > Say Y here if you built a simple parallel port adapter to attach
> > an additional AT keyboard, XT keyboard or PS/2 mouse.
>
> This driver seems to use only the parport and serio APIs, so it might
> work on systems without HAS_IOPORT. Dunno for sure.
>
> Gr{oetje,eeting}s,
>
> Geert
>
Thanks, yes you're right this driver compiles fine without inb()/outb()
etc. I removed the dependency, not sure if it used to have a dependency
or this was a mixup but it's corrected for v4.
Thanks,
Niklas
^ permalink raw reply
* Re: [RFC PATCH 3/3] Revert "input: gpio-keys - use device_pm_move_to_tail"
From: Rafael J. Wysocki @ 2023-04-28 11:40 UTC (permalink / raw)
To: Greg Kroah-Hartman, Doug Berger
Cc: 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,
Saravana Kannan, Florian Fainelli, linux-kernel, linux-input
In-Reply-To: <ZEtP3uRX5Ib1W_Kd@kroah.com>
On Fri, Apr 28, 2023 at 6:47 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Thu, Apr 27, 2023 at 03:16:25PM -0700, Doug Berger wrote:
> > This reverts commit 2569873096f7eb1acf63624e9772d82b23923bf4.
>
> You have to give a reason why you are reverting it please...
Also, the commit ID above doesn't match any commits in the mainline.
^ permalink raw reply
* [PATCH v4] Fix freeze in lm8333 i2c keyboard driver
From: Tomas Mudrunka @ 2023-04-28 10:20 UTC (permalink / raw)
To: jeff; +Cc: dmitry.torokhov, linux-input, linux-kernel, tomas.mudrunka
In-Reply-To: <ZEnErxfnSn2JOpvm@nixie71>
LM8333 uses gpio interrupt line which is triggered by falling edge.
When button is pressed before driver is loaded,
driver will miss the edge and never respond again.
To fix this we run the interrupt handler after registering IRQ
to clear the interrupt via i2c command.
Signed-off-by: Tomas Mudrunka <tomas.mudrunka@gmail.com>
---
drivers/input/keyboard/lm8333.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/keyboard/lm8333.c b/drivers/input/keyboard/lm8333.c
index 7457c3220..9a810ca00 100644
--- a/drivers/input/keyboard/lm8333.c
+++ b/drivers/input/keyboard/lm8333.c
@@ -184,6 +184,8 @@ static int lm8333_probe(struct i2c_client *client)
if (err)
goto free_mem;
+ lm8333_irq_thread(client->irq, lm8333);
+
err = input_register_device(input);
if (err)
goto free_irq;
--
2.40.0
^ permalink raw reply related
* Re: [PATCH 4/4] ARM: dts: qcom: msm8974-hammerhead: Add vibrator
From: Caleb Connolly @ 2023-04-28 10:11 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-4-e87eeb94da51@z3ntu.xyz>
On 27/04/2023 21:34, Luca Weiss wrote:
> The Nexus 5 has a vibrator connected to the clock output of GP1_CLK
> which we can use with the clk-pwm driver, then we can use that pwm with
> pwm-vibrator to get haptics functionality.
>
> This patch is based on Brian Masney's previous patch with clk-vibrator.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
> ---
> .../dts/qcom-msm8974-lge-nexus5-hammerhead.dts | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> index ab35f2d644c0..fea8a6be9021 100644
> --- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> +++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> @@ -41,6 +41,25 @@ key-volume-down {
> };
> };
>
> + clk_pwm: pwm {
> + compatible = "clk-pwm";
> + clocks = <&mmcc CAMSS_GP1_CLK>;
> +
> + pinctrl-0 = <&vibrator_pin>;
> + pinctrl-names = "default";
> +
> + #pwm-cells = <2>;
> + };
> +
> + vibrator {
> + compatible = "pwm-vibrator";
> + pwms = <&clk_pwm 0 100000>;
> + pwm-names = "enable";
> +
> + vcc-supply = <&pm8941_l19>;
> + enable-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> + };
> +
> vreg_wlan: wlan-regulator {
> compatible = "regulator-fixed";
>
> @@ -637,6 +656,22 @@ shutdown-pins {
> function = "gpio";
> };
> };
> +
> + vibrator_pin: vibrator-state {
> + core-pins {
> + pins = "gpio27";
> + function = "gp1_clk";
> + drive-strength = <6>;
> + bias-disable;
> + };
> +
> + enable-pins {
> + pins = "gpio60";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> + };
> };
>
> &usb {
>
^ permalink raw reply
* Re: [PATCH 3/4] Input: pwm-vibra - add support for enable GPIO
From: Caleb Connolly @ 2023-04-28 10:11 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-3-e87eeb94da51@z3ntu.xyz>
On 27/04/2023 21:34, Luca Weiss wrote:
> Some pwm vibrators have a dedicated enable GPIO that needs to be set
> high so that the vibrator works. Add support for that optionally.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
> ---
> drivers/input/misc/pwm-vibra.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
> index c08971c97ad6..2ba035299db8 100644
> --- a/drivers/input/misc/pwm-vibra.c
> +++ b/drivers/input/misc/pwm-vibra.c
> @@ -11,6 +11,7 @@
> * Copyright (C) 2010, Lars-Peter Clausen <lars@metafoo.de>
> */
>
> +#include <linux/gpio/consumer.h>
> #include <linux/input.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> @@ -23,6 +24,7 @@
>
> struct pwm_vibrator {
> struct input_dev *input;
> + struct gpio_desc *enable_gpio;
> struct pwm_device *pwm;
> struct pwm_device *pwm_dir;
> struct regulator *vcc;
> @@ -48,6 +50,8 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
> vibrator->vcc_on = true;
> }
>
> + gpiod_set_value_cansleep(vibrator->enable_gpio, 1);
> +
> pwm_get_state(vibrator->pwm, &state);
> pwm_set_relative_duty_cycle(&state, vibrator->level, 0xffff);
> state.enabled = true;
> @@ -80,6 +84,8 @@ static void pwm_vibrator_stop(struct pwm_vibrator *vibrator)
> pwm_disable(vibrator->pwm_dir);
> pwm_disable(vibrator->pwm);
>
> + gpiod_set_value_cansleep(vibrator->enable_gpio, 0);
> +
> if (vibrator->vcc_on) {
> regulator_disable(vibrator->vcc);
> vibrator->vcc_on = false;
> @@ -142,6 +148,16 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
> return err;
> }
>
> + vibrator->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
> + GPIOD_OUT_LOW);
> + err = PTR_ERR_OR_ZERO(vibrator->enable_gpio);
> + if (err) {
> + if (err != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to request enable gpio: %d\n",
> + err);
> + return err;
> + }
> +
> vibrator->pwm = devm_pwm_get(&pdev->dev, "enable");
> err = PTR_ERR_OR_ZERO(vibrator->pwm);
> if (err) {
>
^ permalink raw reply
* Re: [PATCH 2/4] Input: pwm-vibra - add newline to dev_err prints
From: Caleb Connolly @ 2023-04-28 10:10 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-2-e87eeb94da51@z3ntu.xyz>
On 27/04/2023 21:34, Luca Weiss wrote:
> Make sure all printed messages end with a newline.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
> ---
> drivers/input/misc/pwm-vibra.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
> index d0e58a7cdfa3..c08971c97ad6 100644
> --- a/drivers/input/misc/pwm-vibra.c
> +++ b/drivers/input/misc/pwm-vibra.c
> @@ -42,7 +42,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
> if (!vibrator->vcc_on) {
> err = regulator_enable(vibrator->vcc);
> if (err) {
> - dev_err(pdev, "failed to enable regulator: %d", err);
> + dev_err(pdev, "failed to enable regulator: %d\n", err);
> return err;
> }
> vibrator->vcc_on = true;
> @@ -54,7 +54,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
>
> err = pwm_apply_state(vibrator->pwm, &state);
> if (err) {
> - dev_err(pdev, "failed to apply pwm state: %d", err);
> + dev_err(pdev, "failed to apply pwm state: %d\n", err);
> return err;
> }
>
> @@ -65,7 +65,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
>
> err = pwm_apply_state(vibrator->pwm_dir, &state);
> if (err) {
> - dev_err(pdev, "failed to apply dir-pwm state: %d", err);
> + dev_err(pdev, "failed to apply dir-pwm state: %d\n", err);
> pwm_disable(vibrator->pwm);
> return err;
> }
> @@ -137,7 +137,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
> err = PTR_ERR_OR_ZERO(vibrator->vcc);
> if (err) {
> if (err != -EPROBE_DEFER)
> - dev_err(&pdev->dev, "Failed to request regulator: %d",
> + dev_err(&pdev->dev, "Failed to request regulator: %d\n",
> err);
> return err;
> }
> @@ -146,7 +146,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
> err = PTR_ERR_OR_ZERO(vibrator->pwm);
> if (err) {
> if (err != -EPROBE_DEFER)
> - dev_err(&pdev->dev, "Failed to request main pwm: %d",
> + dev_err(&pdev->dev, "Failed to request main pwm: %d\n",
> err);
> return err;
> }
> @@ -158,7 +158,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
> state.enabled = false;
> err = pwm_apply_state(vibrator->pwm, &state);
> if (err) {
> - dev_err(&pdev->dev, "failed to apply initial PWM state: %d",
> + dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
> err);
> return err;
> }
> @@ -172,7 +172,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
> state.enabled = false;
> err = pwm_apply_state(vibrator->pwm_dir, &state);
> if (err) {
> - dev_err(&pdev->dev, "failed to apply initial PWM state: %d",
> + dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
> err);
> return err;
> }
> @@ -189,7 +189,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
> break;
>
> default:
> - dev_err(&pdev->dev, "Failed to request direction pwm: %d", err);
> + dev_err(&pdev->dev, "Failed to request direction pwm: %d\n", err);
> fallthrough;
>
> case -EPROBE_DEFER:
> @@ -207,13 +207,13 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
> err = input_ff_create_memless(vibrator->input, NULL,
> pwm_vibrator_play_effect);
> if (err) {
> - dev_err(&pdev->dev, "Couldn't create FF dev: %d", err);
> + dev_err(&pdev->dev, "Couldn't create FF dev: %d\n", err);
> return err;
> }
>
> err = input_register_device(vibrator->input);
> if (err) {
> - dev_err(&pdev->dev, "Couldn't register input dev: %d", err);
> + dev_err(&pdev->dev, "Couldn't register input dev: %d\n", err);
> return err;
> }
>
>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: input: pwm-vibrator: Add enable-gpio
From: Caleb Connolly @ 2023-04-28 10:10 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 21: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>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
> ---
> Documentation/devicetree/bindings/input/pwm-vibrator.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.yaml b/Documentation/devicetree/bindings/input/pwm-vibrator.yaml
> index d32716c604fe..6398534b43c3 100644
> --- a/Documentation/devicetree/bindings/input/pwm-vibrator.yaml
> +++ b/Documentation/devicetree/bindings/input/pwm-vibrator.yaml
> @@ -32,6 +32,8 @@ properties:
> minItems: 1
> maxItems: 2
>
> + enable-gpios: true
> +
> vcc-supply: true
>
> direction-duty-cycle-ns:
>
^ permalink raw reply
* [PATCH v3] Fix freeze in lm8333 i2c keyboard driver
From: Tomas Mudrunka @ 2023-04-28 10:09 UTC (permalink / raw)
To: jeff; +Cc: dmitry.torokhov, linux-input, linux-kernel, tomas.mudrunka
In-Reply-To: <ZEnErxfnSn2JOpvm@nixie71>
LM8333 uses gpio interrupt line which is triggered by falling edge.
When button is pressed before driver is loaded,
driver will miss the edge and never respond again.
To fix this we run the interrupt handler after registering IRQ
to clear the interrupt via i2c command.
Signed-off-by: Tomas Mudrunka <tomas.mudrunka@gmail.com>
---
drivers/input/keyboard/lm8333.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/keyboard/lm8333.c b/drivers/input/keyboard/lm8333.c
index 7457c3220..9a810ca00 100644
--- a/drivers/input/keyboard/lm8333.c
+++ b/drivers/input/keyboard/lm8333.c
@@ -184,6 +184,8 @@ static int lm8333_probe(struct i2c_client *client)
if (err)
goto free_mem;
+ lm8333_irq_thread(client->irq, (void *) lm8333);
+
err = input_register_device(input);
if (err)
goto free_irq;
--
2.40.0
^ permalink raw reply related
* Re: [RFC v1 0/4] Input: support virtual objects on touchscreens
From: Javier Carrasco @ 2023-04-28 6:08 UTC (permalink / raw)
To: Jeff LaBundy
Cc: Thomas Weißschuh, linux-input, devicetree, linux-kernel,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Henrik Rydberg,
Ulf Hansson, Hans Verkuil, Stephen Boyd, Sebastian Reichel,
Linus Walleij, Jonathan Cameron, Uwe Kleine-g, Bastian Hecht,
Michael Riesch
In-Reply-To: <ZEqvgnhzm7r4O7hz@nixie71>
Hi Jeff,
On 27.04.23 19:23, Jeff LaBundy wrote:
> Hi Javier,
>
> On Thu, Apr 27, 2023 at 05:59:42PM +0200, Javier Carrasco wrote:
>> Hi,
>>
>> On 25.04.23 18:02, Jeff LaBundy wrote:
>>> Hi Thomas,
>>>
>>> On Tue, Apr 25, 2023 at 05:29:39PM +0200, Thomas Weißschuh wrote:
>>>> Hi Javier,
>>>>
>>>> On 2023-04-25 13:50:45+0200, Javier Carrasco 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.
>>>>>
>>>>> In order to generate proper key events by overlay buttons and adjust the
>>>>> touch events to a clipped surface, these patches offer a documented,
>>>>> device-tree-based solution by means of helper functions.
>>>>> An implementation for a specific touchscreen driver is also included.
>>>>>
>>>>> The functions in ts-virtobj provide a simple workflow to acquire
>>>>> physical objects from the device tree, map them into the device driver
>>>>> structures as virtual objects and generate events according to
>>>>> the object descriptions.
>>>>>
>>>>> This solution has been tested with a JT240MHQS-E3 display, which uses
>>>>> the st1624 as a touchscreen and provides two overly buttons and a frame
>>>>> that clips its effective surface.
>>>>
>>>> There are quite a few of notebooks from Asus that feature a printed
>>>> numpad on their touchpad [0]. The mapping from the touch events to the
>>>> numpad events needs to happen in software.
>>>
>>> That example seems a kind of fringe use-case in my opinion; I think the
>>> gap filled by this RFC is the case where a touchscreen has a printed
>>> overlay with a key that represents a fixed function.
>>
>> Exactly, this RFC addresses exactly such printed overlays.
>>>
>>> One problem I do see here is something like libinput or multitouch taking
>>> hold of the input device, and swallowing the key presses because it sees
>>> the device as a touchscreen and is not interested in these keys.
>>
>> Unfortunately I do not know libinput or multitouch and I might be
>> getting you wrong, but I guess the same would apply to any event
>> consumer that takes touchscreens as touch event producers and nothing else.
>>
>> Should they not check the supported events from the device instead of
>> making such assumptions? This RFC adds key events defined in the device
>> tree and they are therefore available and published as device
>> capabilities. That is for example what evtest does to report the
>> supported events and they are then notified accordingly. Is that not the
>> right way to do it?
>
> evtest is just that, a test tool. It's handy for ensuring the device emits
> the appropriate input events in response to hardware inputs, but it is not
> necessarily representative of how the input device may be used in practice.
You are right. I might have been biased by my use case though, where a
touchscreen with key capabilities is is exactly that and there is no
reason to ignore any event if the capabilities are available.
Well, props to evtest for being representative of at least that
practical use.
>
> I would encourage you to test this solution with a simple use-case such as
> Raspbian, and the virtual keys mapped to easily recognizable functions like
> volume up/down.
>
> Here, you will find that libinput will grab the device and declare it to be
> a touchscreen based on the input events it advertises. However, you will not
> see volume up/down keys are handled.
>
> If you break out the virtual keypad as a separate input device, however, you
> will see libinput additionally recognize it as a keyboard and volume up/down
> keys will be handled. It is for this reason that a handful of drivers with
> this kind of mixed functionality (e.g. ad714x) already branch out multiple
> input devices for each function.
>
> As a matter of principle, I find it to be most flexible for logically separate
> functions to be represented as logically separate input devices, even if those
> input devices all stem from the same piece of hardware. Not only does it allow
> you to attach different handlers to each device (i.e. file descriptor), but it
> also allows user space to inhibit one device but not the other, etc.
I had complex devices in mind where many capabilities are provided (like
a mouse with several buttons, wheels, and who knows what else or a bunch
of other complex pieces of hardware) but are still registered as a
single input device. That makes the whole functionality accessible
within a single object that translates 1:1 to the actual hardware, but
on the other hand it lacks of the flexibility you mention.
Nevertheless, in the end this RFC applies to touchscreens and if the
existing tools do not expect them to have key events, they must be
advertised in a different way. And ss I want any tool to identify the
touchscreen and the keys properly, I will go for the multi-device solution.
> Maybe the right approach, which your RFC already seems to support, is to simply
> let the driver decide whether to pass the touchscreen input_dev or a different
> input_dev. The driver would be responsible for allocating and registering the
> keypad; your functions simply set the capabilities for, and report events from,Y
> whichever input_dev is passed to them. This is something to consider for your
> st1232 example.
I would let the drivers register the devices that fit better in each
case according to the objects defined in the device tree and the
hardware configuration. Of course I could include the device
registration too, but that would probably reduce flexibility with no
real gain.
This RFC will not work out of the box with several input devices from a
single driver because it sets the key capabilities right away as it
always supposes there is only one input device. But splitting that part
is rather trivial and the rest does not need to change much as it works
with generic input devices.
The st1232 example will need some bigger changes though, so that part
will change a bit in the next version.
>
>>
>> Thanks a lot for your feedback!
>>>
>>> Therefore, my first impression is that the virtual keypad may be better
>>> served by registering its own input device.
>>>
>>> Great work by the way, Javier!
>>>
>>>>
>>>> Do you think your solution is general enough to also support this
>>>> usecase?
>>>>
>>>> The differences I see are
>>>> * not device-tree based
>>>> * touchpads instead of touchscreens
>>>>
>>>>> [..]
>>>>
>>>> [0] https://unix.stackexchange.com/q/494400
>>>
>>> Kind regards,
>>> Jeff LaBundy
>
> Kind regards,
> Jeff LaBundy
Thanks again for your feedback, I will keep your comments in mind for
the next version.
Best regards,
Javier Carrasco
^ permalink raw reply
* Re: [RFC PATCH 3/3] Revert "input: gpio-keys - use device_pm_move_to_tail"
From: Greg Kroah-Hartman @ 2023-04-28 4:47 UTC (permalink / raw)
To: Doug Berger
Cc: 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,
Saravana Kannan, Florian Fainelli, linux-kernel, linux-input
In-Reply-To: <20230427221625.116050-4-opendmb@gmail.com>
On Thu, Apr 27, 2023 at 03:16:25PM -0700, Doug Berger wrote:
> This reverts commit 2569873096f7eb1acf63624e9772d82b23923bf4.
You have to give a reason why you are reverting it please...
thanks,
greg k-h
^ permalink raw reply
* Re: Re: [PATCH] Input: vmmouse - add macros to enable vmmouse relative mode
From: Zack Rusin @ 2023-04-28 3:35 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com, Pv-drivers, zhouzongmin@kylinos.cn,
Linux-graphics-maintainer
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <9d739de8fec7683c3a71bc1be3229818325ade0b.camel@kylinos.cn>
On Fri, 2023-04-28 at 10:34 +0800, zongmin zhou wrote:
> On Thu, 2023-04-20 at 09:49 +0800, 周宗敏 wrote:
> > > Dear zack:
> > >
> > > As far as I know, I think in the current design for vmmouse device,
> > > the mouse mode can only choose one,can't request both two mode.
> > >
> > > The flowchart for vmmouse device between host and guest roughly as
> > > > follows：
> picture link:
> https://imgs.wiki/imgs/2023/04/28/1898b0428ecb366a.png
>
> > > QEMU VMMouse emulation code defined variables of 's->absolute'
> > > to identify the mouse mode requested by the guest driver.
> > > Based on the value of 's->absolute',qemu will add different >
> > > spice-input VD-Interface,
> > > spice-server will notify client to use the correct mouse mode,
> > > and then spice client will update mouse motion/position based on
> > > the > mouse mode.
> > >
> > > About the VMMOUSE_RELATIVE_PACKET events,I guess that designer may
> > > > want use it
> > > to distinguish relative from absolute of the process events.But >
> > > doesn't mark them as such
> > > on QEMU's vmmouse device code.In fact, the status corresponds to
> > > the > following buttons value on QEMU：
> link:
> https://imgs.wiki/imgs/2023/04/28/2c6a92c33e2537dd.png
> > >
> > > From the screenshot we can know it didn't mark the mouse mode
> > > status > on original design,
> > > only set the actual button state. So I think have to mark it here >
> > > according to the value of 's->absolute'.
> > >
> Dear zack:
>
> I guess the last mail sent to you may has been lost
> as I don't see it in lore.kernel.org.Just resending it.
Do you mean the one I replied to yesterday? My reply to it is here
https://lore.kernel.org/lkml/3a4f27ad2122fe0457dc2a41a3b1b24ac556d26c.camel@vmware.com/
(and surely somewhere in your inbox as well)
z
^ permalink raw reply
* Re: Re: [PATCH] Input: vmmouse - add macros to enable vmmouse relative mode
From: zongmin zhou @ 2023-04-28 2:34 UTC (permalink / raw)
To: Zack Rusin, dmitry.torokhov@gmail.com, Pv-drivers,
Linux-graphics-maintainer
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <rk3ip31xbz-rk4smwgz5s@nsmail7.0.0--kylin--1>
On Thu, 2023-04-20 at 09:49 +0800, 周宗敏 wrote:
> > Dear zack:
> >
> > As far as I know, I think in the current design for vmmouse device,
> > the mouse mode can only choose one,can't request both two mode.
> >
> > The flowchart for vmmouse device between host and guest roughly as
> > > follows：
picture link: https://imgs.wiki/imgs/2023/04/28/1898b0428ecb366a.png
> > QEMU VMMouse emulation code defined variables of 's->absolute'
> > to identify the mouse mode requested by the guest driver.
> > Based on the value of 's->absolute',qemu will add different >
> > spice-input VD-Interface,
> > spice-server will notify client to use the correct mouse mode,
> > and then spice client will update mouse motion/position based on
> > the > mouse mode.
> >
> > About the VMMOUSE_RELATIVE_PACKET events,I guess that designer may
> > > want use it
> > to distinguish relative from absolute of the process events.But >
> > doesn't mark them as such
> > on QEMU's vmmouse device code.In fact, the status corresponds to
> > the > following buttons value on QEMU：
link: https://imgs.wiki/imgs/2023/04/28/2c6a92c33e2537dd.png
> >
> > From the screenshot we can know it didn't mark the mouse mode
> > status > on original design,
> > only set the actual button state. So I think have to mark it here >
> > according to the value of 's->absolute'.
> >
Dear zack:
I guess the last mail sent to you may has been lost
as I don't see it in lore.kernel.org.Just resending it.
If you have any questions, please let me know.
Thanks.
> > Best Regards.
> >
> > ----
> >
> >
> >
> >
> > 主 题：Re: [PATCH] Input: vmmouse - add macros to enable vmmouse >
> > relative mode
> > 日 期：2023-04-14 23:32
> > 发件人：zackr@vmware.com
> > 收件人：dmitry.torokhov@gmail.com;Pv-
> > drivers;zhouzongmin@kylinos.cn;Linux> -graphics-maintainer;
> >
> > On Fri, 2023-04-14 at 16:58 +0800, zongmin zhou wrote:
> > > > On Fri, 2023-04-14 at 01:22 +0000, Zack Rusin wrote:
> > > > > > On Thu, 2023-04-13 at 16:56 +0800, Zongmin Zhou wrote:
> > > > > > > > Add macros to enable request relative mode.
> > > > > > > >
> > > > > > > > Change the REL_Y value passed by input_report_rel
> > > > > > > > function,
> > > > > > > > to match the direction of mouse movement.
> > > > > >
> > > > > > Thanks for the patch, but in its current form it's a nack.
> > > > > > First > > > of
> > > > > > all we don't
> > > > > > want any defines in the driver code that affect
> > > > > > compilation, it's
> > > > > > never going to be
> > > > > > tested or compiled in. Either a kconfig or a module
> > > > > > parameter > > > would
> > > > > > be acceptable
> > > > > > but that's only if you can actually explain what it is that
> > > > > > > > > you're
> > > > > > fixing. The
> > > > > > current single line description just mentions what the
> > > > > > effect it > > > has
> > > > > > (not completely
> > > > > > correctly either because for merged packets absolute will
> > > > > > still > > > be
> > > > > > x=x, y=y, but
> > > > > > relative will be x += dx, y -= dy) but not why it's done,
> > > > > > what > > > it's
> > > > > > fixing and how
> > > > > > to reproduce.
> > > > > >
> > > > > > z
> > > > > >
> > > > Dear zack:
> > > >
> > > > Firstly,thanks for your reply.
> > > >
> > > > The reason I want to add macros to request different vmmouse
> > > > modes(relative or absolute) is that the vmmouse drivers
> > > > currently > > only
> > > > supports request absolute mode.But in some case we want request
> > > > relative mode so that Pointer acceleration feature can be
> > > > used.(as > > I
> > > > know,libinput module only support Pointer acceleration feature
> > > > in
> > > > relative mode.)
> > > > So I think we can provide two vmmouse modes to facilitate the
> > > > use > > of
> > > > different needs.
> > > > If need,I can change it to a kconfig or a module parameter.
> > > >
> > > > The reasons of fix for REL_Y value，are as follows:
> > > > When I request relative vmmouse mode,and let mouse move up,the
> > > > > > mouse
> > > > pointer moved down instead.
> > > > Similarly, when I move the mouse down, the mouse pointer moved
> > > > up.
> > > > it obviously with a wrong motion direction in y.
> > > >
> > > > Actually，I understand that the value of y here is the end > >
> > > > calculation
> > > > result of relative coordinate movement，the real calculation is
> > > > in
> > > > motion_event() of spice-gtk and legacy_mouse_event() of qemu.
> > > >
> > > > Test scenario:
> > > > 1) start virtual machine with qemu command "vmport=on"，also
> > > > with > > spice
> > > > protocal.
> > > > 2) modify guest vmmouse drivers to request relative mode.
> > > > 3) move the mouse,will observe the pointer freezed,it's because
> > > > > > driver
> > > > not match the condition 'status &
> > > > VMMOUSE_RELATIVE_PACKET',can't > > find
> > > > correct input device.need merge this patch in qemu:
> > > > https://lore.kernel.org/all/20230413081526.2229916-1-zhouzongmin@kylinos.cn/
> > > > 4) after merge the patch in qemu,we can observe the issue of
> > > > wrong
> > > > motion direction in y.
> >
> > Sounds like you have a bug in the monitor code to me. The mouse
> > might > request
> > relative mode, but that doesn't mean that it's going to be
> > switched, > it's a hint. On
> > enable we definitely want to request the default absolute mode.
> >
> > Ultimately it's the delivery mechanism (i.e. whether the delivered
> > > event is
> > VMMOUSE_RELATIVE_PACKET or not) that defines what an event is. This
> > > sounds to me
> > like the monitor delivers VMMOUSE_RELATIVE_PACKET events but
> > doesn't > mark them as
> > such. You can confirm by putting some debugging output in the >
> > vmmouse_report_events.
> >
> > z
> >
^ permalink raw reply
* RE: [PATCH] Input: elan_i2c - Implement inhibit/uninhibit functions.
From: Jingle.Wu @ 2023-04-28 2:21 UTC (permalink / raw)
To: 'Dmitry Torokhov'
Cc: linux-kernel, linux-input, phoenix, josh.chen, dave.wang
In-Reply-To: <ZEmsc0HyZuXlJARq@google.com>
Hi Dmitry:
During the initial process and when the users open/close device,
having the elan uninhibit/inhibit commands (low power mode) was not what
Elan expects to happen. Due to that touchpad would do the calibration in
uninhibit moment , we don't want the calibration to be affected by fingers
on the touchpad.
However, the LID inhibit/uninhibit functions in the Linux kernel
driver calls open/close(), so we need to separate the inhibit/uninhibit
behavior from open/close() function
https://elixir.bootlin.com/linux/latest/source/drivers/input/input.c#L1783
https://elixir.bootlin.com/linux/latest/source/drivers/input/input.c#L1813
THANKS
JINGLE
-----Original Message-----
From: 'Dmitry Torokhov' [mailto:dmitry.torokhov@gmail.com]
Sent: Thursday, April 27, 2023 6:58 AM
To: Jingle.Wu <jingle.wu@emc.com.tw>
Cc: linux-kernel@vger.kernel.org; linux-input@vger.kernel.org;
phoenix@emc.com.tw; josh.chen@emc.com.tw; dave.wang@emc.com.tw
Subject: Re: [PATCH] Input: elan_i2c - Implement inhibit/uninhibit
functions.
Hi Jingle,
On Mon, Apr 10, 2023 at 09:26:04AM +0800, Jingle.Wu wrote:
> HI Dmitry:
>
> > +static void elan_close(struct input_dev *input_dev) {
> > + if ((input_dev->users) && (!input_dev->inhibited))
> > + elan_inhibit(input_dev);
>
> This check is for "only inhibit request", and elan_open() its check is
> for "only uninhibit request".
> Because input_dev-> open() close() will be executed 2-3 times when
initial.
I do not see why this would be an issue if what you are doing is putting the
device into a low power mode.
If this issue is about need to re-calibrate after opening the lid on certain
devices, then I think we need to do the same that we did for the I2C-HID
connected devices on Redrix and hook this functionality to a LID handler.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: qcom: msm8974-hammerhead: Add vibrator
From: Brian Masney @ 2023-04-27 23:34 UTC (permalink / raw)
To: Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Sebastian Reichel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Brian Masney, linux-input,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20230427-hammerhead-vibra-v1-4-e87eeb94da51@z3ntu.xyz>
On Thu, Apr 27, 2023 at 10:34:29PM +0200, Luca Weiss wrote:
> The Nexus 5 has a vibrator connected to the clock output of GP1_CLK
> which we can use with the clk-pwm driver, then we can use that pwm with
> pwm-vibrator to get haptics functionality.
>
> This patch is based on Brian Masney's previous patch with clk-vibrator.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH 2/4] Input: pwm-vibra - add newline to dev_err prints
From: Brian Masney @ 2023-04-27 23:30 UTC (permalink / raw)
To: Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Sebastian Reichel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Brian Masney, linux-input,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20230427-hammerhead-vibra-v1-2-e87eeb94da51@z3ntu.xyz>
On Thu, Apr 27, 2023 at 10:34:27PM +0200, Luca Weiss wrote:
> Make sure all printed messages end with a newline.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: input: pwm-vibrator: Add enable-gpio
From: Brian Masney @ 2023-04-27 23:29 UTC (permalink / raw)
To: Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Sebastian Reichel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Brian Masney, linux-input,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20230427-hammerhead-vibra-v1-1-e87eeb94da51@z3ntu.xyz>
On Thu, Apr 27, 2023 at 10:34:26PM +0200, 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>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH 3/4] Input: pwm-vibra - add support for enable GPIO
From: Brian Masney @ 2023-04-27 23:29 UTC (permalink / raw)
To: Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Sebastian Reichel, Andy Gross,
Bjorn Andersson, Konrad Dybcio, Brian Masney, linux-input,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20230427-hammerhead-vibra-v1-3-e87eeb94da51@z3ntu.xyz>
On Thu, Apr 27, 2023 at 10:34:28PM +0200, Luca Weiss wrote:
> Some pwm vibrators have a dedicated enable GPIO that needs to be set
> high so that the vibrator works. Add support for that optionally.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Hi Luca,
Thank you for picking up this work!
> + vibrator->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
> + GPIOD_OUT_LOW);
> + err = PTR_ERR_OR_ZERO(vibrator->enable_gpio);
> + if (err) {
> + if (err != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to request enable gpio: %d\n",
> + err);
> + return err;
> + }
> +
Take a look at dev_err_probe() to remove the -EPROBE_DEFER check.
With that fixed:
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* [RFC PATCH 3/3] Revert "input: gpio-keys - use device_pm_move_to_tail"
From: Doug Berger @ 2023-04-27 22:16 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Dmitry Torokhov
Cc: Lad Prabhakar, Gergo Koteles, Jonathan Cameron, Andy Shevchenko,
Dan Williams, Hans de Goede, Thomas Gleixner, Kees Cook,
Kishon Vijay Abraham I, Saravana Kannan, Florian Fainelli,
linux-kernel, linux-input, Doug Berger
In-Reply-To: <20230427221625.116050-1-opendmb@gmail.com>
This reverts commit 2569873096f7eb1acf63624e9772d82b23923bf4.
Signed-off-by: Doug Berger <opendmb@gmail.com>
---
drivers/base/core.c | 1 -
drivers/input/keyboard/gpio_keys.c | 2 --
include/linux/device.h | 1 -
3 files changed, 4 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 8385df4d9677..6878dfcbf0d6 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -428,7 +428,6 @@ void device_pm_move_to_tail(struct device *dev)
device_pm_unlock();
device_links_read_unlock(idx);
}
-EXPORT_SYMBOL_GPL(device_pm_move_to_tail);
#define to_devlink(dev) container_of((dev), struct device_link, link_dev)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 7a0dcfeb02dc..e5af0a254a3f 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -810,8 +810,6 @@ static int gpio_keys_probe(struct platform_device *pdev)
int i, error;
int wakeup = 0;
- device_pm_move_to_tail(dev);
-
if (!pdata) {
pdata = gpio_keys_get_devtree_pdata(dev);
if (IS_ERR(pdata))
diff --git a/include/linux/device.h b/include/linux/device.h
index dad40bd45509..1508e637bb26 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1082,7 +1082,6 @@ void device_link_del(struct device_link *link);
void device_link_remove(void *consumer, struct device *supplier);
void device_links_supplier_sync_state_pause(void);
void device_links_supplier_sync_state_resume(void);
-void device_pm_move_to_tail(struct device *dev);
extern __printf(3, 4)
int dev_err_probe(const struct device *dev, int err, const char *fmt, ...);
--
2.34.1
^ permalink raw reply related
* [RFC PATCH 1/3] input: gpio-keys - use device_pm_move_to_tail
From: Doug Berger @ 2023-04-27 22:16 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Dmitry Torokhov
Cc: Lad Prabhakar, Gergo Koteles, Jonathan Cameron, Andy Shevchenko,
Dan Williams, Hans de Goede, Thomas Gleixner, Kees Cook,
Kishon Vijay Abraham I, Saravana Kannan, Florian Fainelli,
linux-kernel, linux-input, Doug Berger
In-Reply-To: <20230427221625.116050-1-opendmb@gmail.com>
The gpio-keys device driver implements the functionality of its
child nodes which do not receive dedicated drivers. This means
it should inherit the dependencies of these child nodes and
their effects on suspend/resume and shutdown order.
This commit exposes the device_pm_move_to_tail function to
allow the driver to move itself to the end of the lists upon a
successful probe to allow proper sequencing when other methods
are not available.
Fixes: 722e5f2b1eec ("driver core: Partially revert "driver core: correct device's shutdown order"")
Signed-off-by: Doug Berger <opendmb@gmail.com>
---
drivers/base/core.c | 1 +
drivers/input/keyboard/gpio_keys.c | 2 ++
include/linux/device.h | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 6878dfcbf0d6..8385df4d9677 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -428,6 +428,7 @@ void device_pm_move_to_tail(struct device *dev)
device_pm_unlock();
device_links_read_unlock(idx);
}
+EXPORT_SYMBOL_GPL(device_pm_move_to_tail);
#define to_devlink(dev) container_of((dev), struct device_link, link_dev)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index c42f86ad0766..0516c6279d8a 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -810,6 +810,8 @@ static int gpio_keys_probe(struct platform_device *pdev)
int i, error;
int wakeup = 0;
+ device_pm_move_to_tail(dev);
+
if (!pdata) {
pdata = gpio_keys_get_devtree_pdata(dev);
if (IS_ERR(pdata))
diff --git a/include/linux/device.h b/include/linux/device.h
index 1508e637bb26..dad40bd45509 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1082,6 +1082,7 @@ void device_link_del(struct device_link *link);
void device_link_remove(void *consumer, struct device *supplier);
void device_links_supplier_sync_state_pause(void);
void device_links_supplier_sync_state_resume(void);
+void device_pm_move_to_tail(struct device *dev);
extern __printf(3, 4)
int dev_err_probe(const struct device *dev, int err, const char *fmt, ...);
--
2.34.1
^ permalink raw reply related
* [RFC PATCH 2/3] input: gpio-keys - add device links of children
From: Doug Berger @ 2023-04-27 22:16 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Dmitry Torokhov
Cc: Lad Prabhakar, Gergo Koteles, Jonathan Cameron, Andy Shevchenko,
Dan Williams, Hans de Goede, Thomas Gleixner, Kees Cook,
Kishon Vijay Abraham I, Saravana Kannan, Florian Fainelli,
linux-kernel, linux-input, Doug Berger
In-Reply-To: <20230427221625.116050-1-opendmb@gmail.com>
Since the child nodes of gpio-keys are implemented by the
gpio-keys device driver, that driver should explicitly create
the appropriate device links to support proper device power
management and shutdown sequencing.
Fixes: f9aa460672c9 ("driver core: Refactor fw_devlink feature")
Signed-off-by: Doug Berger <opendmb@gmail.com>
---
drivers/input/keyboard/gpio_keys.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 0516c6279d8a..7a0dcfeb02dc 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -865,6 +865,7 @@ static int gpio_keys_probe(struct platform_device *pdev)
for (i = 0; i < pdata->nbuttons; i++) {
const struct gpio_keys_button *button = &pdata->buttons[i];
+ struct fwnode_link *link;
if (!dev_get_platdata(dev)) {
child = device_get_next_child_node(dev, child);
@@ -882,6 +883,12 @@ static int gpio_keys_probe(struct platform_device *pdev)
fwnode_handle_put(child);
return error;
}
+ if (child) {
+ list_for_each_entry(link, &child->suppliers, c_hook) {
+ device_link_add(dev, link->supplier->dev,
+ DL_FLAG_AUTOREMOVE_CONSUMER);
+ }
+ }
if (button->wakeup)
wakeup = 1;
--
2.34.1
^ permalink raw reply related
* [RFC PATCH 0/3] input: gpio-keys - fix pm ordering
From: Doug Berger @ 2023-04-27 22:16 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Dmitry Torokhov
Cc: Lad Prabhakar, Gergo Koteles, Jonathan Cameron, Andy Shevchenko,
Dan Williams, Hans de Goede, Thomas Gleixner, Kees Cook,
Kishon Vijay Abraham I, Saravana Kannan, Florian Fainelli,
linux-kernel, linux-input, Doug Berger
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.
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.
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
* [PATCH 3/4] Input: pwm-vibra - add support for enable GPIO
From: Luca Weiss @ 2023-04-27 20:34 UTC (permalink / raw)
To: ~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, Luca Weiss
In-Reply-To: <20230427-hammerhead-vibra-v1-0-e87eeb94da51@z3ntu.xyz>
Some pwm vibrators have a dedicated enable GPIO that needs to be set
high so that the vibrator works. Add support for that optionally.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
drivers/input/misc/pwm-vibra.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
index c08971c97ad6..2ba035299db8 100644
--- a/drivers/input/misc/pwm-vibra.c
+++ b/drivers/input/misc/pwm-vibra.c
@@ -11,6 +11,7 @@
* Copyright (C) 2010, Lars-Peter Clausen <lars@metafoo.de>
*/
+#include <linux/gpio/consumer.h>
#include <linux/input.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -23,6 +24,7 @@
struct pwm_vibrator {
struct input_dev *input;
+ struct gpio_desc *enable_gpio;
struct pwm_device *pwm;
struct pwm_device *pwm_dir;
struct regulator *vcc;
@@ -48,6 +50,8 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
vibrator->vcc_on = true;
}
+ gpiod_set_value_cansleep(vibrator->enable_gpio, 1);
+
pwm_get_state(vibrator->pwm, &state);
pwm_set_relative_duty_cycle(&state, vibrator->level, 0xffff);
state.enabled = true;
@@ -80,6 +84,8 @@ static void pwm_vibrator_stop(struct pwm_vibrator *vibrator)
pwm_disable(vibrator->pwm_dir);
pwm_disable(vibrator->pwm);
+ gpiod_set_value_cansleep(vibrator->enable_gpio, 0);
+
if (vibrator->vcc_on) {
regulator_disable(vibrator->vcc);
vibrator->vcc_on = false;
@@ -142,6 +148,16 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
return err;
}
+ vibrator->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
+ GPIOD_OUT_LOW);
+ err = PTR_ERR_OR_ZERO(vibrator->enable_gpio);
+ if (err) {
+ if (err != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Failed to request enable gpio: %d\n",
+ err);
+ return err;
+ }
+
vibrator->pwm = devm_pwm_get(&pdev->dev, "enable");
err = PTR_ERR_OR_ZERO(vibrator->pwm);
if (err) {
--
2.40.0
^ permalink raw reply related
* [PATCH 2/4] Input: pwm-vibra - add newline to dev_err prints
From: Luca Weiss @ 2023-04-27 20:34 UTC (permalink / raw)
To: ~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, Luca Weiss
In-Reply-To: <20230427-hammerhead-vibra-v1-0-e87eeb94da51@z3ntu.xyz>
Make sure all printed messages end with a newline.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
drivers/input/misc/pwm-vibra.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
index d0e58a7cdfa3..c08971c97ad6 100644
--- a/drivers/input/misc/pwm-vibra.c
+++ b/drivers/input/misc/pwm-vibra.c
@@ -42,7 +42,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
if (!vibrator->vcc_on) {
err = regulator_enable(vibrator->vcc);
if (err) {
- dev_err(pdev, "failed to enable regulator: %d", err);
+ dev_err(pdev, "failed to enable regulator: %d\n", err);
return err;
}
vibrator->vcc_on = true;
@@ -54,7 +54,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
err = pwm_apply_state(vibrator->pwm, &state);
if (err) {
- dev_err(pdev, "failed to apply pwm state: %d", err);
+ dev_err(pdev, "failed to apply pwm state: %d\n", err);
return err;
}
@@ -65,7 +65,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
err = pwm_apply_state(vibrator->pwm_dir, &state);
if (err) {
- dev_err(pdev, "failed to apply dir-pwm state: %d", err);
+ dev_err(pdev, "failed to apply dir-pwm state: %d\n", err);
pwm_disable(vibrator->pwm);
return err;
}
@@ -137,7 +137,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
err = PTR_ERR_OR_ZERO(vibrator->vcc);
if (err) {
if (err != -EPROBE_DEFER)
- dev_err(&pdev->dev, "Failed to request regulator: %d",
+ dev_err(&pdev->dev, "Failed to request regulator: %d\n",
err);
return err;
}
@@ -146,7 +146,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
err = PTR_ERR_OR_ZERO(vibrator->pwm);
if (err) {
if (err != -EPROBE_DEFER)
- dev_err(&pdev->dev, "Failed to request main pwm: %d",
+ dev_err(&pdev->dev, "Failed to request main pwm: %d\n",
err);
return err;
}
@@ -158,7 +158,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
state.enabled = false;
err = pwm_apply_state(vibrator->pwm, &state);
if (err) {
- dev_err(&pdev->dev, "failed to apply initial PWM state: %d",
+ dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
err);
return err;
}
@@ -172,7 +172,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
state.enabled = false;
err = pwm_apply_state(vibrator->pwm_dir, &state);
if (err) {
- dev_err(&pdev->dev, "failed to apply initial PWM state: %d",
+ dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
err);
return err;
}
@@ -189,7 +189,7 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
break;
default:
- dev_err(&pdev->dev, "Failed to request direction pwm: %d", err);
+ dev_err(&pdev->dev, "Failed to request direction pwm: %d\n", err);
fallthrough;
case -EPROBE_DEFER:
@@ -207,13 +207,13 @@ static int pwm_vibrator_probe(struct platform_device *pdev)
err = input_ff_create_memless(vibrator->input, NULL,
pwm_vibrator_play_effect);
if (err) {
- dev_err(&pdev->dev, "Couldn't create FF dev: %d", err);
+ dev_err(&pdev->dev, "Couldn't create FF dev: %d\n", err);
return err;
}
err = input_register_device(vibrator->input);
if (err) {
- dev_err(&pdev->dev, "Couldn't register input dev: %d", err);
+ dev_err(&pdev->dev, "Couldn't register input dev: %d\n", err);
return err;
}
--
2.40.0
^ permalink raw reply related
* [PATCH 0/4] Add haptics support to Nexus 5 using pwm-vibra driver
From: Luca Weiss @ 2023-04-27 20:34 UTC (permalink / raw)
To: ~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, Luca Weiss
A while ago Brian Masney sent some patches for a clk-vibrator which was
then succeeded by the idea of a clk-pwm driver that "converts" a clock
into a PWM and to use the existing pwm-vibra driver.
Since clk-pwm has landed last year we can finally add haptics support
upstream.
We just need to add support for an enable GPIO to the pwm-vibra driver
since that also needs to be high for the haptics to work on this device.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
Luca Weiss (4):
dt-bindings: input: pwm-vibrator: Add enable-gpio
Input: pwm-vibra - add newline to dev_err prints
Input: pwm-vibra - add support for enable GPIO
ARM: dts: qcom: msm8974-hammerhead: Add vibrator
.../devicetree/bindings/input/pwm-vibrator.yaml | 2 ++
.../dts/qcom-msm8974-lge-nexus5-hammerhead.dts | 35 +++++++++++++++++++++
drivers/input/misc/pwm-vibra.c | 36 ++++++++++++++++------
3 files changed, 63 insertions(+), 10 deletions(-)
---
base-commit: dec7f67a13c3270f9a38eba227a4fc15993f01b3
change-id: 20230427-hammerhead-vibra-06bd1bf771a3
Best regards,
--
Luca Weiss <luca@z3ntu.xyz>
^ 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