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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
