Hi,
On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote:
> Comments?
I haven't seen this mentioned yet, but are there any plans for a sysfs
interface to set up waking from suspend/standby on a particular IR scancode
(for hardware decoders that support masking of comparing of the IR data), kind
of analagous to the rtc framework's wakealarm sysfs file?
Cheers
James
On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote:
> Hi,
>
> On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote:
> > Comments?
>
> I haven't seen this mentioned yet, but are there any plans for a sysfs
> interface to set up waking from suspend/standby on a particular IR scancode
> (for hardware decoders that support masking of comparing of the IR data), kind
> of analagous to the rtc framework's wakealarm sysfs file?
This requires support at the hardware level. (You can't have CPU code
running to decode IR pulses when your CPU is "asleep".)
I know of two video chips supported under linux that provide such a
function.
Wake-up from IR for these chips will rely on the kernel PCIe or USB
infrastructure supporting PCIe or USB Power Managment Events from
hardware. It will take a huge amount of work and time to get the
respective linux video drivers to properly support suspend/resume
properly.
If you're waiting for me to get that working, I'll advise you to plan on
getting off the couch and pushing the power switch for some time to
come. ;)
The MCE-USB, I *speculate*, can perform wakes. It's driver would need
to support that, if it can.
Regards,
Andy
On Fri, Apr 09, 2010 at 06:50:26AM -0400, Andy Walls wrote:
> On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote:
> > Hi,
> >
> > On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote:
> > > Comments?
> >
> > I haven't seen this mentioned yet, but are there any plans for a sysfs
> > interface to set up waking from suspend/standby on a particular IR scancode
> > (for hardware decoders that support masking of comparing of the IR data), kind
> > of analagous to the rtc framework's wakealarm sysfs file?
>
> This requires support at the hardware level. (You can't have CPU code
> running to decode IR pulses when your CPU is "asleep".)
>
> I know of two video chips supported under linux that provide such a
> function.
>
> Wake-up from IR for these chips will rely on the kernel PCIe or USB
> infrastructure supporting PCIe or USB Power Managment Events from
> hardware. It will take a huge amount of work and time to get the
> respective linux video drivers to properly support suspend/resume
> properly.
>
> If you're waiting for me to get that working, I'll advise you to plan on
> getting off the couch and pushing the power switch for some time to
> come. ;)
>
>
>
>
> The MCE-USB, I *speculate*, can perform wakes. It's driver would need
> to support that, if it can.
Yep, it can perform wakes, and the current lirc_mceusb does support it,
though it requires some screwing around with echoing something into
somewhere in sysfs (for the usb controller its attached to) to enable it,
from what I recall... Making it Just Work would be a good idea.
--
Jarod Wilson
[email protected]
On Fri, Apr 9, 2010 at 8:58 AM, Jarod Wilson <[email protected]> wrote:
> On Fri, Apr 09, 2010 at 06:50:26AM -0400, Andy Walls wrote:
>> On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote:
>> > Hi,
>> >
>> > On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote:
>> > > Comments?
>> >
>> > I haven't seen this mentioned yet, but are there any plans for a sysfs
>> > interface to set up waking from suspend/standby on a particular IR scancode
>> > (for hardware decoders that support masking of comparing of the IR data), kind
>> > of analagous to the rtc framework's wakealarm sysfs file?
>>
>> This requires support at the hardware level. ?(You can't have CPU code
>> running to decode IR pulses when your CPU is "asleep".)
>>
>> I know of two video chips supported under linux that provide such a
>> function.
>>
>> Wake-up from IR for these chips will rely on the kernel PCIe or USB
>> infrastructure supporting PCIe or USB Power Managment Events from
>> hardware. ?It will take a huge amount of work and time to get the
>> respective linux video drivers to properly support suspend/resume
>> properly.
>>
>> If you're waiting for me to get that working, I'll advise you to plan on
>> getting off the couch and pushing the power switch for some time to
>> come. ;)
>>
>>
>>
>>
>> The MCE-USB, I *speculate*, can perform wakes. ?It's driver would need
>> to support that, if it can.
>
> Yep, it can perform wakes, and the current lirc_mceusb does support it,
> though it requires some screwing around with echoing something into
> somewhere in sysfs (for the usb controller its attached to) to enable it,
You probably need to tell the USB system to leave the MSMCE's power
turned on during suspend. Maybe the MSMCE driver can tell the USB
subsystem to leave it powered across suspend when the driver loads.
> from what I recall... Making it Just Work would be a good idea.
>
> --
> Jarod Wilson
> [email protected]
>
>
--
Jon Smirl
[email protected]
Hi James,
Andy Walls wrote:
> On Fri, 2010-04-09 at 08:21 +0100, James Hogan wrote:
>> Hi,
>>
>> On Thursday 25 March 2010 14:42:33 Mauro Carvalho Chehab wrote:
>>> Comments?
>> I haven't seen this mentioned yet, but are there any plans for a sysfs
>> interface to set up waking from suspend/standby on a particular IR scancode
>> (for hardware decoders that support masking of comparing of the IR data), kind
>> of analagous to the rtc framework's wakealarm sysfs file?
>
> This requires support at the hardware level. (You can't have CPU code
> running to decode IR pulses when your CPU is "asleep".)
The additions at IR core, if needed [1], shouldn't be hard, but the main changes should
happen at the hardware driver level. There's no current plans for it, at least from
my side, but, let's see if some hardware driver developers want to implement it on
the corresponding driver.
[1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by
associating some scancode to KEY_POWER via ir-core, the driver can program the hardware
to wake up the machine with the corresponding scancode. I can't see a need for a change at
ir-core to implement such behavior. Of course, some attributes at sysfs can be added
to enable or disable this feature, and to control the associated logic, but we first
need to implement the wakeup feature at the hardware driver, and then adding some logic
at ir-core to add the non-hardware specific code there.
--
Cheers,
Mauro
On Fri, Apr 09, 2010 at 06:50:26AM -0400, Andy Walls wrote:
> If you're waiting for me to get that working, I'll advise you to plan on
> getting off the couch and pushing the power switch for some time to
> come. ;)
:-)
On Friday 09 April 2010 14:01:46 Mauro Carvalho Chehab wrote:
> The additions at IR core, if needed [1], shouldn't be hard, but the main
> changes should happen at the hardware driver level. There's no current
> plans for it, at least from my side, but, let's see if some hardware
> driver developers want to implement it on the corresponding driver.
>
> [1] Basically, a keycode (like KEY_POWER) could be used to wake up the
> machine. So, by associating some scancode to KEY_POWER via ir-core, the
> driver can program the hardware to wake up the machine with the
> corresponding scancode. I can't see a need for a change at ir-core to
> implement such behavior. Of course, some attributes at sysfs can be added
> to enable or disable this feature, and to control the associated logic,
> but we first need to implement the wakeup feature at the hardware driver,
> and then adding some logic at ir-core to add the non-hardware specific
> code there.
Thanks for the info Mauro.
Cheers
James
On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
<[email protected]> wrote:
> [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by
> associating some scancode to KEY_POWER via ir-core, the driver can program the hardware
> to wake up the machine with the corresponding scancode. I can't see a need for a change at
> ir-core to implement such behavior. Of course, some attributes at sysfs can be added
> to enable or disable this feature, and to control the associated logic, but we first
> need to implement the wakeup feature at the hardware driver, and then adding some logic
> at ir-core to add the non-hardware specific code there.
Really? Have you actually seen any hardware where a particular scan
code can be used to wake up the hardware? The only hardware I have
seen has the ability to unsuspend on arrival of IR traffic, but you
didn't have the granularity to dictate that it only wake up on
particular scancodes.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote:
> On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
> <[email protected]> wrote:
> > [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by
> > associating some scancode to KEY_POWER via ir-core, the driver can program the hardware
> > to wake up the machine with the corresponding scancode. I can't see a need for a change at
> > ir-core to implement such behavior. Of course, some attributes at sysfs can be added
> > to enable or disable this feature, and to control the associated logic, but we first
> > need to implement the wakeup feature at the hardware driver, and then adding some logic
> > at ir-core to add the non-hardware specific code there.
>
> Really? Have you actually seen any hardware where a particular scan
> code can be used to wake up the hardware? The only hardware I have
> seen has the ability to unsuspend on arrival of IR traffic, but you
> didn't have the granularity to dictate that it only wake up on
> particular scancodes.
The CX23888 and CX23102 can do it. Basically any IR pulse pattern your
heart desires; within reason. And any carrier freq you want too; within
reason.
But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere
near properly supporing suspend/resume for their main video and DMA
functions, AFAIK.
Regards,
Andy
Andy Walls wrote:
> On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote:
>> On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
>> <[email protected]> wrote:
>>> [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by
>>> associating some scancode to KEY_POWER via ir-core, the driver can program the hardware
>>> to wake up the machine with the corresponding scancode. I can't see a need for a change at
>>> ir-core to implement such behavior. Of course, some attributes at sysfs can be added
>>> to enable or disable this feature, and to control the associated logic, but we first
>>> need to implement the wakeup feature at the hardware driver, and then adding some logic
>>> at ir-core to add the non-hardware specific code there.
>> Really? Have you actually seen any hardware where a particular scan
>> code can be used to wake up the hardware? The only hardware I have
>> seen has the ability to unsuspend on arrival of IR traffic, but you
>> didn't have the granularity to dictate that it only wake up on
>> particular scancodes.
>
> The CX23888 and CX23102 can do it. Basically any IR pulse pattern your
> heart desires; within reason. And any carrier freq you want too; within
> reason.
>
> But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere
> near properly supporing suspend/resume for their main video and DMA
> functions, AFAIK.
AFAIK, only saa7134 have a good suspend/resume code [1]. You may be watching TV,
do a suspend and waking the hardware again, and you'll keep seeing the same
channel (I tested it some time ago, when the proper suspend code were added,
on analog mode, with alsa enabled). Other drivers can suspend/resume, but
they won't properly restore the video registers, so, you'll see artifacts when
it returns.
So, yes, you're right: before any suspend/resume code on those drivers, we
first need to add some code to properly handle kernel threads and work queues
during suspend, and to restore all the registers to a sane state at resume,
before implementing IR wakeup on them.
In the case of mceusb, as there is already an userspace code for it on lirc,
it would probably not be that hard to make this feature to work with ir-core.
[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.
--
Cheers,
Mauro
On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab
<[email protected]> 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.
--
Jon Smirl
[email protected]
Hi!
Am Freitag, den 09.04.2010, 20:32 -0300 schrieb Mauro Carvalho Chehab:
> Andy Walls wrote:
> > On Fri, 2010-04-09 at 17:55 -0400, Devin Heitmueller wrote:
> >> On Fri, Apr 9, 2010 at 9:01 AM, Mauro Carvalho Chehab
> >> <[email protected]> wrote:
> >>> [1] Basically, a keycode (like KEY_POWER) could be used to wake up the machine. So, by
> >>> associating some scancode to KEY_POWER via ir-core, the driver can program the hardware
> >>> to wake up the machine with the corresponding scancode. I can't see a need for a change at
> >>> ir-core to implement such behavior. Of course, some attributes at sysfs can be added
> >>> to enable or disable this feature, and to control the associated logic, but we first
> >>> need to implement the wakeup feature at the hardware driver, and then adding some logic
> >>> at ir-core to add the non-hardware specific code there.
> >> Really? Have you actually seen any hardware where a particular scan
> >> code can be used to wake up the hardware? The only hardware I have
> >> seen has the ability to unsuspend on arrival of IR traffic, but you
> >> didn't have the granularity to dictate that it only wake up on
> >> particular scancodes.
> >
> > The CX23888 and CX23102 can do it. Basically any IR pulse pattern your
> > heart desires; within reason. And any carrier freq you want too; within
> > reason.
> >
> > But let's be real, the cx23885, cx231xx, and cx25840 modules are nowhere
> > near properly supporing suspend/resume for their main video and DMA
> > functions, AFAIK.
>
> AFAIK, only saa7134 have a good suspend/resume code [1]. You may be watching TV,
> do a suspend and waking the hardware again, and you'll keep seeing the same
> channel (I tested it some time ago, when the proper suspend code were added,
> on analog mode, with alsa enabled). Other drivers can suspend/resume, but
> they won't properly restore the video registers, so, you'll see artifacts when
> it returns.
Yes, that was Maxim with enough testers around and Matthias Schwarzott
had fixes.
To remind, we don't recover from suspend on DVB, needs to reload the
driver once. We are also not MFE ready with mixed init calls through v4l
and dvb.
But yes, analog is on leading edge on that ;)
Cheers,
Hermann
> So, yes, you're right: before any suspend/resume code on those drivers, we
> first need to add some code to properly handle kernel threads and work queues
> during suspend, and to restore all the registers to a sane state at resume,
> before implementing IR wakeup on them.
>
> In the case of mceusb, as there is already an userspace code for it on lirc,
> it would probably not be that hard to make this feature to work with ir-core.
>
> [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.
>
Jon Smirl wrote:
> On Fri, Apr 9, 2010 at 7:32 PM, Mauro Carvalho Chehab
> <[email protected]> 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