Hi Dmitry, >From: ext Dmitry Torokhov [mailto:dmitry.torokhov@xxxxxxxxx] >Sent: 26 October, 2010 19:10 >To: Koskinen Ilkka (Nokia-MS/Tampere) >Cc: linux-input@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; spi- >devel-general@xxxxxxxxxxxxxxxxxxxxx >Subject: Re: [PATCH] input: spi: Driver for SPI data stream driven >vibrator > >Hi Ilkka, > >On Mon, Oct 25, 2010 at 04:31:02PM +0300, Ilkka Koskinen wrote: >> This driver provides access to drive a vibrator connected >> to SPI data line via Input layer's Force Feedback interface. >> >> Client application provides samples (data streams) to be >> played as CUSTOM_DATA. The samples are stored in driver's >> internal buffers. > >If device is able to do custom waveform can't it also do regular effects >(constant, periodic, etc. Or is custom is actually random and you are >doing something like rumble effect? How about if I told about the vibration device a little? :) The device can only accept analog signal with relatively narrow frequency band. The bit stream consists of n-bit wide words that are interpreted as PWM pulses. PWM pulses are used to generate the desired waveform (close to sine wave). One problem is that wave period needs to be symmetric in order to avoid DC-offset. Therefore, we always have to play complete periods. Another issue is that due to narrow frequency band, we'd like to minimize the gap (or at least keep it quite stable) between waves as that would affect the overall frequency once again. Narrow band also means that the overall mechanics plays a bigger role and probably needs more careful tuning. Due to tuning issues, I'd prefer custom data provided by user space. By that we would avoid compiling kernel unnecessarily. Calculating the waveforms in the driver with help from board specific functions sounds tempting as well, but would it be better approach after all? >> >> The driver is not able to mix the given samples. Instead, it >> remembers the currently played sample and next one to be played. >> > >Why is this driver not using the memoryless FF library (and extends it >to handle FF_CUSTOM effects) but rather reimplements it in the driver >itself? I don't know how I missed this one :( So if FF_CUSTOM is the option to take, it makes sense to move the buffers to the memoryless FF library. >> Signed-off-by: Ilkka Koskinen <ilkka.koskinen@xxxxxxxxx> >> --- >> drivers/input/misc/Kconfig | 5 + >> drivers/input/misc/Makefile | 2 +- >> drivers/input/misc/vibra_spi.c | 429 >++++++++++++++++++++++++++++++++++++++++ >> include/linux/spi/vibra.h | 34 ++++ >> 4 files changed, 469 insertions(+), 1 deletions(-) >> create mode 100644 drivers/input/misc/vibra_spi.c >> create mode 100644 include/linux/spi/vibra.h >> >> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig >> index b49e233..3441832 100644 >> --- a/drivers/input/misc/Kconfig >> +++ b/drivers/input/misc/Kconfig >> @@ -438,4 +438,9 @@ config INPUT_ADXL34X_SPI >> To compile this driver as a module, choose M here: the >> module will be called adxl34x-spi. >> >> +config INPUT_SPI_VIBRA >> + tristate "Support for SPI driven Vibra module" >> + help >> + Support for Vibra module that is connected to OMAP SPI bus. >> + > >"To compile this driver as a module". Also please keep Kconfig and >Makefile sorted alphabetically. I'll fix this. Cheers, Ilkka -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
