[SPAM] Votre complementaire sante a partir de 0,65 euro par jour
-- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] input: spi: Driver for SPI data stream driven vibrator
On Tue, Oct 26, 2010 at 06:50:33PM +0200, ilkka.koski...@nokia.com wrote:
Hi Grant and thanks for comments,
[...]
+static int vibra_spi_playback(struct input_dev *input, int effect_id,
int value)
+{
+struct vibra_data *vibra = input_get_drvdata(input);
+struct effect_info *einfo = vibra-effects[effect_id];
+struct ff_effect *ff_effect = input-ff-effects[effect_id];
+
+if (!vibra-workqueue)
+return -ENODEV;
+
+if (test_bit(FF_EFFECT_UPLOADING, einfo-flags))
+return -EBUSY;
+
+if (value == 0) {
+/* Abort the given effect */
+if (test_bit(FF_EFFECT_PLAYING, einfo-flags))
+__set_bit(FF_EFFECT_ABORTING, einfo-flags);
+
+__clear_bit(FF_EFFECT_QUEUED, einfo-flags);
+} else {
+/* Move the given effect as the next one */
+__clear_bit(FF_EFFECT_QUEUED,
+vibra-effects[vibra-next_effect].flags);
+
+vibra-next_effect = effect_id;
+__set_bit(FF_EFFECT_QUEUED, einfo-flags);
+__clear_bit(FF_EFFECT_ABORTING, einfo-flags);
+einfo-stop_at = jiffies +
+msecs_to_jiffies(ff_effect-replay.length);
+
+if (vibra-status == IDLE) {
+vibra-status = STARTED;
+queue_work(vibra-workqueue, vibra-play_work);
+}
+}
I can't speak anything about the input event handling because I'm not
very familiar with it. However, it looks like the shared effect data
(vibra-effects) is getting modified outside of a critical region. Is
this safe?
Hmmm, I don't know why the force feedback layer is using a spin lock,
but it looks like overkill. Since you're already deferring work, I
would look at queueing the request and pushing down the spin lock
exposure as much as possible, but I'm really not the expert on the
input layer.
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] input: spi: Driver for SPI data stream driven vibrator
On Wed, Oct 27, 2010 at 09:47:30AM +0100, Grant Likely wrote:
On Tue, Oct 26, 2010 at 06:50:33PM +0200, ilkka.koski...@nokia.com wrote:
Hi Grant and thanks for comments,
[...]
+static int vibra_spi_playback(struct input_dev *input, int effect_id,
int value)
+{
+struct vibra_data *vibra = input_get_drvdata(input);
+struct effect_info *einfo = vibra-effects[effect_id];
+struct ff_effect *ff_effect = input-ff-effects[effect_id];
+
+if (!vibra-workqueue)
+return -ENODEV;
+
+if (test_bit(FF_EFFECT_UPLOADING, einfo-flags))
+return -EBUSY;
+
+if (value == 0) {
+/* Abort the given effect */
+if (test_bit(FF_EFFECT_PLAYING, einfo-flags))
+__set_bit(FF_EFFECT_ABORTING, einfo-flags);
+
+__clear_bit(FF_EFFECT_QUEUED, einfo-flags);
+} else {
+/* Move the given effect as the next one */
+__clear_bit(FF_EFFECT_QUEUED,
+vibra-effects[vibra-next_effect].flags);
+
+vibra-next_effect = effect_id;
+__set_bit(FF_EFFECT_QUEUED, einfo-flags);
+__clear_bit(FF_EFFECT_ABORTING, einfo-flags);
+einfo-stop_at = jiffies +
+msecs_to_jiffies(ff_effect-replay.length);
+
+if (vibra-status == IDLE) {
+vibra-status = STARTED;
+queue_work(vibra-workqueue, vibra-play_work);
+}
+}
I can't speak anything about the input event handling because I'm not
very familiar with it. However, it looks like the shared effect data
(vibra-effects) is getting modified outside of a critical region. Is
this safe?
Hmmm, I don't know why the force feedback layer is using a spin lock,
but it looks like overkill. Since you're already deferring work, I
would look at queueing the request and pushing down the spin lock
exposure as much as possible, but I'm really not the expert on the
input layer.
Events are often sent from IRQ context so input core has to use spinlocks to
protect its internal data structures. Since output events travel the
same data path the event handlers are also called in atomic context.
--
Dmitry
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] input: spi: Driver for SPI data stream driven vibrator
The driver could, of course, calculate the bit streams with help of board specific functions. It was just thought that tuning vibration device would be a lot easier, if we could just modify the bit streams provided by user space application. In fact, the bit stream basically consists of series of PWM pulses that are fed to the vibra. Perhaps, calculating the waveforms in the driver at probe time would be the most natural choice :\ Or assuming its a trivial conversion accepting them in a standard format and doing a quick pass across them ? (and failing that adding and documenting the format..) -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
RE: [PATCH] input: spi: Driver for SPI data stream driven vibrator
Hi Dmitry, From: ext Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] Sent: 26 October, 2010 19:10 To: Koskinen Ilkka (Nokia-MS/Tampere) Cc: linux-in...@vger.kernel.org; linux-ker...@vger.kernel.org; spi- devel-gene...@lists.sourceforge.net 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.koski...@nokia.com --- 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 -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
