Re: [PATCH v4 11/18] input: Add initial support for TWL6040 vibrator

["Péter Ujfalusi" <peter.ujfalusi@ti.com>]

On Tuesday 14 June 2011 09:31:30 Tejun Heo wrote:
> Thanks for the explanation.  I have a couple more questions.
> 
> * While transferring data from I2C, I suppose the work item is fully
>   occupying the CPU?

Not exactly on OMAP platforms at least. We do not have busy looping in low 
level driver (we wait with wait_for_completion_timeout for the transfer to be 
done), so scheduling on the same CPU can be possible.

>   If so, how long delay are we talking about?
>   Millisecs?

It is hard to predict, but it can be few tens of ms for one device, if we have 
several devices on the same bus (which we tend to have), and they want to 
read/write something at the same time we can see hundred(s) ms in total - it 
is rare to happen, and hard to reproduce, but it does happen for sure.
 
> * You said that the if one task is accessing I2C bus, the other would
>   wait even if scheduled on a different CPU.  Is access to I2C bus
>   protected with a spinlock?

At the bottom it is using rt_mutex_lock/unlick to protect the bus.
And yes, the others need to wait till the ongoing transfer has been finished.
 
> Also, as it's currently implemented, single threaded wq's effectively
> bypass concurrency level control.  This is an implementation detail
> which may change in the future, so even if you're seeing lower latency
> by using a separate single threaded wq, it's an accident and if you
> require lower latency you should be expressing the requirement
> explicitly.

I see, do you have suggestion to which would be best for this kind of 
scenarios.
In most cases global wq would be OK for this, but time-to-time we face with 
sudden latency spikes, which makes the user experience really bad.
Currently with singlethreaded wq we can avoid these spikes.

Thank you, 
Péter