Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 09 Apr 2010 22:01:18 -0300 | From | Mauro Carvalho Chehab <> | Subject | Re: [RFC] What are the goals for the architecture of an in-kernel IR system? |
| |
Jon Smirl wrote: > On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab > <mchehab@redhat.com> 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
| ![\](/images/icornerr.gif) |