Re: [PATCH] [media] nec decoder: wrong bit order for nec32 protocol

[Jarod Wilson]

On Tue, Nov 22, 2016 at 11:35:06AM -0200, Mauro Carvalho Chehab wrote:
> Em Wed,  9 Nov 2016 16:13:35 +
> Sean Young <s...@mess.org> escreveu:
> 
> > The bits are sent in lsb first. Hardware decoders also send nec32
> > in this order (e.g. dib0700). This should be consistent, however
> > I have no way of knowing which order the LME2510 and Tivo keymaps
> > are (the only two kernel keymaps with NEC32).
> 
> Hmm.. the lme2510 receives the scancode directly. So, this
> patch shouldn't affect it. So, we're stuck with the Tivo IR.
> 
> On Tivo, only a few keys (with duplicated scancodes) don't start with
> 0xa10c. So, it *seems* that this is an address.
> 
> The best here would be to try to get a Tivo remote controller[1], and
> do some tests with a driver that has a hardware decoder capable of
> output NEC32 data, and some driver that receives raw IR data in
> order to be sure.
> 
> In any case, we need to patch both the NEC32 decoder and the table
> at the same time, to be 100% sure.
> 
> [1] or some universal remote controller that could emulate
> the Tivo's scan codes. I suspect that the IR in question is
> this one, but maybe Jarod could shed some light here:
>   
> https://www.amazon.com/TiVo-Remote-Control-Universal-Replacement/dp/B00DYYKA04

Been away from the game for a few years now, so there are a good number of
cobwebs in this section of my brain... I'm pretty sure I do have both a
remote and receiver on hand that would fit the bill here though. Is the
question primarily about what actually gets emitted by the TiVo remote?

-- 
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] [media] dvb: avoid warning in dvb_net

[Jarod Wilson]

On Thu, Oct 27, 2016 at 05:09:28PM +0200, Arnd Bergmann wrote:
> On Thursday, October 27, 2016 10:13:27 AM CEST Jarod Wilson wrote:
> > On Thu, Oct 27, 2016 at 03:57:41PM +0200, Arnd Bergmann wrote:
> > > With gcc-5 or higher on x86, we can get a bogus warning in the
> > > dvb-net code:
> > > 
> > > drivers/media/dvb-core/dvb_net.c: In function ‘dvb_net_ule’:
> > > arch/x86/include/asm/string_32.h:77:14: error: ‘dest_addr’ may be used 
> > > uninitialized in this function [-Werror=maybe-uninitialized]
> > > drivers/media/dvb-core/dvb_net.c:633:8: note: ‘dest_addr’ was declared 
> > > here
> > > 
> > > The problem here is that gcc doesn't track all of the conditions
> > > to prove it can't end up copying uninitialized data.
> > > This changes the logic around so we zero out the destination
> > > address earlier when we determine that it is not set here.
> > > This allows the compiler to figure it out.
> > > 
> > > Signed-off-by: Arnd Bergmann <a...@arndb.de>
> > > ---
> > >  drivers/media/dvb-core/dvb_net.c | 12 +---
> > >  1 file changed, 5 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/media/dvb-core/dvb_net.c 
> > > b/drivers/media/dvb-core/dvb_net.c
> > > index 088914c4623f..f1b416de9dab 100644
> > > --- a/drivers/media/dvb-core/dvb_net.c
> > > +++ b/drivers/media/dvb-core/dvb_net.c
> > > @@ -688,6 +688,9 @@ static void dvb_net_ule( struct net_device *dev, 
> > > const u8 *buf, size_t buf_len )
> > > ETH_ALEN);
> > >   skb_pull(priv->ule_skb, 
> > > ETH_ALEN);
> > >   }
> > > + } else {
> > > +  /* othersie use zero destination 
> > > address */
> > 
> > I'm assuming you meant "otherwise" there instead of "othersie".
> > 
> 
> Yes, I sent a v2 now, thanks for taking a look. I assume this means
> you have no other objections to the patch?

No objections, but I don't know enough about ULE or it's handling there
to do an informed critique outside of the typo.

-- 
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] [media] dvb: avoid warning in dvb_net

[Jarod Wilson]

On Thu, Oct 27, 2016 at 03:57:41PM +0200, Arnd Bergmann wrote:
> With gcc-5 or higher on x86, we can get a bogus warning in the
> dvb-net code:
> 
> drivers/media/dvb-core/dvb_net.c: In function ‘dvb_net_ule’:
> arch/x86/include/asm/string_32.h:77:14: error: ‘dest_addr’ may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/media/dvb-core/dvb_net.c:633:8: note: ‘dest_addr’ was declared here
> 
> The problem here is that gcc doesn't track all of the conditions
> to prove it can't end up copying uninitialized data.
> This changes the logic around so we zero out the destination
> address earlier when we determine that it is not set here.
> This allows the compiler to figure it out.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
>  drivers/media/dvb-core/dvb_net.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_net.c 
> b/drivers/media/dvb-core/dvb_net.c
> index 088914c4623f..f1b416de9dab 100644
> --- a/drivers/media/dvb-core/dvb_net.c
> +++ b/drivers/media/dvb-core/dvb_net.c
> @@ -688,6 +688,9 @@ static void dvb_net_ule( struct net_device *dev, const u8 
> *buf, size_t buf_len )
> ETH_ALEN);
>   skb_pull(priv->ule_skb, 
> ETH_ALEN);
>   }
> + } else {
> +  /* othersie use zero destination 
> address */

I'm assuming you meant "otherwise" there instead of "othersie".

-- 
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] nuvoton-cir: Don't touch PS/2 interrupts while initializing

[Jarod Wilson]

On Sat, Jan 25, 2014 at 11:57:46AM +0200, Antti Seppälä wrote:
 There are reports[1] that on some motherboards loading the nuvoton-cir
 disables PS/2 keyboard input. This is caused by an erroneous write of
 CIR_INTR_MOUSE_IRQ_BIT to ACPI control register.
 
 According to datasheet the write enables mouse power management event
 interrupts which will probably have ill effects if the motherboard has
 only one PS/2 port with keyboard in it.
 
 The cir hardware does not need mouse interrupts to function and should
 not touch them. This patch removes the illegal writes and registry
 definitions.

Probably a carry-over from the old Nuvoton code, nuking it makes sense to
me, always thought it was a little odd, but it never caused issues on the
system I had (which had no ps2).

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 mceusb: fix invalid urb interval

[Jarod Wilson]

On Sun, Jan 19, 2014 at 09:56:48PM +, Sean Young wrote:
 On Sun, Jan 19, 2014 at 10:05:15PM +0100, Martin Kittel wrote:
  Hi Mauro, hi Sean,
...
  From a71676dad29adef9cafb08598e693ec308ba2e95 Mon Sep 17 00:00:00 2001
  From: Martin Kittel li...@martin-kittel.de
  Date: Sun, 19 Jan 2014 21:24:55 +0100
  Subject: [PATCH] mceusb: use endpoint xfer mode as advertised
  
  mceusb always sets endpoints to interrupt transfer mode no matter
  what the device itself is advertising. This causes trouble on xhci
  hubs. This patch changes the behavior to honor the device endpoint
  settings.
 
 This patch is wrong. I get:
 
 [   60.962727] [ cut here ]
 [   60.962729] WARNING: CPU: 0 PID: 0 at drivers/usb/core/urb.c:452 
 usb_submit_u
 rb+0x1fd/0x5b0()
 [   60.962730] usb 3-2: BOGUS urb xfer, pipe 1 != type 3
 
 This is because the patch no longer sets the endpoints to interrupt
 endpoints, but still uses the interrupt functions like
 usb_fill_int_urb().

Crap, I sent a working patch to everyone a few days ago, but from a new
host that didn't have relay stuff set up yet, so I don't think anyone got
the message. Oops... I'll try to dig it back up. Its a quick fix, but its
tested as fully functional on multiple devices here, including a mix of
ones that claim bulk and interrupt, ones with no bInterval, ones with
different non-0 bIntervals, etc.

-- 
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 mceusb: fix invalid urb interval

[Jarod Wilson]

On Wed, Jan 15, 2014 at 04:52:45PM +, Sean Young wrote:
 On Wed, Jan 15, 2014 at 01:49:17PM -0200, Mauro Carvalho Chehab wrote:
  Hi Martin,
  
  Em Wed, 11 Dec 2013 21:34:55 +0100
  Martin Kittel li...@martin-kittel.de escreveu:
  
   Hi Mauro, hi Sean,
   
   thanks for considering the patch. I have added an updated version at the
   end of this mail.
   
   Regarding the info Sean was requesting, it is indeed an xhci hub. I also
   added the details of the remote itself.
   
   Please let me know if there is anything missing.
   
   Best wishes,
   
   Martin.
   
   
   lsusb -vvv
   --
   Bus 001 Device 002: ID 2304:0225 Pinnacle Systems, Inc. Remote Kit
   Infrared Transceiver
   Device Descriptor:
 bLength  18
 bDescriptorType   1
 bcdUSB 2.00
 bDeviceClass  0 (Defined at Interface level)
 bDeviceSubClass   0
 bDeviceProtocol   0
 bMaxPacketSize0   8
 idVendor 0x2304 Pinnacle Systems, Inc.
 idProduct0x0225 Remote Kit Infrared Transceiver
 bcdDevice  0.01
 iManufacturer 1 Pinnacle Systems
 iProduct  2 PCTV Remote USB
 iSerial   5 7FFF
 bNumConfigurations1
 Configuration Descriptor:
   bLength   9
   bDescriptorType   2
   wTotalLength 32
   bNumInterfaces1
   bConfigurationValue   1
   iConfiguration3 StandardConfiguration
   bmAttributes   0xa0
 (Bus Powered)
 Remote Wakeup
   MaxPower100mA
   Interface Descriptor:
 bLength   9
 bDescriptorType   4
 bInterfaceNumber  0
 bAlternateSetting 0
 bNumEndpoints 2
 bInterfaceClass 255 Vendor Specific Class
 bInterfaceSubClass  0
 bInterfaceProtocol  0
 iInterface4 StandardInterface
 Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x81  EP 1 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0040  1x 64 bytes
 bInterval  10
  
  Hmm... interval is equal to 10, e. g. 125us * 2^(10 - 1) = 64 ms.
  
  I'm wandering why mceusb is just forcing the interval to 1 (125ms). That
  sounds wrong, except, of course, if the endpoint descriptor is wrong.
 
 Note that the endpoint descriptor describes it as a bulk endpoint, but
 it is used as a interrupt endpoint by the driver. For bulk endpoints,
 the interval should not be used (?).
 
 Maybe the correct solution would be to use the endpoints as bulk endpoints
 if that is what the endpoint says? mceusb devices come in interrupt and 
 bulk flavours.

Yeah, I just went through a number of my devices here. I have the same
pinnacle one with bulk and 10, a topseed with bulk and 1, a topseed with
interrupt and 0, a philips with bulk and 0... There's a pretty nasty mix
of them. The interrupt and 0 one actually winds up with a default
bInterval of 32 from the usb subsystem, but the bulk/0 one sticks with a
default of 0.

Something to properly handle bulk vs. interrupt might be useful, but at
least at first glance here, simply saying

if (ep_{in,out}-bInterval == 0)
ep_{in,out}-bInterval = 8;

seems to work just fine here with the stack of mceusb devices I've tried
so far (all hooked to usb 1.1 and/or usb 2.0 ports).

  On my eyes, though, 64ms seems to be a good enough interval to get
  those events.
 
 Each packet will be 64 bytes, and at 64 ms you should be able to 960 
 bytes per second. That's more than enough.
 
  Jarod/Sean,
  
  Are there any good reason for the mceusb driver to do this?
  ep_in-bInterval = 1;
  ep_out-bInterval = 1;
 
 I don't know.

It was basically a cover for the bulk/bInterval=0 case.

 The xhci driver is not happy about the interval being changed. With
 CONFIG_USB_DEBUG you get:
 
 usb 3-12: Driver uses different interval (8 microframes) than xHCI (1 
 microframe)

I suppose I need to get a machine with usb3 up and running to poke at...

-- 
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] MAINTAINERS: Remove Jarod Wilson and orphan LIRC drivers

[Jarod Wilson]

On Wed, Feb 13, 2013 at 09:36:04AM +0300, Dan Carpenter wrote:
 On Tue, Feb 12, 2013 at 01:20:36PM -0800, Joe Perches wrote:
  His email bounces and he hasn't done work on
  these sections in a couple of years.
  
 
 I've added him to the CC list.
 
 Can we just update MAINTAINERS with the correct email address?  It's
 been useful to CC him on stuff.

Domain reg lapsed, never saw the notice, but its all better now. Yes, I've
been inactive on this stuff of late, lots going on in my personal life
that has reduced free time for upstream work to nearly nil. I hope to get
back into it once things settle down, which should be happening relativley
soon...

-- 
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 0/8] rc-core: patches for 3.7

[Jarod Wilson]

On Sat, Aug 25, 2012 at 11:46:47PM +0200, David Härdeman wrote:
 This is two minor winbond-cir fixes as well as the first six patches
 from my previous patchbomb.
 
 The latter have been modified so that backwards compatibility is retained
 as much as possible (the format of the sysfs files do not change for
 example).

I've read through the set, and it all seems to make sense to me, but I
haven't actually tried it out with any of the hardware I've got. I assume
its been tested on various other hardware though.

Side note: my life has been turned a wee bit upside down, been busy
dealing with some fairly big changes, and that's still ongoing, thus the
relative lack of repsonsiveness on, well, anything, lately.


-- 
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 5/8] nuvoton-cir: Code cleanup: remove unused variable and function

[Jarod Wilson]

On Thu, Jun 14, 2012 at 02:58:13PM -0300, Peter Senna Tschudin wrote:
 Tested by compilation only.

Making use of this code is on the TODO list, possibly even happens by way
of David's pending patches for lirc interface parity, so I'm against
removing it.

-- 
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

[PATCH] [media] lirc_sir: make device registration work

[Jarod Wilson]

For one, the driver device pointer needs to be filled in, or the lirc core
will refuse to load the driver. And we really need to wire up all the
platform_device bits. This has been tested via the lirc sourceforge tree
and verified to work, been sitting there for months, finally getting
around to sending it. :\

CC: Josh Boyer jwbo...@redhat.com
CC: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/media/lirc/lirc_sir.c |   60 +++-
 1 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_sir.c 
b/drivers/staging/media/lirc/lirc_sir.c
index 945d962..4afc3b4 100644
--- a/drivers/staging/media/lirc/lirc_sir.c
+++ b/drivers/staging/media/lirc/lirc_sir.c
@@ -52,6 +52,7 @@
 #include linux/io.h
 #include asm/irq.h
 #include linux/fcntl.h
+#include linux/platform_device.h
 #ifdef LIRC_ON_SA1100
 #include asm/hardware.h
 #ifdef CONFIG_SA1100_COLLIE
@@ -487,9 +488,11 @@ static struct lirc_driver driver = {
.owner  = THIS_MODULE,
 };
 
+static struct platform_device *lirc_sir_dev;
 
 static int init_chrdev(void)
 {
+   driver.dev = lirc_sir_dev-dev;
driver.minor = lirc_register_driver(driver);
if (driver.minor  0) {
printk(KERN_ERR LIRC_DRIVER_NAME : init_chrdev() failed.\n);
@@ -1215,20 +1218,71 @@ static int init_lirc_sir(void)
return 0;
 }
 
+static int __devinit lirc_sir_probe(struct platform_device *dev)
+{
+   return 0;
+}
+
+static int __devexit lirc_sir_remove(struct platform_device *dev)
+{
+   return 0;
+}
+
+static struct platform_driver lirc_sir_driver = {
+   .probe  = lirc_sir_probe,
+   .remove = __devexit_p(lirc_sir_remove),
+   .driver = {
+   .name   = lirc_sir,
+   .owner  = THIS_MODULE,
+   },
+};
 
 static int __init lirc_sir_init(void)
 {
int retval;
 
+   retval = platform_driver_register(lirc_sir_driver);
+   if (retval) {
+   printk(KERN_ERR LIRC_DRIVER_NAME : Platform driver register 
+  failed!\n);
+   return -ENODEV;
+   }
+
+   lirc_sir_dev = platform_device_alloc(lirc_dev, 0);
+   if (!lirc_sir_dev) {
+   printk(KERN_ERR LIRC_DRIVER_NAME : Platform device alloc 
+  failed!\n);
+   retval = -ENOMEM;
+   goto pdev_alloc_fail;
+   }
+
+   retval = platform_device_add(lirc_sir_dev);
+   if (retval) {
+   printk(KERN_ERR LIRC_DRIVER_NAME : Platform device add 
+  failed!\n);
+   retval = -ENODEV;
+   goto pdev_add_fail;
+   }
+
retval = init_chrdev();
if (retval  0)
-   return retval;
+   goto fail;
+
retval = init_lirc_sir();
if (retval) {
drop_chrdev();
-   return retval;
+   goto fail;
}
+
return 0;
+
+fail:
+   platform_device_del(lirc_sir_dev);
+pdev_add_fail:
+   platform_device_put(lirc_sir_dev);
+pdev_alloc_fail:
+   platform_driver_unregister(lirc_sir_driver);
+   return retval;
 }
 
 static void __exit lirc_sir_exit(void)
@@ -1236,6 +1290,8 @@ static void __exit lirc_sir_exit(void)
drop_hardware();
drop_chrdev();
drop_port();
+   platform_device_unregister(lirc_sir_dev);
+   platform_driver_unregister(lirc_sir_driver);
printk(KERN_INFO LIRC_DRIVER_NAME : Uninstalled.\n);
 }
 
-- 
1.7.1

--
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] [media] fintek-cir: change || to

[Jarod Wilson]

On Sun, Apr 22, 2012 at 11:06:17AM +0300, Dan Carpenter wrote:
 The current condition is always true, so everything uses
 LOGICAL_DEV_CIR_REV2 (8).  It should be that Fintek products
 0x0408(F71809) and 0x0804(F71855) use logical device
 LOGICAL_DEV_CIR_REV1 (5) and other chip ids use logical device 8.
 
 In other words, this fixes hardware detection for 0x0408 and 0x0804.
 
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

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 v3] [media] rc: Postpone ISR registration

[Jarod Wilson]

On Sat, Apr 21, 2012 at 05:25:21PM +0100, Luis Henriques wrote:
 An early registration of an ISR was causing a crash to several users (for
 example, with the ite-cir driver: http://bugs.launchpad.net/bugs/972723).
 The reason was that IRQs were being triggered before a driver
 initialisation was completed.
 
 This patch fixes this by moving the invocation to request_irq() and to
 request_region() to a later stage on the driver probe function.

From what I can tell, it looks like v3 should do the job for all affected
drivers.

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 v3 1/1] rc: Add support for GPIO based IR Receiver driver.

[Jarod Wilson]

On Tue, Feb 28, 2012 at 11:21:40AM +0530, Ravi Kumar V wrote:
 Adds GPIO based IR Receiver driver. It decodes signals using decoders
 available in rc framework.

Been meaning to look at this, but it looks like its already merged
upstream. Just one question though, inlined below.

 --- /dev/null
 +++ b/drivers/media/rc/gpio-ir-recv.c
 @@ -0,0 +1,205 @@
 +/* Copyright (c) 2012, Code Aurora Forum. All rights reserved.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 and
 + * only version 2 as published by the Free Software Foundation.
 + *
 + * 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.
 + */
 +
 +#include linux/kernel.h
 +#include linux/init.h
 +#include linux/module.h
 +#include linux/interrupt.h
 +#include linux/gpio.h
 +#include linux/slab.h
 +#include linux/platform_device.h
 +#include linux/irq.h
 +#include media/rc-core.h
 +#include media/gpio-ir-recv.h
 +
 +#define GPIO_IR_DRIVER_NAME  gpio-rc-recv
 +#define GPIO_IR_DEVICE_NAME  gpio_ir_recv
 +
 +struct gpio_rc_dev {
 + struct rc_dev *rcdev;
 + unsigned int gpio_nr;
 + bool active_low;
 +};
 +
 +static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
 +{
 + struct gpio_rc_dev *gpio_dev = dev_id;
 + unsigned int gval;
 + int rc = 0;
 + enum raw_event_type type = IR_SPACE;
 +
 + gval = gpio_get_value_cansleep(gpio_dev-gpio_nr);
 +
 + if (gval  0)
 + goto err_get_value;
 +
 + if (gpio_dev-active_low)
 + gval = !gval;
 +
 + if (gval == 1)
 + type = IR_PULSE;

What happens if gval is  1?

 + rc = ir_raw_event_store_edge(gpio_dev-rcdev, type);
 + if (rc  0)
 + goto err_get_value;
 +
 + ir_raw_event_handle(gpio_dev-rcdev);
 +
 +err_get_value:
 + return IRQ_HANDLED;
 +}

Looks like you'll store a space any time you get gval  1, which may or
may not be intended here...


-- 
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: nuvoton-cir on Intel DH67CL

[Jarod Wilson]

On Tue, Mar 20, 2012 at 10:46:46PM +0100, Steffen Barszus wrote:
 On Mon, 19 Mar 2012 17:00:11 -0400
 Jarod Wilson ja...@redhat.com wrote:
  On Wed, Mar 14, 2012 at 10:32:43PM +0100, Steffen Barszus wrote:
   Anything to be activated to wakeup on S3/S5 ?  I.e. the key to wake
   it up ? I'm using RC6 remote - operation as already said is without
   any issues, just not wakeup. 
  
  It occurs to me that the box I've got had Windows on it at one point,
  and its possible wake via IR works only because someone set a wake
  key pattern under Windows. And that your box doesn't wake, because it
  hasn't had a wake key pattern set yet. We don't have any UI for
  setting a wake key pattern just yet... (Or if we do, I'm just not
  familiar with it).
 
 
 Anything i can do to help getting it going ? (Except writing a driver)
 I could not find any reference to a tool either - so i guess it just
 doesnt exist :) 

Nothing comes to mind, and I've not had time to look into it any further,
let alone reply to you. :\

-- 
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 v2] [media] rc: Postpone ISR registration

[Jarod Wilson]

 + SP_IOMEM_LEN - 1);
 + err = -EBUSY;
 + goto exit_release_ebase;
 + }
 +
 + err = request_irq(data-irq, wbcir_irq_handler,
 +   IRQF_DISABLED, DRVNAME, device);
 + if (err) {
 + dev_err(dev, Failed to claim IRQ %u\n, data-irq);
 + err = -EBUSY;
 + goto exit_release_sbase;
 + }
 +
   err = rc_register_device(data-dev);
   if (err)
   goto exit_free_rc;
 -- 
 1.7.9.5
 

-- 
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: [media] fintek-cir: add support for newer chip version

[Jarod Wilson]

On Thu, Apr 19, 2012 at 08:25:10PM +0300, Dan Carpenter wrote:
 Hi Mauro,
 
 The patch 83ec8225b6ae: [media] fintek-cir: add support for newer 
 chip version from Feb 14, 2012, leads to the following warning:
 drivers/media/rc/fintek-cir.c:200 fintek_hw_detect()
warn: known condition '1032 != 2052'
 
 drivers/media/rc/fintek-cir.c
197  /*
198   * Newer reviews of this chipset uses port 8 instead of 5
199   */
200  if ((chip != 0x0408) || (chip != 0x0804))
  ^^
 One of these conditions is always true.
 
 Probably it should it be:
   if ((chip == 0x0408) || (chip == 0x0804))
 or:
   if ((chip != 0x0408)  (chip != 0x0804))

Reasonably sure the latter case would be the proper one there.


 depending one if those are the newer or the older chipsets.  I googled
 for it a bit and then decided to just email you.  :P
 
201  fintek-logical_dev_cir = LOGICAL_DEV_CIR_REV2;
202  else
203  fintek-logical_dev_cir = LOGICAL_DEV_CIR_REV1;
204  
 
 regards,
 dan carpenter
 

-- 
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 1/1] [media] ite-cir: postpone ISR registration

[Jarod Wilson]

On Wed, Apr 18, 2012 at 09:54:07PM +0100, Luis Henriques wrote:
 An early registration of an ISR was causing a crash to several users (for
 example here: http://bugs.launchpad.net/bugs/972723  The reason was that
 IRQs were being triggered before the driver initialisation was completed.
 
 This patch fixes this by moving the invocation to request_irq() to a later
 stage on the driver probe function.

Ugh. Looks like we actually have a similar problem with multiple lpc super
i/o based CIR drivers. I'd probably move both the irq and io region
requests in ite-cir, fintek-cir, nuvoton-cir, ene_ir and winbond-cir. If
I'm thinking clearly, I've actually seen a very similar report for one of
the other CIR drivers recently. Good catch. But yeah, lets do the same for
all the drivers, and move request_region as well.

-- 
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: nuvoton-cir on Intel DH67CL

[Jarod Wilson]

On Wed, Mar 14, 2012 at 10:32:43PM +0100, Steffen Barszus wrote:
 On Wed, 14 Mar 2012 16:41:01 -0400
 Jarod Wilson ja...@redhat.com wrote:
 
  On Wed, Mar 14, 2012 at 07:10:37AM +0100, Steffen Barszus wrote:
   Hi !
   
   I'm using above board which has a nuvoton-cir onboard (as most Intel
   Media boards) - It shows itself as NTN0530. 
   
   The remote function works without a problem (loaded RC6 MCE
   keytable). 
   
   What doesn't work is wake from S3 and wake from S5. There are some
   rumors that installing Windows 7 and corresponding drivers has a
   positive effect (for some it seems to be enough to do it one time,
   others need to redo this from time to time (power loss?). This
   leads me to believe, that some hardware initialization is missing. 
   
   I'm about to try latest linux-media tree next days, but i believe
   there hasn't been any change on this driver. 
   
   My questions: 
   - any idea of what i should look at ?
   - any change on the driver i could try ? 
   - *IF* i go to install Win7 and drivers - anything i could to to
   help tracking down what this does in order to make the driver work
   out of the box on linux ?
   
   As a lot of Sandy Bridge Boards to have this chip lately - it would
   be nice if this could just work or is my impression, that this is a
   general problem in this hardware wrong ?   
  
  My only nuvoton hardware works perfectly w/resume via IR after commit
  3198ed161c9be9bbd15bb2e9c22561248cac6e6a, but its possible what
  you've got is a newer hardware variant with some slightly different
  registers to tweak. What does the driver identify your chip as in
  dmesg?
 
 I'm on Linux 3.2.0-18-generic #29-Ubuntu SMP (Ubuntu Precise)
 
 
  As of commit 362d3a3a9592598cef1d3e211ad998eb844dc5f3, the driver will
  bind to anything with the PNP ID of NTN0530, but will spew a warning
  in dmesg if its not an explicitly recognized chip.
  
 
 From dmesg it seems to be fine. 
 [0.553258] system 00:02: [io  0x0290-0x029f] has been reserved
 [0.553261] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
 [0.553504] pnp 00:03: [io  0x0240-0x024f]
 [0.553513] pnp 00:03: [irq 3]
 [0.553515] pnp 00:03: [io  0x0250-0x025f]
 [0.553534] pnp 00:03: Plug and Play ACPI device, IDs NTN0530 (active)
 [0.553544] pnp 00:04: [dma 4]
 [0.553545] pnp 00:04: [io  0x-0x000f]
 [0.553547] pnp 00:04: [io  0x0081-0x0083]
 [0.553549] pnp 00:04: [io  0x0087]
 [0.553550] pnp 00:04: [io  0x0089-0x008b]
 [0.553552] pnp 00:04: [io  0x008f]
 [0.553553] pnp 00:04: [io  0x00c0-0x00df]
 
 Anything to be activated to wakeup on S3/S5 ?  I.e. the key to wake it
 up ? I'm using RC6 remote - operation as already said is without any
 issues, just not wakeup. 

It occurs to me that the box I've got had Windows on it at one point, and
its possible wake via IR works only because someone set a wake key pattern
under Windows. And that your box doesn't wake, because it hasn't had a
wake key pattern set yet. We don't have any UI for setting a wake key
pattern just yet... (Or if we do, I'm just not familiar with it).

-- 
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] media: rc: Pospone ir raw decoders loading until really needed

[Jarod Wilson]

On Thu, Mar 15, 2012 at 04:39:02PM -0300, Ezequiel Garcia wrote:
 This changes rc_core to not load the IR decoders at load time,
 postponing it to load only if a RC_DRIVER_IR_RAW device is registered
 via rc_register_device.
 
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
 ---
  drivers/media/rc/rc-main.c |8 ++--
  include/media/rc-core.h|2 ++
  2 files changed, 8 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
 index f6a930b..adf4a99 100644
 --- a/drivers/media/rc/rc-main.c
 +++ b/drivers/media/rc/rc-main.c
 @@ -1103,6 +1103,12 @@ int rc_register_device(struct rc_dev *dev)
   kfree(path);
  
   if (dev-driver_type == RC_DRIVER_IR_RAW) {
 + /* Load raw decoders, if they aren't already */
 + if (dev-raw_init) {
 + IR_dprintk(1, Loading raw decoders\n);
 + ir_raw_init();
 + dev-raw_init = true;
 + }
   rc = ir_raw_event_register(dev);
   if (rc  0)
   goto out_input;
 @@ -1176,8 +1182,6 @@ static int __init rc_core_init(void)
   return rc;
   }
  
 - /* Initialize/load the decoders/keymap code that will be used */
 - ir_raw_init();
   rc_map_register(empty_map);
  
   return 0;

Uhm. How does this ever actually work? The only place I see raw_init set
to true is inside a conditional that requires it already be true. That's
not going to fly.

-- 
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 v2] media: rc: Pospone ir raw decoders loading until really needed

