On Wed, Jul 28, 2010 at 07:32:58PM +0300, Maxim Levitsky wrote: > On Wed, 2010-07-28 at 13:03 -0300, Mauro Carvalho Chehab wrote: > > Em 28-07-2010 12:14, Maxim Levitsky escreveu: > > > Some handlers (lirc for example) allocates memory on initialization, > > > doing so in atomic context is cumbersome. > > > Fixes warning about sleeping function in atomic context. > > > > You should not replace it by a mutex, as the decoding code may happen during > > IRQ time on several drivers. > I though decoding code is run by a work queue?
Yeah, it is. (INIT_WORK(&ir->raw->rx_work, ir_raw_event_work); in ir_raw_event_register). > I don't see any atomic codepath here... I think the ir_raw_event_store variants are the only things that are run from an interrupt context, and none of them touch ir_raw_handler_lock. That lock is advertised as being for the protection of ir_raw_handler_list and ir_raw_client_list, which are primarily manipulated by register/unregister functions, and we just lock them when doing actual IR decode work (via said work queue) so we don't feed raw IR somewhere that we shouldn't. I think Maxim is correct here, we should be okay with changing this to a mutex, unless I'm missing something else. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
