From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Smirl Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system? Date: Tue, 8 Dec 2009 09:51:20 -0500 Message-ID: <9e4733910912080651s30d600aay4c37f59e60e9c697@mail.gmail.com> References: <20091204220708.GD25669@core.coreip.homeip.net> <20091206065512.GA14651@core.coreip.homeip.net> <4B1B99A5.2080903@redhat.com> <9e4733910912060952h4aad49dake8e8486acb6566bc@mail.gmail.com> <9e4733910912061323x22c618ccyf6edcee5b021cbe3@mail.gmail.com> <4B1D934E.7030103@redhat.com> <4B1E5DA3.7000206@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <4B1E5DA3.7000206@redhat.com> Sender: linux-media-owner@vger.kernel.org To: Mauro Carvalho Chehab Cc: Krzysztof Halasa , Dmitry Torokhov , hermann pitton , Christoph Bartelmus , awalls@radix.net, j@jannau.net, jarod@redhat.com, jarod@wilsonet.com, kraxel@redhat.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, superm1@ubuntu.com List-Id: linux-input@vger.kernel.org On Tue, Dec 8, 2009 at 9:07 AM, Mauro Carvalho Chehab wrote: > Krzysztof Halasa wrote: >> Mauro Carvalho Chehab writes: >> >>>> What is the interface for attaching an in-kernel decoder? >>> IMO, it should use the kfifo for it. However, if we allow both raw = data and >>> in-kernel decoders to read data there, we'll need a spinlock to pro= tect the >>> kfifo. >> >> This may be an option, but I think we should be able to attach proto= col >> decoders in parallel, directly to the IRQ handler. At least with RC-= 5 >> (that's what I personally use) it means reliable decoding, no need f= or >> any timeouts, the code is clean, fast (can be a part of hard IRQ >> handler) and simple. >> >> The decoder needs something like >> =A0 =A0 =A0 rc5_signal_change(ptr, space_or_mark, microseconds). >> >> At least mark->space or space->mark events must be reported. For bet= ter >> reliability, both of them. > > If you use a kfifo to store the event (space_or_mark, timestamp), > the IRQ handler can return immediately, and a separate kernel thread > can do the decode without needing to touch at the IRQ. It also helps = to > have a decoder independent of the kernel driver. The first version of my code ran the decoders from the IRQ. That wasn't a good model for sharing decoders between drivers. So I switched to using a kernel thread. There is also the problem of handing decoded events off up the chain. You can't do that from IRQ context. If I remember correctly the kernel thread would run approximately two times per IR message received. But sometimes it would only run once. It's a random function of the load on the system. The kernel thread empties the FIFO and sends the pulses in parallel to the decoders. Code for doing this is in the patches I posted. I wasn't aware of kfifo when I wrote them so I coded my own fifo. --=20 Jon Smirl jonsmirl@gmail.com