Date:	Sat, 10 Apr 2010 02:38:23 +0200
From:	hermann pitton <hermann-pitton@...or.de>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Andy Walls <awalls@...ix.net>,
	Devin Heitmueller <dheitmueller@...nellabs.com>,
	James Hogan <james@...anarts.com>,
	Jon Smirl <jonsmirl@...il.com>, Pavel Machek <pavel@....cz>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	Christoph Bartelmus <lirc@...telmus.de>, j@...nau.net,
	jarod@...hat.com, jarod@...sonet.com, kraxel@...hat.com,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
	IR  system?

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
> >> <mchehab@...hat.com> 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.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists