[alsa-devel] [PATCH v4 11/18] input: Add initial support for TWL6040 vibrator
tj at kernel.org
Tue Jun 14 09:31:30 CEST 2011
On Tue, Jun 14, 2011 at 10:17:10AM +0300, Péter Ujfalusi wrote:
> The latency in most cases comes from the fact, that we are running an embedded
> system. Number of peripherals are connected via I2C, these drivers are using
> workqueues to communicate with the IC.
> Since only one device can communicate through I2C at the time. This is
> basically the source of the latency. It does not really matter, if the devices
> are on the same I2C bus or not, it is enough if two work belonging to device,
> which happens to be on the same I2C bus, and the first work in the queue takes
> long time to complete (reading back bigger chunk of info, configuring, etc).
> Even if we could schedule the second work on the other CPU, it will be put
> waiting till the I2C bus is free, so both CPU core has work assigned, the
> first is keeping the I2C bus, the other waits for the I2C bus, and the third
> is waiting to be scheduled (which will be happening, when the first work
> IMHO the tactile feedback (vibra) should have an excuse to have separate WQ to
> avoid latency spikes.
> I agree, that most cases we can use the global wq.
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? If so, how long delay are we talking about?
* 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?
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
More information about the Alsa-devel