[Jarod Wilson]

On Thu, Mar 15, 2012 at 05:53:49PM -0300, Ezequiel Garcia wrote:
 This changes rc_core to not load the IR decoders at load time,
 postponing it to load only if a RC_DRIVER_IR_RAW device is 
 registered via rc_register_device.
 We use a static boolean variable, to ensure decoders modules
 are only loaded once.
 Tested with rc-loopback device only.
 
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
 ---
 v2: Fix broken logic in v1. 
 Also, put raw_init as static instead of inside rc_dev
 struct to ensure loading is only tried the first time.
 ---
  drivers/media/rc/rc-main.c |   11 +--
  1 files changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
 index f6a930b..d366d53 100644
 --- a/drivers/media/rc/rc-main.c
 +++ b/drivers/media/rc/rc-main.c
 @@ -32,6 +32,9 @@
  static LIST_HEAD(rc_map_list);
  static DEFINE_SPINLOCK(rc_map_lock);
  
 +/* Used to load raw decoders modules only if needed */
 +static bool raw_init;
 +
  static struct rc_map_list *seek_rc_map(const char *name)
  {
   struct rc_map_list *map = NULL;
 @@ -1103,6 +1106,12 @@ int rc_register_device(struct rc_dev *dev)
   kfree(path);
  
   if (dev-driver_type == RC_DRIVER_IR_RAW) {
 + /* Load raw decoders, if they aren't already */
 + if (!raw_init) {
 + IR_dprintk(1, Loading raw decoders\n);

I think this is slightly redundant, since we already print something for
each of the decoders loaded, but eh, its a debug printk, maybe you're
debugging why none are loading, so its good to know you're reaching the
call to ir_raw_init...

So yeah, ok, I'm fine with this. Haven't tested it with actual raw IR
hardware, but I don't see any reason it wouldn't work.

Acked-by: Jarod Wilson ja...@redhat.com

 + ir_raw_init();
 + raw_init = true;
 + }
   rc = ir_raw_event_register(dev);
   if (rc  0)
   goto out_input;
 @@ -1176,8 +1185,6 @@ static int __init rc_core_init(void)
   return rc;
   }
  
 - /* Initialize/load the decoders/keymap code that will be used */
 - ir_raw_init();
   rc_map_register(empty_map);
  
   return 0;

-- 
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 v2] media: rc: Pospone ir raw decoders loading until really needed

[Jarod Wilson]

On Mar 15, 2012, at 5:42 PM, Ezequiel García elezegar...@gmail.com wrote:

 Hi Jarod,
 
 On Thu, Mar 15, 2012 at 6:35 PM, Jarod Wilson ja...@redhat.com wrote:
 
 So yeah, ok, I'm fine with this. Haven't tested it with actual raw IR
 hardware, but I don't see any reason it wouldn't work.
 
 Acked-by: Jarod Wilson ja...@redhat.com
 
 Thanks for the feedback.
 I have a paranoid question: Is it ok to solve this with a static variable?
 I don't like static (as I fear globals), but in this case I saw no
 cleaner solution.

Ah, actually... I think you could avoid the global and just make it 
function-local, since no others access it, and be just as functional.

-j

N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w*jg����ݢj/���z�ޖ��2�ޙ�)ߡ�a�����G���h��j:+v���w��٥

Re: nuvoton-cir on Intel DH67CL

[Jarod Wilson]

On Wed, Mar 14, 2012 at 07:10:37AM +0100, Steffen Barszus wrote:
 Hi !
 
 I'm using above board which has a nuvoton-cir onboard (as most Intel
 Media boards) - It shows itself as NTN0530. 
 
 The remote function works without a problem (loaded RC6 MCE keytable). 
 
 What doesn't work is wake from S3 and wake from S5. There are some
 rumors that installing Windows 7 and corresponding drivers has a
 positive effect (for some it seems to be enough to do it one time,
 others need to redo this from time to time (power loss?). This leads me
 to believe, that some hardware initialization is missing. 
 
 I'm about to try latest linux-media tree next days, but i believe
 there hasn't been any change on this driver. 
 
 My questions: 
 - any idea of what i should look at ?
 - any change on the driver i could try ? 
 - *IF* i go to install Win7 and drivers - anything i could to to help
   tracking down what this does in order to make the driver work out
   of the box on linux ?
 
 As a lot of Sandy Bridge Boards to have this chip lately - it would
 be nice if this could just work or is my impression, that this is a
 general problem in this hardware wrong ?   

My only nuvoton hardware works perfectly w/resume via IR after commit
3198ed161c9be9bbd15bb2e9c22561248cac6e6a, but its possible what you've got
is a newer hardware variant with some slightly different registers to
tweak. What does the driver identify your chip as in dmesg?

As of commit 362d3a3a9592598cef1d3e211ad998eb844dc5f3, the driver will
bind to anything with the PNP ID of NTN0530, but will spew a warning in
dmesg if its not an explicitly recognized chip.

-- 
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

[PATCH] mceusb: add Formosa device ID 0xe042

[Jarod Wilson]

Yet another device ID that has started showing up in the wild.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 60d3c1e..0918c69 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -361,6 +361,8 @@ static struct usb_device_id mceusb_dev_table[] = {
{ USB_DEVICE(VENDOR_FORMOSA, 0xe03c) },
/* Formosa Industrial Computing */
{ USB_DEVICE(VENDOR_FORMOSA, 0xe03e) },
+   /* Formosa Industrial Computing */
+   { USB_DEVICE(VENDOR_FORMOSA, 0xe042) },
/* Fintek eHome Infrared Transceiver (HP branded) */
{ USB_DEVICE(VENDOR_FINTEK, 0x5168) },
/* Fintek eHome Infrared Transceiver */
-- 
1.7.1

--
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: Fintek driver linux

[Jarod Wilson]

On 02/14/2012 02:47 PM, W R wrote:

Thanks again Jarod. I have emailed Jetway asking about the specs for the
CIR header on the motheboard. (JNC64-LF - nvidia chipset, *not* Atom/Ion
though...) which they have replied is the Fintek F71809 I/O chipset, and
I believe the same chipset on many of their Atom boards.
According to Fintek this had linux support since kernel 2.6.36? Not sure
about that.


Looks like it went in upstream after 2.6.39, so the first release that 
carried it was actually 3.0.


If it really is the F71809, then the fix I had in mind shouldn't matter, 
but I'd have to question if its really that and not an F71869A, which is 
nearly identical, but needs to use a different logical device for the IR 
input, lest you lock up the system -- sounds familiar, eh? :)


However, its also possible its something else going on here, some sort 
of bad interaction between multiple different drivers all poking at the 
super i/o chip without any coordinated locking.


Now, I *think* that if you get evdev installed and run it against the 
input device that fintek-cir exposes, you should be able to see the chip 
ID to confirm if its really the F71809 or not. If you see Product and 
Version of 0x08 and 0x04 (or vice versa), then its indeed one of the 
older chips that use logical device 5. Anything else, and it should be 
logical device 8, and a patch that just went into the for-v3.4 media 
tree branch is necessary.


-j



Since my previous email I have left my IR device plugged in to the
header on the motherboard and I have added fintek-cir to the blacklist.
After boot if I modprobe ir-rc6-decoder (which triggers rc-core and
lirc_dev and all the other protocols etc.) then fairly quickly after
that modprobe fintek-cir then 1 in 10 times it actually works. The other
9 times it freezes. It freezes everytime if I try to start fintek-cir
first.
I have already added my remotes config with the help of ir-keytable to
/etc/rc_keymaps/ and pointed /etc/rc_maps.cfg towards it. It gets loaded
automatically. I have uninstalled LIRC. A copy of my logs when it hasn't
crashed is here: http://pastebin.com/MqETvBsz
Not sure if any of this helps anyone, and to anyone reading this please
feel free to point out any of my stupid errors!


  Date: Fri, 10 Feb 2012 13:56:38 -0500
  From: ja...@redhat.com
  To: gridmunc...@hotmail.com
  Subject: Re: Fintek driver linux
 
  On 02/05/2012 10:48 AM, W R wrote:
   Tried various kernels, including 3.0.0 and 3.2 and kernel panic is
   almost always caused when ir receiver plugged into cir header on
   motherboard. If device plugged in after boot then it works fine.
Can use
   remote and configure buttons etc.
  
   Where's a good forum to discuss this openly so others with perhaps the
   same issues can read it?
 
  linux-media@vger.kernel.org is the relevant upstream mailing list.
 
 
   Any ideas off-hand why this is? I have various cir header options in
   bios: Disabled, 3F8/IRQ4, 2F8/IRQ3, 3E8/IRQ4, 2E8/IRQ3 and have tried
   all of these without luck, although I have once or twice been able to
   boot into mythbuntu and its worked. But out of 50 odd boot attempts it
   worked twice. I also have the choice to enable wake from CIR which
   obviously I need to have on to be able to wake my HTPC with remote. Any
   help would be greatly appreciated.
 
  According to my fintek contact, the CIR logical device on a number of
  shipped systems is actually different than the devel board I was
  provided, so there's a patch coming to account for that. Its possible
  what you're seeing is due to the incorrect logical device number, but
  I'm just shooting in the dark.
 
 
  --
  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] [media] hdpvr: update picture controls to support firmware versions 0.15

[Jarod Wilson]

On Mon, Nov 7, 2011 at 7:54 PM, Taylor Ralph taylor.ra...@gmail.com wrote:
 On Mon, Nov 7, 2011 at 7:21 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Em 21-10-2011 01:33, Taylor Ralph escreveu:
 On Thu, Oct 20, 2011 at 3:26 PM, Taylor Ralph taylor.ra...@gmail.com 
 wrote:
 On Thu, Oct 20, 2011 at 2:14 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
 On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau j...@jannau.net wrote:
 I think such scenario is unlikely but I don't know it for sure and
 I don't want to force anyone to test every firmware version.
 Ignoring them for firmware version  16 should be safe since we assume
 they had no effect. Returning -EINVAL might break API-ignoring
 applications written with the HD PVR in mind but I think it's a better
 approach than silently ignoring those controls.

 At this point, let's just make it so that the old behavior is
 unchanged for old firmwares, meaning from both an API standpoint as
 well as what the values are.  At some point if somebody cares enough
 to go back and fix the support so that the controls actually work with
 old firmwares, they can take that up as a separate task.  In reality,
 it is likely that nobody will ever do that, as the easy answer is
 just to upgrade to firmware 16.

 Taylor, could you please tweak your patch to that effect and resubmit?


 Sure, I'll try to get to it tonight and have it tested.

Looks sane to me, and really needs to get in ASAP. I'd even suggest we
get it sent to stable, as these newer firmware HDPVR are pretty wonky
with any current kernel.

Acked-by: Jarod Wilson ja...@redhat.com
Reviewed-by: Jarod Wilson ja...@redhat.com
CC: sta...@vger.kernel.org

-- 
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

Re: Fintek driver linux

[Jarod Wilson]

On 02/14/2012 04:25 PM, W R wrote:

Thanks for your quick reply. It does seem like I have the old version:

cat /proc/bus/input/devices

*I: Bus=0019 Vendor=1934 Product=0004 Version=0008*


Hm, okay, so the changes for newer hardware shouldn't matter at all.


N: Name=Fintek LPC SuperIO Consumer IR Transceiver
P: Phys=fintek/cir0

...

Is there anything out of the ordinary? Any way to find out which modules
that cause the problem and can maybe be removed?


Nothing out of the ordinary, no. You'd have to capture serial console 
output or a vmcore from the time of the crash to really get a better 
idea of where its falling down. The panic trace ought to give a clue 
where to start looking.


I can't recall, have you tried using this under Windows, and if so, was 
it stable there? A hardware fault is always a possibility, especially 
when there's only a single report of something like this. Then again, 
this is a fairly young driver. But I never saw anything like this in my 
own testing during driver devel, nor did Fintek. :\


--
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] [media] hdpvr: update picture controls to support firmware versions 0.15

[Jarod Wilson]

On Tue, Feb 14, 2012 at 4:32 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Tue, Feb 14, 2012 at 3:43 PM, Jarod Wilson ja...@wilsonet.com wrote:
 Looks sane to me, and really needs to get in ASAP. I'd even suggest we
 get it sent to stable, as these newer firmware HDPVR are pretty wonky
 with any current kernel.

 Acked-by: Jarod Wilson ja...@redhat.com
 Reviewed-by: Jarod Wilson ja...@redhat.com
 CC: sta...@vger.kernel.org

 Where did the process break down here?  Taylor did this patch *months*
 ago, and there has been absolutely no comment with why it wouldn't go
 upstream.  If he hadn't been diligent in pinging the ML repeatedly, it
 would have been lost.

It looks like for some reason, the v3 patch got eaten. :\

http://patchwork.linuxtv.org/patch/8183/ is the v2, in state Changes
Requested, but you can see in the comments a mail that says v3 is
attached, which contains the requested change (added s-o-b). A v3
patch object is nowhere to be found though. The patch *was* indeed
attached to the mail though, I've got it here in my linux-media
mailbox.

So at least on this one, I think I'm blaming patchwork, but it would
be good to better understand how that patch got eaten, and to know if
indeed its happened to other patches as well.

-- 
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

[PATCH v2] imon: don't wedge hardware after early callbacks

[Jarod Wilson]

This patch is just a minor update to one titled imon: Input from ffdc
device type ignored from Corinna Vinschen. An earlier patch to prevent
an oops when we got early callbacks also has the nasty side-effect of
wedging imon hardware, as we don't acknowledge the urb. Rework the check
slightly here to bypass processing the packet, as the driver isn't yet
fully initialized, but still acknowlege the urb and submit a new rx_urb.
Do this for both interfaces -- irrelevant for ffdc hardware, but
relevant for newer hardware, though newer hardware doesn't spew the
constant stream of data as soon as the hardware is initialized like the
older ffdc devices, so they'd be less likely to trigger this anyway...

Tested with both an ffdc device and an 0042 device.

v2: Per Corinna's suggestion and prior precedent, increment driver
version number so we can more easily tell if a user has this fix.

CC: Corinna Vinschen vinsc...@redhat.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/imon.c |   26 ++
 1 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 6ed9646..046f529 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -47,7 +47,7 @@
 #define MOD_AUTHOR Jarod Wilson ja...@wilsonet.com
 #define MOD_DESC   Driver for SoundGraph iMON MultiMedia IR/Display
 #define MOD_NAME   imon
-#define MOD_VERSION0.9.3
+#define MOD_VERSION0.9.4
 
 #define DISPLAY_MINOR_BASE 144
 #define DEVICE_NAMElcd%d
@@ -1658,9 +1658,17 @@ static void usb_rx_callback_intf0(struct urb *urb)
return;
 
ictx = (struct imon_context *)urb-context;
-   if (!ictx || !ictx-dev_present_intf0)
+   if (!ictx)
return;
 
+   /*
+* if we get a callback before we're done configuring the hardware, we
+* can't yet process the data, as there's nowhere to send it, but we
+* still need to acknowledge the URB to avoid wedging the hardware
+*/
+   if (!ictx-dev_present_intf0)
+   goto out;
+
switch (urb-status) {
case -ENOENT:   /* usbcore unlink successful! */
return;
@@ -1678,6 +1686,7 @@ static void usb_rx_callback_intf0(struct urb *urb)
break;
}
 
+out:
usb_submit_urb(ictx-rx_urb_intf0, GFP_ATOMIC);
 }
 
@@ -1690,9 +1699,17 @@ static void usb_rx_callback_intf1(struct urb *urb)
return;
 
ictx = (struct imon_context *)urb-context;
-   if (!ictx || !ictx-dev_present_intf1)
+   if (!ictx)
return;
 
+   /*
+* if we get a callback before we're done configuring the hardware, we
+* can't yet process the data, as there's nowhere to send it, but we
+* still need to acknowledge the URB to avoid wedging the hardware
+*/
+   if (!ictx-dev_present_intf1)
+   goto out;
+
switch (urb-status) {
case -ENOENT:   /* usbcore unlink successful! */
return;
@@ -1710,6 +1727,7 @@ static void usb_rx_callback_intf1(struct urb *urb)
break;
}
 
+out:
usb_submit_urb(ictx-rx_urb_intf1, GFP_ATOMIC);
 }
 
@@ -2242,7 +2260,7 @@ find_endpoint_failed:
mutex_unlock(ictx-lock);
usb_free_urb(rx_urb);
 rx_urb_alloc_failed:
-   dev_err(ictx-dev, unable to initialize intf0, err %d\n, ret);
+   dev_err(ictx-dev, unable to initialize intf1, err %d\n, ret);
 
return NULL;
 }
-- 
1.7.1

--
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] imon: don't wedge hardware after early callbacks

[Jarod Wilson]

This patch is just a minor update to one titled imon: Input from ffdc
device type ignored from Corinna Vinschen. An earlier patch to prevent
an oops when we got early callbacks also has the nasty side-effect of
wedging imon hardware, as we don't acknowledge the urb. Rework the check
slightly here to bypass processing the packet, as the driver isn't yet
fully initialized, but still acknowlege the urb and submit a new rx_urb.
Do this for both interfaces -- irrelevant for ffdc hardware, but
relevant for newer hardware, though newer hardware doesn't spew the
constant stream of data as soon as the hardware is initialized like the
older ffdc devices, so they'd be less likely to trigger this anyway...

Tested with both an ffdc device and an 0042 device.

v2: Per Corinna's suggestion and prior precedent, increment driver
version number so we can more easily tell if a user has this fix.

v3: cc stable, as this fixes a functional regression in 3.2

CC: sta...@vger.kernel.org
CC: Corinna Vinschen vinsc...@redhat.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/imon.c |   26 ++
 1 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 6ed9646..3f175eb 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -47,7 +47,7 @@
 #define MOD_AUTHOR Jarod Wilson ja...@wilsonet.com
 #define MOD_DESC   Driver for SoundGraph iMON MultiMedia IR/Display
 #define MOD_NAME   imon
-#define MOD_VERSION0.9.3
+#define MOD_VERSION0.9.4
 
 #define DISPLAY_MINOR_BASE 144
 #define DEVICE_NAMElcd%d
@@ -1658,9 +1658,17 @@ static void usb_rx_callback_intf0(struct urb *urb)
return;
 
ictx = (struct imon_context *)urb-context;
-   if (!ictx || !ictx-dev_present_intf0)
+   if (!ictx)
return;
 
+   /*
+* if we get a callback before we're done configuring the hardware, we
+* can't yet process the data, as there's nowhere to send it, but we
+* still need to submit a new rx URB to avoid wedging the hardware
+*/
+   if (!ictx-dev_present_intf0)
+   goto out;
+
switch (urb-status) {
case -ENOENT:   /* usbcore unlink successful! */
return;
@@ -1678,6 +1686,7 @@ static void usb_rx_callback_intf0(struct urb *urb)
break;
}
 
+out:
usb_submit_urb(ictx-rx_urb_intf0, GFP_ATOMIC);
 }
 
@@ -1690,9 +1699,17 @@ static void usb_rx_callback_intf1(struct urb *urb)
return;
 
ictx = (struct imon_context *)urb-context;
-   if (!ictx || !ictx-dev_present_intf1)
+   if (!ictx)
return;
 
+   /*
+* if we get a callback before we're done configuring the hardware, we
+* can't yet process the data, as there's nowhere to send it, but we
+* still need to submit a new rx URB to avoid wedging the hardware
+*/
+   if (!ictx-dev_present_intf1)
+   goto out;
+
switch (urb-status) {
case -ENOENT:   /* usbcore unlink successful! */
return;
@@ -1710,6 +1727,7 @@ static void usb_rx_callback_intf1(struct urb *urb)
break;
}
 
+out:
usb_submit_urb(ictx-rx_urb_intf1, GFP_ATOMIC);
 }
 
@@ -2242,7 +2260,7 @@ find_endpoint_failed:
mutex_unlock(ictx-lock);
usb_free_urb(rx_urb);
 rx_urb_alloc_failed:
-   dev_err(ictx-dev, unable to initialize intf0, err %d\n, ret);
+   dev_err(ictx-dev, unable to initialize intf1, err %d\n, ret);
 
return NULL;
 }
-- 
1.7.1

--
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] imon: don't wedge hardware after early callbacks

[Jarod Wilson]

This patch is just a minor update to one titled imon: Input from ffdc
device type ignored from Corinna Vinschen. An earlier patch to prevent
an oops when we got early callbacks also has the nasty side-effect of
wedging imon hardware, as we don't acknowledge the urb. Rework the check
slightly here to bypass processing the packet, as the driver isn't yet
fully initialized, but still acknowlege the urb and submit a new rx_urb.
Do this for both interfaces -- irrelevant for ffdc hardware, but
relevant for newer hardware, though newer hardware doesn't spew the
constant stream of data as soon as the hardware is initialized like the
older ffdc devices, so they'd be less likely to trigger this anyway...

Tested with both an ffdc device and an 0042 device.

CC: Corinna Vinschen vinsc...@redhat.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/imon.c |   24 +---
 1 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 6ed9646..0292741 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1658,9 +1658,17 @@ static void usb_rx_callback_intf0(struct urb *urb)
return;
 
ictx = (struct imon_context *)urb-context;
-   if (!ictx || !ictx-dev_present_intf0)
+   if (!ictx)
return;
 
+   /*
+* if we get a callback before we're done configuring the hardware, we
+* can't yet process the data, as there's nowhere to send it, but we
+* still need to acknowledge the URB to avoid wedging the hardware
+*/
+   if (!ictx-dev_present_intf0)
+   goto out;
+
switch (urb-status) {
case -ENOENT:   /* usbcore unlink successful! */
return;
@@ -1678,6 +1686,7 @@ static void usb_rx_callback_intf0(struct urb *urb)
break;
}
 
+out:
usb_submit_urb(ictx-rx_urb_intf0, GFP_ATOMIC);
 }
 
@@ -1690,9 +1699,17 @@ static void usb_rx_callback_intf1(struct urb *urb)
return;
 
ictx = (struct imon_context *)urb-context;
-   if (!ictx || !ictx-dev_present_intf1)
+   if (!ictx)
return;
 
+   /*
+* if we get a callback before we're done configuring the hardware, we
+* can't yet process the data, as there's nowhere to send it, but we
+* still need to acknowledge the URB to avoid wedging the hardware
+*/
+   if (!ictx-dev_present_intf1)
+   goto out;
+
switch (urb-status) {
case -ENOENT:   /* usbcore unlink successful! */
return;
@@ -1710,6 +1727,7 @@ static void usb_rx_callback_intf1(struct urb *urb)
break;
}
 
+out:
usb_submit_urb(ictx-rx_urb_intf1, GFP_ATOMIC);
 }
 
@@ -2242,7 +2260,7 @@ find_endpoint_failed:
mutex_unlock(ictx-lock);
usb_free_urb(rx_urb);
 rx_urb_alloc_failed:
-   dev_err(ictx-dev, unable to initialize intf0, err %d\n, ret);
+   dev_err(ictx-dev, unable to initialize intf1, err %d\n, ret);
 
return NULL;
 }
-- 
1.7.7.5

--
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] imon: don't wedge hardware after early callbacks

[Jarod Wilson]

Corinna Vinschen wrote:

Hi Jarod,

On Jan 25 15:56, Jarod Wilson wrote:

This patch is just a minor update to one titled imon: Input from ffdc
device type ignored from Corinna Vinschen. An earlier patch to prevent
an oops when we got early callbacks also has the nasty side-effect of
wedging imon hardware, as we don't acknowledge the urb. Rework the check
slightly here to bypass processing the packet, as the driver isn't yet
fully initialized, but still acknowlege the urb and submit a new rx_urb.
Do this for both interfaces -- irrelevant for ffdc hardware, but
relevant for newer hardware, though newer hardware doesn't spew the
constant stream of data as soon as the hardware is initialized like the
older ffdc devices, so they'd be less likely to trigger this anyway...


just a question, wouldn't it make sense to bump the version number of the
module to 0.9.4?  Or do you do that for functional changes only?


I've not been terribly consistent with it, but it does seem the last 
time I bumped the version number *was* to have an easy way to tell if a 
particular fix was included or not. We can bump it here too, doesn't 
really matter 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: [mythtv-users] Anyone tested the DVB-T2 dual tuner TBS6280?

[Jarod Wilson]

On Aug 14, 2011, at 11:50 AM, Harald Gustafsson wrote:

 Thanks for sharing your experience.
 
 On Sat, Aug 13, 2011 at 11:08 AM, Lawrence Rust l...@softsystem.co.uk wrote:
 The stock v4l sources supplied are old (from around 2.6.35) and don't
 contain many current fixes.  This isn't a problem per-se unless you
 intend to use the card with another v4l card.  In this case your brand
 new, bug fixed drivers are replaced by TBS's version which may or, as in
 my case, may not work.
 I have 2 other older cards that I intend to use it with, but currently
 I'm using Ubuntu 10.04 LTS which have a 2.6.32 kernel, so this would
 not be a problem, but later when I upgrade to 12.04 LTS and a newer
 kernel this will be problematic. Since I can't trust that TBS will
 deliver newer drivers.
 
 I repeatedly mailed TBS support at supp...@tbsdtv.com to ask how I could
 only install the 6981 driver but never got an answer.  In desperation I
 setup a git tree of 2.6.35 and merged it with the TBS drivers in order
 to separate their changes.  Finally after many hours I have a set of
 patches that I can apply to 2.6.39 that produce a working driver.
 Is it possible to mix modules based on different versions of v4l? To
 me that looks like it will work as long as the core infrastructure is
 the same, but as soon as some common data structure that is used by
 the obj files is changed it will break and you might not notice
 directly. Just as you say with the IR changes, but also more subtle
 changes by adding/removing elements in structures.
 
 Be warned that if you run a 2.6.38 or later kernel then the IR RC won't
 work because of significant changes to the RC architecture that TBS
 don't like (see http://www.tbsdtv.com/forum/viewtopic.php?f=22t=929 and
 http://www.tbsdtv.com/forum/viewtopic.php?f=22t=110start=90#p2693 )
 
 In the links you refer to the driver author (at least he seems to be
 the author) states that he has not upgraded to the latest IR code due
 to compatibility issues between the CX23885 and IR.

Someone please inform TBS that it would nice if they'd actually report
issues upstream. Nobody from TBS every said boo about their issues,
which, I'm 99% certain, have *absolutely* nothing to do with supposedly
rewriting ir-core to rc-core. (It was a transition to a new name of the
same code). This probably fixed all their issues:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d7515b8866b60c9526d2d7af37ebcd16c3c5ed97

