RE: [PATCH v18 3/3] Input: new da7280 haptic driver
On Sun, August 2, 2020 8:54 PM, Pavel Machek wrote: > Hi! > > > > +static DEVICE_ATTR_RW(ps_seq_id); > > > +static DEVICE_ATTR_RW(ps_seq_loop); static > > > +DEVICE_ATTR_RW(gpi_seq_id0); static DEVICE_ATTR_RW(gpi_seq_id1); > > > +static DEVICE_ATTR_RW(gpi_seq_id2); static > > > +DEVICE_ATTR_WO(patterns); > > > > Should this be a binary attribute instead of having string parsing in > > the kernel? > > Plus... is this suitable userland interface? Should it be documetned? It could be used by sysfs interface and string parsing, and I added some examples ahead of id and loop attributes, but for the patterns yes, it should be. As I have already added some comment before for the first comment from Dmitry, now the upload effect covers this attributes, so I would like to remove them and I have added some code a little bit more in the upload effect function in the next patch. Thanks for your comments. > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html Kind regards Roy
Re: [PATCH v18 3/3] Input: new da7280 haptic driver
Hi! > > +static DEVICE_ATTR_RW(ps_seq_id); > > +static DEVICE_ATTR_RW(ps_seq_loop); > > +static DEVICE_ATTR_RW(gpi_seq_id0); > > +static DEVICE_ATTR_RW(gpi_seq_id1); > > +static DEVICE_ATTR_RW(gpi_seq_id2); > > +static DEVICE_ATTR_WO(patterns); > > Should this be a binary attribute instead of having string parsing in > the kernel? Plus... is this suitable userland interface? Should it be documetned? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
RE: [PATCH v18 3/3] Input: new da7280 haptic driver
On Thu, July 30, 2020 2:10 PM, Dmitry Torokhov > On Wed, Jul 29, 2020 at 02:09:48PM +, Roy Im wrote: > > Wednesday, July 29, 2020 3:37 PM, Dmitry Torokhov wrote: > > > On Wed, Jul 29, 2020 at 11:59:40AM +0900, Roy Im wrote: > > > > v11: > > > > - Updated the pwm related code, comments and typo. > > > > v10: > > > > - Updated the pwm related function and added some comments. > > > > v9: > > > > - Removed the header file and put the definitions into the c > > > > file. > > > > - Updated the pwm code and error logs with %pE > > > > > > I believe the %pE is to format an escaped buffer, you probably want > > > to %pe (lowercase) to print errors. I am also not quite sure if we want > > > to use it in cases when we have non-pointer error, or > we should stick with %d as most of the kernel does. > > > > Right, it should be %pe as you and Uwe said, Uwe suggested %pe to > > understand easier.. do you still prefer to stick with %d? > > Depends on the situation. If you already have ERR_PTR-encoded error there is > no reason for not using %pe, but if you have > integer error, or you have already converted pointer to integer I'd prefer we > stick with %d. > > As I mentioned in another message maybe we should consider adding '%de' > or similar for formatting integer errors. I have seen the discussion messages in another email, then I am not still quite sure what could be good for now. Do you still prefer to be with %d if I have already converted pointer to integer and with %pe for something that I already have ERR_PTR-encoded error? Kind regards, Roy
Re: [PATCH v18 3/3] Input: new da7280 haptic driver
On Thu, Jul 30, 2020 at 11:30:58AM +0300, Andy Shevchenko wrote: > On Thu, Jul 30, 2020 at 08:16:31AM +0200, Uwe Kleine-König wrote: > > On Wed, Jul 29, 2020 at 10:06:53PM -0700, Dmitry Torokhov wrote: > > > On Wed, Jul 29, 2020 at 09:21:45AM +0200, Uwe Kleine-König wrote: > > > > On Tue, Jul 28, 2020 at 11:36:38PM -0700, Dmitry Torokhov wrote: > > ... > > > > Maybe we should introduce something like '%de' for the integer error > > > case? > > > > I suggested that some time ago with limited success, see > > https://lore.kernel.org/lkml/20200129115516.zsvxu56e6h7gh...@pathway.suse.cz/ > > Oh, please, no need for that really. We have now dev_err_probe() on its way to > upstream (now in Greg's tree) which hides all this behind. > > Just switch to dev_err_probe() and forget about what is under the hood. Awesome, we just need to make sure there is never an error condition outside of probe path, and we will be set ;) Easy peasy ;) Thanks. -- Dmitry
Re: [PATCH v18 3/3] Input: new da7280 haptic driver
On Thu, Jul 30, 2020 at 08:16:31AM +0200, Uwe Kleine-König wrote: > On Wed, Jul 29, 2020 at 10:06:53PM -0700, Dmitry Torokhov wrote: > > On Wed, Jul 29, 2020 at 09:21:45AM +0200, Uwe Kleine-König wrote: > > > On Tue, Jul 28, 2020 at 11:36:38PM -0700, Dmitry Torokhov wrote: ... > > Maybe we should introduce something like '%de' for the integer error > > case? > > I suggested that some time ago with limited success, see > https://lore.kernel.org/lkml/20200129115516.zsvxu56e6h7gh...@pathway.suse.cz/ Oh, please, no need for that really. We have now dev_err_probe() on its way to upstream (now in Greg's tree) which hides all this behind. Just switch to dev_err_probe() and forget about what is under the hood. -- With Best Regards, Andy Shevchenko
Re: [PATCH v18 3/3] Input: new da7280 haptic driver
Hello, On Wed, Jul 29, 2020 at 11:34:04PM -0700, Dmitry Torokhov wrote: > On Thu, Jul 30, 2020 at 08:16:31AM +0200, Uwe Kleine-König wrote: > > I suggested that some time ago with limited success, see > > https://lore.kernel.org/lkml/20200129115516.zsvxu56e6h7gh...@pathway.suse.cz/ > > . > > > > > In the meantime I would prefer using %d when we have integer > > > error. We should not see these error messages anyway ;) > > > > I don't agree. Error messages are supposed to be helpful and I prefer > > some casting between error pointer and error int over emitting bare > > numbers to the kernel log. (And additionally the uglyness might help to > > convince the vsprintf guys that %de might be a good idea after all :-) > > Sorry, but I do not think that I want to introduce this pointless > casting just to sway printk folks. Either we have proper way of > formatting error codes, or we do not and we stick with what was working > since forever. You got me wrong. Getting an argument to rediscuss %de is just a minor side reason for me. Getting an expressive error message is the relevant reason. There is also an inconsitence in what you suggest that I don't like. If in a probe function devm_clk_get fails it should say "-ENODEV" but if it's clk_enable that fails it should say "-5"? Also "we stick with what was working since forever" is a poor argument. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH v18 3/3] Input: new da7280 haptic driver
On Thu, Jul 30, 2020 at 08:16:31AM +0200, Uwe Kleine-König wrote:
> [Adding vsprintf maintainers to Cc:]
>
> Hello,
>
> On Wed, Jul 29, 2020 at 10:06:53PM -0700, Dmitry Torokhov wrote:
> > On Wed, Jul 29, 2020 at 09:21:45AM +0200, Uwe Kleine-König wrote:
> > > Hello,
> > >
> > > On Tue, Jul 28, 2020 at 11:36:38PM -0700, Dmitry Torokhov wrote:
> > > > > v9:
> > > > > - Removed the header file and put the definitions into the c
> > > > > file.
> > > > > - Updated the pwm code and error logs with %pE
> > > >
> > > > I believe the %pE is to format an escaped buffer, you probably want to
> > > > %pe (lowercase) to print errors. I am also not quite sure if we want to
> > > > use it in cases when we have non-pointer error, or we should stick with
> > > > %d as most of the kernel does.
> > >
> > > compared with %d %pe is easier to understand as it emits "-ETIMEOUT"
> > > instead of "-110". And yes, %pE is wrong.
> >
> > While I can see that symbolic name instead of a numeric constant might
> > be appealing, I do not believe that we want fragments like this with
> > endless conversions between integer and pointer errors:
> >
> > if (haptics->const_op_mode == DA7280_PWM_MODE) {
> > haptics->pwm_dev = devm_pwm_get(dev, NULL);
> > if (IS_ERR(haptics->pwm_dev)) {
> > error = PTR_ERR(haptics->pwm_dev);
> > if (error != -EPROBE_DEFER)
> > dev_err(dev, "unable to request PWM: %pE\n",
> > ERR_PTR(error));
> > return error;
> > }
> >
> > Maybe we should introduce something like '%de' for the integer error
> > case?
>
> I suggested that some time ago with limited success, see
> https://lore.kernel.org/lkml/20200129115516.zsvxu56e6h7gh...@pathway.suse.cz/
> .
>
> > In the meantime I would prefer using %d when we have integer
> > error. We should not see these error messages anyway ;)
>
> I don't agree. Error messages are supposed to be helpful and I prefer
> some casting between error pointer and error int over emitting bare
> numbers to the kernel log. (And additionally the uglyness might help to
> convince the vsprintf guys that %de might be a good idea after all :-)
Sorry, but I do not think that I want to introduce this pointless
casting just to sway printk folks. Either we have proper way of
formatting error codes, or we do not and we stick with what was working
since forever.
Thanks.
--
Dmitry
Re: [PATCH v18 3/3] Input: new da7280 haptic driver
[Adding vsprintf maintainers to Cc:]
Hello,
On Wed, Jul 29, 2020 at 10:06:53PM -0700, Dmitry Torokhov wrote:
> On Wed, Jul 29, 2020 at 09:21:45AM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Tue, Jul 28, 2020 at 11:36:38PM -0700, Dmitry Torokhov wrote:
> > > > v9:
> > > > - Removed the header file and put the definitions into the c
> > > > file.
> > > > - Updated the pwm code and error logs with %pE
> > >
> > > I believe the %pE is to format an escaped buffer, you probably want to
> > > %pe (lowercase) to print errors. I am also not quite sure if we want to
> > > use it in cases when we have non-pointer error, or we should stick with
> > > %d as most of the kernel does.
> >
> > compared with %d %pe is easier to understand as it emits "-ETIMEOUT"
> > instead of "-110". And yes, %pE is wrong.
>
> While I can see that symbolic name instead of a numeric constant might
> be appealing, I do not believe that we want fragments like this with
> endless conversions between integer and pointer errors:
>
> if (haptics->const_op_mode == DA7280_PWM_MODE) {
> haptics->pwm_dev = devm_pwm_get(dev, NULL);
> if (IS_ERR(haptics->pwm_dev)) {
> error = PTR_ERR(haptics->pwm_dev);
> if (error != -EPROBE_DEFER)
> dev_err(dev, "unable to request PWM: %pE\n",
> ERR_PTR(error));
> return error;
> }
>
> Maybe we should introduce something like '%de' for the integer error
> case?
I suggested that some time ago with limited success, see
https://lore.kernel.org/lkml/20200129115516.zsvxu56e6h7gh...@pathway.suse.cz/
.
> In the meantime I would prefer using %d when we have integer
> error. We should not see these error messages anyway ;)
I don't agree. Error messages are supposed to be helpful and I prefer
some casting between error pointer and error int over emitting bare
numbers to the kernel log. (And additionally the uglyness might help to
convince the vsprintf guys that %de might be a good idea after all :-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [PATCH v18 3/3] Input: new da7280 haptic driver
On Wed, Jul 29, 2020 at 02:09:48PM +, Roy Im wrote: > Hello Dmitry and Uwe, > > Wednesday, July 29, 2020 3:37 PM, Dmitry Torokhov wrote: > > > On Wed, Jul 29, 2020 at 11:59:40AM +0900, Roy Im wrote: > > > Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with multiple > > > mode and integrated waveform memory and wideband support. > > > It communicates via an I2C bus to the device. > > > > A few questions/suggestions... > > > > > > > > Reviewed-by: Jes Sorensen . > > > > > > Signed-off-by: Roy Im > > > > > > --- > > > v18: > > > - Corrected comments in Kconfig > > > - Updated to preferred style for multi line comments in c file. > > > v17: > > > - fixed an issue. > > > v16: > > > - Corrected some code and updated description in Kconfig. > > > v15: > > > - Removed some defines and updated some comments. > > > v14: > > > - Updated pwm related code, alignments and comments. > > > v13: > > > - Updated some conditions in pwm function and alignments. > > > v12: No changes. > > > v11: > > > - Updated the pwm related code, comments and typo. > > > v10: > > > - Updated the pwm related function and added some comments. > > > v9: > > > - Removed the header file and put the definitions into the c file. > > > - Updated the pwm code and error logs with %pE > > > > I believe the %pE is to format an escaped buffer, you probably want to %pe > > (lowercase) to print errors. I am also not quite sure > > if we want to use it in cases when we have non-pointer error, or we should > > stick with %d as most of the kernel does. > > Right, it should be %pe as you and Uwe said, Uwe suggested %pe to understand > easier.. do you still prefer to stick with %d? Depends on the situation. If you already have ERR_PTR-encoded error there is no reason for not using %pe, but if you have integer error, or you have already converted pointer to integer I'd prefer we stick with %d. As I mentioned in another message maybe we should consider adding '%de' or similar for formatting integer errors. Thanks. -- Dmitry
Re: [PATCH v18 3/3] Input: new da7280 haptic driver
Hi Uwe,
On Wed, Jul 29, 2020 at 09:21:45AM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jul 28, 2020 at 11:36:38PM -0700, Dmitry Torokhov wrote:
> > > v9:
> > > - Removed the header file and put the definitions into the c file.
> > > - Updated the pwm code and error logs with %pE
> >
> > I believe the %pE is to format an escaped buffer, you probably want to
> > %pe (lowercase) to print errors. I am also not quite sure if we want to
> > use it in cases when we have non-pointer error, or we should stick with
> > %d as most of the kernel does.
>
> compared with %d %pe is easier to understand as it emits "-ETIMEOUT"
> instead of "-110". And yes, %pE is wrong.
While I can see that symbolic name instead of a numeric constant might
be appealing, I do not believe that we want fragments like this with
endless conversions between integer and pointer errors:
if (haptics->const_op_mode == DA7280_PWM_MODE) {
haptics->pwm_dev = devm_pwm_get(dev, NULL);
if (IS_ERR(haptics->pwm_dev)) {
error = PTR_ERR(haptics->pwm_dev);
if (error != -EPROBE_DEFER)
dev_err(dev, "unable to request PWM: %pE\n",
ERR_PTR(error));
return error;
}
Maybe we should introduce something like '%de' for the integer error
case? In the meantime I would prefer using %d when we have integer
error. We should not see these error messages anyway ;)
Thanks.
--
Dmitry
RE: [PATCH v18 3/3] Input: new da7280 haptic driver
Hello Dmitry and Uwe,
Wednesday, July 29, 2020 3:37 PM, Dmitry Torokhov wrote:
> On Wed, Jul 29, 2020 at 11:59:40AM +0900, Roy Im wrote:
> > Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with multiple
> > mode and integrated waveform memory and wideband support.
> > It communicates via an I2C bus to the device.
>
> A few questions/suggestions...
>
> >
> > Reviewed-by: Jes Sorensen .
> >
> > Signed-off-by: Roy Im
> >
> > ---
> > v18:
> > - Corrected comments in Kconfig
> > - Updated to preferred style for multi line comments in c file.
> > v17:
> > - fixed an issue.
> > v16:
> > - Corrected some code and updated description in Kconfig.
> > v15:
> > - Removed some defines and updated some comments.
> > v14:
> > - Updated pwm related code, alignments and comments.
> > v13:
> > - Updated some conditions in pwm function and alignments.
> > v12: No changes.
> > v11:
> > - Updated the pwm related code, comments and typo.
> > v10:
> > - Updated the pwm related function and added some comments.
> > v9:
> > - Removed the header file and put the definitions into the c file.
> > - Updated the pwm code and error logs with %pE
>
> I believe the %pE is to format an escaped buffer, you probably want to %pe
> (lowercase) to print errors. I am also not quite sure
> if we want to use it in cases when we have non-pointer error, or we should
> stick with %d as most of the kernel does.
Right, it should be %pe as you and Uwe said, Uwe suggested %pe to understand
easier.. do you still prefer to stick with %d?
>
> ...
> > +
> > +/* DA7280_ACTUATOR3 (Address 0x0e) */
> > +#define DA7280_IMAX_MASK (31 << 0)
>
> We have GENMASK(h,l) macro in include/linux/bits.h that could be used here
> and in other mask definitions.
I will do.
>
> > +
> > + bool legacy;
> > + struct delayed_work work_duration;
> > + struct work_struct work_playback;
> > + struct work_struct work_setgain;
>
> How do we ensure that all these works do not clash with each other?
> As far as I can see we could have the "duration" work executing
> simultaneously with playback...
You are right, I will use use cancel_delayed_work_sync()/duration and
cancel_work_sync()/playback before scheduling playback work. And same as for
the work_setgain. For setgain, there is no problem to run this regardless the
playback.
>
> > +static int da7280_haptics_playback(struct input_dev *dev,
> > + int effect_id, int val)
> > +{
> > + struct da7280_haptic *haptics = input_get_drvdata(dev);
> > +
> > + if (!haptics->op_mode) {
> > + dev_warn(haptics->dev,
> > +"Any effects are not uploaded yet\n");
>
> "No effects have been uploaded"?
Ok, let me update so.
>
> > + return -EPERM;
>
> I'd say EINVAL.
OK
>
> > +static DEVICE_ATTR_RW(ps_seq_id);
> > +static DEVICE_ATTR_RW(ps_seq_loop);
> > +static DEVICE_ATTR_RW(gpi_seq_id0);
> > +static DEVICE_ATTR_RW(gpi_seq_id1);
> > +static DEVICE_ATTR_RW(gpi_seq_id2);
> > +static DEVICE_ATTR_WO(patterns);
>
> Should this be a binary attribute instead of having string parsing in the
> kernel?
I have carefully reviewed my driver again with your comments, now the upload
effect covers this attributes, so I would like to remove them and add some code
more for gpi_seq_idx update.
Thanks for your comments.
Kinds regards,
Roy
Re: [PATCH v18 3/3] Input: new da7280 haptic driver
Hello, On Tue, Jul 28, 2020 at 11:36:38PM -0700, Dmitry Torokhov wrote: > > v9: > > - Removed the header file and put the definitions into the c file. > > - Updated the pwm code and error logs with %pE > > I believe the %pE is to format an escaped buffer, you probably want to > %pe (lowercase) to print errors. I am also not quite sure if we want to > use it in cases when we have non-pointer error, or we should stick with > %d as most of the kernel does. compared with %d %pe is easier to understand as it emits "-ETIMEOUT" instead of "-110". And yes, %pE is wrong. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH v18 3/3] Input: new da7280 haptic driver
Hi Roy,
On Wed, Jul 29, 2020 at 11:59:40AM +0900, Roy Im wrote:
> Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with
> multiple mode and integrated waveform memory and wideband support.
> It communicates via an I2C bus to the device.
A few questions/suggestions...
>
> Reviewed-by: Jes Sorensen .
>
> Signed-off-by: Roy Im
>
> ---
> v18:
> - Corrected comments in Kconfig
> - Updated to preferred style for multi line comments in c file.
> v17:
> - fixed an issue.
> v16:
> - Corrected some code and updated description in Kconfig.
> v15:
> - Removed some defines and updated some comments.
> v14:
> - Updated pwm related code, alignments and comments.
> v13:
> - Updated some conditions in pwm function and alignments.
> v12: No changes.
> v11:
> - Updated the pwm related code, comments and typo.
> v10:
> - Updated the pwm related function and added some comments.
> v9:
> - Removed the header file and put the definitions into the c file.
> - Updated the pwm code and error logs with %pE
I believe the %pE is to format an escaped buffer, you probably want to
%pe (lowercase) to print errors. I am also not quite sure if we want to
use it in cases when we have non-pointer error, or we should stick with
%d as most of the kernel does.
...
> +
> +/* DA7280_ACTUATOR3 (Address 0x0e) */
> +#define DA7280_IMAX_MASK (31 << 0)
We have GENMASK(h,l) macro in include/linux/bits.h that could be used
here and in other mask definitions.
> +
> + bool legacy;
> + struct delayed_work work_duration;
> + struct work_struct work_playback;
> + struct work_struct work_setgain;
How do we ensure that all these works do not clash with each other?
As far as I can see we could have the "duration" work executing
simultaneously with playback...
> +static int da7280_haptics_playback(struct input_dev *dev,
> +int effect_id, int val)
> +{
> + struct da7280_haptic *haptics = input_get_drvdata(dev);
> +
> + if (!haptics->op_mode) {
> + dev_warn(haptics->dev,
> + "Any effects are not uploaded yet\n");
"No effects have been uploaded"?
> + return -EPERM;
I'd say EINVAL.
> +static DEVICE_ATTR_RW(ps_seq_id);
> +static DEVICE_ATTR_RW(ps_seq_loop);
> +static DEVICE_ATTR_RW(gpi_seq_id0);
> +static DEVICE_ATTR_RW(gpi_seq_id1);
> +static DEVICE_ATTR_RW(gpi_seq_id2);
> +static DEVICE_ATTR_WO(patterns);
Should this be a binary attribute instead of having string parsing in
the kernel?
Thanks.
--
Dmitry
[PATCH v18 3/3] Input: new da7280 haptic driver
Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with multiple mode and integrated waveform memory and wideband support. It communicates via an I2C bus to the device. Reviewed-by: Jes Sorensen . Signed-off-by: Roy Im --- v18: - Corrected comments in Kconfig - Updated to preferred style for multi line comments in c file. v17: - fixed an issue. v16: - Corrected some code and updated description in Kconfig. v15: - Removed some defines and updated some comments. v14: - Updated pwm related code, alignments and comments. v13: - Updated some conditions in pwm function and alignments. v12: No changes. v11: - Updated the pwm related code, comments and typo. v10: - Updated the pwm related function and added some comments. v9: - Removed the header file and put the definitions into the c file. - Updated the pwm code and error logs with %pE v8: - Added changes to support FF_PERIODIC/FF_CUSTOM and FF_CONSTANT. - Updated the dt-related code. - Removed memless related functions. v7: - Added more attributes to handle one value per file. - Replaced and updated the dt-related code and functions called. - Fixed error/functions. v6: No changes. v5: Fixed errors in Kconfig file. v4: Updated code as dt-bindings are changed. v3: No changes. v2: Fixed kbuild error/warning drivers/input/misc/Kconfig | 12 + drivers/input/misc/Makefile |1 + drivers/input/misc/da7280.c | 1845 +++ 3 files changed, 1858 insertions(+) create mode 100644 drivers/input/misc/da7280.c diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 362e8a0..d38b466 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -869,4 +869,16 @@ config INPUT_STPMIC1_ONKEY To compile this driver as a module, choose M here: the module will be called stpmic1_onkey. +config INPUT_DA7280_HAPTICS + tristate "Dialog Semiconductor DA7280 haptics support" + depends on INPUT && I2C + select REGMAP_I2C + help + Say Y to enable support for the Dialog DA7280 haptics driver. + The haptics can be controlled by PWM or GPIO + with I2C communication. + + To compile this driver as a module, choose M here: the + module will be called da7280. + endif diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index a48e5f2..9cfd6ab 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -25,6 +25,7 @@ obj-$(CONFIG_INPUT_CMA3000) += cma3000_d0x.o obj-$(CONFIG_INPUT_CMA3000_I2C)+= cma3000_d0x_i2c.o obj-$(CONFIG_INPUT_COBALT_BTNS)+= cobalt_btns.o obj-$(CONFIG_INPUT_CPCAP_PWRBUTTON)+= cpcap-pwrbutton.o +obj-$(CONFIG_INPUT_DA7280_HAPTICS) += da7280.o obj-$(CONFIG_INPUT_DA9052_ONKEY) += da9052_onkey.o obj-$(CONFIG_INPUT_DA9055_ONKEY) += da9055_onkey.o obj-$(CONFIG_INPUT_DA9063_ONKEY) += da9063_onkey.o diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c new file mode 100644 index 000..ecc8428 --- /dev/null +++ b/drivers/input/misc/da7280.c @@ -0,0 +1,1845 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * DA7280 Haptic device driver + * + * Copyright (c) 2020 Dialog Semiconductor. + * Author: Roy Im + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Registers */ +#define DA7280_IRQ_EVENT1 0x03 +#define DA7280_IRQ_EVENT_WARNING_DIAG 0x04 +#define DA7280_IRQ_EVENT_SEQ_DIAG 0x05 +#define DA7280_IRQ_STATUS10x06 +#define DA7280_IRQ_MASK1 0x07 +#define DA7280_FRQ_LRA_PER_H 0x0A +#define DA7280_FRQ_LRA_PER_L 0x0B +#define DA7280_ACTUATOR1 0x0C +#define DA7280_ACTUATOR2 0x0D +#define DA7280_ACTUATOR3 0x0E +#define DA7280_CALIB_V2I_H0x0F +#define DA7280_CALIB_V2I_L0x10 +#define DA7280_TOP_CFG1 0x13 +#define DA7280_TOP_CFG2 0x14 +#define DA7280_TOP_CFG4 0x16 +#define DA7280_TOP_INT_CFG1 0x17 +#define DA7280_TOP_CTL1 0x22 +#define DA7280_TOP_CTL2 0x23 +#define DA7280_SEQ_CTL2 0x28 +#define DA7280_GPI_0_CTL 0x29 +#define DA7280_GPI_1_CTL 0x2A +#define DA7280_GPI_2_CTL 0x2B +#define DA7280_MEM_CTL1 0x2C +#define DA7280_MEM_CTL2 0x2D +#define DA7280_TOP_CFG5 0x6E +#define DA7280_IRQ_MASK2 0x83 +#define DA7280_SNP_MEM_99 0xE7 + +/* Register field */ +
