Thread (64 messages) 64 messages, 12 authors, 2010-04-10

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

From: Mauro Carvalho Chehab <hidden>
Date: 2010-04-10 01:02:44
Also in: linux-input, linux-media

Possibly related (same subject, not in this thread)

Jon Smirl wrote:
On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab
[off-list ref] wrote:
quoted
[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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help