Similarly, just booting with pci=nomsi on an unpatched kernel should
achieve the same effect. Sigh.

-- 
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

Re: [PATCH 5/7] [media] ati_remote: add keymap for Medion X10 RF remote

[Jarod Wilson]

Anssi Hannula wrote:

On 08.08.2011 08:57, Dmitry Torokhov wrote:

On Sun, Aug 07, 2011 at 01:18:11AM +0300, Anssi Hannula wrote:

Add keymap for the Medion X10 RF remote which uses the ati_remote
driver, and default to it based on the usb id.

Since rc-core supports loading custom keytmaps should we ass medion
keymap here?

I think we should keep the original keymap to avoid regressions, but new
keymaps should be offloaded to udev.


Well, I simply followed the convention, as all other remotes under
media/ have the default table in-kernel.

I'm not against putting it off-kernel, but in that case the same should
be done for all new media devices. Is that the plan?


That's the long-term plan, but not every distro has a sufficiently new 
enough v4l-utils and ir-keytable with udev rules to load keymaps, so 
we've been adding default remotes in-kernel and userspace (effectively 
meaning duplicated keymap loads if the user does have ir-keytable with 
udev rules, but meh). I'd say add it for now, and when we get to the 
point of v4l-utils ubiquity, we can drop this along with all the other 
in-kernel rc keymaps.


--
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

[PATCH] [media] nuvoton-cir: simplify raw IR sample handling

[Jarod Wilson]

The nuvoton-cir driver was storing up consecutive pulse-pulse and
space-space samples internally, for no good reason, since
ir_raw_event_store_with_filter() already merges back to back like
samples types for us. This should also fix a regression introduced late
in 3.0 that related to a timeout change, which actually becomes correct
when coupled with this change. Tested with RC6 and RC5 on my own
nuvoton-cir hardware atop vanilla 3.0.0, after verifying quirky
behavior in 3.0 due to the timeout change.

Reported-by: Stephan Raue sr...@openelec.tv
CC: Stephan Raue sr...@openelec.tv
CC: sta...@vger.kernel.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/nuvoton-cir.c |   45 +++
 drivers/media/rc/nuvoton-cir.h |1 -
 2 files changed, 8 insertions(+), 38 deletions(-)

diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index ce595f9..9fd019e 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -624,7 +624,6 @@ static void nvt_dump_rx_buf(struct nvt_dev *nvt)
 static void nvt_process_rx_ir_data(struct nvt_dev *nvt)
 {
DEFINE_IR_RAW_EVENT(rawir);
-   unsigned int count;
u32 carrier;
u8 sample;
int i;
@@ -637,65 +636,38 @@ static void nvt_process_rx_ir_data(struct nvt_dev *nvt)
if (nvt-carrier_detect_enabled)
carrier = nvt_rx_carrier_detect(nvt);
 
-   count = nvt-pkts;
-   nvt_dbg_verbose(Processing buffer of len %d, count);
+   nvt_dbg_verbose(Processing buffer of len %d, nvt-pkts);
 
init_ir_raw_event(rawir);
 
-   for (i = 0; i  count; i++) {
-   nvt-pkts--;
+   for (i = 0; i  nvt-pkts; i++) {
sample = nvt-buf[i];
 
rawir.pulse = ((sample  BUF_PULSE_BIT) != 0);
rawir.duration = US_TO_NS((sample  BUF_LEN_MASK)
  * SAMPLE_PERIOD);
 
-   if ((sample  BUF_LEN_MASK) == BUF_LEN_MASK) {
-   if (nvt-rawir.pulse == rawir.pulse)
-   nvt-rawir.duration += rawir.duration;
-   else {
-   nvt-rawir.duration = rawir.duration;
-   nvt-rawir.pulse = rawir.pulse;
-   }
-   continue;
-   }
-
-   rawir.duration += nvt-rawir.duration;
+   nvt_dbg(Storing %s with duration %d,
+   rawir.pulse ? pulse : space, rawir.duration);
 
-   init_ir_raw_event(nvt-rawir);
-   nvt-rawir.duration = 0;
-   nvt-rawir.pulse = rawir.pulse;
-
-   if (sample == BUF_PULSE_BIT)
-   rawir.pulse = false;
-
-   if (rawir.duration) {
-   nvt_dbg(Storing %s with duration %d,
-   rawir.pulse ? pulse : space,
-   rawir.duration);
-
-   ir_raw_event_store_with_filter(nvt-rdev, rawir);
-   }
+   ir_raw_event_store_with_filter(nvt-rdev, rawir);
 
/*
 * BUF_PULSE_BIT indicates end of IR data, BUF_REPEAT_BYTE
 * indicates end of IR signal, but new data incoming. In both
 * cases, it means we're ready to call ir_raw_event_handle
 */
-   if ((sample == BUF_PULSE_BIT)  nvt-pkts) {
+   if ((sample == BUF_PULSE_BIT)  (i + 1  nvt-pkts)) {
nvt_dbg(Calling ir_raw_event_handle (signal end)\n);
ir_raw_event_handle(nvt-rdev);
}
}
 
+   nvt-pkts = 0;
+
nvt_dbg(Calling ir_raw_event_handle (buffer empty)\n);
ir_raw_event_handle(nvt-rdev);
 
-   if (nvt-pkts) {
-   nvt_dbg(Odd, pkts should be 0 now... (its %u), nvt-pkts);
-   nvt-pkts = 0;
-   }
-
nvt_dbg_verbose(%s done, __func__);
 }
 
@@ -1054,7 +1026,6 @@ static int nvt_probe(struct pnp_dev *pdev, const struct 
pnp_device_id *dev_id)
 
spin_lock_init(nvt-nvt_lock);
spin_lock_init(nvt-tx.lock);
-   init_ir_raw_event(nvt-rawir);
 
ret = -EBUSY;
/* now claim resources */
diff --git a/drivers/media/rc/nuvoton-cir.h b/drivers/media/rc/nuvoton-cir.h
index 1241fc8..0d5e087 100644
--- a/drivers/media/rc/nuvoton-cir.h
+++ b/drivers/media/rc/nuvoton-cir.h
@@ -67,7 +67,6 @@ static int debug;
 struct nvt_dev {
struct pnp_dev *pdev;
struct rc_dev *rdev;
-   struct ir_raw_event rawir;
 
spinlock_t nvt_lock;
 
-- 
1.7.1

--
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] [media] nuvoton-cir: simplify raw IR sample handling

[Jarod Wilson]

Jarod Wilson wrote:

The nuvoton-cir driver was storing up consecutive pulse-pulse and
space-space samples internally, for no good reason, since
ir_raw_event_store_with_filter() already merges back to back like
samples types for us. This should also fix a regression introduced late
in 3.0 that related to a timeout change, which actually becomes correct
when coupled with this change. Tested with RC6 and RC5 on my own
nuvoton-cir hardware atop vanilla 3.0.0, after verifying quirky
behavior in 3.0 due to the timeout change.

Reported-by: Stephan Rauesr...@openelec.tv
CC: Stephan Rauesr...@openelec.tv
CC: sta...@vger.kernel.org


Bah. I pooched the above CC, should have been sta...@kernel.org.


Signed-off-by: Jarod Wilsonja...@redhat.com
---
  drivers/media/rc/nuvoton-cir.c |   45 +++
  drivers/media/rc/nuvoton-cir.h |1 -
  2 files changed, 8 insertions(+), 38 deletions(-)

diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index ce595f9..9fd019e 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -624,7 +624,6 @@ static void nvt_dump_rx_buf(struct nvt_dev *nvt)
  static void nvt_process_rx_ir_data(struct nvt_dev *nvt)
  {
DEFINE_IR_RAW_EVENT(rawir);
-   unsigned int count;
u32 carrier;
u8 sample;
int i;
@@ -637,65 +636,38 @@ static void nvt_process_rx_ir_data(struct nvt_dev *nvt)
if (nvt-carrier_detect_enabled)
carrier = nvt_rx_carrier_detect(nvt);

-   count = nvt-pkts;
-   nvt_dbg_verbose(Processing buffer of len %d, count);
+   nvt_dbg_verbose(Processing buffer of len %d, nvt-pkts);

init_ir_raw_event(rawir);

-   for (i = 0; i  count; i++) {
-   nvt-pkts--;
+   for (i = 0; i  nvt-pkts; i++) {
sample = nvt-buf[i];

rawir.pulse = ((sample  BUF_PULSE_BIT) != 0);
rawir.duration = US_TO_NS((sample  BUF_LEN_MASK)
  * SAMPLE_PERIOD);

-   if ((sample  BUF_LEN_MASK) == BUF_LEN_MASK) {
-   if (nvt-rawir.pulse == rawir.pulse)
-   nvt-rawir.duration += rawir.duration;
-   else {
-   nvt-rawir.duration = rawir.duration;
-   nvt-rawir.pulse = rawir.pulse;
-   }
-   continue;
-   }
-
-   rawir.duration += nvt-rawir.duration;
+   nvt_dbg(Storing %s with duration %d,
+   rawir.pulse ? pulse : space, rawir.duration);

-   init_ir_raw_event(nvt-rawir);
-   nvt-rawir.duration = 0;
-   nvt-rawir.pulse = rawir.pulse;
-
-   if (sample == BUF_PULSE_BIT)
-   rawir.pulse = false;
-
-   if (rawir.duration) {
-   nvt_dbg(Storing %s with duration %d,
-   rawir.pulse ? pulse : space,
-   rawir.duration);
-
-   ir_raw_event_store_with_filter(nvt-rdev,rawir);
-   }
+   ir_raw_event_store_with_filter(nvt-rdev,rawir);

/*
 * BUF_PULSE_BIT indicates end of IR data, BUF_REPEAT_BYTE
 * indicates end of IR signal, but new data incoming. In both
 * cases, it means we're ready to call ir_raw_event_handle
 */
-   if ((sample == BUF_PULSE_BIT)  nvt-pkts) {
+   if ((sample == BUF_PULSE_BIT)  (i + 1  nvt-pkts)) {
nvt_dbg(Calling ir_raw_event_handle (signal end)\n);
ir_raw_event_handle(nvt-rdev);
}
}

+   nvt-pkts = 0;
+
nvt_dbg(Calling ir_raw_event_handle (buffer empty)\n);
ir_raw_event_handle(nvt-rdev);

-   if (nvt-pkts) {
-   nvt_dbg(Odd, pkts should be 0 now... (its %u), nvt-pkts);
-   nvt-pkts = 0;
-   }
-
nvt_dbg_verbose(%s done, __func__);
  }

@@ -1054,7 +1026,6 @@ static int nvt_probe(struct pnp_dev *pdev, const struct 
pnp_device_id *dev_id)

spin_lock_init(nvt-nvt_lock);
spin_lock_init(nvt-tx.lock);
-   init_ir_raw_event(nvt-rawir);

ret = -EBUSY;
/* now claim resources */
diff --git a/drivers/media/rc/nuvoton-cir.h b/drivers/media/rc/nuvoton-cir.h
index 1241fc8..0d5e087 100644
--- a/drivers/media/rc/nuvoton-cir.h
+++ b/drivers/media/rc/nuvoton-cir.h
@@ -67,7 +67,6 @@ static int debug;
  struct nvt_dev {
struct pnp_dev *pdev;
struct rc_dev *rdev;
-   struct ir_raw_event rawir;

spinlock_t nvt_lock;




--
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 1/2] [media] rc-main: Fix device de-registration logic

[Jarod Wilson]

On Jul 29, 2011, at 1:53 AM, Mauro Carvalho Chehab wrote:

 rc unregister logic were deadly broken, preventing some drivers to
 be removed. Among the broken things, rc_dev_uevent() is being called
 during device_del(), causing a data filling on an area that it is
 not ready anymore.
 
 Also, some drivers have a stop callback defined, that needs to be called
 before data removal, as it stops data polling.
 
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 
 diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
 index 51a23f4..666d4bb 100644
 --- a/drivers/media/rc/rc-main.c
 +++ b/drivers/media/rc/rc-main.c
 @@ -928,10 +928,6 @@ out:
 
 static void rc_dev_release(struct device *device)
 {
 - struct rc_dev *dev = to_rc_dev(device);
 -
 - kfree(dev);
 - module_put(THIS_MODULE);
 }

Since this function become a no-op, does it make sense to just remove it
and not set a .release function for static struct device_type rc_dev_type?

Other than that, after reading through the patch several times, along with
the resulting rc-main.c and some input code, everything seems to make
sense to me. Will do some quick sanity-testing with a few of my various
devices before I give an ack though, just to be sure. :)

-- 
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

Re: [PATCH 1/2] [media] rc-main: Fix device de-registration logic

[Jarod Wilson]

On Jul 29, 2011, at 1:30 PM, Jarod Wilson wrote:

 On Jul 29, 2011, at 1:53 AM, Mauro Carvalho Chehab wrote:
 
 rc unregister logic were deadly broken, preventing some drivers to
 be removed. Among the broken things, rc_dev_uevent() is being called
 during device_del(), causing a data filling on an area that it is
 not ready anymore.
 
 Also, some drivers have a stop callback defined, that needs to be called
 before data removal, as it stops data polling.
 
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 
 diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
 index 51a23f4..666d4bb 100644
 --- a/drivers/media/rc/rc-main.c
 +++ b/drivers/media/rc/rc-main.c
 @@ -928,10 +928,6 @@ out:
 
 static void rc_dev_release(struct device *device)
 {
 -struct rc_dev *dev = to_rc_dev(device);
 -
 -kfree(dev);
 -module_put(THIS_MODULE);
 }
 
 Since this function become a no-op, does it make sense to just remove it
 and not set a .release function for static struct device_type rc_dev_type?

Nope, that leads to this:

[  765.095926] [ cut here ]
[  765.098076] WARNING: at /home/jarod/src/linux-ir/drivers/base/core.c:143 
device_release+0x73/0x7f()
[  765.100215] Hardware name: empty
[  765.102343] Device 'rc0' does not have a release() function, it is broken 
and must be fixed.

Which may or not be bogus. But I've got a hanging modprobe -r em28xx-dvb
with this change in place. Now to test with it rolled back...


-- 
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

Re: [PATCH 1/2] [media] rc-main: Fix device de-registration logic

[Jarod Wilson]

On Jul 29, 2011, at 5:25 PM, Mauro Carvalho Chehab wrote:

 Em 29-07-2011 14:30, Jarod Wilson escreveu:
 On Jul 29, 2011, at 1:53 AM, Mauro Carvalho Chehab wrote:
 
 rc unregister logic were deadly broken, preventing some drivers to
 be removed. Among the broken things, rc_dev_uevent() is being called
 during device_del(), causing a data filling on an area that it is
 not ready anymore.
 
 Also, some drivers have a stop callback defined, that needs to be called
 before data removal, as it stops data polling.
 
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 
 diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
 index 51a23f4..666d4bb 100644
 --- a/drivers/media/rc/rc-main.c
 +++ b/drivers/media/rc/rc-main.c
 @@ -928,10 +928,6 @@ out:
 
 static void rc_dev_release(struct device *device)
 {
 -   struct rc_dev *dev = to_rc_dev(device);
 -
 -   kfree(dev);
 -   module_put(THIS_MODULE);
 }
 
 Since this function become a no-op, does it make sense to just remove it
 and not set a .release function for static struct device_type rc_dev_type?
 
 As you tested, this function needs to exist... well, other drivers sometimes
 do the same, by defining it as a no-op function.
 
 Other than that, after reading through the patch several times, along with
 the resulting rc-main.c and some input code, everything seems to make
 sense to me. Will do some quick sanity-testing with a few of my various
 devices before I give an ack though, just to be sure. :)
 
 Thanks! Yeah, a test with other devices is welcome, as we don't want fix for 
 one
 and break for the others ;)

Done. Checked out mceusb, redrat3 and imon, all show no ill effects.


 The logic there looks simple, but it is, in fact, tricky, especially since
 drivers may have polling tasks running, and they need to be cancelled before 
 freeing the resources.

Indeed. Took a bit to wrap my head around it all, but I think I got it.


Acked-by: Jarod Wilson ja...@redhat.com

-- 
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

Re: [PATCH] [media] imon: don't parse scancodes until intf configured

[Jarod Wilson]

Chris W wrote:

On 20/07/11 23:18, Jarod Wilson wrote:

On Wed, Jul 20, 2011 at 08:05:43AM +1000, Chris W wrote:

On 20/07/11 02:12, Jarod Wilson wrote:

The imon devices have either 1 or 2 usb interfaces on them, each wired
up to its own urb callback. The interface 0 urb callback is wired up
before the imon context's rc_dev pointer is filled in, which is
necessary for imon 0xffdc device auto-detection to work properly, but
we need to make sure we don't actually run the callback routines until
we've entirely filled in the necessary bits for each given interface,
lest we wind up oopsing. Technically, any imon device could have hit
this, but the issue is exacerbated on the 0xffdc devices, which send a
constant stream of interrupts, even when they have no valid key data.



OK.  The patch applies and everything continues to work.   There is no
obvious difference in the dmesg output on module load, with my device
remaining unidentified.  I don't know if that is indicative of anything.

Did you apply this patch on top of the earlier patch, or instead of it?


On top of it.   I've reversed the patches and installed just the last
one with this result on loading the module:

input: iMON Panel, Knob and Mouse(15c2:ffdc) as
/devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/input/input8
imon 4-2:1.0: 0xffdc iMON VFD, iMON IR (id 0x24)
Registered IR keymap rc-imon-pad
input: iMON Remote (15c2:ffdc) as
/devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc3/input9
rc3: iMON Remote (15c2:ffdc) as
/devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc3
imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb4:3  initialized
usbcore: registered new interface driver imon

Much better.


Yeah, that looks sane now. We missed 3.0, but I'll try to flag this one 
to go into the various stable trees when it gets merged for 3.1.




intf0 decoded packet: 00 00 00 00 00 00 24 01
intf0 decoded packet: 00 00 00 00 00 00 24 01
intf0 decoded packet: 00 00 00 00 00 00 24 01

One other amusing tidbit: you get continuous spew like the above, because
to date, I thought all the ffdc devices had nothing to report spew that
started with 0xff, which we filter out. Sigh. I hate imon hardware...


I am beginning to understand why. That output was only printed with the
debug=1 option and is not printed with the patched module.


Yup. The additional filtering was added because my own ffdc imon devices 
were so noisy, it was next to impossible to see what was going on when 
trying to debug anything.



--
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] [media] imon: don't submit urb before rc_dev set up

[Jarod Wilson]

Jarod Wilson wrote:

The interface 0 urb callback was being wired up before the rc_dev device
was allocated, meaning the callback could be called with a null rc_dev,
leading to an oops. This likely only ever happens on the older 0xffdc
SoundGraph devices, which continually trigger interrupts even when they
have no valid keydata, and the window in which it could happen is small,
but its actually happening regularly for at least one user, and its an
obvious fix. Compile and sanity-tested with one of my own imon devices.


Explicit self-nak on this one, just to crystal-clear, since this is 
handled without breaking ffdc device detection by a later patch.


--
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] [media] imon: don't parse scancodes until intf configured

[Jarod Wilson]

On Wed, Jul 20, 2011 at 08:05:43AM +1000, Chris W wrote:
 On 20/07/11 02:12, Jarod Wilson wrote:
  The imon devices have either 1 or 2 usb interfaces on them, each wired
  up to its own urb callback. The interface 0 urb callback is wired up
  before the imon context's rc_dev pointer is filled in, which is
  necessary for imon 0xffdc device auto-detection to work properly, but
  we need to make sure we don't actually run the callback routines until
  we've entirely filled in the necessary bits for each given interface,
  lest we wind up oopsing. Technically, any imon device could have hit
  this, but the issue is exacerbated on the 0xffdc devices, which send a
  constant stream of interrupts, even when they have no valid key data.
 
 
 
 OK.  The patch applies and everything continues to work.   There is no
 obvious difference in the dmesg output on module load, with my device
 remaining unidentified.  I don't know if that is indicative of anything.

Did you apply this patch on top of the earlier patch, or instead of it?

 input: iMON Panel, Knob and Mouse(15c2:ffdc) as
 /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/input/input9
 imon 4-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x00)

The 'id 0x00' part should read 'id 0x24', as the ongoing spew below has in
index 6, which makes me think you still have the earlier patch applied.
You actually want only the newer patch applied. If you only have the newer
one applied, then I'll have to take another look to see what's up.

 intf0 decoded packet: 00 00 00 00 00 00 24 01
 intf0 decoded packet: 00 00 00 00 00 00 24 01
 intf0 decoded packet: 00 00 00 00 00 00 24 01

One other amusing tidbit: you get continuous spew like the above, because
to date, I thought all the ffdc devices had nothing to report spew that
started with 0xff, which we filter out. Sigh. I hate imon hardware...

-- 
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] [media] imon: don't submit urb before rc_dev set up

[Jarod Wilson]

On Jul 18, 2011, at 6:29 PM, Chris W l...@psychogeeks.com wrote:

 On 19/07/11 02:46, Jarod Wilson wrote:
 The interface 0 urb callback was being wired up before the rc_dev device
 was allocated, meaning the callback could be called with a null rc_dev,
 leading to an oops. This likely only ever happens on the older 0xffdc
 SoundGraph devices, which continually trigger interrupts even when they
 have no valid keydata, and the window in which it could happen is small,
 but its actually happening regularly for at least one user, and its an
 obvious fix. Compile and sanity-tested with one of my own imon devices.
 
 As the at least one user I can confirm that the patch has indeed
 corrected the problem on my 2.6.38-gentoo-r6, 2.6.39.3 vanilla, and
 3.0.0-rc7 kernels.
 
 This is what loading the module with the debug=1 option outputs:
 
 input: iMON Panel, Knob and Mouse(15c2:ffdc) as
 /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/input/input7
 imon 4-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x00)

Ugh, damn, that change broke the ffdc device auto-detection... Better than a 
crash, but lemme see if I can alter things slightly so we can have our cake and 
eat it too...


 Registered IR keymap rc-imon-pad
 input: iMON Remote (15c2:ffdc) as
 /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc2/input8
 rc2: iMON Remote (15c2:ffdc) as
 /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc2
 imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb4:3 initialized
 usbcore: registered new interface driver imon
 intf0 decoded packet: 00 00 00 00 00 00 24 01
 intf0 decoded packet: 00 00 00 00 00 00 24 01
 intf0 decoded packet: 00 00 00 00 00 00 24 01
 intf0 decoded packet: 00 00 00 00 00 00 24 01
 ...
 
 The decoded packet lines are fast and furious with no deliberate IR
 input (the VFD is in use), which might explain how this device managed
 to break the code in the small window available.

Yep. I hate hate hate hate the ffdc imon hardware, for this and multiple other 
reasons (including the nasty hack used for ffdc device type auto-detection)... 
My ffdc devices do similar constant spewing, but never triggered the oops, so 
maybe yours is even worse, or your system is faster, or a kernel config change 
made a difference here...


 Thank you Jarod and Andy for taking the time to track this problem down
 to give it a drubbing.

Thanks for the testing and patience, hopefully just one more patch to test out 
before we can say case closed here...

--jarod
--
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] [media] imon: don't parse scancodes until intf configured

[Jarod Wilson]

The imon devices have either 1 or 2 usb interfaces on them, each wired
up to its own urb callback. The interface 0 urb callback is wired up
before the imon context's rc_dev pointer is filled in, which is
necessary for imon 0xffdc device auto-detection to work properly, but we
need to make sure we don't actually run the callback routines until
we've entirely filled in the necessary bits for each given interface,
lest we wind up oopsing. Technically, any imon device could have hit
this, but the issue is exacerbated on the 0xffdc devices, which send a
constant stream of interrupts, even when they have no valid key data.

CC: Andy Walls awa...@md.metrocast.net
CC: Chris W l...@psychogeeks.com
Reported-by: Chris W l...@psychogeeks.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/imon.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index caa3e3a..6ed9646 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1658,7 +1658,7 @@ static void usb_rx_callback_intf0(struct urb *urb)
return;
 
ictx = (struct imon_context *)urb-context;
-   if (!ictx)
+   if (!ictx || !ictx-dev_present_intf0)
return;
 
switch (urb-status) {
@@ -1690,7 +1690,7 @@ static void usb_rx_callback_intf1(struct urb *urb)
return;
 
ictx = (struct imon_context *)urb-context;
-   if (!ictx)
+   if (!ictx || !ictx-dev_present_intf1)
return;
 
switch (urb-status) {
@@ -2118,7 +2118,6 @@ static struct imon_context *imon_init_intf0(struct 
usb_interface *intf)
 
ictx-dev = dev;
ictx-usbdev_intf0 = usb_get_dev(interface_to_usbdev(intf));
-   ictx-dev_present_intf0 = true;
ictx-rx_urb_intf0 = rx_urb;
ictx-tx_urb = tx_urb;
ictx-rf_device = false;
@@ -2157,6 +2156,8 @@ static struct imon_context *imon_init_intf0(struct 
usb_interface *intf)
goto rdev_setup_failed;
}
 
+   ictx-dev_present_intf0 = true;
+
mutex_unlock(ictx-lock);
return ictx;
 
@@ -2200,7 +2201,6 @@ static struct imon_context *imon_init_intf1(struct 
usb_interface *intf,
}
 
ictx-usbdev_intf1 = usb_get_dev(interface_to_usbdev(intf));
-   ictx-dev_present_intf1 = true;
ictx-rx_urb_intf1 = rx_urb;
 
ret = -ENODEV;
@@ -2229,6 +2229,8 @@ static struct imon_context *imon_init_intf1(struct 
usb_interface *intf,
goto urb_submit_failed;
}
 
+   ictx-dev_present_intf1 = true;
+
mutex_unlock(ictx-lock);
return ictx;
 
-- 
1.7.1

--
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: Happuage HDPVR 0 byte files.

[Jarod Wilson]

Keep it on the mailing list, please.

On Jul 18, 2011, at 10:58 AM, Greg Williamson wrote:

 I'm using rca on the back. Audio input is set to 0. trying to change
 it results in 'VIDIOC_S_AUDIO: failed: Resource temporarily
 unavailable'

Hm. Afriad I have no clue what's going on then, just know that not
having audio connected to the expected input can cause 0-byte files.
The failure message there is mildly alarming, but I don't know what
might be the cause. Certainly seems like it could be related to you
getting 0-byte files though (i.e., same root cause). :)


 On Mon, Jul 18, 2011 at 10:49 AM, Jarod Wilson ja...@wilsonet.com wrote:
 On Jul 18, 2011, at 6:49 AM, Greg Williamson wrote:
 
 Hi,  I'm on Archlinux running 2.6.39-ARCH.  When I plug in my hdpvr I
 see it registers.
 
 Here is the dmesg output:
 [  778.518866] hdpvr 1-3:1.0: firmware version 0x15 dated Jun 17 2010 
 09:26:53
 [  778.704965] hdpvr 1-3:1.0: device now attached to video0
 [  778.705006] usbcore: registered new interface driver hdpvr
 
 
 However 'cat /dev/video0  test.ts' creates 0 byte files every time.
 
 What audio input do you have wired up, and has the driver been told to
 use the right one? You'll get 0-byte files if there's no audio on the
 selected audio input (default is rear RCA). Can alter the default with
 a modparam (default_audio_input=2 for spdif), or change it on the fly
 using v4l-utils.


-- 
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

[PATCH] [media] imon: don't submit urb before rc_dev set up

[Jarod Wilson]

The interface 0 urb callback was being wired up before the rc_dev device
was allocated, meaning the callback could be called with a null rc_dev,
leading to an oops. This likely only ever happens on the older 0xffdc
SoundGraph devices, which continually trigger interrupts even when they
have no valid keydata, and the window in which it could happen is small,
but its actually happening regularly for at least one user, and its an
obvious fix. Compile and sanity-tested with one of my own imon devices.

CC: Andy Walls awa...@md.metrocast.net
CC: Chris W l...@psychogeeks.com
CC: Randy Dunlap rdun...@xenotime.net
CC: linux-ker...@vger.kernel.org
Reported-by: Chris W l...@psychogeeks.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/imon.c |   28 ++--
 1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index caa3e3a..26238f5 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2132,6 +2132,18 @@ static struct imon_context *imon_init_intf0(struct 
usb_interface *intf)
goto find_endpoint_failed;
}
 
