linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Dmitry Torokhov
	<dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCHv3 1/2] Input: pwm-vibra: new driver
Date: Mon, 8 May 2017 20:51:28 +0200	[thread overview]
Message-ID: <20170508185128.2vkgkxn6cfnmkqc7@earth> (raw)
In-Reply-To: <20170507213800.GA39686@dtor-ws>

[-- Attachment #1: Type: text/plain, Size: 6501 bytes --]

Hi Dmitry,

On Sun, May 07, 2017 at 02:38:00PM -0700, Dmitry Torokhov wrote:
> > + *  This program is free software; you can redistribute it and/or modify it
> > + *  under  the terms of the GNU General  Public License as published by the
> > + *  Free Software Foundation;  either version 2 of the License, or (at your
> > + *  option) any later version.
> > + */
> > +
> > +#define DEBUG
> 
> I do not think this is needed.

Leftover from writing the driver :) Will remove in v4.

> > +
> > +#include <linux/input.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/pwm.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/slab.h>
> > +
> > +/**
> 
> This is not kernel doc, so no "/**".

Ack.

> > + * Motorola Droid 4 (also known as mapphone), has a vibrator, which pulses
> > + * 1x on rising edge. Increasing the pwm period results in more pulses per
> > + * second, but reduces intensity. There is also a second channel to control
> > + * the vibrator's rotation direction to increase effect. The following
> > + * numbers were determined manually. Going below 12.5 Hz means, clearly
> > + * noticeable pauses and at 30 Hz the vibration is just barely noticable
> > + * anymore.
> > + */
> > +#define MAPPHONE_MIN_FREQ 125 /* 12.5 Hz */
> > +#define MAPPHONE_MAX_FREQ 300 /* 30.0 Hz */
> > +
> > [...]
> > +
> > +	vibrator->pwm_dir = devm_pwm_get(&pdev->dev, "direction");
> > +	err = PTR_ERR_OR_ZERO(vibrator->pwm_dir);
> > +	if (err == -ENODATA) {
> > +		vibrator->pwm_dir = NULL;
> > +	} else if (err == -EPROBE_DEFER) {
> > +		return err;
> > +	} else if (err) {
> > +		dev_err(&pdev->dev, "Failed to request direction pwm: %d", err);
> > +		return err;
> > +	} else {
> > +		/* Sync up PWM state and ensure it is off. */
> > +		pwm_init_state(vibrator->pwm_dir, &state);
> > +		state.enabled = false;
> > +		err = pwm_apply_state(vibrator->pwm_dir, &state);
> > +		if (err) {
> > +			dev_err(&pdev->dev, "failed to apply initial PWM state: %d",
> > +				err);
> > +			return err;
> > +		}
> > +	}
> 
> I wonder if the above is not better with "switch":
> 
> 	switch (err) {
> 	case 0:
> 		/* Sync up PWM state and ensure it is off. */
> 		pwm_init_state(vibrator->pwm_dir, &state);
> 		state.enabled = false;
> 		err = pwm_apply_state(vibrator->pwm_dir, &state);
> 		if (err) {
> 			dev_err(&pdev->dev,
> 				"failed to apply initial PWM state: %d", err);
> 			return err;
> 		}
> 		break;
> 
> 	case -ENODATA:
> 		/* Direction PWM is optional */
> 		vibrator->pwm_dir = NULL;
> 		break;
> 
> 	default:
> 		dev_err(&pdev->dev, "Failed to request direction pwm: %d", err);
> 		/* Fall through */
> 
> 	case -EPROBE_DEFER:
> 		return err;
> 	}

Ack.

