lkml.org 
[lkml]   [2010]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.koskinen@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


\
 
 \ /
  Last update: 2010-10-27 11:01    [W:0.056 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site