Jon Smirl wrote: > On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