+   ictx-idev = imon_init_idev(ictx);
+   if (!ictx-idev) {
+   dev_err(dev, %s: input device setup failed\n, __func__);
+   goto idev_setup_failed;
+   }
+
+   ictx-rdev = imon_init_rdev(ictx);
+   if (!ictx-rdev) {
+   dev_err(dev, %s: rc device setup failed\n, __func__);
+   goto rdev_setup_failed;
+   }
+
usb_fill_int_urb(ictx-rx_urb_intf0, ictx-usbdev_intf0,
usb_rcvintpipe(ictx-usbdev_intf0,
ictx-rx_endpoint_intf0-bEndpointAddress),
@@ -2145,26 +2157,14 @@ static struct imon_context *imon_init_intf0(struct 
usb_interface *intf)
goto urb_submit_failed;
}
 
-   ictx-idev = imon_init_idev(ictx);
-   if (!ictx-idev) {
-   dev_err(dev, %s: input device setup failed\n, __func__);
-   goto idev_setup_failed;
-   }
-
-   ictx-rdev = imon_init_rdev(ictx);
-   if (!ictx-rdev) {
-   dev_err(dev, %s: rc device setup failed\n, __func__);
-   goto rdev_setup_failed;
-   }
-
mutex_unlock(ictx-lock);
return ictx;
 
+urb_submit_failed:
+   rc_unregister_device(ictx-rdev);
 rdev_setup_failed:
input_unregister_device(ictx-idev);
 idev_setup_failed:
-   usb_kill_urb(ictx-rx_urb_intf0);
-urb_submit_failed:
 find_endpoint_failed:
mutex_unlock(ictx-lock);
usb_free_urb(tx_urb);
-- 
1.7.1

--
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] [media] mceusb: give hardware time to reply to cmds

[Jarod Wilson]

Jarod Wilson wrote:

Mauro Carvalho Chehab wrote:

Em 14-07-2011 19:09, Jarod Wilson escreveu:

Sometimes the init routine is blasting commands out to the hardware
faster than it can reply. Throw a brief delay in there to give the
hardware a chance to reply before we send the next command.

Signed-off-by: Jarod Wilsonja...@redhat.com
---
drivers/media/rc/mceusb.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 111bead..13a853b 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -37,6 +37,7 @@
#includelinux/slab.h
#includelinux/usb.h
#includelinux/usb/input.h
+#includelinux/delay.h
#includemedia/rc-core.h

#define DRIVER_VERSION 1.91
@@ -735,6 +736,7 @@ static void mce_request_packet(struct mceusb_dev
*ir, unsigned char *data,
static void mce_async_out(struct mceusb_dev *ir, unsigned char *data,
int size)
{
mce_request_packet(ir, data, size, MCEUSB_TX);
+ mdelay(10);


Can't it be a msleep() instead? Delays spend more power, and keeps the
CPU busy while
running.


I think I was thinking we'd end up sleeping in an interrupt handler when
we shouldn't be, but upon closer code inspection and actual testing,
that's not the case, so yeah, those can be msleeps. While testing all
code paths, I also discovered that patch 6 in the series breaks lirc tx
support (the lirc dev is registered before the tx function pointers are
filled in), so I'll resend at least patches 2 and 6...


I'll just resend an entire v2 series, the changes to patch 2 have 
cascading impact on multiple patches in the rest of the series.


--
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

[PATCH v2 0/9] mceusb updates per MS docs

[Jarod Wilson]

This is a stack of updates made based on the Windows Media Center remote
and receiver/transmitter specification and requirements document that
Rafi Rubin recently pointed me at. Its titled
Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf
which as of this writing, is publicly available from
download.microsoft.com.

Tested with 7 different mceusb devices, with no ill effects. Unfortunately,
for the most part, these chagnes don't actually improve any shortcomings in
the driver, but they do give us a better view of the hardware features and
whatnot, and a few things are better explained now, with most of the command
and response bits lining up with what MS has documented.

v2: use msleep instead of mdelay, and fix a tx regression in v1

Jarod Wilson (9):
  [media] mceusb: command/response updates from MS docs
  [media] mceusb: give hardware time to reply to cmds
  [media] mceusb: set wakeup bits for IR-based resume
  [media] mceusb: issue device resume cmd when needed
  [media] mceusb: query device for firmware emulator version
  [media] mceusb: get misc port data from hardware
  [media] mceusb: flash LED (emu v2+ only) to signal end of init
  [media] mceusb: report actual tx frequencies
  [media] mceusb: update version, copyright, author

 drivers/media/rc/mceusb.c |  410 +++--
 1 files changed, 280 insertions(+), 130 deletions(-)

--
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 1/9] [media] mceusb: command/response updates from MS docs

[Jarod Wilson]

I was recently pointed to the document titled
Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf
which as of this writing, is publicly available from
download.microsoft.com. It covers a LOT of the gaps in the mceusb
driver, which to this point, was written almost entirely by
reverse-engineering. First up, I'm updating the defines for all the MCE
commands and responses to match their names in the spec. More to come...

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |  293 ++--
 1 files changed, 173 insertions(+), 120 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index ec972dc..111bead 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -63,43 +63,90 @@
 #define MCE_PULSE_MASK 0x7f /* Pulse mask */
 #define MCE_MAX_PULSE_LENGTH   0x7f /* Longest transmittable pulse symbol */
 
-#define MCE_HW_CMD_HEADER  0xff/* MCE hardware command header */
-#define MCE_COMMAND_HEADER 0x9f/* MCE command header */
-#define MCE_COMMAND_MASK   0xe0/* Mask out command bits */
-#define MCE_COMMAND_NULL   0x00/* These show up various places... */
-/* if buf[i]  MCE_COMMAND_MASK == 0x80 and buf[i] != MCE_COMMAND_HEADER,
- * then we're looking at a raw IR data sample */
-#define MCE_COMMAND_IRDATA 0x80
-#define MCE_PACKET_LENGTH_MASK 0x1f /* Packet length mask */
-
-/* Sub-commands, which follow MCE_COMMAND_HEADER or MCE_HW_CMD_HEADER */
+/*
+ * The interface between the host and the IR hardware is command-response
+ * based. All commands and responses have a consistent format, where a lead
+ * byte always identifies the type of data following it. The lead byte has
+ * a port value in the 3 highest bits and a length value in the 5 lowest
+ * bits.
+ *
+ * The length field is overloaded, with a value of 1 indicating that the
+ * following byte is a command or response code, and the length of the entire
+ * message is determined by the code. If the length field is not 1, then
+ * it specifies the number of bytes of port data that follow.
+ */
+#define MCE_CMD0x1f
+#define MCE_PORT_IR0x4 /* (0x4  5) | MCE_CMD = 0x9f */
+#define MCE_PORT_SYS   0x7 /* (0x7  5) | MCE_CMD = 0xff */
+#define MCE_PORT_SER   0x6 /* 0xc0 thru 0xdf flush  0x1f bytes */
+#define MCE_PORT_MASK  0xe0/* Mask out command bits */
+
+/* Command port headers */
+#define MCE_CMD_PORT_IR0x9f/* IR-related cmd/rsp */
+#define MCE_CMD_PORT_SYS   0xff/* System (non-IR) device cmd/rsp */
+
+/* Commands that set device state  (2-4 bytes in length) */
+#define MCE_CMD_RESET  0xfe/* Reset device, 2 bytes */
+#define MCE_CMD_RESUME 0xaa/* Resume device after error, 2 bytes */
+#define MCE_CMD_SETIRCFS   0x06/* Set tx carrier, 4 bytes */
+#define MCE_CMD_SETIRTIMEOUT   0x0c/* Set timeout, 4 bytes */
+#define MCE_CMD_SETIRTXPORTS   0x08/* Set tx ports, 3 bytes */
+#define MCE_CMD_SETIRRXPORTEN  0x14/* Set rx ports, 3 bytes */
+#define MCE_CMD_FLASHLED   0x23/* Flash receiver LED, 2 bytes */
+
+/* Commands that query device state (all 2 bytes, unless noted) */
+#define MCE_CMD_GETIRCFS   0x07/* Get carrier */
+#define MCE_CMD_GETIRTIMEOUT   0x0d/* Get timeout */
+#define MCE_CMD_GETIRTXPORTS   0x13/* Get tx ports */
+#define MCE_CMD_GETIRRXPORTEN  0x15/* Get rx ports */
+#define MCE_CMD_GETPORTSTATUS  0x11/* Get tx port status, 3 bytes */
+#define MCE_CMD_GETIRNUMPORTS  0x16/* Get number of ports */
+#define MCE_CMD_GETWAKESOURCE  0x17/* Get wake source */
+#define MCE_CMD_GETEMVER   0x22/* Get emulator interface version */
+#define MCE_CMD_GETDEVDETAILS  0x21/* Get device details (em ver2 only) */
+#define MCE_CMD_GETWAKESUPPORT 0x20/* Get wake details (em ver2 only) */
+#define MCE_CMD_GETWAKEVERSION 0x18/* Get wake pattern (em ver2 only) */
+
+/* Misc commands */
+#define MCE_CMD_NOP0xff/* No operation */
+
+/* Responses to commands (non-error cases) */
+#define MCE_RSP_EQIRCFS0x06/* tx carrier, 4 bytes */
+#define MCE_RSP_EQIRTIMEOUT0x0c/* rx timeout, 4 bytes */
+#define MCE_RSP_GETWAKESOURCE  0x17/* wake source, 3 bytes */
+#define MCE_RSP_EQIRTXPORTS0x08/* tx port mask, 3 bytes */
+#define MCE_RSP_EQIRRXPORTEN   0x14/* rx port mask, 3 bytes */
+#define MCE_RSP_GETPORTSTATUS  0x11/* tx port status, 7 bytes */
+#define MCE_RSP_EQIRRXCFCNT0x15/* rx carrier count, 4 bytes */
+#define MCE_RSP_EQIRNUMPORTS   0x16/* number of ports, 4 bytes */
+#define MCE_RSP_EQWAKESUPPORT  0x20/* wake capabilities, 3 bytes */
+#define MCE_RSP_EQWAKEVERSION  0x18/* wake pattern details, 6 bytes */
+#define MCE_RSP_EQDEVDETAILS   0x21/* device capabilities, 3 bytes */
+#define MCE_RSP_EQEMVER

[PATCH v2 2/9] [media] mceusb: give hardware time to reply to cmds

[Jarod Wilson]

Sometimes the init routine is blasting commands out to the hardware
faster than it can reply. Throw a brief delay in there to give the
hardware a chance to reply before we send the next command.

v2: use msleep instead of mdelay per Mauro's suggestion

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 111bead..b1ea485 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -735,6 +735,7 @@ static void mce_request_packet(struct mceusb_dev *ir, 
unsigned char *data,
 static void mce_async_out(struct mceusb_dev *ir, unsigned char *data, int size)
 {
mce_request_packet(ir, data, size, MCEUSB_TX);
+   msleep(10);
 }
 
 static void mce_flush_rx_buffer(struct mceusb_dev *ir, int size)
-- 
1.7.1

--
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 3/9] [media] mceusb: set wakeup bits for IR-based resume

[Jarod Wilson]

Its not uncommon for folks to force these bits enabled, because people
do want to wake their htpc kit via their remote. Lets just set the bits
for 'em.

v2: rebase for mdelay-msleep changes

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index b1ea485..ab074a3 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -37,6 +37,7 @@
 #include linux/slab.h
 #include linux/usb.h
 #include linux/usb/input.h
+#include linux/pm_wakeup.h
 #include media/rc-core.h
 
 #define DRIVER_VERSION 1.91
@@ -1289,6 +1290,10 @@ static int __devinit mceusb_dev_probe(struct 
usb_interface *intf,
 
usb_set_intfdata(intf, ir);
 
+   /* enable wake via this device */
+   device_set_wakeup_capable(ir-dev, true);
+   device_set_wakeup_enable(ir-dev, true);
+
dev_info(intf-dev, Registered %s on usb%d:%d\n, name,
 dev-bus-busnum, dev-devnum);
 
-- 
1.7.1

--
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 4/9] [media] mceusb: issue device resume cmd when needed

[Jarod Wilson]

According to MS docs, the device firmware may halt after receiving an
unknown instruction, but that it should be possible to tell the firmware
to continue running by simply sending a device resume command. So lets
do that.

v2: use msleep instead of mdelay per Mauro's suggestion

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index ab074a3..f1fc11d 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -436,6 +436,8 @@ struct mceusb_dev {
char name[128];
char phys[64];
enum mceusb_model_type model;
+
+   bool need_reset;/* flag to issue a device resume cmd */
 };
 
 /* MCE Device Command Strings, generally a port and command pair */
@@ -735,6 +737,14 @@ static void mce_request_packet(struct mceusb_dev *ir, 
unsigned char *data,
 
 static void mce_async_out(struct mceusb_dev *ir, unsigned char *data, int size)
 {
+   int rsize = sizeof(DEVICE_RESUME);
+
+   if (ir-need_reset) {
+   ir-need_reset = false;
+   mce_request_packet(ir, DEVICE_RESUME, rsize, MCEUSB_TX);
+   msleep(10);
+   }
+
mce_request_packet(ir, data, size, MCEUSB_TX);
msleep(10);
 }
@@ -911,6 +921,9 @@ static void mceusb_handle_command(struct mceusb_dev *ir, 
int index)
case MCE_RSP_EQIRRXPORTEN:
ir-learning_enabled = ((hi  0x02) == 0x02);
break;
+   case MCE_RSP_CMD_ILLEGAL:
+   ir-need_reset = true;
+   break;
default:
break;
}
-- 
1.7.1

--
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 5/9] [media] mceusb: query device for firmware emulator version

[Jarod Wilson]

Supposedly, there are essentially three different classes of devices
that are compatible with Microsoft's specs. First are the legacy
devices, which are built using Microsoft-provided hardware specs and
firmware. Second are emulator devices, which are built using custom
hardware and firmware, written to emulate Microsoft's firmware. Third
are port devices, which have their own device driver and firmware,
which provides compatible data to higher levels of the stack.

From what I can tell, things like nuvoton-cir and fintek-cir are
essentially port devices -- their raw IR buffer format is very similar
to that of the mceusb devices. Now, within the mceusb driver, we have
three different generations, which at first, seemed like maybe they
mapped to emulator versions. Unfortuantely, every single device I have
responds illegal command to the query to get firmware emulator version
from the hardware, which means they're either all emulator version 1, or
they're legacy devices, and our different generations aren't at all
related here. Though in theory, its possible the gen1 devices are
legacy devices and the rest are emulator v1. There are some useful
features of the v2 interface I was hoping to play with, but alas...

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |   19 +--
 1 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index f1fc11d..fb2fa9d 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -438,12 +438,14 @@ struct mceusb_dev {
enum mceusb_model_type model;
 
bool need_reset;/* flag to issue a device resume cmd */
+   u8 emver;   /* emulator interface version */
 };
 
 /* MCE Device Command Strings, generally a port and command pair */
 static char DEVICE_RESUME[]= {MCE_CMD_NULL, MCE_CMD_PORT_SYS,
   MCE_CMD_RESUME};
 static char GET_REVISION[] = {MCE_CMD_PORT_SYS, MCE_CMD_G_REVISION};
+static char GET_EMVER[]= {MCE_CMD_PORT_SYS, MCE_CMD_GETEMVER};
 static char GET_WAKEVERSION[]  = {MCE_CMD_PORT_SYS, MCE_CMD_GETWAKEVERSION};
 static char GET_UNKNOWN2[] = {MCE_CMD_PORT_IR, MCE_CMD_UNKNOWN2};
 static char GET_CARRIER_FREQ[] = {MCE_CMD_PORT_IR, MCE_CMD_GETIRCFS};
@@ -915,6 +917,9 @@ static void mceusb_handle_command(struct mceusb_dev *ir, 
int index)
break;
 
/* 1-byte return value commands */
+   case MCE_RSP_EQEMVER:
+   ir-emver = hi;
+   break;
case MCE_RSP_EQIRTXPORTS:
ir-tx_mask = hi;
break;
@@ -1037,6 +1042,13 @@ static void mceusb_dev_recv(struct urb *urb, struct 
pt_regs *regs)
usb_submit_urb(urb, GFP_ATOMIC);
 }
 
+static void mceusb_get_emulator_version(struct mceusb_dev *ir)
+{
+   /* If we get no reply or an illegal command reply, its ver 1, says MS */
+   ir-emver = 1;
+   mce_async_out(ir, GET_EMVER, sizeof(GET_EMVER));
+}
+
 static void mceusb_gen1_init(struct mceusb_dev *ir)
 {
int ret;
@@ -1290,6 +1302,9 @@ static int __devinit mceusb_dev_probe(struct 
usb_interface *intf,
mce_dbg(intf-dev, Flushing receive buffers\n);
mce_flush_rx_buffer(ir, maxp);
 
+   /* figure out which firmware/emulator version this hardware has */
+   mceusb_get_emulator_version(ir);
+
/* initialize device */
if (ir-flags.microsoft_gen1)
mceusb_gen1_init(ir);
@@ -1307,8 +1322,8 @@ static int __devinit mceusb_dev_probe(struct 
usb_interface *intf,
device_set_wakeup_capable(ir-dev, true);
device_set_wakeup_enable(ir-dev, true);
 
-   dev_info(intf-dev, Registered %s on usb%d:%d\n, name,
-dev-bus-busnum, dev-devnum);
+   dev_info(intf-dev, Registered %s with mce emulator interface 
+version %x\n, name, ir-emver);
 
return 0;
 
-- 
1.7.1

--
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 8/9] [media] mceusb: report actual tx frequencies

[Jarod Wilson]

Rather than dumping out hex values, lets print the actual calculated
frequency and period the hardware has been configured for. After this
change:

[ 2643.276215] mceusb 3-1:1.0: tx data: 9f 07 (length=2)
[ 2643.276218] mceusb 3-1:1.0: Get carrier mode and freq
[ 2643.277206] mceusb 3-1:1.0: rx data: 9f 06 01 42 (length=4)
[ 2643.277209] mceusb 3-1:1.0: Got carrier of 37037 Hz (period 27us)

Matches up perfectly with the table in Microsoft's docs.

Of course, I've noticed on one of my devices that the MS-recommended
default value of 1 for carrier pre-scaler and 66 for carrier period was
butchered, and instead of converting 66 to hex (0x42 like above), they
put in 0x66, so the hardware reports a default carrier of 24390Hz.
Fortunately, I guess, this particular device is rx-only, but I wouldn't
put it past other hw to screw up here too.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |   16 +++-
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 160409e..b0c8bd2 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -516,6 +516,7 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir, 
char *buf,
u8 cmd, subcmd, data1, data2, data3, data4, data5;
struct device *dev = ir-dev;
int i, start, skip = 0;
+   u32 carrier, period;
 
if (!debug)
return;
@@ -613,9 +614,14 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir, 
char *buf,
dev_info(dev, Resp to 9f 05 of 0x%02x 0x%02x\n,
 data1, data2);
break;
-   case MCE_CMD_SETIRCFS:
-   dev_info(dev, %s carrier mode and freq of 
-0x%02x 0x%02x\n, inout, data1, data2);
+   case MCE_RSP_EQIRCFS:
+   period = DIV_ROUND_CLOSEST(
+   (1  data1 * 2) * (data2 + 1), 10);
+   if (!period)
+   break;
+   carrier = (1000 * 1000) / period;
+   dev_info(dev, %s carrier of %u Hz (period %uus)\n,
+inout, carrier, period);
break;
case MCE_CMD_GETIRCFS:
dev_info(dev, Get carrier mode and freq\n);
@@ -626,9 +632,9 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir, 
char *buf,
break;
case MCE_RSP_EQIRTIMEOUT:
/* value is in units of 50us, so x*50/1000 ms */
+   period = ((data1  8) | data2) * MCE_TIME_UNIT / 1000;
dev_info(dev, %s receive timeout of %d ms\n,
-inout,
-((data1  8) | data2) * MCE_TIME_UNIT / 1000);
+inout, period);
break;
case MCE_CMD_GETIRTIMEOUT:
dev_info(dev, Get receive timeout\n);
-- 
1.7.1

--
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/3] redrat3 driver updates for 3.1

[Jarod Wilson]

Mauro Carvalho Chehab wrote:

Em 13-07-2011 18:26, Jarod Wilson escreveu:

These changes make the redrat3 driver cooperate better with both in-kernel
and lirc userspace decoding of signals, tested with RC5, RC6 and NEC.
There's probably more we can do to make this a bit less hackish, but its
working quite well here for me right now.

Jarod Wilson (3):
   [media] redrat3: sending extra trailing space was useless
   [media] redrat3: cap duration in the right place
   [media] redrat3: improve compat with lirc userspace decode



Applied, thanks. There's one small issue on it (32 bits compilation):

drivers/media/rc/redrat3.c: In function ‘redrat3_init_rc_dev’:
drivers/media/rc/redrat3.c:1106: warning: assignment from incompatible pointer 
type
compilation succeeded



I've mainly been working atop 3.0-rc bits, so I wasn't getting that 
warning. I believe that's new, following merge of one of David 
Härdeman's patches that reworks tx a bit, iirc. I'll take care of that 
as soon as I can.


--
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] [media] imon: rate-limit send_packet spew

[Jarod Wilson]

Mauro Carvalho Chehab wrote:

Em 13-07-2011 18:58, Jarod Wilson escreveu:

There are folks with flaky imon hardware out there that doesn't always
respond to requests to write to their displays for some reason, which
can flood logs quickly when something like lcdproc is trying to
constantly update the display, so lets rate-limit all that error spew.


This patch caused a compilation error here:

drivers/media/rc/imon.c: In function ‘send_packet’:
drivers/media/rc/imon.c:519: warning: type defaults to ‘int’ in declaration of 
‘DEFINE_RATELIMIT_STATE’
drivers/media/rc/imon.c:519: warning: parameter names (without types) in 
function declaration


D'oh, sorry. Missing the linux/ratelimit.h #include... Will send a 
proper v2 after lunch (and a compile sanity-check).


--
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

[PATCH v2] [media] imon: rate-limit send_packet spew

[Jarod Wilson]

There are folks with flaky imon hardware out there that doesn't always
respond to requests to write to their displays for some reason, which
can flood logs quickly when something like lcdproc is trying to
constantly update the display, so lets rate-limit all that error spew.

v2: add missing ratelimit.h include

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/imon.c |   26 ++
 1 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 6bc35ee..caa3e3a 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -34,6 +34,7 @@
 #include linux/module.h
 #include linux/slab.h
 #include linux/uaccess.h
+#include linux/ratelimit.h
 
 #include linux/input.h
 #include linux/usb.h
@@ -516,19 +517,19 @@ static int send_packet(struct imon_context *ictx)
if (retval) {
ictx-tx.busy = false;
smp_rmb(); /* ensure later readers know we're not busy */
-   pr_err(error submitting urb(%d)\n, retval);
+   pr_err_ratelimited(error submitting urb(%d)\n, retval);
} else {
/* Wait for transmission to complete (or abort) */
mutex_unlock(ictx-lock);
retval = wait_for_completion_interruptible(
ictx-tx.finished);
if (retval)
-   pr_err(task interrupted\n);
+   pr_err_ratelimited(task interrupted\n);
mutex_lock(ictx-lock);
 
retval = ictx-tx.status;
if (retval)
-   pr_err(packet tx failed (%d)\n, retval);
+   pr_err_ratelimited(packet tx failed (%d)\n, retval);
}
 