> > +
> > +	vibrator->hw = of_device_get_match_data(&pdev->dev);
> > +	if (!vibrator->hw)
> > +		vibrator->hw = &pwm_vib_hw_generic;
> > +
> > +	input->name = "pwm-vibrator";
> > +	input->id.bustype = BUS_HOST;
> > +	input->dev.parent = &pdev->dev;
> > +	input->close = pwm_vibrator_close;
> > +
> > +	input_set_drvdata(input, vibrator);
> > +	input_set_capability(input, EV_FF, FF_RUMBLE);
> > +
> > +	err = input_ff_create_memless(input, NULL, pwm_vibrator_play_effect);
> > +	if (err) {
> > +		dev_err(&pdev->dev, "Couldn't create FF dev: %d", err);
> > +		return err;
> > +	}
> > +
> > +	err = input_register_device(input);
> > +	if (err) {
> > +		dev_err(&pdev->dev, "Couldn't register input dev: %d", err);
> > +		return err;
> > +	}
> > +
> > +	platform_set_drvdata(pdev, vibrator);
> > +
> > +	return 0;
> > +}
> > +
> > +static int __maybe_unused pwm_vibrator_suspend(struct device *dev)
> > +{
> > +	struct platform_device *pdev = to_platform_device(dev);
> > +	struct pwm_vibrator *vibrator = platform_get_drvdata(pdev);
> > +	struct input_dev *input = vibrator->input;
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&input->event_lock, flags);
> 
> Hmm, no, this is not goting to work. The original patch had a chance if
> PWM was not sleeping, but with introduction of regulator and work this
> definitely sleeps.

Actually PWM is sleeping, that's why I added work (regulator was
added later) :)

> I think we should solve issue of events [not] being delivered during
> suspend transition in input core, and simply drop spin_lock_irqsave()
> here and in resume().

Sounds good. will you take care of the input-core change?

> > +	cancel_work_sync(&vibrator->play_work);
> > +	if (vibrator->level)
> > +		pwm_vibrator_stop(vibrator);
> > +	spin_unlock_irqrestore(&input->event_lock, flags);
> > +
> > +	return 0;
> > +}
> > +
> > +static int __maybe_unused pwm_vibrator_resume(struct device *dev)
> > +{
> > +	struct platform_device *pdev = to_platform_device(dev);
> > +	struct pwm_vibrator *vibrator = platform_get_drvdata(pdev);
> > +	struct input_dev *input = vibrator->input;
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&input->event_lock, flags);
> > +	if (vibrator->level)
> > +		pwm_vibrator_start(vibrator);
> > +	spin_unlock_irqrestore(&input->event_lock, flags);
> > +
> > +	return 0;
> > +}
> > +
> > +static SIMPLE_DEV_PM_OPS(pwm_vibrator_pm_ops,
> > +			 pwm_vibrator_suspend, pwm_vibrator_resume);
> > +
> > +#ifdef CONFIG_OF
> > +
> > +#define PWM_VIB_COMPAT(of_compatible, cfg) {			\
> > +			.compatible = of_compatible,		\
> > +			.data = &cfg,	\
> > +}
> > +
> > +static const struct of_device_id pwm_vibra_dt_match_table[] = {
> > +	PWM_VIB_COMPAT("pwm-vibrator", pwm_vib_hw_generic),
> > +	PWM_VIB_COMPAT("motorola,mapphone-pwm-vibrator", pwm_vib_hw_mapphone),
> > +	{},
> > +};
> > +MODULE_DEVICE_TABLE(of, pwm_vibra_dt_match_table);
> > +#endif
> > +
> > +static struct platform_driver pwm_vibrator_driver = {
> > +	.probe	= pwm_vibrator_probe,
> > +	.driver	= {
> > +		.name	= "pwm-vibrator",
> > +		.pm	= &pwm_vibrator_pm_ops,
> > +		.of_match_table = of_match_ptr(pwm_vibra_dt_match_table),
> > +	},
> > +};
> > +module_platform_driver(pwm_vibrator_driver);
> > +
> > +MODULE_AUTHOR("Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>");
> > +MODULE_DESCRIPTION("PWM vibrator driver");
> > +MODULE_LICENSE("GPL");
> > +MODULE_ALIAS("platform:pwm-vibrator");
> > -- 
> > 2.11.0
> > 
> 
> Thanks.

Thanks for the review.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-05-08 18:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05  9:28 [PATCHv3 0/2] PWM Vibrator driver Sebastian Reichel
2017-05-05  9:28 ` [PATCHv3 1/2] Input: pwm-vibra: new driver Sebastian Reichel
2017-05-07 21:38   ` Dmitry Torokhov
2017-05-08 18:51     ` Sebastian Reichel [this message]
2017-05-10 21:56       ` Dmitry Torokhov
2017-05-08 17:31   ` Rob Herring
2017-05-08 18:38     ` Sebastian Reichel
2017-05-05  9:28 ` [PATCHv3 2/2] ARM: dts: omap4-droid4: Add vibrator Sebastian Reichel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170508185128.2vkgkxn6cfnmkqc7@earth \
    --to=sre-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).