Re: [PATCH 2/4] mx2_camera: return IRQ_NONE when doing nothing
On Tue, Jul 27, 2010 at 03:06:08PM +0300, Baruch Siach wrote: Signed-off-by: Baruch Siach bar...@tkos.co.il --- drivers/media/video/mx2_camera.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c index 1536bd4..b42ad8d 100644 --- a/drivers/media/video/mx2_camera.c +++ b/drivers/media/video/mx2_camera.c @@ -420,15 +420,17 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void *data) struct mx2_camera_dev *pcdev = data; u32 status = readl(pcdev-base_csi + CSISR); - if (status CSISR_DMA_TSF_FB1_INT) + writel(status, pcdev-base_csi + CSISR); + + if (!(status (CSISR_DMA_TSF_FB1_INT | CSISR_DMA_TSF_FB2_INT))) + return IRQ_NONE; I'm not sure this is correct. When we get here, the interrupt definitely is from the camera, it's not a shared interrupt. So this only provokes a 'nobody cared' message from the kernel (if it's still present, I don't know). Sascha + else if (status CSISR_DMA_TSF_FB1_INT) mx25_camera_frame_done(pcdev, 1, VIDEOBUF_DONE); else if (status CSISR_DMA_TSF_FB2_INT) mx25_camera_frame_done(pcdev, 2, VIDEOBUF_DONE); /* FIXME: handle CSISR_RFF_OR_INT */ - writel(status, pcdev-base_csi + CSISR); - return IRQ_HANDLED; } -- 1.7.1 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/4] mm: cma: Contiguous Memory Allocator added
+static inline dma_addr_t __must_check
+cma_alloc(const struct device *dev, const char *kind,
+ size_t size, dma_addr_t alignment)
+{
+ return dev ? -EINVAL : __cma_alloc(dev, kind, size, alignment);
On Tue, 27 Jul 2010 14:08:41 +0200, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
So I can't use this to allocate memory for anything but a NULL device?
+static inline int
+cma_info(struct cma_info *info, const struct device *dev, const char *kind)
+{
+ return dev ? -EINVAL : __cma_info(info, dev, kind);
This won't return information for anything but a NULL device?
Obviously a bug. Thanks for spotting that.
--
Best regards,_ _
| Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o
| Computer Science, Michał mina86 Nazarewicz (o o)
+[mina86*mina86.com]---[mina86*jabber.org]ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2 2/4] mm: cma: Contiguous Memory Allocator added
Hello, On Tuesday, July 27, 2010 6:27 PM Hans Verkuil wrote: On Tuesday 27 July 2010 09:41:40 Marek Szyprowski wrote: On Monday, July 26, 2010 10:29 PM Hans Verkuil wrote: On Monday 26 July 2010 16:40:30 Michal Nazarewicz wrote: The Contiguous Memory Allocator framework is a set of APIs for allocating physically contiguous chunks of memory. Various chips require contiguous blocks of memory to operate. Those chips include devices such as cameras, hardware video decoders and encoders, etc. The code is highly modular and customisable to suit the needs of various users. Set of regions reserved for CMA can be configured on run-time and it is easy to add custom allocator algorithms if one has such need. For more details see Documentation/contiguous-memory.txt. Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Pawel Osciak p.osc...@samsung.com --- Documentation/00-INDEX |2 + .../ABI/testing/sysfs-kernel-mm-contiguous |9 + Documentation/contiguous-memory.txt| 646 +++ Documentation/kernel-parameters.txt|4 + include/linux/cma.h| 445 mm/Kconfig | 34 + mm/Makefile|3 + mm/cma-best-fit.c | 407 +++ mm/cma.c | 1170 9 files changed, 2720 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-kernel-mm- contiguous create mode 100644 Documentation/contiguous-memory.txt create mode 100644 include/linux/cma.h create mode 100644 mm/cma-best-fit.c create mode 100644 mm/cma.c diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 5405f7a..bb50209 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -94,6 +94,8 @@ connector/ - docs on the netlink based userspace-kernel space communication mod. console/ - documentation on Linux console drivers. +contiguous-memory.txt + - documentation on physically-contiguous memory allocation framework. cpu-freq/ - info on CPU frequency and voltage scaling. cpu-hotplug.txt diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-contiguous b/Documentation/ABI/testing/sysfs-kernel-mm-contiguous new file mode 100644 index 000..05e2f6a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-mm-contiguous @@ -0,0 +1,9 @@ +What: /sys/kernel/mm/contiguous/ +Date: July 2008 +Contact: Michal Nazarewicz m.nazarew...@samsung.com +Description: + /sys/kernel/mm/contiguous/ contains two files: asterisk and + map. They are used to configure the Contiguous Memory + Allocator framework. + + For details see Documentation/contiguous-memory.txt. diff --git a/Documentation/contiguous-memory.txt b/Documentation/contiguous-memory.txt new file mode 100644 index 000..6eb1295 --- /dev/null +++ b/Documentation/contiguous-memory.txt @@ -0,0 +1,646 @@ + -*- org -*- + +* Contiguous Memory Allocator + + The Contiguous Memory Allocator (CMA) is a framework, which allows + setting up a machine-specific configuration for physically- contiguous + memory management. Memory for devices is then allocated according + to that configuration. + + The main role of the framework is not to allocate memory, but to + parse and manage memory configurations, as well as to act as an + in-between between device drivers and pluggable allocators. It is + thus not tied to any memory allocation method or strategy. + +** Why is it needed? + +Various devices on embedded systems have no scatter-getter and/or +IO map support and as such require contiguous blocks of memory to +operate. They include devices such as cameras, hardware video +decoders and encoders, etc. + +Such devices often require big memory buffers (a full HD frame is, +for instance, more then 2 mega pixels large, i.e. more than 6 MB +of memory), which makes mechanisms such as kmalloc() ineffective. + +Some embedded devices impose additional requirements on the +buffers, e.g. they can operate only on buffers allocated in +particular location/memory bank (if system has more than one +memory bank) or buffers aligned to a particular memory boundary. + +Development of
[PATCH] V4L/DVB: tvp7002: fix write to H-PLL Feedback Divider LSB register
H-PLL Feedback Divider LSB register is an 8 bit register out
of which the first 4 bits are reserved. Current code is
writing to these reserved location. This patch corrects
this issue by left shifting the values being written to the
register by 4.
This patch has been tested on DM6467 EVM with 720P-60 and
1080I-60 inputs.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
drivers/media/video/tvp7002.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
index 8085ac3..48f5c76 100644
--- a/drivers/media/video/tvp7002.c
+++ b/drivers/media/video/tvp7002.c
@@ -179,7 +179,7 @@ static const struct i2c_reg_value tvp7002_init_default[] = {
/* Register parameters for 480P */
static const struct i2c_reg_value tvp7002_parms_480P[] = {
{ TVP7002_HPLL_FDBK_DIV_MSBS, 0x35, TVP7002_WRITE },
- { TVP7002_HPLL_FDBK_DIV_LSBS, 0x0a, TVP7002_WRITE },
+ { TVP7002_HPLL_FDBK_DIV_LSBS, 0xa0, TVP7002_WRITE },
{ TVP7002_HPLL_CRTL, 0x02, TVP7002_WRITE },
{ TVP7002_HPLL_PHASE_SEL, 0x14, TVP7002_WRITE },
{ TVP7002_AVID_START_PIXEL_LSBS, 0x91, TVP7002_WRITE },
@@ -223,7 +223,7 @@ static const struct i2c_reg_value tvp7002_parms_576P[] = {
/* Register parameters for 1080I60 */
static const struct i2c_reg_value tvp7002_parms_1080I60[] = {
{ TVP7002_HPLL_FDBK_DIV_MSBS, 0x89, TVP7002_WRITE },
- { TVP7002_HPLL_FDBK_DIV_LSBS, 0x08, TVP7002_WRITE },
+ { TVP7002_HPLL_FDBK_DIV_LSBS, 0x80, TVP7002_WRITE },
{ TVP7002_HPLL_CRTL, 0x98, TVP7002_WRITE },
{ TVP7002_HPLL_PHASE_SEL, 0x14, TVP7002_WRITE },
{ TVP7002_AVID_START_PIXEL_LSBS, 0x06, TVP7002_WRITE },
@@ -245,7 +245,7 @@ static const struct i2c_reg_value tvp7002_parms_1080I60[] =
{
/* Register parameters for 1080P60 */
static const struct i2c_reg_value tvp7002_parms_1080P60[] = {
{ TVP7002_HPLL_FDBK_DIV_MSBS, 0x89, TVP7002_WRITE },
- { TVP7002_HPLL_FDBK_DIV_LSBS, 0x08, TVP7002_WRITE },
+ { TVP7002_HPLL_FDBK_DIV_LSBS, 0x80, TVP7002_WRITE },
{ TVP7002_HPLL_CRTL, 0xE0, TVP7002_WRITE },
{ TVP7002_HPLL_PHASE_SEL, 0x14, TVP7002_WRITE },
{ TVP7002_AVID_START_PIXEL_LSBS, 0x06, TVP7002_WRITE },
@@ -289,7 +289,7 @@ static const struct i2c_reg_value tvp7002_parms_1080I50[] =
{
/* Register parameters for 720P60 */
static const struct i2c_reg_value tvp7002_parms_720P60[] = {
{ TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
- { TVP7002_HPLL_FDBK_DIV_LSBS, 0x02, TVP7002_WRITE },
+ { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
{ TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
{ TVP7002_HPLL_PHASE_SEL, 0x16, TVP7002_WRITE },
{ TVP7002_AVID_START_PIXEL_LSBS, 0x47, TVP7002_WRITE },
@@ -311,7 +311,7 @@ static const struct i2c_reg_value tvp7002_parms_720P60[] = {
/* Register parameters for 720P50 */
static const struct i2c_reg_value tvp7002_parms_720P50[] = {
{ TVP7002_HPLL_FDBK_DIV_MSBS, 0x7b, TVP7002_WRITE },
- { TVP7002_HPLL_FDBK_DIV_LSBS, 0x0c, TVP7002_WRITE },
+ { TVP7002_HPLL_FDBK_DIV_LSBS, 0xc0, TVP7002_WRITE },
{ TVP7002_HPLL_CRTL, 0x98, TVP7002_WRITE },
{ TVP7002_HPLL_PHASE_SEL, 0x16, TVP7002_WRITE },
{ TVP7002_AVID_START_PIXEL_LSBS, 0x47, TVP7002_WRITE },
--
1.5.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]videobuf_dma_sg: a new implementation for mmap
Hi,
On Tuesday 27 July 2010 14:21:40 Figo.zhang wrote:
a mmap issue for videobuf-dma-sg: it will alloc a new page for mmaping
when it encounter page fault at video_vm_ops-fault().
a new implementation for mmap, it translate the vmalloc to page at
video_vm_ops-fault().
How is that supposed to work ? mem-dma.vmalloc is NULL in the vm_fault
handler for V4L2_MEMORY_MMAP buffers. Have you tested the code at all ?
Signed-off-by: Figo.zhang figo1...@gmail.com
---
drivers/media/video/videobuf-dma-sg.c | 38
1 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index 8359e6b..c9a8817 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -397,16 +397,44 @@ static void videobuf_vm_close(struct
vm_area_struct *vma)
*/
static int videobuf_vm_fault(struct vm_area_struct *vma, struct
vm_fault *vmf)
{
- struct page *page;
+ struct page *page = NULL;
+ struct videobuf_mapping *map = vma-vm_private_data;
+ struct videobuf_queue *q = map-q;
+ struct videobuf_dma_sg_memory *mem = NULL;
+
+ unsigned long offset;
+ unsigned long page_nr;
+ int first;
dprintk(3, fault: fault @ %08lx [vma %08lx-%08lx]\n,
(unsigned long)vmf-virtual_address,
vma-vm_start, vma-vm_end);
- page = alloc_page(GFP_USER | __GFP_DMA32);
- if (!page)
- return VM_FAULT_OOM;
- clear_user_highpage(page, (unsigned long)vmf-virtual_address);
+ mutex_lock(q-vb_lock);
+
+ offset = (unsigned long)vmf-virtual_address - vma-vm_start;
+ page_nr = offset PAGE_SHIFT;
+
+ for (first = 0; first VIDEO_MAX_FRAME; first++) {
+ if (NULL == q-bufs[first])
+ continue;
+
+ MAGIC_CHECK(mem-magic, MAGIC_SG_MEM);
+
+ if (q-bufs[first]-map == map)
+ break;
+ }
+
+ mem = q-bufs[first]-priv;
+ if (!mem)
+ return VM_FAULT_SIGBUS;
+ if (mem-dma.vmalloc)
+ page = vmalloc_to_page(mem-dma.vmalloc+
+ (offset (~PAGE_MASK)));
+ if (mem-dma.pages)
+ page = mem-dma.pages[page_nr];
+ mutex_unlock(q-vb_lock);
+
vmf-page = page;
return 0;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
JPEG hw decoder
Hi , My board has a hardware JPEG decoder. I want to write a driver for this in Linux kernel, But it seems there that no Framework exists in kernel. Can somebody provide me some pointers? Can V4l2 be used? Thanks in advance. Regards, Rbairva -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: JPEG hw decoder
Hi, rd bairva wrote: My board has a hardware JPEG decoder. I want to write a driver for this in Linux kernel, But it seems there that no Framework exists in kernel. Can somebody provide me some pointers? Can V4l2 be used? Thanks in advance. please take a look at the mem2mem (memory-to-memory) framework, it has been designed just for such hardware, i.e. hardware that takes a source buffer, processes the data and returns the result in another buffer. You can find a short introduction in an LWN article at: http://lwn.net/Articles/389081/ More info in the original threads: http://www.spinics.net/lists/linux-media/msg14063.html http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/10668 Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote: On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl jonsm...@gmail.com wrote: On Tue, Jul 27, 2010 at 7:32 PM, Maxim Levitsky maximlevit...@gmail.com wrote: On Wed, 2010-07-28 at 01:33 +0300, Maxim Levitsky wrote: Hi, I ported my ene driver to in-kernel decoding. It isn't yet ready to be released, but in few days it will be. Now, knowing about wonders of in-kernel decoding, I try to use it, but it just doesn't work. Mind you that lircd works with this remote. (I attach my lircd.conf) Here is the output of mode2 for a single keypress: 8850 4350 525 1575 525 1575 525 450 525 450 525 450 525 450 525 1575 525 450 525 1575 525 450 525 1575 525 450 525 450 525 1575 525 450 525 450 525 23625 That decodes as: 1100 0010 1010 0100 In the NEC protocol the second word is supposed to be the inverse of the first word and it isn't. The timing is too short for NEC protocol too. No its not, its just extended NEC. http://www.sbprojects.com/knowledge/ir/nec.htm Says the last two bytes should be the complement of each other. So for extended NEC it would need to be: 1100 0010 1010 0101 instead of 1100 0010 1010 0100 The last bit is wrong. From the debug output it is decoding as NEC, but then it fails a consistency check. Maybe we need to add a new protocol that lets NEC commands through even if they fail the error checks. It may also be that the NEC machine rejected it because the timing was so far off that it concluded that it couldn't be a NEC messages. The log didn't include the exact reason it got rejected. Add some printks at the end of the NEC machine to determine the exact reason for rejection. The current state machines enforce protocol compliance so there are probably a lot of older remotes that won't decode right. We can use some help in adjusting the state machines to let out of spec codes through. The timing of those pulses is exactly right for JVC. Maybe there is an extended 4 byte version of the JVC protocol. JVC doesn't have the error checks like NEC. The question here is, why didn't the JVC machine get started? User space lirc is much older. Bugs like this have been worked out of it. It will take some time to get the kernel implementation up to the same level. This lirc generic config matches that output quite well: NEC-short-pulse.conf: begin remote name NEC bits 16 flags SPACE_ENC|CONST_LENGTH eps 30 aeps 100 header 9000 4500 one 563 1687 zero 563 562 ptrail 563 pre_data_bits 16 # just a guess gap 108000 repeat 9000 2250 frequency 38000 duty_cycle 33 begin codes end codes end remote Valid NEC... 1100 0011 1010 0101 Maybe JVC protocol but it is longer than normal. The JVC decoder was unable to get started decoding it. I don't think the JVC decoder has been tested much. Take a look at it and see why it couldn't get out of state 0. Personally, I haven't really tried much of anything but RC-6(A) and RC-5 while working on mceusb, so they're the only ones I can really vouch for myself at the moment. It seems that I don't have many remotes that aren't an RC-x variant, outside of universals, which I have yet to get around to programming for various other modes to test any of the protocol decoders. I assume that David Hardeman already did that much before submitting each of the ir protocol decoders with his name one them (which were, if I'm not mistaken, based at least partially on Jon's earlier work), but its entirely possible there are slight variants of each that aren't handled properly just yet. That right there is one of the major reasons I saw for writing the lirc bridge driver plugin in the first place -- the lirc userspace decoder has been around for a LOT longer, and thus is likely to know how to handle more widely varying IR signals. In fact its dead easy to test a lot of remotes, by using an universal remote. These remotes are designed to tech literate persons for a reason On my remote, all I have to do is press TV + predefined number + OK to make remote mimic a random remote. Unill now, kernel decoding couldn't pick anything but one mode Here is a table I created long ago on my remote showing all kinds of protocols there: Heck, hardware isn't very accurate, I know, but streamzap receiver according to what I have heard it even worse... Best regards, Maxim Levitsky 08 - NEC short pulse / SANYO (38 khz), [15 - NEC] 9440 4640 620 550 620 550 620 550 620 550 620 550 620 550 620
Re: [PATCH 2/4] mx2_camera: return IRQ_NONE when doing nothing
A general comment to your patches: the actual driver is going to be merged via the ARM tree, all other your incremental patches should rather go via the v4l tree. So, we'll have to synchronise with ARM, let's hope ARM patches go in early enough. On Tue, 27 Jul 2010, Baruch Siach wrote: Signed-off-by: Baruch Siach bar...@tkos.co.il --- drivers/media/video/mx2_camera.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c index 1536bd4..b42ad8d 100644 --- a/drivers/media/video/mx2_camera.c +++ b/drivers/media/video/mx2_camera.c @@ -420,15 +420,17 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void *data) struct mx2_camera_dev *pcdev = data; u32 status = readl(pcdev-base_csi + CSISR); - if (status CSISR_DMA_TSF_FB1_INT) + writel(status, pcdev-base_csi + CSISR); + + if (!(status (CSISR_DMA_TSF_FB1_INT | CSISR_DMA_TSF_FB2_INT))) + return IRQ_NONE; + else if (status CSISR_DMA_TSF_FB1_INT) mx25_camera_frame_done(pcdev, 1, VIDEOBUF_DONE); else if (status CSISR_DMA_TSF_FB2_INT) mx25_camera_frame_done(pcdev, 2, VIDEOBUF_DONE); /* FIXME: handle CSISR_RFF_OR_INT */ - writel(status, pcdev-base_csi + CSISR); - return IRQ_HANDLED; } I don't think this is correct. You should return IRQ_NONE if this is not an interrupt from your device at all. In this case you don't have to ack your interrupts, which, I presume, is what the write to CSISR is doing. OTOH, if this is an interrupt from your device, but you're just not interested in it, you should ack it and return IRQ_HANDLED. So, the original behaviour was more correct, than what this your patch is doing. The only improvement I can think of is, that you can return IRQ_NONE if status is 0, but then you don't have to ack it. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2]videobuf_dma_sg: a new implementation for mmap
a mmap issue for videobuf-dma-sg: it will alloc a new page for mmaping
when it encounter page fault at video_vm_ops-fault().
a new implementation for mmap, it translate the vmalloc to page at
video_vm_ops-fault().
in v2, if mem-dma.vmalloc is NULL at video_vm_ops-fault(), it will
alloc memory by vmalloc_32().
Signed-off-by: Figo.zhang figo1...@gmail.com
---
drivers/media/video/videobuf-dma-sg.c | 51
+++--
1 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index 8359e6b..767483d 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -201,10 +201,11 @@ int videobuf_dma_init_kernel(struct
videobuf_dmabuf *dma, int direction,
dprintk(1, init kernel [%d pages]\n, nr_pages);
dma-direction = direction;
- dma-vmalloc = vmalloc_32(nr_pages PAGE_SHIFT);
- if (NULL == dma-vmalloc) {
- dprintk(1, vmalloc_32(%d pages) failed\n, nr_pages);
- return -ENOMEM;
+ if (!dma-vmalloc)
+ dma-vmalloc = vmalloc_32(nr_pages PAGE_SHIFT);
+ if (NULL == dma-vmalloc) {
+ dprintk(1, vmalloc_32(%d pages) failed\n, nr_pages);
+ return -ENOMEM;
}
dprintk(1, vmalloc is at addr 0x%08lx, size=%d\n,
@@ -397,16 +398,48 @@ static void videobuf_vm_close(struct
vm_area_struct *vma)
*/
static int videobuf_vm_fault(struct vm_area_struct *vma, struct
vm_fault *vmf)
{
- struct page *page;
+ struct page *page = NULL;
+ struct videobuf_mapping *map = vma-vm_private_data;
+ struct videobuf_queue *q = map-q;
+ struct videobuf_dma_sg_memory *mem = NULL;
+
+ unsigned long offset;
+ unsigned long page_nr;
+ int first;
dprintk(3, fault: fault @ %08lx [vma %08lx-%08lx]\n,
(unsigned long)vmf-virtual_address,
vma-vm_start, vma-vm_end);
- page = alloc_page(GFP_USER | __GFP_DMA32);
- if (!page)
- return VM_FAULT_OOM;
- clear_user_highpage(page, (unsigned long)vmf-virtual_address);
+ mutex_lock(q-vb_lock);
+
+ offset = (unsigned long)vmf-virtual_address - vma-vm_start;
+ page_nr = offset PAGE_SHIFT;
+
+ for (first = 0; first VIDEO_MAX_FRAME; first++) {
+ if (NULL == q-bufs[first])
+ continue;
+
+ MAGIC_CHECK(mem-magic, MAGIC_SG_MEM);
+
+ if (q-bufs[first]-map == map)
+ break;
+ }
+
+ mem = q-bufs[first]-priv;
+ if (!mem)
+ return VM_FAULT_SIGBUS;
+ if (!mem-dma.vmalloc) {
+ mem-dma.vmalloc = vmalloc_32(PAGE_ALIGN(q-bufs[first]-size));
+ if (NULL == mem-dma.vmalloc) {
+ dprintk(1, %s: vmalloc_32() failed\n, __func__);
+ return VM_FAULT_OOM;
+ }
+ } else
+ page = vmalloc_to_page(mem-dma.vmalloc+
+ (offset (~PAGE_MASK)));
+ mutex_unlock(q-vb_lock);
+
vmf-page = page;
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
AverMedia Volar Black HD (A850) - crashes in mythtv, does not find HD
Hi I've read through the earlier thread about the driver for this here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg03661.html First I've used the default Ubuntu Lucid kernel driver (2.6.32) - kaffeine, scan etc work, mythtv scanning finds channels, times out, and channels get added as not visible. LiveTV crashes mythtv - see my report here: http://mythtv.org/pipermail/mythtv-users/2010-July/293751.html I also used hg clone to check out the current v4l tree (on Saturday 24/07/2010) - same Then I tried the latest version I could find http://linuxtv.org/hg/~anttip (last change 5 weeks ago) but still no joy (exactly the same problems). Another issue - as far as I understood the earlier discussion - Antti mentioned that the card reports two tuners. I've noticed that I can not tune any HD channels (though I think I should be in reach). Maybe the second tuner is the HDTV tuner? Any help appreciated. Mythtv recording is working fine btw once I manually manipulate the channels table. It seems like mythtv after the scan tries to tune to each channel in turn and get some info from it and that's what times out at that stage. The crash that happens with LiveTV is documented on the mythtv-users list (see above) - I also posted it to mythtv-devel but strangely they didn't want it Thanks for writing the driver in the first place! mimo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2]videobuf_dma_sg: a new implementation for mmap
a mmap issue for videobuf-dma-sg: it will alloc a new page for mmaping
when it encounter page fault at video_vm_ops-fault().
a new implementation for mmap, it translate the vmalloc to page at
video_vm_ops-fault().
in v2, if mem-dma.vmalloc is NULL at video_vm_ops-fault(), it will
alloc memory by vmalloc_32().
Signed-off-by: Figo.zhang figo1...@gmail.com
---
drivers/media/video/videobuf-dma-sg.c | 51
+++--
1 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index 8359e6b..767483d 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -201,10 +201,11 @@ int videobuf_dma_init_kernel(struct
videobuf_dmabuf *dma, int direction,
dprintk(1, init kernel [%d pages]\n, nr_pages);
dma-direction = direction;
- dma-vmalloc = vmalloc_32(nr_pages PAGE_SHIFT);
- if (NULL == dma-vmalloc) {
- dprintk(1, vmalloc_32(%d pages) failed\n, nr_pages);
- return -ENOMEM;
+ if (!dma-vmalloc)
+ dma-vmalloc = vmalloc_32(nr_pages PAGE_SHIFT);
+ if (NULL == dma-vmalloc) {
+ dprintk(1, vmalloc_32(%d pages) failed\n, nr_pages);
+ return -ENOMEM;
}
dprintk(1, vmalloc is at addr 0x%08lx, size=%d\n,
@@ -397,16 +398,48 @@ static void videobuf_vm_close(struct
vm_area_struct *vma)
*/
static int videobuf_vm_fault(struct vm_area_struct *vma, struct
vm_fault *vmf)
{
- struct page *page;
+ struct page *page = NULL;
+ struct videobuf_mapping *map = vma-vm_private_data;
+ struct videobuf_queue *q = map-q;
+ struct videobuf_dma_sg_memory *mem = NULL;
+
+ unsigned long offset;
+ unsigned long page_nr;
+ int first;
dprintk(3, fault: fault @ %08lx [vma %08lx-%08lx]\n,
(unsigned long)vmf-virtual_address,
vma-vm_start, vma-vm_end);
- page = alloc_page(GFP_USER | __GFP_DMA32);
- if (!page)
- return VM_FAULT_OOM;
- clear_user_highpage(page, (unsigned long)vmf-virtual_address);
+ mutex_lock(q-vb_lock);
+
+ offset = (unsigned long)vmf-virtual_address - vma-vm_start;
+ page_nr = offset PAGE_SHIFT;
+
+ for (first = 0; first VIDEO_MAX_FRAME; first++) {
+ if (NULL == q-bufs[first])
+ continue;
+
+ MAGIC_CHECK(mem-magic, MAGIC_SG_MEM);
+
+ if (q-bufs[first]-map == map)
+ break;
+ }
+
+ mem = q-bufs[first]-priv;
+ if (!mem)
+ return VM_FAULT_SIGBUS;
+ if (!mem-dma.vmalloc) {
+ mem-dma.vmalloc = vmalloc_32(PAGE_ALIGN(q-bufs[first]-size));
+ if (NULL == mem-dma.vmalloc) {
+ dprintk(1, %s: vmalloc_32() failed\n, __func__);
+ return VM_FAULT_OOM;
+ }
+ } else
+ page = vmalloc_to_page(mem-dma.vmalloc+
+ (offset (~PAGE_MASK)));
+ mutex_unlock(q-vb_lock);
+
vmf-page = page;
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
Em 28-07-2010 07:40, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote: On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl jonsm...@gmail.com wrote: No its not, its just extended NEC. http://www.sbprojects.com/knowledge/ir/nec.htm Says the last two bytes should be the complement of each other. So for extended NEC it would need to be: 1100 0010 1010 0101 instead of 1100 0010 1010 0100 The last bit is wrong. From the debug output it is decoding as NEC, but then it fails a consistency check. Maybe we need to add a new protocol that lets NEC commands through even if they fail the error checks. Assuming that Maxim's IR receiver is not causing some bad decode at the NEC code, it seems simpler to add a parameter at sysfs to relax the NEC detection. We should add some way, at the userspace table for those RC's that uses a NEC-like code. There's another alternative: currently, the NEC decoder produces a 16 bits code for NEC and a 24 bits for NEC-extended code. The decoder may return a 32 bits code when none of the checksum's match the NEC or NEC-extended standard. Such 32 bits code won't match a keycode on a 16-bits or 24-bits table, so there's no risk of generating a wrong keycode, if the wrong consistent check is due to a reception error. Btw, we still need to port rc core to use the new tables ioctl's, as cleaning all keycodes on a 32 bits table would take forever with the current input events ioctls. It may also be that the NEC machine rejected it because the timing was so far off that it concluded that it couldn't be a NEC messages. The log didn't include the exact reason it got rejected. Add some printks at the end of the NEC machine to determine the exact reason for rejection. The better is to discard the possibility of a timing issue before changing the decoder to accept NEC-like codes without consistency checks. The current state machines enforce protocol compliance so there are probably a lot of older remotes that won't decode right. We can use some help in adjusting the state machines to let out of spec codes through. Yes, but we should take some care to avoid having another protocol decoder to interpret badly a different protocol. So, I think that the decoders may have some sysfs nodes to tweak the decoders to accept those older remotes. We'll need a consistent way to add some logic at the remotes keycodes used by ir-keycode, in order to allow it to tweak the decoder when a keycode table for such remote is loaded into the driver. User space lirc is much older. Bugs like this have been worked out of it. It will take some time to get the kernel implementation up to the same level. True. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DVBT +AF9015 +MXL5007t
HI all I have a usb dvbt module with af9015 +mx5007t both drivers exist in kernel but af9015.c needs to be patched lsusb: Bus 002 Device 003: ID 15a4:9016 Afatech Technologies, Inc. AF9015 DVB-T USB2.0 stick dmesg | grep 9015 [ 3407.599086] dvb_usb_af9015 2-4:1.0: usb_probe_interface [ 3407.599095] dvb_usb_af9015 2-4:1.0: usb_probe_interface - got id [ 3407.967209] af9015: tuner id:177 not supported, please report! [ 3407.967270] dvb_usb_af9015 2-4:1.1: usb_probe_interface [ 3407.967277] dvb_usb_af9015 2-4:1.1: usb_probe_interface - got id [ 3407.968049] usbcore: registered new interface driver dvb_usb_af9015 driver adress: v4l-dvb/linux/drivers/media/dvb/dvb-usb/af9015.c v4l-dvb/linux/drivers/media/common/tuners/mxl5007.c I dont know how do it can any one help? thanks -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
Let's be really sure it is NEC and not JVC. 8850 4350 525 1575 525 1575 525 450 525 450 525 450 525 450 525 1575 525 450 525 1575 525 450 525 1575 525 450 525 450 525 1575 525 450 525 450 52523625 NEC timings are 9000 4500 560 1680 560 560 etc JVC timings are 8400 4200 525 1575 525 525 It is a closer match to the JVC timing. But neither protocol uses a different mark/space timing -- 450 vs 525 Also look at the repeats. This is repeating at about 25ms. NEC repeat spacing is 110ms. JVC is supposed to be at 50-60ms. NEC does not repeat the entire command and JVC does. The repeats are closer to following the JVC model. I'd say this is a JVC command. So the question is, why didn't JVC decoder get out of state zero? -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Wed, 2010-07-28 at 10:13 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 07:40, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote: On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl jonsm...@gmail.com wrote: No its not, its just extended NEC. http://www.sbprojects.com/knowledge/ir/nec.htm Says the last two bytes should be the complement of each other. So for extended NEC it would need to be: 1100 0010 1010 0101 instead of 1100 0010 1010 0100 The last bit is wrong. From the debug output it is decoding as NEC, but then it fails a consistency check. Maybe we need to add a new protocol that lets NEC commands through even if they fail the error checks. Assuming that Maxim's IR receiver is not causing some bad decode at the NEC code, it seems simpler to add a parameter at sysfs to relax the NEC detection. We should add some way, at the userspace table for those RC's that uses a NEC-like code. There's another alternative: currently, the NEC decoder produces a 16 bits code for NEC and a 24 bits for NEC-extended code. The decoder may return a 32 bits code when none of the checksum's match the NEC or NEC-extended standard. Such 32 bits code won't match a keycode on a 16-bits or 24-bits table, so there's no risk of generating a wrong keycode, if the wrong consistent check is due to a reception error. Btw, we still need to port rc core to use the new tables ioctl's, as cleaning all keycodes on a 32 bits table would take forever with the current input events ioctls. It may also be that the NEC machine rejected it because the timing was so far off that it concluded that it couldn't be a NEC messages. The log didn't include the exact reason it got rejected. Add some printks at the end of the NEC machine to determine the exact reason for rejection. The better is to discard the possibility of a timing issue before changing the decoder to accept NEC-like codes without consistency checks. The current state machines enforce protocol compliance so there are probably a lot of older remotes that won't decode right. We can use some help in adjusting the state machines to let out of spec codes through. Yes, but we should take some care to avoid having another protocol decoder to interpret badly a different protocol. So, I think that the decoders may have some sysfs nodes to tweak the decoders to accept those older remotes. We'll need a consistent way to add some logic at the remotes keycodes used by ir-keycode, in order to allow it to tweak the decoder when a keycode table for such remote is loaded into the driver. User space lirc is much older. Bugs like this have been worked out of it. It will take some time to get the kernel implementation up to the same level. True. I more or less got to the bottom of this. It turns out that ENE reciever has a non linear measurement error. That is the longer sample is, the larger error it contains. Substracting around 4% from the samples makes the output look much more standard compliant. You are right that my remote has JVC protocol. (at least I am sure now it hasn't NEC, because repeat looks differently). My remote now actually partially works with JVC decoder, it decodes every other keypress. Still, no repeat is supported. However, all recievers (and transmitters) aren't perfect. Thats why I prefer lirc, because it makes no assumptions about protocol, so it can be 'trained' to work with any remote, and under very large range of error tolerances. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote: Let's be really sure it is NEC and not JVC. 8850 4350 525 1575 525 1575 525 450 525 450 525 450 525 450 525 1575 525 450 525 1575 525 450 525 1575 525 450 525 450 525 1575 525 450 525 450 52523625 NEC timings are 9000 4500 560 1680 560 560 etc JVC timings are 8400 4200 525 1575 525 525 It is a closer match to the JVC timing. But neither protocol uses a different mark/space timing -- 450 vs 525 I assume you mean different mark/space timing for the symbol for which they are the same length (in NEC that's the '0' symbol IIRC). I've noticed different mark/space timings for the '0' symbol from NEC remotes and with some RC-5 remotes. I usually attribute it to cheap remote designs, weak batteries, capacitive effects, receiver pulse measurement technique, etc. Here's an example of NEC remote from a DTV STB remote as measured by the CX23888 IR receiver on an HVR-1850: 8257296 ns mark 4206185 ns space leader 482926 ns mark 545296 ns space 0 481296 ns mark 1572259 ns space 1 481148 ns mark 546333 ns space 0 479963 ns mark 551815 ns space 0 454333 ns mark 1615519 ns space 1 435074 ns mark 591370 ns space [...] I don't know the source of the error. I would have to check the same remote against my MCE USB receiver to try and determine any receiver induced measurement errors. But, in Maxim's case, the difference isn't bad: 450/525 ~= 86%. I would hope a 15% difference would still be recognizable. Also look at the repeats. This is repeating at about 25ms. NEC repeat spacing is 110ms. JVC is supposed to be at 50-60ms. NEC does not repeat the entire command and JVC does. The repeats are closer to following the JVC model. I'd say this is a JVC command. So the question is, why didn't JVC decoder get out of state zero? Is JVC enabled by default? I recall analyzing that it could generate false positives on NEC codes. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Wed, Jul 28, 2010 at 10:24 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Wed, 2010-07-28 at 10:13 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 07:40, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote: On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl jonsm...@gmail.com wrote: No its not, its just extended NEC. http://www.sbprojects.com/knowledge/ir/nec.htm Says the last two bytes should be the complement of each other. So for extended NEC it would need to be: 1100 0010 1010 0101 instead of 1100 0010 1010 0100 The last bit is wrong. From the debug output it is decoding as NEC, but then it fails a consistency check. Maybe we need to add a new protocol that lets NEC commands through even if they fail the error checks. Assuming that Maxim's IR receiver is not causing some bad decode at the NEC code, it seems simpler to add a parameter at sysfs to relax the NEC detection. We should add some way, at the userspace table for those RC's that uses a NEC-like code. There's another alternative: currently, the NEC decoder produces a 16 bits code for NEC and a 24 bits for NEC-extended code. The decoder may return a 32 bits code when none of the checksum's match the NEC or NEC-extended standard. Such 32 bits code won't match a keycode on a 16-bits or 24-bits table, so there's no risk of generating a wrong keycode, if the wrong consistent check is due to a reception error. Btw, we still need to port rc core to use the new tables ioctl's, as cleaning all keycodes on a 32 bits table would take forever with the current input events ioctls. It may also be that the NEC machine rejected it because the timing was so far off that it concluded that it couldn't be a NEC messages. The log didn't include the exact reason it got rejected. Add some printks at the end of the NEC machine to determine the exact reason for rejection. The better is to discard the possibility of a timing issue before changing the decoder to accept NEC-like codes without consistency checks. The current state machines enforce protocol compliance so there are probably a lot of older remotes that won't decode right. We can use some help in adjusting the state machines to let out of spec codes through. Yes, but we should take some care to avoid having another protocol decoder to interpret badly a different protocol. So, I think that the decoders may have some sysfs nodes to tweak the decoders to accept those older remotes. We'll need a consistent way to add some logic at the remotes keycodes used by ir-keycode, in order to allow it to tweak the decoder when a keycode table for such remote is loaded into the driver. User space lirc is much older. Bugs like this have been worked out of it. It will take some time to get the kernel implementation up to the same level. True. I more or less got to the bottom of this. It turns out that ENE reciever has a non linear measurement error. That is the longer sample is, the larger error it contains. Substracting around 4% from the samples makes the output look much more standard compliant. Most of the protocols are arranged using power of two timings. For example 562.5, 1125, 2250, 4500, 9000 -- NEC 525, 1050, 2100, 4200, 8400 - JVC The decoders are designed to be much more sensitive to the power of two relationship than the exact timing. Your non-linear error messed up the relationship. You are right that my remote has JVC protocol. (at least I am sure now it hasn't NEC, because repeat looks differently). My remote now actually partially works with JVC decoder, it decodes every other keypress. Still, no repeat is supported. It probably isn't implemented yet. Jarod has been focusing more on getting the basic decoders to work. However, all recievers (and transmitters) aren't perfect. Thats why I prefer lirc, because it makes no assumptions about protocol, so it can be 'trained' to work with any remote, and under very large range of error tolerances. It's possible to build a Linux IR decoder engine that can be loaded with the old LIRC config files. But before doing this we should work on getting all of the errors out of the standard decoders. Best regards, Maxim Levitsky -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] IR: Kconfig fixes
Move IR drives below separate menu. This allows to disable them. Also correct a typo. Signed-off-by: Maxim Levitsky maximlevit...@gmail.com --- drivers/media/IR/Kconfig | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig index e557ae0..99ea9cd 100644 --- a/drivers/media/IR/Kconfig +++ b/drivers/media/IR/Kconfig @@ -1,8 +1,10 @@ -config IR_CORE - tristate +menuconfig IR_CORE + tristate Infrared remote controller adapters depends on INPUT default INPUT +if IR_CORE + config VIDEO_IR tristate depends on IR_CORE @@ -16,7 +18,7 @@ config LIRC Enable this option to build the Linux Infrared Remote Control (LIRC) core device interface driver. The LIRC interface passes raw IR to and from userspace, where the - LIRC daemon handles protocol decoding for IR reception ann + LIRC daemon handles protocol decoding for IR reception and encoding for IR transmitting (aka blasting). source drivers/media/IR/keymaps/Kconfig @@ -102,3 +104,9 @@ config IR_MCEUSB To compile this driver as a module, choose M here: the module will be called mceusb. + + + + + +endif #IR_CORE -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] IR: minor fixes:
* lirc: Don't propagate reset event to userspace
* lirc: Remove strange logic from lirc that would make first sample always be
pulse
* Make TO_US macro actualy print what it should.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |3 +--
drivers/media/IR/ir-lirc-codec.c | 14 --
drivers/media/IR/ir-raw-event.c |3 +++
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index babd520..8ce80e4 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -76,7 +76,6 @@ struct ir_raw_event_ctrl {
struct lirc_codec {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
- int lircdata;
} lirc;
};
@@ -104,7 +103,7 @@ static inline void decrease_duration(struct ir_raw_event
*ev, unsigned duration)
ev-duration -= duration;
}
-#define TO_US(duration)(((duration) + 500) / 1000)
+#define TO_US(duration)((duration) / 1000)
#define TO_STR(is_pulse) ((is_pulse) ? pulse : space)
#define IS_RESET(ev) (ev.duration == 0)
diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c
index 3ba482d..8ca01fd 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -32,6 +32,7 @@
static int ir_lirc_decode(struct input_dev *input_dev, struct ir_raw_event ev)
{
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
+ int sample;
if (!(ir_dev-raw-enabled_protocols IR_TYPE_LIRC))
return 0;
@@ -39,18 +40,21 @@ static int ir_lirc_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
if (!ir_dev-raw-lirc.drv || !ir_dev-raw-lirc.drv-rbuf)
return -EINVAL;
+ if (IS_RESET(ev))
+ return 0;
+
IR_dprintk(2, LIRC data transfer started (%uus %s)\n,
TO_US(ev.duration), TO_STR(ev.pulse));
- ir_dev-raw-lirc.lircdata += ev.duration / 1000;
+
+ sample = ev.duration / 1000;
if (ev.pulse)
- ir_dev-raw-lirc.lircdata |= PULSE_BIT;
+ sample |= PULSE_BIT;
lirc_buffer_write(ir_dev-raw-lirc.drv-rbuf,
- (unsigned char *) ir_dev-raw-lirc.lircdata);
+ (unsigned char *) sample);
wake_up(ir_dev-raw-lirc.drv-rbuf-wait_poll);
- ir_dev-raw-lirc.lircdata = 0;
return 0;
}
@@ -224,8 +228,6 @@ static int ir_lirc_register(struct input_dev *input_dev)
ir_dev-raw-lirc.drv = drv;
ir_dev-raw-lirc.ir_dev = ir_dev;
- ir_dev-raw-lirc.lircdata = PULSE_MASK;
-
return 0;
lirc_register_failed:
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index 6f192ef..ab9c4da 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -66,6 +66,9 @@ int ir_raw_event_store(struct input_dev *input_dev, struct
ir_raw_event *ev)
if (!ir-raw)
return -EINVAL;
+ IR_dprintk(2, sample: (05%dus %s)\n, TO_US(ev-duration),
+ TO_STR(ev-pulse));
+
if (kfifo_in(ir-raw-kfifo, ev, sizeof(*ev)) != sizeof(*ev))
return -ENOMEM;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] IR: replace spinlock with mutex.
Some handlers (lirc for example) allocates memory on initialization,
doing so in atomic context is cumbersome.
Fixes warning about sleeping function in atomic context.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-raw-event.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index ab9c4da..c6a80b3 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -13,7 +13,7 @@
*/
#include linux/workqueue.h
-#include linux/spinlock.h
+#include linux/mutex.h
#include linux/sched.h
#include ir-core-priv.h
@@ -24,7 +24,7 @@
static LIST_HEAD(ir_raw_client_list);
/* Used to handle IR raw handler extensions */
-static DEFINE_SPINLOCK(ir_raw_handler_lock);
+static DEFINE_MUTEX(ir_raw_handler_lock);
static LIST_HEAD(ir_raw_handler_list);
static u64 available_protocols;
@@ -41,10 +41,10 @@ static void ir_raw_event_work(struct work_struct *work)
container_of(work, struct ir_raw_event_ctrl, rx_work);
while (kfifo_out(raw-kfifo, ev, sizeof(ev)) == sizeof(ev)) {
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
list_for_each_entry(handler, ir_raw_handler_list, list)
handler-decode(raw-input_dev, ev);
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
raw-prev_ev = ev;
}
}
@@ -150,9 +150,9 @@ u64
ir_raw_get_allowed_protocols()
{
u64 protocols;
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
protocols = available_protocols;
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
return protocols;
}
@@ -180,12 +180,12 @@ int ir_raw_event_register(struct input_dev *input_dev)
return rc;
}
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
list_add_tail(ir-raw-list, ir_raw_client_list);
list_for_each_entry(handler, ir_raw_handler_list, list)
if (handler-raw_register)
handler-raw_register(ir-raw-input_dev);
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
return 0;
}
@@ -200,12 +200,12 @@ void ir_raw_event_unregister(struct input_dev *input_dev)
cancel_work_sync(ir-raw-rx_work);
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
list_del(ir-raw-list);
list_for_each_entry(handler, ir_raw_handler_list, list)
if (handler-raw_unregister)
handler-raw_unregister(ir-raw-input_dev);
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
kfifo_free(ir-raw-kfifo);
kfree(ir-raw);
@@ -220,13 +220,13 @@ int ir_raw_handler_register(struct ir_raw_handler
*ir_raw_handler)
{
struct ir_raw_event_ctrl *raw;
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
list_add_tail(ir_raw_handler-list, ir_raw_handler_list);
if (ir_raw_handler-raw_register)
list_for_each_entry(raw, ir_raw_client_list, list)
ir_raw_handler-raw_register(raw-input_dev);
available_protocols |= ir_raw_handler-protocols;
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
return 0;
}
@@ -236,13 +236,13 @@ void ir_raw_handler_unregister(struct ir_raw_handler
*ir_raw_handler)
{
struct ir_raw_event_ctrl *raw;
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
list_del(ir_raw_handler-list);
if (ir_raw_handler-raw_unregister)
list_for_each_entry(raw, ir_raw_client_list, list)
ir_raw_handler-raw_unregister(raw-input_dev);
available_protocols = ~ir_raw_handler-protocols;
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
}
EXPORT_SYMBOL(ir_raw_handler_unregister);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] IR: add helper functions for ir input devices that send ir timing data in small chunks, and alternation between pulses and spaces isn't guaranteed.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |1 +
drivers/media/IR/ir-keytable.c |2 +-
drivers/media/IR/ir-raw-event.c | 86 +++
include/media/ir-core.h | 24 +-
4 files changed, 109 insertions(+), 4 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 8ce80e4..3eafdb7 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -36,6 +36,7 @@ struct ir_raw_event_ctrl {
struct kfifokfifo; /* fifo for the
pulse/space durations */
ktime_t last_event; /* when last event
occurred */
enum raw_event_type last_type; /* last event type */
+ struct ir_raw_event current_sample; /* sample that is not
yet pushed to fifo */
struct input_dev*input_dev; /* pointer to the
parent input_dev */
u64 enabled_protocols; /* enabled raw
protocol decoders */
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 94a8577..34b9c07 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -428,7 +428,7 @@ static void ir_close(struct input_dev *input_dev)
*/
int __ir_input_register(struct input_dev *input_dev,
const struct ir_scancode_table *rc_tab,
- const struct ir_dev_props *props,
+ struct ir_dev_props *props,
const char *driver_name)
{
struct ir_input_dev *ir_dev;
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index c6a80b3..bdf2ed8 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -129,6 +129,92 @@ int ir_raw_event_store_edge(struct input_dev *input_dev,
enum raw_event_type typ
EXPORT_SYMBOL_GPL(ir_raw_event_store_edge);
/**
+ * ir_raw_event_store_with_filter() - pass next pulse/space to decoders with
some processing
+ * @input_dev: the struct input_dev device descriptor
+ * @type: the type of the event that has occurred
+ *
+ * This routine (which may be called from an interrupt context) is used to
+ * store the beginning of an ir pulse or space (or the start/end of ir
+ * reception) for the raw ir decoding state machines.\
+ * This routine is intended for devices with limited internal buffer
+ * It automerges samples of same type, and handles timeouts
+ */
+int ir_raw_event_store_with_filter(struct input_dev *input_dev,
+ struct ir_raw_event *ev)
+{
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
+ struct ir_raw_event_ctrl *raw = ir-raw;
+
+ if (!ir-raw || !ir-props)
+ return -EINVAL;
+
+ /* Ignore spaces in idle mode */
+ if (ir-idle !ev-pulse)
+ return 0;
+ else if (ir-idle)
+ ir_raw_event_set_idle(input_dev, 0);
+
+ if (!raw-current_sample.duration) {
+ raw-current_sample = *ev;
+ } else if (ev-pulse == raw-current_sample.pulse) {
+ raw-current_sample.duration += ev-duration;
+ } else {
+ ir_raw_event_store(input_dev, raw-current_sample);
+ raw-current_sample = *ev;
+ }
+
+ /* Enter idle mode if nessesary */
+ if (!ev-pulse ir-props-timeout
+ raw-current_sample.duration = ir-props-timeout)
+ ir_raw_event_set_idle(input_dev, 1);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_store_with_filter);
+
+
+void ir_raw_event_set_idle(struct input_dev *input_dev, int idle)
+{
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
+ struct ir_raw_event_ctrl *raw = ir-raw;
+ ktime_t now;
+ u64 delta;
+
+ if (!ir-props)
+ return;
+
+ if (!ir-raw)
+ goto out;
+
+ if (idle) {
+ IR_dprintk(2, enter idle mode\n);
+ raw-last_event = ktime_get();
+ } else {
+ IR_dprintk(2, exit idle mode\n);
+
+ now = ktime_get();
+ delta = ktime_to_ns(ktime_sub(now, ir-raw-last_event));
+
+ WARN_ON(raw-current_sample.pulse);
+
+ raw-current_sample.duration =
+ min(raw-current_sample.duration + delta,
+ (u64)IR_MAX_DURATION);
+
+ ir_raw_event_store(input_dev, raw-current_sample);
+
+ if (raw-current_sample.duration == IR_MAX_DURATION)
+ ir_raw_event_reset(input_dev);
+
+ raw-current_sample.duration = 0;
+ }
+out:
+ if (ir-props-s_idle)
+ ir-props-s_idle(ir-props-priv, idle);
+ ir-idle = idle;
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_set_idle);
+
+/**
* ir_raw_event_handle() -
[PATCH 5/9] IR: extend interfaces to support more device settings
Also reuse LIRC_SET_MEASURE_CARRIER_MODE as LIRC_SET_LEARN_MODE
(LIRC_SET_LEARN_MODE will start carrier reports if possible, and
tune receiver to wide band mode)
This IOCTL isn't yet used by lirc, so this won't break userspace.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |2 +
drivers/media/IR/ir-lirc-codec.c | 100 ++
include/media/ir-core.h | 11
include/media/lirc.h |4 +-
4 files changed, 105 insertions(+), 12 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 3eafdb7..4ed170d 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -77,6 +77,8 @@ struct ir_raw_event_ctrl {
struct lirc_codec {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
+ int timeout_report;
+ int carrier_low;
} lirc;
};
diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c
index 8ca01fd..0f3969c 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -96,13 +96,13 @@ out:
return ret;
}
-static long ir_lirc_ioctl(struct file *filep, unsigned int cmd, unsigned long
arg)
+static long ir_lirc_ioctl(struct file *filep, unsigned int cmd, unsigned long
__user arg)
{
struct lirc_codec *lirc;
struct ir_input_dev *ir_dev;
int ret = 0;
void *drv_data;
- unsigned long val;
+ unsigned long val = 0;
lirc = lirc_get_pdata(filep);
if (!lirc)
@@ -116,10 +116,21 @@ static long ir_lirc_ioctl(struct file *filep, unsigned
int cmd, unsigned long ar
switch (cmd) {
case LIRC_SET_TRANSMITTER_MASK:
+ case LIRC_SET_SEND_CARRIER:
+ case LIRC_SET_SEND_MODE:
+ case LIRC_SET_REC_TIMEOUT:
+ case LIRC_SET_REC_TIMEOUT_REPORTS:
+ case LIRC_SET_LEARN_MODE:
+ case LIRC_SET_REC_CARRIER:
+ case LIRC_SET_REC_CARRIER_RANGE:
+ case LIRC_SET_SEND_DUTY_CYCLE:
ret = get_user(val, (unsigned long *)arg);
if (ret)
return ret;
+ }
+ switch (cmd) {
+ case LIRC_SET_TRANSMITTER_MASK:
if (ir_dev-props ir_dev-props-s_tx_mask)
ret = ir_dev-props-s_tx_mask(drv_data, (u32)val);
else
@@ -127,10 +138,6 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int
cmd, unsigned long ar
break;
case LIRC_SET_SEND_CARRIER:
- ret = get_user(val, (unsigned long *)arg);
- if (ret)
- return ret;
-
if (ir_dev-props ir_dev-props-s_tx_carrier)
ir_dev-props-s_tx_carrier(drv_data, (u32)val);
else
@@ -143,14 +150,75 @@ static long ir_lirc_ioctl(struct file *filep, unsigned
int cmd, unsigned long ar
break;
case LIRC_SET_SEND_MODE:
- ret = get_user(val, (unsigned long *)arg);
- if (ret)
- return ret;
-
if (val != (LIRC_MODE_PULSE LIRC_CAN_SEND_MASK))
return -EINVAL;
break;
+ case LIRC_GET_REC_RESOLUTION:
+ val = ir_dev-props-rx_resolution;
+ ret = put_user(val, (unsigned long *)arg);
+ break;
+
+ case LIRC_SET_REC_TIMEOUT:
+ if (val ir_dev-props-min_timeout ||
+ val ir_dev-props-max_timeout)
+ return -EINVAL;
+
+ ir_dev-props-timeout = val;
+ break;
+
+ case LIRC_SET_REC_TIMEOUT_REPORTS:
+ ir_dev-raw-lirc.timeout_report = !!val;
+ return 0;
+
+ case LIRC_GET_MIN_TIMEOUT:
+
+ if (!ir_dev-props-max_timeout)
+ return -ENOSYS;
+
+ ret = put_user(ir_dev-props-min_timeout, (unsigned long
*)arg);
+ break;
+ case LIRC_GET_MAX_TIMEOUT:
+ if (!ir_dev-props-max_timeout)
+ return -ENOSYS;
+
+ ret = put_user(ir_dev-props-max_timeout, (unsigned long
*)arg);
+ break;
+
+ case LIRC_SET_LEARN_MODE:
+ if (ir_dev-props-s_learning_mode)
+ return ir_dev-props-s_learning_mode(
+ ir_dev-props-priv, !!val);
+ else
+ return -ENOSYS;
+
+ case LIRC_SET_REC_CARRIER:
+ if (ir_dev-props-s_rx_carrier_range)
+ ret = ir_dev-props-s_rx_carrier_range(
+ ir_dev-props-priv,
+ ir_dev-raw-lirc.carrier_low, val);
+ else
+ return -ENOSYS;
+
+ if (!ret)
+
[PATCH 6/9] IR: actually allow not to compile keymaps in..
Currntly, ir device registration fails if keymap requested by driver is not
found...
Fix that by always compiling in the empty keymap, and using it as a failback
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |3 +-
drivers/media/IR/ir-sysfs.c |2 +
drivers/media/IR/keymaps/Makefile |1 -
drivers/media/IR/keymaps/rc-empty.c | 44 ---
drivers/media/IR/rc-map.c | 23 ++
include/media/ir-core.h |8 -
6 files changed, 33 insertions(+), 48 deletions(-)
delete mode 100644 drivers/media/IR/keymaps/rc-empty.c
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 4ed170d..9206b76 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -128,7 +128,8 @@ int ir_raw_handler_register(struct ir_raw_handler
*ir_raw_handler);
void ir_raw_handler_unregister(struct ir_raw_handler *ir_raw_handler);
void ir_raw_init(void);
-
+int ir_rcmap_init(void);
+void ir_rcmap_cleanup(void);
/*
* Decoder initialization code
*
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index a841e51..936dff8 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -341,6 +341,7 @@ static int __init ir_core_init(void)
/* Initialize/load the decoders/keymap code that will be used */
ir_raw_init();
+ ir_rcmap_init();
return 0;
}
@@ -348,6 +349,7 @@ static int __init ir_core_init(void)
static void __exit ir_core_exit(void)
{
class_unregister(ir_input_class);
+ ir_rcmap_cleanup();
}
module_init(ir_core_init);
diff --git a/drivers/media/IR/keymaps/Makefile
b/drivers/media/IR/keymaps/Makefile
index 86d3d1f..24992cd 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -17,7 +17,6 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-dm1105-nec.o \
rc-dntv-live-dvb-t.o \
rc-dntv-live-dvbt-pro.o \
- rc-empty.o \
rc-em-terratec.o \
rc-encore-enltv2.o \
rc-encore-enltv.o \
diff --git a/drivers/media/IR/keymaps/rc-empty.c
b/drivers/media/IR/keymaps/rc-empty.c
deleted file mode 100644
index 3b338d8..000
--- a/drivers/media/IR/keymaps/rc-empty.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/* empty.h - Keytable for empty Remote Controller
- *
- * keymap imported from ir-keymaps.c
- *
- * Copyright (c) 2010 by Mauro Carvalho Chehab mche...@redhat.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include media/rc-map.h
-
-/* empty keytable, can be used as placeholder for not-yet created keytables */
-
-static struct ir_scancode empty[] = {
- { 0x2a, KEY_COFFEE },
-};
-
-static struct rc_keymap empty_map = {
- .map = {
- .scan= empty,
- .size= ARRAY_SIZE(empty),
- .ir_type = IR_TYPE_UNKNOWN, /* Legacy IR type */
- .name= RC_MAP_EMPTY,
- }
-};
-
-static int __init init_rc_map_empty(void)
-{
- return ir_register_map(empty_map);
-}
-
-static void __exit exit_rc_map_empty(void)
-{
- ir_unregister_map(empty_map);
-}
-
-module_init(init_rc_map_empty)
-module_exit(exit_rc_map_empty)
-
-MODULE_LICENSE(GPL);
-MODULE_AUTHOR(Mauro Carvalho Chehab mche...@redhat.com);
diff --git a/drivers/media/IR/rc-map.c b/drivers/media/IR/rc-map.c
index 46a8f15..689143f 100644
--- a/drivers/media/IR/rc-map.c
+++ b/drivers/media/IR/rc-map.c
@@ -82,3 +82,26 @@ void ir_unregister_map(struct rc_keymap *map)
}
EXPORT_SYMBOL_GPL(ir_unregister_map);
+
+static struct ir_scancode empty[] = {
+ { 0x2a, KEY_COFFEE },
+};
+
+static struct rc_keymap empty_map = {
+ .map = {
+ .scan= empty,
+ .size= ARRAY_SIZE(empty),
+ .ir_type = IR_TYPE_UNKNOWN, /* Legacy IR type */
+ .name= RC_MAP_EMPTY,
+ }
+};
+
+int ir_rcmap_init(void)
+{
+ return ir_register_map(empty_map);
+}
+
+void ir_rcmap_cleanup(void)
+{
+ ir_unregister_map(empty_map);
+}
diff --git a/include/media/ir-core.h b/include/media/ir-core.h
index 46cc6c5..1e0abfd 100644
--- a/include/media/ir-core.h
+++ b/include/media/ir-core.h
@@ -134,8 +134,12 @@ static inline int ir_input_register(struct input_dev *dev,
return -EINVAL;
ir_codes = get_rc_map(map_name);
- if (!ir_codes)
- return -EINVAL;
+ if (!ir_codes) {
+ ir_codes = get_rc_map(RC_MAP_EMPTY);
+
+ if (!ir_codes)
+ return -EINVAL;
+ }
rc =
[PATCH 7/9] IR: actualy report unknown scancodes the in-kernel decoders found.
This way it is possible to use evtest to create keymap for unknown remote.
(Providing that in-kernel decoding understands remote's protocol. Hint: it
doesn't)
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-keytable.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 34b9c07..1504a3b 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -383,9 +383,12 @@ void ir_keydown(struct input_dev *dev, int scancode, u8
toggle)
ir-last_toggle = toggle;
ir-last_keycode = keycode;
+ input_event(dev, EV_MSC, MSC_SCAN, scancode);
+
if (keycode == KEY_RESERVED)
goto out;
+
/* Register a keypress */
ir-keypressed = true;
IR_dprintk(1, %s: key down event, key 0x%04x, scancode 0x%04x\n,
@@ -480,6 +483,8 @@ int __ir_input_register(struct input_dev *input_dev,
set_bit(EV_KEY, input_dev-evbit);
set_bit(EV_REP, input_dev-evbit);
+ set_bit(EV_MSC, input_dev-evbit);
+ set_bit(MSC_SCAN, input_dev-mscbit);
if (ir_setkeytable(input_dev, ir_dev-rc_tab, rc_tab)) {
rc = -ENOMEM;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] IR: Add ENE input driver.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/Kconfig | 11 +
drivers/media/IR/Makefile |1 +
drivers/media/IR/ene_ir.c | 1019 +
drivers/media/IR/ene_ir.h | 228 ++
4 files changed, 1259 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/IR/ene_ir.c
create mode 100644 drivers/media/IR/ene_ir.h
diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index 99ea9cd..8390d3c 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -105,8 +105,19 @@ config IR_MCEUSB
To compile this driver as a module, choose M here: the
module will be called mceusb.
+config IR_ENE
+ tristate ENE eHome Receiver/Transciever (pnp id: ENE0100/ENE02xxx)
+ depends on PNP
+ depends on IR_CORE
+ ---help---
+ Say Y here to enable support for integrated infrared receiver
+ /transciever made by ENE.
+ You can see if you have it by looking at lspnp output.
+ Output should include ENE0100 ENE0200 or something similiar.
+ To compile this driver as a module, choose M here: the
+ module will be called ene_ir.
endif #IR_CORE
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 2ae4f3a..3262a68 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_IR_IMON) += imon.o
obj-$(CONFIG_IR_MCEUSB) += mceusb.o
+obj-$(CONFIG_IR_ENE) += ene_ir.o
diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
new file mode 100644
index 000..8b88dbd
--- /dev/null
+++ b/drivers/media/IR/ene_ir.c
@@ -0,0 +1,1019 @@
+/*
+ * driver for ENE KB3926 B/C/D CIR (pnp id: ENE0XXX)
+ *
+ * Copyright (C) 2010 Maxim Levitsky maximlevit...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pnp.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/sched.h
+#include linux/slab.h
+#include linux/input.h
+#include media/ir-core.h
+#include media/ir-common.h
+#include ene_ir.h
+
+
+static int sample_period = -1;
+static int enable_idle = 1;
+static int error_adjustment = 4;
+static int input = 1;
+static int debug;
+static int txsim;
+
+static int ene_irq_status(struct ene_device *dev);
+
+/* read a hardware register */
+static u8 ene_hw_read_reg(struct ene_device *dev, u16 reg)
+{
+ u8 retval;
+ outb(reg 8, dev-hw_io + ENE_ADDR_HI);
+ outb(reg 0xFF, dev-hw_io + ENE_ADDR_LO);
+ retval = inb(dev-hw_io + ENE_IO);
+
+ ene_dbg_verbose(reg %04x == %02x, reg, retval);
+ return retval;
+}
+
+/* write a hardware register */
+static void ene_hw_write_reg(struct ene_device *dev, u16 reg, u8 value)
+{
+ outb(reg 8, dev-hw_io + ENE_ADDR_HI);
+ outb(reg 0xFF, dev-hw_io + ENE_ADDR_LO);
+ outb(value, dev-hw_io + ENE_IO);
+
+ ene_dbg_verbose(reg %04x - %02x, reg, value);
+}
+
+/* change specific bits in hardware register */
+static void ene_hw_write_reg_mask(struct ene_device *dev,
+ u16 reg, u8 value, u8 mask)
+{
+ u8 regvalue;
+
+ outb(reg 8, dev-hw_io + ENE_ADDR_HI);
+ outb(reg 0xFF, dev-hw_io + ENE_ADDR_LO);
+
+ regvalue = inb(dev-hw_io + ENE_IO) ~mask;
+ regvalue |= (value mask);
+ outb(regvalue, dev-hw_io + ENE_IO);
+
+ ene_dbg_verbose(reg %04x - %02x (mask=%02x), reg, value, mask);
+}
+
+/* detect hardware features */
+static int ene_hw_detect(struct ene_device *dev)
+{
+ u8 chip_major, chip_minor;
+ u8 hw_revision, old_ver;
+ u8 tmp;
+ u8 fw_capabilities;
+
+ tmp = ene_hw_read_reg(dev, ENE_HW_UNK);
+ ene_hw_write_reg(dev, ENE_HW_UNK, tmp ~ENE_HW_UNK_CLR);
+
+ chip_major = ene_hw_read_reg(dev, ENE_HW_VER_MAJOR);
+ chip_minor = ene_hw_read_reg(dev, ENE_HW_VER_MINOR);
+
+ ene_hw_write_reg(dev, ENE_HW_UNK, tmp);
+ hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
+ old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
+
+ if (hw_revision == 0xFF) {
+
+ ene_printk(KERN_WARNING, device seems to be disabled\n);
Re: Can I expect in-kernel decoding to work out of box?
On Wed, Jul 28, 2010 at 10:41:27AM -0400, Jon Smirl wrote: On Wed, Jul 28, 2010 at 10:24 AM, Maxim Levitsky ... You are right that my remote has JVC protocol. (at least I am sure now it hasn't NEC, because repeat looks differently). My remote now actually partially works with JVC decoder, it decodes every other keypress. Still, no repeat is supported. It probably isn't implemented yet. Jarod has been focusing more on getting the basic decoders to work. More specifically, getting the basic decoders to work with very specific hardware -- i.e., the mceusb transceivers, and primarily focused only on RC-6(A) decode w/the mceusb bundled remotes. That, and getting the lirc bridge driver working for both rx and tx. Basically, my plan of attack has been to get enough bits in place that we have a reference implementation, if you will, of a driver that supports all in-kernel decoders and the lirc interface, complete with the ability to do tx[*], and from there, then we can really dig into the in-kernel decoders and/or work on porting additional drivers to ir-core. I'm more focused on porting additional drivers to ir-core at the moment than I am on testing all of the protocol decoders right now. [*] we still don't have an ir-core native tx method, but tx on the mceusb works quite well using the lirc bridge plugin -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
Em 28-07-2010 11:53, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote: Is JVC enabled by default? I recall analyzing that it could generate false positives on NEC codes. Hopefully the engines should differentiate the two. If the signal is really messed up it may trigger a response from both engines. That shouldn't be fatal at the higher layers, the wrong protocol would just be ignored. By default, both decoders are enabled, but if you're using the ir-keycode userspace program at udev, it will disable all protocols but the ones associated with the RC keytable loaded for that specific device. Even if both JVC and NEC decoders generate scancodes, it is very unlikely that the scancode generated by the wrong decoder would produce a valid scancode at the RC keycode space. I recommend that all decoders initially follow the strict protocol rules. That will let us find bugs like this one in the ENE driver. Agreed. After we get everything possible working under the strict rules we can loosen then up to allow out of spec devices. We might even end up with an IR-quirk driver that supports broken remotes. I think that the better is to add some parameters, via sysfs, to relax the rules at the current decoders, if needed. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
Em 28-07-2010 11:41, Jon Smirl escreveu: It's possible to build a Linux IR decoder engine that can be loaded with the old LIRC config files. I think it is a good idea to have a decoder that works with such files anyway. There are some good reasons for that, as it would allow in-kernel support for protocols that may have some patent restrictions on a few countries that allow patents on software. We'll need to discuss the API requirements for such decoder, in order to load the RC decoding code into it. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] IR: minor fixes:
Em 28-07-2010 12:14, Maxim Levitsky escreveu:
* lirc: Don't propagate reset event to userspace
* lirc: Remove strange logic from lirc that would make first sample always be
pulse
* Make TO_US macro actualy print what it should.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |3 +--
drivers/media/IR/ir-lirc-codec.c | 14 --
drivers/media/IR/ir-raw-event.c |3 +++
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index babd520..8ce80e4 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -76,7 +76,6 @@ struct ir_raw_event_ctrl {
struct lirc_codec {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
- int lircdata;
} lirc;
};
@@ -104,7 +103,7 @@ static inline void decrease_duration(struct ir_raw_event
*ev, unsigned duration)
ev-duration -= duration;
}
-#define TO_US(duration) (((duration) + 500) / 1000)
+#define TO_US(duration) ((duration) / 1000)
It is better to keep rounding the duration to its closest value.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] IR: replace spinlock with mutex.
Em 28-07-2010 12:14, Maxim Levitsky escreveu: Some handlers (lirc for example) allocates memory on initialization, doing so in atomic context is cumbersome. Fixes warning about sleeping function in atomic context. You should not replace it by a mutex, as the decoding code may happen during IRQ time on several drivers. If lirc is allocating memory, it should be using GFP_ATOMIC to avoid sleeping. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] IR: add helper functions for ir input devices that send ir timing data in small chunks, and alternation between pulses and spaces isn't guaranteed.
Em 28-07-2010 12:14, Maxim Levitsky escreveu:
Please provide a smaller subject. Feel free to add a more detailed description,
but
subjects longer then 74 bytes end by causing some troubles when using git
commands.
It would be nice to have a good description on this patch, as it provides a
method
for working around troubles found on problematic devices.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |1 +
drivers/media/IR/ir-keytable.c |2 +-
drivers/media/IR/ir-raw-event.c | 86
+++
include/media/ir-core.h | 24 +-
4 files changed, 109 insertions(+), 4 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 8ce80e4..3eafdb7 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -36,6 +36,7 @@ struct ir_raw_event_ctrl {
struct kfifokfifo; /* fifo for the
pulse/space durations */
ktime_t last_event; /* when last event
occurred */
enum raw_event_type last_type; /* last event type */
+ struct ir_raw_event current_sample; /* sample that is not
yet pushed to fifo */
struct input_dev*input_dev; /* pointer to the
parent input_dev */
u64 enabled_protocols; /* enabled raw
protocol decoders */
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 94a8577..34b9c07 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -428,7 +428,7 @@ static void ir_close(struct input_dev *input_dev)
*/
int __ir_input_register(struct input_dev *input_dev,
const struct ir_scancode_table *rc_tab,
- const struct ir_dev_props *props,
+ struct ir_dev_props *props,
const char *driver_name)
{
struct ir_input_dev *ir_dev;
Hmm... why are you removing const from ir_dev_props? This change seems
unrelated
with the patch description.
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index c6a80b3..bdf2ed8 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -129,6 +129,92 @@ int ir_raw_event_store_edge(struct input_dev *input_dev,
enum raw_event_type typ
EXPORT_SYMBOL_GPL(ir_raw_event_store_edge);
/**
+ * ir_raw_event_store_with_filter() - pass next pulse/space to decoders with
some processing
+ * @input_dev: the struct input_dev device descriptor
+ * @type:the type of the event that has occurred
+ *
+ * This routine (which may be called from an interrupt context) is used to
+ * store the beginning of an ir pulse or space (or the start/end of ir
+ * reception) for the raw ir decoding state machines.\
+ * This routine is intended for devices with limited internal buffer
+ * It automerges samples of same type, and handles timeouts
+ */
+int ir_raw_event_store_with_filter(struct input_dev *input_dev,
+ struct ir_raw_event *ev)
+{
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
+ struct ir_raw_event_ctrl *raw = ir-raw;
+
+ if (!ir-raw || !ir-props)
+ return -EINVAL;
+
+ /* Ignore spaces in idle mode */
+ if (ir-idle !ev-pulse)
+ return 0;
+ else if (ir-idle)
+ ir_raw_event_set_idle(input_dev, 0);
+
+ if (!raw-current_sample.duration) {
+ raw-current_sample = *ev;
+ } else if (ev-pulse == raw-current_sample.pulse) {
+ raw-current_sample.duration += ev-duration;
+ } else {
+ ir_raw_event_store(input_dev, raw-current_sample);
+ raw-current_sample = *ev;
+ }
+
+ /* Enter idle mode if nessesary */
+ if (!ev-pulse ir-props-timeout
+ raw-current_sample.duration = ir-props-timeout)
+ ir_raw_event_set_idle(input_dev, 1);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_store_with_filter);
+
+
+void ir_raw_event_set_idle(struct input_dev *input_dev, int idle)
+{
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
+ struct ir_raw_event_ctrl *raw = ir-raw;
+ ktime_t now;
+ u64 delta;
+
+ if (!ir-props)
+ return;
+
+ if (!ir-raw)
+ goto out;
+
+ if (idle) {
+ IR_dprintk(2, enter idle mode\n);
+ raw-last_event = ktime_get();
+ } else {
+ IR_dprintk(2, exit idle mode\n);
+
+ now = ktime_get();
+ delta = ktime_to_ns(ktime_sub(now, ir-raw-last_event));
+
+ WARN_ON(raw-current_sample.pulse);
+
+ raw-current_sample.duration =
+ min(raw-current_sample.duration + delta,
+
Re: [PATCH 4/9] IR: add helper functions for ir input devices that send ir timing data in small chunks, and alternation between pulses and spaces isn't guaranteed.
On Wed, 2010-07-28 at 13:09 -0300, Mauro Carvalho Chehab wrote:
Em 28-07-2010 12:14, Maxim Levitsky escreveu:
Please provide a smaller subject. Feel free to add a more detailed
description, but
subjects longer then 74 bytes end by causing some troubles when using git
commands.
I didn't intend that, I just keep forgetting to add a newline between
subject and description..
It would be nice to have a good description on this patch, as it provides a
method
for working around troubles found on problematic devices.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |1 +
drivers/media/IR/ir-keytable.c |2 +-
drivers/media/IR/ir-raw-event.c | 86
+++
include/media/ir-core.h | 24 +-
4 files changed, 109 insertions(+), 4 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h
b/drivers/media/IR/ir-core-priv.h
index 8ce80e4..3eafdb7 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -36,6 +36,7 @@ struct ir_raw_event_ctrl {
struct kfifokfifo; /* fifo for the
pulse/space durations */
ktime_t last_event; /* when last event
occurred */
enum raw_event_type last_type; /* last event type */
+ struct ir_raw_event current_sample; /* sample that is not
yet pushed to fifo */
struct input_dev*input_dev; /* pointer to the
parent input_dev */
u64 enabled_protocols; /* enabled raw
protocol decoders */
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 94a8577..34b9c07 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -428,7 +428,7 @@ static void ir_close(struct input_dev *input_dev)
*/
int __ir_input_register(struct input_dev *input_dev,
const struct ir_scancode_table *rc_tab,
- const struct ir_dev_props *props,
+ struct ir_dev_props *props,
const char *driver_name)
{
struct ir_input_dev *ir_dev;
Hmm... why are you removing const from ir_dev_props? This change seems
unrelated
with the patch description.
Because I add new field 'timeout' I intend to change it in runtime by
the driver.
Best regards,
Maxim Levitsky
diff --git a/drivers/media/IR/ir-raw-event.c
b/drivers/media/IR/ir-raw-event.c
index c6a80b3..bdf2ed8 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -129,6 +129,92 @@ int ir_raw_event_store_edge(struct input_dev
*input_dev, enum raw_event_type typ
EXPORT_SYMBOL_GPL(ir_raw_event_store_edge);
/**
+ * ir_raw_event_store_with_filter() - pass next pulse/space to decoders
with some processing
+ * @input_dev: the struct input_dev device descriptor
+ * @type: the type of the event that has occurred
+ *
+ * This routine (which may be called from an interrupt context) is used to
+ * store the beginning of an ir pulse or space (or the start/end of ir
+ * reception) for the raw ir decoding state machines.\
+ * This routine is intended for devices with limited internal buffer
+ * It automerges samples of same type, and handles timeouts
+ */
+int ir_raw_event_store_with_filter(struct input_dev *input_dev,
+ struct ir_raw_event *ev)
+{
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
+ struct ir_raw_event_ctrl *raw = ir-raw;
+
+ if (!ir-raw || !ir-props)
+ return -EINVAL;
+
+ /* Ignore spaces in idle mode */
+ if (ir-idle !ev-pulse)
+ return 0;
+ else if (ir-idle)
+ ir_raw_event_set_idle(input_dev, 0);
+
+ if (!raw-current_sample.duration) {
+ raw-current_sample = *ev;
+ } else if (ev-pulse == raw-current_sample.pulse) {
+ raw-current_sample.duration += ev-duration;
+ } else {
+ ir_raw_event_store(input_dev, raw-current_sample);
+ raw-current_sample = *ev;
+ }
+
+ /* Enter idle mode if nessesary */
+ if (!ev-pulse ir-props-timeout
+ raw-current_sample.duration = ir-props-timeout)
+ ir_raw_event_set_idle(input_dev, 1);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_store_with_filter);
+
+
+void ir_raw_event_set_idle(struct input_dev *input_dev, int idle)
+{
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
+ struct ir_raw_event_ctrl *raw = ir-raw;
+ ktime_t now;
+ u64 delta;
+
+ if (!ir-props)
+ return;
+
+ if (!ir-raw)
+ goto out;
+
+ if (idle) {
+ IR_dprintk(2, enter idle mode\n);
+ raw-last_event = ktime_get();
+ } else {
+ IR_dprintk(2, exit
Re: [PATCH 3/9] IR: replace spinlock with mutex.
On Wed, 2010-07-28 at 13:03 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 12:14, Maxim Levitsky escreveu: Some handlers (lirc for example) allocates memory on initialization, doing so in atomic context is cumbersome. Fixes warning about sleeping function in atomic context. You should not replace it by a mutex, as the decoding code may happen during IRQ time on several drivers. I though decoding code is run by a work queue? I don't see any atomic codepath here... If lirc is allocating memory, it should be using GFP_ATOMIC to avoid sleeping. If its really not possible, I can make lirc use GFP_ATOMIC. a bit ugly, but should work. Best regards, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] IR: minor fixes:
On Wed, 2010-07-28 at 13:01 -0300, Mauro Carvalho Chehab wrote:
Em 28-07-2010 12:14, Maxim Levitsky escreveu:
* lirc: Don't propagate reset event to userspace
* lirc: Remove strange logic from lirc that would make first sample always
be pulse
* Make TO_US macro actualy print what it should.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |3 +--
drivers/media/IR/ir-lirc-codec.c | 14 --
drivers/media/IR/ir-raw-event.c |3 +++
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h
b/drivers/media/IR/ir-core-priv.h
index babd520..8ce80e4 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -76,7 +76,6 @@ struct ir_raw_event_ctrl {
struct lirc_codec {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
- int lircdata;
} lirc;
};
@@ -104,7 +103,7 @@ static inline void decrease_duration(struct
ir_raw_event *ev, unsigned duration)
ev-duration -= duration;
}
-#define TO_US(duration)(((duration) + 500) / 1000)
+#define TO_US(duration)((duration) / 1000)
It is better to keep rounding the duration to its closest value.
But that breaks if duration is already at maximum. At that case,
you see usual signed int wrap from positive to negative, and abnormally
large space...
I didn't notice though that you do rounding here.
I replace that with something better.
Best regards,
Maxim Levitsky
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] IR: extend interfaces to support more device settings
Em 28-07-2010 12:14, Maxim Levitsky escreveu:
Also reuse LIRC_SET_MEASURE_CARRIER_MODE as LIRC_SET_LEARN_MODE
(LIRC_SET_LEARN_MODE will start carrier reports if possible, and
tune receiver to wide band mode)
This IOCTL isn't yet used by lirc, so this won't break userspace.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |2 +
drivers/media/IR/ir-lirc-codec.c | 100
++
include/media/ir-core.h | 11
include/media/lirc.h |4 +-
4 files changed, 105 insertions(+), 12 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 3eafdb7..4ed170d 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -77,6 +77,8 @@ struct ir_raw_event_ctrl {
struct lirc_codec {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
+ int timeout_report;
+ int carrier_low;
} lirc;
};
diff --git a/drivers/media/IR/ir-lirc-codec.c
b/drivers/media/IR/ir-lirc-codec.c
index 8ca01fd..0f3969c 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -96,13 +96,13 @@ out:
return ret;
}
-static long ir_lirc_ioctl(struct file *filep, unsigned int cmd, unsigned
long arg)
+static long ir_lirc_ioctl(struct file *filep, unsigned int cmd, unsigned
long __user arg)
{
struct lirc_codec *lirc;
struct ir_input_dev *ir_dev;
int ret = 0;
void *drv_data;
- unsigned long val;
+ unsigned long val = 0;
lirc = lirc_get_pdata(filep);
if (!lirc)
@@ -116,10 +116,21 @@ static long ir_lirc_ioctl(struct file *filep, unsigned
int cmd, unsigned long ar
switch (cmd) {
case LIRC_SET_TRANSMITTER_MASK:
+ case LIRC_SET_SEND_CARRIER:
+ case LIRC_SET_SEND_MODE:
+ case LIRC_SET_REC_TIMEOUT:
+ case LIRC_SET_REC_TIMEOUT_REPORTS:
+ case LIRC_SET_LEARN_MODE:
+ case LIRC_SET_REC_CARRIER:
+ case LIRC_SET_REC_CARRIER_RANGE:
+ case LIRC_SET_SEND_DUTY_CYCLE:
ret = get_user(val, (unsigned long *)arg);
if (ret)
return ret;
+ }
As, in all cases, the argument is an __u32, you can just use this, to
get
the arguments for all LIRC_SET_* cases:
if (_IOC_DIR(cmd) _IOC_WRITE) {
ret = get_user(val, (unsigned long *)arg);
if (ret)
return ret;
}
+ switch (cmd) {
+ case LIRC_SET_TRANSMITTER_MASK:
if (ir_dev-props ir_dev-props-s_tx_mask)
ret = ir_dev-props-s_tx_mask(drv_data, (u32)val);
else
@@ -127,10 +138,6 @@ static long ir_lirc_ioctl(struct file *filep, unsigned
int cmd, unsigned long ar
break;
case LIRC_SET_SEND_CARRIER:
- ret = get_user(val, (unsigned long *)arg);
- if (ret)
- return ret;
-
if (ir_dev-props ir_dev-props-s_tx_carrier)
ir_dev-props-s_tx_carrier(drv_data, (u32)val);
else
@@ -143,14 +150,75 @@ static long ir_lirc_ioctl(struct file *filep, unsigned
int cmd, unsigned long ar
break;
case LIRC_SET_SEND_MODE:
- ret = get_user(val, (unsigned long *)arg);
- if (ret)
- return ret;
-
if (val != (LIRC_MODE_PULSE LIRC_CAN_SEND_MASK))
return -EINVAL;
break;
+ case LIRC_GET_REC_RESOLUTION:
+ val = ir_dev-props-rx_resolution;
+ ret = put_user(val, (unsigned long *)arg);
+ break;
You can use something like this, to handle the LIRC_GET* cases:
switch (cmd) {
...
case LIRC_GET_REC_RESOLUTION:
val = ir_dev-props-rx_resolution;
break;
...
}
if (_IOC_DIR(cmd) _IOC_READ) {
ret = put_user(val, (unsigned long *)arg);
if (ret)
return ret;
}
+
+ case LIRC_SET_REC_TIMEOUT:
+ if (val ir_dev-props-min_timeout ||
+ val ir_dev-props-max_timeout)
+ return -EINVAL;
+
+ ir_dev-props-timeout = val;
+ break;
+
+ case LIRC_SET_REC_TIMEOUT_REPORTS:
+ ir_dev-raw-lirc.timeout_report = !!val;
+ return 0;
+
+ case LIRC_GET_MIN_TIMEOUT:
+
+ if (!ir_dev-props-max_timeout)
+ return -ENOSYS;
+
+ ret = put_user(ir_dev-props-min_timeout, (unsigned long
*)arg);
+ break;
+ case LIRC_GET_MAX_TIMEOUT:
+ if (!ir_dev-props-max_timeout)
+ return -ENOSYS;
+
+ ret =
Re: Can I expect in-kernel decoding to work out of box?
On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 11:53, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote: I recommend that all decoders initially follow the strict protocol rules. That will let us find bugs like this one in the ENE driver. Agreed. Well... I'd possibly make an exception for the protocols that have long-mark leaders. The actual long mark measurement can be far off from the protocol's specification and needs a larger tolerance (IMO). Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a protocol element that is 8 to 16 protocol time units long, doesn't make too much sense to me. If the remote has the basic protocol time unit off from our expectation, the error will likely be amplified in a long protocol elements and very much off our expectation. I think that the better is to add some parameters, via sysfs, to relax the rules at the current decoders, if needed. Is that worth the effort? It seems like only going half-way to an ultimate end state. crazy idea If you go through the effort of implementing fine grained controls (tweaking tolerances for this pulse type here or there), why not just implement a configurable decoding engine that takes as input: symbol definitions (pulse and space length specifications and tolerances) pulse train states allowed state transitions gap length decoded output data length and instantiates a decoder that follows a user-space provided specification? The user can write his own decoding engine specification in a text file, feed it into the kernel, and the kernel can implement it for him. /crazy idea OK, maybe that is a little too much time and effort. ;) Regards, Andy Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 28-07-2010 11:41, Jon Smirl escreveu: It's possible to build a Linux IR decoder engine that can be loaded with the old LIRC config files. I think it is a good idea to have a decoder that works with such files anyway. The recorder should use the Linux IR system to record the data. It would confusing to mix the systems. Users need to be really sure that the standard protocol decoders don't understand their protocol before resorting to this. Any one in this situation should post their recorded data so we can check for driver implementation errors. An example: if you use irrecord on Sony remotes lirc always records them in raw mode. The true problem here is that irrecord doesn't understand that Sony remotes mix different flavors of the Sony protocol on a single remote. This leads you to think that the Sony protocol engine is broken when it really isn't. It's the irrecord tool that is broken. The kernel IR system will decode these remotes correctly without resorting to raw mode. There are some good reasons for that, as it would allow in-kernel support for protocols that may have some patent restrictions on a few countries that allow patents on software. Are there any IR protocols less than 20 (or 17) years old? If they are older than that the patents have expired. I expect IR use to decline in the future, it will be replaced with RF4CE radio remotes. We'll need to discuss the API requirements for such decoder, in order to load the RC decoding code into it. Cheers, Mauro. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] IR: Add ENE input driver.
Em 28-07-2010 12:14, Maxim Levitsky escreveu: Signed-off-by: Maxim Levitsky maximlevit...@gmail.com Please, instead of patch 9/9, do a patch moving ENE driver from staging into drivers/media/IR, and then a patch porting it into rc-core. This will allow us to better understand what were done to convert it to rc-core, being an example for others that may work on porting the other drivers to rc-core. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] IR: Add ENE input driver.
On Wed, 2010-07-28 at 14:10 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 12:14, Maxim Levitsky escreveu: Signed-off-by: Maxim Levitsky maximlevit...@gmail.com Please, instead of patch 9/9, do a patch moving ENE driver from staging into drivers/media/IR, and then a patch porting it into rc-core. This will allow us to better understand what were done to convert it to rc-core, being an example for others that may work on porting the other drivers to rc-core. The version in staging is outdated. Should I first update it, and then move? Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for July 28 (lirc)
On Wed, 28 Jul 2010 16:28:55 +1000 Stephen Rothwell wrote: Hi all, Changes since 20100727: when CONFIG_MODULES is not enabled: drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration of function 'module_refcount' drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of function 'module_refcount' drivers/built-in.o: In function `it87_probe': lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev' lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev' drivers/built-in.o: In function `lirc_it87_exit': lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev' --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Wed, 2010-07-28 at 13:04 -0400, Jon Smirl wrote: On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 28-07-2010 11:41, Jon Smirl escreveu: Are there any IR protocols less than 20 (or 17) years old? If they are older than that the patents have expired. I expect IR use to decline in the future, it will be replaced with RF4CE radio remotes. UEI's XMP protocol for one, IIRC. UEI are the folks that sell/make OneForALL branded remotes. You can read about their patents' remaining lifetimes in this March 2010 SEC filing: http://www.faqs.org/sec-filings/100315/UNIVERSAL-ELECTRONICS-INC_10-K/ 1 to 18 years - that includes the ones they just bought from Zilog. That is not to say that all those patents cover protocols. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for July 28 (lirc #2)
On Wed, 28 Jul 2010 16:28:55 +1000 Stephen Rothwell wrote: Hi all, Changes since 20100727: When USB_SUPPORT is not enabled and MEDIA_SUPPORT is not enabled: ERROR: lirc_dev_fop_close [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: lirc_dev_fop_open [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: lirc_dev_fop_poll [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: lirc_dev_fop_write [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: lirc_dev_fop_read [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: usb_register_driver [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: lirc_register_driver [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: usb_string [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: usb_alloc_urb [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: usb_alloc_coherent [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: lirc_dev_fop_ioctl [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: lirc_get_pdata [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: usb_free_coherent [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: usb_free_urb [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: lirc_unregister_driver [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: usb_kill_urb [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: usb_submit_urb [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: usb_deregister [drivers/staging/lirc/lirc_streamzap.ko] undefined! ERROR: lirc_dev_fop_close [drivers/staging/lirc/lirc_sir.ko] undefined! ERROR: lirc_dev_fop_open [drivers/staging/lirc/lirc_sir.ko] undefined! ERROR: lirc_register_driver [drivers/staging/lirc/lirc_sir.ko] undefined! ERROR: lirc_unregister_driver [drivers/staging/lirc/lirc_sir.ko] undefined! --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] IR: Add ENE input driver.
On Wed, Jul 28, 2010 at 08:13:35PM +0300, Maxim Levitsky wrote: On Wed, 2010-07-28 at 14:10 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 12:14, Maxim Levitsky escreveu: Signed-off-by: Maxim Levitsky maximlevit...@gmail.com Please, instead of patch 9/9, do a patch moving ENE driver from staging into drivers/media/IR, and then a patch porting it into rc-core. This will allow us to better understand what were done to convert it to rc-core, being an example for others that may work on porting the other drivers to rc-core. The version in staging is outdated. D'oh, sorry about that. Should I first update it, and then move? Yeah, that sounds sane to me. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] IR: minor fixes:
On Wed, Jul 28, 2010 at 06:14:04PM +0300, Maxim Levitsky wrote: * lirc: Don't propagate reset event to userspace * lirc: Remove strange logic from lirc that would make first sample always be pulse * Make TO_US macro actualy print what it should. Signed-off-by: Maxim Levitsky maximlevit...@gmail.com For the ir-lirc-codec-specific bits: Acked-by: Jarod Wilson ja...@redhat.com I'm inclined to pull them into my tree now, and the IR_dprintk and TO_US portions can be handled separately. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 11:53, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote: I recommend that all decoders initially follow the strict protocol rules. That will let us find bugs like this one in the ENE driver. Agreed. Well... I'd possibly make an exception for the protocols that have long-mark leaders. The actual long mark measurement can be far off from the protocol's specification and needs a larger tolerance (IMO). Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a protocol element that is 8 to 16 protocol time units long, doesn't make too much sense to me. If the remote has the basic protocol time unit off from our expectation, the error will likely be amplified in a long protocol elements and very much off our expectation. Do you have a better way to differentiate JVC and NEC protocols? They are pretty similar except for the timings. What happened in this case was that the first signals matched the NEC protocol. Then we shifted to bits that matched JVC protocol. The NEC bits are 9000/8400 = 7% longer. If we allow more than a 3.5% error in the initial bit you can't separate the protocols. In general the decoders are pretty lax and the closest to the correct one with decode the stream. The 50% rule only comes into play between two very similar protocols. One solution would be to implement NEC/JVC in the same engine. Then apply the NEC consistency checks. If the consistency check pass present the event on the NEC interface. And then always present the event on the JVC interface. I think that the better is to add some parameters, via sysfs, to relax the rules at the current decoders, if needed. Is that worth the effort? It seems like only going half-way to an ultimate end state. crazy idea If you go through the effort of implementing fine grained controls (tweaking tolerances for this pulse type here or there), why not just implement a configurable decoding engine that takes as input: symbol definitions (pulse and space length specifications and tolerances) pulse train states allowed state transitions gap length decoded output data length and instantiates a decoder that follows a user-space provided specification? The user can write his own decoding engine specification in a text file, feed it into the kernel, and the kernel can implement it for him. /crazy idea OK, maybe that is a little too much time and effort. ;) Regards, Andy Cheers, Mauro -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] IR: Kconfig fixes
On Wed, 28 Jul 2010 18:14:03 +0300 Maxim Levitsky wrote: Move IR drives below separate menu. This allows to disable them. Also correct a typo. Signed-off-by: Maxim Levitsky maximlevit...@gmail.com --- drivers/media/IR/Kconfig | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig index e557ae0..99ea9cd 100644 --- a/drivers/media/IR/Kconfig +++ b/drivers/media/IR/Kconfig @@ -1,8 +1,10 @@ -config IR_CORE - tristate +menuconfig IR_CORE + tristate Infrared remote controller adapters depends on INPUT default INPUT +if IR_CORE + config VIDEO_IR tristate depends on IR_CORE @@ -16,7 +18,7 @@ config LIRC Enable this option to build the Linux Infrared Remote Control (LIRC) core device interface driver. The LIRC interface passes raw IR to and from userspace, where the -LIRC daemon handles protocol decoding for IR reception ann +LIRC daemon handles protocol decoding for IR reception and encoding for IR transmitting (aka blasting). source drivers/media/IR/keymaps/Kconfig @@ -102,3 +104,9 @@ config IR_MCEUSB To compile this driver as a module, choose M here: the module will be called mceusb. + + + + + +endif #IR_CORE I don't think that those extra blank lines are a fix... --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Wed, Jul 28, 2010 at 1:21 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 13:04 -0400, Jon Smirl wrote: On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 28-07-2010 11:41, Jon Smirl escreveu: Are there any IR protocols less than 20 (or 17) years old? If they are older than that the patents have expired. I expect IR use to decline in the future, it will be replaced with RF4CE radio remotes. UEI's XMP protocol for one, IIRC. The beauty of LIRC is that you can use any remote for input. If one remote's protocols are patented, just use another remote. Only in the case where we have to xmit the protocol is the patent conflict unavoidable. In that case we could resort to sending a raw pulse timing string that comes from user space. UEI are the folks that sell/make OneForALL branded remotes. You can read about their patents' remaining lifetimes in this March 2010 SEC filing: http://www.faqs.org/sec-filings/100315/UNIVERSAL-ELECTRONICS-INC_10-K/ 1 to 18 years - that includes the ones they just bought from Zilog. That is not to say that all those patents cover protocols. Regards, Andy -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] IR: replace spinlock with mutex.
On Wed, Jul 28, 2010 at 07:32:58PM +0300, Maxim Levitsky wrote: On Wed, 2010-07-28 at 13:03 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 12:14, Maxim Levitsky escreveu: Some handlers (lirc for example) allocates memory on initialization, doing so in atomic context is cumbersome. Fixes warning about sleeping function in atomic context. You should not replace it by a mutex, as the decoding code may happen during IRQ time on several drivers. I though decoding code is run by a work queue? Yeah, it is. (INIT_WORK(ir-raw-rx_work, ir_raw_event_work); in ir_raw_event_register). I don't see any atomic codepath here... I think the ir_raw_event_store variants are the only things that are run from an interrupt context, and none of them touch ir_raw_handler_lock. That lock is advertised as being for the protection of ir_raw_handler_list and ir_raw_client_list, which are primarily manipulated by register/unregister functions, and we just lock them when doing actual IR decode work (via said work queue) so we don't feed raw IR somewhere that we shouldn't. I think Maxim is correct here, we should be okay with changing this to a mutex, unless I'm missing something else. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] IR: add helper functions for ir input devices that send ir timing data in small chunks, and alternation between pulses and spaces isn't guaranteed.
On Wed, Jul 28, 2010 at 06:14:06PM +0300, Maxim Levitsky wrote: Signed-off-by: Maxim Levitsky maximlevit...@gmail.com With the caveat of requiring an improved changelog, per Mauro's suggestion: Acked-by: Jarod Wilson ja...@redhat.com I suspect at least some of this code may be of use to the streamzap driver as well (which I started looking at porting last night, despite my insistence that I was going to work on lirc_zilog first...). -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] IR: minor fixes:
Em 28-07-2010 13:38, Maxim Levitsky escreveu:
On Wed, 2010-07-28 at 13:01 -0300, Mauro Carvalho Chehab wrote:
Em 28-07-2010 12:14, Maxim Levitsky escreveu:
* lirc: Don't propagate reset event to userspace
* lirc: Remove strange logic from lirc that would make first sample always
be pulse
* Make TO_US macro actualy print what it should.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |3 +--
drivers/media/IR/ir-lirc-codec.c | 14 --
drivers/media/IR/ir-raw-event.c |3 +++
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h
b/drivers/media/IR/ir-core-priv.h
index babd520..8ce80e4 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -76,7 +76,6 @@ struct ir_raw_event_ctrl {
struct lirc_codec {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
- int lircdata;
} lirc;
};
@@ -104,7 +103,7 @@ static inline void decrease_duration(struct
ir_raw_event *ev, unsigned duration)
ev-duration -= duration;
}
-#define TO_US(duration)(((duration) + 500) / 1000)
+#define TO_US(duration)((duration) / 1000)
It is better to keep rounding the duration to its closest value.
But that breaks if duration is already at maximum. At that case,
you see usual signed int wrap from positive to negative, and abnormally
large space...
I didn't notice though that you do rounding here.
I replace that with something better.
There's a function for rounding at kernel. The better is to use it, as it
should already
solve the signal wrap.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
Em 28-07-2010 14:04, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 28-07-2010 11:41, Jon Smirl escreveu: It's possible to build a Linux IR decoder engine that can be loaded with the old LIRC config files. I think it is a good idea to have a decoder that works with such files anyway. The recorder should use the Linux IR system to record the data. It would confusing to mix the systems. Users need to be really sure that the standard protocol decoders don't understand their protocol before resorting to this. Any one in this situation should post their recorded data so we can check for driver implementation errors. An example: if you use irrecord on Sony remotes lirc always records them in raw mode. The true problem here is that irrecord doesn't understand that Sony remotes mix different flavors of the Sony protocol on a single remote. This leads you to think that the Sony protocol engine is broken when it really isn't. It's the irrecord tool that is broken. The kernel IR system will decode these remotes correctly without resorting to raw mode. A decoder like that should be a last-resort decoder, only in the cases where there's no other option. There are some good reasons for that, as it would allow in-kernel support for protocols that may have some patent restrictions on a few countries that allow patents on software. Are there any IR protocols less than 20 (or 17) years old? Yes. This protocol is brand new: https://www.smkusa.com/usa/technologies/qp/ And several new devices are starting to accept it. If they are older than that the patents have expired. I expect IR use to decline in the future, it will be replaced with RF4CE radio remotes. I expect so, but it will take some time until this transition happens. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] IR: actually allow not to compile keymaps in..
On Wed, Jul 28, 2010 at 06:14:08PM +0300, Maxim Levitsky wrote: Currntly, ir device registration fails if keymap requested by driver is not found... Fix that by always compiling in the empty keymap, and using it as a failback Signed-off-by: Maxim Levitsky maximlevit...@gmail.com I like this one, useful improvement, I think. We even get meaningful output logged as well -- get_rc_map() will let us know the initially requested keymap failed to load, and then will let us know whether or not the empty keymap loaded. Acked-by: Jarod Wilson ja...@redhat.com -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] IR: Add ENE input driver.
Em 28-07-2010 14:13, Maxim Levitsky escreveu: On Wed, 2010-07-28 at 14:10 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 12:14, Maxim Levitsky escreveu: Signed-off-by: Maxim Levitsky maximlevit...@gmail.com Please, instead of patch 9/9, do a patch moving ENE driver from staging into drivers/media/IR, and then a patch porting it into rc-core. This will allow us to better understand what were done to convert it to rc-core, being an example for others that may work on porting the other drivers to rc-core. The version in staging is outdated. Should I first update it, and then move? Yes, please. It shouldn't be hard to produce such patches, and this will help other developers when porting the other drivers. So, it may result on a some gain at the speed for the other ports. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Wed, Jul 28, 2010 at 03:08:13PM -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 14:04, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 28-07-2010 11:41, Jon Smirl escreveu: It's possible to build a Linux IR decoder engine that can be loaded with the old LIRC config files. I think it is a good idea to have a decoder that works with such files anyway. The recorder should use the Linux IR system to record the data. It would confusing to mix the systems. Users need to be really sure that the standard protocol decoders don't understand their protocol before resorting to this. Any one in this situation should post their recorded data so we can check for driver implementation errors. An example: if you use irrecord on Sony remotes lirc always records them in raw mode. The true problem here is that irrecord doesn't understand that Sony remotes mix different flavors of the Sony protocol on a single remote. This leads you to think that the Sony protocol engine is broken when it really isn't. It's the irrecord tool that is broken. The kernel IR system will decode these remotes correctly without resorting to raw mode. A decoder like that should be a last-resort decoder, only in the cases where there's no other option. There are some good reasons for that, as it would allow in-kernel support for protocols that may have some patent restrictions on a few countries that allow patents on software. Are there any IR protocols less than 20 (or 17) years old? Yes. This protocol is brand new: https://www.smkusa.com/usa/technologies/qp/ And several new devices are starting to accept it. The US patent appears to have been filed in 1995 and granted in 1997, so brand new is relative. ;) http://www.freepatentsonline.com/5640160.html We do have a few more years of being encumbered by it here in the US though. :( -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Wed, 2010-07-28 at 13:35 -0400, Jon Smirl wrote: On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 11:53, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote: I recommend that all decoders initially follow the strict protocol rules. That will let us find bugs like this one in the ENE driver. Agreed. Well... I'd possibly make an exception for the protocols that have long-mark leaders. The actual long mark measurement can be far off from the protocol's specification and needs a larger tolerance (IMO). Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a protocol element that is 8 to 16 protocol time units long, doesn't make too much sense to me. If the remote has the basic protocol time unit off from our expectation, the error will likely be amplified in a long protocol elements and very much off our expectation. Do you have a better way to differentiate JVC and NEC protocols? They are pretty similar except for the timings. Yes: Invoke the 80/20 rule and don't try. Enable NEC and disable JVC by default. Let the users know so as to properly manage user expectations. (Maxim's original question was about expectation.) When the user knows NEC isn't working, or he suspects JVC may work, he can bind that protocol to the particular IR receiver. Trying to solve the discrimination problem with blindly parallel decoding all the possible protocols is a big waste of effort IMO: a. Many remotes are sloppy and out of spec, and get worse with weak batteries. b. The IR receiver driver knows what remotes possibly came bundled with the hardware. (For the case of the MCE USB, it's almost always an RC-6 6A remote.) c. The user can tell the kernel about his remote unambiguously. There's no burning need to wear a blindfold, AFAICT, so let's not. Why bother to solve a hard problem (discrimination of protocols from out of spec remotes), when it raises the error rate of solving the simple one (properly decoding a single protocol)? Doing many things poorly is worse than doing one thing well. Non-adaptive protocol discovery (i.e. blind parallel decoding) should not be the default if it leads to problems or inflated expectations for the user. What happened in this case was that the first signals matched the NEC protocol. Then we shifted to bits that matched JVC protocol. The NEC bits are 9000/8400 = 7% longer. If we allow more than a 3.5% error in the initial bit you can't separate the protocols. In general the decoders are pretty lax and the closest to the correct one with decode the stream. The 50% rule only comes into play between two very similar protocols. One solution would be to implement NEC/JVC in the same engine. Then apply the NEC consistency checks. If the consistency check pass present the event on the NEC interface. And then always present the event on the JVC interface. It's just too simple to have the user: a. Try NEC b. Try JVC c. Make a judgment and stick with the one he perceives works. To have reliable discrimination in the general case between two protocols, given the variables out of our control (i.e. the remote control implementation) would require some sort of data collection and adaptive algorithm to go on inside the kernel. I don't think you can get reliable discrimination in one key press. Maybe by looking at the key press and the repeats together might up the probability of correct discrimination (that's one criterion you examined to make a determination in your earlier email). Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
Em 28-07-2010 14:02, Andy Walls escreveu: On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 11:53, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote: I recommend that all decoders initially follow the strict protocol rules. That will let us find bugs like this one in the ENE driver. Agreed. Well... I'd possibly make an exception for the protocols that have long-mark leaders. The actual long mark measurement can be far off from the protocol's specification and needs a larger tolerance (IMO). Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a protocol element that is 8 to 16 protocol time units long, doesn't make too much sense to me. If the remote has the basic protocol time unit off from our expectation, the error will likely be amplified in a long protocol elements and very much off our expectation. We may adjust it as we note problems on it, but relaxing rules may cause bad effects, so the better is to be more strict. I think that the better is to add some parameters, via sysfs, to relax the rules at the current decoders, if needed. Is that worth the effort? It seems like only going half-way to an ultimate end state. Well, let's see first if this is needed. Then, we take the decisions case by case. crazy idea If you go through the effort of implementing fine grained controls (tweaking tolerances for this pulse type here or there), why not just implement a configurable decoding engine that takes as input: symbol definitions (pulse and space length specifications and tolerances) pulse train states allowed state transitions gap length decoded output data length and instantiates a decoder that follows a user-space provided specification? The user can write his own decoding engine specification in a text file, feed it into the kernel, and the kernel can implement it for him. /crazy idea It is not a crazy idea, and perhaps this is the only way to work with certain protocols, like Quatro Pulse (see my previous email). But I think that we should still have the proper decoders for common protocols and that we won't have any legal restriction to implement a decoder. A generic decoder will be less efficient than OK, maybe that is a little too much time and effort. ;) Good point. Well, we'll need some volunteer to write such driver ;) Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
Em 28-07-2010 14:38, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 1:21 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 13:04 -0400, Jon Smirl wrote: On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 28-07-2010 11:41, Jon Smirl escreveu: Are there any IR protocols less than 20 (or 17) years old? If they are older than that the patents have expired. I expect IR use to decline in the future, it will be replaced with RF4CE radio remotes. UEI's XMP protocol for one, IIRC. The beauty of LIRC is that you can use any remote for input. If one remote's protocols are patented, just use another remote. Only in the case where we have to xmit the protocol is the patent conflict unavoidable. In that case we could resort to sending a raw pulse timing string that comes from user space. Well, software patents are valid only on very few Countries. People that live on a software-patent-free Country can keep using those protocols, if they can just upload a set of rules for a generic driver. On the other hand, a rule-hardcoded codec for a patented protocol cannot be inside Kernel, as this would restrict kernel distribution on those non-software-patent-free Countries. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] IR: replace spinlock with mutex.
Em 28-07-2010 14:43, Jarod Wilson escreveu: On Wed, Jul 28, 2010 at 07:32:58PM +0300, Maxim Levitsky wrote: On Wed, 2010-07-28 at 13:03 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 12:14, Maxim Levitsky escreveu: Some handlers (lirc for example) allocates memory on initialization, doing so in atomic context is cumbersome. Fixes warning about sleeping function in atomic context. You should not replace it by a mutex, as the decoding code may happen during IRQ time on several drivers. I though decoding code is run by a work queue? Yeah, it is. (INIT_WORK(ir-raw-rx_work, ir_raw_event_work); in ir_raw_event_register). I don't see any atomic codepath here... I think the ir_raw_event_store variants are the only things that are run from an interrupt context, and none of them touch ir_raw_handler_lock. That lock is advertised as being for the protection of ir_raw_handler_list and ir_raw_client_list, which are primarily manipulated by register/unregister functions, and we just lock them when doing actual IR decode work (via said work queue) so we don't feed raw IR somewhere that we shouldn't. I think Maxim is correct here, we should be okay with changing this to a mutex, unless I'm missing something else. You're probably right. The previous code used to do this at IRQ time, but a latter patch changed it to happen via a workqueue. So, I'm OK with this patch. Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
Em 28-07-2010 15:05, Jarod Wilson escreveu: On Wed, Jul 28, 2010 at 03:08:13PM -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 14:04, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 11:56 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 28-07-2010 11:41, Jon Smirl escreveu: It's possible to build a Linux IR decoder engine that can be loaded with the old LIRC config files. I think it is a good idea to have a decoder that works with such files anyway. The recorder should use the Linux IR system to record the data. It would confusing to mix the systems. Users need to be really sure that the standard protocol decoders don't understand their protocol before resorting to this. Any one in this situation should post their recorded data so we can check for driver implementation errors. An example: if you use irrecord on Sony remotes lirc always records them in raw mode. The true problem here is that irrecord doesn't understand that Sony remotes mix different flavors of the Sony protocol on a single remote. This leads you to think that the Sony protocol engine is broken when it really isn't. It's the irrecord tool that is broken. The kernel IR system will decode these remotes correctly without resorting to raw mode. A decoder like that should be a last-resort decoder, only in the cases where there's no other option. There are some good reasons for that, as it would allow in-kernel support for protocols that may have some patent restrictions on a few countries that allow patents on software. Are there any IR protocols less than 20 (or 17) years old? Yes. This protocol is brand new: https://www.smkusa.com/usa/technologies/qp/ And several new devices are starting to accept it. The US patent appears to have been filed in 1995 and granted in 1997, so brand new is relative. ;) Yes, I saw the patent timestamps too ;) Yet, AFAIK, they're starting to use this protocol on newer IR devices, so, we'll probably see some new devices using it. http://www.freepatentsonline.com/5640160.html We do have a few more years of being encumbered by it here in the US though. :( :( Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Pinnacle Systems, Inc. PCTV 330e 2.6.34 /dev/dvb
Hi, I have a: Bus 001 Device 006: ID 2304:0226 Pinnacle Systems, Inc. PCTV 330e inserted in a system with kernel 2.6.34. When plugged in, I get: [3639480.291662] em28xx: New device Pinnacle Systems PCTV 330e @ 480 Mbps (2304:0226, interface 0, class 0) [3639480.291870] em28xx #0: chip ID is em2882/em2883 [3639480.500623] em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 26 02 d0 12 5c 03 8e 16 a4 1c [3639480.501148] em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00 00 00 00 00 00 00 [3639480.501696] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b e0 00 00 [3639480.502241] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 00 00 00 00 00 00 [3639480.502739] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [3639480.503311] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [3639480.503839] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 50 00 69 00 [3639480.504279] em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 [3639480.504730] em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 00 00 16 03 [3639480.505182] em28xx #0: i2c eeprom 90: 50 00 43 00 54 00 56 00 20 00 33 00 33 00 30 00 [3639480.505628] em28xx #0: i2c eeprom a0: 65 00 00 00 1c 03 30 00 38 00 30 00 33 00 30 00 [3639480.506081] em28xx #0: i2c eeprom b0: 31 00 32 00 37 00 38 00 34 00 37 00 37 00 00 00 [3639480.506567] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [3639480.507060] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [3639480.507532] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [3639480.508003] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [3639480.508607] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x18b3a0bf [3639480.508692] em28xx #0: EEPROM info: [3639480.508769] em28xx #0: AC97 audio (5 sample rates) [3639480.508835] em28xx #0: 500mA max power [3639480.508898] em28xx #0: Table at 0x27, strings=0x168e, 0x1ca4, 0x246a [3639480.518750] em28xx #0: Identified as Pinnacle Hybrid Pro (2) (card=56) [3639480.518812] em28xx #0: [3639480.518813] [3639480.518900] em28xx #0: The support for this board weren't valid yet. [3639480.518950] em28xx #0: Please send a report of having this working [3639480.519003] em28xx #0: not to V4L mailing list (and/or to other addresses) [3639480.519005] [3639480.530412] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0) [3639480.553938] tuner 1-0061: chip found @ 0xc2 (em28xx #0) [3639480.574022] xc2028 1-0061: creating new instance [3639480.574082] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [3639480.574148] usb 1-1: firmware: requesting xc3028-v27.fw [3639480.602064] xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [3639480.661299] xc2028 1-0061: Loading firmware for type=BASE MTS (5), id . [3639481.581015] xc2028 1-0061: Loading firmware for type=MTS (4), id b700. [3639481.595642] xc2028 1-0061: Loading SCODE for type=MTS LCD NOGD MONO IF SCODE HAS_IF_4500 (6002b004), id b700. [3639481.811392] em28xx #0: Config register raw data: 0xd0 [3639481.812138] em28xx #0: AC97 vendor ID = 0x [3639481.812513] em28xx #0: AC97 features = 0x6a90 [3639481.812579] em28xx #0: Empia 202 AC97 audio processor detected [3639481.981768] tvp5150 1-005c: tvp5150am1 detected. [3639482.082272] em28xx #0: v4l2 driver version 0.1.2 [3639482.188623] em28xx #0: V4L2 video device registered as video1 [3639482.188700] em28xx #0: V4L2 VBI device registered as vbi0 [3639482.201320] usbcore: registered new interface driver em28xx [3639482.201419] em28xx driver loaded [3639482.203450] Em28xx: Initialized (Em28xx dvb Extension) extension [3639482.229668] em28xx-audio.c: probing for em28x1 non standard usbaudio [3639482.229731] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [3639482.230065] Em28xx: Initialized (Em28xx Audio Extension) extension [3639482.341779] tvp5150 1-005c: tvp5150am1 detected. [3639482.561905] tvp5150 1-005c: tvp5150am1 detected. Now all kinds of devices appear then: crw-rw 1 root video81, 2 Jul 28 20:59 vbi0 crw-rw-rw- 1 root video81, 1 Jul 28 20:59 video1 crw--- 1 root root189, 5 Jul 28 20:59 usbdev1.6 drwxr-xr-x 2 root root 240 Jul 28 20:59 snd crw-rw 1 root audio14, 36 Jul 28 20:59 audio2 crw-rw 1 root audio14, 35 Jul 28 20:59 dsp2 crw-rw 1 root audio14, 32 Jul 28 20:59 mixer2 but one important thing is missing: /dev/dvb ! I think all appropriate modules are loaded: em28xx_alsa 5606 0 em28xx_dvb 6740 0 tuner_xc2028 16229 1 em28xx 77411 2 em28xx_alsa,em28xx_dvb dvb_ttusb_budget 14285 0 saa711511969 0 saa7134_dvb19581 0 videobuf_dvb4282 1 saa7134_dvb saa7134
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Jul 28 19:00:24 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
Andy, Em 28-07-2010 15:18, Andy Walls escreveu: On Wed, 2010-07-28 at 13:35 -0400, Jon Smirl wrote: On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 11:53, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote: I recommend that all decoders initially follow the strict protocol rules. That will let us find bugs like this one in the ENE driver. Agreed. Well... I'd possibly make an exception for the protocols that have long-mark leaders. The actual long mark measurement can be far off from the protocol's specification and needs a larger tolerance (IMO). Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a protocol element that is 8 to 16 protocol time units long, doesn't make too much sense to me. If the remote has the basic protocol time unit off from our expectation, the error will likely be amplified in a long protocol elements and very much off our expectation. Do you have a better way to differentiate JVC and NEC protocols? They are pretty similar except for the timings. Yes: Invoke the 80/20 rule and don't try. At the room where my computers is located, I have two wide fluorescent lamps each with 20W. If I don't hide the IR sensors bellow my desk, those lamps are enough to generate random flickers at the sensors. With the more relaxed driver we used to have at saa7134, it ended by producing random scancodes, or, even worse, random repeat codes. So, lots of false-positive events. It is a way worse to have false-positive than having a false-negative events. So, I don't think it is a good idea to use a relaxed mode by default. Enable NEC and disable JVC by default. Let the users know so as to properly manage user expectations. (Maxim's original question was about expectation.) We should discuss a little bit about RC subsystem evolution during LPC/2010, but, from my point of view, we should soon deprecate the in-kernel keymap tables on some new kernel version, using, instead, the ir-keycode application to dynamically load the keycode tables via UDEV. Of course, after some time, we may end by removing all those tables from the kernel. So, assuming that we follow this patch, what we'll have for a newer device is: For most devices, the keymap configuration table (rc_maps.cfg) will associate all known devices with their corresponding keytable (we still need to generate a default rc_maps.cfg that corresponds to the current in-kernel mapping, but this is trivial). As ir-keytable disables all protocols but the one(s) needed by a given device, in practice, if the scancode table specifies a NEC keymap table, JVC will be disabled. If the table is for JVC, NEC will be disabled. So, this already happens in a practical scenario, as all decoders will be enabled only before loading a keymap (or if the user explicitly enable the other decoders). So, the device will be in some sort of training mode, e. g. it will try every possible decoder, and will be generating the scancodes for some userspace application that will be learning the keycodes and creating a keymap table. IMO, we should have a way to tell the RC and/or the decoding subsystem to work on a relaxed mode only when the user (or the userspace app) detects that there's something wrong with that device. When the user knows NEC isn't working, or he suspects JVC may work, he can bind that protocol to the particular IR receiver. Trying to solve the discrimination problem with blindly parallel decoding all the possible protocols is a big waste of effort IMO: a. Many remotes are sloppy and out of spec, and get worse with weak batteries. b. The IR receiver driver knows what remotes possibly came bundled with the hardware. (For the case of the MCE USB, it's almost always an RC-6 6A remote.) c. The user can tell the kernel about his remote unambiguously. There's no burning need to wear a blindfold, AFAICT, so let's not. Why bother to solve a hard problem (discrimination of protocols from out of spec remotes), when it raises the error rate of solving the simple one (properly decoding a single protocol)? Doing many things poorly is worse than doing one thing well. Non-adaptive protocol discovery (i.e. blind parallel decoding) should not be the default if it leads to problems or inflated expectations for the user. What happened in this case was that the first signals matched the NEC protocol. Then we shifted to bits that matched JVC protocol. The NEC bits are 9000/8400 = 7% longer. If we allow more than a 3.5% error in the initial bit you can't separate the protocols. In general the decoders are pretty lax and the closest to the correct one with decode the stream. The 50% rule only comes into play between two very similar protocols. One solution would be to
Re: Can I expect in-kernel decoding to work out of box?
On Wed, 2010-07-28 at 17:13 -0300, Mauro Carvalho Chehab wrote: Andy, Em 28-07-2010 15:18, Andy Walls escreveu: On Wed, 2010-07-28 at 13:35 -0400, Jon Smirl wrote: On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 11:53, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote: I recommend that all decoders initially follow the strict protocol rules. That will let us find bugs like this one in the ENE driver. Agreed. Well... I'd possibly make an exception for the protocols that have long-mark leaders. The actual long mark measurement can be far off from the protocol's specification and needs a larger tolerance (IMO). Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a protocol element that is 8 to 16 protocol time units long, doesn't make too much sense to me. If the remote has the basic protocol time unit off from our expectation, the error will likely be amplified in a long protocol elements and very much off our expectation. Do you have a better way to differentiate JVC and NEC protocols? They are pretty similar except for the timings. Yes: Invoke the 80/20 rule and don't try. At the room where my computers is located, I have two wide fluorescent lamps each with 20W. If I don't hide the IR sensors bellow my desk, those lamps are enough to generate random flickers at the sensors. With the more relaxed driver we used to have at saa7134, it ended by producing random scancodes, or, even worse, random repeat codes. So, lots of false-positive events. It is a way worse to have false-positive than having a false-negative events. So, I don't think it is a good idea to use a relaxed mode by default. Enable NEC and disable JVC by default. Let the users know so as to properly manage user expectations. (Maxim's original question was about expectation.) We should discuss a little bit about RC subsystem evolution during LPC/2010, but, from my point of view, we should soon deprecate the in-kernel keymap tables on some new kernel version, using, instead, the ir-keycode application to dynamically load the keycode tables via UDEV. Of course, after some time, we may end by removing all those tables from the kernel. /me is very happy about it. The reason isn't even about size or some principle. These keymaps just increase compilation time too much... So, assuming that we follow this patch, what we'll have for a newer device is: For most devices, the keymap configuration table (rc_maps.cfg) will associate all known devices with their corresponding keytable (we still need to generate a default rc_maps.cfg that corresponds to the current in-kernel mapping, but this is trivial). As ir-keytable disables all protocols but the one(s) needed by a given device, in practice, if the scancode table specifies a NEC keymap table, JVC will be disabled. If the table is for JVC, NEC will be disabled. So, this already happens in a practical scenario, as all decoders will be enabled only before loading a keymap (or if the user explicitly enable the other decoders). So, the device will be in some sort of training mode, e. g. it will try every possible decoder, and will be generating the scancodes for some userspace application that will be learning the keycodes and creating a keymap table. IMO, we should have a way to tell the RC and/or the decoding subsystem to work on a relaxed mode only when the user (or the userspace app) detects that there's something wrong with that device. When the user knows NEC isn't working, or he suspects JVC may work, he can bind that protocol to the particular IR receiver. Trying to solve the discrimination problem with blindly parallel decoding all the possible protocols is a big waste of effort IMO: a. Many remotes are sloppy and out of spec, and get worse with weak batteries. b. The IR receiver driver knows what remotes possibly came bundled with the hardware. (For the case of the MCE USB, it's almost always an RC-6 6A remote.) c. The user can tell the kernel about his remote unambiguously. There's no burning need to wear a blindfold, AFAICT, so let's not. Why bother to solve a hard problem (discrimination of protocols from out of spec remotes), when it raises the error rate of solving the simple one (properly decoding a single protocol)? Doing many things poorly is worse than doing one thing well. Non-adaptive protocol discovery (i.e. blind parallel decoding) should not be the default if it leads to problems or inflated expectations for the user. What happened in this case was that the first signals matched the NEC protocol. Then we shifted to bits that matched JVC protocol. The NEC
Re: [PATCH 1/9] IR: Kconfig fixes
On Wed, 2010-07-28 at 10:36 -0700, Randy Dunlap wrote: On Wed, 28 Jul 2010 18:14:03 +0300 Maxim Levitsky wrote: Move IR drives below separate menu. This allows to disable them. Also correct a typo. Signed-off-by: Maxim Levitsky maximlevit...@gmail.com --- drivers/media/IR/Kconfig | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig index e557ae0..99ea9cd 100644 --- a/drivers/media/IR/Kconfig +++ b/drivers/media/IR/Kconfig @@ -1,8 +1,10 @@ -config IR_CORE - tristate +menuconfig IR_CORE + tristate Infrared remote controller adapters depends on INPUT default INPUT +if IR_CORE + config VIDEO_IR tristate depends on IR_CORE @@ -16,7 +18,7 @@ config LIRC Enable this option to build the Linux Infrared Remote Control (LIRC) core device interface driver. The LIRC interface passes raw IR to and from userspace, where the - LIRC daemon handles protocol decoding for IR reception ann + LIRC daemon handles protocol decoding for IR reception and encoding for IR transmitting (aka blasting). source drivers/media/IR/keymaps/Kconfig @@ -102,3 +104,9 @@ config IR_MCEUSB To compile this driver as a module, choose M here: the module will be called mceusb. + + + + + +endif #IR_CORE I don't think that those extra blank lines are a fix... Sure. This patch series wasn't meant to be prefect, I rushed it a bit out of dour. When I split the patches, I forgot to remove that whitespace. Other that that, any more comments? Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] IR: extend interfaces to support more device settings
On Wed, Jul 28, 2010 at 06:14:07PM +0300, Maxim Levitsky wrote: Also reuse LIRC_SET_MEASURE_CARRIER_MODE as LIRC_SET_LEARN_MODE (LIRC_SET_LEARN_MODE will start carrier reports if possible, and tune receiver to wide band mode) This IOCTL isn't yet used by lirc, so this won't break userspace. Plus, once lirc 0.8.7 is released (Real Soon Now), we'll start working on lirc 0.9.0 with the express goal of it being built against lirc.h as provided by the kernel. These all generally look good and sane to me, and I'll make use of the LEARN_MODE bits for mceusb after something along these lines is committed. I like the simplifications Mauro suggested for the ioctl handling. In addition to those, there's a bit of whitespace damage in lirc.h that I'd like to see cleaned up for v2. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] IR: add helper functions for ir input devices that send ir timing data in small chunks, and alternation between pulses and spaces isn't guaranteed.
On Wed, Jul 28, 2010 at 01:46:27PM -0400, Jarod Wilson wrote: On Wed, Jul 28, 2010 at 06:14:06PM +0300, Maxim Levitsky wrote: Signed-off-by: Maxim Levitsky maximlevit...@gmail.com With the caveat of requiring an improved changelog, per Mauro's suggestion: Acked-by: Jarod Wilson ja...@redhat.com I suspect at least some of this code may be of use to the streamzap driver as well (which I started looking at porting last night, despite my insistence that I was going to work on lirc_zilog first...). One other note: idle looks like it can happily exist as a bool instead of as an int, no? -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] IR: add helper functions for ir input devices that send ir timing data in small chunks, and alternation between pulses and spaces isn't guaranteed.
On Wed, 2010-07-28 at 16:57 -0400, Jarod Wilson wrote: On Wed, Jul 28, 2010 at 01:46:27PM -0400, Jarod Wilson wrote: On Wed, Jul 28, 2010 at 06:14:06PM +0300, Maxim Levitsky wrote: Signed-off-by: Maxim Levitsky maximlevit...@gmail.com With the caveat of requiring an improved changelog, per Mauro's suggestion: Acked-by: Jarod Wilson ja...@redhat.com I suspect at least some of this code may be of use to the streamzap driver as well (which I started looking at porting last night, despite my insistence that I was going to work on lirc_zilog first...). One other note: idle looks like it can happily exist as a bool instead of as an int, no? sure. I have a problem with this code however, I just discovered. I pretty much don't know how to solve it currently... I just posted a mail about it. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
Em 28-07-2010 18:01, Maxim Levitsky escreveu: On Wed, 2010-07-28 at 17:24 +0300, Maxim Levitsky wrote: On Wed, 2010-07-28 at 10:13 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 07:40, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 2:30 AM, Maxim Levitsky maximlevit...@gmail.com wrote: On Tue, 2010-07-27 at 22:33 -0400, Jarod Wilson wrote: On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl jonsm...@gmail.com wrote: No its not, its just extended NEC. http://www.sbprojects.com/knowledge/ir/nec.htm Says the last two bytes should be the complement of each other. So for extended NEC it would need to be: 1100 0010 1010 0101 instead of 1100 0010 1010 0100 The last bit is wrong. From the debug output it is decoding as NEC, but then it fails a consistency check. Maybe we need to add a new protocol that lets NEC commands through even if they fail the error checks. Assuming that Maxim's IR receiver is not causing some bad decode at the NEC code, it seems simpler to add a parameter at sysfs to relax the NEC detection. We should add some way, at the userspace table for those RC's that uses a NEC-like code. There's another alternative: currently, the NEC decoder produces a 16 bits code for NEC and a 24 bits for NEC-extended code. The decoder may return a 32 bits code when none of the checksum's match the NEC or NEC-extended standard. Such 32 bits code won't match a keycode on a 16-bits or 24-bits table, so there's no risk of generating a wrong keycode, if the wrong consistent check is due to a reception error. Btw, we still need to port rc core to use the new tables ioctl's, as cleaning all keycodes on a 32 bits table would take forever with the current input events ioctls. It may also be that the NEC machine rejected it because the timing was so far off that it concluded that it couldn't be a NEC messages. The log didn't include the exact reason it got rejected. Add some printks at the end of the NEC machine to determine the exact reason for rejection. The better is to discard the possibility of a timing issue before changing the decoder to accept NEC-like codes without consistency checks. The current state machines enforce protocol compliance so there are probably a lot of older remotes that won't decode right. We can use some help in adjusting the state machines to let out of spec codes through. Yes, but we should take some care to avoid having another protocol decoder to interpret badly a different protocol. So, I think that the decoders may have some sysfs nodes to tweak the decoders to accept those older remotes. We'll need a consistent way to add some logic at the remotes keycodes used by ir-keycode, in order to allow it to tweak the decoder when a keycode table for such remote is loaded into the driver. User space lirc is much older. Bugs like this have been worked out of it. It will take some time to get the kernel implementation up to the same level. True. I more or less got to the bottom of this. It turns out that ENE reciever has a non linear measurement error. That is the longer sample is, the larger error it contains. Substracting around 4% from the samples makes the output look much more standard compliant. You are right that my remote has JVC protocol. (at least I am sure now it hasn't NEC, because repeat looks differently). My remote now actually partially works with JVC decoder, it decodes every other keypress. Still, no repeat is supported. However, all recievers (and transmitters) aren't perfect. Thats why I prefer lirc, because it makes no assumptions about protocol, so it can be 'trained' to work with any remote, and under very large range of error tolerances. Best regards, Maxim Levitsky I think I found the reason behind some of incorrect behavior. I see that in-kernel decoding is unhappy about the way I process gaps. I do exactly the same I did in lirc driver. At the end of keypress, the driver receives series of spaces from hardware. I accumulate 'em until patience^Wtimeout runs out. Then I put hardware in 'idle' mode, and remember current time. As soon as I get new pulse, I send a sum of accumulated same and time difference to user. Therefore every keypress ends with a pulse, and starts with space. But in-kernel decoding isn't happy about it, it seems.. at least NEC decoder... How you think to solve that? Fix in-kernel decoders maybe? Just send whatever you receive from hardware to the decoders. both LIRC and decoders have already a code to handle the timeouts. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for July 28 (lirc #2)
On Wed, Jul 28, 2010 at 10:24:17AM -0700, Randy Dunlap wrote: On Wed, 28 Jul 2010 16:28:55 +1000 Stephen Rothwell wrote: Hi all, Changes since 20100727: When USB_SUPPORT is not enabled and MEDIA_SUPPORT is not enabled: following patch should fix it Janne From 7d1cc98c19a6c27dd74a28f04dfe4248a0b335ce Mon Sep 17 00:00:00 2001 From: Janne Grunau j...@jannau.net Date: Wed, 28 Jul 2010 23:53:35 +0200 Subject: [PATCH 1/2] staging/lirc: fix Kconfig dependencies Signed-off-by: Janne Grunau j...@jannau.net --- drivers/staging/lirc/Kconfig | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) diff --git a/drivers/staging/lirc/Kconfig b/drivers/staging/lirc/Kconfig index 968c2ade..3981a4a 100644 --- a/drivers/staging/lirc/Kconfig +++ b/drivers/staging/lirc/Kconfig @@ -13,13 +13,13 @@ if LIRC_STAGING config LIRC_BT829 tristate BT829 based hardware - depends on LIRC_STAGING + depends on LIRC LIRC_STAGING help Driver for the IR interface on BT829-based hardware config LIRC_ENE0100 tristate ENE KB3924/ENE0100 CIR Port Reciever - depends on LIRC_STAGING + depends on LIRC LIRC_STAGING help This is a driver for CIR port handled by ENE KB3924 embedded controller found on some notebooks. @@ -27,20 +27,20 @@ config LIRC_ENE0100 config LIRC_I2C tristate I2C Based IR Receivers - depends on LIRC_STAGING + depends on I2C LIRC LIRC_STAGING help Driver for I2C-based IR receivers, such as those commonly found onboard Hauppauge PVR-150/250/350 video capture cards config LIRC_IGORPLUGUSB tristate Igor Cesko's USB IR Receiver - depends on LIRC_STAGING USB + depends on USB LIRC LIRC_STAGING USB help Driver for Igor Cesko's USB IR Receiver config LIRC_IMON tristate Legacy SoundGraph iMON Receiver and Display - depends on LIRC_STAGING + depends on LIRC LIRC_STAGING help Driver for the original SoundGraph iMON IR Receiver and Display @@ -48,31 +48,31 @@ config LIRC_IMON config LIRC_IT87 tristate ITE IT87XX CIR Port Receiver - depends on LIRC_STAGING + depends on LIRC LIRC_STAGING help Driver for the ITE IT87xx IR Receiver config LIRC_ITE8709 tristate ITE8709 CIR Port Receiver - depends on LIRC_STAGING PNP + depends on LIRC LIRC_STAGING PNP help Driver for the ITE8709 IR Receiver config LIRC_PARALLEL tristate Homebrew Parallel Port Receiver - depends on LIRC_STAGING !SMP + depends on LIRC LIRC_STAGING !SMP help Driver for Homebrew Parallel Port Receivers config LIRC_SASEM tristate Sasem USB IR Remote - depends on LIRC_STAGING + depends on USB LIRC LIRC_STAGING help Driver for the Sasem OnAir Remocon-V or Dign HV5 HTPC IR/VFD Module config LIRC_SERIAL tristate Homebrew Serial Port Receiver - depends on LIRC_STAGING + depends on LIRC LIRC_STAGING help Driver for Homebrew Serial Port Receivers @@ -85,25 +85,25 @@ config LIRC_SERIAL_TRANSMITTER config LIRC_SIR tristate Built-in SIR IrDA port - depends on LIRC_STAGING + depends on LIRC LIRC_STAGING help Driver for the SIR IrDA port config LIRC_STREAMZAP tristate Streamzap PC Receiver - depends on LIRC_STAGING + depends on USB LIRC LIRC_STAGING help Driver for the Streamzap PC Receiver config LIRC_TTUSBIR tristate Technotrend USB IR Receiver - depends on LIRC_STAGING USB + depends on USB LIRC LIRC_STAGING USB help Driver for the Technotrend USB IR Receiver config LIRC_ZILOG tristate Zilog/Hauppauge IR Transmitter - depends on LIRC_STAGING + depends on I2C LIRC LIRC_STAGING help Driver for the Zilog/Hauppauge IR Transmitter, found on PVR-150/500, HVR-1200/1250/1700/1800, HD-PVR and other cards -- 1.7.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Subject: [PATCH 0/9 v2] IR: few fixes, additions and ENE driver Hi, This is second version of the patchset. Hopefully, I didn't forget to address all comments. In addition to comments, I changed helper function that processes samples so it sends last space as soon as timeout is reached. This breaks somewhat lirc, because now it gets 2 spaces in row. However, if it uses timeout reports (which are now fully supported) it will get such report in middle. Note that I send timeout report with zero value. I don't think that this value is importaint. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] IR: Kconfig fixes
Move IR drives below separate menu. This allows to disable them. Also correct a typo. Signed-off-by: Maxim Levitsky maximlevit...@gmail.com --- drivers/media/IR/Kconfig | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig index e557ae0..fc48a3f 100644 --- a/drivers/media/IR/Kconfig +++ b/drivers/media/IR/Kconfig @@ -1,8 +1,10 @@ -config IR_CORE - tristate +menuconfig IR_CORE + tristate Infrared remote controller adapters depends on INPUT default INPUT +if IR_CORE + config VIDEO_IR tristate depends on IR_CORE @@ -16,7 +18,7 @@ config LIRC Enable this option to build the Linux Infrared Remote Control (LIRC) core device interface driver. The LIRC interface passes raw IR to and from userspace, where the - LIRC daemon handles protocol decoding for IR reception ann + LIRC daemon handles protocol decoding for IR reception and encoding for IR transmitting (aka blasting). source drivers/media/IR/keymaps/Kconfig @@ -102,3 +104,5 @@ config IR_MCEUSB To compile this driver as a module, choose M here: the module will be called mceusb. + +endif #IR_CORE -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] IR: minor fixes:
* lirc: Don't propagate reset event to userspace
* lirc: Remove strange logic from lirc that would make first sample always be
pulse
* Make TO_US macro actualy print what it should.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |4 +---
drivers/media/IR/ir-lirc-codec.c | 14 --
drivers/media/IR/ir-raw-event.c |3 +++
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index babd520..dc26e2b 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -76,7 +76,6 @@ struct ir_raw_event_ctrl {
struct lirc_codec {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
- int lircdata;
} lirc;
};
@@ -104,10 +103,9 @@ static inline void decrease_duration(struct ir_raw_event
*ev, unsigned duration)
ev-duration -= duration;
}
-#define TO_US(duration)(((duration) + 500) / 1000)
+#define TO_US(duration)DIV_ROUND_CLOSEST((duration),
1000)
#define TO_STR(is_pulse) ((is_pulse) ? pulse : space)
#define IS_RESET(ev) (ev.duration == 0)
-
/*
* Routines from ir-sysfs.c - Meant to be called only internally inside
* ir-core
diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c
index 3ba482d..8ca01fd 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -32,6 +32,7 @@
static int ir_lirc_decode(struct input_dev *input_dev, struct ir_raw_event ev)
{
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
+ int sample;
if (!(ir_dev-raw-enabled_protocols IR_TYPE_LIRC))
return 0;
@@ -39,18 +40,21 @@ static int ir_lirc_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
if (!ir_dev-raw-lirc.drv || !ir_dev-raw-lirc.drv-rbuf)
return -EINVAL;
+ if (IS_RESET(ev))
+ return 0;
+
IR_dprintk(2, LIRC data transfer started (%uus %s)\n,
TO_US(ev.duration), TO_STR(ev.pulse));
- ir_dev-raw-lirc.lircdata += ev.duration / 1000;
+
+ sample = ev.duration / 1000;
if (ev.pulse)
- ir_dev-raw-lirc.lircdata |= PULSE_BIT;
+ sample |= PULSE_BIT;
lirc_buffer_write(ir_dev-raw-lirc.drv-rbuf,
- (unsigned char *) ir_dev-raw-lirc.lircdata);
+ (unsigned char *) sample);
wake_up(ir_dev-raw-lirc.drv-rbuf-wait_poll);
- ir_dev-raw-lirc.lircdata = 0;
return 0;
}
@@ -224,8 +228,6 @@ static int ir_lirc_register(struct input_dev *input_dev)
ir_dev-raw-lirc.drv = drv;
ir_dev-raw-lirc.ir_dev = ir_dev;
- ir_dev-raw-lirc.lircdata = PULSE_MASK;
-
return 0;
lirc_register_failed:
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index 6f192ef..ab9c4da 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -66,6 +66,9 @@ int ir_raw_event_store(struct input_dev *input_dev, struct
ir_raw_event *ev)
if (!ir-raw)
return -EINVAL;
+ IR_dprintk(2, sample: (05%dus %s)\n, TO_US(ev-duration),
+ TO_STR(ev-pulse));
+
if (kfifo_in(ir-raw-kfifo, ev, sizeof(*ev)) != sizeof(*ev))
return -ENOMEM;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] IR: replace spinlock with mutex.
Some handlers (lirc for example) allocates memory on initialization,
doing so in atomic context is cumbersome.
Fixes warning about sleeping function in atomic context.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-raw-event.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index ab9c4da..c6a80b3 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -13,7 +13,7 @@
*/
#include linux/workqueue.h
-#include linux/spinlock.h
+#include linux/mutex.h
#include linux/sched.h
#include ir-core-priv.h
@@ -24,7 +24,7 @@
static LIST_HEAD(ir_raw_client_list);
/* Used to handle IR raw handler extensions */
-static DEFINE_SPINLOCK(ir_raw_handler_lock);
+static DEFINE_MUTEX(ir_raw_handler_lock);
static LIST_HEAD(ir_raw_handler_list);
static u64 available_protocols;
@@ -41,10 +41,10 @@ static void ir_raw_event_work(struct work_struct *work)
container_of(work, struct ir_raw_event_ctrl, rx_work);
while (kfifo_out(raw-kfifo, ev, sizeof(ev)) == sizeof(ev)) {
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
list_for_each_entry(handler, ir_raw_handler_list, list)
handler-decode(raw-input_dev, ev);
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
raw-prev_ev = ev;
}
}
@@ -150,9 +150,9 @@ u64
ir_raw_get_allowed_protocols()
{
u64 protocols;
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
protocols = available_protocols;
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
return protocols;
}
@@ -180,12 +180,12 @@ int ir_raw_event_register(struct input_dev *input_dev)
return rc;
}
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
list_add_tail(ir-raw-list, ir_raw_client_list);
list_for_each_entry(handler, ir_raw_handler_list, list)
if (handler-raw_register)
handler-raw_register(ir-raw-input_dev);
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
return 0;
}
@@ -200,12 +200,12 @@ void ir_raw_event_unregister(struct input_dev *input_dev)
cancel_work_sync(ir-raw-rx_work);
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
list_del(ir-raw-list);
list_for_each_entry(handler, ir_raw_handler_list, list)
if (handler-raw_unregister)
handler-raw_unregister(ir-raw-input_dev);
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
kfifo_free(ir-raw-kfifo);
kfree(ir-raw);
@@ -220,13 +220,13 @@ int ir_raw_handler_register(struct ir_raw_handler
*ir_raw_handler)
{
struct ir_raw_event_ctrl *raw;
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
list_add_tail(ir_raw_handler-list, ir_raw_handler_list);
if (ir_raw_handler-raw_register)
list_for_each_entry(raw, ir_raw_client_list, list)
ir_raw_handler-raw_register(raw-input_dev);
available_protocols |= ir_raw_handler-protocols;
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
return 0;
}
@@ -236,13 +236,13 @@ void ir_raw_handler_unregister(struct ir_raw_handler
*ir_raw_handler)
{
struct ir_raw_event_ctrl *raw;
- spin_lock(ir_raw_handler_lock);
+ mutex_lock(ir_raw_handler_lock);
list_del(ir_raw_handler-list);
if (ir_raw_handler-raw_unregister)
list_for_each_entry(raw, ir_raw_client_list, list)
ir_raw_handler-raw_unregister(raw-input_dev);
available_protocols = ~ir_raw_handler-protocols;
- spin_unlock(ir_raw_handler_lock);
+ mutex_unlock(ir_raw_handler_lock);
}
EXPORT_SYMBOL(ir_raw_handler_unregister);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] IR: extend interfaces to support more device settings
Also reuse LIRC_SET_MEASURE_CARRIER_MODE as LIRC_SET_LEARN_MODE
(LIRC_SET_LEARN_MODE will start carrier reports if possible, and
tune receiver to wide band mode)
This IOCTL isn't yet used by lirc, so this won't break userspace.
Note that drivers currently can't report carrier,
because raw event doesn't have space to indicate that.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |2 +
drivers/media/IR/ir-lirc-codec.c | 119 +++---
drivers/media/IR/ir-raw-event.c | 13 ++---
include/media/ir-core.h | 11
include/media/lirc.h |4 +-
5 files changed, 117 insertions(+), 32 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index d6ec4fe..9c594af 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -77,6 +77,8 @@ struct ir_raw_event_ctrl {
struct lirc_codec {
struct ir_input_dev *ir_dev;
struct lirc_driver *drv;
+ int timeout_report;
+ int carrier_low;
} lirc;
};
diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c
index 8ca01fd..70c299f 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -40,16 +40,24 @@ static int ir_lirc_decode(struct input_dev *input_dev,
struct ir_raw_event ev)
if (!ir_dev-raw-lirc.drv || !ir_dev-raw-lirc.drv-rbuf)
return -EINVAL;
- if (IS_RESET(ev))
- return 0;
+ if (IS_RESET(ev)) {
+
+ if (ir_dev-raw-lirc.timeout_report)
+ sample = LIRC_TIMEOUT(0);
+ else
+ return 0;
- IR_dprintk(2, LIRC data transfer started (%uus %s)\n,
- TO_US(ev.duration), TO_STR(ev.pulse));
+ IR_dprintk(2, LIRC: Sending timeout packet\n);
+ } else {
+ sample = ev.duration / 1000;
+ if (ev.pulse)
+ sample |= PULSE_BIT;
+
+ IR_dprintk(2, LIRC data transfer started (%uus %s)\n,
+ TO_US(ev.duration), TO_STR(ev.pulse));
+ }
- sample = ev.duration / 1000;
- if (ev.pulse)
- sample |= PULSE_BIT;
lirc_buffer_write(ir_dev-raw-lirc.drv-rbuf,
(unsigned char *) sample);
@@ -96,13 +104,13 @@ out:
return ret;
}
-static long ir_lirc_ioctl(struct file *filep, unsigned int cmd, unsigned long
arg)
+static long ir_lirc_ioctl(struct file *filep, unsigned int cmd, unsigned long
__user arg)
{
struct lirc_codec *lirc;
struct ir_input_dev *ir_dev;
int ret = 0;
void *drv_data;
- unsigned long val;
+ unsigned long val = 0;
lirc = lirc_get_pdata(filep);
if (!lirc)
@@ -114,24 +122,22 @@ static long ir_lirc_ioctl(struct file *filep, unsigned
int cmd, unsigned long ar
drv_data = ir_dev-props-priv;
- switch (cmd) {
- case LIRC_SET_TRANSMITTER_MASK:
+ if (_IOC_DIR(cmd) _IOC_WRITE) {
ret = get_user(val, (unsigned long *)arg);
if (ret)
return ret;
+ }
- if (ir_dev-props ir_dev-props-s_tx_mask)
+ switch (cmd) {
+ case LIRC_SET_TRANSMITTER_MASK:
+ if (ir_dev-props-s_tx_mask)
ret = ir_dev-props-s_tx_mask(drv_data, (u32)val);
else
return -EINVAL;
break;
case LIRC_SET_SEND_CARRIER:
- ret = get_user(val, (unsigned long *)arg);
- if (ret)
- return ret;
-
- if (ir_dev-props ir_dev-props-s_tx_carrier)
+ if (ir_dev-props-s_tx_carrier)
ir_dev-props-s_tx_carrier(drv_data, (u32)val);
else
return -EINVAL;
@@ -139,22 +145,79 @@ static long ir_lirc_ioctl(struct file *filep, unsigned
int cmd, unsigned long ar
case LIRC_GET_SEND_MODE:
val = LIRC_CAN_SEND_PULSE LIRC_CAN_SEND_MASK;
- ret = put_user(val, (unsigned long *)arg);
break;
case LIRC_SET_SEND_MODE:
- ret = get_user(val, (unsigned long *)arg);
- if (ret)
- return ret;
-
if (val != (LIRC_MODE_PULSE LIRC_CAN_SEND_MASK))
return -EINVAL;
break;
+ case LIRC_GET_REC_RESOLUTION:
+ val = ir_dev-props-rx_resolution;
+ break;
+
+ case LIRC_SET_REC_TIMEOUT:
+ if (val ir_dev-props-min_timeout ||
+ val ir_dev-props-max_timeout)
+ return -EINVAL;
+ ir_dev-props-timeout = val;
+ break;
+
+ case LIRC_SET_REC_TIMEOUT_REPORTS:
+
[PATCH 6/9] IR: Allow not to compile keymaps in.
Currently, ir device registration fails if keymap requested by driver is not
found.
Fix that by always compiling in the empty keymap, and using it as a failback.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |3 +-
drivers/media/IR/ir-sysfs.c |2 +
drivers/media/IR/keymaps/Makefile |1 -
drivers/media/IR/keymaps/rc-empty.c | 44 ---
drivers/media/IR/rc-map.c | 23 ++
include/media/ir-core.h |8 -
6 files changed, 33 insertions(+), 48 deletions(-)
delete mode 100644 drivers/media/IR/keymaps/rc-empty.c
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 9c594af..78106a0 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -127,7 +127,8 @@ int ir_raw_handler_register(struct ir_raw_handler
*ir_raw_handler);
void ir_raw_handler_unregister(struct ir_raw_handler *ir_raw_handler);
void ir_raw_init(void);
-
+int ir_rcmap_init(void);
+void ir_rcmap_cleanup(void);
/*
* Decoder initialization code
*
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index a841e51..936dff8 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -341,6 +341,7 @@ static int __init ir_core_init(void)
/* Initialize/load the decoders/keymap code that will be used */
ir_raw_init();
+ ir_rcmap_init();
return 0;
}
@@ -348,6 +349,7 @@ static int __init ir_core_init(void)
static void __exit ir_core_exit(void)
{
class_unregister(ir_input_class);
+ ir_rcmap_cleanup();
}
module_init(ir_core_init);
diff --git a/drivers/media/IR/keymaps/Makefile
b/drivers/media/IR/keymaps/Makefile
index 86d3d1f..24992cd 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -17,7 +17,6 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-dm1105-nec.o \
rc-dntv-live-dvb-t.o \
rc-dntv-live-dvbt-pro.o \
- rc-empty.o \
rc-em-terratec.o \
rc-encore-enltv2.o \
rc-encore-enltv.o \
diff --git a/drivers/media/IR/keymaps/rc-empty.c
b/drivers/media/IR/keymaps/rc-empty.c
deleted file mode 100644
index 3b338d8..000
--- a/drivers/media/IR/keymaps/rc-empty.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/* empty.h - Keytable for empty Remote Controller
- *
- * keymap imported from ir-keymaps.c
- *
- * Copyright (c) 2010 by Mauro Carvalho Chehab mche...@redhat.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include media/rc-map.h
-
-/* empty keytable, can be used as placeholder for not-yet created keytables */
-
-static struct ir_scancode empty[] = {
- { 0x2a, KEY_COFFEE },
-};
-
-static struct rc_keymap empty_map = {
- .map = {
- .scan= empty,
- .size= ARRAY_SIZE(empty),
- .ir_type = IR_TYPE_UNKNOWN, /* Legacy IR type */
- .name= RC_MAP_EMPTY,
- }
-};
-
-static int __init init_rc_map_empty(void)
-{
- return ir_register_map(empty_map);
-}
-
-static void __exit exit_rc_map_empty(void)
-{
- ir_unregister_map(empty_map);
-}
-
-module_init(init_rc_map_empty)
-module_exit(exit_rc_map_empty)
-
-MODULE_LICENSE(GPL);
-MODULE_AUTHOR(Mauro Carvalho Chehab mche...@redhat.com);
diff --git a/drivers/media/IR/rc-map.c b/drivers/media/IR/rc-map.c
index 46a8f15..689143f 100644
--- a/drivers/media/IR/rc-map.c
+++ b/drivers/media/IR/rc-map.c
@@ -82,3 +82,26 @@ void ir_unregister_map(struct rc_keymap *map)
}
EXPORT_SYMBOL_GPL(ir_unregister_map);
+
+static struct ir_scancode empty[] = {
+ { 0x2a, KEY_COFFEE },
+};
+
+static struct rc_keymap empty_map = {
+ .map = {
+ .scan= empty,
+ .size= ARRAY_SIZE(empty),
+ .ir_type = IR_TYPE_UNKNOWN, /* Legacy IR type */
+ .name= RC_MAP_EMPTY,
+ }
+};
+
+int ir_rcmap_init(void)
+{
+ return ir_register_map(empty_map);
+}
+
+void ir_rcmap_cleanup(void)
+{
+ ir_unregister_map(empty_map);
+}
diff --git a/include/media/ir-core.h b/include/media/ir-core.h
index 7299e7a..cf17be3 100644
--- a/include/media/ir-core.h
+++ b/include/media/ir-core.h
@@ -134,8 +134,12 @@ static inline int ir_input_register(struct input_dev *dev,
return -EINVAL;
ir_codes = get_rc_map(map_name);
- if (!ir_codes)
- return -EINVAL;
+ if (!ir_codes) {
+ ir_codes = get_rc_map(RC_MAP_EMPTY);
+
+ if (!ir_codes)
+ return -EINVAL;
+ }
rc =
[PATCH 4/9] IR: add helper function for hardware with small o/b buffer.
Some ir input devices have small buffer, and interrupt the host
each time it is full (or half full)
Add a helper that automaticly handles timeouts, and also
automaticly merges samples of same time (space-space)
Such samples might be placed by hardware because size of
sample in the buffer is small (a byte for example).
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-core-priv.h |1 +
drivers/media/IR/ir-keytable.c |2 +-
drivers/media/IR/ir-raw-event.c | 86 +++
include/media/ir-core.h | 24 +-
4 files changed, 109 insertions(+), 4 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index dc26e2b..d6ec4fe 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -36,6 +36,7 @@ struct ir_raw_event_ctrl {
struct kfifokfifo; /* fifo for the
pulse/space durations */
ktime_t last_event; /* when last event
occurred */
enum raw_event_type last_type; /* last event type */
+ struct ir_raw_event current_sample; /* sample that is not
yet pushed to fifo */
struct input_dev*input_dev; /* pointer to the
parent input_dev */
u64 enabled_protocols; /* enabled raw
protocol decoders */
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 94a8577..34b9c07 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -428,7 +428,7 @@ static void ir_close(struct input_dev *input_dev)
*/
int __ir_input_register(struct input_dev *input_dev,
const struct ir_scancode_table *rc_tab,
- const struct ir_dev_props *props,
+ struct ir_dev_props *props,
const char *driver_name)
{
struct ir_input_dev *ir_dev;
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index c6a80b3..bdf2ed8 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -129,6 +129,92 @@ int ir_raw_event_store_edge(struct input_dev *input_dev,
enum raw_event_type typ
EXPORT_SYMBOL_GPL(ir_raw_event_store_edge);
/**
+ * ir_raw_event_store_with_filter() - pass next pulse/space to decoders with
some processing
+ * @input_dev: the struct input_dev device descriptor
+ * @type: the type of the event that has occurred
+ *
+ * This routine (which may be called from an interrupt context) is used to
+ * store the beginning of an ir pulse or space (or the start/end of ir
+ * reception) for the raw ir decoding state machines.\
+ * This routine is intended for devices with limited internal buffer
+ * It automerges samples of same type, and handles timeouts
+ */
+int ir_raw_event_store_with_filter(struct input_dev *input_dev,
+ struct ir_raw_event *ev)
+{
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
+ struct ir_raw_event_ctrl *raw = ir-raw;
+
+ if (!ir-raw || !ir-props)
+ return -EINVAL;
+
+ /* Ignore spaces in idle mode */
+ if (ir-idle !ev-pulse)
+ return 0;
+ else if (ir-idle)
+ ir_raw_event_set_idle(input_dev, 0);
+
+ if (!raw-current_sample.duration) {
+ raw-current_sample = *ev;
+ } else if (ev-pulse == raw-current_sample.pulse) {
+ raw-current_sample.duration += ev-duration;
+ } else {
+ ir_raw_event_store(input_dev, raw-current_sample);
+ raw-current_sample = *ev;
+ }
+
+ /* Enter idle mode if nessesary */
+ if (!ev-pulse ir-props-timeout
+ raw-current_sample.duration = ir-props-timeout)
+ ir_raw_event_set_idle(input_dev, 1);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_store_with_filter);
+
+
+void ir_raw_event_set_idle(struct input_dev *input_dev, int idle)
+{
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
+ struct ir_raw_event_ctrl *raw = ir-raw;
+ ktime_t now;
+ u64 delta;
+
+ if (!ir-props)
+ return;
+
+ if (!ir-raw)
+ goto out;
+
+ if (idle) {
+ IR_dprintk(2, enter idle mode\n);
+ raw-last_event = ktime_get();
+ } else {
+ IR_dprintk(2, exit idle mode\n);
+
+ now = ktime_get();
+ delta = ktime_to_ns(ktime_sub(now, ir-raw-last_event));
+
+ WARN_ON(raw-current_sample.pulse);
+
+ raw-current_sample.duration =
+ min(raw-current_sample.duration + delta,
+ (u64)IR_MAX_DURATION);
+
+ ir_raw_event_store(input_dev, raw-current_sample);
+
+ if (raw-current_sample.duration ==
[PATCH 7/9] IR: report unknown scancodes the in-kernel decoders found.
This way it is possible to use evtest to create keymap for unknown remote.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/ir-keytable.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 34b9c07..4498c64 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -339,6 +339,8 @@ void ir_repeat(struct input_dev *dev)
spin_lock_irqsave(ir-keylock, flags);
+ input_event(dev, EV_MSC, MSC_SCAN, ir-last_scancode);
+
if (!ir-keypressed)
goto out;
@@ -383,9 +385,12 @@ void ir_keydown(struct input_dev *dev, int scancode, u8
toggle)
ir-last_toggle = toggle;
ir-last_keycode = keycode;
+ input_event(dev, EV_MSC, MSC_SCAN, scancode);
+
if (keycode == KEY_RESERVED)
goto out;
+
/* Register a keypress */
ir-keypressed = true;
IR_dprintk(1, %s: key down event, key 0x%04x, scancode 0x%04x\n,
@@ -480,6 +485,8 @@ int __ir_input_register(struct input_dev *input_dev,
set_bit(EV_KEY, input_dev-evbit);
set_bit(EV_REP, input_dev-evbit);
+ set_bit(EV_MSC, input_dev-evbit);
+ set_bit(MSC_SCAN, input_dev-mscbit);
if (ir_setkeytable(input_dev, ir_dev-rc_tab, rc_tab)) {
rc = -ENOMEM;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/9] IR: Port ene driver to new IR subsystem and enable it.
note that error_adjustment module option is added.
This allows to reduce input samples by a percent.
This makes input on my system more correct.
Default is 4% as it works best here.
Note that only normal input is adjusted. I don't know
what ajustements to apply to fan tachtometer input.
Maybe it is accurate already.
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
drivers/media/IR/Kconfig | 14 +
drivers/media/IR/Makefile |1 +
drivers/media/IR/ene_ir.c | 589 +
drivers/media/IR/ene_ir.h | 32 +--
4 files changed, 241 insertions(+), 395 deletions(-)
diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index fc48a3f..3f62bf9 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -105,4 +105,18 @@ config IR_MCEUSB
To compile this driver as a module, choose M here: the
module will be called mceusb.
+config IR_ENE
+ tristate ENE eHome Receiver/Transciever (pnp id: ENE0100/ENE02xxx)
+ depends on PNP
+ depends on IR_CORE
+ ---help---
+ Say Y here to enable support for integrated infrared receiver
+ /transciever made by ENE.
+
+ You can see if you have it by looking at lspnp output.
+ Output should include ENE0100 ENE0200 or something similiar.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ene_ir.
+
endif #IR_CORE
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 2ae4f3a..3262a68 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_IR_IMON) += imon.o
obj-$(CONFIG_IR_MCEUSB) += mceusb.o
+obj-$(CONFIG_IR_ENE) += ene_ir.o
diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
index 9d11caf..8b88dbd 100644
--- a/drivers/media/IR/ene_ir.c
+++ b/drivers/media/IR/ene_ir.c
@@ -1,5 +1,5 @@
/*
- * driver for ENE KB3926 B/C/D CIR (also known as ENE0100/ENE0200/ENE0201)
+ * driver for ENE KB3926 B/C/D CIR (pnp id: ENE0XXX)
*
* Copyright (C) 2010 Maxim Levitsky maximlevit...@gmail.com
*
@@ -25,20 +25,21 @@
#include linux/io.h
#include linux/interrupt.h
#include linux/sched.h
-#include linux/uaccess.h
-#include lirc_ene0100.h
+#include linux/slab.h
+#include linux/input.h
+#include media/ir-core.h
+#include media/ir-common.h
+#include ene_ir.h
static int sample_period = -1;
static int enable_idle = 1;
-static int enable_duty_carrier;
+static int error_adjustment = 4;
static int input = 1;
static int debug;
static int txsim;
-static void ene_rx_set_idle(struct ene_device *dev, int idle);
static int ene_irq_status(struct ene_device *dev);
-static void ene_send_sample(struct ene_device *dev, unsigned long sample);
/* read a hardware register */
static u8 ene_hw_read_reg(struct ene_device *dev, u16 reg)
@@ -160,7 +161,7 @@ static int ene_hw_detect(struct ene_device *dev)
}
/* this enables/disables IR input via gpio40*/
-static void ene_enable_gpio40_recieve(struct ene_device *dev, int enable)
+static void ene_enable_gpio40_receive(struct ene_device *dev, int enable)
{
ene_hw_write_reg_mask(dev, ENE_CIR_CONF2, enable ?
0 : ENE_CIR_CONF2_GPIO40DIS,
@@ -168,13 +169,13 @@ static void ene_enable_gpio40_recieve(struct ene_device
*dev, int enable)
}
/* this enables/disables IR via standard input */
-static void ene_enable_normal_recieve(struct ene_device *dev, int enable)
+static void ene_enable_normal_receive(struct ene_device *dev, int enable)
{
ene_hw_write_reg(dev, ENE_CIR_CONF1, enable ? ENE_CIR_CONF1_RX_ON : 0);
}
/* this enables/disables IR input via unused fan tachtometer input */
-static void ene_enable_fan_recieve(struct ene_device *dev, int enable)
+static void ene_enable_fan_receive(struct ene_device *dev, int enable)
{
if (!enable)
ene_hw_write_reg(dev, ENE_FAN_AS_IN1, 0);
@@ -186,7 +187,7 @@ static void ene_enable_fan_recieve(struct ene_device *dev,
int enable)
}
-/* Sense current recieved carrier */
+/* Sense current received carrier */
static int ene_rx_sense_carrier(struct ene_device *dev)
{
int period = ene_hw_read_reg(dev, ENE_RX_CARRIER);
@@ -209,37 +210,37 @@ static int ene_rx_sense_carrier(struct ene_device *dev)
/* determine which input to use*/
static void ene_rx_set_inputs(struct ene_device *dev)
{
- int learning_mode = dev-learning_enabled || dev-rx_carrier_sense;
+ int learning_mode = dev-learning_enabled;
- ene_dbg(RX: setup reciever, learning mode = %d, learning_mode);
+ ene_dbg(RX: setup receiver, learning mode = %d, learning_mode);
- ene_enable_normal_recieve(dev, 1);
+ ene_enable_normal_receive(dev, 1);
/* old hardware doesn't support learning mode for sure */
if (dev-hw_revision = ENE_HW_B)
return;
Re: saa7164 i2c problem
Hi Dong, On Sun, 2010-07-25 at 09:38 -0700, Dong Lin wrote: Andy, PLease be advised that I will usually ignore private emails asking for tech support, when there is no obvious need for privacy. Linux development works best with many eyes to help shoulder the workload and spot the problems. Thus I respond Cc:-ing the LMML list. I am having trouble using an hvr-2250 card (0070:8851). It seems that there was some kind of i2c error triggered by the 7164 driver. Well, I'm not quite the right person to ask about Philips chips. I don't have access to datasheets and programming manuals for them. The strangest thing is that it worked for the very first time when the card was physically inserted into the machine. But Starting from the second boot, it no longer works. I wonder if you have looked into this problem. It looks like a power management problem or chip reset problem. See below. Steven Toth mentioned on one mailing list that it might be related to AMD systems only. But I cannot find any specifics. Thanks, Dong Lin - [ 20.406838] saa7164 driver loaded [ 20.407370] ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16 [ 20.407375] saa7164 :03:00.0: PCI INT A - Link[APC5] - GSI 16 (level, low) - IRQ 16 [ 20.407541] CORE saa7164[0]: subsystem: 0070:8851, board: Hauppauge WinTV-HVR2250 [card=7,autodetected] [ 20.407547] saa7164[0]/0: found at :03:00.0, rev: 129, irq: 16, latency: 0, mmio: 0xfd00 [ 20.407552] saa7164 :03:00.0: setting latency timer to 64 [ 20.407556] IRQ 16/saa7164[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 20.564011] saa7164_downloadfirmware() no first image [ 20.564264] saa7164_downloadfirmware() Waiting for firmware upload (v4l-saa7164-1.0.3.fw) [ 20.564269] saa7164 :03:00.0: firmware: requesting v4l-saa7164-1.0.3.fw [ 20.684414] saa7164_downloadfirmware() firmware read 3978608 bytes. [ 20.684418] saa7164_downloadfirmware() firmware loaded. [ 20.684419] Firmware file header part 1: [ 20.684422] .FirmwareSize = 0x0 [ 20.684423] .BSLSize = 0x0 [ 20.684424] .Reserved = 0x3cb57 [ 20.684426] .Version = 0x3 [ 20.684427] saa7164_downloadfirmware() SecBootLoader.FileSize = 3978608 [ 20.684433] saa7164_downloadfirmware() FirmwareSize = 0x1fd6 [ 20.684434] saa7164_downloadfirmware() BSLSize = 0x0 [ 20.684436] saa7164_downloadfirmware() Reserved = 0x0 [ 20.684438] saa7164_downloadfirmware() Version = 0x51cc1 [ 20.699720] ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 [ 20.699726] HDA Intel :00:05.0: PCI INT B - Link[AAZA] - GSI 22 (level, low) - IRQ 22 [ 20.699729] hda_intel: Disable MSI for Nvidia chipset [ 20.699761] HDA Intel :00:05.0: setting latency timer to 64 [ 21.296090] input: HDA Digital PCBeep as /devices/pci:00/:00:05.0/input/input7 [ 24.922396] CPU0 attaching NULL sched-domain. [ 24.922403] CPU1 attaching NULL sched-domain. [ 24.944083] CPU0 attaching sched-domain: [ 24.944088] domain 0: span 0-1 level MC [ 24.944091] groups: 0 1 [ 24.944097] CPU1 attaching sched-domain: [ 24.944099] domain 0: span 0-1 level MC [ 24.944101] groups: 1 0 [ 27.276020] saa7164_downloadimage() Image downloaded, booting... [ 27.380013] saa7164_downloadimage() Image booted successfully. [ 27.380031] starting firmware download(2) [ 29.504018] saa7164_downloadimage() Image downloaded, booting... [ 30.720519] eth1: no IPv6 routers present [ 31.168047] saa7164_downloadimage() Image booted successfully. [ 31.168072] firmware download complete. [ 31.204870] tveeprom 5-: Hauppauge model 88061, rev C4F2, serial# 6567048 [ 31.204874] tveeprom 5-: MAC address is 00-0D-FE-64-34-88 [ 31.204877] tveeprom 5-: tuner model is NXP 18271C2_716x (idx 152, type 4) [ 31.204880] tveeprom 5-: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) [ 31.204883] tveeprom 5-: audio processor is SAA7164 (idx 43) [ 31.204885] tveeprom 5-: decoder processor is SAA7164 (idx 40) [ 31.204887] tveeprom 5-: has radio, has IR receiver, has no IR transmitter [ 31.204889] saa7164[0]: Hauppauge eeprom: model=88061 [ 31.708552] tda18271 6-0060: creating new instance [ 31.712620] TDA18271HD/C2 detected @ 6-0060 [ 31.964810] DVB: registering new adapter (saa7164) [ 31.964818] DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... [ 32.248340] tda18271 7-0060: creating new instance [ 32.252388] TDA18271HD/C2 detected @ 7-0060 [ 32.500491] tda18271: performing RF tracking filter calibration [ 35.254384] tda18271: RF tracking filter calibration complete [ 35.254732] DVB: registering new adapter (saa7164) [ 35.254738] DVB: registering adapter 1 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... What did you try in the 30 minutes and 45 seconds between driver load and the error? [ 1879.428026] Event timed out
Re: cx23885: Unknown symbol __ir_input_register
On Sun, 2010-07-25 at 14:55 -0300, Mauro Carvalho Chehab wrote: Em 25-07-2010 10:22, Andy Walls escreveu: On Sun, 2010-07-25 at 08:44 -0400, Andy Walls wrote: On Sat, 2010-07-24 at 18:45 +0200, v...@onet.pl wrote: Or do I misunderstand the select depends keywords? IMHO, we need to re-work at the IR dependencies. The better is to not use select. The proper solution seems to re-work on the existing drivers to allow them to work with IR disabled via Kconfig. So, if IR support were compiled, it will enable the *-input. Otherwise, the driver will keep compiling, but without IR. Ack. That's the smart thing to do. I'll try to work on that when I finally get IR Tx ironed out. Regards, Andy Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Wed, 2010-07-28 at 17:13 -0300, Mauro Carvalho Chehab wrote: Andy, Em 28-07-2010 15:18, Andy Walls escreveu: On Wed, 2010-07-28 at 13:35 -0400, Jon Smirl wrote: On Wed, Jul 28, 2010 at 1:02 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 12:42 -0300, Mauro Carvalho Chehab wrote: Em 28-07-2010 11:53, Jon Smirl escreveu: On Wed, Jul 28, 2010 at 10:38 AM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-07-28 at 09:46 -0400, Jon Smirl wrote: I recommend that all decoders initially follow the strict protocol rules. That will let us find bugs like this one in the ENE driver. Agreed. Well... I'd possibly make an exception for the protocols that have long-mark leaders. The actual long mark measurement can be far off from the protocol's specification and needs a larger tolerance (IMO). Only allowing 0.5 to 1.0 of a protocol time unit tolerance, for a protocol element that is 8 to 16 protocol time units long, doesn't make too much sense to me. If the remote has the basic protocol time unit off from our expectation, the error will likely be amplified in a long protocol elements and very much off our expectation. Do you have a better way to differentiate JVC and NEC protocols? They are pretty similar except for the timings. Yes: Invoke the 80/20 rule and don't try. At the room where my computers is located, I have two wide fluorescent lamps each with 20W. If I don't hide the IR sensors bellow my desk, those lamps are enough to generate random flickers at the sensors. With the more relaxed driver we used to have at saa7134, it ended by producing random scancodes, or, even worse, random repeat codes. So, lots of false-positive events. It is a way worse to have false-positive than having a false-negative events. So those sorts of false positiives are bad, but a glitch filter handles those. (Easily done in software - borrow from the LIRC userspace if need be.) Set the glictch filter discard pulses that are shorter than some fraction of the expected protocol time unit. In the cx23885-input.c file I chose to set the hardware glitch filter at 75% for RC-6 and 62.5% for NEC (I forget my reasons for those numbers aside from being 3/4 5/8 respectively) So, I don't think it is a good idea to use a relaxed mode by default. So I disagree. We should set the default to make the most common use case as error free as possible, reducing false detections and missed detections, so that it just works. I see two conflicting goals, which force optimizations one direction or another: 1. Optimize for good protocol discrimination (at the expense of ability to decode from remotes/receviers that don't meet the protocol specs). 2. Optimize for good decoding within each protocol (at the expense of discriminating between the protocols). My assertion that goal #1, is not important in the most common use case and the ability have an acceptable success rate in the general case is questionable. There is so much information available to constrain what IR protocols will be present on a receiver, it hardly seems worth the effort for the normal user with 1 TV capture device and the remote that came with it. I'll also assert that goal #2 is easier to attain and more useful to the general case. Cheap remotes and poor ambient light conditions are common occurences. Glitch filters are simpler if you can just throw out glitches, restarting the measurment, knowing that the tolerances will still pull you in. One can also start to think about adaptive decoders, that adjust to the protocol time unit the remotes appears to be using. (In NEC, the normal mark time indicates the remote's idea of the protocol time unit.) What am I going to do about it all in the end? Probably not much. :) (I seem to have more time to gripe than do much else nowadays. :P ) Enable NEC and disable JVC by default. Let the users know so as to properly manage user expectations. (Maxim's original question was about expectation.) We should discuss a little bit about RC subsystem evolution during LPC/2010, Yes. I'll be there. but, from my point of view, we should soon deprecate the in-kernel keymap tables on some new kernel version, using, instead, the ir-keycode application to dynamically load the keycode tables via UDEV. Of course, after some time, we may end by removing all those tables from the kernel. So, assuming that we follow this patch, what we'll have for a newer device is: For most devices, the keymap configuration table (rc_maps.cfg) will associate all known devices with their corresponding keytable (we still need to generate a default rc_maps.cfg that corresponds to the current in-kernel mapping, but this is trivial). As ir-keytable disables all protocols but the one(s) needed by a given device, in practice, if the scancode table specifies a NEC keymap table, JVC will be disabled. If the table is for JVC, NEC will
Re: [PATCH] IR/mceusb: remove bad ir_input_dev use
On Tue, Jul 27, 2010 at 10:24 PM, Jarod Wilson ja...@redhat.com wrote:
The ir_input_dev gets filled in by __ir_input_register, the one
allocated in mceusb_init_input_dev was being overwritten by the correct
one shortly after it was initialized (ultimately resulting in a memory
leak). This bug was inherited from imon.c, and was pointed out to me by
Maxim Levitsky.
D'oh, there's a minor errorlet in this patch...
CC: Maxim Levitsky maximlevit...@gmail.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/mceusb.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index 78bf7f7..9a7da32 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -228,7 +228,6 @@ static struct usb_device_id std_tx_mask_list[] = {
/* data structure for each usb transceiver */
struct mceusb_dev {
/* ir-core bits */
- struct ir_input_dev *irdev;
struct ir_dev_props *props;
struct ir_raw_event rawir;
@@ -739,7 +738,7 @@ static void mceusb_dev_recv(struct urb *urb, struct
pt_regs *regs)
if (ir-send_flags == RECV_FLAG_IN_PROGRESS) {
ir-send_flags = SEND_FLAG_COMPLETE;
- dev_dbg(ir-irdev-dev, setup answer received %d bytes\n,
+ dev_dbg(ir-dev, setup answer received %d bytes\n,
This should be dev_dbg(ir-dev, ... (i.e., without the ampersand).
Mauro, shall I resend this, or can you fix that at commit time?
--
Jarod Wilson
ja...@wilsonet.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.36] cx23885, cx25840, v4l2_subdev: I/O pin config and CX23885 chip IR Rx
Mauro, Please pull these changes for 2.6.36. They are based off of the v4l-dvb/other branch from a few weeks ago, IIRC. These changes implement CX23885 chip IR Rx support, which different people seem to bug me about once a month or so. IR support for the CX23885 chip, which is not used in new designs, will never get better unless it is in the hands of the masses. These changes are also a necessary step for CX23887 and CX231xx IR Tx/Rx and CX2388[58] IR Tx. Regards, Andy The following changes since commit f6242ad1007df90691fd5b70f0808320fe7aee07: V4L/DVB: xc5000: Fix a few warnings (2010-07-05 18:38:46 -0300) are available in the git repository at: ssh://linuxtv.org/git/awalls/v4l-dvb.git cx-ir Andy Walls (15): cx25840: Make cx25840 i2c register read transactions atomic cx23885: Add correct detection of the HVR-1250 model 79501 cx23885: Add a VIDIOC_LOG_STATUS ioctl function for analog video devices v4l2_subdev: Add s_io_pin_config to v4l2_subdev_core_ops cx25840: Add s_io_pin_config core subdev ops for the CX2388[578] v4l2_subdev, cx23885: Differentiate IR carrier sense and I/O pin inversion cx23885: For CX23888 IR, configure the IO pin mux IR pins explcitly v4l2_subdev: Move interrupt_service_routine ptr to v4l2_subdev_core_ops cx25840: Add support for CX2388[57] A/V core integrated IR controllers cx23885: Add a v4l2_subdev group id for the CX2388[578] integrated AV core cx23885: Add preliminary IR Rx support for the HVR-1250 and TeVii S470 cx23885: Protect PCI interrupt mask manipulations with a spinlock cx23885: Move AV Core irq handling to a work handler cx23885: Require user to explicitly enable CX2388[57] IR via module param cx23885: Change Kconfig dependencies to new IR_CORE functions Jean Delvare (3): cx23885: Return -ENXIO on slave nack cx23885: Check for slave nack on all transactions cx23885: i2c_wait_done returns 0 or 1, don't check for 0 return value drivers/media/video/cx23885/Kconfig |2 +- drivers/media/video/cx23885/Makefile|5 +- drivers/media/video/cx23885/cx23885-av.c| 35 + drivers/media/video/cx23885/cx23885-av.h| 27 + drivers/media/video/cx23885/cx23885-cards.c | 114 +++- drivers/media/video/cx23885/cx23885-core.c | 124 +++- drivers/media/video/cx23885/cx23885-i2c.c | 27 +- drivers/media/video/cx23885/cx23885-input.c | 48 +- drivers/media/video/cx23885/cx23885-ir.c| 24 +- drivers/media/video/cx23885/cx23885-reg.h |1 + drivers/media/video/cx23885/cx23885-vbi.c |2 +- drivers/media/video/cx23885/cx23885-video.c | 23 +- drivers/media/video/cx23885/cx23885.h |9 +- drivers/media/video/cx23885/cx23888-ir.c| 35 +- drivers/media/video/cx25840/Makefile|2 +- drivers/media/video/cx25840/cx25840-core.c | 339 +++- drivers/media/video/cx25840/cx25840-core.h | 28 + drivers/media/video/cx25840/cx25840-ir.c| 1262 +++ include/media/cx25840.h | 75 ++ include/media/v4l2-subdev.h | 44 +- 20 files changed, 2136 insertions(+), 90 deletions(-) create mode 100644 drivers/media/video/cx23885/cx23885-av.c create mode 100644 drivers/media/video/cx23885/cx23885-av.h create mode 100644 drivers/media/video/cx25840/cx25840-ir.c -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9 v2] IR: few fixes, additions and ENE driver
On Thu, Jul 29, 2010 at 02:40:43AM +0300, Maxim Levitsky wrote: Hi, This is second version of the patchset. Hopefully, I didn't forget to address all comments. In addition to comments, I changed helper function that processes samples so it sends last space as soon as timeout is reached. This breaks somewhat lirc, because now it gets 2 spaces in row. However, if it uses timeout reports (which are now fully supported) it will get such report in middle. Note that I send timeout report with zero value. I don't think that this value is importaint. I just patched the entire series into a branch here and tested, no regressions with an mceusb transceiver with in-kernel decode, lirc decode or lirc tx. Only issue I had (which I neglected to mention earlier) was some pedantic issues w/whitespace. Here's the tree I built and tested: http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=shortlog;h=refs/heads/maxim 7486d6ae3 addresses all the whitespace/formatting issues I had. Could either merge that into your patches, or I can just send it along as an additional patch after the fact. In either case, for 1-7 v2: Tested-by: Jarod Wilson ja...@redhat.com I have no ene hardware to actually test with, but it did build. :) For 1-9 v2: Acked-by: Jarod Wilson ja...@redhat.com -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for July 28 (lirc #2)
On Wed, Jul 28, 2010 at 6:27 PM, Jarod Wilson ja...@wilsonet.com wrote: On Wed, Jul 28, 2010 at 6:16 PM, Randy Dunlap randy.dun...@oracle.com wrote: On 07/28/10 15:04, Janne Grunau wrote: On Wed, Jul 28, 2010 at 10:24:17AM -0700, Randy Dunlap wrote: On Wed, 28 Jul 2010 16:28:55 +1000 Stephen Rothwell wrote: Hi all, Changes since 20100727: When USB_SUPPORT is not enabled and MEDIA_SUPPORT is not enabled: following patch should fix it Janne Acked-by: Randy Dunlap randy.dun...@oracle.com Thanks. Acked-by: Jarod Wilson ja...@redhat.com Indeed, thanks much, Janne! D'oh, I should have looked a bit closer... What if instead of making all the drivers depend on both LIRC LIRC_STAGING, LIRC_STAGING just depends on LIRC? And there are a few depends lines with duplicate USB's in them and LIRC_IMON should have USB added to it (technically, I think ene0100 should also have a PNP, but we already have patches pending that move it from staging to an ir-core driver). -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
