Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754793AbZLCUyz (ORCPT ); Thu, 3 Dec 2009 15:54:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753892AbZLCUyy (ORCPT ); Thu, 3 Dec 2009 15:54:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58659 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751575AbZLCUyx (ORCPT ); Thu, 3 Dec 2009 15:54:53 -0500 Message-ID: <4B182584.9090105@redhat.com> Date: Thu, 03 Dec 2009 18:54:28 -0200 From: Mauro Carvalho Chehab User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: Krzysztof Halasa CC: Jon Smirl , Jarod Wilson , Dmitry Torokhov , Jarod Wilson , Devin Heitmueller , Maxim Levitsky , awalls@radix.net, j@jannau.net, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, lirc-list@lists.sourceforge.net, superm1@ubuntu.com, Christoph Bartelmus Subject: Re: [RFC v2] Another approach to IR References: <4B155288.1060509@redhat.com> <20091202093803.GA8656@core.coreip.homeip.net> <4B16614A.3000208@redhat.com> <20091202171059.GC17839@core.coreip.homeip.net> <9e4733910912020930t3c9fe973k16fd353e916531a4@mail.gmail.com> <4B16BE6A.7000601@redhat.com> <20091202195634.GB22689@core.coreip.homeip.net> <2D11378A-041C-4B56-91FF-3E62F5F19753@wilsonet.com> <9e4733910912021620s7a2b09a8v88dd45eef38835a@mail.gmail.com> <4B1720E6.3000802@redhat.com> <9e4733910912022108j71d0c27fh75dacfa79dca7c22@mail.gmail.com> <4B179C5A.2090504@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2278 Lines: 57 Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > >> Btw, looking at that code, while it is not impossible to split the >> IR pulse/space measures from the NEC decoder itself, and make it generic >> to support other protocols, it is not a trivial task, and may result on >> a less stable driver. > > And it's not needed at all. > Protocol decoders can be easily run in parallel, I've done it on saa713x > and this is trivial at least there. Can do that when the lirc interface > is available. >> The advantage of the NEC decoding approach on saa7134 is that you know for >> sure how much time it is required to get the entire code. So, the code >> can easily abort the reception of a bad code. The disadvantage is that >> only one protocol can be decoded at the same time. > > This isn't a hard thing to fix. Good to know. We're open to patches to improve it. The point is that we've got in the past several complains about saa713x machines hanging due to IRQ's generated by IR sensor port. We ended by adding an option to disable IR and a code at the driver that disables IR IRQ if it happens too often. > >> The same problem also happens with almost all in-kernel drivers: the decoders >> for raw mode were constructed to work with just one pulse/space code at the >> same time. A conversion into a generic code can happen, but it will require >> several tests to be sure that they won't cause undesirable side-effects. > > IOW any such receiver has to be tested, sure. > >> The advantage of hardware decoders is that you don't need to be polling the >> IR serial port at a high rate, as you'll get directly the code. So, you'll >> free the CPU to do something else. > > Which device requires polling the port? > Most are IRQ-driven, aren't they? Most of the devices that have a hardware IR decodes needs polling. Most of they simply outputs the scan code on some set of GPIO pins. In general, the devices with the IR sensor connected to a GPIO pin are IRQ-driven. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/