Re: linux-next: workqueues tree build failure

[Peter Ujfalusi <peter.ujfalusi@nokia.com>]

Hello,

On Friday 27 November 2009 10:42:27 ext Tejun Heo wrote:
> Hello,
> 
> 11/27/2009 05:37 PM, Takashi Iwai wrote:
> >> Sounds like it should be using bottom half tasklet not workqueue.
> >> Tasklet is exactly designed to handle situations like this.  Is there
> >> any reason tasklet can't be used?
> >
> > Right now the h/w accessing code is using mutex.  I'm not sure whether
> > the deeper part might sleep, though...
> 
> Ah... I see.  Using mutex from a handler where response time is
> critical is strange tho.  Anyways, I don't really think singlethread
> will satisfy the timing requirement under loaded conditions.  IMHO,
> update locking and using tasklets would be the best.

Hmmm, yes, I'm aware that it might be not sufficient to use the singlethread wq, 
but that was the fastest fix that I could think of, and it was needed for the 
linux-next.
In case of the tlv320dac33 driver, I can also play with the codec as well to 
adjust the required latency, but if I hit the wall, than for sure I will look 
for another solution for the problem.
So far this is working for my development needs, but time will tell if I need to 
make bigger modifications.

For the record: on OMAP platforms the I2C implementation is sleeping during the 
transfer (internally using interrupt based transfer), which might be not that 
wise in the tasklet. Since the I2C bus is kind of a slow bus, this could take 
several ms in some cases.

Thank you,
Péter