From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mauro Carvalho Chehab Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system? Date: Fri, 09 Apr 2010 22:01:18 -0300 Message-ID: <4BBFCDDE.7050405@redhat.com> References: <9e4733910912060952h4aad49dake8e8486acb6566bc@mail.gmail.com> <9e4733910912151338n62b30af5i35f8d0963e6591c@mail.gmail.com> <4BAB7659.1040408@redhat.com> <201004090821.10435.james@albanarts.com> <1270810226.3764.34.camel@palomino.walls.org> <4BBF253A.8030406@redhat.com> <1270851240.3038.51.camel@palomino.walls.org> <4BBFB925.7080606@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:20411 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751135Ab0DJBCh (ORCPT ); Fri, 9 Apr 2010 21:02:37 -0400 In-Reply-To: Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Jon Smirl Cc: Andy Walls , Devin Heitmueller , James Hogan , Pavel Machek , Dmitry Torokhov , Krzysztof Halasa , hermann pitton , Christoph Bartelmus , 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 Jon Smirl wrote: > On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab > wrote: > >> [1] Yet, none of the in-hardware decoders allow resume, AFAIK. With a software >> decoder, the IR IRQ might be used to wake, but this means that everything, >> even a glitch, would wake the hardware, so this won't work neither. > > On my embedded hardware there is 100KB of static RAM on the CPU die. > It is preserved even in deep sleep. An IR pulse can wake the CPU and > run code in this 100KB RAM. Then the CPU can decide whether it wants > to power on main RAM and restore the OS. But implementing this is > outside the scope of the Linux kernel. > > In someways this is how an MSMCE behaves in suspend. There is code > running on the MCU inside the MSMCE receiver. Too bad we can't tell it > a pattern to watch for and then trigger USB wake up. It is easy to > build a MSMCE clone, maybe someone will clone it and add the wakeup > pattern match. An enterprising hacker can probably change the firmware > in the existing devices. Waking up the entire hardware just because an IRQ was triggered doesn't seem a good idea on PC's. Here, I had to put the IR sensors behind the table to avoid receiving too many noise from my room's lamp. If I put it on the right place, I start receiving several of glitches per second. I doubt this would be useful for suspend/resume operations. -- Cheers, Mauro