kfree(control_req);
@@ -830,20 +831,20 @@ static ssize_t vfd_write(struct file *file, const char 
*buf,
 
ictx = file-private_data;
if (!ictx) {
-   pr_err(no context for device\n);
+   pr_err_ratelimited(no context for device\n);
return -ENODEV;
}
 
mutex_lock(ictx-lock);
 
if (!ictx-dev_present_intf0) {
-   pr_err(no iMON device present\n);
+   pr_err_ratelimited(no iMON device present\n);
retval = -ENODEV;
goto exit;
}
 
if (n_bytes = 0 || n_bytes  32) {
-   pr_err(invalid payload size\n);
+   pr_err_ratelimited(invalid payload size\n);
retval = -EINVAL;
goto exit;
}
@@ -869,7 +870,7 @@ static ssize_t vfd_write(struct file *file, const char *buf,
 
retval = send_packet(ictx);
if (retval) {
-   pr_err(send packet failed for packet #%d\n, seq / 2);
+   pr_err_ratelimited(send packet #%d failed\n, seq / 2);
goto exit;
} else {
seq += 2;
@@ -883,7 +884,7 @@ static ssize_t vfd_write(struct file *file, const char *buf,
ictx-usb_tx_buf[7] = (unsigned char) seq;
retval = send_packet(ictx);
if (retval)
-   pr_err(send packet failed for packet #%d\n, seq / 2);
+   pr_err_ratelimited(send packet #%d failed\n, seq / 2);
 
 exit:
mutex_unlock(ictx-lock);
@@ -912,20 +913,21 @@ static ssize_t lcd_write(struct file *file, const char 
*buf,
 
ictx = file-private_data;
if (!ictx) {
-   pr_err(no context for device\n);
+   pr_err_ratelimited(no context for device\n);
return -ENODEV;
}
 
mutex_lock(ictx-lock);
 
if (!ictx-display_supported) {
-   pr_err(no iMON display present\n);
+   pr_err_ratelimited(no iMON display present\n);
retval = -ENODEV;
goto exit;
}
 
if (n_bytes != 8) {
-   pr_err(invalid payload size: %d (expected 8)\n, (int)n_bytes);
+   pr_err_ratelimited(invalid payload size: %d (expected 8)\n,
+  (int)n_bytes);
retval = -EINVAL;
goto exit;
}
@@ -937,7 +939,7 @@ static ssize_t lcd_write(struct file *file, const char *buf,
 
retval = send_packet(ictx);
if (retval) {
-   pr_err(send packet failed!\n);
+   pr_err_ratelimited(send packet failed!\n);
goto exit;
} else {
dev_dbg(ictx-dev, %s: write %d bytes to LCD\n,
-- 
1.7.5.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] [media] redrat3: remove unused dev struct members

[Jarod Wilson]

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/redrat3.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 5fc2f05..ee1303c 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -195,11 +195,6 @@ struct redrat3_dev {
dma_addr_t dma_in;
dma_addr_t dma_out;
 
-   /* true if write urb is busy */
-   bool write_busy;
-   /* wait for the write to finish */
-   struct completion write_finished;
-
/* locks this structure */
struct mutex lock;
 
@@ -207,8 +202,6 @@ struct redrat3_dev {
struct timer_list rx_timeout;
u32 hw_timeout;
 
-   /* Is the device currently receiving? */
-   bool recv_in_progress;
/* is the detector enabled*/
bool det_enabled;
/* Is the device currently transmitting?*/
-- 
1.7.1

--
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] [media] em28xx: add em28xx_ prefix to functions

[Jarod Wilson]

Makes it more straight-forward to follow stack traces if the functions
don't have generic names. Using this as a crutch while trying to better
understand the lockdep warnings I get when loading the em28xx driver.

CC: Devin Heitmueller dheitmuel...@kernellabs.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/video/em28xx/em28xx-dvb.c |   58 +++
 1 files changed, 28 insertions(+), 30 deletions(-)

diff --git a/drivers/media/video/em28xx/em28xx-dvb.c 
b/drivers/media/video/em28xx/em28xx-dvb.c
index 7904ca4..922b858 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -115,7 +115,7 @@ static inline void print_err_status(struct em28xx *dev,
}
 }
 
-static inline int dvb_isoc_copy(struct em28xx *dev, struct urb *urb)
+static inline int em28xx_dvb_isoc_copy(struct em28xx *dev, struct urb *urb)
 {
int i;
 
@@ -148,7 +148,7 @@ static inline int dvb_isoc_copy(struct em28xx *dev, struct 
urb *urb)
return 0;
 }
 
-static int start_streaming(struct em28xx_dvb *dvb)
+static int em28xx_start_streaming(struct em28xx_dvb *dvb)
 {
int rc;
struct em28xx *dev = dvb-adapter.priv;
@@ -163,10 +163,10 @@ static int start_streaming(struct em28xx_dvb *dvb)
 
return em28xx_init_isoc(dev, EM28XX_DVB_MAX_PACKETS,
EM28XX_DVB_NUM_BUFS, max_dvb_packet_size,
-   dvb_isoc_copy);
+   em28xx_dvb_isoc_copy);
 }
 
-static int stop_streaming(struct em28xx_dvb *dvb)
+static int em28xx_stop_streaming(struct em28xx_dvb *dvb)
 {
struct em28xx *dev = dvb-adapter.priv;
 
@@ -177,7 +177,7 @@ static int stop_streaming(struct em28xx_dvb *dvb)
return 0;
 }
 
-static int start_feed(struct dvb_demux_feed *feed)
+static int em28xx_start_feed(struct dvb_demux_feed *feed)
 {
struct dvb_demux *demux  = feed-demux;
struct em28xx_dvb *dvb = demux-priv;
@@ -191,7 +191,7 @@ static int start_feed(struct dvb_demux_feed *feed)
rc = dvb-nfeeds;
 
if (dvb-nfeeds == 1) {
-   ret = start_streaming(dvb);
+   ret = em28xx_start_streaming(dvb);
if (ret  0)
rc = ret;
}
@@ -200,7 +200,7 @@ static int start_feed(struct dvb_demux_feed *feed)
return rc;
 }
 
-static int stop_feed(struct dvb_demux_feed *feed)
+static int em28xx_stop_feed(struct dvb_demux_feed *feed)
 {
struct dvb_demux *demux  = feed-demux;
struct em28xx_dvb *dvb = demux-priv;
@@ -210,7 +210,7 @@ static int stop_feed(struct dvb_demux_feed *feed)
dvb-nfeeds--;
 
if (0 == dvb-nfeeds)
-   err = stop_streaming(dvb);
+   err = em28xx_stop_streaming(dvb);
 
mutex_unlock(dvb-lock);
return err;
@@ -295,7 +295,7 @@ static struct drxd_config em28xx_drxd = {
.disable_i2c_gate_ctrl = 1,
 };
 
-static int mt352_terratec_xs_init(struct dvb_frontend *fe)
+static int em28xx_mt352_terratec_xs_init(struct dvb_frontend *fe)
 {
/* Values extracted from a USB trace of the Terratec Windows driver */
static u8 clock_config[]   = { CLOCK_CTL,  0x38, 0x2c };
@@ -327,7 +327,7 @@ static struct mt352_config terratec_xs_mt352_cfg = {
.demod_address = (0x1e  1),
.no_tuner = 1,
.if2 = 45600,
-   .demod_init = mt352_terratec_xs_init,
+   .demod_init = em28xx_mt352_terratec_xs_init,
 };
 
 static struct tda10023_config em28xx_tda10023_config = {
@@ -357,7 +357,7 @@ static struct tda18271_config 
em28xx_cxd2820r_tda18271_config = {
 
 /* -- */
 
-static int attach_xc3028(u8 addr, struct em28xx *dev)
+static int em28xx_attach_xc3028(u8 addr, struct em28xx *dev)
 {
struct dvb_frontend *fe;
struct xc2028_config cfg;
@@ -387,10 +387,8 @@ static int attach_xc3028(u8 addr, struct em28xx *dev)
 
 /* -- */
 
-static int register_dvb(struct em28xx_dvb *dvb,
-struct module *module,
-struct em28xx *dev,
-struct device *device)
+static int em28xx_register_dvb(struct em28xx_dvb *dvb, struct module *module,
+  struct em28xx *dev, struct device *device)
 {
int result;
 
@@ -437,8 +435,8 @@ static int register_dvb(struct em28xx_dvb *dvb,
dvb-demux.priv   = dvb;
dvb-demux.filternum  = 256;
dvb-demux.feednum= 256;
-   dvb-demux.start_feed = start_feed;
-   dvb-demux.stop_feed  = stop_feed;
+   dvb-demux.start_feed = em28xx_start_feed;
+   dvb-demux.stop_feed  = em28xx_stop_feed;
 
result = dvb_dmx_init(dvb-demux);
if (result  0) {
@@ -506,7 +504,7 @@ fail_adapter:
return result;
 }
 
-static void unregister_dvb(struct em28xx_dvb *dvb)
+static void em28xx_unregister_dvb(struct em28xx_dvb

[PATCH 0/9] mceusb updates per MS docs

[Jarod Wilson]

This is a stack of updates made based on the Windows Media Center remote
and receiver/transmitter specification and requirements document that
Rafi Rubin recently pointed me at. Its titled
Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf
which as of this writing, is publicly available from
download.microsoft.com.

Tested with 7 different mceusb devices, with no ill effects. Unfortunately,
for the most part, these chagnes don't actually improve any shortcomings in
the driver, but they do give us a better view of the hardware features and
whatnot, and a few things are better explained now, with most of the command
and response bits lining up with what MS has documented.

Jarod Wilson (9):
  [media] mceusb: command/response updates from MS docs
  [media] mceusb: give hardware time to reply to cmds
  [media] mceusb: set wakeup bits for IR-based resume
  [media] mceusb: issue device resume cmd when needed
  [media] mceusb: query device for firmware emulator version
  [media] mceusb: get misc port data from hardware
  [media] mceusb: flash LED (emu v2+ only) to signal end of init
  [media] mceusb: report actual tx frequencies
  [media] mceusb: update version, copyright, author

 drivers/media/rc/mceusb.c |  422 ++---
 1 files changed, 286 insertions(+), 136 deletions(-)

--
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] [media] mceusb: give hardware time to reply to cmds

[Jarod Wilson]

Sometimes the init routine is blasting commands out to the hardware
faster than it can reply. Throw a brief delay in there to give the
hardware a chance to reply before we send the next command.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 111bead..13a853b 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -37,6 +37,7 @@
 #include linux/slab.h
 #include linux/usb.h
 #include linux/usb/input.h
+#include linux/delay.h
 #include media/rc-core.h
 
 #define DRIVER_VERSION 1.91
@@ -735,6 +736,7 @@ static void mce_request_packet(struct mceusb_dev *ir, 
unsigned char *data,
 static void mce_async_out(struct mceusb_dev *ir, unsigned char *data, int size)
 {
mce_request_packet(ir, data, size, MCEUSB_TX);
+   mdelay(10);
 }
 
 static void mce_flush_rx_buffer(struct mceusb_dev *ir, int size)
-- 
1.7.1

--
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] [media] mceusb: set wakeup bits for IR-based resume

[Jarod Wilson]

Its not uncommon for folks to force these bits enabled, because people
do want to wake their htpc kit via their remote. Lets just set the bits
for 'em.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 13a853b..7ff755f 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -37,6 +37,7 @@
 #include linux/slab.h
 #include linux/usb.h
 #include linux/usb/input.h
+#include linux/pm_wakeup.h
 #include linux/delay.h
 #include media/rc-core.h
 
@@ -1290,6 +1291,10 @@ static int __devinit mceusb_dev_probe(struct 
usb_interface *intf,
 
usb_set_intfdata(intf, ir);
 
+   /* enable wake via this device */
+   device_set_wakeup_capable(ir-dev, true);
+   device_set_wakeup_enable(ir-dev, true);
+
dev_info(intf-dev, Registered %s on usb%d:%d\n, name,
 dev-bus-busnum, dev-devnum);
 
-- 
1.7.1

--
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] [media] mceusb: issue device resume cmd when needed

[Jarod Wilson]

According to MS docs, the device firmware may halt after receiving an
unknown instruction, but that it should be possible to tell the firmware
to continue running by simply sending a device resume command. So lets
do that.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 7ff755f..a777623 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -437,6 +437,8 @@ struct mceusb_dev {
char name[128];
char phys[64];
enum mceusb_model_type model;
+
+   bool need_reset;/* flag to issue a device resume cmd */
 };
 
 /* MCE Device Command Strings, generally a port and command pair */
@@ -736,6 +738,14 @@ static void mce_request_packet(struct mceusb_dev *ir, 
unsigned char *data,
 
 static void mce_async_out(struct mceusb_dev *ir, unsigned char *data, int size)
 {
+   int rsize = sizeof(DEVICE_RESUME);
+
+   if (ir-need_reset) {
+   ir-need_reset = false;
+   mce_request_packet(ir, DEVICE_RESUME, rsize, MCEUSB_TX);
+   mdelay(10);
+   }
+
mce_request_packet(ir, data, size, MCEUSB_TX);
mdelay(10);
 }
@@ -912,6 +922,9 @@ static void mceusb_handle_command(struct mceusb_dev *ir, 
int index)
case MCE_RSP_EQIRRXPORTEN:
ir-learning_enabled = ((hi  0x02) == 0x02);
break;
+   case MCE_RSP_CMD_ILLEGAL:
+   ir-need_reset = true;
+   break;
default:
break;
}
-- 
1.7.1

--
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] [media] mceusb: report actual tx frequencies

[Jarod Wilson]

Rather than dumping out hex values, lets print the actual calculated
frequency and period the hardware has been configured for. After this
change:

[ 2643.276215] mceusb 3-1:1.0: tx data: 9f 07 (length=2)
[ 2643.276218] mceusb 3-1:1.0: Get carrier mode and freq
[ 2643.277206] mceusb 3-1:1.0: rx data: 9f 06 01 42 (length=4)
[ 2643.277209] mceusb 3-1:1.0: Got carrier of 37037 Hz (period 27us)

Matches up perfectly with the table in Microsoft's docs.

Of course, I've noticed on one of my devices that the MS-recommended
default value of 1 for carrier pre-scaler and 66 for carrier period was
butchered, and instead of converting 66 to hex (0x42 like above), they
put in 0x66, so the hardware reports a default carrier of 24390Hz.
Fortunately, I guess, this particular device is rx-only, but I wouldn't
put it past other hw to screw up here too.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |   16 +++-
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index bbd79c0..fa1d182 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -517,6 +517,7 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir, 
char *buf,
u8 cmd, subcmd, data1, data2, data3, data4, data5;
struct device *dev = ir-dev;
int i, start, skip = 0;
+   u32 carrier, period;
 
if (!debug)
return;
@@ -614,9 +615,14 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir, 
char *buf,
dev_info(dev, Resp to 9f 05 of 0x%02x 0x%02x\n,
 data1, data2);
break;
-   case MCE_CMD_SETIRCFS:
-   dev_info(dev, %s carrier mode and freq of 
-0x%02x 0x%02x\n, inout, data1, data2);
+   case MCE_RSP_EQIRCFS:
+   period = DIV_ROUND_CLOSEST(
+   (1  data1 * 2) * (data2 + 1), 10);
+   if (!period)
+   break;
+   carrier = (1000 * 1000) / period;
+   dev_info(dev, %s carrier of %u Hz (period %uus)\n,
+inout, carrier, period);
break;
case MCE_CMD_GETIRCFS:
dev_info(dev, Get carrier mode and freq\n);
@@ -627,9 +633,9 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir, 
char *buf,
break;
case MCE_RSP_EQIRTIMEOUT:
/* value is in units of 50us, so x*50/1000 ms */
+   period = ((data1  8) | data2) * MCE_TIME_UNIT / 1000;
dev_info(dev, %s receive timeout of %d ms\n,
-inout,
-((data1  8) | data2) * MCE_TIME_UNIT / 1000);
+inout, period);
break;
case MCE_CMD_GETIRTIMEOUT:
dev_info(dev, Get receive timeout\n);
-- 
1.7.1

--
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 7/9] [media] mceusb: flash LED (emu v2+ only) to signal end of init

[Jarod Wilson]

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index e4171f7..bbd79c0 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -452,6 +452,7 @@ static char DEVICE_RESUME[] = {MCE_CMD_NULL, 
MCE_CMD_PORT_SYS,
 static char GET_REVISION[] = {MCE_CMD_PORT_SYS, MCE_CMD_G_REVISION};
 static char GET_EMVER[]= {MCE_CMD_PORT_SYS, MCE_CMD_GETEMVER};
 static char GET_WAKEVERSION[]  = {MCE_CMD_PORT_SYS, MCE_CMD_GETWAKEVERSION};
+static char FLASH_LED[]= {MCE_CMD_PORT_SYS, MCE_CMD_FLASHLED};
 static char GET_UNKNOWN2[] = {MCE_CMD_PORT_IR, MCE_CMD_UNKNOWN2};
 static char GET_CARRIER_FREQ[] = {MCE_CMD_PORT_IR, MCE_CMD_GETIRCFS};
 static char GET_RX_TIMEOUT[]   = {MCE_CMD_PORT_IR, MCE_CMD_GETIRTIMEOUT};
@@ -592,6 +593,9 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir, 
char *buf,
dev_info(dev, TX port %d: blaster is%s 
connected\n,
 data1 + 1, data4 ?  not : );
break;
+   case MCE_CMD_FLASHLED:
+   dev_info(dev, Attempting to flash LED\n);
+   break;
default:
dev_info(dev, Unknown command 0x%02x 0x%02x\n,
 cmd, subcmd);
@@ -1166,6 +1170,14 @@ static void mceusb_get_parameters(struct mceusb_dev *ir)
}
 }
 
+static void mceusb_flash_led(struct mceusb_dev *ir)
+{
+   if (ir-emver  2)
+   return;
+
+   mce_async_out(ir, FLASH_LED, sizeof(FLASH_LED));
+}
+
 static struct rc_dev *mceusb_init_rc_dev(struct mceusb_dev *ir)
 {
struct device *dev = ir-dev;
@@ -1343,6 +1355,8 @@ static int __devinit mceusb_dev_probe(struct 
usb_interface *intf,
 
mceusb_get_parameters(ir);
 
+   mceusb_flash_led(ir);
+
if (ir-num_txports  !ir-flags.no_tx) {
ir-rc-s_tx_mask = mceusb_set_tx_mask;
ir-rc-s_tx_carrier = mceusb_set_tx_carrier;
-- 
1.7.1

--
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] [media] mceusb: update version, copyright, author

[Jarod Wilson]

Add note about recent updates coming from Microsoft's publicly available
specs on Windows Media Center remotes and receivers/transmitters.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index fa1d182..053d079 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1,7 +1,7 @@
 /*
  * Driver for USB Windows Media Center Ed. eHome Infrared Transceivers
  *
- * Copyright (c) 2010 by Jarod Wilson ja...@redhat.com
+ * Copyright (c) 2010-2011, Jarod Wilson ja...@redhat.com
  *
  * Based on the original lirc_mceusb and lirc_mceusb2 drivers, by Dan
  * Conti, Martin Blatter and Daniel Melander, the latter of which was
@@ -15,6 +15,11 @@
  * Jon Smirl, which included enhancements and simplifications to the
  * incoming IR buffer parsing routines.
  *
+ * Updated in July of 2011 with the aid of Microsoft's official
+ * remote/transceiver requirements and specification document, found at
+ * download.microsoft.com, title
+ * 
Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf
+ *
  *
  * 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
@@ -41,8 +46,8 @@
 #include linux/delay.h
 #include media/rc-core.h
 
-#define DRIVER_VERSION 1.91
-#define DRIVER_AUTHOR  Jarod Wilson ja...@wilsonet.com
+#define DRIVER_VERSION 1.92
+#define DRIVER_AUTHOR  Jarod Wilson ja...@redhat.com
 #define DRIVER_DESCWindows Media Center Ed. eHome Infrared Transceiver  \
device driver
 #define DRIVER_NAMEmceusb
-- 
1.7.1

--
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] [media] mceusb: query device for firmware emulator version

[Jarod Wilson]

Supposedly, there are essentially three different classes of devices
that are compatible with Microsoft's specs. First are the legacy
devices, which are built using Microsoft-provided hardware specs and
firmware. Second are emulator devices, which are built using custom
hardware and firmware, written to emulate Microsoft's firmware. Third
are port devices, which have their own device driver and firmware,
which provides compatible data to higher levels of the stack.

From what I can tell, things like nuvoton-cir and fintek-cir are
essentially port devices -- their raw IR buffer format is very similar
to that of the mceusb devices. Now, within the mceusb driver, we have
three different generations, which at first, seemed like maybe they
mapped to emulator versions. Unfortuantely, every single device I have
responds illegal command to the query to get firmware emulator version
from the hardware, which means they're either all emulator version 1, or
they're legacy devices, and our different generations aren't at all
related here. Though in theory, its possible the gen1 devices are
legacy devices and the rest are emulator v1. There are some useful
features of the v2 interface I was hoping to play with, but alas...

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |   19 +--
 1 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index a777623..114fb13 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -439,12 +439,14 @@ struct mceusb_dev {
enum mceusb_model_type model;
 
bool need_reset;/* flag to issue a device resume cmd */
+   u8 emver;   /* emulator interface version */
 };
 
 /* MCE Device Command Strings, generally a port and command pair */
 static char DEVICE_RESUME[]= {MCE_CMD_NULL, MCE_CMD_PORT_SYS,
   MCE_CMD_RESUME};
 static char GET_REVISION[] = {MCE_CMD_PORT_SYS, MCE_CMD_G_REVISION};
+static char GET_EMVER[]= {MCE_CMD_PORT_SYS, MCE_CMD_GETEMVER};
 static char GET_WAKEVERSION[]  = {MCE_CMD_PORT_SYS, MCE_CMD_GETWAKEVERSION};
 static char GET_UNKNOWN2[] = {MCE_CMD_PORT_IR, MCE_CMD_UNKNOWN2};
 static char GET_CARRIER_FREQ[] = {MCE_CMD_PORT_IR, MCE_CMD_GETIRCFS};
@@ -916,6 +918,9 @@ static void mceusb_handle_command(struct mceusb_dev *ir, 
int index)
break;
 
/* 1-byte return value commands */
+   case MCE_RSP_EQEMVER:
+   ir-emver = hi;
+   break;
case MCE_RSP_EQIRTXPORTS:
ir-tx_mask = hi;
break;
@@ -1038,6 +1043,13 @@ static void mceusb_dev_recv(struct urb *urb, struct 
pt_regs *regs)
usb_submit_urb(urb, GFP_ATOMIC);
 }
 
+static void mceusb_get_emulator_version(struct mceusb_dev *ir)
+{
+   /* If we get no reply or an illegal command reply, its ver 1, says MS */
+   ir-emver = 1;
+   mce_async_out(ir, GET_EMVER, sizeof(GET_EMVER));
+}
+
 static void mceusb_gen1_init(struct mceusb_dev *ir)
 {
int ret;
@@ -1291,6 +1303,9 @@ static int __devinit mceusb_dev_probe(struct 
usb_interface *intf,
mce_dbg(intf-dev, Flushing receive buffers\n);
mce_flush_rx_buffer(ir, maxp);
 
+   /* figure out which firmware/emulator version this hardware has */
+   mceusb_get_emulator_version(ir);
+
/* initialize device */
if (ir-flags.microsoft_gen1)
mceusb_gen1_init(ir);
@@ -1308,8 +1323,8 @@ static int __devinit mceusb_dev_probe(struct 
usb_interface *intf,
device_set_wakeup_capable(ir-dev, true);
device_set_wakeup_enable(ir-dev, true);
 
-   dev_info(intf-dev, Registered %s on usb%d:%d\n, name,
-dev-bus-busnum, dev-devnum);
+   dev_info(intf-dev, Registered %s with mce emulator interface 
+version %x\n, name, ir-emver);
 
return 0;
 
-- 
1.7.1

--
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 6/9] [media] mceusb: get misc port data from hardware

[Jarod Wilson]

According to the specs, you can read the number of tx ports, number of
rx sensors, which tx ports have cables plugged into them, and which rx
sensors are active. In practice, most of my devices do seem to report
sane values for tx ports and rx sensors (but not all -- one without any
tx ports reports having them), and most report the active sensor
correctly, but only one of eight reports cabled tx ports correctly. So
for the most part, this is just for informational purposes.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |   51 ++--
 1 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 114fb13..e4171f7 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -440,6 +440,10 @@ struct mceusb_dev {
 
bool need_reset;/* flag to issue a device resume cmd */
u8 emver;   /* emulator interface version */
+   u8 num_txports; /* number of transmit ports */
+   u8 num_rxports; /* number of receive sensors */
+   u8 txports_cabled;  /* bitmask of transmitters with cable */
+   u8 rxports_active;  /* bitmask of active receive sensors */
 };
 
 /* MCE Device Command Strings, generally a port and command pair */
@@ -451,6 +455,7 @@ static char GET_WAKEVERSION[]   = {MCE_CMD_PORT_SYS, 
MCE_CMD_GETWAKEVERSION};
 static char GET_UNKNOWN2[] = {MCE_CMD_PORT_IR, MCE_CMD_UNKNOWN2};
 static char GET_CARRIER_FREQ[] = {MCE_CMD_PORT_IR, MCE_CMD_GETIRCFS};
 static char GET_RX_TIMEOUT[]   = {MCE_CMD_PORT_IR, MCE_CMD_GETIRTIMEOUT};
+static char GET_NUM_PORTS[]= {MCE_CMD_PORT_IR, MCE_CMD_GETIRNUMPORTS};
 static char GET_TX_BITMASK[]   = {MCE_CMD_PORT_IR, MCE_CMD_GETIRTXPORTS};
 static char GET_RX_SENSOR[]= {MCE_CMD_PORT_IR, MCE_CMD_GETIRRXPORTEN};
 /* sub in desired values in lower byte or bytes for full command */
@@ -544,6 +549,8 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir, 
char *buf,
 
switch (cmd) {
case MCE_CMD_NULL:
+   if (subcmd == MCE_CMD_NULL)
+   break;
if ((subcmd == MCE_CMD_PORT_SYS) 
(data1 == MCE_CMD_RESUME))
dev_info(dev, Device resume requested\n);
@@ -912,10 +919,20 @@ static void mceusb_handle_command(struct mceusb_dev *ir, 
int index)
u8 lo = ir-buf_in[index + 2]  0xff;
 
switch (ir-buf_in[index]) {
+   /* the one and only 5-byte return value command */
+   case MCE_RSP_GETPORTSTATUS:
+   if ((ir-buf_in[index + 4]  0xff) == 0x00)
+   ir-txports_cabled |= 1  hi;
+   break;
+
/* 2-byte return value commands */
case MCE_RSP_EQIRTIMEOUT:
ir-rc-timeout = US_TO_NS((hi  8 | lo) * MCE_TIME_UNIT);
break;
+   case MCE_RSP_EQIRNUMPORTS:
+   ir-num_txports = hi;
+   ir-num_rxports = lo;
+   break;
 
/* 1-byte return value commands */
case MCE_RSP_EQEMVER:
@@ -926,6 +943,7 @@ static void mceusb_handle_command(struct mceusb_dev *ir, 
int index)
break;
case MCE_RSP_EQIRRXPORTEN:
ir-learning_enabled = ((hi  0x02) == 0x02);
+   ir-rxports_active = hi;
break;
case MCE_RSP_CMD_ILLEGAL:
ir-need_reset = true;
@@ -1118,10 +1136,21 @@ static void mceusb_gen2_init(struct mceusb_dev *ir)
 
 static void mceusb_get_parameters(struct mceusb_dev *ir)
 {
+   int i;
+   unsigned char cmdbuf[3] = { MCE_CMD_PORT_SYS,
+   MCE_CMD_GETPORTSTATUS, 0x00 };
+
+   /* defaults, if the hardware doesn't support querying */
+   ir-num_txports = 2;
+   ir-num_rxports = 2;
+
+   /* get number of tx and rx ports */
+   mce_async_out(ir, GET_NUM_PORTS, sizeof(GET_NUM_PORTS));
+
/* get the carrier and frequency */
mce_async_out(ir, GET_CARRIER_FREQ, sizeof(GET_CARRIER_FREQ));
 
-   if (!ir-flags.no_tx)
+   if (ir-num_txports  !ir-flags.no_tx)
/* get the transmitter bitmask */
mce_async_out(ir, GET_TX_BITMASK, sizeof(GET_TX_BITMASK));
 
@@ -1130,6 +1159,11 @@ static void mceusb_get_parameters(struct mceusb_dev *ir)
 
/* get receiver sensor setting */
mce_async_out(ir, GET_RX_SENSOR, sizeof(GET_RX_SENSOR));
+
+   for (i = 0; i  ir-num_txports; i++) {
+   cmdbuf[2] = i;
+   mce_async_out(ir, cmdbuf, sizeof(cmdbuf));
+   }
 }
 
 static struct rc_dev *mceusb_init_rc_dev(struct mceusb_dev *ir)
@@ -1161,11 +1195,6 @@ static struct rc_dev *mceusb_init_rc_dev(struct 
mceusb_dev *ir)
rc-driver_type = RC_DRIVER_IR_RAW;
rc-allowed_protos = RC_TYPE_ALL;
rc-timeout = MS_TO_NS(100);
-   if (!ir-flags.no_tx) {
-   rc-s_tx_mask = mceusb_set_tx_mask

[PATCH 1/9] [media] mceusb: command/response updates from MS docs

[Jarod Wilson]

I was recently pointed to the document titled
Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf
which as of this writing, is publicly available from
download.microsoft.com. It covers a LOT of the gaps in the mceusb
driver, which to this point, was written almost entirely by
reverse-engineering. First up, I'm updating the defines for all the MCE
commands and responses to match their names in the spec. More to come...

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/mceusb.c |  293 ++--
 1 files changed, 173 insertions(+), 120 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index ec972dc..111bead 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -63,43 +63,90 @@
 #define MCE_PULSE_MASK 0x7f /* Pulse mask */
 #define MCE_MAX_PULSE_LENGTH   0x7f /* Longest transmittable pulse symbol */
 
-#define MCE_HW_CMD_HEADER  0xff/* MCE hardware command header */
-#define MCE_COMMAND_HEADER 0x9f/* MCE command header */
-#define MCE_COMMAND_MASK   0xe0/* Mask out command bits */
-#define MCE_COMMAND_NULL   0x00/* These show up various places... */
-/* if buf[i]  MCE_COMMAND_MASK == 0x80 and buf[i] != MCE_COMMAND_HEADER,
- * then we're looking at a raw IR data sample */
-#define MCE_COMMAND_IRDATA 0x80
-#define MCE_PACKET_LENGTH_MASK 0x1f /* Packet length mask */
-
-/* Sub-commands, which follow MCE_COMMAND_HEADER or MCE_HW_CMD_HEADER */
+/*
+ * The interface between the host and the IR hardware is command-response
+ * based. All commands and responses have a consistent format, where a lead
+ * byte always identifies the type of data following it. The lead byte has
+ * a port value in the 3 highest bits and a length value in the 5 lowest
+ * bits.
+ *
+ * The length field is overloaded, with a value of 1 indicating that the
+ * following byte is a command or response code, and the length of the entire
+ * message is determined by the code. If the length field is not 1, then
+ * it specifies the number of bytes of port data that follow.
+ */
+#define MCE_CMD0x1f
+#define MCE_PORT_IR0x4 /* (0x4  5) | MCE_CMD = 0x9f */
+#define MCE_PORT_SYS   0x7 /* (0x7  5) | MCE_CMD = 0xff */
+#define MCE_PORT_SER   0x6 /* 0xc0 thru 0xdf flush  0x1f bytes */
+#define MCE_PORT_MASK  0xe0/* Mask out command bits */
+
+/* Command port headers */
+#define MCE_CMD_PORT_IR0x9f/* IR-related cmd/rsp */
+#define MCE_CMD_PORT_SYS   0xff/* System (non-IR) device cmd/rsp */
+
+/* Commands that set device state  (2-4 bytes in length) */
+#define MCE_CMD_RESET  0xfe/* Reset device, 2 bytes */
+#define MCE_CMD_RESUME 0xaa/* Resume device after error, 2 bytes */
+#define MCE_CMD_SETIRCFS   0x06/* Set tx carrier, 4 bytes */
+#define MCE_CMD_SETIRTIMEOUT   0x0c/* Set timeout, 4 bytes */
+#define MCE_CMD_SETIRTXPORTS   0x08/* Set tx ports, 3 bytes */
+#define MCE_CMD_SETIRRXPORTEN  0x14/* Set rx ports, 3 bytes */
+#define MCE_CMD_FLASHLED   0x23/* Flash receiver LED, 2 bytes */
+
+/* Commands that query device state (all 2 bytes, unless noted) */
+#define MCE_CMD_GETIRCFS   0x07/* Get carrier */
+#define MCE_CMD_GETIRTIMEOUT   0x0d/* Get timeout */
+#define MCE_CMD_GETIRTXPORTS   0x13/* Get tx ports */
+#define MCE_CMD_GETIRRXPORTEN  0x15/* Get rx ports */
+#define MCE_CMD_GETPORTSTATUS  0x11/* Get tx port status, 3 bytes */
+#define MCE_CMD_GETIRNUMPORTS  0x16/* Get number of ports */
+#define MCE_CMD_GETWAKESOURCE  0x17/* Get wake source */
+#define MCE_CMD_GETEMVER   0x22/* Get emulator interface version */
+#define MCE_CMD_GETDEVDETAILS  0x21/* Get device details (em ver2 only) */
+#define MCE_CMD_GETWAKESUPPORT 0x20/* Get wake details (em ver2 only) */
+#define MCE_CMD_GETWAKEVERSION 0x18/* Get wake pattern (em ver2 only) */
+
+/* Misc commands */
+#define MCE_CMD_NOP0xff/* No operation */
+
+/* Responses to commands (non-error cases) */
+#define MCE_RSP_EQIRCFS0x06/* tx carrier, 4 bytes */
+#define MCE_RSP_EQIRTIMEOUT0x0c/* rx timeout, 4 bytes */
+#define MCE_RSP_GETWAKESOURCE  0x17/* wake source, 3 bytes */
+#define MCE_RSP_EQIRTXPORTS0x08/* tx port mask, 3 bytes */
+#define MCE_RSP_EQIRRXPORTEN   0x14/* rx port mask, 3 bytes */
+#define MCE_RSP_GETPORTSTATUS  0x11/* tx port status, 7 bytes */
+#define MCE_RSP_EQIRRXCFCNT0x15/* rx carrier count, 4 bytes */
+#define MCE_RSP_EQIRNUMPORTS   0x16/* number of ports, 4 bytes */
+#define MCE_RSP_EQWAKESUPPORT  0x20/* wake capabilities, 3 bytes */
+#define MCE_RSP_EQWAKEVERSION  0x18/* wake pattern details, 6 bytes */
+#define MCE_RSP_EQDEVDETAILS   0x21/* device capabilities, 3 bytes */
+#define MCE_RSP_EQEMVER

[PATCH] [media] rc-rc6-mce: minor keymap updates

[Jarod Wilson]

Microsoft's Windows Media Center specification and requirements doc from
2011.03.18 now refers to the former Power Toggle button as the Sleep
Toggle, and recommends using a new moon sleep icon for it. Its the same
key, but its apparently always been meant to put the system to sleep,
not power it off. Adjust accordingly. While we're here, lets also remove
the duplicate KEY_PLAYPAUSE entry.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/keymaps/rc-rc6-mce.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/keymaps/rc-rc6-mce.c 
b/drivers/media/rc/keymaps/rc-rc6-mce.c
index 01b69bc..c3907e2 100644
--- a/drivers/media/rc/keymaps/rc-rc6-mce.c
+++ b/drivers/media/rc/keymaps/rc-rc6-mce.c
@@ -29,7 +29,7 @@ static struct rc_map_table rc6_mce[] = {
 
{ 0x800f040a, KEY_DELETE },
{ 0x800f040b, KEY_ENTER },
-   { 0x800f040c, KEY_POWER },  /* PC Power */
+   { 0x800f040c, KEY_SLEEP },  /* Formerly PC Power */
{ 0x800f040d, KEY_MEDIA },  /* Windows MCE button */
{ 0x800f040e, KEY_MUTE },
{ 0x800f040f, KEY_INFO },
@@ -44,7 +44,6 @@ static struct rc_map_table rc6_mce[] = {
{ 0x800f0416, KEY_PLAY },
{ 0x800f0417, KEY_RECORD },
{ 0x800f0418, KEY_PAUSE },
-   { 0x800f046e, KEY_PLAYPAUSE },
{ 0x800f0419, KEY_STOP },
{ 0x800f041a, KEY_NEXT },
{ 0x800f041b, KEY_PREVIOUS },
-- 
1.7.1

--
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] [media] rc-core support for Microsoft IR keyboard/mouse

[Jarod Wilson]

This is a custom IR protocol decoder, for the RC-6-ish protocol used by
the Microsoft Remote Keyboard, apparently developed internally at
Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and
transceiver requirements and specifications document, which also touches
on this IR keyboard/mouse device.

http://www.amazon.com/Microsoft-Remote-Keyboard-Windows-ZV1-4/dp/B000AOAAN8

Its a standard keyboard with embedded thumb stick mouse pointer and
mouse buttons, along with a number of media keys. The media keys are
standard RC-6, identical to the signals from the stock MCE remotes, and
will be handled as such. The keyboard and mouse signals will be decoded
and delivered to the system by an input device registered specifically
by this driver.

Successfully tested with multiple mceusb-driven transceivers, as well as
with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware
with enough sampling resolution should be able to use this decoder,
nothing about it is at all receiver-hardware-specific.

This work is inspired by lirc_mod_mce:

http://mod-mce.sourceforge.net/

The documentation there and code aided in understanding and decoding the
protocol, but the bulk of the code is actually borrowed more from the
existing in-kernel decoders than anything. I did recycle the keyboard
keycode table, a few defines, and some of the keyboard and mouse data
parsing bits from lirc_mod_mce though.

Special thanks to James Meyer for providing the hardware, and being
patient with me as I took forever to get around to writing this.

v2: now know its MCIR-2, updated accordingly, added a key release timer
callback routine to ensure we don't get any stuck keys, and used
symbolic names for the keytable. Also cc'ing Florian this time, who I
believe is the original mod-mce author...

CC: Florian Demski fdem...@users.sourceforge.net
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/Kconfig  |   11 +
 drivers/media/rc/Makefile |1 +
 drivers/media/rc/ir-mce_kbd-decoder.c |  448 +
 drivers/media/rc/ir-raw.c |1 +
 drivers/media/rc/rc-core-priv.h   |   18 ++
 drivers/media/rc/rc-main.c|1 +
 include/media/rc-map.h|3 +-
 7 files changed, 482 insertions(+), 1 deletions(-)
 create mode 100644 drivers/media/rc/ir-mce_kbd-decoder.c

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 7d4bbc2..899f783 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -87,6 +87,17 @@ config IR_RC5_SZ_DECODER
   uses an IR protocol that is almost standard RC-5, but not quite,
   as it uses an additional bit).
 
+config IR_MCE_KBD_DECODER
+   tristate Enable IR raw decoder for the MCE keyboard/mouse protocol
+   depends on RC_CORE
+   select BITREVERSE
+   default y
+
+   ---help---
+  Enable this option if you have a Microsoft Remote Keyboard for
+  Windows Media Center Edition, which you would like to use with
+  a raw IR receiver in your system.
+
 config IR_LIRC_CODEC
tristate Enable IR to LIRC bridge
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 52830e5..f224db0 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
 obj-$(CONFIG_IR_JVC_DECODER) += ir-jvc-decoder.o
 obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o
 obj-$(CONFIG_IR_RC5_SZ_DECODER) += ir-rc5-sz-decoder.o
+obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
 obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
 
 # stand-alone IR receivers/transmitters
diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c 
b/drivers/media/rc/ir-mce_kbd-decoder.c
new file mode 100644
index 000..fe96e54
--- /dev/null
+++ b/drivers/media/rc/ir-mce_kbd-decoder.c
@@ -0,0 +1,448 @@
+/* ir-mce_kbd-decoder.c - A decoder for the RC6-ish keyboard/mouse IR protocol
+ * used by the Microsoft Remote Keyboard for Windows Media Center Edition,
+ * referred to by Microsoft's Windows Media Center remote specification docs
+ * as an internal protocol called MCIR-2.
+ *
+ * Copyright (C) 2011 by Jarod Wilson ja...@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 version 2 of the License.
+ *
+ * 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.
+ */
+
+#include rc-core-priv.h
+
+/*
+ * This decoder currently supports:
+ * - MCIR-2 29-bit IR signals used for mouse movement and buttons
+ * - MCIR-2 32-bit IR signals used for standard keyboard keys
+ *
+ * The media keys on the keyboard send RC-6

[PATCH 0/3] redrat3 driver updates for 3.1

[Jarod Wilson]

These changes make the redrat3 driver cooperate better with both in-kernel
and lirc userspace decoding of signals, tested with RC5, RC6 and NEC.
There's probably more we can do to make this a bit less hackish, but its
working quite well here for me right now.

Jarod Wilson (3):
  [media] redrat3: sending extra trailing space was useless
  [media] redrat3: cap duration in the right place
  [media] redrat3: improve compat with lirc userspace decode

 drivers/media/rc/redrat3.c |   61 ---
 1 files changed, 28 insertions(+), 33 deletions(-)

--
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/3] [media] redrat3: sending extra trailing space was useless

[Jarod Wilson]

We already add a trailing space, this wasn't doing anything useful, and
actually confused lirc userspace a bit. Rip it out.

CC: Chris Dodge ch...@redrat.co.uk
CC: Andrew Vincer andrew.vin...@redrat.co.uk
CC: Stephen Cox scox...@yahoo.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/redrat3.c |   12 +---
 1 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 5147767..9134254 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -414,20 +414,10 @@ static u32 redrat3_us_to_len(u32 microsec)
 
 }
 
-/* timer callback to send long trailing space on receive timeout */
+/* timer callback to send reset event */
 static void redrat3_rx_timeout(unsigned long data)
 {
struct redrat3_dev *rr3 = (struct redrat3_dev *)data;
-   DEFINE_IR_RAW_EVENT(rawir);
-
-   rawir.pulse = false;
-   rawir.duration = rr3-rc-timeout;
-   rr3_dbg(rr3-dev, storing trailing space with duration %d\n,
-   rawir.duration);
-   ir_raw_event_store_with_filter(rr3-rc, rawir);
-
-   rr3_dbg(rr3-dev, calling ir_raw_event_handle\n);
-   ir_raw_event_handle(rr3-rc);
 
rr3_dbg(rr3-dev, calling ir_raw_event_reset\n);
ir_raw_event_reset(rr3-rc);
-- 
1.7.1

--
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/3] [media] redrat3: cap duration in the right place

[Jarod Wilson]

Trying to cap duration before multiplying it was obviously wrong.

CC: Chris Dodge ch...@redrat.co.uk
CC: Andrew Vincer andrew.vin...@redrat.co.uk
CC: Stephen Cox scox...@yahoo.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/redrat3.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 9134254..5312e34 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -496,9 +496,6 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3)
u16 val = len_vals[data_vals[i]];
single_len = redrat3_len_to_us((u32)be16_to_cpu(val));
 
-   /* cap the value to IR_MAX_DURATION */
-   single_len = IR_MAX_DURATION;
-
/* we should always get pulse/space/pulse/space samples */
if (i % 2)
rawir.pulse = false;
@@ -506,6 +503,9 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3)
rawir.pulse = true;
 
rawir.duration = US_TO_NS(single_len);
+   /* cap the value to IR_MAX_DURATION */
+   rawir.duration = IR_MAX_DURATION;
+
rr3_dbg(dev, storing %s with duration %d (i: %d)\n,
rawir.pulse ? pulse : space, rawir.duration, i);
ir_raw_event_store_with_filter(rr3-rc, rawir);
-- 
1.7.1

--
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/3] [media] redrat3: improve compat with lirc userspace decode

[Jarod Wilson]

This is admittedly a bit of a hack, but if we change our timeout value
to something longer and fudge our synthesized trailing space sample
based on the initial pulse sample, rc-core decode continues to work just
fine with both rc-6 and rc-5, and now lirc userspace decode shows proper
repeats for both of those protocols as well. Also tested NEC
successfully with both decode options.

We do still need a reset timer callback using the hardware's timeout
value to make sure we actually process samples correctly, regardless of
our somewhat hacky timeout and synthesized trailer above.

This also adds a missing del_timer_sync call to the module unload path.

CC: Chris Dodge ch...@redrat.co.uk
CC: Andrew Vincer andrew.vin...@redrat.co.uk
CC: Stephen Cox scox...@yahoo.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/redrat3.c |   43 ---
 1 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 5312e34..5fc2f05 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -205,6 +205,7 @@ struct redrat3_dev {
 
/* rx signal timeout timer */
struct timer_list rx_timeout;
+   u32 hw_timeout;
 
/* Is the device currently receiving? */
bool recv_in_progress;
@@ -428,7 +429,7 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3)
DEFINE_IR_RAW_EVENT(rawir);
struct redrat3_signal_header header;
struct device *dev;
-   int i;
+   int i, trailer = 0;
unsigned long delay;
u32 mod_freq, single_len;
u16 *len_vals;
@@ -454,7 +455,8 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3)
if (!(header.length = RR3_HEADER_LENGTH))
dev_warn(dev, read returned less than rr3 header len\n);
 
-   delay = usecs_to_jiffies(rr3-rc-timeout / 1000);
+   /* Make sure we reset the IR kfifo after a bit of inactivity */
+   delay = usecs_to_jiffies(rr3-hw_timeout);
mod_timer(rr3-rx_timeout, jiffies + delay);
 
memcpy(tmp32, sig_data + RR3_PAUSE_OFFSET, sizeof(tmp32));
@@ -503,6 +505,9 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3)
rawir.pulse = true;
 
rawir.duration = US_TO_NS(single_len);
+   /* Save initial pulse length to fudge trailer */
+   if (i == 0)
+   trailer = rawir.duration;
/* cap the value to IR_MAX_DURATION */
rawir.duration = IR_MAX_DURATION;
 
@@ -515,7 +520,10 @@ static void redrat3_process_ir_data(struct redrat3_dev 
*rr3)
if (i % 2) {
rawir.pulse = false;
/* this duration is made up, and may not be ideal... */
-   rawir.duration = rr3-rc-timeout / 2;
+   if (trailer  US_TO_NS(1000))
+   rawir.duration = US_TO_NS(2800);
+   else
+   rawir.duration = trailer;
rr3_dbg(dev, storing trailing space with duration %d\n,
rawir.duration);
ir_raw_event_store_with_filter(rr3-rc, rawir);
@@ -619,36 +627,31 @@ static inline void redrat3_delete(struct redrat3_dev *rr3,
kfree(rr3);
 }
 
-static u32 redrat3_get_timeout(struct device *dev,
-  struct rc_dev *rc, struct usb_device *udev)
+static u32 redrat3_get_timeout(struct redrat3_dev *rr3)
 {
u32 *tmp;
-   u32 timeout = MS_TO_NS(150); /* a sane default, if things go haywire */
+   u32 timeout = MS_TO_US(150); /* a sane default, if things go haywire */
int len, ret, pipe;
 
len = sizeof(*tmp);
tmp = kzalloc(len, GFP_KERNEL);
if (!tmp) {
-   dev_warn(dev, Memory allocation faillure\n);
+   dev_warn(rr3-dev, Memory allocation faillure\n);
return timeout;
}
 
-   pipe = usb_rcvctrlpipe(udev, 0);
-   ret = usb_control_msg(udev, pipe, RR3_GET_IR_PARAM,
+   pipe = usb_rcvctrlpipe(rr3-udev, 0);
+   ret = usb_control_msg(rr3-udev, pipe, RR3_GET_IR_PARAM,
  USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
  RR3_IR_IO_SIG_TIMEOUT, 0, tmp, len, HZ * 5);
if (ret != len) {
-   dev_warn(dev, Failed to read timeout from hardware\n);
+   dev_warn(rr3-dev, Failed to read timeout from hardware\n);
return timeout;
}
 
-   timeout = US_TO_NS(redrat3_len_to_us(be32_to_cpu(*tmp)));
-   if (timeout  rc-min_timeout)
-   timeout = rc-min_timeout;
-   else if (timeout  rc-max_timeout)
-   timeout = rc-max_timeout;
+   timeout = redrat3_len_to_us(be32_to_cpu(*tmp));
 
-   rr3_dbg(dev, Got timeout of %d ms\n, timeout / (1000 * 1000));
+   rr3_dbg(rr3-dev, Got timeout of %d ms\n, timeout / 1000);
return

[PATCH] [media] imon: rate-limit send_packet spew

[Jarod Wilson]

There are folks with flaky imon hardware out there that doesn't always
respond to requests to write to their displays for some reason, which
can flood logs quickly when something like lcdproc is trying to
constantly update the display, so lets rate-limit all that error spew.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/imon.c |   25 +
 1 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 6bc35ee..ba48c1e 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -516,19 +516,19 @@ static int send_packet(struct imon_context *ictx)
if (retval) {
ictx-tx.busy = false;
smp_rmb(); /* ensure later readers know we're not busy */
-   pr_err(error submitting urb(%d)\n, retval);
+   pr_err_ratelimited(error submitting urb(%d)\n, retval);
} else {
/* Wait for transmission to complete (or abort) */
mutex_unlock(ictx-lock);
retval = wait_for_completion_interruptible(
ictx-tx.finished);
if (retval)
-   pr_err(task interrupted\n);
+   pr_err_ratelimited(task interrupted\n);
mutex_lock(ictx-lock);
 
retval = ictx-tx.status;
if (retval)
-   pr_err(packet tx failed (%d)\n, retval);
+   pr_err_ratelimited(packet tx failed (%d)\n, retval);
}
 
kfree(control_req);
@@ -830,20 +830,20 @@ static ssize_t vfd_write(struct file *file, const char 
*buf,
 
ictx = file-private_data;
if (!ictx) {
-   pr_err(no context for device\n);
+   pr_err_ratelimited(no context for device\n);
return -ENODEV;
}
 
mutex_lock(ictx-lock);
 
if (!ictx-dev_present_intf0) {
-   pr_err(no iMON device present\n);
+   pr_err_ratelimited(no iMON device present\n);
retval = -ENODEV;
goto exit;
}
 
if (n_bytes = 0 || n_bytes  32) {
-   pr_err(invalid payload size\n);
+   pr_err_ratelimited(invalid payload size\n);
retval = -EINVAL;
goto exit;
}
@@ -869,7 +869,7 @@ static ssize_t vfd_write(struct file *file, const char *buf,
 
retval = send_packet(ictx);
if (retval) {
-   pr_err(send packet failed for packet #%d\n, seq / 2);
+   pr_err_ratelimited(send packet #%d failed\n, seq / 2);
goto exit;
} else {
seq += 2;
@@ -883,7 +883,7 @@ static ssize_t vfd_write(struct file *file, const char *buf,
ictx-usb_tx_buf[7] = (unsigned char) seq;
retval = send_packet(ictx);
if (retval)
-   pr_err(send packet failed for packet #%d\n, seq / 2);
+   pr_err_ratelimited(send packet #%d failed\n, seq / 2);
 
 exit:
mutex_unlock(ictx-lock);
@@ -912,20 +912,21 @@ static ssize_t lcd_write(struct file *file, const char 
*buf,
 
ictx = file-private_data;
if (!ictx) {
-   pr_err(no context for device\n);
+   pr_err_ratelimited(no context for device\n);
return -ENODEV;
}
 
mutex_lock(ictx-lock);
 
if (!ictx-display_supported) {
-   pr_err(no iMON display present\n);
+   pr_err_ratelimited(no iMON display present\n);
retval = -ENODEV;
goto exit;
}
 
if (n_bytes != 8) {
-   pr_err(invalid payload size: %d (expected 8)\n, (int)n_bytes);
+   pr_err_ratelimited(invalid payload size: %d (expected 8)\n,
+  (int)n_bytes);
retval = -EINVAL;
goto exit;
}
@@ -937,7 +938,7 @@ static ssize_t lcd_write(struct file *file, const char *buf,
 
retval = send_packet(ictx);
if (retval) {
-   pr_err(send packet failed!\n);
+   pr_err_ratelimited(send packet failed!\n);
goto exit;
} else {
dev_dbg(ictx-dev, %s: write %d bytes to LCD\n,
-- 
1.7.1

--
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: Imon module Oops and kernel hang

[Jarod Wilson]

On Jul 13, 2011, at 1:42 AM, Chris W wrote:

 
 On 13/07/11 14:20, Jarod Wilson wrote:
 
 Chris W wrote:
 The rc keymap modules have been built (en masse as a result of
 CONFIG_RC_MAP=m) but I am not explicitly loading them and they do not
 get automatically loaded.
 
 Huh. That's unexpected. They get auto-loaded here, last I knew. I'll
 have to give one of my devices a spin tomorrow, not sure exactly what
 the last kernel I tried one of them on was. Pretty sure they're
 working fine with the Fedora 15 2.6.38.x kernels and vanilla (but
 Fedora-configured) 3.0-rc kernels though.
 
 
 I just ran depmod to make sure things were straight in this dept.
 
 kepler ~ # depmod -F System.map -e -av 2.6.39.3
 
 There are no reported errors.   The modules rc-imon-mce.ko,
 rc-imon-pad.ko and imon.ko depend only on rc-core.ko according to the
 output.  There don't seem to be any explicit dependencies to the keymaps
 (not a kernel dev so I don't know if there should be)

Yeah, imon depends on rc-core, and requests its keymap via rc-core, so
rc-core should then load up rc-imon-pad. Just tried on 3.0-rc7+ here,
and everything is happy:

[10791.866789] imon 3-2:1.0: usb_probe_interface
[10791.868944] imon 3-2:1.0: usb_probe_interface - got id
[10791.871332] input: iMON Panel, Knob and Mouse(15c2:0042) as 
/devices/pci:00/:00:03.1/usb3/3-2/3-2:1.0/input/input18
[10791.916037] Registered IR keymap rc-imon-pad
[10791.918709] input: iMON Remote (15c2:0042) as 
/devices/pci:00/:00:03.1/usb3/3-2/3-2:1.0/rc/rc6/input19
[10791.921331] rc6: iMON Remote (15c2:0042) as 
/devices/pci:00/:00:03.1/usb3/3-2/3-2:1.0/rc/rc6
[10791.930038] imon 3-2:1.0: iMON device (15c2:0042, intf0) on usb3:3 
initialized
[10791.932507] imon 3-2:1.1: usb_probe_interface
[10791.934949] imon 3-2:1.1: usb_probe_interface - got id
[10791.937416] imon 3-2:1.1: iMON device (15c2:0042, intf1) on usb3:3 
initialized
[10791.939996] usbcore: registered new interface driver imon

Just noticed your report is for 2.6.39.x and 2.6.38.x only, but I'm not
aware of any relevant imon changes between 2.6.39 and 3.0.

 Perhaps there something else in the kernel config that must be on in
 order to support the keymaps?
 
 Any other thoughts?
 
 Not at the moment. That T.889 line is... odd. No clue what the heck
 that thing is. Lemme see what I can see tomorrow (just past midnight
 here at the moment), if I don't hit anything, I might need a copy of
 your kernel config to repro.
 
 I can only see the T.889 string in the System.map, kernel binary and
 kernel/sched.o (but not the source?).  I have sent the config file
 off-list to Jarod.

Looks like I'll probably have to give that a spin, since I'm not seeing
the problem here (I can also switch to an 0xffdc device, which is actually
handled a bit differently by the 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

Re: Imon module Oops and kernel hang

[Jarod Wilson]

 kepler [c128ac16] uhci_scan_schedule+0x396/0x9a0
 Jul 12 09:44:20 kepler [c128cfd1] uhci_irq+0x91/0x170
 Jul 12 09:44:20 kepler [c1271de1] usb_hcd_irq+0x21/0x50
 Jul 12 09:44:20 kepler [c1051246] handle_irq_event_percpu+0x36/0x140
 Jul 12 09:44:20 kepler [c1015f06] ? __io_apic_modify_irq+0x76/0x90
 Jul 12 09:44:20 kepler [c1053000] ? handle_edge_irq+0x100/0x100
 Jul 12 09:44:20 kepler [c1051382] handle_irq_event+0x32/0x60
 Jul 12 09:44:20 kepler [c1053045] handle_fasteoi_irq+0x45/0xc0
 Jul 12 09:44:20 kepler IRQ
 Jul 12 09:44:20 kepler [c1003cea] ? do_IRQ+0x3a/0xb0
 Jul 12 09:44:20 kepler [c1089fcd] ? sys_read+0x3d/0x70
 Jul 12 09:44:20 kepler [c13d8d69] ? common_interrupt+0x29/0x30
 
 
 
 
 root@kepler # lsusb -v -d 15c2:ffdc
 Bus 004 Device 003: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller
 Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x15c2 SoundGraph Inc.
  idProduct  0xffdc iMON PAD Remote Controller
  bcdDevice0.00
  iManufacturer   0
  iProduct0
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   41
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 0 (Defined at Interface level)
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  ** UNRECOGNIZED:  09 21 00 01 00 01 22 25 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10
 Device Status: 0x
  (Bus Powered)
 
 
 
 # Kernel options from Media/RC
 #
 # Multimedia drivers
 #
 CONFIG_RC_CORE=m
 CONFIG_LIRC=m
 CONFIG_RC_MAP=m
 CONFIG_IR_NEC_DECODER=m
 CONFIG_IR_RC5_DECODER=m
 CONFIG_IR_RC6_DECODER=m
 CONFIG_IR_JVC_DECODER=m
 CONFIG_IR_SONY_DECODER=m
 CONFIG_IR_RC5_SZ_DECODER=m
 CONFIG_IR_LIRC_CODEC=m
 # CONFIG_IR_ENE is not set
 CONFIG_IR_IMON=m
 CONFIG_IR_MCEUSB=m
 # CONFIG_IR_ITE_CIR is not set
 # CONFIG_IR_NUVOTON is not set
 # CONFIG_IR_STREAMZAP is not set
 # CONFIG_IR_WINBOND_CIR is not set
 # CONFIG_RC_LOOPBACK is not set
 
 
 # cat /proc/cpuinfo
 processor: 0
 vendor_id: AuthenticAMD
 cpu family: 6
 model: 8
 model name: AMD Athlon(TM) XP 2400+
 stepping: 1
 cpu MHz: 2000.091
 cache size: 256 KB
 fdiv_bug: no
 hlt_bug: no
 f00f_bug: no
 coma_bug: no
 fpu: yes
 fpu_exception: yes
 cpuid level: 1
 wp: yes
 flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
 cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
 bogomips: 4000.18
 clflush size: 32
 cache_alignment: 32
 address sizes: 34 bits physical, 32 bits virtual
 power management: ts
 
 -- 
 Chris Williams
 Brisbane, Australia
 
 --
 
 
 ---
 ~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

-- 
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 PULL] last-minute IR fixes for 3.0

[Jarod Wilson]

Hey Mauro,

I know its late in the game, but after a weekend of testing here, and
feedback from other folks testing, I'd like to see if we can sneak a few
more minor changes into kernel 3.0. If not, these can probably all go in
via the stable tree later, but here they are... These changes greatly
improve the reliability of IR functionality for cx23885, mceusb and
nuvoton-cir users (the latter two primarily when using non-stock remotes
and lirc userspace decode -- RC5 and RC6 both work fine w/o this change).

The following changes since commit e3bbfa78bab125f58b831b5f7f45b5a305091d72:

  Merge branch 'hwmon-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging (2011-07-10 
10:24:47 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jarod/linux-2.6-ir.git/ for-3.0

Jarod Wilson (2):
  Revert V4L/DVB: cx23885: Enable Message Signaled Interrupts(MSI)
  [media] nuvoton-cir: make idle timeout more sane

Rafi Rubin (2):
  [media] mceusb: Timeout unit corrections
  [media] mceusb: increase default timeout to 100ms

 drivers/media/rc/mceusb.c  |9 +
 drivers/media/rc/nuvoton-cir.c |2 +-
 drivers/media/video/cx23885/cx23885-core.c |9 ++---
 3 files changed, 8 insertions(+), 12 deletions(-)

-- 
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: [git:v4l-dvb/for_v3.1] [media] rc: call input_sync after scancode reports

[Jarod Wilson]

On Thu, Jul 7, 2011 at 7:58 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 On Fri, Jul 01, 2011 at 09:34:45PM +0200, Mauro Carvalho Chehab wrote:
 This is an automatic generated email to let you know that the following 
 patch were queued at the
 http://git.linuxtv.org/media_tree.git tree:

 Subject: [media] rc: call input_sync after scancode reports
 Author:  Jarod Wilson ja...@redhat.com
 Date:    Thu Jun 23 10:40:55 2011 -0300

 Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only
 becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If
 we get a repeat or a scancode we don't have a mapping for, we never call
 input_sync, and thus those events don't get reported in a timely
 fashion.

 Hmm, any chance to get it into 3.0?

Its actually already there, I think the branch was just mis-named, or
something along those lines.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98c32bcded0e249fd48726930ae9f393e0e318b4


-- 
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

Re: [PATCH] [staging] lirc_serial: allocate irq at init time

[Jarod Wilson]

On Tue, Jul 5, 2011 at 1:21 PM, Greg KH g...@kroah.com wrote:
 On Thu, Jun 16, 2011 at 03:31:46PM -0400, Jarod Wilson wrote:
 There's really no good reason not to just grab the desired IRQ at driver
 init time, instead of every time the lirc device node is accessed. This
 also improves the speed and reliability with which a serial transmitter
 can operate, as back-to-back transmission attempts (i.e., channel change
 to a multi-digit channel) don't have to spend time acquiring and then
 releasing the IRQ for every digit, sometimes multiple times, if lircd
 has been told to use the min_repeat parameter.

 CC: de...@driverdev.osuosl.org
 Signed-off-by: Jarod Wilson ja...@redhat.com
 ---
  drivers/staging/lirc/lirc_serial.c |   44 
 +--
  1 files changed, 21 insertions(+), 23 deletions(-)

 This patch doesn't apply to the staging-next branch, care to respin it
 and resend it so I can apply it?

This actually got merged into mainline a few days ago via the media tree.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c4b0afee3c1730cf9b0f6ad21729928d23d3918e

Do you want me to take a look at what's in staging-next and fix that
up to apply on top of the above?

-- 
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

[PATCH] Revert V4L/DVB: cx23885: Enable Message Signaled Interrupts(MSI)

[Jarod Wilson]

This reverts commit e38030f3ff02684eb9e25e983a03ad318a10a2ea.

MSI flat-out doesn't work right on cx2388x devices yet. There are now
multiple reports of cards that hard-lock systems when MSI is enabled,
including my own HVR-1250 when trying to use its built-in IR receiver.
Disable MSI and it works just fine. Similar for another user's HVR-1270.
Issues have also been reported with the HVR-1850 when MSI is enabled,
and the 1850 behavior sounds similar to an as-yet-undiagnosed issue I've
seen with an 1800.

References:

http://www.spinics.net/lists/linux-media/msg25956.html
http://www.spinics.net/lists/linux-media/msg33676.html
http://www.spinics.net/lists/linux-media/msg34734.html

CC: Andy Walls awa...@md.metrocast.net
CC: Kusanagi Kouichi sl...@ac.auone-net.jp
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/video/cx23885/cx23885-core.c |9 ++---
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/media/video/cx23885/cx23885-core.c 
b/drivers/media/video/cx23885/cx23885-core.c
index 64d9b21..419777a 100644
--- a/drivers/media/video/cx23885/cx23885-core.c
+++ b/drivers/media/video/cx23885/cx23885-core.c
@@ -2060,12 +2060,8 @@ static int __devinit cx23885_initdev(struct pci_dev 
*pci_dev,
goto fail_irq;
}
 
-   if (!pci_enable_msi(pci_dev))
-   err = request_irq(pci_dev-irq, cx23885_irq,
- IRQF_DISABLED, dev-name, dev);
-   else
-   err = request_irq(pci_dev-irq, cx23885_irq,
- IRQF_SHARED | IRQF_DISABLED, dev-name, dev);
+   err = request_irq(pci_dev-irq, cx23885_irq,
+ IRQF_SHARED | IRQF_DISABLED, dev-name, dev);
if (err  0) {
printk(KERN_ERR %s: can't get IRQ %d\n,
   dev-name, pci_dev-irq);
@@ -2114,7 +2110,6 @@ static void __devexit cx23885_finidev(struct pci_dev 
*pci_dev)
 
/* unregister stuff */
free_irq(pci_dev-irq, dev);
-   pci_disable_msi(pci_dev);
 
cx23885_dev_unregister(dev);
v4l2_device_unregister(v4l2_dev);
-- 
1.7.1

--
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] Revert V4L/DVB: cx23885: Enable Message Signaled Interrupts(MSI)

[Jarod Wilson]

On Jun 29, 2011, at 7:35 PM, Andy Walls wrote:

 On Wed, 2011-06-29 at 17:49 -0400, Jarod Wilson wrote:
 This reverts commit e38030f3ff02684eb9e25e983a03ad318a10a2ea.
 
 MSI flat-out doesn't work right on cx2388x devices yet. There are now
 multiple reports of cards that hard-lock systems when MSI is enabled,
 including my own HVR-1250 when trying to use its built-in IR receiver.
 Disable MSI and it works just fine. Similar for another user's HVR-1270.
 Issues have also been reported with the HVR-1850 when MSI is enabled,
 and the 1850 behavior sounds similar to an as-yet-undiagnosed issue I've
 seen with an 1800.
 
 References:
 
 http://www.spinics.net/lists/linux-media/msg25956.html
 http://www.spinics.net/lists/linux-media/msg33676.html
 http://www.spinics.net/lists/linux-media/msg34734.html
 
 CC: Andy Walls awa...@md.metrocast.net
 
 Fine by me.
 
 Acked-by: Andy Walls awa...@md.metrocast.net
 
 but you should really
 
 Cc: Steven Toth st...@kernellabs.com

Crud, yeah, Steven was listed in the commit being reverted. Apologies,
rushed to get it out the door, heading out on vacation for a week
starting tomorrow. (Of course, I'm bringing a laptop and a few usb
devices with me...). :)

-- 
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

Re: HVR-1250/CX23885 IR Rx

[Jarod Wilson]

On Jun 28, 2011, at 6:30 AM, Andy Walls wrote:

 Jarod Wilson ja...@wilsonet.com wrote:
 
 On Apr 10, 2011, at 7:08 PM, Andy Walls wrote:
 
 On Sat, 2011-04-09 at 21:39 -0400, Jarod Wilson wrote:
 
 Jarod,
 
 The HVR-1850 uses a raw IR receiver in the CX23888 and older
 HVR-1250s use the raw IR receiver in the CX23885.  They both work
 for
 Rx (I need to tweak the Cx23885 rx watermark though), but I never
 found time to finish Tx (lack of kernel interface when I had time).
 
 If you obtain one of these I can answer any driver questions.
 
 Quite some time back, I bought an HVR-1800 and an HVR-1250. I know
 one of
 them came with an mceusb transceiver and remote, as was pretty sure
 it was
 the 1800. For some reason, I didn't recall the 1250 coming with
 anything at
 all, but looking at dmesg output for it:
 
 cx23885 driver version 0.0.2 loaded
 cx23885 :03:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
 CORE cx23885[0]: subsystem: 0070:7911, board: Hauppauge
 WinTV-HVR1250 [card=3,autodetected]
 tveeprom 0-0050: Hauppauge model 79001, rev E3D9, serial# 4904656
 tveeprom 0-0050: MAC address is 00:0d:fe:4a:d6:d0
 tveeprom 0-0050: tuner model is Microtune MT2131 (idx 139, type 4)
 tveeprom 0-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88)
 tveeprom 0-0050: audio processor is CX23885 (idx 39)
 tveeprom 0-0050: decoder processor is CX23885 (idx 33)
 tveeprom 0-0050: has no radio, has IR receiver, has no IR
 transmitter
 
 So it seems I do have hardware. However, its one of the two tuner
 cards in
 my production mythtv backend right now, making it a bit hard to do
 any
 experimenting with. If I can get it out of there, it looks like I
 just add
 an enable_885_ir=1, and I should be able to poke at it...
 
 Yeah.  Igor's TeVii S470 CX23885 based card had interrupt storms when
 enabled, so IR for '885 chips is disabled by default.  To
 investigate, I
 tried to by an HVR-1250 with a CX23885, but instead got an HVR-1275
 with
 a CX23888.  dandel, on IRC, did a pretty decent job in testing
 HVR-1250
 operation and finding it works, despite climbing kernel
 build/development learning curve at the time.
 ...
 
 Finally got some time to play with my 1250, dug out its rx cable, turns
 out to
 be the same one I special-ordered to work on the 1150 Devin sent me.
 Oops.
 Anyway. First impressions, not so good. Got a panic on boot, somewhere
 in
 cx23885_video_irq, iirc, when booting with enable_885_ir=1 set.
 However, dmesg
 was somewhere in the middle of cx18 init of the HVR-1600 in the box.
 Dunno if
 there's any way that's actually directly related, but I yanked the
 1600. After
 doing that, the box managed to boot fine, but then while testing
 w/ir-keytable
 and an RC-6 remote, I got what I think was the same panic -- definitely
 the
 cx23885_video_irq bit in the trace, something about sleeping while
 atomic, IP
 at mwait_idle. (On the plus side, IR did seem to be working before
 that).
 
 Note also that this is a 2.6.32-based kernel with a 2.6.38-era backport
 of the
 driver code, because that's what was on this box. Was about to put it
 back into
 production use, but hey, its summer, there's nothing really for it to
 record
 for another few months, so I'll keep it out and throw it into another
 box with
 a newer kernel and serial console, etc., so I can further debug...
 
 In a very early version of the CX23885 IR changes I made the mistake of 
 performing I2C transactions in an interrupt handler.  That has been fixed in 
 cx23885 for quite some time though.  It also required some I2C fixes in 
 cx25840-core.c IIRC, which again, has been fixed for some time.

Up and running on 3.0-rc5 now, and I'm not seeing the panic, but the
box keeps hard-locking after some number of keypresses. Can't get a
peep out of it with sysrq, nmi watchdog doesn't seem to fire, etc.

At the suggestion of Dark Shadow, I've also tried booting the box
with pci=nomsi. Works a treat then. Since his HVR-1270 and my HVR-1250
both behave much better with pci=nomsi, I'm thinking that in the
short-term, we should probably make sure msi doesn't get enabled in
the cx23885 driver, and longer-term, we can look at fixing it.

-- 
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

Re: HVR-1250/CX23885 IR Rx

[Jarod Wilson]

On Jun 28, 2011, at 6:32 PM, Andy Walls wrote:

 On Tue, 2011-06-28 at 17:39 -0400, Jarod Wilson wrote:
 
 Up and running on 3.0-rc5 now, and I'm not seeing the panic, but the
 box keeps hard-locking after some number of keypresses. Can't get a
 peep out of it with sysrq, nmi watchdog doesn't seem to fire, etc.
 
 At the suggestion of Dark Shadow, I've also tried booting the box
 with pci=nomsi. Works a treat then. Since his HVR-1270 and my HVR-1250
 both behave much better with pci=nomsi, I'm thinking that in the
 short-term, we should probably make sure msi doesn't get enabled in
 the cx23885 driver, and longer-term, we can look at fixing it.
 
 Sounds fine.  But fixcing the cx23885 driver to deal with both PCIe
 emulation of legacy PCI INTx and PCIe MSI will likely be very involved.
 (Maybe I'm wrong?)

I'm not sure either, but I know a few PCI gurus at work who could
probably lend some insight.


 Taking a trip down memory lane to 2 Dec 2010...
 http://www.spinics.net/lists/linux-media/msg25956.html

Man. I really gotta learn to search the list archive (and bugzillas
assigned to me...) before sending mail to the list, eh? ;)


 On Wed, 2010-12-01 at 21:52 -0800, David Liontooth wrote:
 On 11/29/2010 04:38 AM, Andy Walls wrote:
 On Sun, 2010-11-28 at 23:49 -0800, David Liontooth wrote:
 
 For a quick band-aid, use pci=nomsi on your kernel command line, and
 reboot to reset the CX23888 hardware.
 
 The problem is MSI.  The cx23885 driver isn't ready for it.  The patch
 that enabled MSI for cx23885 probably needs to be reverted until some of
 these issues are sorted out.
 
 -- what do we lose by removing the MSI support patch?
 
 Problems mostly. The driver was written to work with emulated legacy PCI
 INTx interrupts, which are to be treated as level triggered, and not
 PCIe MSI, which are to be treated as edge triggered.  That's why I say
 the cx23885 driver isn't ready for MSI, but I'm not sure how involved an
 audit and conversion would be.  I know an audit will take time and
 expertise.

Dropping msi support looks to be quite trivial, I got the card behaving
after only a few lines of change in cx23885-core.c without having to pass
in pci=nomsi, but I *only* tried IR, I haven't tried video capture. I'll
see if I can give that a spin tomorrow, and if that behaves, I can send
along the diff. If we wanted to get really fancy, I could add a modparam
to let people turn msi back on. (Never had a single issue with this card
recording with msi enabled, only IR seems busted).

Just had another thought though... I have an HVR-1800 that *does* have
issues recording, and the way the video is corrupted, its possible that
its msi-related... Will have to keep that in mind next time I poke at it.

-- 
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

Re: cx18 init lockdep spew

[Jarod Wilson]

On Jun 24, 2011, at 5:34 PM, Andy Walls wrote:

 On Fri, 2011-06-24 at 13:39 -0400, Jarod Wilson wrote:
 I only just recently acquired a Hauppauge HVR-1600 cards, and at least both
 2.6.39 and 3.0-rc4 kernels with copious debug spew enabled spit out the
 lockdep spew included below. Haven't looked into it at all yet, but I
 thought I'd ask before I do if it is already a known issue.
 
 Why, yes, it is.  See comments 11-13 of this bug assigned to Jarod
 Wilson in Dec 2010:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=662384
 
 Also please ask ja...@redhat.com to send you some off-list emails he
 received from me on 21-22 Dec 2010.
 
 ;)
 
 
 Oh, look, some nice fellow submitted a patch to get rid of the false
 alarms:
 
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg26097.html
 https://patchwork.kernel.org/patch/431311/
 
 ;)

Hahahaha, *facepalm*. I forgot all about that, but its suddenly coming
rushing back to me. :)


 I'm not sure if it still applies cleanly, but it's not that hard to
 grok.  The lockdep happiness comes from the lock being initialized in a
 macro.  That is what's critical to spread all lock instances from one
 class into many individual classes for lockdep.
 
 
 The issue is the control handling framework creates instances where the
 bridge driver acquires its own control handler lock and subsequently a
 subdev driver lock (or maybe the other way around).  Since the framework
 instantiated all the handler locks in the same common function, lockdep
 considers them one class and can't/won't think of them as different.
 
 
 
 If you don't like my patch above, you can try some magic lockdep calls
 in v4l2_ctrl_add_handler() to make lockdep ignore that particular
 recursion for the hdl-lock lock class (for a depth of 1?), knowing
 that it is allowed.
 
 For reference:
 
 http://lkml.org/lkml/2009/9/2/83
 
 I'm pretty sure mutex_lock_nested(...-lock, 1) is what we needed  in
 v4l2_ctrl_add_handler().
 
 
 Here is a DVB and I2C related use of mutex_lock_nested() that was added
 some years ago:
 
 http://www.jikos.cz/~jikos/dev/lockdep_fix_recursive_i2c_transfer.patch
 
 It is different from our current use case, in that the lock ordering
 relationship was well defined.  I think that I2C lock class recursion in
 DVB could have been solved better with lock class annotations vs.
 nesting.

Cool, thanks, I'll try to give it a closer look this week...

-- 
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

cx18 init lockdep spew

[Jarod Wilson]

 adapter (cx18)
[   13.157923] MXL5005S: Attached at address 0x63
[   13.159569] DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB 
Frontend)...
[   13.161557] cx18-0: DVB Frontend registered
[   13.163239] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
[   13.165079] cx18-0: Registered device video32 for encoder YUV (20 x 101.25 
kB)
[   13.166889] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes)
[   13.168708] cx18-0: Registered device video24 for encoder PCM audio (256 x 
4.00 kB)
[   13.170407] cx18-0: Initialized card: Hauppauge HVR-1600
[   13.172251] cx18:  End initialization
[   13.387206] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
[   13.551919] cx18-0: loaded v4l-cx23418-apu.fw firmware V0012 (141200 
bytes)
[   13.560280] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
[   13.571169] cx18-alsa: module loading...
[   14.477034] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
[   14.503906] cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 
bytes)

-- 
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 PULL] IR Fixups for 3.0

[Jarod Wilson]

Hi Mauro,

There are quite a few patches here, but they're all fairly small targeted
fixes, all worth pushing into 3.0 if we can. The last patch in the series
is the most critical one, it fixes a fairly significant problem with key
repeats, introduced by a core input layer change (evdev won't allow
reading data until there's an EV_SYN).

Nb: I sent a prior pull req on June 4 that had the first 11 patches in
this stack, not sure if that was already pulled, but I think I recall you
saying your scripts would handle things just fine if there were changes
included that you'd already pulled...

Thanks much,

The following changes since commit 56299378726d5f2ba8d3c8cbbd13cb280ba45e4f:

  Linux 3.0-rc4 (2011-06-20 20:25:46 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/jarod/linux-2.6-ir.git/ for-3.0

Jarod Wilson (20):
  [media] mceusb: add and use mce_dbg printk macro
  [media] mceusb: support I-O Data GV-MC7/RCKIT
  [media] mceusb: mce_sync_in is brain-dead
  [staging] lirc_imon: fix unused-but-set warnings
  [staging] lirc_sir: fix unused-but-set warnings
  [media] lirc_dev: store cdev in irctl, up maxdevs
  [media] fintek-cir: make suspend with active IR more reliable
  [media] nuvoton-cir: in_use isn't actually in use, remove it
  [media] mceusb: plug memory leak on data transmit
  [media] imon: support for 0x46 0xffdc imon vfd
  [media] imon: fix initial panel key repeat suppression
  [media] ite-cir: 8709 needs to use pnp resource 2
  [media] keymaps: fix table for pinnacle pctv hd devices
  [media] lirc_zilog: fix spinning rx thread
  [staging] lirc_serial: allocate irq at init time
  [media] rc: fix ghost keypresses with certain hw
  [media] saa7134: fix raw IR timeout value
  [media] imon: auto-config ffdc 7e device
  [media] imon: allow either proto on unknown 0xffdc
  [media] rc: call input_sync after scancode reports

 drivers/media/rc/fintek-cir.c  |5 ++
 drivers/media/rc/imon.c|   19 +-
 drivers/media/rc/ir-raw.c  |4 +-
 drivers/media/rc/ite-cir.c |   12 +++-
 drivers/media/rc/ite-cir.h |3 +
 drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c |   58 -
 drivers/media/rc/lirc_dev.c|   37 ---
 drivers/media/rc/mceusb.c  |   80 +++
 drivers/media/rc/nuvoton-cir.c |2 -
 drivers/media/rc/nuvoton-cir.h |1 -
 drivers/media/rc/rc-main.c |2 +
 drivers/media/video/saa7134/saa7134-input.c|2 +-
 drivers/staging/lirc/lirc_imon.c   |   10 +---
 drivers/staging/lirc/lirc_serial.c |   44 ++---
 drivers/staging/lirc/lirc_sir.c|   11 +---
 drivers/staging/lirc/lirc_zilog.c  |4 +-
 include/media/lirc_dev.h   |2 +-
 17 files changed, 159 insertions(+), 137 deletions(-)

-- 
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

[PATCH] [media] rc: call input_sync after scancode reports

[Jarod Wilson]

Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only
becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If
we get a repeat or a scancode we don't have a mapping for, we never call
input_sync, and thus those events don't get reported in a timely
fashion.

For example, take an mceusb transceiver with a default rc6 keymap. Press
buttons on an rc5 remote while monitoring with ir-keytable, and you'll
see nothing. Now press a button on the rc6 remote matching the keymap.
You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6
key spit out all at the same time.

Pressing and holding a button on a remote we do have a keymap for also
works rather unreliably right now, due to repeat events also happening
without a call to input_sync (we bail from ir_do_keydown before getting
to the point where it calls input_sync).

Easy fix though, just add two strategically placed input_sync calls
right after our input_event calls for EV_MSC, and all is well again.
Technically, we probably should have been doing this all along, its just
that it never caused any function difference until the referenced change
went into the input layer.

Reported-by: Stephan Raue sr...@openelec.tv
CC: Mauro Carvalho Chehab mche...@redhat.com
CC: Jeff Brown jeffbr...@android.com
CC: Dmitry Torokhov d...@mail.ru
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/rc-main.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index f57cd56..c25c243 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -597,6 +597,7 @@ void rc_repeat(struct rc_dev *dev)
spin_lock_irqsave(dev-keylock, flags);
 
input_event(dev-input_dev, EV_MSC, MSC_SCAN, dev-last_scancode);
+   input_sync(dev-input_dev);
 
if (!dev-keypressed)
goto out;
@@ -623,6 +624,7 @@ static void ir_do_keydown(struct rc_dev *dev, int scancode,
  u32 keycode, u8 toggle)
 {
input_event(dev-input_dev, EV_MSC, MSC_SCAN, scancode);
+   input_sync(dev-input_dev);
 
/* Repeat event? */
if (dev-keypressed 
-- 
1.7.1

--
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: Last key repeated after every keypress on remote control (saa7134 lirc devinput driver)

[Jarod Wilson]

On Jun 7, 2011, at 12:04 PM, Jarod Wilson wrote:

 On Jun 7, 2011, at 2:45 AM, Radim wrote:
 
 
  Pôvodná správa 
 Od: Jarod Wilson ja...@redhat.com
 Predmet: Re: Last key repeated after every keypress on remote control 
 (saa7134
 lirc devinput driver)
 Dátum: 06.6.2011 20:39:50
 
 Devin Heitmueller wrote:
 On Mon, Jun 6, 2011 at 2:13 PM, Radimradim...@seznam.cz  wrote:
 Hello to everybody,
 I was redirected here from lirc mailinglist (reason is at the end).
 
 I'm asking for any help because I wasn't able to solve
 this problem by my self (and google of course).
 
 When I'm testing lirc configuration using irw, last pressed key is 
 repeated
 just befor the new one:
 
 after pressing key 1:
 80010002 00 KEY_1 devinput
 
 after pressing key 2:
 80010002 00 KEY_1 devinput
 80010003 00 KEY_2 devinput
 
 after pressing key 3:
 80010003 00 KEY_2 devinput
 80010004 00 KEY_3 devinput
 
 after pressing key 4:
 80010004 00 KEY_3 devinput
 80010005 00 KEY_4 devinput
 
 after pressing key 5:
 80010005 00 KEY_4 devinput
 80010006 00 KEY_5 devinput
 
 
 My configuration:
 Archlinux (allways up-to-date)
 Asus MyCinema P7131 with remote control PC-39
 lircd 0.9.0, driver devinput, default config file lirc.conf.devinput
 kernel 2.6.38
 
 # ir-keytable
 Found /sys/class/rc/rc0/ (/dev/input/event5) with:
   Driver saa7134, table rc-asus-pc39
   Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC
   Enabled protocols: RC-5
   Repeat delay = 500 ms, repeat period = 33 ms
 
 Answare from lirc-mainlinglist (Jarod Wilson):
 Looks like a bug in saa7134-input.c, which doesn't originate in lirc land,
 its from the kernel itself. The more apropos location to tackle this issue
 is linux-media@vger.kernel.org.
 
 I can provide any other listings, just ask for them.
 
 Thank you for any help,
 Radim
 
 I actually sent Jarod a board specifically to investigate this issue
 (the same issue occurs on the saa7134 based HVR-1150).  I believe it's
 on his TODO list.
 Yep, he chopped out the part of my reply where I said as much. :)
 Just waiting on the IR receiver cable to arrive, could well be here in 
 today's mail...
 
 Oh, I misunderstood Jarod answer - he pointed me to this list as a right 
 place for posting this possible bug in saa7134 driver, so I sent it also 
 here. I was thinking that this is not a job for member of lirc developers, 
 so I was trying luck here..
 
 I work on both lirc and media tree drivers. In this case, lircd is doing
 exactly the right thing with the data its being fed, the bug is in the
 kernel driver, which is from the media tree. Best to discuss the bug on
 the list for the layer at which it exists. :)
 
 (No cable yet, still awaiting its arrival).

Forgot to reply in this thread. Patch was posted last week that fixes
the repeat problem on the HVR-1150 Devin sent me. Best as I can tell
from looking at the saa7134 code and the particulars for your hardware,
that fix should solve your repeat issue as well.

-- 
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

Re: [PATCH] [media] rc: call input_sync after scancode reports

[Jarod Wilson]

Dmitry Torokhov wrote:

Hi Jarod,

On Thu, Jun 23, 2011 at 01:58:06PM -0400, Jarod Wilson wrote:

@@ -623,6 +624,7 @@ static void ir_do_keydown(struct rc_dev *dev, int scancode,
  u32 keycode, u8 toggle)
  {
input_event(dev-input_dev, EV_MSC, MSC_SCAN, scancode);
+   input_sync(dev-input_dev);

/* Repeat event? */
if (dev-keypressed


It looks like we would be issuing up to 3 input_sync() for a single
keypress... Order of events is wrong too (we first issue MSC_SCAN for
new key and then release old key). How about we change it a bit like in
the patch below?


Yeah, your patch does result in a nicer overall flow of things (esp. the 
ordering of the release, which I hadn't noticed), and eliminates the 
extra unnecessary syncs. I've got one tiny tweak, where I just pass a 
true/false to ir_do_keyup to say whether or not it should do a sync to 
further reduce some code duplication. Building and testing here locally 
to make sure it does behave as expected, will then send it along.


--
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

[PATCH v2] [media] rc: call input_sync after scancode reports

[Jarod Wilson]

Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only
becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If
we get a repeat or a scancode we don't have a mapping for, we never call
input_sync, and thus those events don't get reported in a timely
fashion.

For example, take an mceusb transceiver with a default rc6 keymap. Press
buttons on an rc5 remote while monitoring with ir-keytable, and you'll
see nothing. Now press a button on the rc6 remote matching the keymap.
You'll suddenly get the rc5 key scancodes, the rc6 scancode and the rc6
key spit out all at the same time.

Pressing and holding a button on a remote we do have a keymap for also
works rather unreliably right now, due to repeat events also happening
without a call to input_sync (we bail from ir_do_keydown before getting
to the point where it calls input_sync).

Easy fix though, just add two strategically placed input_sync calls
right after our input_event calls for EV_MSC, and all is well again.
Technically, we probably should have been doing this all along, its just
that it never caused any functional difference until the referenced
change went into the input layer.

v2: rework code a bit, per Dmitry's example, so that we only call
input_sync once per IR signal. There was another hidden bug in the code
where we were calling input_report_key using last_keycode instead of our
just discovered keycode, which manifested with the reordering of calling
input_report_key and setting last_keycode.

Reported-by: Stephan Raue sr...@openelec.tv
CC: Stephan Raue sr...@openelec.tv
CC: Mauro Carvalho Chehab mche...@redhat.com
CC: Jeff Brown jeffbr...@android.com
CC: Dmitry Torokhov d...@mail.ru
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/rc-main.c |   48 ++-
 1 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index f57cd56..3186ac7 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -522,18 +522,20 @@ EXPORT_SYMBOL_GPL(rc_g_keycode_from_table);
 /**
  * ir_do_keyup() - internal function to signal the release of a keypress
  * @dev:   the struct rc_dev descriptor of the device
+ * @sync:  whether or not to call input_sync
  *
  * This function is used internally to release a keypress, it must be
  * called with keylock held.
  */
-static void ir_do_keyup(struct rc_dev *dev)
+static void ir_do_keyup(struct rc_dev *dev, bool sync)
 {
if (!dev-keypressed)
return;
 
IR_dprintk(1, keyup key 0x%04x\n, dev-last_keycode);
input_report_key(dev-input_dev, dev-last_keycode, 0);
-   input_sync(dev-input_dev);
+   if (sync)
+   input_sync(dev-input_dev);
dev-keypressed = false;
 }
 
@@ -549,7 +551,7 @@ void rc_keyup(struct rc_dev *dev)
unsigned long flags;
 
spin_lock_irqsave(dev-keylock, flags);
-   ir_do_keyup(dev);
+   ir_do_keyup(dev, true);
spin_unlock_irqrestore(dev-keylock, flags);
 }
 EXPORT_SYMBOL_GPL(rc_keyup);
@@ -578,7 +580,7 @@ static void ir_timer_keyup(unsigned long cookie)
 */
spin_lock_irqsave(dev-keylock, flags);
if (time_is_before_eq_jiffies(dev-keyup_jiffies))
-   ir_do_keyup(dev);
+   ir_do_keyup(dev, true);
spin_unlock_irqrestore(dev-keylock, flags);
 }
 
@@ -597,6 +599,7 @@ void rc_repeat(struct rc_dev *dev)
spin_lock_irqsave(dev-keylock, flags);
 
input_event(dev-input_dev, EV_MSC, MSC_SCAN, dev-last_scancode);
+   input_sync(dev-input_dev);
 
if (!dev-keypressed)
goto out;
@@ -622,29 +625,28 @@ EXPORT_SYMBOL_GPL(rc_repeat);
 static void ir_do_keydown(struct rc_dev *dev, int scancode,
  u32 keycode, u8 toggle)
 {
-   input_event(dev-input_dev, EV_MSC, MSC_SCAN, scancode);
-
-   /* Repeat event? */
-   if (dev-keypressed 
-   dev-last_scancode == scancode 
-   dev-last_toggle == toggle)
-   return;
+   bool new_event = !dev-keypressed ||
+dev-last_scancode != scancode ||
+dev-last_toggle != toggle;
 
-   /* Release old keypress */
-   ir_do_keyup(dev);
+   if (new_event  dev-keypressed)
+   ir_do_keyup(dev, false);
 
-   dev-last_scancode = scancode;
-   dev-last_toggle = toggle;
-   dev-last_keycode = keycode;
+   input_event(dev-input_dev, EV_MSC, MSC_SCAN, scancode);
 
-   if (keycode == KEY_RESERVED)
-   return;
+   if (new_event  keycode != KEY_RESERVED) {
+   /* Register a keypress */
+   dev-keypressed = true;
+   dev-last_scancode = scancode;
+   dev-last_toggle = toggle;
+   dev-last_keycode = keycode;
+
+   IR_dprintk(1, %s: key down event, 
+  key 0x%04x, scancode 0x%04x\n

[PATCH] [media] rc: fix ghost keypresses with certain hw

[Jarod Wilson]

With hardware that has to use ir_raw_event_store_edge to collect IR
sample durations, we were not doing an event reset unless
IR_MAX_DURATION had passed. That's around 4 seconds. So if someone
presses up, then down, with less than 4 seconds in between, they'd get
the initial up, then up and down upon pressing down.

To fix this, I've lowered the send a reset event logic's threshold to
the input device's REP_DELAY (defaults to 500ms), and with an
saa7134-based GPIO-driven IR receiver in a Hauppauge HVR-1150, I get
*much* better behavior out of the remote now. Special thanks to Devin
for providing the hardware to investigate this issue.

CC: Devin Heitmueller dheitmuel...@kernellabs.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/ir-raw.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/media/rc/ir-raw.c b/drivers/media/rc/ir-raw.c
index f4efd2f..27808bb 100644
--- a/drivers/media/rc/ir-raw.c
+++ b/drivers/media/rc/ir-raw.c
@@ -114,18 +114,20 @@ int ir_raw_event_store_edge(struct rc_dev *dev, enum 
raw_event_type type)
s64 delta; /* ns */
DEFINE_IR_RAW_EVENT(ev);
int rc = 0;
+   int delay;
 
if (!dev-raw)
return -EINVAL;
 
now = ktime_get();
delta = ktime_to_ns(ktime_sub(now, dev-raw-last_event));
+   delay = MS_TO_NS(dev-input_dev-rep[REP_DELAY]);
 
/* Check for a long duration since last event or if we're
 * being called for the first time, note that delta can't
 * possibly be negative.
 */
-   if (delta  IR_MAX_DURATION || !dev-raw-last_type)
+   if (delta  delay || !dev-raw-last_type)
type |= IR_START_EVENT;
else
ev.duration = delta;
-- 
1.7.1

--
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] [staging] lirc_serial: allocate irq at init time

[Jarod Wilson]

There's really no good reason not to just grab the desired IRQ at driver
init time, instead of every time the lirc device node is accessed. This
also improves the speed and reliability with which a serial transmitter
can operate, as back-to-back transmission attempts (i.e., channel change
to a multi-digit channel) don't have to spend time acquiring and then
releasing the IRQ for every digit, sometimes multiple times, if lircd
has been told to use the min_repeat parameter.

CC: de...@driverdev.osuosl.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_serial.c |   44 +--
 1 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/lirc/lirc_serial.c 
b/drivers/staging/lirc/lirc_serial.c
index 1c3099b..805df91 100644
--- a/drivers/staging/lirc/lirc_serial.c
+++ b/drivers/staging/lirc/lirc_serial.c
@@ -838,7 +838,23 @@ static int hardware_init_port(void)
 
 static int init_port(void)
 {
-   int i, nlow, nhigh;
+   int i, nlow, nhigh, result;
+
+   result = request_irq(irq, irq_handler,
+IRQF_DISABLED | (share_irq ? IRQF_SHARED : 0),
+LIRC_DRIVER_NAME, (void *)hardware);
+
+   switch (result) {
+   case -EBUSY:
+   printk(KERN_ERR LIRC_DRIVER_NAME : IRQ %d busy\n, irq);
+   return -EBUSY;
+   case -EINVAL:
+   printk(KERN_ERR LIRC_DRIVER_NAME
+  : Bad irq number or handler\n);
+   return -EINVAL;
+   default:
+   break;
+   };
 
/* Reserve io region. */
/*
@@ -893,34 +909,17 @@ static int init_port(void)
printk(KERN_INFO LIRC_DRIVER_NAME  : Manually using active 
   %s receiver\n, sense ? low : high);
 
+   dprintk(Interrupt %d, port %04x obtained\n, irq, io);
return 0;
 }
 
 static int set_use_inc(void *data)
 {
-   int result;
unsigned long flags;
 
/* initialize timestamp */
do_gettimeofday(lasttv);
 
-   result = request_irq(irq, irq_handler,
-IRQF_DISABLED | (share_irq ? IRQF_SHARED : 0),
-LIRC_DRIVER_NAME, (void *)hardware);
-
-   switch (result) {
-   case -EBUSY:
-   printk(KERN_ERR LIRC_DRIVER_NAME : IRQ %d busy\n, irq);
-   return -EBUSY;
-   case -EINVAL:
-   printk(KERN_ERR LIRC_DRIVER_NAME
-  : Bad irq number or handler\n);
-   return -EINVAL;
-   default:
-   dprintk(Interrupt %d, port %04x obtained\n, irq, io);
-   break;
-   };
-
spin_lock_irqsave(hardware[type].lock, flags);
 
/* Set DLAB 0. */
@@ -945,10 +944,6 @@ static void set_use_dec(void *data)
soutp(UART_IER, sinp(UART_IER) 
  (~(UART_IER_MSI|UART_IER_RLSI|UART_IER_THRI|UART_IER_RDI)));
spin_unlock_irqrestore(hardware[type].lock, flags);
-
-   free_irq(irq, (void *)hardware);
-
-   dprintk(freed IRQ %d\n, irq);
 }
 
 static ssize_t lirc_write(struct file *file, const char *buf,
@@ -1256,6 +1251,9 @@ exit_serial_exit:
 static void __exit lirc_serial_exit_module(void)
 {
lirc_serial_exit();
+
+   free_irq(irq, (void *)hardware);
+
if (iommap != 0)
release_mem_region(iommap, 8  ioshift);
else
-- 
1.7.1

--
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] [media] saa7134: fix raw IR timeout value

[Jarod Wilson]

The comment says wait 15ms, but the code says jiffies_to_msecs(15)
instead of msecs_to_jiffies(15). Fix that. Tested, works fine with both
rc5 and rc6 decode, in-kernel and via lirc userspace, with an HVR-1150.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/video/saa7134/saa7134-input.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/saa7134/saa7134-input.c 
b/drivers/media/video/saa7134/saa7134-input.c
index ff6c0e9..d4ee24b 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -963,7 +963,7 @@ static int saa7134_raw_decode_irq(struct saa7134_dev *dev)
 * to work with other protocols.
 */
if (!ir-active) {
-   timeout = jiffies + jiffies_to_msecs(15);
+   timeout = jiffies + msecs_to_jiffies(15);
mod_timer(ir-timer, timeout);
ir-active = true;
}
-- 
1.7.1

--
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] [media] rc-core support for Microsoft IR keyboard/mouse

[Jarod Wilson]

On Jun 11, 2011, at 9:38 AM, Mauro Carvalho Chehab wrote:

 Em 03-06-2011 18:28, Jarod Wilson escreveu:
 This is a custom IR protocol decoder, for the RC-6-ish protocol used by
 the Microsoft Remote Keyboard.
 
 http://www.amazon.com/Microsoft-Remote-Keyboard-Windows-ZV1-4/dp/B000AOAAN8
 
 Its a standard keyboard with embedded thumb stick mouse pointer and
 mouse buttons, along with a number of media keys. The media keys are
 standard RC-6, identical to the signals from the stock MCE remotes, and
 will be handled as such. The keyboard and mouse signals will be decoded
 and delivered to the system by an input device registered specifically
 by this driver.
 
 Successfully tested with an mceusb-driven receiver, but this should
 actually work with any raw IR rc-core receiver.
 
 This work is inspired by lirc_mod_mce:
 
 http://mod-mce.sourceforge.net/
 
 The documentation there and code aided in understanding and decoding the
 protocol, but the bulk of the code is actually borrowed more from the
 existing in-kernel decoders than anything. I did recycle the keyboard
 keycode table and a few defines from lirc_mod_mce though.
 
 Signed-off-by: Jarod Wilson ja...@redhat.com
 ---
 
 I did only a quick review, and everything looks fine for me. Just two 
 comments:
 
 +#if 0
 +/* Adding this reference means two input devices are associated with
 + * this rc-core device, which ir-keytable doesn't cope with yet */
 +idev-dev.parent = dev-dev;
 +#endif
 
 Well, it was never tested with such config ;)

D'oh, I meant to mention that #if 0...


 Feel free to fix rc-core.

It wasn't actually rc-core that complained, it was ir-keytable that spit out
a message about not being able to handle an rc device with multiple input
devices, but the fix may well require both userspace and kernelspace changes...


 +static unsigned char kbd_keycodes[256] = {
 +  0,   0,   0,   0,  30,  48,  46,  32,  18,  33,  34,  35,  23,  
 36,  37,  38,
 + 50,  49,  24,  25,  16,  19,  31,  20,  22,  47,  17,  45,  21,  
 44,   2,   3,
 +  4,   5,   6,   7,   8,   9,  10,  11,  28,   1,  14,  15,  57,  
 12,  13,  26,
 + 27,  43,  43,  39,  40,  41,  51,  52,  53,  58,  59,  60,  61,  
 62,  63,  64,
 + 65,  66,  67,  68,  87,  88,  99,  70, 119, 110, 102, 104, 111, 
 107, 109, 106,
 +105, 108, 103,  69,  98,  55,  74,  78,  96,  79,  80,  81,  75,  
 76,  77,  71,
 + 72,  73,  82,  83,  86, 127, 116, 117, 183, 184, 185, 186, 187, 
 188, 189, 190,
 +191, 192, 193, 194, 134, 138, 130, 132, 128, 129, 131, 137, 133, 
 135, 136, 113,
 +115, 114,   0,   0,   0, 121,   0,  89,  93, 124,  92,  94,  95,   
 0,   0,   0,
 +122, 123,  90,  91,  85,   0,   0,   0,   0,   0,   0,   0,   0,   
 0,   0,   0,
 +  0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   
 0,   0,   0,
 +  0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   
 0,   0,   0,
 +  0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   
 0,   0,   0,
 +  0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   
 0,   0,   0,
 + 29,  42,  56, 125,  97,  54, 100, 126, 164, 166, 165, 163, 161, 
 115, 114, 113,
 +150, 158, 159, 128, 136, 177, 178, 176, 142, 152, 173, 140
 +};
 
 This table looks weird to me: too much magic numbers there. Shouldn't
 the above be replaced by KEY_* definitions?

Yeah, probably. The above is basically the same convention as hid_keyboard in
drivers/hid/hid-input.c, but that doesn't mean we can't strive to do better. ;)


 PS.: I would like to have one of those keyboards, in order to test some 
 things here,
 in special, for the xorg input/event proposal on my TODO list ;) Is it a 
 cheap device?
 I may try to buy one the next time I would travel to US.

Looks like Amazon has them listed for less than $40USD right now, but they're
becoming increasingly hard to find, as I believe they're discontinued. Don't
know if I've ever seen them in a brick-n-mortar store anywhere. I should really
get one for myself, I have to send this one back to the guy who loaned it to me.
I could just make it a double order and stash one on the shelf for ya.

-- 
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

[PATCH] [media] ite-cir: 8709 needs to use pnp resource 2

[Jarod Wilson]

Thanks to the intrepid testing and debugging of Matthijs van Drunen, it
was uncovered that at least some variants of the ITE8709 need to use pnp
resource 2, rather than 0, for things to function properly. Resource 0
has a length of only 1, and if you try to bypass the pnp_port_len check
and use it anyway (with either a length of 1 or 2), the system in
question's trackpad ceased to function.

The circa lirc 0.8.7 lirc_ite8709 driver used resource 2, but the value
was (amusingly) changed to 0 by way of a patch from ITE themselves, so I
don't know if there may be variants where 0 actually *is* correct, but
at least in this case and in the original lirc_ite8709 driver author's
case, it sure looks like 2 is the right value.

This fix should probably be applied to all stable kernels with the
ite-cir driver, lest we nuke more people's trackpads.

Tested-by: Matthijs van Drunen
CC: Juan Jesús García de Soria skanda...@gmail.com
CC: sta...@kernel.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/ite-cir.c |   12 +---
 drivers/media/rc/ite-cir.h |3 +++
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index e716b93..ecd3d02 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1347,6 +1347,7 @@ static const struct ite_dev_params ite_dev_descs[] = {
{   /* 0: ITE8704 */
   .model = ITE8704 CIR transceiver,
   .io_region_size = IT87_IOREG_LENGTH,
+  .io_rsrc_no = 0,
   .hw_tx_capable = true,
   .sample_period = (u32) (10ULL / 115200),
   .tx_carrier_freq = 38000,
@@ -1371,6 +1372,7 @@ static const struct ite_dev_params ite_dev_descs[] = {
{   /* 1: ITE8713 */
   .model = ITE8713 CIR transceiver,
   .io_region_size = IT87_IOREG_LENGTH,
+  .io_rsrc_no = 0,
   .hw_tx_capable = true,
   .sample_period = (u32) (10ULL / 115200),
   .tx_carrier_freq = 38000,
@@ -1395,6 +1397,7 @@ static const struct ite_dev_params ite_dev_descs[] = {
{   /* 2: ITE8708 */
   .model = ITE8708 CIR transceiver,
   .io_region_size = IT8708_IOREG_LENGTH,
+  .io_rsrc_no = 0,
   .hw_tx_capable = true,
   .sample_period = (u32) (10ULL / 115200),
   .tx_carrier_freq = 38000,
@@ -1420,6 +1423,7 @@ static const struct ite_dev_params ite_dev_descs[] = {
{   /* 3: ITE8709 */
   .model = ITE8709 CIR transceiver,
   .io_region_size = IT8709_IOREG_LENGTH,
+  .io_rsrc_no = 2,
   .hw_tx_capable = true,
   .sample_period = (u32) (10ULL / 115200),
   .tx_carrier_freq = 38000,
@@ -1461,6 +1465,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct 
pnp_device_id
struct rc_dev *rdev = NULL;
int ret = -ENOMEM;
int model_no;
+   int io_rsrc_no;
 
ite_dbg(%s called, __func__);
 
@@ -1490,10 +1495,11 @@ static int ite_probe(struct pnp_dev *pdev, const struct 
pnp_device_id
 
/* get the description for the device */
dev_desc = ite_dev_descs[model_no];
+   io_rsrc_no = dev_desc-io_rsrc_no;
 
/* validate pnp resources */
-   if (!pnp_port_valid(pdev, 0) ||
-   pnp_port_len(pdev, 0) != dev_desc-io_region_size) {
+   if (!pnp_port_valid(pdev, io_rsrc_no) ||
+   pnp_port_len(pdev, io_rsrc_no) != dev_desc-io_region_size) {
dev_err(pdev-dev, IR PNP Port not valid!\n);
goto failure;
}
@@ -1504,7 +1510,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct 
pnp_device_id
}
 
/* store resource values */
-   itdev-cir_addr = pnp_port_start(pdev, 0);
+   itdev-cir_addr = pnp_port_start(pdev, io_rsrc_no);
itdev-cir_irq = pnp_irq(pdev, 0);
 
/* initialize spinlocks */
diff --git a/drivers/media/rc/ite-cir.h b/drivers/media/rc/ite-cir.h
index 16a19f5..aa899a0 100644
--- a/drivers/media/rc/ite-cir.h
+++ b/drivers/media/rc/ite-cir.h
@@ -57,6 +57,9 @@ struct ite_dev_params {
/* size of the I/O region */
int io_region_size;
 
+   /* IR pnp I/O resource number */
+   int io_rsrc_no;
+
/* true if the hardware supports transmission */
bool hw_tx_capable;
 
-- 
1.7.1

--
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] [media] keymaps: fix table for pinnacle pctv hd devices

[Jarod Wilson]

Both consumers of RC_MAP_PINNACLE_PCTV_HD send along full RC-5
scancodes, so this update makes this keymap actually *have* full
scancodes, heisted from rc-dib0700-rc5.c. This should fix out of the box
remote functionality for the Pinnacle PCTV HD 800i (cx88 pci card) and
PCTV HD Pro 801e (em28xx usb stick).

CC: sta...@kernel.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c |   58 +++-
 1 files changed, 27 insertions(+), 31 deletions(-)

diff --git a/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c 
b/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c
index bb10ffe..8d558ae 100644
--- a/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c
+++ b/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c
@@ -15,43 +15,39 @@
 /* Pinnacle PCTV HD 800i mini remote */
 
 static struct rc_map_table pinnacle_pctv_hd[] = {
-
-   { 0x0f, KEY_1 },
-   { 0x15, KEY_2 },
-   { 0x10, KEY_3 },
-   { 0x18, KEY_4 },
-   { 0x1b, KEY_5 },
-   { 0x1e, KEY_6 },
-   { 0x11, KEY_7 },
-   { 0x21, KEY_8 },
-   { 0x12, KEY_9 },
-   { 0x27, KEY_0 },
-
-   { 0x24, KEY_ZOOM },
-   { 0x2a, KEY_SUBTITLE },
-
-   { 0x00, KEY_MUTE },
-   { 0x01, KEY_ENTER },/* Pinnacle Logo */
-   { 0x39, KEY_POWER },
-
-   { 0x03, KEY_VOLUMEUP },
-   { 0x09, KEY_VOLUMEDOWN },
-   { 0x06, KEY_CHANNELUP },
-   { 0x0c, KEY_CHANNELDOWN },
-
-   { 0x2d, KEY_REWIND },
-   { 0x30, KEY_PLAYPAUSE },
-   { 0x33, KEY_FASTFORWARD },
-   { 0x3c, KEY_STOP },
-   { 0x36, KEY_RECORD },
-   { 0x3f, KEY_EPG },  /* Labeled ? */
+   /* Key codes for the tiny Pinnacle remote*/
+   { 0x0700, KEY_MUTE },
+   { 0x0701, KEY_MENU }, /* Pinnacle logo */
+   { 0x0739, KEY_POWER },
+   { 0x0703, KEY_VOLUMEUP },
+   { 0x0709, KEY_VOLUMEDOWN },
+   { 0x0706, KEY_CHANNELUP },
+   { 0x070c, KEY_CHANNELDOWN },
+   { 0x070f, KEY_1 },
+   { 0x0715, KEY_2 },
+   { 0x0710, KEY_3 },
+   { 0x0718, KEY_4 },
+   { 0x071b, KEY_5 },
+   { 0x071e, KEY_6 },
+   { 0x0711, KEY_7 },
+   { 0x0721, KEY_8 },
+   { 0x0712, KEY_9 },
+   { 0x0727, KEY_0 },
+   { 0x0724, KEY_ZOOM }, /* 'Square' key */
+   { 0x072a, KEY_SUBTITLE },   /* 'T' key */
+   { 0x072d, KEY_REWIND },
+   { 0x0730, KEY_PLAYPAUSE },
+   { 0x0733, KEY_FASTFORWARD },
+   { 0x0736, KEY_RECORD },
+   { 0x073c, KEY_STOP },
+   { 0x073f, KEY_HELP }, /* '?' key */
 };
 
 static struct rc_map_list pinnacle_pctv_hd_map = {
.map = {
.scan= pinnacle_pctv_hd,
.size= ARRAY_SIZE(pinnacle_pctv_hd),
-   .rc_type = RC_TYPE_UNKNOWN, /* Legacy IR type */
+   .rc_type = RC_TYPE_RC5,
.name= RC_MAP_PINNACLE_PCTV_HD,
}
 };
-- 
1.7.1

--
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] [media] lirc_zilog: fix spinning rx thread

[Jarod Wilson]

We were calling schedule_timeout with the rx thread's task state still
at TASK_RUNNING, which it shouldn't be. Make sure we call
set_current_state(TASK_INTERRUPTIBLE) *before* schedule_timeout, and
we're all good here. I believe this problem was mistakenly introduced in
commit 5bd6b0464b68d429bc8a3fe6595d19c39dfc4d95, and I'm not sure how I
missed it before, as I swear I tested the patchset that was included in,
but alas, stuff happens...

CC: Andy Walls awa...@md.metrocast.net
CC: sta...@kernel.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_zilog.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lirc/lirc_zilog.c 
b/drivers/staging/lirc/lirc_zilog.c
index dd6a57c..4e051f6 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -475,14 +475,14 @@ static int lirc_thread(void *arg)
dprintk(poll thread started\n);
 
while (!kthread_should_stop()) {
+   set_current_state(TASK_INTERRUPTIBLE);
+
/* if device not opened, we can sleep half a second */
if (atomic_read(ir-open_count) == 0) {
schedule_timeout(HZ/2);
continue;
}
 
-   set_current_state(TASK_INTERRUPTIBLE);
-
/*
 * This is ~113*2 + 24 + jitter (2*repeat gap + code length).
 * We use this interval as the chip resets every time you poll
-- 
1.7.1

--
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: Last key repeated after every keypress on remote control (saa7134 lirc devinput driver)

[Jarod Wilson]

On Jun 7, 2011, at 2:45 AM, Radim wrote:

 
  Pôvodná správa 
 Od: Jarod Wilson ja...@redhat.com
 Predmet: Re: Last key repeated after every keypress on remote control 
 (saa7134
 lirc devinput driver)
 Dátum: 06.6.2011 20:39:50
 
 Devin Heitmueller wrote:
  On Mon, Jun 6, 2011 at 2:13 PM, Radimradim...@seznam.cz  wrote:
  Hello to everybody,
  I was redirected here from lirc mailinglist (reason is at the end).
 
  I'm asking for any help because I wasn't able to solve
  this problem by my self (and google of course).
 
  When I'm testing lirc configuration using irw, last pressed key is 
  repeated
  just befor the new one:
 
  after pressing key 1:
  80010002 00 KEY_1 devinput
 
  after pressing key 2:
  80010002 00 KEY_1 devinput
  80010003 00 KEY_2 devinput
 
  after pressing key 3:
  80010003 00 KEY_2 devinput
  80010004 00 KEY_3 devinput
 
  after pressing key 4:
  80010004 00 KEY_3 devinput
  80010005 00 KEY_4 devinput
 
  after pressing key 5:
  80010005 00 KEY_4 devinput
  80010006 00 KEY_5 devinput
 
 
  My configuration:
  Archlinux (allways up-to-date)
  Asus MyCinema P7131 with remote control PC-39
  lircd 0.9.0, driver devinput, default config file lirc.conf.devinput
  kernel 2.6.38
 
  # ir-keytable
  Found /sys/class/rc/rc0/ (/dev/input/event5) with:
 Driver saa7134, table rc-asus-pc39
 Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC
 Enabled protocols: RC-5
 Repeat delay = 500 ms, repeat period = 33 ms
 
  Answare from lirc-mainlinglist (Jarod Wilson):
  Looks like a bug in saa7134-input.c, which doesn't originate in lirc land,
  its from the kernel itself. The more apropos location to tackle this issue
  is linux-media@vger.kernel.org.
 
  I can provide any other listings, just ask for them.
 
  Thank you for any help,
  Radim
 
  I actually sent Jarod a board specifically to investigate this issue
  (the same issue occurs on the saa7134 based HVR-1150).  I believe it's
  on his TODO list.
 Yep, he chopped out the part of my reply where I said as much. :)
 Just waiting on the IR receiver cable to arrive, could well be here in 
 today's mail...
 
 Oh, I misunderstood Jarod answer - he pointed me to this list as a right 
 place for posting this possible bug in saa7134 driver, so I sent it also 
 here. I was thinking that this is not a job for member of lirc developers, so 
 I was trying luck here..

I work on both lirc and media tree drivers. In this case, lircd is doing
exactly the right thing with the data its being fed, the bug is in the
kernel driver, which is from the media tree. Best to discuss the bug on
the list for the layer at which it exists. :)

(No cable yet, still awaiting its arrival).

-- 
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

Re: [PATCH] [media] rc-core support for Microsoft IR keyboard/mouse

[Jarod Wilson]

On Jun 3, 2011, at 5:28 PM, Jarod Wilson wrote:

 This is a custom IR protocol decoder, for the RC-6-ish protocol used by
 the Microsoft Remote Keyboard.
 
 http://www.amazon.com/Microsoft-Remote-Keyboard-Windows-ZV1-4/dp/B000AOAAN8
 
 Its a standard keyboard with embedded thumb stick mouse pointer and
 mouse buttons, along with a number of media keys. The media keys are
 standard RC-6, identical to the signals from the stock MCE remotes, and
 will be handled as such. The keyboard and mouse signals will be decoded
 and delivered to the system by an input device registered specifically
 by this driver.
 
 Successfully tested with an mceusb-driven receiver, but this should
 actually work with any raw IR rc-core receiver.
 
 This work is inspired by lirc_mod_mce:
 
 http://mod-mce.sourceforge.net/
 
 The documentation there and code aided in understanding and decoding the
 protocol, but the bulk of the code is actually borrowed more from the
 existing in-kernel decoders than anything. I did recycle the keyboard
 keycode table and a few defines from lirc_mod_mce though.

Nb: this should more or less be considered as an RFC.

One thing I already know I need/want to add is a timer callback to make
sure we don't get stuck keys due to missing a release event signal.

The main area of contention though is over how the keyboard/mouse device is
set up. Currently, if you have three raw rc-core IR receivers in your system,
you get three separate keyboard/mouse event devices, stored inside
rc_dev-raw-mce_kbd-idev. I *think* this is the right way to do this, but
one could argue that the decoder should just have a single input_dev within
the decoder itself, which is used to feed along signals from any raw IR device.

The other question is whether or not this module should be loaded by default
when rc-core is initialized. The current implementation means this is loaded,
and input devices are set up for every raw IR device, and I doubt the vast
majority of people with raw IR receivers actually have this keyboard.

-- 
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