From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Jarod Wilson <jarod@redhat.com>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>,
lirc-list@lists.sourceforge.net,
Jarod Wilson <jarod@wilsonet.com>,
linux-input@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 3/9] IR: replace spinlock with mutex.
Date: Wed, 28 Jul 2010 15:37:28 -0300 [thread overview]
Message-ID: <4C5078E8.5010409@redhat.com> (raw)
In-Reply-To: <20100728174338.GD26480@redhat.com>
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.
next prev parent reply other threads:[~2010-07-28 18:37 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-28 15:14 [PATCH 0/9 v1] IR: few fixes, additions and ENE driver Maxim Levitsky
2010-07-28 15:14 ` [PATCH 1/9] IR: Kconfig fixes Maxim Levitsky
2010-07-28 17:36 ` Randy Dunlap
2010-07-28 20:31 ` Maxim Levitsky
2010-07-28 15:14 ` [PATCH 2/9] IR: minor fixes: Maxim Levitsky
2010-07-28 16:01 ` Mauro Carvalho Chehab
2010-07-28 16:38 ` Maxim Levitsky
2010-07-28 17:59 ` Mauro Carvalho Chehab
2010-07-28 17:23 ` Jarod Wilson
2010-07-28 15:14 ` [PATCH 3/9] IR: replace spinlock with mutex Maxim Levitsky
2010-07-28 16:03 ` Mauro Carvalho Chehab
2010-07-28 16:32 ` Maxim Levitsky
2010-07-28 17:43 ` Jarod Wilson
2010-07-28 18:37 ` Mauro Carvalho Chehab [this message]
2010-07-28 15:14 ` [PATCH 4/9] IR: add helper functions for ir input devices that send ir timing data in small chunks, and alternation between pulses and spaces isn't guaranteed Maxim Levitsky
2010-07-28 16:09 ` Mauro Carvalho Chehab
2010-07-28 16:29 ` Maxim Levitsky
2010-07-28 17:46 ` Jarod Wilson
2010-07-28 20:57 ` Jarod Wilson
2010-07-28 21:16 ` Maxim Levitsky
2010-07-28 15:14 ` [PATCH 5/9] IR: extend interfaces to support more device settings Maxim Levitsky
2010-07-28 17:00 ` Mauro Carvalho Chehab
2010-07-28 20:47 ` Jarod Wilson
2010-07-28 15:14 ` [PATCH 6/9] IR: actually allow not to compile keymaps in Maxim Levitsky
2010-07-28 17:58 ` Jarod Wilson
2010-07-28 15:14 ` [PATCH 7/9] IR: actualy report unknown scancodes the in-kernel decoders found Maxim Levitsky
2010-07-28 15:14 ` [PATCH 8/9] IR: Add ENE input driver Maxim Levitsky
2010-07-28 17:10 ` Mauro Carvalho Chehab
2010-07-28 17:13 ` Maxim Levitsky
2010-07-28 17:17 ` Jarod Wilson
2010-07-28 18:13 ` Mauro Carvalho Chehab
2010-07-28 15:14 ` [PATCH 9/9] STAGING: remove ENE driver Maxim Levitsky
-- strict thread matches above, loose matches on Subject: below --
2010-07-28 23:40 (unknown), Maxim Levitsky
2010-07-28 23:40 ` [PATCH 3/9] IR: replace spinlock with mutex Maxim Levitsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C5078E8.5010409@redhat.com \
--to=mchehab@redhat.com \
--cc=jarod@redhat.com \
--cc=jarod@wilsonet.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lirc-list@lists.sourceforge.net \
--cc=maximlevitsky@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).