Re: [PATCH 3/9] IR: replace spinlock with mutex.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em 28-07-2010 14:43, Jarod Wilson escreveu:
> 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.

You're probably right. The previous code used to do this at IRQ time, but a latter
patch changed it to happen via a workqueue.

So, I'm OK with this patch.

Cheers,
Mauro.


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux