From: "David Härdeman" <david@hardeman.nu>
To: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Jon Smirl <jonsmirl@gmail.com>,
linux-input@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [RFC2] Teach drivers/media/IR/ir-raw-event.c to use durations
Date: Thu, 8 Apr 2010 17:53:17 +0200 [thread overview]
Message-ID: <20100408155317.GA21848@hardeman.nu> (raw)
In-Reply-To: <4BBDD4ED.5040007@infradead.org>
On Thu, Apr 08, 2010 at 10:06:53AM -0300, Mauro Carvalho Chehab wrote:
> Jon Smirl wrote:
> > On Thu, Apr 8, 2010 at 1:10 AM, Mauro Carvalho Chehab
> > <mchehab@infradead.org> wrote:
> >> On the previous code, it is drivers responsibility to call the
> >> function that
> >> de-queue. On saa7134, I've scheduled it to wake after 15 ms. So, instead of
> >> 32 wakeups, just one is done, and the additional delay introduced by it is not
> >> enough to disturb the user.
> >
> > The wakeup is variable when the default thread is used. My quad core
> > desktop wakes up on every pulse. My embedded system wakes up about
> > every 15 pulses. The embedded system called schedule_work() fifteen
> > times from the IRQ, but the kernel collapsed them into a single
> > wakeup. I'd stick with the default thread and let the kernel get
> > around to processing IR whenever it has some time.
>
> Makes sense.
Given Jon's experience, it would perhaps make sense to remove
ir_raw_event_handle() and call schedule_work() from every call to
ir_raw_event_store()?
One thing less for IR drivers to care about...
--
David Härdeman
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: "David Härdeman" <david@hardeman.nu>
To: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Jon Smirl <jonsmirl@gmail.com>,
linux-input@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [RFC2] Teach drivers/media/IR/ir-raw-event.c to use durations
Date: Thu, 8 Apr 2010 17:53:17 +0200 [thread overview]
Message-ID: <20100408155317.GA21848@hardeman.nu> (raw)
In-Reply-To: <4BBDD4ED.5040007@infradead.org>
On Thu, Apr 08, 2010 at 10:06:53AM -0300, Mauro Carvalho Chehab wrote:
> Jon Smirl wrote:
> > On Thu, Apr 8, 2010 at 1:10 AM, Mauro Carvalho Chehab
> > <mchehab@infradead.org> wrote:
> >> On the previous code, it is drivers responsibility to call the
> >> function that
> >> de-queue. On saa7134, I've scheduled it to wake after 15 ms. So, instead of
> >> 32 wakeups, just one is done, and the additional delay introduced by it is not
> >> enough to disturb the user.
> >
> > The wakeup is variable when the default thread is used. My quad core
> > desktop wakes up on every pulse. My embedded system wakes up about
> > every 15 pulses. The embedded system called schedule_work() fifteen
> > times from the IRQ, but the kernel collapsed them into a single
> > wakeup. I'd stick with the default thread and let the kernel get
> > around to processing IR whenever it has some time.
>
> Makes sense.
Given Jon's experience, it would perhaps make sense to remove
ir_raw_event_handle() and call schedule_work() from every call to
ir_raw_event_store()?
One thing less for IR drivers to care about...
--
David Härdeman
next prev parent reply other threads:[~2010-04-08 15:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-07 20:18 [RFC2] Teach drivers/media/IR/ir-raw-event.c to use durations David Härdeman
2010-04-07 20:18 ` David Härdeman
2010-04-07 21:01 ` Jon Smirl
2010-04-08 0:18 ` Jon Smirl
2010-04-08 0:44 ` Andy Walls
2010-04-08 5:10 ` Mauro Carvalho Chehab
2010-04-08 5:10 ` Mauro Carvalho Chehab
2010-04-08 11:23 ` David Härdeman
2010-04-08 11:50 ` Mauro Carvalho Chehab
2010-04-08 12:43 ` David Härdeman
2010-04-08 12:43 ` David Härdeman
2010-04-08 13:07 ` Mauro Carvalho Chehab
2010-04-08 12:41 ` Jon Smirl
2010-04-08 12:41 ` Jon Smirl
2010-04-08 13:06 ` Mauro Carvalho Chehab
2010-04-08 13:06 ` Mauro Carvalho Chehab
2010-04-08 15:53 ` David Härdeman [this message]
2010-04-08 15:53 ` David Härdeman
2010-04-08 17:04 ` Mauro Carvalho Chehab
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=20100408155317.GA21848@hardeman.nu \
--to=david@hardeman.nu \
--cc=jonsmirl@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.