[PATCH 3/8] [media] lirc: LIRC_{G,S}ET_SEND_MODE fail if device cannot transmit

2016-12-02 Thread Sean Young
These ioctls should not succeed if the device cannot send. Also make it
clear that these ioctls should return the lirc mode, although the actual
value does not change.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/ir-lirc-codec.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index c327730..9e41305 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -204,11 +204,17 @@ static long ir_lirc_ioctl(struct file *filep, unsigned 
int cmd,
 
/* legacy support */
case LIRC_GET_SEND_MODE:
-   val = LIRC_CAN_SEND_PULSE & LIRC_CAN_SEND_MASK;
+   if (!dev->tx_ir)
+   return -ENOTTY;
+
+   val = LIRC_MODE_PULSE;
break;
 
case LIRC_SET_SEND_MODE:
-   if (val != (LIRC_MODE_PULSE & LIRC_CAN_SEND_MASK))
+   if (!dev->tx_ir)
+   return -ENOTTY;
+
+   if (val != LIRC_MODE_PULSE)
return -EINVAL;
return 0;
 
-- 
2.9.3

--
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/8] [media] rc: allow software timeout to be set

2016-12-02 Thread Sean Young
Both the iguanair and the technotrend usb ir do not do any timeout
handling in hardware, so timeout is entirely done in
ir_raw_event_store_with_filter(). Any sensible timeout value will
do, so allow it to be set using LIRC_SET_REC_TIMEOUT.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/iguanair.c | 4 +++-
 drivers/media/rc/ttusbir.c  | 5 -
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index 5f63454..139a09c 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -504,7 +504,9 @@ static int iguanair_probe(struct usb_interface *intf,
rc->tx_ir = iguanair_tx;
rc->driver_name = DRIVER_NAME;
rc->map_name = RC_MAP_RC6_MCE;
-   rc->timeout = MS_TO_NS(100);
+   rc->min_timeout = 1;
+   rc->timeout = IR_DEFAULT_TIMEOUT;
+   rc->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
rc->rx_resolution = RX_RESOLUTION;
 
iguanair_set_tx_carrier(rc, 38000);
diff --git a/drivers/media/rc/ttusbir.c b/drivers/media/rc/ttusbir.c
index bc214e2..8393014 100644
--- a/drivers/media/rc/ttusbir.c
+++ b/drivers/media/rc/ttusbir.c
@@ -322,7 +322,10 @@ static int ttusbir_probe(struct usb_interface *intf,
rc->priv = tt;
rc->driver_name = DRIVER_NAME;
rc->map_name = RC_MAP_TT_1500;
-   rc->timeout = MS_TO_NS(100);
+   rc->min_timeout = 1;
+   rc->timeout = IR_DEFAULT_TIMEOUT;
+   rc->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
+
/*
 * The precision is NS_PER_BIT, but since every 8th bit can be
 * overwritten with garbage the accuracy is at best 2 * NS_PER_BIT.
-- 
2.9.3

--
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/8] [media] lirc_dev: LIRC_{G,S}ET_REC_MODE do not work

2016-12-02 Thread Sean Young
Since "273b902 [media] lirc_dev: use LIRC_CAN_REC() define" these
ioctls no longer work.

Signed-off-by: Sean Young <s...@mess.org>
Cc: Andi Shyti <andi.sh...@samsung.com>
Cc: <sta...@vger.kernel.org> # v4.8+
---
 drivers/media/rc/lirc_dev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 3854809..7f5d109 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -582,7 +582,7 @@ long lirc_dev_fop_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
result = put_user(ir->d.features, (__u32 __user *)arg);
break;
case LIRC_GET_REC_MODE:
-   if (LIRC_CAN_REC(ir->d.features)) {
+   if (!LIRC_CAN_REC(ir->d.features)) {
result = -ENOTTY;
break;
}
@@ -592,7 +592,7 @@ long lirc_dev_fop_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
  (__u32 __user *)arg);
break;
case LIRC_SET_REC_MODE:
-   if (LIRC_CAN_REC(ir->d.features)) {
+   if (!LIRC_CAN_REC(ir->d.features)) {
result = -ENOTTY;
break;
}
-- 
2.9.3

--
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/8] [media] rc5x: document that this is the 20 bit variant

2016-12-02 Thread Sean Young
There are many variants of extended rc5. This implements the 20 bit
version.

Signed-off-by: Sean Young <s...@mess.org>
Cc: David Härdeman <da...@hardeman.nu>
---
 drivers/media/rc/ir-rc5-decoder.c | 6 +++---
 drivers/media/rc/rc-main.c| 2 +-
 include/media/rc-map.h| 8 
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/media/rc/ir-rc5-decoder.c 
b/drivers/media/rc/ir-rc5-decoder.c
index a95477c..484185e 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -124,7 +124,7 @@ static int ir_rc5_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
if (data->is_rc5x && data->count == RC5X_NBITS) {
/* RC5X */
u8 xdata, command, system;
-   if (!(dev->enabled_protocols & RC_BIT_RC5X)) {
+   if (!(dev->enabled_protocols & RC_BIT_RC5X_20)) {
data->state = STATE_INACTIVE;
return 0;
}
@@ -134,7 +134,7 @@ static int ir_rc5_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
toggle   = (data->bits & 0x2) ? 1 : 0;
command += (data->bits & 0x4) ? 0 : 0x40;
scancode = system << 16 | command << 8 | xdata;
-   protocol = RC_TYPE_RC5X;
+   protocol = RC_TYPE_RC5X_20;
 
} else if (!data->is_rc5x && data->count == RC5_NBITS) {
/* RC5 */
@@ -182,7 +182,7 @@ static int ir_rc5_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
 }
 
 static struct ir_raw_handler rc5_handler = {
-   .protocols  = RC_BIT_RC5 | RC_BIT_RC5X | RC_BIT_RC5_SZ,
+   .protocols  = RC_BIT_RC5 | RC_BIT_RC5X_20 | RC_BIT_RC5_SZ,
.decode = ir_rc5_decode,
 };
 
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index dedaf38..75bdc49 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -796,7 +796,7 @@ static const struct {
{ RC_BIT_OTHER, "other",NULL},
{ RC_BIT_UNKNOWN,   "unknown",  NULL},
{ RC_BIT_RC5 |
- RC_BIT_RC5X,  "rc-5", "ir-rc5-decoder"},
+ RC_BIT_RC5X_20,   "rc-5", "ir-rc5-decoder"},
{ RC_BIT_NEC |
  RC_BIT_NECX |
  RC_BIT_NEC32, "nec",  "ir-nec-decoder"},
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index e1cc14c..39c00ef 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -17,7 +17,7 @@
  * @RC_TYPE_UNKNOWN: Protocol not known
  * @RC_TYPE_OTHER: Protocol known but proprietary
  * @RC_TYPE_RC5: Philips RC5 protocol
- * @RC_TYPE_RC5X: Philips RC5x protocol
+ * @RC_TYPE_RC5X_20: Philips RC5x 20 bit protocol
  * @RC_TYPE_RC5_SZ: StreamZap variant of RC5
  * @RC_TYPE_JVC: JVC protocol
  * @RC_TYPE_SONY12: Sony 12 bit protocol
@@ -41,7 +41,7 @@ enum rc_type {
RC_TYPE_UNKNOWN = 0,
RC_TYPE_OTHER   = 1,
RC_TYPE_RC5 = 2,
-   RC_TYPE_RC5X= 3,
+   RC_TYPE_RC5X_20 = 3,
RC_TYPE_RC5_SZ  = 4,
RC_TYPE_JVC = 5,
RC_TYPE_SONY12  = 6,
@@ -66,7 +66,7 @@ enum rc_type {
 #define RC_BIT_UNKNOWN (1ULL << RC_TYPE_UNKNOWN)
 #define RC_BIT_OTHER   (1ULL << RC_TYPE_OTHER)
 #define RC_BIT_RC5 (1ULL << RC_TYPE_RC5)
-#define RC_BIT_RC5X(1ULL << RC_TYPE_RC5X)
+#define RC_BIT_RC5X_20 (1ULL << RC_TYPE_RC5X_20)
 #define RC_BIT_RC5_SZ  (1ULL << RC_TYPE_RC5_SZ)
 #define RC_BIT_JVC (1ULL << RC_TYPE_JVC)
 #define RC_BIT_SONY12  (1ULL << RC_TYPE_SONY12)
@@ -87,7 +87,7 @@ enum rc_type {
 #define RC_BIT_CEC (1ULL << RC_TYPE_CEC)
 
 #define RC_BIT_ALL (RC_BIT_UNKNOWN | RC_BIT_OTHER | \
-RC_BIT_RC5 | RC_BIT_RC5X | RC_BIT_RC5_SZ | \
+RC_BIT_RC5 | RC_BIT_RC5X_20 | RC_BIT_RC5_SZ | \
 RC_BIT_JVC | \
 RC_BIT_SONY12 | RC_BIT_SONY15 | RC_BIT_SONY20 | \
 RC_BIT_NEC | RC_BIT_NECX | RC_BIT_NEC32 | \
-- 
2.9.3

--
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/8] [media] em28xx: IR protocol not reported correctly

2016-12-02 Thread Sean Young
Report the correct NEC variant.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/usb/em28xx/em28xx-input.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-input.c 
b/drivers/media/usb/em28xx/em28xx-input.c
index a1904e2..a9a7f16 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -259,18 +259,21 @@ static int em2874_polling_getkey(struct em28xx_IR *ir,
break;
 
case RC_BIT_NEC:
-   poll_result->protocol = RC_TYPE_RC5;
poll_result->scancode = msg[1] << 8 | msg[2];
-   if ((msg[3] ^ msg[4]) != 0xff)  /* 32 bits NEC */
+   if ((msg[3] ^ msg[4]) != 0xff) {/* 32 bits NEC */
+   poll_result->protocol = RC_TYPE_NEC32;
poll_result->scancode = RC_SCANCODE_NEC32((msg[1] << 
24) |
  (msg[2] << 
16) |
  (msg[3] << 8) 
 |
  (msg[4]));
-   else if ((msg[1] ^ msg[2]) != 0xff) /* 24 bits NEC */
+   } else if ((msg[1] ^ msg[2]) != 0xff) { /* 24 bits NEC */
+   poll_result->protocol = RC_TYPE_NECX;
poll_result->scancode = RC_SCANCODE_NECX(msg[1] << 8 |
 msg[2], 
msg[3]);
-   else/* Normal NEC */
+   } else {/* Normal NEC */
+   poll_result->protocol = RC_TYPE_NEC;
poll_result->scancode = RC_SCANCODE_NEC(msg[1], msg[3]);
+   }
break;
 
case RC_BIT_RC6_0:
@@ -775,7 +778,7 @@ static int em28xx_ir_init(struct em28xx *dev)
case CHIP_ID_EM28178:
ir->get_key = em2874_polling_getkey;
rc->allowed_protocols = RC_BIT_RC5 | RC_BIT_NEC |
-RC_BIT_RC6_0;
+   RC_BIT_NECX | RC_BIT_NEC32 | RC_BIT_RC6_0;
break;
default:
err = -ENODEV;
-- 
2.9.3

--
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/8] [media] mceusb: LIRC_SET_SEND_CARRIER returns 0 on success

2016-12-02 Thread Sean Young
LIRC_SET_SEND_CARRIER ioctl should not return the carrier used, it
should return 0.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/mceusb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 9bf6917..96b0ade 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -890,7 +890,7 @@ static int mceusb_set_tx_carrier(struct rc_dev *dev, u32 
carrier)
cmdbuf[3] = MCE_IRDATA_TRAILER;
dev_dbg(ir->dev, "disabling carrier modulation");
mce_async_out(ir, cmdbuf, sizeof(cmdbuf));
-   return carrier;
+   return 0;
}
 
for (prescaler = 0; prescaler < 4; ++prescaler) {
@@ -904,7 +904,7 @@ static int mceusb_set_tx_carrier(struct rc_dev *dev, u32 
carrier)
 
/* Transmit new carrier to mce device */
mce_async_out(ir, cmdbuf, sizeof(cmdbuf));
-   return carrier;
+   return 0;
}
}
 
-- 
2.9.3

--
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/8] [media] serial_ir: generate timeout

2016-12-02 Thread Sean Young
No timeout is generated by serial_ir since the port only generates
interrupts on edges. Some IR protocols like rc6 and rc5 need a trailing
space or timeout so they know there are no more bits coming.

Without it, the current key will only be reported once some more IR
occurs.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/serial_ir.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
index 436bd58..2cb6471 100644
--- a/drivers/media/rc/serial_ir.c
+++ b/drivers/media/rc/serial_ir.c
@@ -137,6 +137,7 @@ struct serial_ir {
ktime_t lastkt;
struct rc_dev *rcdev;
struct platform_device *pdev;
+   struct timer_list timeout_timer;
 
unsigned int freq;
unsigned int duty_cycle;
@@ -395,9 +396,14 @@ static irqreturn_t serial_ir_irq_handler(int i, void *blah)
frbwrite(data, !(dcd ^ sense));
serial_ir.lastkt = kt;
last_dcd = dcd;
-   ir_raw_event_handle(serial_ir.rcdev);
}
} while (!(sinp(UART_IIR) & UART_IIR_NO_INT)); /* still pending ? */
+
+   mod_timer(_ir.timeout_timer,
+ jiffies + nsecs_to_jiffies(serial_ir.rcdev->timeout));
+
+   ir_raw_event_handle(serial_ir.rcdev);
+
return IRQ_HANDLED;
 }
 
@@ -471,6 +477,16 @@ static int hardware_init_port(void)
return 0;
 }
 
+static void serial_ir_timeout(unsigned long arg)
+{
+   DEFINE_IR_RAW_EVENT(ev);
+
+   ev.timeout = true;
+   ev.duration = serial_ir.rcdev->timeout;
+   ir_raw_event_store_with_filter(serial_ir.rcdev, );
+   ir_raw_event_handle(serial_ir.rcdev);
+}
+
 static int serial_ir_probe(struct platform_device *dev)
 {
int i, nlow, nhigh, result;
@@ -500,6 +516,9 @@ static int serial_ir_probe(struct platform_device *dev)
return -EBUSY;
}
 
+   setup_timer(_ir.timeout_timer, serial_ir_timeout,
+   (unsigned long)_ir);
+
result = hardware_init_port();
if (result < 0)
return result;
@@ -781,7 +800,9 @@ static int __init serial_ir_init_module(void)
rcdev->allowed_protocols = RC_BIT_ALL;
rcdev->driver_name = KBUILD_MODNAME;
rcdev->map_name = RC_MAP_RC6_MCE;
+   rcdev->min_timeout = 1;
rcdev->timeout = IR_DEFAULT_TIMEOUT;
+   rcdev->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
rcdev->rx_resolution = 25;
 
serial_ir.rcdev = rcdev;
@@ -797,6 +818,7 @@ static int __init serial_ir_init_module(void)
 
 static void __exit serial_ir_exit_module(void)
 {
+   del_timer_sync(_ir.timeout_timer);
rc_unregister_device(serial_ir.rcdev);
serial_ir_exit();
 }
-- 
2.9.3

--
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 FOR v4.10] lirc cdev fixes for 4.10

2016-11-29 Thread Sean Young
Hi Mauro,

Just one fix to prevent double free or NULL deref in error path.

Thanks,
Sean

The following changes since commit a000f0d3995f622410d433a01e94fbfb45969e27:

  [media] vivid: Set color_enc on HSV formats (2016-11-29 12:12:32 -0200)

are available in the git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.10

for you to fetch changes up to 90a0560777a72ea91b0fb1147264614dd236853c:

  [media] lirc: fix error paths in lirc_cdev_add() (2016-11-29 20:05:25 +)


Sean Young (1):
  [media] lirc: fix error paths in lirc_cdev_add()

 drivers/media/rc/lirc_dev.c | 8 +++-
 1 file changed, 3 insertions(+), 5 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


Re: ir-keytable: infinite loops, segfaults

2016-11-27 Thread Sean Young
On Fri, Nov 25, 2016 at 07:59:21PM +1100, Vincent McIntyre wrote:
> On 11/25/16, Sean Young <s...@mess.org> wrote:
> >
> > So if I understand you correctly, if you change the keymap, like you
> > changed 0xfe47 to KEY_PAUSE, then "ir-keytable -s rc1 -t" show you the
> > correct (new) key? So as far as ir-keytable is concerned, everything
> > works?
> >
> > However when you try to use the new mapping in some application then
> > it does not work?
> 
> That's correct. ir-keytable seems to be doing the right thing, mapping
> the scancode to the input-event-codes.h key code I asked it to.

ir-keytable reads from the input layer, so that's the key being sent. The
problem is elsewhere.

> The application I am trying to use it with is the mythtv frontend.  I
> am doing the keycode munging from an SSH session while myth is still
> running on the main screen. I didn't think this would matter (since it
> worked for KEY_OK->KEY_ENTER) but perhaps it does. Obviously
> ir-keytable -t intercepts the scancodes when it is running, but when I
> kill it myth responds normally to some keys, but not all.

X and keycodes is a bit messy. You might need xmodmap mappings. You
can check them xev. I don't know much about this, I'm afraid. What
linux distribution, version and keyboard layout are you using? I could
try and see if I can reproduce/fix this.
 
> I wanted to mention that the IR protocol is still showing as unknown.
> Is there anything that can be done to sort that out?

It would be nice if that could be sorted out, although that would be 
a separate patch.

So all we know right now is what scancode the IR receiver hardware
produces but we have no idea what IR protocol is being used. In order to
figure this out we need a recording of the IR the remote sends, for which
a different IR receiver is needed. Neither your imon nor your 
dvb_usb_af9035 can do this, something like a mce usb IR receiver would
be best. Do you have access to one? One with an IR emitter would be
best.

So with that we can have a recording of the IR the remote sends, and
with the emitter we can see which IR protocols the IR receiver 
understands.


Sean
--
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: fix error paths in lirc_cdev_add()

2016-11-27 Thread Sean Young
"c77d17c0 [media] lirc: use-after free" introduces two problems:
cdev_del() can be called with a NULL argument, and the kobject_put()
path will cause a double free.

Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/lirc_dev.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index d3039ef..3854809 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -157,13 +157,13 @@ static const struct file_operations lirc_dev_fops = {
 
 static int lirc_cdev_add(struct irctl *ir)
 {
-   int retval = -ENOMEM;
struct lirc_driver *d = >d;
struct cdev *cdev;
+   int retval;
 
cdev = cdev_alloc();
if (!cdev)
-   goto err_out;
+   return -ENOMEM;
 
if (d->fops) {
cdev->ops = d->fops;
@@ -177,10 +177,8 @@ static int lirc_cdev_add(struct irctl *ir)
goto err_out;
 
retval = cdev_add(cdev, MKDEV(MAJOR(lirc_base_dev), d->minor), 1);
-   if (retval) {
-   kobject_put(>kobj);
+   if (retval)
goto err_out;
-   }
 
ir->cdev = cdev;
 
-- 
2.9.3

--
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: [bug report] [media] lirc: prevent use-after free

2016-11-26 Thread Sean Young
Hi Dan,

On Sat, Nov 26, 2016 at 12:57:17PM +0300, Dan Carpenter wrote:
> Hello Sean Young,
> 
> The patch afbb110172b9: "[media] lirc: prevent use-after free" from
> Oct 31, 2016, leads to the following static checker warning:
> 
>   drivers/media/rc/lirc_dev.c:190 lirc_cdev_add()
>   error: potential null dereference 'cdev'.  (cdev_alloc returns null)
> 
> drivers/media/rc/lirc_dev.c
>158  static int lirc_cdev_add(struct irctl *ir)
>159  {
>160  int retval = -ENOMEM;
>161  struct lirc_driver *d = >d;
>162  struct cdev *cdev;
>163  
>164  cdev = cdev_alloc();
>165  if (!cdev)
>166  goto err_out;
> 
> Classic one err bug.  Just return directly here.  return -ENOMEM is 100%
> readable but goto err_out is opaque because you first have to scroll
> down to see what err_out does then you have to scroll to the start of
> the function to verify that retval is set.
> 
>167  
>168  if (d->fops) {
>169  cdev->ops = d->fops;
>170  cdev->owner = d->owner;
>171  } else {
>172  cdev->ops = _dev_fops;
>173  cdev->owner = THIS_MODULE;
>174  }
>175  retval = kobject_set_name(>kobj, "lirc%d", d->minor);
>176  if (retval)
>177  goto err_out;
>178  
>179  retval = cdev_add(cdev, MKDEV(MAJOR(lirc_base_dev), 
> d->minor), 1);
>180  if (retval) {
>181  kobject_put(>kobj);
> 
> This is a double free, isn't it?  It should just be goto del_cdev;
> 
>182  goto err_out;
>183  }
>184  
>185  ir->cdev = cdev;
>186  
>187  return 0;
>188  
>189  err_out:
>190  cdev_del(cdev);
> 
> Can't pass NULLs to this function.
> 
>191  return retval;
>192  }

Oh dear! Thanks for reporting this, you're absolutely right. I'll send
out a patch shortly.

Thanks
Sean
--
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: refactor raw handler kthread

2016-11-25 Thread Sean Young
On Tue, Aug 02, 2016 at 07:44:07AM +0200, Heiner Kallweit wrote:
> I think we can get rid of the spinlock protecting the kthread from being
> interrupted by a wakeup in certain parts.
> Even with the current implementation of the kthread the only lost wakeup
> scenario could happen if the wakeup occurs between the kfifo_len check
> and setting the state to TASK_INTERRUPTIBLE.
> 
> In the changed version we could lose a wakeup if it occurs between
> processing the fifo content and setting the state to TASK_INTERRUPTIBLE.
> This scenario is covered by an additional check for available events in
> the fifo and setting the state to TASK_RUNNING in this case.
> 
> In addition the changed version flushes the kfifo before ending
> when the kthread is stopped.
> 
> With this patch we gain:
> - Get rid of the spinlock
> - Simplify code
> - Don't grep / release the mutex for each individual event but just once
>   for the complete fifo content. This reduces overhead if a driver e.g.
>   triggers processing after writing the content of a hw fifo to the kfifo.
> 
> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com>

Looks good to me and I've also tested it.

Tested-by: Sean Young <s...@mess.org>

> ---
>  drivers/media/rc/rc-core-priv.h |  2 --
>  drivers/media/rc/rc-ir-raw.c| 46 
> +++--
>  2 files changed, 17 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
> index 585d5e5..577128a 100644
> --- a/drivers/media/rc/rc-core-priv.h
> +++ b/drivers/media/rc/rc-core-priv.h
> @@ -20,7 +20,6 @@
>  #define  MAX_IR_EVENT_SIZE   512
>  
>  #include 
> -#include 
>  #include 
>  
>  struct ir_raw_handler {
> @@ -37,7 +36,6 @@ struct ir_raw_handler {
>  struct ir_raw_event_ctrl {
>   struct list_headlist;   /* to keep track of raw 
> clients */
>   struct task_struct  *thread;
> - spinlock_t  lock;
>   /* fifo for the pulse/space durations */
>   DECLARE_KFIFO(kfifo, struct ir_raw_event, MAX_IR_EVENT_SIZE);
>   ktime_t last_event; /* when last event 
> occurred */
> diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
> index 205ecc6..71a3e17 100644
> --- a/drivers/media/rc/rc-ir-raw.c
> +++ b/drivers/media/rc/rc-ir-raw.c
> @@ -17,7 +17,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include "rc-core-priv.h"
>  
>  /* Used to keep track of IR raw clients, protected by ir_raw_handler_lock */
> @@ -35,32 +34,26 @@ static int ir_raw_event_thread(void *data)
>   struct ir_raw_handler *handler;
>   struct ir_raw_event_ctrl *raw = (struct ir_raw_event_ctrl *)data;
>  
> - while (!kthread_should_stop()) {
> -
> - spin_lock_irq(>lock);
> -
> - if (!kfifo_len(>kfifo)) {
> - set_current_state(TASK_INTERRUPTIBLE);
> -
> - if (kthread_should_stop())
> - set_current_state(TASK_RUNNING);
> -
> - spin_unlock_irq(>lock);
> - schedule();
> - continue;
> + while (1) {
> + mutex_lock(_raw_handler_lock);
> + while (kfifo_out(>kfifo, , 1)) {
> + list_for_each_entry(handler, _raw_handler_list, list)
> + if (raw->dev->enabled_protocols &
> + handler->protocols || !handler->protocols)
> + handler->decode(raw->dev, ev);
> + raw->prev_ev = ev;
>   }
> + mutex_unlock(_raw_handler_lock);
>  
> - if(!kfifo_out(>kfifo, , 1))
> - dev_err(>dev->dev, "IR event FIFO is empty!\n");
> - spin_unlock_irq(>lock);
> + set_current_state(TASK_INTERRUPTIBLE);
>  
> - mutex_lock(_raw_handler_lock);
> - list_for_each_entry(handler, _raw_handler_list, list)
> - if (raw->dev->enabled_protocols & handler->protocols ||
> - !handler->protocols)
> - handler->decode(raw->dev, ev);
> - raw->prev_ev = ev;
> - mutex_unlock(_raw_handler_lock);
> + if (kthread_should_stop()) {
> + __set_current_state(TASK_RUNNING);
> + break;
> + } else if (!kfifo_is_empty(>kfifo))
> + set_current_st

Re: ir-keytable: infinite loops, segfaults

2016-11-24 Thread Sean Young
On Thu, Nov 24, 2016 at 11:12:57PM +1100, Vincent McIntyre wrote:
> On Wed, Nov 23, 2016 at 10:34:19PM +0000, Sean Young wrote:
> > > Not sure why Driver is (null), dvb_usb_cxusb is loaded.
> > 
> > That's a mistake, I've fixed that now.
> 
> Ah. I see the added module_name struct members.
> 
> > > I tried -t and it generated events constantly, before I could press
> > > any keys.
> > > # ir-keytable -s rc1 -t
> > > Testing events. Please, press CTRL-C to abort.
> > > 1479903007.535509: event type EV_MSC(0x04): scancode = 0x00
> > > 1479903007.535509: event type EV_SYN(0x00).
> > > 1479903007.635521: event type EV_MSC(0x04): scancode = 0x00
> > 
> > That's also been fixed.
> > 
> 
> yep, works nicely.
> 
> Things are looking much better!
> As shown below I am able to clear a keytable and put in a fresh one.
> Having a bit of trouble with key remapping.
> I guess we still have to work out the protocol in use.
> 
> Test details:
> # ir-keytable -v
> Found device /sys/class/rc/rc0/
> Found device /sys/class/rc/rc1/
> Found device /sys/class/rc/rc2/
> Input sysfs node is /sys/class/rc/rc0/input8/
> Event sysfs node is /sys/class/rc/rc0/input8/event5/
> Parsing uevent /sys/class/rc/rc0/input8/event5/uevent
> /sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13
> /sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69
> /sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5
> Parsing uevent /sys/class/rc/rc0/uevent
> /sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce
> /sys/class/rc/rc0/uevent uevent DRV_NAME=imon
> input device is /dev/input/event5
> /sys/class/rc/rc0/protocols protocol rc-6 (enabled)
> Found /sys/class/rc/rc0/ (/dev/input/event5) with:
>   Driver imon, table rc-imon-mce
>   Supported protocols: rc-6 
>   Enabled protocols: rc-6 
>   Name: iMON Remote (15c2:ffdc)
>   bus: 3, vendor/product: 15c2:ffdc, version: 0x
> Input sysfs node is /sys/class/rc/rc1/input18/
> Event sysfs node is /sys/class/rc/rc1/input18/event15/
> Parsing uevent /sys/class/rc/rc1/input18/event15/uevent
> /sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13
> /sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79
> /sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15
> Parsing uevent /sys/class/rc/rc1/uevent
> /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
> /sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb
> input device is /dev/input/event15
> /sys/class/rc/rc1/protocols protocol unknown (disabled)
> Found /sys/class/rc/rc1/ (/dev/input/event15) with:
>   Driver dvb_usb_cxusb, table rc-dvico-mce
>   Supported protocols: unknown 
>   Enabled protocols: 
>   Name: IR-receiver inside an USB DVB re
>   bus: 3, vendor/product: 0fe9:db78, version: 0x827b
> Input sysfs node is /sys/class/rc/rc2/input19/
> Event sysfs node is /sys/class/rc/rc2/input19/event16/
> Parsing uevent /sys/class/rc/rc2/input19/event16/uevent
> /sys/class/rc/rc2/input19/event16/uevent uevent MAJOR=13
> /sys/class/rc/rc2/input19/event16/uevent uevent MINOR=80
> /sys/class/rc/rc2/input19/event16/uevent uevent DEVNAME=input/event16
> Parsing uevent /sys/class/rc/rc2/uevent
> /sys/class/rc/rc2/uevent uevent NAME=rc-empty
> /sys/class/rc/rc2/uevent uevent DRV_NAME=dvb_usb_af9035
> input device is /dev/input/event16
> /sys/class/rc/rc2/protocols protocol nec (disabled)
> Found /sys/class/rc/rc2/ (/dev/input/event16) with:
>   Driver dvb_usb_af9035, table rc-empty
>   Supported protocols: nec 
>   Enabled protocols: 
>   Name: Leadtek WinFast DTV Dongle Dual
>   bus: 3, vendor/product: 0413:6a05, version: 0x0200
>   Repeat delay = 500 ms, repeat period = 125 ms
>   Repeat delay = 500 ms, repeat period = 125 ms
>   Repeat delay = 500 ms, repeat period = 125 ms
> 
> # ir-keytable -r -v -s rc1
> Found device /sys/class/rc/rc0/
> Found device /sys/class/rc/rc1/
> Found device /sys/class/rc/rc2/
> Input sysfs node is /sys/class/rc/rc1/input18/
> Event sysfs node is /sys/class/rc/rc1/input18/event15/
> Parsing uevent /sys/class/rc/rc1/input18/event15/uevent
> /sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13
> /sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79
> /sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15
> Parsing uevent /sys/class/rc/rc1/uevent
> /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
> /sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb
> input device is /dev/input/event15
> /sys/class/rc/rc1/protocols protocol unknown (disabled)
> Opening /dev/input/event15
> Input Protocol version: 0x00010001
> Enabled protocols: 
> scanco

Re: ir-keytable: infinite loops, segfaults

2016-11-23 Thread Sean Young
On Wed, Nov 23, 2016 at 11:39:06PM +1100, Vincent McIntyre wrote:
> On Tue, Nov 22, 2016 at 09:20:44AM +0000, Sean Young wrote:
> > > Thanks for this. I have got it to build within the media_build setup
> > > but will need to find some windows in the schedule for testing. More
> > > in a couple of days. Are there specific things you would like me to
> > > test?
> > 
> > You should have an rc device for the IR receiver in the dvb device; does
> > it continue to work and can you clear/load a new keymap with ir-keytable,
> > and does it work after that.
> > 
> > A "Tested-by" would be great if it all works of course.
> 
> Time for some initial results. Good start, not quite there yet.
> 
> Nov 23 23:04:56 kernel: Registered IR keymap rc-dvico-mce
> Nov 23 23:04:56 kernel: input: IR-receiver inside an USB DVB receiver as 
> /devices/pci:00
> Nov 23 23:04:56 kernel: rc rc1: IR-receiver inside an USB DVB receiver as 
> /devices/pci:0
> Nov 23 23:04:56 kernel: dvb-usb: schedule remote query interval to 100 msecs.
> Nov 23 23:04:56 kernel: dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 
> successfully initiali
> Nov 23 23:04:56 kernel: dvb-usb: found a 'DViCO FusionHDTV DVB-T Dual Digital 
> 4' in warm sta
> Nov 23 23:04:56 kernel: dvb-usb: will pass the complete MPEG2 transport 
> stream to the softwa
> Nov 23 23:04:56 kernel: dvbdev: DVB: registering new adapter (DViCO 
> FusionHDTV DVB-T Dual Di
> Nov 23 23:04:56 kernel: usb 3-2: media controller created
> Nov 23 23:04:56 kernel: dvbdev: dvb_create_media_entity: media entity 
> 'dvb-demux' registered
> Nov 23 23:04:56 kernel: cxusb: No IR receiver detected on this device.
> Nov 23 23:04:56 kernel: usb 3-2: DVB: registering adapter 1 frontend 0 
> (Zarlink ZL10353 DVB-
> Nov 23 23:04:56 kernel: dvbdev: dvb_create_media_entity: media entity 
> 'Zarlink ZL10353 DVB-T
> Nov 23 23:04:56 kernel: xc2028 5-0061: creating new instance
> Nov 23 23:04:56 kernel: xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner
> Nov 23 23:04:56 kernel: xc2028 5-0061: Loading 80 firmware images from 
> xc3028-v27.fw, type: 
> Nov 23 23:04:56 kernel: dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 
> successfully initiali
> Nov 23 23:04:56 kernel: usbcore: registered new interface driver dvb_usb_cxusb
> 
> # lsmod |grep rc
> rc_dvico_mce   16384  0
> rc_imon_mce16384  0
> rc_core32768  11 
> imon,dvb_usb,winbond_cir,dvb_usb_cxusb,rc_imon_mce,rc_dvico_mce,dvb_usb_v2,dvb_usb_af9035
> libcrc32c  16384  1 raid456
> crc_itu_t  16384  1 firewire_core
> 
> # lsmod |grep cxu
> dvb_usb_cxusb  77824  2
> dib007020480  1 dvb_usb_cxusb
> dvb_usb32768  1 dvb_usb_cxusb
> rc_core32768  11 
> imon,dvb_usb,winbond_cir,dvb_usb_cxusb,rc_imon_mce,rc_dvico_mce,dvb_usb_v2,dvb_usb_af9035
> 
> 
> # ir-keytable
> Found /sys/class/rc/rc0/ (/dev/input/event5) with:
> Driver imon, table rc-imon-mce
> Supported protocols: rc-6 
> Enabled protocols: rc-6 
> Name: iMON Remote (15c2:ffdc)
> bus: 3, vendor/product: 15c2:ffdc, version: 0x
> Repeat delay = 500 ms, repeat period = 125 ms
> Found /sys/class/rc/rc1/ (/dev/input/event15) with:
> Driver (null), table rc-dvico-mce
> Supported protocols: unknown 
> Enabled protocols: 
> Name: IR-receiver inside an USB DVB re
> bus: 3, vendor/product: 0fe9:db78, version: 0x827b
> Repeat delay = 500 ms, repeat period = 125 ms
> Found /sys/class/rc/rc2/ (/dev/input/event16) with:
> Driver dvb_usb_af9035, table rc-empty
> Supported protocols: nec 
> Enabled protocols: 
> Name: Leadtek WinFast DTV Dongle Dual
> bus: 3, vendor/product: 0413:6a05, version: 0x0200
> Repeat delay = 500 ms, repeat period = 125 ms
> 
> Not sure why Driver is (null), dvb_usb_cxusb is loaded.

That's a mistake, I've fixed that now.

> # ir-keytable -s rc1 -r -v
> Found device /sys/class/rc/rc0/
> Found device /sys/class/rc/rc1/
> Found device /sys/class/rc/rc2/
> Input sysfs node is /sys/class/rc/rc1/input18/
> Event sysfs node is /sys/class/rc/rc1/input18/event15/
> Parsing uevent /sys/class/rc/rc1/input18/event15/uevent
> /sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13
> /sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79
> /sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15
> Parsing uevent /sys/class/rc/rc1/uevent
> /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
> input device is /dev/input/event15
> /sys/class/rc/rc1/protocols protocol unknown (disabled)
> Opening /dev/input/event15
> Input Protocol version: 0x00010001
> 

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

2016-11-22 Thread Sean Young
On Tue, Nov 22, 2016 at 01:08:52PM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 22 Nov 2016 09:19:19 -0500
> Jarod Wilson <ja...@redhat.com> escreveu:
> > 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?
> 
> Yes. Sean suspects that we're decoding the NEC 32 bits in the
> wrong order at the in-kernel NEC decoder on x86[1].
> 
> The idea here is to double-check how the bits are encapsulated, in order
> to do the right thing at the IR decoder.
> 
> [1] the current code actually sucks, as it produces different
> scancodes on big endian or little endian, so it needs to be
> fixed anyway, as it simply does:
>   scancode = data->bits;
> 
> instead of using be32_to_cpu().

Bits are shifted in one at at time in the nec decoder so it is endian safe.

The problem is that the same NEC32 IR will produce different scancodes
with ir-nec-decoder.c and other nec decoders, e.g. dib0700_core.c


Sean
--
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] nec decoder: wrong bit order for nec32 protocol

2016-11-22 Thread Sean Young
On Tue, Nov 22, 2016 at 09:19:19AM -0500, Jarod Wilson wrote:
> 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 problem here is that each *byte* is sent lsb first, so only the 
ordering within each byte would change. 

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

Yes, it is. Hardware nec decoders send each byte lsb first, but 
ir-nec-decoder.c decoder does msb first for nec32 (not for extended nec or
plain nec).

If we have a mode2 recording of the remote (and if we know what button it
is), then we can replay it against a hardware nec decoder and the software
decoder. Rather than mode2, this can also be done with ir-ctl which is in
v4l-utils git.

Alternatively simply checking if the tivo keymap works with the
software decoder (mceusb hardware for example) should be sufficient.

That would be really helpful, thanks.


Sean
--
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: ir-keytable: infinite loops, segfaults

2016-11-22 Thread Sean Young
On Tue, Nov 22, 2016 at 06:25:59PM +1100, Vincent McIntyre wrote:
> On 11/21/16, Sean Young <s...@mess.org> wrote:
> >>
> >> Ah. Here we have a problem. The device (/dev/input/event15)
> >> doesn't have a corresponding rcX node, see ir-keytable output below.
> >> I had it explained to me like this:
> >
> > As I said you would need to use a raw IR receiver which has rc-core support
> > to determine the protocol, so never mind. Please can you try this patch:
> >
> > I don't have the hardware to test this so your input would be appreciated.
> >
> 
> Thanks for this. I have got it to build within the media_build setup
> but will need to find some windows in the schedule for testing. More
> in a couple of days. Are there specific things you would like me to
> test?

You should have an rc device for the IR receiver in the dvb device; does
it continue to work and can you clear/load a new keymap with ir-keytable,
and does it work after that.

A "Tested-by" would be great if it all works of course.

Thanks
Sean
--
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 v4 3/3] [media] lirc_serial: move out of staging and rename to serial_ir

2016-11-21 Thread Sean Young
Signed-off-by: Sean Young <s...@mess.org>
---
 MAINTAINERS  |   6 +
 drivers/media/rc/Kconfig |  17 +
 drivers/media/rc/Makefile|   1 +
 drivers/media/rc/serial_ir.c | 845 +++
 drivers/staging/media/lirc/Kconfig   |  13 -
 drivers/staging/media/lirc/Makefile  |   1 -
 drivers/staging/media/lirc/lirc_serial.c | 845 ---
 7 files changed, 869 insertions(+), 859 deletions(-)
 create mode 100644 drivers/media/rc/serial_ir.c
 delete mode 100644 drivers/staging/media/lirc/lirc_serial.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7db3f7a..5c48f49 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10629,6 +10629,12 @@ S: Maintained
 F: Documentation/devicetree/bindings/serial/
 F: drivers/tty/serial/
 
+SERIAL IR RECEIVER
+M:     Sean Young <s...@mess.org>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/rc/serial_ir.c
+
 STI CEC DRIVER
 M: Benjamin Gaignard <benjamin.gaign...@linaro.org>
 L: ker...@stlinux.com
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 370e16e..629e8ca 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -389,4 +389,21 @@ config IR_SUNXI
   To compile this driver as a module, choose M here: the module will
   be called sunxi-ir.
 
+config IR_SERIAL
+   tristate "Homebrew Serial Port Receiver"
+   depends on RC_CORE
+   ---help---
+  Say Y if you want to use Homebrew Serial Port Receivers and
+  Transceivers.
+
+  To compile this driver as a module, choose M here: the module will
+  be called serial-ir.
+
+config IR_SERIAL_TRANSMITTER
+   bool "Serial Port Transmitter"
+   default y
+   depends on IR_SERIAL
+   ---help---
+  Serial Port Transmitter support
+
 endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 379a5c0..3a984ee 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
 obj-$(CONFIG_RC_ST) += st_rc.o
 obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
 obj-$(CONFIG_IR_IMG) += img-ir/
+obj-$(CONFIG_IR_SERIAL) += serial_ir.o
diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
new file mode 100644
index 000..aad9bec
--- /dev/null
+++ b/drivers/media/rc/serial_ir.c
@@ -0,0 +1,845 @@
+/*
+ * serial_ir.c
+ *
+ * serial_ir - Device driver that records pulse- and pause-lengths
+ *(space-lengths) between DDCD event on a serial port.
+ *
+ * Copyright (C) 1996,97 Ralph Metzler <r...@thp.uni-koeln.de>
+ * Copyright (C) 1998 Trent Piepho <xy...@u.washington.edu>
+ * Copyright (C) 1998 Ben Pfaff <b...@gnu.org>
+ * Copyright (C) 1999 Christoph Bartelmus <l...@bartelmus.de>
+ * Copyright (C) 2007 Andrei Tanas <and...@tanas.ca> (suspend/resume support)
+ * Copyright (C) 2016 Sean Young <s...@mess.org> (port to rc-core)
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct serial_ir_hw {
+   int signal_pin;
+   int signal_pin_change;
+   u8 on;
+   u8 off;
+   unsigned set_send_carrier:1;
+   unsigned set_duty_cycle:1;
+   void (*send_pulse)(unsigned int length, ktime_t edge);
+   void (*send_space)(void);
+   spinlock_t lock;
+};
+
+#define IR_HOMEBREW0
+#define IR_IRDEO   1
+#define IR_IRDEO_REMOTE2
+#define IR_ANIMAX  3
+#define IR_IGOR4
+
+/* module parameters */
+static int type;
+static int io;
+static int irq;
+static bool iommap;
+static int ioshift;
+static bool softcarrier = true;
+static bool share_irq;
+static int sense = -1; /* -1 = auto, 0 = active high, 1 = active low */
+static bool txsense;   /* 0 = active high, 1 = active low */
+
+/* forward declarations */
+static void send_pulse_irdeo(unsigned int length, ktime_t edge);
+static void send_space_irdeo(void);
+#ifdef CONFIG_IR_SERIAL_TRANSMITTER
+static void send_pulse_homebrew(unsigned int length, ktime_t edge);
+static void send_space_homebrew(void);
+#endif
+
+static struct serial_ir_hw hardware[] = {
+   [IR_HOMEBREW] = {
+   .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_HOMEBREW].lock),
+

[PATCH v4 2/3] [media] lirc_serial: use precision ktime rather than guessing

2016-11-21 Thread Sean Young
This makes transmission more reliable and the code much cleaner.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/staging/media/lirc/lirc_serial.c | 286 +++
 1 file changed, 65 insertions(+), 221 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_serial.c 
b/drivers/staging/media/lirc/lirc_serial.c
index 05a8a47..7d1c2af 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -21,29 +21,6 @@
  *  GNU General Public License for more details.
  */
 
-/*
- * Steve's changes to improve transmission fidelity:
- *   - for systems with the rdtsc instruction and the clock counter, a
- * send_pule that times the pulses directly using the counter.
- * This means that the IR_SERIAL_TRANSMITTER_LATENCY fudge is
- * not needed. Measurement shows very stable waveform, even where
- * PCI activity slows the access to the UART, which trips up other
- * versions.
- *   - For other system, non-integer-microsecond pulse/space lengths,
- * done using fixed point binary. So, much more accurate carrier
- * frequency.
- *   - fine tuned transmitter latency, taking advantage of fractional
- * microseconds in previous change
- *   - Fixed bug in the way transmitter latency was accounted for by
- * tuning the pulse lengths down - the send_pulse routine ignored
- * this overhead as it timed the overall pulse length - so the
- * pulse frequency was right but overall pulse length was too
- * long. Fixed by accounting for latency on each pulse/space
- * iteration.
- *
- * Steve Davies <st...@daviesfam.org>  July 2001
- */
-
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
@@ -64,8 +41,8 @@ struct serial_ir_hw {
u8 off;
unsigned set_send_carrier:1;
unsigned set_duty_cycle:1;
-   long (*send_pulse)(unsigned long length);
-   void (*send_space)(long length);
+   void (*send_pulse)(unsigned int length, ktime_t edge);
+   void (*send_space)(void);
spinlock_t lock;
 };
 
@@ -87,11 +64,11 @@ static int sense = -1;  /* -1 = auto, 0 = active high, 
1 = active low */
 static bool txsense;   /* 0 = active high, 1 = active low */
 
 /* forward declarations */
-static long send_pulse_irdeo(unsigned long length);
-static void send_space_irdeo(long length);
+static void send_pulse_irdeo(unsigned int length, ktime_t edge);
+static void send_space_irdeo(void);
 #ifdef CONFIG_IR_SERIAL_TRANSMITTER
-static long send_pulse_homebrew(unsigned long length);
-static void send_space_homebrew(long length);
+static void send_pulse_homebrew(unsigned int length, ktime_t edge);
+static void send_space_homebrew(void);
 #endif
 
 static struct serial_ir_hw hardware[] = {
@@ -137,8 +114,6 @@ static struct serial_ir_hw hardware[] = {
.signal_pin_change = UART_MSR_DDCD,
.on  = 0,
.off = (UART_MCR_RTS | UART_MCR_DTR | UART_MCR_OUT2),
-   .send_pulse = NULL,
-   .send_space = NULL,
},
 
[IR_IGOR] = {
@@ -166,51 +141,11 @@ struct serial_ir {
unsigned int freq;
unsigned int duty_cycle;
 
-   unsigned long period;
-   unsigned long pulse_width, space_width;
+   unsigned int pulse_width, space_width;
 };
 
 static struct serial_ir serial_ir;
 
-#if defined(__i386__)
-/*
- * From:
- * Linux I/O port programming mini-HOWTO
- * Author: Riku Saikkonen <riku.saikko...@hut.fi>
- * v, 28 December 1997
- *
- * [...]
- * Actually, a port I/O instruction on most ports in the 0-0x3ff range
- * takes almost exactly 1 microsecond, so if you're, for example, using
- * the parallel port directly, just do additional inb()s from that port
- * to delay.
- * [...]
- */
-/* transmitter latency 1.5625us 0x1.90 - this figure arrived at from
- * comment above plus trimming to match actual measured frequency.
- * This will be sensitive to cpu speed, though hopefully most of the 1.5us
- * is spent in the uart access.  Still - for reference test machine was a
- * 1.13GHz Athlon system - Steve
- */
-
-/*
- * changed from 400 to 450 as this works better on slower machines;
- * faster machines will use the rdtsc code anyway
- */
-#define IR_SERIAL_TRANSMITTER_LATENCY 450
-
-#else
-
-/* does anybody have information on other platforms ? */
-/* 256 = 1<<8 */
-#define IR_SERIAL_TRANSMITTER_LATENCY 256
-
-#endif /* __i386__ */
-/*
- * FIXME: should we be using hrtimers instead of this
- * IR_SERIAL_TRANSMITTER_LATENCY nonsense?
- */
-
 /* fetch serial input packet (1 byte) from register offset */
 static u8 sinp(int offset)
 {
@@ -247,96 +182,21 @@ static void off(void)
soutp(UART_MCR, hardware[type].off);
 }
 
-#ifndef MAX_UDELAY_MS
-#define MAX_UDELAY_US 5000
-#else
-#define MAX_UDELAY_US (MAX_UDELAY_MS*1000)
-#endif
-
-static void safe_udelay(unsigned long usecs)
+static void init_timing_params(unsigned int new_duty_cycle,
+ 

[PATCH v4 1/3] [media] lirc_serial: port to rc-core

2016-11-21 Thread Sean Young
Tested with a homebrew serial ir. Remove last remmants of the nslu2
which could not be enabled, and fix checkpatch warnings.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/staging/media/lirc/lirc_serial.c | 677 +--
 1 file changed, 274 insertions(+), 403 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_serial.c 
b/drivers/staging/media/lirc/lirc_serial.c
index b798b31..05a8a47 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -9,6 +9,7 @@
  * Copyright (C) 1998 Ben Pfaff <b...@gnu.org>
  * Copyright (C) 1999 Christoph Bartelmus <l...@bartelmus.de>
  * Copyright (C) 2007 Andrei Tanas <and...@tanas.ca> (suspend/resume support)
+ * Copyright (C) 2016 Sean Young <s...@mess.org> (port to rc-core)
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
  *  the Free Software Foundation; either version 2 of the License, or
@@ -18,18 +19,13 @@
  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- *
  */
 
 /*
  * Steve's changes to improve transmission fidelity:
  *   - for systems with the rdtsc instruction and the clock counter, a
  * send_pule that times the pulses directly using the counter.
- * This means that the LIRC_SERIAL_TRANSMITTER_LATENCY fudge is
+ * This means that the IR_SERIAL_TRANSMITTER_LATENCY fudge is
  * not needed. Measurement shows very stable waveform, even where
  * PCI activity slows the access to the UART, which trips up other
  * versions.
@@ -52,56 +48,34 @@
 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
-#include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
+#include 
 
-/* From Intel IXP42X Developer's Manual (#252480-005): */
-/* ftp://download.intel.com/design/network/manuals/25248005.pdf */
-#define UART_IE_IXP42X_UUE   0x40 /* IXP42X UART Unit enable */
-#define UART_IE_IXP42X_RTOIE 0x10 /* IXP42X Receiver Data Timeout int.enable */
-
-#include 
-#include 
-
-#define LIRC_DRIVER_NAME "lirc_serial"
-
-struct lirc_serial {
+struct serial_ir_hw {
int signal_pin;
int signal_pin_change;
u8 on;
u8 off;
+   unsigned set_send_carrier:1;
+   unsigned set_duty_cycle:1;
long (*send_pulse)(unsigned long length);
void (*send_space)(long length);
-   int features;
spinlock_t lock;
 };
 
-#define LIRC_HOMEBREW  0
-#define LIRC_IRDEO 1
-#define LIRC_IRDEO_REMOTE  2
-#define LIRC_ANIMAX3
-#define LIRC_IGOR  4
-#define LIRC_NSLU2 5
+#define IR_HOMEBREW0
+#define IR_IRDEO   1
+#define IR_IRDEO_REMOTE2
+#define IR_ANIMAX  3
+#define IR_IGOR4
 
-/*** module parameters ***/
+/* module parameters */
 static int type;
 static int io;
 static int irq;
@@ -114,107 +88,89 @@ static bool txsense;  /* 0 = active high, 1 = active 
low */
 
 /* forward declarations */
 static long send_pulse_irdeo(unsigned long length);
-static long send_pulse_homebrew(unsigned long length);
 static void send_space_irdeo(long length);
+#ifdef CONFIG_IR_SERIAL_TRANSMITTER
+static long send_pulse_homebrew(unsigned long length);
 static void send_space_homebrew(long length);
+#endif
 
-static struct lirc_serial hardware[] = {
-   [LIRC_HOMEBREW] = {
-   .lock = __SPIN_LOCK_UNLOCKED(hardware[LIRC_HOMEBREW].lock),
-   .signal_pin= UART_MSR_DCD,
+static struct serial_ir_hw hardware[] = {
+   [IR_HOMEBREW] = {
+   .lock = __SPIN_LOCK_UNLOCKED(hardware[IR_HOMEBREW].lock),
+   .signal_pin= UART_MSR_DCD,
.signal_pin_change = UART_MSR_DDCD,
.on  = (UART_MCR_RTS | UART_MCR_OUT2 | UART_MCR_DTR),
.off = (UART_MCR_RTS | UART_MCR_OUT2),
+#ifdef CONFIG_IR_SERIAL_TRANSMITTER
.send_pulse = send_pulse_homebrew,
.send_space = send_space_homebrew,
-#ifdef CONFIG_LIRC_SERIAL_TRANSMITTER
-   .features= (LIRC_CAN_SET_SEND_DUTY_CYCLE |
-   LIRC_CAN_SET_SEND_CARRIER |
-   LIRC_CAN_SEND_PULSE | LIRC_CAN_REC_MODE2)
-#else
-   .features= LIRC_CAN_REC_MODE2
+   .set_send_carrier = true,
+   .set_duty_cycle = true,
 #endif
},
 
-   [LIRC_IRDEO] = {
-   .lock = __SPIN

Re: [PATCH v3 1/2] [media] serial_ir: port lirc_serial to rc-core

2016-11-21 Thread Sean Young
On Mon, Nov 21, 2016 at 02:28:08PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 11 Nov 2016 23:13:06 +
> Sean Young <s...@mess.org> escreveu:
> 
> > Tested with a homebrew serial ir. Remove last remmants of the nslu2
> > which could not be enabled.
> 
> Thanks for this! It is really nice to see any efforts on moving the drivers
> under staging. 

Unfortunately some of the hardware is hard to track down. I've got my eyes
on ebay, but if anyone can help me out with:

- Sasem OnAir VFD/IR (Dign HV5 or D.Vine 5 HTPC IR/VFD) (lirc_sasem)
- lirc parallel (lirc_parallel)
- Original iMon SoundGraph IR receiver/display (lirc_imon)

I would appreciate it and I can work on getting the drivers out of staging.

> IMHO, it is almost ready for upstream merge, but I would prefer if you
> could do all changes, in incremental patches, on the driver at
> drivers/staging/media/lirc/lirc_serial.c, doing the module rename
> (together with Kconfig/Makefile/MAINTAINERS change) on the last one. 

That is better, I've reworked it.

> That makes my life a way easier, as I'll only need to review the final
> patch, not caring about the intermediate ones (except for compilation test).

New patch series ready to be sent and tested at each commit.

> I have a few nitpicks here, plus one more serious issue: don't use
> udelay() for very long times. See below.

Thanks!
> 
> > 
> > Signed-off-by: Sean Young <s...@mess.org>
> > ---
> >  MAINTAINERS  |6 +
> >  drivers/media/rc/Kconfig |   17 +
> >  drivers/media/rc/Makefile|1 +
> >  drivers/media/rc/serial_ir.c | 1003 ++
> >  drivers/staging/media/lirc/Kconfig   |   13 -
> >  drivers/staging/media/lirc/Makefile  |1 -
> >  drivers/staging/media/lirc/lirc_serial.c | 1130 
> > --
> >  7 files changed, 1027 insertions(+), 1144 deletions(-)
> >  create mode 100644 drivers/media/rc/serial_ir.c
> >  delete mode 100644 drivers/staging/media/lirc/lirc_serial.c
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 93e9f42..cd8fd50 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -10604,6 +10604,12 @@ S: Maintained
> >  F: Documentation/devicetree/bindings/serial/
> >  F: drivers/tty/serial/
> >  
> > +SERIAL IR RECEIVER
> > +M: Sean Young <s...@mess.org>
> > +L: linux-media@vger.kernel.org
> > +S: Maintained
> > +F: drivers/media/rc/serial_ir.c
> > +
> >  STI CEC DRIVER
> >  M: Benjamin Gaignard <benjamin.gaign...@linaro.org>
> >  L: ker...@stlinux.com
> > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> > index 370e16e..629e8ca 100644
> > --- a/drivers/media/rc/Kconfig
> > +++ b/drivers/media/rc/Kconfig
> > @@ -389,4 +389,21 @@ config IR_SUNXI
> >To compile this driver as a module, choose M here: the module will
> >be called sunxi-ir.
> >  
> > +config IR_SERIAL
> > +   tristate "Homebrew Serial Port Receiver"
> > +   depends on RC_CORE
> > +   ---help---
> > +  Say Y if you want to use Homebrew Serial Port Receivers and
> > +  Transceivers.
> > +
> > +  To compile this driver as a module, choose M here: the module will
> > +  be called serial-ir.
> > +
> > +config IR_SERIAL_TRANSMITTER
> > +   bool "Serial Port Transmitter"
> > +   default y
> > +   depends on IR_SERIAL
> > +   ---help---
> > +  Serial Port Transmitter support
> > +
> >  endif #RC_DEVICES
> > diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> > index 379a5c0..3a984ee 100644
> > --- a/drivers/media/rc/Makefile
> > +++ b/drivers/media/rc/Makefile
> > @@ -37,3 +37,4 @@ obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
> >  obj-$(CONFIG_RC_ST) += st_rc.o
> >  obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
> >  obj-$(CONFIG_IR_IMG) += img-ir/
> > +obj-$(CONFIG_IR_SERIAL) += serial_ir.o
> > diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
> > new file mode 100644
> > index 000..378ae09
> > --- /dev/null
> > +++ b/drivers/media/rc/serial_ir.c
> > @@ -0,0 +1,1003 @@
> > +/*
> > + * serial-ir.c
> > + *
> > + * serial-ir - Device driver that records pulse- and pause-lengths
> > + *(space-lengths) between DDCD event on a serial port.
> > + *
> > + * Copyright (C) 1996,97 Ralph Metzler <r...@thp.uni-koeln.de>
> > + * Copyright (C) 1998 Trent Piepho <xy...@u.washington.edu>
> > + * Copyright (C) 1998 Be

Re: ir-keytable: infinite loops, segfaults

2016-11-20 Thread Sean Young
On Sat, Nov 19, 2016 at 09:01:10AM +1100, Vincent McIntyre wrote:
> On Fri, Nov 18, 2016 at 05:40:34PM +0000, Sean Young wrote:
> > >  
> > > So are you saying that the hex codes in the rc_map_dvico_mce_table
> > > struct are invalid (at least in some cases)?
> > 
> > Most likely the remote produces IR in a standard protocol (e.g. rc5, rc6). 
> > If we first get the keymap right then the remote can be used with any 
> > IR receiver that can deal with its protocol; conversely, if we know 
> > what protocol the IR receiver can receive, and we make it produce the 
> > scancodes in the right format, it can then be used with any remote that 
> > uses the protocol it understands.
> > 
> > So at the moment we don't know what protocol it is, and even if it is 
> > rc5 then some bit shifting might be needed to make it into a proper
> > rc5 scancode (both driver and keymap).
> > 
> > > How can I tell what protocol is in use?
> > > 0x00010001 doesn't mean much to me; I did search the linux source
> > > for the code but didn't find any helpful matches.
> > 
> > At the moment it's not easy to determine what protocol an remote uses;
> > I would like to change that but for now, the following is probably
> > the easiest way.
> > 
> > cd /sys/class/rc/rc1 # replace rc1 with your receiver
> > for i in $(<protocols); do echo +$i > protocols; done
> > echo 3 > /sys/module/rc_core/parameters/debug
> > journal -f -k
>  
> Ah. Here we have a problem. The device (/dev/input/event15)
> doesn't have a corresponding rcX node, see ir-keytable output below.
> I had it explained to me like this:

As I said you would need to use a raw IR receiver which has rc-core support
to determine the protocol, so never mind. Please can you try this patch:

I don't have the hardware to test this so your input would be appreciated.


Sean

From: Sean Young <s...@mess.org>
Subject: [PATCH] [media] cxusb: port to rc-core

The d680_dmb keymap has some new new mappings.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/keymaps/Makefile|   3 +
 drivers/media/rc/keymaps/rc-d680-dmb.c   |  75 +++
 drivers/media/rc/keymaps/rc-dvico-mce.c  |  85 
 drivers/media/rc/keymaps/rc-dvico-portable.c |  76 +++
 drivers/media/usb/dvb-usb/cxusb.c| 298 ++-
 include/media/rc-map.h   |   3 +
 6 files changed, 308 insertions(+), 232 deletions(-)
 create mode 100644 drivers/media/rc/keymaps/rc-d680-dmb.c
 create mode 100644 drivers/media/rc/keymaps/rc-dvico-mce.c
 create mode 100644 drivers/media/rc/keymaps/rc-dvico-portable.c

diff --git a/drivers/media/rc/keymaps/Makefile 
b/drivers/media/rc/keymaps/Makefile
index d7b13fa..11d5d5a 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-cec.o \
rc-cinergy-1400.o \
rc-cinergy.o \
+   rc-d680-dmb.o \
rc-delock-61959.o \
rc-dib0700-nec.o \
rc-dib0700-rc5.o \
@@ -31,6 +32,8 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-dntv-live-dvbt-pro.o \
rc-dtt200u.o \
rc-dvbsky.o \
+   rc-dvico-mce.o \
+   rc-dvico-portable.o \
rc-em-terratec.o \
rc-encore-enltv2.o \
rc-encore-enltv.o \
diff --git a/drivers/media/rc/keymaps/rc-d680-dmb.c 
b/drivers/media/rc/keymaps/rc-d680-dmb.c
new file mode 100644
index 000..bb5745d
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-d680-dmb.c
@@ -0,0 +1,75 @@
+/*
+ * keymap imported from cxusb.c
+ *
+ * Copyright (C) 2016 Sean Young
+ *
+ * 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.
+ */
+
+#include 
+#include 
+
+static struct rc_map_table rc_map_d680_dmb_table[] = {
+   { 0x0038, KEY_SWITCHVIDEOMODE },/* TV/AV */
+   { 0x080c, KEY_ZOOM },
+   { 0x0800, KEY_0 },
+   { 0x0001, KEY_1 },
+   { 0x0802, KEY_2 },
+   { 0x0003, KEY_3 },
+   { 0x0804, KEY_4 },
+   { 0x0005, KEY_5 },
+   { 0x0806, KEY_6 },
+   { 0x0007, KEY_7 },
+   { 0x0808, KEY_8 },
+   { 0x0009, KEY_9 },
+   { 0x000a, KEY_MUTE },
+   { 0x0829, KEY_BACK },
+   { 0x0012, KEY_CHANNELUP },
+   { 0x0813, KEY_CHANNELDOWN },
+   { 0x002b, KEY_VOLUMEUP },
+   { 0x082c, KEY_VOLUMEDOWN },
+   { 0x0020, KEY_UP },
+   { 0x0821, KEY_DOWN },
+

Re: ir-keytable: infinite loops, segfaults

2016-11-18 Thread Sean Young
On Fri, Nov 18, 2016 at 11:14:25PM +1100, Vincent McIntyre wrote:
> On Thu, Nov 17, 2016 at 01:45:26PM +0000, Sean Young wrote:
> > On Wed, Nov 16, 2016 at 09:52:58PM +1100, Vincent McIntyre wrote:
> > > I have a fairly old dvico dual digital 4 tuner and remote.
> > > There seem to be some issues with support for it, can I help fix them?
> > > 
> > > I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS,
> > > with kernel 4.4.0-47-generic (package version 4.4.0-47-generic)
> > > 
> > > The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce;
> > > kernel support for the device is in media/usb/dvb-usb/cxusb.c.
> > > 
> > > Mostly it works, in that I get correct keycodes back from evtest
> > > and ir-keytable -t. But I want to change some of the keycode mappings
> > > and that is not working.
> > 
> > I suspect the problem here is rc-core is not used and 
> > legacy_dvb_usb_setkeycode has a bug (it has several problems).
> > 
> > It would be nicer if we could move it rc-core, but for that to work
> > we need to know what scancodes remote sends (and in what protocol).
> > A scancode of 0xfe47 is not a valid RC5 scancode.
>  
> So are you saying that the hex codes in the rc_map_dvico_mce_table
> struct are invalid (at least in some cases)?

Most likely the remote produces IR in a standard protocol (e.g. rc5, rc6). 
If we first get the keymap right then the remote can be used with any 
IR receiver that can deal with its protocol; conversely, if we know 
what protocol the IR receiver can receive, and we make it produce the 
scancodes in the right format, it can then be used with any remote that 
uses the protocol it understands.

So at the moment we don't know what protocol it is, and even if it is 
rc5 then some bit shifting might be needed to make it into a proper
rc5 scancode (both driver and keymap).

> How can I tell what protocol is in use?
> 0x00010001 doesn't mean much to me; I did search the linux source
> for the code but didn't find any helpful matches.

At the moment it's not easy to determine what protocol an remote uses;
I would like to change that but for now, the following is probably
the easiest way.

cd /sys/class/rc/rc1 # replace rc1 with your receiver
for i in $(<protocols); do echo +$i > protocols; done
echo 3 > /sys/module/rc_core/parameters/debug
journal -f -k

Protocol numbers are defined in enum rc_type, see include/media/rc-map.h

> > Would it be possible to test the remote with another device (say an
> > usb mce receiver or so) and see what scancodes it sends? Then we can
> > translate the keymap to a real one and make the cxusb driver send
> > correct scancodes to rc-core.
> 
> Great idea. Do you mean something like [1]?

Yes, it would be a receiver like that.

> Or the (presumably generic) receiver that comes with [2]?

It's not clear what usb receiver it uses.

> Would a FLIRC work?

I hadn't heard of flirc, looks like it doesn't have a kernel driver. Maybe
I'll go and get one. :)

> Probably dumb question - in this machine I also have
> an iMon Remote (152c:ffdc)
> and Leadtek WinFast DTV Dongle Dual
> Do you think either of those would be helpful?
> I tried evtest with them and the remote, no responses.
> 
> # ir-keytable
> Found /sys/class/rc/rce0/ (/dev/input/event5) with:
> Driver imon, table rc-imon-mce
> Supported protocols: rc-6 
> Enabled protocols: rc-6 
> Name: iMON Remote (15c2:ffdc)
> bus: 3, vendor/product: 15c2:ffdc, version: 0x
> Repeat delay = 500 ms, repeat period = 125 ms
> Found /sys/class/rc/rc1/ (/dev/input/event16) with:
> Driver dvb_usb_af9035, table rc-empty
> Supported protocols: nec 
> Enabled protocols: 
> Name: Leadtek WinFamst DTV Dongle Dual
> bus: 3, vendor/product: 0413:6a05, version: 0x0200
> Repeat delay = 500 mss, repeat period = 125 ms

Looks like it's neither rc6 nor nec then.

If you don't have the right receiver then all of this a bit academic.
Maybe it's possible to port to rc-core with the existing scancodes.

Thanks
Sean

> 
> Thanks
> Vince
> 
> [1] 
> http://www.ebay.com.au/itm/New-HP-USB-MCE-IR-Wireless-Receiver-Windows-7-Vista-/261127073131
> [2] https://www.jaycar.com.au/home-theatre-pc-remote-control/p/XC4939
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: ir-keytable: infinite loops, segfaults

2016-11-17 Thread Sean Young
On Wed, Nov 16, 2016 at 09:52:58PM +1100, Vincent McIntyre wrote:
> I have a fairly old dvico dual digital 4 tuner and remote.
> There seem to be some issues with support for it, can I help fix them?
> 
> I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS,
> with kernel 4.4.0-47-generic (package version 4.4.0-47-generic)
> 
> The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce;
> kernel support for the device is in media/usb/dvb-usb/cxusb.c.
> 
> Mostly it works, in that I get correct keycodes back from evtest
> and ir-keytable -t. But I want to change some of the keycode mappings
> and that is not working.

I suspect the problem here is rc-core is not used and 
legacy_dvb_usb_setkeycode has a bug (it has several problems).

It would be nicer if we could move it rc-core, but for that to work
we need to know what scancodes remote sends (and in what protocol).
A scancode of 0xfe47 is not a valid RC5 scancode.

Would it be possible to test the remote with another device (say an
usb mce receiver or so) and see what scancodes it sends? Then we can
translate the keymap to a real one and make the cxusb driver send
correct scancodes to rc-core.


Sean
--
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 v3 1/2] [media] serial_ir: port lirc_serial to rc-core

2016-11-11 Thread Sean Young
Tested with a homebrew serial ir. Remove last remmants of the nslu2
which could not be enabled.

Signed-off-by: Sean Young <s...@mess.org>
---
 MAINTAINERS  |6 +
 drivers/media/rc/Kconfig |   17 +
 drivers/media/rc/Makefile|1 +
 drivers/media/rc/serial_ir.c | 1003 ++
 drivers/staging/media/lirc/Kconfig   |   13 -
 drivers/staging/media/lirc/Makefile  |1 -
 drivers/staging/media/lirc/lirc_serial.c | 1130 --
 7 files changed, 1027 insertions(+), 1144 deletions(-)
 create mode 100644 drivers/media/rc/serial_ir.c
 delete mode 100644 drivers/staging/media/lirc/lirc_serial.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 93e9f42..cd8fd50 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10604,6 +10604,12 @@ S: Maintained
 F: Documentation/devicetree/bindings/serial/
 F: drivers/tty/serial/
 
+SERIAL IR RECEIVER
+M:     Sean Young <s...@mess.org>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/rc/serial_ir.c
+
 STI CEC DRIVER
 M: Benjamin Gaignard <benjamin.gaign...@linaro.org>
 L: ker...@stlinux.com
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 370e16e..629e8ca 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -389,4 +389,21 @@ config IR_SUNXI
   To compile this driver as a module, choose M here: the module will
   be called sunxi-ir.
 
+config IR_SERIAL
+   tristate "Homebrew Serial Port Receiver"
+   depends on RC_CORE
+   ---help---
+  Say Y if you want to use Homebrew Serial Port Receivers and
+  Transceivers.
+
+  To compile this driver as a module, choose M here: the module will
+  be called serial-ir.
+
+config IR_SERIAL_TRANSMITTER
+   bool "Serial Port Transmitter"
+   default y
+   depends on IR_SERIAL
+   ---help---
+  Serial Port Transmitter support
+
 endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 379a5c0..3a984ee 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
 obj-$(CONFIG_RC_ST) += st_rc.o
 obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
 obj-$(CONFIG_IR_IMG) += img-ir/
+obj-$(CONFIG_IR_SERIAL) += serial_ir.o
diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
new file mode 100644
index 000..378ae09
--- /dev/null
+++ b/drivers/media/rc/serial_ir.c
@@ -0,0 +1,1003 @@
+/*
+ * serial-ir.c
+ *
+ * serial-ir - Device driver that records pulse- and pause-lengths
+ *(space-lengths) between DDCD event on a serial port.
+ *
+ * Copyright (C) 1996,97 Ralph Metzler <r...@thp.uni-koeln.de>
+ * Copyright (C) 1998 Trent Piepho <xy...@u.washington.edu>
+ * Copyright (C) 1998 Ben Pfaff <b...@gnu.org>
+ * Copyright (C) 1999 Christoph Bartelmus <l...@bartelmus.de>
+ * Copyright (C) 2007 Andrei Tanas <and...@tanas.ca> (suspend/resume support)
+ * Copyright (C) 2016 Sean Young <s...@mess.org> (port to rc-core)
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ */
+
+/*
+ * Steve's changes to improve transmission fidelity:
+ *   - for systems with the rdtsc instruction and the clock counter, a
+ * send_pule that times the pulses directly using the counter.
+ * This means that the IR_SERIAL_TRANSMITTER_LATENCY fudge is
+ * not needed. Measurement shows very stable waveform, even where
+ * PCI activity slows the access to the UART, which trips up other
+ * versions.
+ *   - For other system, non-integer-microsecond pulse/space lengths,
+ * done using fixed point binary. So, much more accurate carrier
+ * frequency.
+ *   - fine tuned transmitter latency, taking advantage of fractional
+ * microseconds in previous change
+ *   - Fixed bug in the way transmitter latency was accounted for by
+ * tuning the pulse lengths down - the send_pulse routine ignored
+ * this overhead as it timed the overall pulse length - so the
+ * pulse frequency was right but overall pulse length was too
+ * long. Fixed by accounting for latency on each pulse/space
+ * iteration.
+ *
+ * Steve Davies <st...@daviesfam.org>  July 2001
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#i

[PATCH v3 2/2] [media] serial_ir: use precision ktime rather than guessing

2016-11-11 Thread Sean Young
This makes transmission more reliable and the code much cleaner.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/serial_ir.c | 264 ++-
 1 file changed, 59 insertions(+), 205 deletions(-)

diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
index 378ae09..1ae8425 100644
--- a/drivers/media/rc/serial_ir.c
+++ b/drivers/media/rc/serial_ir.c
@@ -21,29 +21,6 @@
  *  GNU General Public License for more details.
  */
 
-/*
- * Steve's changes to improve transmission fidelity:
- *   - for systems with the rdtsc instruction and the clock counter, a
- * send_pule that times the pulses directly using the counter.
- * This means that the IR_SERIAL_TRANSMITTER_LATENCY fudge is
- * not needed. Measurement shows very stable waveform, even where
- * PCI activity slows the access to the UART, which trips up other
- * versions.
- *   - For other system, non-integer-microsecond pulse/space lengths,
- * done using fixed point binary. So, much more accurate carrier
- * frequency.
- *   - fine tuned transmitter latency, taking advantage of fractional
- * microseconds in previous change
- *   - Fixed bug in the way transmitter latency was accounted for by
- * tuning the pulse lengths down - the send_pulse routine ignored
- * this overhead as it timed the overall pulse length - so the
- * pulse frequency was right but overall pulse length was too
- * long. Fixed by accounting for latency on each pulse/space
- * iteration.
- *
- * Steve Davies <st...@daviesfam.org>  July 2001
- */
-
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
@@ -66,8 +43,8 @@ struct serial_ir_hw {
u8 off;
unsigned set_send_carrier:1;
unsigned set_duty_cycle:1;
-   long (*send_pulse)(unsigned long length);
-   void (*send_space)(long length);
+   void (*send_pulse)(unsigned int length, ktime_t edge);
+   void (*send_space)(void);
spinlock_t lock;
 };
 
@@ -89,11 +66,11 @@ static int sense = -1;  /* -1 = auto, 0 = active high, 
1 = active low */
 static bool txsense;   /* 0 = active high, 1 = active low */
 
 /* forward declarations */
-static long send_pulse_irdeo(unsigned long length);
-static void send_space_irdeo(long length);
+static void send_pulse_irdeo(unsigned int length, ktime_t edge);
+static void send_space_irdeo(void);
 #ifdef CONFIG_IR_SERIAL_TRANSMITTER
-static long send_pulse_homebrew(unsigned long length);
-static void send_space_homebrew(long length);
+static void send_pulse_homebrew(unsigned int length, ktime_t edge);
+static void send_space_homebrew(void);
 #endif
 
 static struct serial_ir_hw hardware[] = {
@@ -139,8 +116,6 @@ static struct serial_ir_hw hardware[] = {
.signal_pin_change = UART_MSR_DDCD,
.on  = 0,
.off = (UART_MCR_RTS | UART_MCR_DTR | UART_MCR_OUT2),
-   .send_pulse = NULL,
-   .send_space = NULL,
},
 
[IR_IGOR] = {
@@ -168,51 +143,11 @@ struct serial_ir {
unsigned int freq;
unsigned int duty_cycle;
 
-   unsigned long period;
-   unsigned long pulse_width, space_width;
+   unsigned int pulse_width, space_width;
 };
 
 static struct serial_ir serial_ir;
 
-#if defined(__i386__)
-/*
- * From:
- * Linux I/O port programming mini-HOWTO
- * Author: Riku Saikkonen <riku.saikko...@hut.fi>
- * v, 28 December 1997
- *
- * [...]
- * Actually, a port I/O instruction on most ports in the 0-0x3ff range
- * takes almost exactly 1 microsecond, so if you're, for example, using
- * the parallel port directly, just do additional inb()s from that port
- * to delay.
- * [...]
- */
-/* transmitter latency 1.5625us 0x1.90 - this figure arrived at from
- * comment above plus trimming to match actual measured frequency.
- * This will be sensitive to cpu speed, though hopefully most of the 1.5us
- * is spent in the uart access.  Still - for reference test machine was a
- * 1.13GHz Athlon system - Steve
- */
-
-/*
- * changed from 400 to 450 as this works better on slower machines;
- * faster machines will use the rdtsc code anyway
- */
-#define IR_SERIAL_TRANSMITTER_LATENCY 450
-
-#else
-
-/* does anybody have information on other platforms ? */
-/* 256 = 1<<8 */
-#define IR_SERIAL_TRANSMITTER_LATENCY 256
-
-#endif /* __i386__ */
-/*
- * FIXME: should we be using hrtimers instead of this
- * IR_SERIAL_TRANSMITTER_LATENCY nonsense?
- */
-
 /* fetch serial input packet (1 byte) from register offset */
 static u8 sinp(int offset)
 {
@@ -264,81 +199,21 @@ static void safe_udelay(unsigned long usecs)
udelay(usecs);
 }
 
-#ifdef USE_RDTSC
-/*
- * This is an overflow/precision juggle, complicated in that we can't
- * do long long divide in the kernel
- */
-
-/*
- * When we use the rdtsc instruction to measure clocks, we keep the
- * pulse and space widths as clock cycles.  As this is CPU speed
- * depend

Re: [PATCH v2 2/2] serial_ir: use precision ktime rather than guessing

2016-11-11 Thread Sean Young
On Fri, Nov 11, 2016 at 11:49:38AM +0800, kbuild test robot wrote:
> Hi Sean,
> 
> [auto build test ERROR on linuxtv-media/master]
> [also build test ERROR on next-20161110]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Sean-Young/serial_ir-port-lirc_serial-to-rc-core/2016-033554
> base:   git://linuxtv.org/media_tree.git master
> config: m68k-allmodconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 4.9.0
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=m68k 
> 
> All errors (new ones prefixed by >>):
> 
> >> ERROR: "__divdi3" [drivers/media/rc/serial_ir.ko] undefined!

Apparently calling ndelay() with 64 bit type causes this on m68k. We don't
need it that wide so I'll down cast it to 32 bit. Expect a v3 later today
or tomorrow.

Thanks
Sean
--
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/2] [media] serial_ir: port lirc_serial to rc-core

2016-11-10 Thread Sean Young
Tested with a homebrew serial ir.

Signed-off-by: Sean Young <s...@mess.org>
---
 MAINTAINERS  |6 +
 drivers/media/rc/Kconfig |   17 +
 drivers/media/rc/Makefile|1 +
 drivers/media/rc/serial_ir.c | 1025 +++
 drivers/staging/media/lirc/Kconfig   |   13 -
 drivers/staging/media/lirc/Makefile  |1 -
 drivers/staging/media/lirc/lirc_serial.c | 1130 --
 7 files changed, 1049 insertions(+), 1144 deletions(-)
 create mode 100644 drivers/media/rc/serial_ir.c
 delete mode 100644 drivers/staging/media/lirc/lirc_serial.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 93e9f42..cd8fd50 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10604,6 +10604,12 @@ S: Maintained
 F: Documentation/devicetree/bindings/serial/
 F: drivers/tty/serial/
 
+SERIAL IR RECEIVER
+M:     Sean Young <s...@mess.org>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/rc/serial_ir.c
+
 STI CEC DRIVER
 M: Benjamin Gaignard <benjamin.gaign...@linaro.org>
 L: ker...@stlinux.com
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 370e16e..629e8ca 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -389,4 +389,21 @@ config IR_SUNXI
   To compile this driver as a module, choose M here: the module will
   be called sunxi-ir.
 
+config IR_SERIAL
+   tristate "Homebrew Serial Port Receiver"
+   depends on RC_CORE
+   ---help---
+  Say Y if you want to use Homebrew Serial Port Receivers and
+  Transceivers.
+
+  To compile this driver as a module, choose M here: the module will
+  be called serial-ir.
+
+config IR_SERIAL_TRANSMITTER
+   bool "Serial Port Transmitter"
+   default y
+   depends on IR_SERIAL
+   ---help---
+  Serial Port Transmitter support
+
 endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 379a5c0..3a984ee 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
 obj-$(CONFIG_RC_ST) += st_rc.o
 obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
 obj-$(CONFIG_IR_IMG) += img-ir/
+obj-$(CONFIG_IR_SERIAL) += serial_ir.o
diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
new file mode 100644
index 000..32db2b7
--- /dev/null
+++ b/drivers/media/rc/serial_ir.c
@@ -0,0 +1,1025 @@
+/*
+ * serial-ir.c
+ *
+ * serial-ir - Device driver that records pulse- and pause-lengths
+ *(space-lengths) between DDCD event on a serial port.
+ *
+ * Copyright (C) 1996,97 Ralph Metzler <r...@thp.uni-koeln.de>
+ * Copyright (C) 1998 Trent Piepho <xy...@u.washington.edu>
+ * Copyright (C) 1998 Ben Pfaff <b...@gnu.org>
+ * Copyright (C) 1999 Christoph Bartelmus <l...@bartelmus.de>
+ * Copyright (C) 2007 Andrei Tanas <and...@tanas.ca> (suspend/resume support)
+ * Copyright (C) 2016 Sean Young <s...@mess.org> (port to rc-core)
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ */
+
+/*
+ * Steve's changes to improve transmission fidelity:
+ *   - for systems with the rdtsc instruction and the clock counter, a
+ * send_pule that times the pulses directly using the counter.
+ * This means that the IR_SERIAL_TRANSMITTER_LATENCY fudge is
+ * not needed. Measurement shows very stable waveform, even where
+ * PCI activity slows the access to the UART, which trips up other
+ * versions.
+ *   - For other system, non-integer-microsecond pulse/space lengths,
+ * done using fixed point binary. So, much more accurate carrier
+ * frequency.
+ *   - fine tuned transmitter latency, taking advantage of fractional
+ * microseconds in previous change
+ *   - Fixed bug in the way transmitter latency was accounted for by
+ * tuning the pulse lengths down - the send_pulse routine ignored
+ * this overhead as it timed the overall pulse length - so the
+ * pulse frequency was right but overall pulse length was too
+ * long. Fixed by accounting for latency on each pulse/space
+ * iteration.
+ *
+ * Steve Davies <st...@daviesfam.org>  July 2001
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "serial_ir"
+
+st

[PATCH v2 2/2] serial_ir: use precision ktime rather than guessing

2016-11-10 Thread Sean Young
This makes transmission more reliable and the code much cleaner.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/serial_ir.c | 260 +--
 1 file changed, 54 insertions(+), 206 deletions(-)

diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
index 32db2b7..1d8b5dd 100644
--- a/drivers/media/rc/serial_ir.c
+++ b/drivers/media/rc/serial_ir.c
@@ -21,31 +21,6 @@
  *  GNU General Public License for more details.
  */
 
-/*
- * Steve's changes to improve transmission fidelity:
- *   - for systems with the rdtsc instruction and the clock counter, a
- * send_pule that times the pulses directly using the counter.
- * This means that the IR_SERIAL_TRANSMITTER_LATENCY fudge is
- * not needed. Measurement shows very stable waveform, even where
- * PCI activity slows the access to the UART, which trips up other
- * versions.
- *   - For other system, non-integer-microsecond pulse/space lengths,
- * done using fixed point binary. So, much more accurate carrier
- * frequency.
- *   - fine tuned transmitter latency, taking advantage of fractional
- * microseconds in previous change
- *   - Fixed bug in the way transmitter latency was accounted for by
- * tuning the pulse lengths down - the send_pulse routine ignored
- * this overhead as it timed the overall pulse length - so the
- * pulse frequency was right but overall pulse length was too
- * long. Fixed by accounting for latency on each pulse/space
- * iteration.
- *
- * Steve Davies <st...@daviesfam.org>  July 2001
- */
-
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
 #include 
 #include 
 #include 
@@ -66,8 +41,8 @@ struct serial_ir_hw {
u8 off;
unsigned set_send_carrier:1;
unsigned set_duty_cycle:1;
-   long (*send_pulse)(unsigned long length);
-   void (*send_space)(long length);
+   void (*send_pulse)(unsigned long length, ktime_t edge);
+   void (*send_space)(void);
spinlock_t lock;
 };
 
@@ -90,11 +65,11 @@ static int sense = -1;  /* -1 = auto, 0 = active high, 
1 = active low */
 static bool txsense;   /* 0 = active high, 1 = active low */
 
 /* forward declarations */
-static long send_pulse_irdeo(unsigned long length);
-static void send_space_irdeo(long length);
+static void send_pulse_irdeo(unsigned long length, ktime_t edge);
+static void send_space_irdeo(void);
 #ifdef CONFIG_IR_SERIAL_TRANSMITTER
-static long send_pulse_homebrew(unsigned long length);
-static void send_space_homebrew(long length);
+static void send_pulse_homebrew(unsigned long length, ktime_t edge);
+static void send_space_homebrew(void);
 #endif
 
 static struct serial_ir_hw hardware[] = {
@@ -140,8 +115,6 @@ static struct serial_ir_hw hardware[] = {
.signal_pin_change = UART_MSR_DDCD,
.on  = 0,
.off = (UART_MCR_RTS | UART_MCR_DTR | UART_MCR_OUT2),
-   .send_pulse = NULL,
-   .send_space = NULL,
},
 
[IR_IGOR] = {
@@ -180,51 +153,11 @@ struct serial_ir {
unsigned int freq;
unsigned int duty_cycle;
 
-   unsigned long period;
unsigned long pulse_width, space_width;
 };
 
 static struct serial_ir serial_ir;
 
-#if defined(__i386__)
-/*
- * From:
- * Linux I/O port programming mini-HOWTO
- * Author: Riku Saikkonen <riku.saikko...@hut.fi>
- * v, 28 December 1997
- *
- * [...]
- * Actually, a port I/O instruction on most ports in the 0-0x3ff range
- * takes almost exactly 1 microsecond, so if you're, for example, using
- * the parallel port directly, just do additional inb()s from that port
- * to delay.
- * [...]
- */
-/* transmitter latency 1.5625us 0x1.90 - this figure arrived at from
- * comment above plus trimming to match actual measured frequency.
- * This will be sensitive to cpu speed, though hopefully most of the 1.5us
- * is spent in the uart access.  Still - for reference test machine was a
- * 1.13GHz Athlon system - Steve
- */
-
-/*
- * changed from 400 to 450 as this works better on slower machines;
- * faster machines will use the rdtsc code anyway
- */
-#define IR_SERIAL_TRANSMITTER_LATENCY 450
-
-#else
-
-/* does anybody have information on other platforms ? */
-/* 256 = 1<<8 */
-#define IR_SERIAL_TRANSMITTER_LATENCY 256
-
-#endif /* __i386__ */
-/*
- * FIXME: should we be using hrtimers instead of this
- * IR_SERIAL_TRANSMITTER_LATENCY nonsense?
- */
-
 /* fetch serial input packet (1 byte) from register offset */
 static u8 sinp(int offset)
 {
@@ -276,81 +209,21 @@ static void safe_udelay(unsigned long usecs)
udelay(usecs);
 }
 
-#ifdef USE_RDTSC
-/*
- * This is an overflow/precision juggle, complicated in that we can't
- * do long long divide in the kernel
- */
-
-/*
- * When we use the rdtsc instruction to measure clocks, we keep the
- * pulse and space widths as clock cycles.  As this is CPU speed
- * dependent, the widths must be

Re: [PATCH 1/2] [media] serial_ir: port lirc_serial to rc-core

2016-11-10 Thread Sean Young
On Thu, Nov 03, 2016 at 03:39:31AM +0800, kbuild test robot wrote:
> Hi Sean,
> 
> [auto build test WARNING on linuxtv-media/master]
> [also build test WARNING on v4.9-rc3 next-20161028]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
> convenience) to record what (public, well-known) commit your patch series was 
> built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
> 
> url:
> https://github.com/0day-ci/linux/commits/Sean-Young/serial_ir-port-lirc_serial-to-rc-core/20161103-014155
> base:   git://linuxtv.org/media_tree.git master
> config: parisc-allyesconfig (attached as .config)
> compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=parisc 
> 
> All warnings (new ones prefixed by >>):
> 
>drivers/media/rc/serial_ir.c: In function 'serial_ir_irq_handler':
> >> drivers/media/rc/serial_ir.c:592:1: warning: the frame size of 1196 bytes 
> >> is larger than 1024 bytes [-Wframe-larger-than=]

Since ktime_t is in nanoseconds, ktime_to_us() does a 64 bit division by 1000
which quite some instructions/stack space on 32 bit parisc. Since the 
ktime_to_us() is just for a printk() it can simply report in nanoseconds
(so use ktime_to_ns() instead). The resulting machine code on parisc 32 bit
is much shorter and the warning goes away.

I'll send out a new version of this patch shortly. Please ignore this
version.

Thanks,

Sean
--
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] ir-kbd-i2c: fix uninitialized variable reference

2016-11-10 Thread Sean Young
On Thu, Nov 10, 2016 at 08:45:24AM +0100, Hans Verkuil wrote:
> Fix compiler warning about uninitialized variable reference:
> 
> ir-kbd-i2c.c: In function 'get_key_haup_common.isra.3':
> ir-kbd-i2c.c:62:2: warning: 'toggle' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
>   printk(KERN_DEBUG MODULE_NAME ": " fmt , ## arg)
>   ^~
> ir-kbd-i2c.c:70:20: note: 'toggle' was declared here
>   int start, range, toggle, dev, code, ircode, vendor;
> ^~

Again this patch already exists (which does exactly the same).

https://patchwork.linuxtv.org/patch/37930/


Sean

> 
> Signed-off-by: Hans Verkuil <hansv...@cisco.com>
> ---
> diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
> index f95a6bc..cede397 100644
> --- a/drivers/media/i2c/ir-kbd-i2c.c
> +++ b/drivers/media/i2c/ir-kbd-i2c.c
> @@ -118,7 +118,7 @@ static int get_key_haup_common(struct IR_i2c *ir, enum 
> rc_type *protocol,
>   *protocol = RC_TYPE_RC6_MCE;
>   dev &= 0x7f;
>   dprintk(1, "ir hauppauge (rc6-mce): t%d vendor=%d 
> dev=%d code=%d\n",
> - toggle, vendor, dev, code);
> + *ptoggle, vendor, dev, code);
>   } else {
>   *ptoggle = 0;
>   *protocol = RC_TYPE_RC6_6A_32;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: dib0700_core.c: uninitialized variable warning, not sure how to fix

2016-11-10 Thread Sean Young
On Thu, Nov 10, 2016 at 08:49:43AM +0100, Hans Verkuil wrote:
> The daily build produces this compiler warning:
> 
> dib0700_core.c: In function 'dib0700_rc_urb_completion':
> dib0700_core.c:787:2: warning: 'protocol' may be used uninitialized in this 
> function [-Wmaybe-uninitialized]
>   rc_keydown(d->rc_dev, protocol, keycode, toggle);
>   ^~~~
> 
> This is indeed correct as there is a path in that function where protocol is
> uninitialized, but I lack the knowledge how this should be fixed.
> 
> Mauro, can you take a look?
> 
> It goes wrong in the switch in case RC_BIT_NEC if the first 'if' is true.
> Note that keycode is also uninitialized, but it is declared as 
> uninitialized_var(),
> although why you would want to do that instead of just initializing it to 0 or
> something like that is a mystery to me.

This is already solved in this patch:

https://patchwork.linuxtv.org/patch/37516/


Sean
--
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 v4l-utils 3/3] ir-keytable: make it possible to select the rc5 streamzap variant

2016-11-09 Thread Sean Young
It was not possible to select the rc-5-sz protocol.

Signed-off-by: Sean Young <s...@mess.org>
---
 utils/keytable/keytable.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 3922ad2..202610a 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -123,6 +123,7 @@ const struct protocol_map_entry protocol_map[] = {
{ "rc5",NULL,   SYSFS_RC5   },
{ "rc-5x",  NULL,   SYSFS_INVALID   },
{ "rc5x",   NULL,   SYSFS_INVALID   },
+   { "rc-5-sz",NULL,   SYSFS_RC5_SZ},
{ "jvc","/jvc_decoder", SYSFS_JVC   },
{ "sony",   "/sony_decoder",SYSFS_SONY  },
{ "sony12", NULL,   SYSFS_INVALID   },
-- 
2.7.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 v4l-utils 1/3] ir-ctl: add ability to send scancodes in most protocols

2016-11-09 Thread Sean Young
Teach ir-ctl to send scancodes. This has a number of uses:

1. Controlling devices through IR transmission aka blasting
2. Testing the in-kernel software IR decoders (2 bugs uncovered so far)
3. Testing the capability of hardware IR decoders

All protocols supported by the kernel are supported except for XMP
and the MCE Keyboard.

Signed-off-by: Sean Young <s...@mess.org>
---
 utils/ir-ctl/Makefile.am |   2 +-
 utils/ir-ctl/ir-ctl.1.in |  82 ++---
 utils/ir-ctl/ir-ctl.c| 130 ++-
 utils/ir-ctl/ir-encode.c | 427 +++
 utils/ir-ctl/ir-encode.h |  35 
 5 files changed, 653 insertions(+), 23 deletions(-)
 create mode 100644 utils/ir-ctl/ir-encode.c
 create mode 100644 utils/ir-ctl/ir-encode.h

diff --git a/utils/ir-ctl/Makefile.am b/utils/ir-ctl/Makefile.am
index 9a1bfed..4c148e5 100644
--- a/utils/ir-ctl/Makefile.am
+++ b/utils/ir-ctl/Makefile.am
@@ -1,6 +1,6 @@
 bin_PROGRAMS = ir-ctl
 man_MANS = ir-ctl.1
 
-ir_ctl_SOURCES = ir-ctl.c
+ir_ctl_SOURCES = ir-ctl.c ir-encode.c
 ir_ctl_LDADD = @LIBINTL@
 ir_ctl_LDFLAGS = $(ARGP_LIBS)
diff --git a/utils/ir-ctl/ir-ctl.1.in b/utils/ir-ctl/ir-ctl.1.in
index 4bdf47e..2efe293 100644
--- a/utils/ir-ctl/ir-ctl.1.in
+++ b/utils/ir-ctl/ir-ctl.1.in
@@ -12,10 +12,13 @@ ir\-ctl \- a swiss\-knife tool to handle raw IR and to set 
lirc options
 [\fIOPTION\fR]... \fI\-\-send\fR [\fIpulse and space file to send\fR]
 .br
 .B ir\-ctl
+[\fIOPTION\fR]... \fI\-\-scancode\fR [\fIprotocol and scancode to send\fR]
+.br
+.B ir\-ctl
 [\fIOPTION\fR]... \fI\-\-record\fR [\fIsave to file\fR]
 .SH DESCRIPTION
 ir\-ctl is a tool that allows one to list the features of a lirc device,
-set its options, record raw IR and send raw IR.
+set its options, record raw IR, send raw IR or send complete IR scancodes.
 .PP
 Note: You need to have read or write permissions on the /dev/lirc device
 for options to work.
@@ -36,6 +39,10 @@ Send IR in text file. It must be in the format described 
below. If this
 option is specified multiple times, send all files in order with 125ms delay
 between them.
 .TP
+\fB-S\fR, \fB\-\-scancode\fR=\fIPROTOCOL:SCANCODE\fR
+Send the IR scancode in the protocol specified. The protocol must one of
+the protocols listed below, followed by a semicolon and the scancode number.
+.TP
 \fB\-1\fR, \fB\-\-oneshot\fR
 When recording, stop recording after the first message, i.e. after a space or
 timeout of more than 19ms is received.
@@ -106,43 +113,74 @@ by length in microseconds. The following is a rc-5 
encoded message:
 .PP
carrier 36000
 .br
-   pulse 920
+   pulse 940
+.br
+   space 860
+.br
+   pulse 1790
+.br
+   space 1750
+.br
+   pulse 880
 .br
-   space 110
+   space 880
 .br
-   pulse 270
+   pulse 900
 .br
-   space 380
+   space 890
 .br
-   pulse 1800
+   pulse 870
 .br
-   space 1560
+   space 900
 .br
-   pulse 1730
+   pulse 1750
 .br
-   space 1630
+   space 900
 .br
-   pulse 1730
+   pulse 890
 .br
-   space 1640
+   space 910
 .br
-   pulse 850
+   pulse 840
 .br
-   space 830
+   space 920
 .br
-   pulse 1690
+   pulse 870
 .br
-   space 820
+   space 920
 .br
-   pulse 860
+   pulse 840
 .br
-   space 1660
+   space 920
 .br
-   pulse 1690
+   pulse 870
 .br
-   space 830
+   space 1810
 .br
-   pulse 850
+   pulse 840
+.PP
+Rather than specifying the raw IR, you can also specify the scancode and
+protocol you want to send. This will also automatically set the correct
+carrier. The above can be written as:
+.PP
+   scancode rc5:0x1e01
+.PP
+Do not specify scancodes with different protocols in one file, as the
+carrier might differ and the transmitter cannot send this. Multiple
+scancodes can be specified in one file but ensure that the rules for the
+protocol are met by inserting an appropriate space between them. Also,
+there are limits to what lirc devices can send in one go.
+.PP
+.SS Supported Protocols
+A scancode with protocol can be specified on the command line or in the
+pulse and space file. The following protocols are supported:
+\fBrc5\fR, \fBrc5x\fR, \fBrc5_sz\fR, \fBjvc\fR, \fBsony12\fR, \fBsony\fB15\fR,
+\fBsony20\fR, \fBnec\fR, \fBnecx\fR, \fBnec32\fR, \fBsanyo\fR, \fBrc6_0\fR,
+\fBrc6_6a_20\fR, \fBrc6_6a_24\fR, \fBrc6_6a_32\fR, \fBrc6_mce\fR, \fBsharp\fR.
+If the scancode starts with 0x it will be interpreted as a
+hexidecimal number, and if it starts with 0 it will be interpreted as an
+octal number.
+.PP
 .SS Wideband and narrowband receiver
 Most IR receivers have a narrowband and wideband receiver. The narrowband
 receiver can receive over longer distances (usually around 10 metres without
@@ -178,6 +216,10 @@ To send the pulse and space file \fBplay\fR on emitter 3:
 .br
\fBir\-ctl \-e 3 \-\-send=play\fR
 .PP
+To send the rc-5 hauppuage '1' scancode:
+.br
+   \fBir\-ctl \-S rc5:

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

2016-11-09 Thread Sean Young
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).

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/ir-nec-decoder.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-nec-decoder.c 
b/drivers/media/rc/ir-nec-decoder.c
index 2a9d155..ba02d05 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -170,7 +170,10 @@ static int ir_nec_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
if (send_32bits) {
/* NEC transport, but modified protocol, used by at
 * least Apple and TiVo remotes */
-   scancode = data->bits;
+   scancode = address << 24 |
+  not_address << 16 |
+  command << 8 |
+  not_command;
IR_dprintk(1, "NEC (modified) scancode 0x%08x\n", 
scancode);
rc_type = RC_TYPE_NEC32;
} else if ((address ^ not_address) != 0xff) {
-- 
2.7.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] sanyo decoder: address was being truncated

2016-11-09 Thread Sean Young
The address is 13 bits but it was stuffed in an u8, so 5 bits are
missing from the scancode.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/ir-sanyo-decoder.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-sanyo-decoder.c 
b/drivers/media/rc/ir-sanyo-decoder.c
index 7331e5e7..b07d9ca 100644
--- a/drivers/media/rc/ir-sanyo-decoder.c
+++ b/drivers/media/rc/ir-sanyo-decoder.c
@@ -56,7 +56,8 @@ static int ir_sanyo_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
 {
struct sanyo_dec *data = >raw->sanyo;
u32 scancode;
-   u8 address, command, not_command;
+   u16 address;
+   u8 command, not_command;
 
if (!is_timing_event(ev)) {
if (ev.reset) {
-- 
2.7.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 v4l-utils 2/3] ir-ctl: add verbose option

2016-11-09 Thread Sean Young
This is useful to see what IR is actually being sent (e.g. after
scancode generation).

Signed-off-by: Sean Young <s...@mess.org>
---
 utils/ir-ctl/ir-ctl.1.in |  3 +++
 utils/ir-ctl/ir-ctl.c| 15 ++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/utils/ir-ctl/ir-ctl.1.in b/utils/ir-ctl/ir-ctl.1.in
index 2efe293..a1d5aeb 100644
--- a/utils/ir-ctl/ir-ctl.1.in
+++ b/utils/ir-ctl/ir-ctl.1.in
@@ -99,6 +99,9 @@ Prints the help message
 \fB\-\-usage\fR
 Give a short usage message
 .TP
+\fB\-v\fR, \fB\-\-verbose\fR
+Verbose output; this prints the IR before sending.
+.TP
 \fB\-V\fR, \fB\-\-version\fR
 print the v4l2\-utils version
 .PP
diff --git a/utils/ir-ctl/ir-ctl.c b/utils/ir-ctl/ir-ctl.c
index bdea741..f19bd05 100644
--- a/utils/ir-ctl/ir-ctl.c
+++ b/utils/ir-ctl/ir-ctl.c
@@ -65,6 +65,7 @@ struct arguments {
char *device;
bool features;
bool record;
+   bool verbose;
struct file *send;
bool oneshot;
char *savetofile;
@@ -85,6 +86,7 @@ static const struct argp_option options[] = {
{ "record", 'r',N_("FILE"), OPTION_ARG_OPTIONAL,
N_("record IR to stdout or file") },
{ "send",   's',N_("FILE"), 0,  N_("send IR pulse and 
space file") },
{ "scancode", 'S',  N_("SCANCODE"), 0,  N_("send IR scancode in 
protocol specified") },
+   { "verbose",'v',0,  0,  N_("verbose output") },
{ .doc = N_("Recording options:") },
{ "one-shot",   '1',0,  0,  N_("end recording after 
first message") },
{ "wideband",   'w',0,  0,  N_("use wideband 
receiver aka learning mode") },
@@ -397,6 +399,9 @@ static error_t parse_opt(int k, char *arg, struct 
argp_state *state)
case '1':
arguments->oneshot = true;
break;
+   case 'v':
+   arguments->verbose = true;
+   break;
case 'm':
if (arguments->carrier_reports == 2)
argp_error(state, _("cannot enable and disable carrier 
reports"));
@@ -515,7 +520,7 @@ static error_t parse_opt(int k, char *arg, struct 
argp_state *state)
return ARGP_ERR_UNKNOWN;
}
 
-   if (k != '1' && k != 'd')
+   if (k != '1' && k != 'd' && k != 'v')
arguments->work_to_do = true;
 
return 0;
@@ -739,6 +744,12 @@ static int lirc_send(struct arguments *args, int fd, 
unsigned features, struct f
lirc_set_send_carrier(fd, dev, features, f->carrier);
 
size_t size = f->len * sizeof(unsigned);
+   if (args->verbose) {
+   int i;
+   printf("Sending:\n");
+   for (i=0; ilen; i++)
+   printf("%s %u\n", i & 1 ? "space" : "pulse", f->buf[i]);
+   }
ssize_t ret = TEMP_FAILURE_RETRY(write(fd, f->buf, size));
if (ret < 0) {
fprintf(stderr, _("%s: failed to send: %m\n"), dev);
@@ -752,6 +763,8 @@ static int lirc_send(struct arguments *args, int fd, 
unsigned features, struct f
size / sizeof(unsigned));
return EX_IOERR;
}
+   if (args->verbose)
+   printf("Successfully sent\n");
 
return 0;
 }
-- 
2.7.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


Re: [PATCH] media: fix uninitialized variable warning in dib0700_rc_urb_completion()

2016-11-08 Thread Sean Young
On Mon, Nov 07, 2016 at 08:41:12AM -0700, Shuah Khan wrote:
> Fix the following uninitialized variable compiler warning:
> 
> drivers/media/usb/dvb-usb/dib0700_core.c: In function 
> ‘dib0700_rc_urb_completion’:
>  drivers/media/usb/dvb-usb/dib0700_core.c:763:2: warning: ‘protocol’ may be 
> used uninitialized in this function [-Wmaybe-uninitialized]
>rc_keydown(d->rc_dev, protocol, keycode, toggle);
>^~~~
> 
> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
> ---
>  drivers/media/usb/dvb-usb/dib0700_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c 
> b/drivers/media/usb/dvb-usb/dib0700_core.c
> index f319665..cfe28ec 100644
> --- a/drivers/media/usb/dvb-usb/dib0700_core.c
> +++ b/drivers/media/usb/dvb-usb/dib0700_core.c
> @@ -676,7 +676,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
>  {
>   struct dvb_usb_device *d = purb->context;
>   struct dib0700_rc_response *poll_reply;
> - enum rc_type protocol;
> + enum rc_type protocol = RC_TYPE_UNKNOWN;
>   u32 uninitialized_var(keycode);
>   u8 toggle;
>  

There is another (better) fix for it here:

https://patchwork.linuxtv.org/patch/37516/


Thanks
Sean
--
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/2] [media] lirc: remove lirc_serial driver

2016-11-02 Thread Sean Young
On Wed, Nov 02, 2016 at 02:00:16PM -0700, VDR User wrote:
> > serial_ir driver in rc-core
> 
> Which kernel did this happen in? I don't see a sign of it in 4.8.5 and
> I want to make sure that homebrew serial devices still work with lirc
> after this. Are you sure the serial_ir driver you refer to isn't about
> a usb-based serial ir?

See patch 1/2. That introduces the serial_ir rc-core driver. 

http://www.spinics.net/lists/linux-media/msg107352.html


Sean
--
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/2] [media] lirc: remove lirc_serial driver

2016-11-02 Thread Sean Young
This has been replaced by the serial_ir driver in rc-core.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/staging/media/lirc/Kconfig   |   13 -
 drivers/staging/media/lirc/Makefile  |1 -
 drivers/staging/media/lirc/lirc_serial.c | 1130 --
 3 files changed, 1144 deletions(-)
 delete mode 100644 drivers/staging/media/lirc/lirc_serial.c

diff --git a/drivers/staging/media/lirc/Kconfig 
b/drivers/staging/media/lirc/Kconfig
index 6879c46..25b7e7c 100644
--- a/drivers/staging/media/lirc/Kconfig
+++ b/drivers/staging/media/lirc/Kconfig
@@ -38,19 +38,6 @@ config LIRC_SASEM
help
  Driver for the Sasem OnAir Remocon-V or Dign HV5 HTPC IR/VFD Module
 
-config LIRC_SERIAL
-   tristate "Homebrew Serial Port Receiver"
-   depends on LIRC
-   help
- Driver for Homebrew Serial Port Receivers
-
-config LIRC_SERIAL_TRANSMITTER
-   bool "Serial Port Transmitter"
-   default y
-   depends on LIRC_SERIAL
-   help
- Serial Port Transmitter support
-
 config LIRC_SIR
tristate "Built-in SIR IrDA port"
depends on LIRC
diff --git a/drivers/staging/media/lirc/Makefile 
b/drivers/staging/media/lirc/Makefile
index 5430adf..7f919ea 100644
--- a/drivers/staging/media/lirc/Makefile
+++ b/drivers/staging/media/lirc/Makefile
@@ -7,6 +7,5 @@ obj-$(CONFIG_LIRC_BT829)+= lirc_bt829.o
 obj-$(CONFIG_LIRC_IMON)+= lirc_imon.o
 obj-$(CONFIG_LIRC_PARALLEL)+= lirc_parallel.o
 obj-$(CONFIG_LIRC_SASEM)   += lirc_sasem.o
-obj-$(CONFIG_LIRC_SERIAL)  += lirc_serial.o
 obj-$(CONFIG_LIRC_SIR) += lirc_sir.o
 obj-$(CONFIG_LIRC_ZILOG)   += lirc_zilog.o
diff --git a/drivers/staging/media/lirc/lirc_serial.c 
b/drivers/staging/media/lirc/lirc_serial.c
deleted file mode 100644
index b798b31..000
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ /dev/null
@@ -1,1130 +0,0 @@
-/*
- * lirc_serial.c
- *
- * lirc_serial - Device driver that records pulse- and pause-lengths
- *(space-lengths) between DDCD event on a serial port.
- *
- * Copyright (C) 1996,97 Ralph Metzler <r...@thp.uni-koeln.de>
- * Copyright (C) 1998 Trent Piepho <xy...@u.washington.edu>
- * Copyright (C) 1998 Ben Pfaff <b...@gnu.org>
- * Copyright (C) 1999 Christoph Bartelmus <l...@bartelmus.de>
- * Copyright (C) 2007 Andrei Tanas <and...@tanas.ca> (suspend/resume support)
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- *
- */
-
-/*
- * Steve's changes to improve transmission fidelity:
- *   - for systems with the rdtsc instruction and the clock counter, a
- * send_pule that times the pulses directly using the counter.
- * This means that the LIRC_SERIAL_TRANSMITTER_LATENCY fudge is
- * not needed. Measurement shows very stable waveform, even where
- * PCI activity slows the access to the UART, which trips up other
- * versions.
- *   - For other system, non-integer-microsecond pulse/space lengths,
- * done using fixed point binary. So, much more accurate carrier
- * frequency.
- *   - fine tuned transmitter latency, taking advantage of fractional
- * microseconds in previous change
- *   - Fixed bug in the way transmitter latency was accounted for by
- * tuning the pulse lengths down - the send_pulse routine ignored
- * this overhead as it timed the overall pulse length - so the
- * pulse frequency was right but overall pulse length was too
- * long. Fixed by accounting for latency on each pulse/space
- * iteration.
- *
- * Steve Davies <st...@daviesfam.org>  July 2001
- */
-
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/* From Intel IXP42X Developer's Manual (#252480-005): */
-/* ftp://download.intel.com/design/network/manuals/25248005.pdf */
-#define UART_IE_IXP42X_UUE   0x40 /* IXP42X UART Unit enable */
-#define UART_IE_IXP42X_RTOIE 0x10 /* IXP42X Receiver Data Timeout int.enable */
-
-#include 
-#include 
-
-#define LIRC_DRIVER_NAME "lirc_serial&quo

[PATCH 1/2] [media] serial_ir: port lirc_serial to rc-core

2016-11-02 Thread Sean Young
Tested with a homebrew serial ir.

Signed-off-by: Sean Young <s...@mess.org>
---
 MAINTAINERS  |6 +
 drivers/media/rc/Kconfig |   17 +
 drivers/media/rc/Makefile|1 +
 drivers/media/rc/serial_ir.c | 1020 ++
 4 files changed, 1044 insertions(+)
 create mode 100644 drivers/media/rc/serial_ir.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 93e9f42..cd8fd50 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10604,6 +10604,12 @@ S: Maintained
 F: Documentation/devicetree/bindings/serial/
 F: drivers/tty/serial/
 
+SERIAL IR RECEIVER
+M:     Sean Young <s...@mess.org>
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/rc/serial_ir.c
+
 STI CEC DRIVER
 M: Benjamin Gaignard <benjamin.gaign...@linaro.org>
 L: ker...@stlinux.com
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 370e16e..629e8ca 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -389,4 +389,21 @@ config IR_SUNXI
   To compile this driver as a module, choose M here: the module will
   be called sunxi-ir.
 
+config IR_SERIAL
+   tristate "Homebrew Serial Port Receiver"
+   depends on RC_CORE
+   ---help---
+  Say Y if you want to use Homebrew Serial Port Receivers and
+  Transceivers.
+
+  To compile this driver as a module, choose M here: the module will
+  be called serial-ir.
+
+config IR_SERIAL_TRANSMITTER
+   bool "Serial Port Transmitter"
+   default y
+   depends on IR_SERIAL
+   ---help---
+  Serial Port Transmitter support
+
 endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 379a5c0..3a984ee 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
 obj-$(CONFIG_RC_ST) += st_rc.o
 obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
 obj-$(CONFIG_IR_IMG) += img-ir/
+obj-$(CONFIG_IR_SERIAL) += serial_ir.o
diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
new file mode 100644
index 000..77193c3
--- /dev/null
+++ b/drivers/media/rc/serial_ir.c
@@ -0,0 +1,1020 @@
+/*
+ * serial-ir.c
+ *
+ * serial-ir - Device driver that records pulse- and pause-lengths
+ *(space-lengths) between DDCD event on a serial port.
+ *
+ * Copyright (C) 1996,97 Ralph Metzler <r...@thp.uni-koeln.de>
+ * Copyright (C) 1998 Trent Piepho <xy...@u.washington.edu>
+ * Copyright (C) 1998 Ben Pfaff <b...@gnu.org>
+ * Copyright (C) 1999 Christoph Bartelmus <l...@bartelmus.de>
+ * Copyright (C) 2007 Andrei Tanas <and...@tanas.ca> (suspend/resume support)
+ * Copyright (C) 2016 Sean Young <s...@mess.org> (port to rc-core)
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ */
+
+/*
+ * Steve's changes to improve transmission fidelity:
+ *   - for systems with the rdtsc instruction and the clock counter, a
+ * send_pule that times the pulses directly using the counter.
+ * This means that the IR_SERIAL_TRANSMITTER_LATENCY fudge is
+ * not needed. Measurement shows very stable waveform, even where
+ * PCI activity slows the access to the UART, which trips up other
+ * versions.
+ *   - For other system, non-integer-microsecond pulse/space lengths,
+ * done using fixed point binary. So, much more accurate carrier
+ * frequency.
+ *   - fine tuned transmitter latency, taking advantage of fractional
+ * microseconds in previous change
+ *   - Fixed bug in the way transmitter latency was accounted for by
+ * tuning the pulse lengths down - the send_pulse routine ignored
+ * this overhead as it timed the overall pulse length - so the
+ * pulse frequency was right but overall pulse length was too
+ * long. Fixed by accounting for latency on each pulse/space
+ * iteration.
+ *
+ * Steve Davies <st...@daviesfam.org>  July 2001
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* From Intel IXP42X Developer's Manual (#252480-005): */
+/* ftp://download.intel.com/design/network/manuals/25248005.pdf */
+#define UART_IE_IXP42X_UUE   0x40 /* IXP42X UART Unit enable */
+#define UART_IE_IXP42X_RTOIE 0x10 /* IXP42X Receiver Data Timeout int.enable */
+
+#define DRIVER_NAME "serial_ir"
+
+struct serial_ir 

Re: [PATCH v3 0/6] Add support for IR transmitters

2016-11-02 Thread Sean Young
On Wed, Nov 02, 2016 at 07:40:04PM +0900, Andi Shyti wrote:
> The main goal is to add support in the rc framework for IR
> transmitters, which currently is only supported by lirc but that
> is not the preferred way.
> 
> The last patch adds support for an IR transmitter driven by
> the MOSI line of an SPI controller, it's the case of the Samsung
> TM2(e) board which support is currently ongoing.
> 
> The last patch adds support for an IR transmitter driven by
> the MOSI line of an SPI controller, it's the case of the Samsung
> TM2(e) board which support is currently ongoing.

Looks great! For the whole series:

Reviewed-by: Sean Young <s...@mess.org>

Thanks,
Sean
--
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] dib0700: fix nec repeat handling

2016-11-02 Thread Sean Young
On Sat, Oct 29, 2016 at 11:04:32PM +0200, Arnd Bergmann wrote:
> On Thursday, October 13, 2016 10:28:44 PM CEST Sean Young wrote:
> > When receiving a nec repeat, ensure the correct scancode is repeated
> > rather than a random value from the stack. This removes the need
> > for the bogus uninitialized_var() and also fixes the warnings:
> > 
> > drivers/media/usb/dvb-usb/dib0700_core.c: In function 
> > ‘dib0700_rc_urb_completion’:
> > drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may 
> > be used uninitialized in this function
> > 
> > Signed-off-by: Sean Young <s...@mess.org>
> > ---
> >  drivers/media/usb/dvb-usb/dib0700_core.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Acked-by: Arnd Bergmann <a...@arndb.de>
> Cc: sta...@vger.kernel.org
> Fixes: 2ceeca0499d7 ("[media] rc: split nec protocol into its three variants")
> Fixes: d3c501d1938c ("V4L/DVB: dib0700: Fix RC protocol logic to properly 
> handle NEC/NECx and RC-5")
> 
> 
> The warning is gone for me too, so this obsoletes both
> https://patchwork.linuxtv.org/patch/37494/ and
> https://patchwork.kernel.org/patch/9380747/
> 
> Can we get this patch merged into v4.9 soonish? The warning
> is currently disabled, but I'd like to make sure it gets turned
> on again by default, and we should fix all the actual bugs in
> the process.

So after writing the patch and submitting it, I've bought the hardware on
ebay. Without this patch you get random scancodes on nec repeats, which
the patch indeed fixes.

Tested-by: Sean Young <s...@mess.org>

Note that this has been broken forever, so it is not a regression, so 
does it belong in stable?
 

Sean
--
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 5/7] [media] ir-lirc-codec: don't wait any transmitting time for tx only devices

2016-11-01 Thread Sean Young

Hi Andi,

On Tue, Nov 01, 2016 at 03:51:11PM +0900, Andi Shyti wrote:
> > Andi, it would be good to know what the use-case for the original change is.
> 
> the use case is the ir-spi itself which doesn't need the lirc to
> perform any waiting on its behalf.

Here is the crux of the problem: in the ir-spi case no wait will actually 
happen here, and certainly no "over-wait". The patch below will not change
behaviour at all.

In the ir-spi case, "towait" will be 0 and no wait happens.

I think the code is already in good shape but somehow there is a 
misunderstanding. Did I miss something?


Sean

> To me it just doesn't look right to simulate a fake transmission
> period and wait unnecessary time. Of course, the "over-wait" is not
> a big deal and at the end we can decide to drop it.
> 
> Otherwise, an alternative could be to add the boolean
> 'tx_no_wait' in the rc_dev structure. It could be set by the
> device driver during the initialization and the we can follow
> your approach.
> 
> Something like this:
> 
> diff --git a/drivers/media/rc/ir-lirc-codec.c 
> b/drivers/media/rc/ir-lirc-codec.c
> index c327730..4553d04 100644
> --- a/drivers/media/rc/ir-lirc-codec.c
> +++ b/drivers/media/rc/ir-lirc-codec.c
> @@ -161,15 +161,19 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> const char __user *buf,
>  
> ret *= sizeof(unsigned int);
>  
> -   /*
> -* The lircd gap calculation expects the write function to
> -* wait for the actual IR signal to be transmitted before
> -* returning.
> -*/
> -   towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
> -   if (towait > 0) {
> -   set_current_state(TASK_INTERRUPTIBLE);
> -   schedule_timeout(usecs_to_jiffies(towait));
> +   if (!dev->tx_no_wait) {
> +   /*
> +* The lircd gap calculation expects the write function to
> +* wait for the actual IR signal to be transmitted before
> +* returning.
> +*/
> +   towait = ktime_us_delta(ktime_add_us(start, duration),
> +   ktime_get());
> +   if (towait > 0) {
> +   set_current_state(TASK_INTERRUPTIBLE);
> +   schedule_timeout(usecs_to_jiffies(towait));
> +   }
> +
> }
>  
>  out:
> diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
> index fcda1e4..e44abfa 100644
> --- a/drivers/media/rc/ir-spi.c
> +++ b/drivers/media/rc/ir-spi.c
> @@ -149,6 +149,7 @@ static int ir_spi_probe(struct spi_device *spi)
> if (!idata->rc)
> return -ENOMEM;
>  
> +   idata->rc->tx_no_wait  = true;
> idata->rc->tx_ir   = ir_spi_tx;
> idata->rc->s_tx_carrier= ir_spi_set_tx_carrier;
> idata->rc->s_tx_duty_cycle = ir_spi_set_duty_cycle;
> diff --git a/include/media/rc-core.h b/include/media/rc-core.h
> index fe0c9c4..c3ced9b 100644
> --- a/include/media/rc-core.h
> +++ b/include/media/rc-core.h
> @@ -85,6 +85,9 @@ enum rc_filter_type {
>   * @input_dev: the input child device used to communicate events to userspace
>   * @driver_type: specifies if protocol decoding is done in hardware or 
> software
>   * @idle: used to keep track of RX state
> + * @tx_no_wait: decides whether to perform or not a sync write or not. The
> + *  device driver setting it to true must make sure to not break the ABI
> + *  which requires a sync transfer.
>   * @allowed_protocols: bitmask with the supported RC_BIT_* protocols
>   * @enabled_protocols: bitmask with the enabled RC_BIT_* protocols
>   * @allowed_wakeup_protocols: bitmask with the supported RC_BIT_* wakeup 
> protocols
> @@ -147,6 +150,7 @@ struct rc_dev {
> struct input_dev*input_dev;
> enum rc_driver_type driver_type;
> boolidle;
> +   booltx_no_wait;
> u64 allowed_protocols;
> u64 enabled_protocols;
> u64 allowed_wakeup_protocols;
> 
> Thanks,
> Andi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 5/9] [media] redrat3: enable carrier reports using wideband receiver

2016-10-31 Thread Sean Young
The wideband receiver is a little awkward on the redrat3. Data arrives
on a different endpoint, and the learning command must be reissued
every time data is learned.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/redrat3.c | 186 ++---
 1 file changed, 140 insertions(+), 46 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index eaf374d..1882712 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -81,6 +81,8 @@
 #define RR3_RC_DET_ENABLE  0xbb
 /* Stop capture with the RC receiver */
 #define RR3_RC_DET_DISABLE 0xbc
+/* Start capture with the wideband receiver */
+#define RR3_MODSIG_CAPTURE 0xb2
 /* Return the status of RC detector capture */
 #define RR3_RC_DET_STATUS  0xbd
 /* Reset redrat */
@@ -105,8 +107,10 @@
 #define RR3_CLK_PER_COUNT  12
 /* (RR3_CLK / RR3_CLK_PER_COUNT) */
 #define RR3_CLK_CONV_FACTOR200
-/* USB bulk-in IR data endpoint address */
-#define RR3_BULK_IN_EP_ADDR0x82
+/* USB bulk-in wideband IR data endpoint address */
+#define RR3_WIDE_IN_EP_ADDR0x81
+/* USB bulk-in narrowband IR data endpoint address */
+#define RR3_NARROW_IN_EP_ADDR  0x82
 
 /* Size of the fixed-length portion of the signal */
 #define RR3_DRIVER_MAXLENS 128
@@ -207,15 +211,22 @@ struct redrat3_dev {
struct urb *flash_urb;
u8 flash_in_buf;
 
+   /* learning */
+   bool wideband;
+   struct usb_ctrlrequest learn_control;
+   struct urb *learn_urb;
+   u8 learn_buf;
+
/* save off the usb device pointer */
struct usb_device *udev;
 
/* the receive endpoint */
-   struct usb_endpoint_descriptor *ep_in;
+   struct usb_endpoint_descriptor *ep_narrow;
/* the buffer to receive data */
void *bulk_in_buf;
/* urb used to read ir data */
-   struct urb *read_urb;
+   struct urb *narrow_urb;
+   struct urb *wide_urb;
 
/* the send endpoint */
struct usb_endpoint_descriptor *ep_out;
@@ -236,23 +247,6 @@ struct redrat3_dev {
char phys[64];
 };
 
-/*
- * redrat3_issue_async
- *
- *  Issues an async read to the ir data in port..
- *  sets the callback to be redrat3_handle_async
- */
-static void redrat3_issue_async(struct redrat3_dev *rr3)
-{
-   int res;
-
-   res = usb_submit_urb(rr3->read_urb, GFP_ATOMIC);
-   if (res)
-   dev_dbg(rr3->dev,
-   "%s: receive request FAILED! (res %d, len %d)\n",
-   __func__, res, rr3->read_urb->transfer_buffer_length);
-}
-
 static void redrat3_dump_fw_error(struct redrat3_dev *rr3, int code)
 {
if (!rr3->transmitting && (code != 0x40))
@@ -367,6 +361,14 @@ static void redrat3_process_ir_data(struct redrat3_dev 
*rr3)
 
mod_freq = redrat3_val_to_mod_freq(>irdata);
dev_dbg(dev, "Got mod_freq of %u\n", mod_freq);
+   if (mod_freq && rr3->wideband) {
+   DEFINE_IR_RAW_EVENT(ev);
+
+   ev.carrier_report = 1;
+   ev.carrier = mod_freq;
+
+   ir_raw_event_store(rr3->rc, );
+   }
 
/* process each rr3 encoded byte into an int */
sig_size = be16_to_cpu(rr3->irdata.sig_size);
@@ -449,19 +451,31 @@ static int redrat3_enable_detector(struct redrat3_dev 
*rr3)
return -EIO;
}
 
-   redrat3_issue_async(rr3);
+   ret = usb_submit_urb(rr3->narrow_urb, GFP_KERNEL);
+   if (ret) {
+   dev_err(rr3->dev, "narrow band urb failed: %d", ret);
+   return ret;
+   }
 
-   return 0;
+   ret = usb_submit_urb(rr3->wide_urb, GFP_KERNEL);
+   if (ret)
+   dev_err(rr3->dev, "wide band urb failed: %d", ret);
+
+   return ret;
 }
 
 static inline void redrat3_delete(struct redrat3_dev *rr3,
  struct usb_device *udev)
 {
-   usb_kill_urb(rr3->read_urb);
+   usb_kill_urb(rr3->narrow_urb);
+   usb_kill_urb(rr3->wide_urb);
usb_kill_urb(rr3->flash_urb);
-   usb_free_urb(rr3->read_urb);
+   usb_kill_urb(rr3->learn_urb);
+   usb_free_urb(rr3->narrow_urb);
+   usb_free_urb(rr3->wide_urb);
usb_free_urb(rr3->flash_urb);
-   usb_free_coherent(udev, le16_to_cpu(rr3->ep_in->wMaxPacketSize),
+   usb_free_urb(rr3->learn_urb);
+   usb_free_coherent(udev, le16_to_cpu(rr3->ep_narrow->wMaxPacketSize),
  rr3->bulk_in_buf, rr3->dma_in);
 
kfree(rr3);
@@ -694,9 +708,19 @@ static void redrat3_handle_async(struct urb *urb)
switch (urb->status) {
case 0:
ret = redrat3_get_ir_data(rr3, urb->actual_length);
+   if (!ret && rr3->wideband && !rr3->learn_urb->hcpriv) {
+   

[PATCH 5/9] [media] redrat3: enable carrier reports using wideband receiver

2016-10-31 Thread Sean Young
The wideband receiver is a little awkward on the redrat3. Data arrives
on a different endpoint, and the learning command must be reissued
every time data is learned.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/redrat3.c | 184 ++---
 1 file changed, 140 insertions(+), 44 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index eaf374d..4370d21 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -81,6 +81,8 @@
 #define RR3_RC_DET_ENABLE  0xbb
 /* Stop capture with the RC receiver */
 #define RR3_RC_DET_DISABLE 0xbc
+/* Start capture with the wideband receiver */
+#define RR3_MODSIG_CAPTURE 0xb2
 /* Return the status of RC detector capture */
 #define RR3_RC_DET_STATUS  0xbd
 /* Reset redrat */
@@ -105,8 +107,10 @@
 #define RR3_CLK_PER_COUNT  12
 /* (RR3_CLK / RR3_CLK_PER_COUNT) */
 #define RR3_CLK_CONV_FACTOR200
-/* USB bulk-in IR data endpoint address */
-#define RR3_BULK_IN_EP_ADDR0x82
+/* USB bulk-in wideband IR data endpoint address */
+#define RR3_WIDE_IN_EP_ADDR0x81
+/* USB bulk-in narrowband IR data endpoint address */
+#define RR3_NARROW_IN_EP_ADDR  0x82
 
 /* Size of the fixed-length portion of the signal */
 #define RR3_DRIVER_MAXLENS 128
@@ -207,15 +211,22 @@ struct redrat3_dev {
struct urb *flash_urb;
u8 flash_in_buf;
 
+   /* learning */
+   bool wideband;
+   struct usb_ctrlrequest learn_control;
+   struct urb *learn_urb;
+   u8 learn_buf;
+
/* save off the usb device pointer */
struct usb_device *udev;
 
/* the receive endpoint */
-   struct usb_endpoint_descriptor *ep_in;
+   struct usb_endpoint_descriptor *ep_narrow;
/* the buffer to receive data */
void *bulk_in_buf;
/* urb used to read ir data */
-   struct urb *read_urb;
+   struct urb *narrow_urb;
+   struct urb *wide_urb;
 
/* the send endpoint */
struct usb_endpoint_descriptor *ep_out;
@@ -236,23 +247,6 @@ struct redrat3_dev {
char phys[64];
 };
 
-/*
- * redrat3_issue_async
- *
- *  Issues an async read to the ir data in port..
- *  sets the callback to be redrat3_handle_async
- */
-static void redrat3_issue_async(struct redrat3_dev *rr3)
-{
-   int res;
-
-   res = usb_submit_urb(rr3->read_urb, GFP_ATOMIC);
-   if (res)
-   dev_dbg(rr3->dev,
-   "%s: receive request FAILED! (res %d, len %d)\n",
-   __func__, res, rr3->read_urb->transfer_buffer_length);
-}
-
 static void redrat3_dump_fw_error(struct redrat3_dev *rr3, int code)
 {
if (!rr3->transmitting && (code != 0x40))
@@ -367,6 +361,14 @@ static void redrat3_process_ir_data(struct redrat3_dev 
*rr3)
 
mod_freq = redrat3_val_to_mod_freq(>irdata);
dev_dbg(dev, "Got mod_freq of %u\n", mod_freq);
+   if (mod_freq && rr3->wideband) {
+   DEFINE_IR_RAW_EVENT(ev);
+
+   ev.carrier_report = 1;
+   ev.carrier = mod_freq;
+
+   ir_raw_event_store(rr3->rc, );
+   }
 
/* process each rr3 encoded byte into an int */
sig_size = be16_to_cpu(rr3->irdata.sig_size);
@@ -449,19 +451,31 @@ static int redrat3_enable_detector(struct redrat3_dev 
*rr3)
return -EIO;
}
 
-   redrat3_issue_async(rr3);
+   ret = usb_submit_urb(rr3->narrow_urb, GFP_KERNEL);
+   if (ret) {
+   dev_err(rr3->dev, "narrow band urb failed: %d", ret);
+   return ret;
+   }
 
-   return 0;
+   ret = usb_submit_urb(rr3->wide_urb, GFP_KERNEL);
+   if (ret)
+   dev_err(rr3->dev, "wide band urb failed: %d", ret);
+
+   return ret;
 }
 
 static inline void redrat3_delete(struct redrat3_dev *rr3,
  struct usb_device *udev)
 {
-   usb_kill_urb(rr3->read_urb);
+   usb_kill_urb(rr3->narrow_urb);
+   usb_kill_urb(rr3->wide_urb);
usb_kill_urb(rr3->flash_urb);
-   usb_free_urb(rr3->read_urb);
+   usb_kill_urb(rr3->learn_urb);
+   usb_free_urb(rr3->narrow_urb);
+   usb_free_urb(rr3->wide_urb);
usb_free_urb(rr3->flash_urb);
-   usb_free_coherent(udev, le16_to_cpu(rr3->ep_in->wMaxPacketSize),
+   usb_free_urb(rr3->learn_urb);
+   usb_free_coherent(udev, le16_to_cpu(rr3->ep_narrow->wMaxPacketSize),
  rr3->bulk_in_buf, rr3->dma_in);
 
kfree(rr3);
@@ -694,9 +708,19 @@ static void redrat3_handle_async(struct urb *urb)
switch (urb->status) {
case 0:
ret = redrat3_get_ir_data(rr3, urb->actual_length);
+   if (!ret && rr3->wideband && !rr3->learn_urb->hcpriv) {
+   

[PATCH 9/9] [media] lirc: use-after free while reading from device and unplugging

2016-10-31 Thread Sean Young
Many lirc drivers have their own receive buffers which are freed on
unplug (e.g. ir_lirc_unregister). This means that ir->buf->wait_poll
will be freed directly after unplug so do not remove yourself from the
wait queue.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/lirc_dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 60fd106..b0c79a5 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -718,7 +718,7 @@ ssize_t lirc_dev_fop_read(struct file *file,
 
if (!ir->attached) {
ret = -ENODEV;
-   break;
+   goto out_locked;
}
} else {
lirc_buffer_read(ir->buf, buf);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 4/9] [media] redrat3: fix error paths in probe

2016-10-31 Thread Sean Young
If redrat3_delete() is called, ensure ep_in and udev members are set
up so we don't dereference null in the error path. Also ensure that
rc dev device exists before we enable the receiver and that the
led urb exists before we create the led device.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/redrat3.c | 49 ++
 1 file changed, 23 insertions(+), 26 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 23180ec..eaf374d 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -982,17 +982,19 @@ static int redrat3_dev_probe(struct usb_interface *intf,
goto no_endpoints;
 
rr3->dev = >dev;
+   rr3->ep_in = ep_in;
+   rr3->ep_out = ep_out;
+   rr3->udev = udev;
 
/* set up bulk-in endpoint */
rr3->read_urb = usb_alloc_urb(0, GFP_KERNEL);
if (!rr3->read_urb)
-   goto error;
+   goto redrat_free;
 
-   rr3->ep_in = ep_in;
rr3->bulk_in_buf = usb_alloc_coherent(udev,
le16_to_cpu(ep_in->wMaxPacketSize), GFP_KERNEL, >dma_in);
if (!rr3->bulk_in_buf)
-   goto error;
+   goto redrat_free;
 
pipe = usb_rcvbulkpipe(udev, ep_in->bEndpointAddress);
usb_fill_bulk_urb(rr3->read_urb, udev, pipe, rr3->bulk_in_buf,
@@ -1000,34 +1002,16 @@ static int redrat3_dev_probe(struct usb_interface *intf,
rr3->read_urb->transfer_dma = rr3->dma_in;
rr3->read_urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
 
-   rr3->ep_out = ep_out;
-   rr3->udev = udev;
-
redrat3_reset(rr3);
redrat3_get_firmware_rev(rr3);
 
-   /* might be all we need to do? */
-   retval = redrat3_enable_detector(rr3);
-   if (retval < 0)
-   goto error;
-
/* default.. will get overridden by any sends with a freq defined */
rr3->carrier = 38000;
 
-   /* led control */
-   rr3->led.name = "redrat3:red:feedback";
-   rr3->led.default_trigger = "rc-feedback";
-   rr3->led.brightness_set = redrat3_brightness_set;
-   retval = led_classdev_register(>dev, >led);
-   if (retval)
-   goto error;
-
atomic_set(>flash, 0);
rr3->flash_urb = usb_alloc_urb(0, GFP_KERNEL);
-   if (!rr3->flash_urb) {
-   retval = -ENOMEM;
-   goto led_free_error;
-   }
+   if (!rr3->flash_urb)
+   goto redrat_free;
 
/* setup packet is 'c0 b9   0001' */
rr3->flash_control.bRequestType = 0xc0;
@@ -1039,20 +1023,33 @@ static int redrat3_dev_probe(struct usb_interface *intf,
>flash_in_buf, sizeof(rr3->flash_in_buf),
redrat3_led_complete, rr3);
 
+   /* led control */
+   rr3->led.name = "redrat3:red:feedback";
+   rr3->led.default_trigger = "rc-feedback";
+   rr3->led.brightness_set = redrat3_brightness_set;
+   retval = led_classdev_register(>dev, >led);
+   if (retval)
+   goto redrat_free;
+
rr3->rc = redrat3_init_rc_dev(rr3);
if (!rr3->rc) {
retval = -ENOMEM;
-   goto led_free_error;
+   goto led_free;
}
 
+   /* might be all we need to do? */
+   retval = redrat3_enable_detector(rr3);
+   if (retval < 0)
+   goto led_free;
+
/* we can register the device now, as it is ready */
usb_set_intfdata(intf, rr3);
 
return 0;
 
-led_free_error:
+led_free:
led_classdev_unregister(>led);
-error:
+redrat_free:
redrat3_delete(rr3, rr3->udev);
 
 no_endpoints:
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/9] [media] redrat3: remove dead code and pointless messages

2016-10-31 Thread Sean Young
No need to log kmalloc failures.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/redrat3.c | 42 ++
 1 file changed, 6 insertions(+), 36 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index de40e58..23180ec 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -363,11 +363,6 @@ static void redrat3_process_ir_data(struct redrat3_dev 
*rr3)
unsigned int i, sig_size, single_len, offset, val;
u32 mod_freq;
 
-   if (!rr3) {
-   pr_err("%s called with no context!\n", __func__);
-   return;
-   }
-
dev = rr3->dev;
 
mod_freq = redrat3_val_to_mod_freq(>irdata);
@@ -480,10 +475,8 @@ static u32 redrat3_get_timeout(struct redrat3_dev *rr3)
 
len = sizeof(*tmp);
tmp = kzalloc(len, GFP_KERNEL);
-   if (!tmp) {
-   dev_warn(rr3->dev, "Memory allocation faillure\n");
+   if (!tmp)
return timeout;
-   }
 
pipe = usb_rcvctrlpipe(rr3->udev, 0);
ret = usb_control_msg(rr3->udev, pipe, RR3_GET_IR_PARAM,
@@ -544,10 +537,8 @@ static void redrat3_reset(struct redrat3_dev *rr3)
txpipe = usb_sndctrlpipe(udev, 0);
 
val = kmalloc(len, GFP_KERNEL);
-   if (!val) {
-   dev_err(dev, "Memory allocation failure\n");
+   if (!val)
return;
-   }
 
*val = 0x01;
rc = usb_control_msg(udev, rxpipe, RR3_RESET,
@@ -589,10 +580,8 @@ static void redrat3_get_firmware_rev(struct redrat3_dev 
*rr3)
char *buffer;
 
buffer = kzalloc(sizeof(char) * (RR3_FW_VERSION_LEN + 1), GFP_KERNEL);
-   if (!buffer) {
-   dev_err(rr3->dev, "Memory allocation failure\n");
+   if (!buffer)
return;
-   }
 
rc = usb_control_msg(rr3->udev, usb_rcvctrlpipe(rr3->udev, 0),
 RR3_FW_VERSION,
@@ -699,19 +688,9 @@ static int redrat3_get_ir_data(struct redrat3_dev *rr3, 
unsigned len)
 /* callback function from USB when async USB request has completed */
 static void redrat3_handle_async(struct urb *urb)
 {
-   struct redrat3_dev *rr3;
+   struct redrat3_dev *rr3 = urb->context;
int ret;
 
-   if (!urb)
-   return;
-
-   rr3 = urb->context;
-   if (!rr3) {
-   pr_err("%s called with invalid context!\n", __func__);
-   usb_unlink_urb(urb);
-   return;
-   }
-
switch (urb->status) {
case 0:
ret = redrat3_get_ir_data(rr3, urb->actual_length);
@@ -999,10 +978,8 @@ static int redrat3_dev_probe(struct usb_interface *intf,
 
/* allocate memory for our device state and initialize it */
rr3 = kzalloc(sizeof(*rr3), GFP_KERNEL);
-   if (rr3 == NULL) {
-   dev_err(dev, "Memory allocation failure\n");
+   if (rr3 == NULL)
goto no_endpoints;
-   }
 
rr3->dev = >dev;
 
@@ -1014,10 +991,8 @@ static int redrat3_dev_probe(struct usb_interface *intf,
rr3->ep_in = ep_in;
rr3->bulk_in_buf = usb_alloc_coherent(udev,
le16_to_cpu(ep_in->wMaxPacketSize), GFP_KERNEL, >dma_in);
-   if (!rr3->bulk_in_buf) {
-   dev_err(dev, "Read buffer allocation failure\n");
+   if (!rr3->bulk_in_buf)
goto error;
-   }
 
pipe = usb_rcvbulkpipe(udev, ep_in->bEndpointAddress);
usb_fill_bulk_urb(rr3->read_urb, udev, pipe, rr3->bulk_in_buf,
@@ -1081,8 +1056,6 @@ static int redrat3_dev_probe(struct usb_interface *intf,
redrat3_delete(rr3, rr3->udev);
 
 no_endpoints:
-   dev_err(dev, "%s: retval = %x", __func__, retval);
-
return retval;
 }
 
@@ -1091,9 +1064,6 @@ static void redrat3_dev_disconnect(struct usb_interface 
*intf)
struct usb_device *udev = interface_to_usbdev(intf);
struct redrat3_dev *rr3 = usb_get_intfdata(intf);
 
-   if (!rr3)
-   return;
-
usb_set_intfdata(intf, NULL);
rc_unregister_device(rr3->rc);
led_classdev_unregister(>led);
-- 
2.7.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 1/9] [media] winbond-cir: use name without space for pnp driver

2016-10-31 Thread Sean Young
Rename the pnp driver in sysfs from /sys/bus/pnp/drivers/Winbond CIR
to /sys/bus/pnp/drivers/winbond-cir

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/winbond-cir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index cdcd6e3..1ccb6bb 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1185,7 +1185,7 @@ static const struct pnp_device_id wbcir_ids[] = {
 MODULE_DEVICE_TABLE(pnp, wbcir_ids);
 
 static struct pnp_driver wbcir_driver = {
-   .name = WBCIR_NAME,
+   .name = DRVNAME,
.id_table = wbcir_ids,
.probe= wbcir_probe,
.remove   = wbcir_remove,
-- 
2.7.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 6/9] [media] redrat3: increase set size for lengths to maximum

2016-10-31 Thread Sean Young
In learning mode, you can get much longer messages which can run out
of lengths. The usb message will slightly larger.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/redrat3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 4370d21..12e299f 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -113,7 +113,7 @@
 #define RR3_NARROW_IN_EP_ADDR  0x82
 
 /* Size of the fixed-length portion of the signal */
-#define RR3_DRIVER_MAXLENS 128
+#define RR3_DRIVER_MAXLENS 255
 #define RR3_MAX_SIG_SIZE   512
 #define RR3_TIME_UNIT  50
 #define RR3_END_OF_SIGNAL  0x7f
-- 
2.7.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 7/9] [media] lirc: might sleep error in lirc_dev_fop_read

2016-10-31 Thread Sean Young
[  101.457944] [ cut here ]
[  101.457954] WARNING: CPU: 3 PID: 1819 at kernel/sched/core.c:7708 
__might_sleep+0x7e/0x80
[  101.457960] do not call blocking ops when !TASK_RUNNING; state=1 set at 
[] lirc_dev_fop_read+0x292/0x4e0 [lirc_dev]

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/lirc_dev.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index 91f9bb8..bf4309f 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -684,7 +684,6 @@ ssize_t lirc_dev_fop_read(struct file *file,
 * between while condition checking and scheduling)
 */
add_wait_queue(>buf->wait_poll, );
-   set_current_state(TASK_INTERRUPTIBLE);
 
/*
 * while we didn't provide 'length' bytes, device is opened in blocking
@@ -709,13 +708,13 @@ ssize_t lirc_dev_fop_read(struct file *file,
}
 
mutex_unlock(>irctl_lock);
-   schedule();
set_current_state(TASK_INTERRUPTIBLE);
+   schedule();
+   set_current_state(TASK_RUNNING);
 
if (mutex_lock_interruptible(>irctl_lock)) {
ret = -ERESTARTSYS;
remove_wait_queue(>buf->wait_poll, );
-   set_current_state(TASK_RUNNING);
goto out_unlocked;
}
 
@@ -735,7 +734,6 @@ ssize_t lirc_dev_fop_read(struct file *file,
}
 
remove_wait_queue(>buf->wait_poll, );
-   set_current_state(TASK_RUNNING);
 
 out_locked:
mutex_unlock(>irctl_lock);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 8/9] [media] lirc: prevent use-after free

2016-10-31 Thread Sean Young
If you unplug an lirc device while reading from it, you will get an
use after free as the cdev is freed while still in use.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/lirc_dev.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index bf4309f..60fd106 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -164,15 +164,15 @@ static int lirc_cdev_add(struct irctl *ir)
struct lirc_driver *d = >d;
struct cdev *cdev;
 
-   cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
+   cdev = cdev_alloc();
if (!cdev)
goto err_out;
 
if (d->fops) {
-   cdev_init(cdev, d->fops);
+   cdev->ops = d->fops;
cdev->owner = d->owner;
} else {
-   cdev_init(cdev, _dev_fops);
+   cdev->ops = _dev_fops;
cdev->owner = THIS_MODULE;
}
retval = kobject_set_name(>kobj, "lirc%d", d->minor);
@@ -190,7 +190,7 @@ static int lirc_cdev_add(struct irctl *ir)
return 0;
 
 err_out:
-   kfree(cdev);
+   cdev_del(cdev);
return retval;
 }
 
@@ -420,7 +420,6 @@ int lirc_unregister_driver(int minor)
} else {
lirc_irctl_cleanup(ir);
cdev_del(cdev);
-   kfree(cdev);
kfree(ir);
irctls[minor] = NULL;
}
@@ -521,7 +520,6 @@ int lirc_dev_fop_close(struct inode *inode, struct file 
*file)
lirc_irctl_cleanup(ir);
cdev_del(cdev);
irctls[ir->d.minor] = NULL;
-   kfree(cdev);
kfree(ir);
}
 
-- 
2.7.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 0/9] Various IR fixes

2016-10-31 Thread Sean Young
Teach the redrat3 driver how to use the wideband receiver, also fix
some very nasty crashes if you disconnect a lirc device while
reading from it.

Sean Young (9):
  [media] winbond-cir: use name without space for pnp driver
  [media] redrat3: don't include vendor/product id in name
  [media] redrat3: remove dead code and pointless messages
  [media] redrat3: fix error paths in probe
  [media] redrat3: enable carrier reports using wideband receiver
  [media] redrat3: increase set size for lengths to maximum
  [media] lirc: might sleep error in lirc_dev_fop_read
  [media] lirc: prevent use-after free
  [media] lirc: use-after free while reading from device and unplugging

 drivers/media/rc/lirc_dev.c|  18 +--
 drivers/media/rc/redrat3.c | 283 +
 drivers/media/rc/winbond-cir.c |   2 +-
 3 files changed, 181 insertions(+), 122 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/9] [media] redrat3: don't include vendor/product id in name

2016-10-31 Thread Sean Young
No need to duplicate these in the rc name.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/redrat3.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 3b0ed1c..de40e58 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -912,9 +912,9 @@ static struct rc_dev *redrat3_init_rc_dev(struct 
redrat3_dev *rr3)
goto out;
}
 
-   snprintf(rr3->name, sizeof(rr3->name), "RedRat3%s Infrared Remote 
Transceiver (%04x:%04x)",
-prod == USB_RR3IIUSB_PRODUCT_ID ? "-II" : "",
-le16_to_cpu(rr3->udev->descriptor.idVendor), prod);
+   snprintf(rr3->name, sizeof(rr3->name),
+"RedRat3%s Infrared Remote Transceiver",
+prod == USB_RR3IIUSB_PRODUCT_ID ? "-II" : "");
 
usb_make_path(rr3->udev, rr3->phys, sizeof(rr3->phys));
 
-- 
2.7.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


Re: [PATCH v2 5/7] [media] ir-lirc-codec: don't wait any transmitting time for tx only devices

2016-10-31 Thread Sean Young
Hi David, Andi,

On Mon, Oct 31, 2016 at 02:31:52PM +, David Härdeman wrote:
> October 27, 2016 4:36 PM, "Sean Young" <s...@mess.org> wrote:
> > Since we have to be able to switch between waiting and not waiting,
> > we need some sort of ABI for this. I think this warrants a new ioctl;
> > I'm not sure how else it can be done. I'll be sending out a patch
> > shortly.
> 
> Hi Sean,
> 
> have you considered using a module param for the LIRC bridge module instead? 
> As far as I understand it, this is an issue which is entirely internal to 
> LIRC, and it's also not something which really needs to be changed on a 
> per-device level (either you have a modern LIRC daemon or you don't, and all 
> drivers should behave the same, no?).

I still don't see how any of this would change anything for the ir-spi case:
since it uses sync spi transfer, it's going to block anyway.

> Another advantage is that the parameter would then go away if and when the 
> lirc bridge ever goes away (yes, I can still dream, can't I?).

The suggested ioctl is unique to lirc too and would disappear if the
lirc ABI goes away. With a module parameter you would change the lirc ABI
into an incompatible one. Not sure that is what module parameters should
be used for.

Andi, it would be good to know what the use-case for the original change is.


Thanks
Sean
--
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] lirc: introduce LIRC_SET_TRANSMITTER_WAIT ioctl

2016-10-28 Thread Sean Young
Hi Andi,

On Fri, Oct 28, 2016 at 04:38:39PM +0900, Andi Shyti wrote:
> Hi Sean,
> 
> > ret *= sizeof(unsigned int);
> >  
> > -   /*
> > -* The lircd gap calculation expects the write function to
> > -* wait for the actual IR signal to be transmitted before
> > -* returning.
> > -*/
> > -   towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
> > -   if (towait > 0) {
> > -   set_current_state(TASK_INTERRUPTIBLE);
> > -   schedule_timeout(usecs_to_jiffies(towait));
> > +   if (!lirc->tx_no_wait) {
> > +   /*
> > +* The lircd gap calculation expects the write function to
> > +* wait for the actual IR signal to be transmitted before
> > +* returning.
> > +*/
> > +   towait = ktime_us_delta(ktime_add_us(start, duration),
> > +   ktime_get());
> > +   if (towait > 0) {
> > +   set_current_state(TASK_INTERRUPTIBLE);
> > +   schedule_timeout(usecs_to_jiffies(towait));
> > +   }
> > }
> > -
> 
> this doesn't fix my problem, though.
> 
> This approach gives the userspace the possibility to choose to
> either sync or not. In my case the sync happens, but in a
> different level and it's not up to the userspace to make the
> decision.

What problem are you trying to solve?

I wrote this patch as a response to this patch:

https://lkml.org/lkml/2016/9/1/653

In the spi case, the driver already waits for the IR to complete so the 
wait in ir_lirc_transmit_ir() is unnecessary. However it does not end up
waiting. There are other drivers like yours that wait for the IR to 
complete (ene_ir, ite-cir). Since towait in ir_lirc_transmit_ir is the 
delta between before and after the driver transmits, it will be 0 and 
will never goto into schedule_timeout(), barring some very minor rounding 
differences.

> Besides, I see here a security issue: what happens if userspace
> does something like
> 
>  fd = open("/dev/lirc0", O_RDWR);
> 
>  ioctl(fd, LIRC_SET_TRANSMITTER_WAIT, 0);
> 
>  while(1)
> write(fd, buffer, ENORMOUS_BUFFER_SIZE);

I don't understand what problem this would introduce.

You can't write more than 512 pulse/spaces and each write cannot
have more than 500ms in IR (so adding up the pulses and spaces). The driver
should only send once the previous send completed.

> >  
> > +   case LIRC_SET_TRANSMITTER_WAIT:
> > +   if (!dev->tx_ir)
> > +   return -ENOTTY;
> > +
> > +   lirc->tx_no_wait = !val;
> > +   break;
> > +
> 
> Here I see an innocuous bug. Depending on the hardware (for
> example ir-spi) it might happen that the device waits in any
> case (in ir-spi the sync is done by the spi). This means that if
> userspace sets 'tx_no_wait = true', the device/driver doesn't
> care and waits anyway, doing the opposite from what is described
> in the ABI.
> 
> Here we could call a dev->tx_set_transmitter_wait(...) function
> that sets the value or returns error in case the wait is not
> feasable, something like:
> 
>   case LIRC_SET_TRANSMITTER_WAIT:
>   if (!dev->tx_ir)
>   return -ENOTTY;
> 
>   if (dev->tx_set_transmitter_wait)
>   return dev->tx_set_transmitter_wait(lirc, val);
> 
>   lirc->tx_no_wait = !val;
>   break;

That is true. Do you want the ir-spi driver to be able to send without
waiting?

> > --- a/drivers/media/rc/rc-core-priv.h
> > +++ b/drivers/media/rc/rc-core-priv.h
> > @@ -112,7 +112,7 @@ struct ir_raw_event_ctrl {
> > u64 gap_duration;
> > bool gap;
> > bool send_timeout_reports;
> > -
> > +   bool tx_no_wait;
> > } lirc;
> 
> this to me looks confusing, it has a negative meaning in kernel
> space and a positive meaning in userspace. Can't we call it
> lirc->tx_wait instead of lirc->tx_no_wait, so that we keep the
> same meaning and we don't need to negate val?

This was just done to avoid having to initialise to true (non-zero).


Thanks,
Sean
--
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: introduce LIRC_SET_TRANSMITTER_WAIT ioctl

2016-10-27 Thread Sean Young
lirc transmit waits for the IR to complete, since existing versions
of lircd (prior to 0.9.4) rely on this. Allows this to be configurable
if this is not desirable.

Signed-off-by: Sean Young <s...@mess.org>
---
 Documentation/media/uapi/rc/lirc-func.rst  |  1 +
 .../media/uapi/rc/lirc-set-transmitter-wait.rst| 46 ++
 Documentation/media/uapi/rc/lirc-write.rst |  6 ++-
 drivers/media/rc/ir-lirc-codec.c   | 29 +-
 drivers/media/rc/rc-core-priv.h|  2 +-
 include/uapi/linux/lirc.h  |  5 +++
 6 files changed, 76 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/media/uapi/rc/lirc-set-transmitter-wait.rst

diff --git a/Documentation/media/uapi/rc/lirc-func.rst 
b/Documentation/media/uapi/rc/lirc-func.rst
index 9b5a772..be02ca2 100644
--- a/Documentation/media/uapi/rc/lirc-func.rst
+++ b/Documentation/media/uapi/rc/lirc-func.rst
@@ -26,3 +26,4 @@ LIRC Function Reference
 lirc-set-rec-timeout-reports
 lirc-set-measure-carrier-mode
 lirc-set-wideband-receiver
+lirc-set-transmitter-wait
diff --git a/Documentation/media/uapi/rc/lirc-set-transmitter-wait.rst 
b/Documentation/media/uapi/rc/lirc-set-transmitter-wait.rst
new file mode 100644
index 000..37835ad
--- /dev/null
+++ b/Documentation/media/uapi/rc/lirc-set-transmitter-wait.rst
@@ -0,0 +1,46 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _lirc_set_transmitter_mask:
+
+***
+ioctl LIRC_SET_TRANSMITTER_WAIT
+***
+
+Name
+
+
+LIRC_SET_TRANSMITTER_WAIT - Wait for IR to transmit
+
+Synopsis
+
+
+.. c:function:: int ioctl( int fd, LIRC_SET_TRANSMITTER_WAIT, __u32 *enable )
+:name: LIRC_SET_TRANSMITTER_WAIT
+
+Arguments
+=
+
+``fd``
+File descriptor returned by open().
+
+``enable``
+enable = 1 means wait for IR to transmit before write() returns,
+enable = 0 means return as soon as the driver has sent the commmand
+to the hardware.
+
+
+Description
+===
+
+Early lirc drivers would only return from write() when the IR had been
+transmitted and the lirc daemon relies on this for calculating when to
+send the next IR signal. Some drivers (e.g. usb drivers) can return
+earlier than that.
+
+
+Return Value
+
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes ` chapter.
diff --git a/Documentation/media/uapi/rc/lirc-write.rst 
b/Documentation/media/uapi/rc/lirc-write.rst
index 3b035c6..32c2152 100644
--- a/Documentation/media/uapi/rc/lirc-write.rst
+++ b/Documentation/media/uapi/rc/lirc-write.rst
@@ -46,8 +46,10 @@ The data written to the chardev is a pulse/space sequence of 
integer
 values. Pulses and spaces are only marked implicitly by their position.
 The data must start and end with a pulse, therefore, the data must
 always include an uneven number of samples. The write function must
-block until the data has been transmitted by the hardware. If more data
-is provided than the hardware can send, the driver returns ``EINVAL``.
+block until the data has been transmitted by the hardware, unless
+:ref:`LIRC_SET_TRANSMITTER_WAIT ` has been
+disabled. If more data is provided than the hardware can send, the driver
+returns ``EINVAL``.
 
 
 Return Value
diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index c327730..110e501 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -161,17 +161,19 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
 
ret *= sizeof(unsigned int);
 
-   /*
-* The lircd gap calculation expects the write function to
-* wait for the actual IR signal to be transmitted before
-* returning.
-*/
-   towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
-   if (towait > 0) {
-   set_current_state(TASK_INTERRUPTIBLE);
-   schedule_timeout(usecs_to_jiffies(towait));
+   if (!lirc->tx_no_wait) {
+   /*
+* The lircd gap calculation expects the write function to
+* wait for the actual IR signal to be transmitted before
+* returning.
+*/
+   towait = ktime_us_delta(ktime_add_us(start, duration),
+   ktime_get());
+   if (towait > 0) {
+   set_current_state(TASK_INTERRUPTIBLE);
+   schedule_timeout(usecs_to_jiffies(towait));
+   }
}
-
 out:
kfree(txbuf);
return ret;
@@ -234,6 +236,13 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
 
return dev->s_tx_duty_cycle(dev, val);
 
+   case LIRC_SET_TRANSMITTER_WAIT:
+ 

Re: [PATCH v2 5/7] [media] ir-lirc-codec: don't wait any transmitting time for tx only devices

2016-10-27 Thread Sean Young
On Thu, Oct 27, 2016 at 04:44:01PM +0900, Andi Shyti wrote:
> Hi Sean,
> 
> it's been a while :)
> 
> I was going through your review fixing what needs to be fixed,
> but...
> 
> > > @@ -153,7 +153,7 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> > > const char __user *buf,
> > >   }
> > >  
> > >   ret = dev->tx_ir(dev, txbuf, count);
> > > - if (ret < 0)
> > > + if (ret < 0 || dev->driver_type == RC_DRIVER_IR_RAW_TX)
> > 
> > Just because a driver only does transmit doesn't mean its transmit ABI
> > should change.
> > 
> > Now this bit of code is pretty horrible. It ensures that the call to write()
> > takes at least as long as the length of the transmit IR by sleeping. That's
> > not much of a guarantee that the IR has been sent.
> > 
> > Note that in the case of ir-spi, since your spi transfer is sync no sleep
> > should be introduced here.
> > 
> > The gap calculation in lirc checks that if the call to write() took _longer_
> > than expected wait before sending the next IR code (when either multiple
> > IR codes or repeats are specified). Introducing the sleep in the kernel
> > here does not help at all, lirc already ensures that it waits as long as
> > the IR is long (see schedule_repeat_timer in lirc).
> > 
> > This change was introduced in 3.10, commit f8e00d5. 
> 
> ... I'm not sure what can be done here. I get your point and I
> understand that this indeed is a kind of fake sync point and by
> doing this I 

My original plan was to send a patch which just removes the silly wait,
but on further investigating debian stable and testing still carry a
lirc version that depend on it, so that's not going to fly.

> How about creating two different functions:
> 
> - ir_lirc_transmit_ir where we actually do what the function
>   already does
> - ir_lirc_transmit_no_sync where the function we don't wait
>   because the the sync is done on a different level (for example
>   in the SPI case).
> 
> SPI does approximately the same thing.

Since we have to be able to switch between waiting and not waiting, 
we need some sort of ABI for this. I think this warrants a new ioctl;
I'm not sure how else it can be done. I'll be sending out a patch
shortly.


Sean
--
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 04/18] [media] RedRat3: One function call less in redrat3_transmit_ir() after error detection

2016-10-15 Thread Sean Young
On Thu, Oct 13, 2016 at 06:24:46PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Thu, 13 Oct 2016 10:50:24 +0200
> 
> The kfree() function was called in one case by the
> redrat3_transmit_ir() function during error handling
> even if the passed variable contained a null pointer.
> 
> * Adjust jump targets according to the Linux coding style convention.
> 
> * Move the resetting for the data structure member "transmitting"
>   at the end.
> 
> * Delete initialisations for the variables "irdata" and "sample_lens"
>   at the beginning which became unnecessary with this refactoring.
> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/media/rc/redrat3.c | 18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
> index 7ae2ced..71e901d 100644
> --- a/drivers/media/rc/redrat3.c
> +++ b/drivers/media/rc/redrat3.c
> @@ -723,10 +723,10 @@ static int redrat3_transmit_ir(struct rc_dev *rcdev, 
> unsigned *txbuf,
>  {
>   struct redrat3_dev *rr3 = rcdev->priv;
>   struct device *dev = rr3->dev;
> - struct redrat3_irdata *irdata = NULL;
> + struct redrat3_irdata *irdata;
>   int ret, ret_len;
>   int lencheck, cur_sample_len, pipe;
> - int *sample_lens = NULL;
> + int *sample_lens;
>   u8 curlencheck;
>   unsigned i, sendbuf_len;
>  
> @@ -747,7 +747,7 @@ static int redrat3_transmit_ir(struct rc_dev *rcdev, 
> unsigned *txbuf,
>   irdata = kzalloc(sizeof(*irdata), GFP_KERNEL);
>   if (!irdata) {
>   ret = -ENOMEM;
> - goto out;
> + goto free_sample;
>   }
>  
>   /* rr3 will disable rc detector on transmit */
> @@ -776,7 +776,7 @@ static int redrat3_transmit_ir(struct rc_dev *rcdev, 
> unsigned *txbuf,
>   curlencheck++;
>   } else {
>   ret = -EINVAL;
> - goto out;
> + goto reset_member;
>   }
>   }
>   irdata->sigdata[i] = lencheck;
> @@ -811,14 +811,12 @@ static int redrat3_transmit_ir(struct rc_dev *rcdev, 
> unsigned *txbuf,
>   dev_err(dev, "Error: control msg send failed, rc %d\n", ret);
>   else
>   ret = count;
> -
> -out:
> - kfree(irdata);
> - kfree(sample_lens);
> -
> +reset_member:
>   rr3->transmitting = false;
>   /* rr3 re-enables rc detector because it was enabled before */
> -
> + kfree(irdata);
> +free_sample:
> + kfree(sample_lens);

In this error path, rr3->transmitting is not set to false so now the driver
will never allow you transmit again.

Also this patch does not apply against latest.

Sean

>   return ret;
>  }
>  
> -- 
> 2.10.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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/5] [media] winbond-cir: One variable and its check less in wbcir_shutdown() after error detection

2016-10-15 Thread Sean Young
se + WBCIR_REG_WCEIR_STS, 0x17, 0x17);
> + /* Set compare and compare mask */
> + wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_INDEX,
> +WBCIR_REGSEL_COMPARE | WBCIR_REG_ADDR0,
> +0x3F);
> + outsb(data->wbase + WBCIR_REG_WCEIR_DATA, match, 11);
> + wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_INDEX,
> +WBCIR_REGSEL_MASK | WBCIR_REG_ADDR0,
> +0x3F);
> + outsb(data->wbase + WBCIR_REG_WCEIR_DATA, mask, 11);
>  
> - /* Clear BUFF_EN, Clear END_EN, Set MATCH_EN */
> - wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_EV_EN, 0x01, 0x07);
> + /* RC6 Compare String Len */
> + outb(rc6_csl, data->wbase + WBCIR_REG_WCEIR_CSL);
>  
> - /* Set CEIR_EN */
> - wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_CTL, 0x01, 0x01);
> -
> - } else {
> - /* Clear BUFF_EN, Clear END_EN, Clear MATCH_EN */
> - wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_EV_EN, 0x00, 0x07);
> + /* Clear status bits NEC_REP, BUFF, MSG_END, MATCH */
> + wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_STS, 0x17, 0x17);
>  
> - /* Clear CEIR_EN */
> - wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_CTL, 0x00, 0x01);
> - }
> + /* Clear BUFF_EN, Clear END_EN, Set MATCH_EN */
> + wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_EV_EN, 0x01, 0x07);
>  
> + /* Set CEIR_EN */
> + wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_CTL, 0x01, 0x01);
> +set_irqmask:
>   /*
>* ACPI will set the HW disable bit for SP3 which means that the
>* output signals are left in an undefined state which may cause
> @@ -876,6 +858,14 @@ wbcir_shutdown(struct pnp_dev *device)
>*/
>   wbcir_set_irqmask(data, WBCIR_IRQ_NONE);
>   disable_irq(data->irq);
> + return;
> +clear_bits:
> + /* Clear BUFF_EN, Clear END_EN, Clear MATCH_EN */
> + wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_EV_EN, 0x00, 0x07);
> +
> + /* Clear CEIR_EN */
> + wbcir_set_bits(data->wbase + WBCIR_REG_WCEIR_CTL, 0x00, 0x01);
> + goto set_irqmask;

I'm not convinced that adding a goto which goes backwards is making this
code any more readible, just so that a local variable can be dropped.


Sean

>  }
>  
>  static int
> -- 
> 2.10.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
--
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 12/18] [media] RedRat3: Move a variable assignment in redrat3_init_rc_dev()

2016-10-13 Thread Sean Young
On Thu, Oct 13, 2016 at 06:39:23PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Thu, 13 Oct 2016 14:50:05 +0200
> 
> Move the assignment for the local variable "prod" behind the source code
> for a memory allocation by this function.

The redrat3 driver shouldn't be adding the usb vendor/product id to the
device name. A better patch would be to remove those from the snprintf
completely and to away with the local variable.

Sean

> 
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
>  drivers/media/rc/redrat3.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
> index b23a8bb..002030f 100644
> --- a/drivers/media/rc/redrat3.c
> +++ b/drivers/media/rc/redrat3.c
> @@ -856,12 +856,13 @@ static struct rc_dev *redrat3_init_rc_dev(struct 
> redrat3_dev *rr3)
>  {
>   struct rc_dev *rc;
>   int ret;
> - u16 prod = le16_to_cpu(rr3->udev->descriptor.idProduct);
> + u16 prod;
>  
>   rc = rc_allocate_device();
>   if (!rc)
>   goto out;
>  
> + prod = le16_to_cpu(rr3->udev->descriptor.idProduct);
>   snprintf(rr3->name, sizeof(rr3->name), "RedRat3%s "
>"Infrared Remote Transceiver (%04x:%04x)",
>prod == USB_RR3IIUSB_PRODUCT_ID ? "-II" : "",
> -- 
> 2.10.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
--
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] dib0700: fix nec repeat handling

2016-10-13 Thread Sean Young
When receiving a nec repeat, ensure the correct scancode is repeated
rather than a random value from the stack. This removes the need
for the bogus uninitialized_var() and also fixes the warnings:

drivers/media/usb/dvb-usb/dib0700_core.c: In function 
‘dib0700_rc_urb_completion’:
drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be 
used uninitialized in this function

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/usb/dvb-usb/dib0700_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c 
b/drivers/media/usb/dvb-usb/dib0700_core.c
index f319665..5bb23ef 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -677,7 +677,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
struct dvb_usb_device *d = purb->context;
struct dib0700_rc_response *poll_reply;
enum rc_type protocol;
-   u32 uninitialized_var(keycode);
+   u32 keycode;
u8 toggle;
 
deb_info("%s()\n", __func__);
@@ -718,7 +718,8 @@ static void dib0700_rc_urb_completion(struct urb *purb)
poll_reply->nec.data   == 0x00 &&
poll_reply->nec.not_data   == 0xff) {
poll_reply->data_state = 2;
-   break;
+   rc_repeat(d->rc_dev);
+   goto resubmit;
}
 
if ((poll_reply->nec.data ^ poll_reply->nec.not_data) != 0xff) {
-- 
2.7.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


Re: [PATCH] [media] dib0700: Fix uninitialized protocol for NEC repeat codes

2016-10-13 Thread Sean Young
On Thu, Oct 13, 2016 at 03:51:39PM +0200, Geert Uytterhoeven wrote:
> drivers/media/usb/dvb-usb/dib0700_core.c: In function 
> ‘dib0700_rc_urb_completion’:
> drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be 
> used uninitialized in this function
> 
> When receiving an NEC repeat code, protocol is indeed not initialized.
> Set it to RC_TYPE_NECX to fix this.
> 
> Fixes: 2ceeca0499d74521 ("[media] rc: split nec protocol into its three 
> variants")
> Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
> ---
> Is RC_TYPE_NECX correct, or should it be RC_TYPE_NEC?
> I used RC_TYPE_NECX based on the checks for {,not_}data and
> {,not_}system for the other cases.

It should be the protocol that the last scancode was received with. This
code path is very broken; it calls:

rc_keydown(d->rc_dev, protocol, keycode, toggle);

But keycode in this codepath is never set. Luckily keycode is declared as:

u32 uninitialized_var(keycode);

I've got another patch for this which I'll send as a reply to this.


Sean


> ---
>  drivers/media/usb/dvb-usb/dib0700_core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c 
> b/drivers/media/usb/dvb-usb/dib0700_core.c
> index f3196658fb700706..5878ae4d20ad27ed 100644
> --- a/drivers/media/usb/dvb-usb/dib0700_core.c
> +++ b/drivers/media/usb/dvb-usb/dib0700_core.c
> @@ -718,6 +718,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
>   poll_reply->nec.data   == 0x00 &&
>   poll_reply->nec.not_data   == 0xff) {
>   poll_reply->data_state = 2;
> + protocol = RC_TYPE_NECX;
>   break;
>   }
>  
> -- 
> 1.9.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
--
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/input] rc: report rc protocol type to userspace through input

2016-09-25 Thread Sean Young
Hi Dmitry,

On Fri, Sep 23, 2016 at 03:08:31PM -0700, Dmitry Torokhov wrote:
> On Thu, Sep 22, 2016 at 11:57:13AM -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 21 Sep 2016 10:54:21 +0100
> > Sean Young <s...@mess.org> escreveu:
> > 
> > > We might want to know what protocol a remote uses when we do not know. 
> > > With
> > > this patch and another patch for v4l-utils (follows), you can do that 
> > > with:
> > > 
> > > ./ir-keytable  -p rc-5,nec,rc-6,jvc,sony,sanyo,sharp,xmp -t
> > > Testing events. Please, press CTRL-C to abort.
> > > 1474415431.689685: event type EV_MSC(0x04): protocol = RC_TYPE_RC6_MCE
> > > 1474415431.689685: event type EV_MSC(0x04): scancode = 0x800f040e
> > > 1474415431.689685: event type EV_SYN(0x00).
> > > 
> > > This makes RC_TYPE_* part of the ABI. We also remove the enum rc_type,
> > > since in input-event-codes.h we cannot not use enums.
> > > 
> > > In addition, now that the input layer knows the rc protocol and scancode,
> > > at a later point we could add a feature where keymaps could be created
> > > based on both protocol and scancode, not just scancode.
> > 
> > We need Dmitry's ack in order to apply this one.
> 
> I'd rather not: I am trying to keep input API hardware-independent and
> the kind of device emitting keycodes (a remote control in the sense of
> drivers/media/rc or USB device or BT device) should not really matter to
> consumers. Similarly how we do not export whether device is USB1.1 or
> USB2 or USB3 (although we do have input->id.bustype, but it is more for
> identification purposes rather than for adjusting properties).

Keyboards produce device dependant scancodes; the only output RC devices 
have is protocol and scancode. The scancode is already being sent to
the input layer, and if we can't send the rc protocol to the input layer
we would need a new char device just for that, which is complete overkill.

Alternatively we can put the rc protocol type in MSC_RAW, MSC_SERIAL or
ABS_MISC or one of the other existing device dependant input codes. 

> For configuration (like loading keymaps) we can examine
> parent hardware device and decide.

Unfortunately there is nothing to examine there. The usb device of an 
infrared receiver will tell you nothing about the remote the user is
using.

It would be really helpful if this could be merged; I don't know what
other solution there is to this problem.


Sean
--
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: split nec protocol into its three variants

2016-09-21 Thread Sean Young
Currently we do not know what variant (bit length) of the nec protocol
is used, other than from guessing from the length of the scancode. Now
nec will be handled the same way as the sony protocol or the rc6 protocol;
one variant per bit length.

In the future we might want to expose the rc protocol type to userspace
and we don't want to be introducing this world of pain into userspace
too.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/pci/cx23885/cx23885-input.c |  2 +-
 drivers/media/pci/cx88/cx88-input.c   |  5 +++--
 drivers/media/pci/saa7134/saa7134-input.c |  4 ++--
 drivers/media/rc/igorplugusb.c|  3 ++-
 drivers/media/rc/img-ir/img-ir-nec.c  |  6 --
 drivers/media/rc/ir-nec-decoder.c |  8 ++--
 drivers/media/rc/rc-main.c|  4 +++-
 drivers/media/usb/au0828/au0828-input.c   |  3 ++-
 drivers/media/usb/dvb-usb-v2/af9015.c |  8 ++--
 drivers/media/usb/dvb-usb-v2/af9035.c |  9 +++--
 drivers/media/usb/dvb-usb-v2/az6007.c | 13 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c|  5 +++--
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c   |  9 +++--
 drivers/media/usb/dvb-usb/dib0700_core.c  |  4 +++-
 drivers/media/usb/dvb-usb/dtt200u.c   |  5 -
 include/media/rc-map.h| 31 +++
 16 files changed, 81 insertions(+), 38 deletions(-)

diff --git a/drivers/media/pci/cx23885/cx23885-input.c 
b/drivers/media/pci/cx23885/cx23885-input.c
index 64328d0..410c314 100644
--- a/drivers/media/pci/cx23885/cx23885-input.c
+++ b/drivers/media/pci/cx23885/cx23885-input.c
@@ -293,7 +293,7 @@ int cx23885_input_init(struct cx23885_dev *dev)
case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
/* Integrated CX23885 IR controller */
driver_type = RC_DRIVER_IR_RAW;
-   allowed_protos = RC_BIT_NEC;
+   allowed_protos = RC_BIT_ALL;
/* The grey Terratec remote with orange buttons */
rc_map = RC_MAP_NEC_TERRATEC_CINERGY_XS;
break;
diff --git a/drivers/media/pci/cx88/cx88-input.c 
b/drivers/media/pci/cx88/cx88-input.c
index 3f1342c..6eac81b 100644
--- a/drivers/media/pci/cx88/cx88-input.c
+++ b/drivers/media/pci/cx88/cx88-input.c
@@ -144,7 +144,8 @@ static void cx88_ir_handle_key(struct cx88_IR *ir)
scancode = RC_SCANCODE_NECX(addr, cmd);
 
if (0 == (gpio & ir->mask_keyup))
-   rc_keydown_notimeout(ir->dev, RC_TYPE_NEC, scancode, 0);
+   rc_keydown_notimeout(ir->dev, RC_TYPE_NECX, scancode,
+   0);
else
rc_keyup(ir->dev);
 
@@ -345,7 +346,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev 
*pci)
 * 002-T mini RC, provided with newer PV hardware
 */
ir_codes = RC_MAP_PIXELVIEW_MK12;
-   rc_type = RC_BIT_NEC;
+   rc_type = RC_BIT_NECX;
ir->gpio_addr = MO_GP1_IO;
ir->mask_keyup = 0x80;
ir->polling = 10; /* ms */
diff --git a/drivers/media/pci/saa7134/saa7134-input.c 
b/drivers/media/pci/saa7134/saa7134-input.c
index c8042c3..eff52bb 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -345,7 +345,7 @@ static int get_key_beholdm6xx(struct IR_i2c *ir, enum 
rc_type *protocol,
if (data[9] != (unsigned char)(~data[8]))
return 0;
 
-   *protocol = RC_TYPE_NEC;
+   *protocol = RC_TYPE_NECX;
*scancode = RC_SCANCODE_NECX(data[11] << 8 | data[10], data[9]);
*toggle = 0;
return 1;
@@ -1035,7 +1035,7 @@ void saa7134_probe_i2c_ir(struct saa7134_dev *dev)
dev->init_data.name = "BeholdTV";
dev->init_data.get_key = get_key_beholdm6xx;
dev->init_data.ir_codes = RC_MAP_BEHOLD;
-   dev->init_data.type = RC_BIT_NEC;
+   dev->init_data.type = RC_BIT_NECX;
info.addr = 0x2d;
break;
case SAA7134_BOARD_AVERMEDIA_CARDBUS_501:
diff --git a/drivers/media/rc/igorplugusb.c b/drivers/media/rc/igorplugusb.c
index e0c531f..5cf983b 100644
--- a/drivers/media/rc/igorplugusb.c
+++ b/drivers/media/rc/igorplugusb.c
@@ -203,7 +203,8 @@ static int igorplugusb_probe(struct usb_interface *intf,
 * This device can only store 36 pulses + spaces, which is not enough
 * for the NEC protocol and many others.
 */
-   rc->allowed_protocols = RC_BIT_ALL & ~(RC_BIT_NEC | RC_BIT_RC6_6A_20 |
+   rc->allowed_protocols = RC_BIT_ALL & ~(RC_BIT_NEC | RC_BIT_NECX |
+   RC_BIT_NEC32 | RC_BIT_RC6_6A_20 |
RC_BIT_RC6_6A_24 | RC_BIT_RC6_6A_32 | RC_BIT_RC6_MCE |
  

[PATCH] [media/input] rc: report rc protocol type to userspace through input

2016-09-21 Thread Sean Young
We might want to know what protocol a remote uses when we do not know. With
this patch and another patch for v4l-utils (follows), you can do that with:

./ir-keytable  -p rc-5,nec,rc-6,jvc,sony,sanyo,sharp,xmp -t
Testing events. Please, press CTRL-C to abort.
1474415431.689685: event type EV_MSC(0x04): protocol = RC_TYPE_RC6_MCE
1474415431.689685: event type EV_MSC(0x04): scancode = 0x800f040e
1474415431.689685: event type EV_SYN(0x00).

This makes RC_TYPE_* part of the ABI. We also remove the enum rc_type,
since in input-event-codes.h we cannot not use enums.

In addition, now that the input layer knows the rc protocol and scancode,
at a later point we could add a feature where keymaps could be created
based on both protocol and scancode, not just scancode.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/i2c/ir-kbd-i2c.c  | 17 +
 drivers/media/pci/bt8xx/bttv-input.c|  4 +--
 drivers/media/pci/cx88/cx88-input.c |  4 +--
 drivers/media/pci/ivtv/ivtv-i2c.c   |  4 +--
 drivers/media/pci/saa7134/saa7134-input.c   | 18 +-
 drivers/media/rc/img-ir/img-ir-hw.h |  2 +-
 drivers/media/rc/ir-nec-decoder.c   |  3 +-
 drivers/media/rc/ir-rc5-decoder.c   |  3 +-
 drivers/media/rc/ir-rc6-decoder.c   |  3 +-
 drivers/media/rc/ir-sony-decoder.c  |  3 +-
 drivers/media/rc/rc-main.c  | 11 +++---
 drivers/media/usb/cx231xx/cx231xx-input.c   |  4 +--
 drivers/media/usb/dvb-usb-v2/af9015.c   |  2 +-
 drivers/media/usb/dvb-usb-v2/af9035.c   |  3 +-
 drivers/media/usb/dvb-usb-v2/az6007.c   |  2 +-
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c |  2 +-
 drivers/media/usb/dvb-usb/dib0700_core.c|  2 +-
 drivers/media/usb/dvb-usb/dib0700_devices.c |  3 +-
 drivers/media/usb/dvb-usb/dtt200u.c |  2 +-
 drivers/media/usb/em28xx/em28xx-input.c | 15 
 drivers/media/usb/tm6000/tm6000-input.c |  3 +-
 include/media/i2c/ir-kbd-i2c.h  |  4 +--
 include/media/rc-core.h |  7 ++--
 include/media/rc-map.h  | 54 ++---
 include/uapi/linux/input-event-codes.h  | 28 +++
 25 files changed, 89 insertions(+), 114 deletions(-)

diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index bf82726..f8435fa 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -62,7 +62,7 @@ module_param(debug, int, 0644);/* debug level (0,1,2) */
 
 /* --- */
 
-static int get_key_haup_common(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_haup_common(struct IR_i2c *ir, u32 *protocol,
   u32 *scancode, u8 *ptoggle, int size, int offset)
 {
unsigned char buf[6];
@@ -104,13 +104,13 @@ static int get_key_haup_common(struct IR_i2c *ir, enum 
rc_type *protocol,
return 1;
 }
 
-static int get_key_haup(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_haup(struct IR_i2c *ir, u32 *protocol,
u32 *scancode, u8 *toggle)
 {
return get_key_haup_common (ir, protocol, scancode, toggle, 3, 0);
 }
 
-static int get_key_haup_xvr(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_haup_xvr(struct IR_i2c *ir, u32 *protocol,
u32 *scancode, u8 *toggle)
 {
int ret;
@@ -129,7 +129,7 @@ static int get_key_haup_xvr(struct IR_i2c *ir, enum rc_type 
*protocol,
return get_key_haup_common(ir, protocol, scancode, toggle, 6, 3);
 }
 
-static int get_key_pixelview(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_pixelview(struct IR_i2c *ir, u32 *protocol,
 u32 *scancode, u8 *toggle)
 {
unsigned char b;
@@ -146,7 +146,7 @@ static int get_key_pixelview(struct IR_i2c *ir, enum 
rc_type *protocol,
return 1;
 }
 
-static int get_key_fusionhdtv(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_fusionhdtv(struct IR_i2c *ir, u32 *protocol,
  u32 *scancode, u8 *toggle)
 {
unsigned char buf[4];
@@ -171,7 +171,7 @@ static int get_key_fusionhdtv(struct IR_i2c *ir, enum 
rc_type *protocol,
return 1;
 }
 
-static int get_key_knc1(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_knc1(struct IR_i2c *ir, u32 *protocol,
u32 *scancode, u8 *toggle)
 {
unsigned char b;
@@ -201,7 +201,7 @@ static int get_key_knc1(struct IR_i2c *ir, enum rc_type 
*protocol,
return 1;
 }
 
-static int get_key_avermedia_cardbus(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_avermedia_cardbus(struct IR_i2c *ir, u32 *protocol,
 u32 *scancode, u8 *toggle)
 {
unsigned char subaddr, key, keygroup;
@@ -248,8 +248,7 @@ static int get_key_avermedia_cardbus(struct IR_i2c *ir, 
enum rc_type *pr

[PATCH] [media] v4l-utils: report rc protocol while testing

2016-09-21 Thread Sean Young
If you have a remote and want to see what protocol it uses, simply run
the following. That's enough to write a new keymap.

./ir-keytable  -p rc-5,nec,rc-6,jvc,sony,sanyo,sharp,xmp -t
Testing events. Please, press CTRL-C to abort.
1474415431.689685: event type EV_MSC(0x04): protocol = RC_TYPE_RC6_MCE
1474415431.689685: event type EV_MSC(0x04): scancode = 0x800f040e
1474415431.689685: event type EV_SYN(0x00).
1474415443.857071: event type EV_MSC(0x04): protocol = RC_TYPE_RC5
1474415443.857071: event type EV_MSC(0x04): scancode = 0x1e0f
1474415443.857071: event type EV_SYN(0x00).

Signed-off-by: Sean Young <s...@mess.org>
---
 utils/keytable/Makefile.am |  7 +++
 utils/keytable/keytable.c  |  6 ++
 utils/keytable/parse.h | 26 ++
 3 files changed, 39 insertions(+)

diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
index 62b90ad..73cd676 100644
--- a/utils/keytable/Makefile.am
+++ b/utils/keytable/Makefile.am
@@ -59,6 +59,13 @@ sync-with-kernel:
>> $(srcdir)/parse.h
@printf "\t{ NULL, 0}\n};\n" >> $(srcdir)/parse.h
 
+   @printf "struct parse_event rc_type_events[] = {\n" >> $(srcdir)/parse.h
+   @more $(KERNEL_DIR)/usr/include/linux/input-event-codes.h | perl -n \
+   -e 'if (m/^\#define\s+(RC_TYPE_[^\s]+)\s+(0x[\d\w]+|[\d]+)/) ' \
+   -e '{ printf "\t{\"%s\", %s},\n",$$1,$$2; }' \
+   >> $(srcdir)/parse.h
+   @printf "\t{ NULL, 0}\n};\n" >> $(srcdir)/parse.h
+
@-mkdir -p $(srcdir)/rc_keymaps
@-rm $(srcdir)/rc_keymaps/*
@-cp $(srcdir)/rc_keymaps_userspace/* $(srcdir)/rc_keymaps/
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 3922ad2..d4c295b 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -55,6 +55,10 @@ struct input_keymap_entry_v2 {
 #define EVIOCSKEYCODE_V2   _IOW('E', 0x04, struct input_keymap_entry_v2)
 #endif
 
+#ifndef MSC_RC_TYPE
+#define MSC_RC_TYPE 6
+#endif
+
 struct keytable_entry {
u_int32_t scancode;
u_int32_t keycode;
@@ -1294,6 +1298,8 @@ static void test_event(int fd)
case EV_MSC:
if (ev[i].code == MSC_SCAN)
printf(_(": scancode = 0x%02x\n"), 
ev[i].value);
+   else if (ev[i].code == MSC_RC_TYPE)
+   printf(_(": protocol = %s\n"), 
get_event_name(rc_type_events, ev[i].value));
else
printf(_(": code = %s(0x%02x), value = 
%d\n"),
get_event_name(msc_events, 
ev[i].code),
diff --git a/utils/keytable/parse.h b/utils/keytable/parse.h
index 67eb1a6..10f58ef 100644
--- a/utils/keytable/parse.h
+++ b/utils/keytable/parse.h
@@ -25,6 +25,7 @@ struct parse_event msc_events[] = {
{"MSC_RAW", 0x03},
{"MSC_SCAN", 0x04},
{"MSC_TIMESTAMP", 0x05},
+   {"MSC_RC_TYPE", 0x06},
{"MSC_MAX", 0x07},
{ NULL, 0}
 };
@@ -639,3 +640,28 @@ struct parse_event abs_events[] = {
{"ABS_MAX", 0x3f},
{ NULL, 0}
 };
+struct parse_event rc_type_events[] = {
+   {"RC_TYPE_UNKNOWN", 0},
+   {"RC_TYPE_OTHER", 1},
+   {"RC_TYPE_RC5", 2},
+   {"RC_TYPE_RC5X", 3},
+   {"RC_TYPE_RC5_SZ", 4},
+   {"RC_TYPE_JVC", 5},
+   {"RC_TYPE_SONY12", 6},
+   {"RC_TYPE_SONY15", 7},
+   {"RC_TYPE_SONY20", 8},
+   {"RC_TYPE_NEC", 9},
+   {"RC_TYPE_NECX", 10},
+   {"RC_TYPE_NEC32", 11},
+   {"RC_TYPE_SANYO", 12},
+   {"RC_TYPE_MCE_KBD", 13},
+   {"RC_TYPE_RC6_0", 14},
+   {"RC_TYPE_RC6_6A_20", 15},
+   {"RC_TYPE_RC6_6A_24", 16},
+   {"RC_TYPE_RC6_6A_32", 17},
+   {"RC_TYPE_RC6_MCE", 18},
+   {"RC_TYPE_SHARP", 19},
+   {"RC_TYPE_XMP", 20},
+   {"RC_TYPE_CEC", 21},
+   { NULL, 0}
+};
-- 
2.7.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] v4l-utils: ir-ctl: give proper error message if transmitter does not exist

2016-09-19 Thread Sean Young
If a transmitter does not exist when setting using -e, you get the error:

warning: /dev/lirc0: failed to set send transmitters: Success

Signed-off-by: Sean Young <s...@mess.org>
---
 utils/ir-ctl/ir-ctl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/utils/ir-ctl/ir-ctl.c b/utils/ir-ctl/ir-ctl.c
index 05b46a3..229330e 100644
--- a/utils/ir-ctl/ir-ctl.c
+++ b/utils/ir-ctl/ir-ctl.c
@@ -516,7 +516,9 @@ static int lirc_options(struct arguments *args, int fd, 
unsigned features)
if (args->emitters) {
if (features & LIRC_CAN_SET_TRANSMITTER_MASK) {
rc = ioctl(fd, LIRC_SET_TRANSMITTER_MASK, 
>emitters);
-   if (rc)
+   if (rc > 0)
+   fprintf(stderr, _("warning: %s: failed to set 
send transmitters: only %d available\n"), dev, rc);
+   else if (rc < 0)
fprintf(stderr, _("warning: %s: failed to set 
send transmitters: %m\n"), dev);
} else
fprintf(stderr, _("warning: %s: does not support 
setting send transmitters\n"), dev);
-- 
2.7.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] rc: rc6 decoder should report protocol correctly

2016-09-19 Thread Sean Young
When reporting decoded protocol use the enum rather than the bitmap.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/ir-rc6-decoder.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/ir-rc6-decoder.c 
b/drivers/media/rc/ir-rc6-decoder.c
index e0e2ede..5cc54c9 100644
--- a/drivers/media/rc/ir-rc6-decoder.c
+++ b/drivers/media/rc/ir-rc6-decoder.c
@@ -248,7 +248,7 @@ again:
toggle = 0;
break;
case 24:
-   protocol = RC_BIT_RC6_6A_24;
+   protocol = RC_TYPE_RC6_6A_24;
toggle = 0;
break;
case 32:
@@ -257,7 +257,7 @@ again:
toggle = !!(scancode & 
RC6_6A_MCE_TOGGLE_MASK);
scancode &= ~RC6_6A_MCE_TOGGLE_MASK;
} else {
-   protocol = RC_BIT_RC6_6A_32;
+   protocol = RC_TYPE_RC6_6A_32;
toggle = 0;
}
break;
-- 
2.7.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] rc: Hauppauge z8f0811 can decode RC6

2016-09-19 Thread Sean Young
The hardware does not decode the 16, 20 or 24 bit variety.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/i2c/ir-kbd-i2c.c   | 90 ++--
 drivers/media/pci/cx18/cx18-i2c.c|  3 +-
 drivers/media/pci/cx88/cx88-input.c  |  3 +-
 drivers/media/pci/ivtv/ivtv-i2c.c|  3 +-
 drivers/media/usb/hdpvr/hdpvr-i2c.c  |  2 +-
 drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c |  3 +-
 6 files changed, 69 insertions(+), 35 deletions(-)

diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index bf82726..f95a6bc 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -35,6 +35,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -63,51 +64,80 @@ module_param(debug, int, 0644);/* debug level (0,1,2) */
 /* --- */
 
 static int get_key_haup_common(struct IR_i2c *ir, enum rc_type *protocol,
-  u32 *scancode, u8 *ptoggle, int size, int offset)
+   u32 *scancode, u8 *ptoggle, int size)
 {
unsigned char buf[6];
-   int start, range, toggle, dev, code, ircode;
+   int start, range, toggle, dev, code, ircode, vendor;
 
/* poll IR chip */
if (size != i2c_master_recv(ir->c, buf, size))
return -EIO;
 
-   /* split rc5 data block ... */
-   start  = (buf[offset] >> 7) &1;
-   range  = (buf[offset] >> 6) &1;
-   toggle = (buf[offset] >> 5) &1;
-   dev=  buf[offset]   & 0x1f;
-   code   = (buf[offset+1] >> 2) & 0x3f;
+   if (buf[0] & 0x80) {
+   int offset = (size == 6) ? 3 : 0;
 
-   /* rc5 has two start bits
-* the first bit must be one
-* the second bit defines the command range (1 = 0-63, 0 = 64 - 127)
-*/
-   if (!start)
-   /* no key pressed */
-   return 0;
+   /* split rc5 data block ... */
+   start  = (buf[offset] >> 7) &1;
+   range  = (buf[offset] >> 6) &1;
+   toggle = (buf[offset] >> 5) &1;
+   dev=  buf[offset]   & 0x1f;
+   code   = (buf[offset+1] >> 2) & 0x3f;
 
-   /* filter out invalid key presses */
-   ircode = (start << 12) | (toggle << 11) | (dev << 6) | code;
-   if ((ircode & 0x1fff) == 0x1fff)
-   return 0;
+   /* rc5 has two start bits
+* the first bit must be one
+* the second bit defines the command range:
+* 1 = 0-63, 0 = 64 - 127
+*/
+   if (!start)
+   /* no key pressed */
+   return 0;
 
-   if (!range)
-   code += 64;
+   /* filter out invalid key presses */
+   ircode = (start << 12) | (toggle << 11) | (dev << 6) | code;
+   if ((ircode & 0x1fff) == 0x1fff)
+   return 0;
 
-   dprintk(1,"ir hauppauge (rc5): s%d r%d t%d dev=%d code=%d\n",
-   start, range, toggle, dev, code);
+   if (!range)
+   code += 64;
 
-   *protocol = RC_TYPE_RC5;
-   *scancode = RC_SCANCODE_RC5(dev, code);
-   *ptoggle = toggle;
-   return 1;
+   dprintk(1, "ir hauppauge (rc5): s%d r%d t%d dev=%d code=%d\n",
+   start, range, toggle, dev, code);
+
+   *protocol = RC_TYPE_RC5;
+   *scancode = RC_SCANCODE_RC5(dev, code);
+   *ptoggle = toggle;
+
+   return 1;
+   } else if (size == 6 && (buf[0] & 0x40)) {
+   code = buf[4];
+   dev = buf[3];
+   vendor = get_unaligned_be16(buf + 1);
+
+   if (vendor == 0x800f) {
+   *ptoggle = (dev & 0x80) != 0;
+   *protocol = RC_TYPE_RC6_MCE;
+   dev &= 0x7f;
+   dprintk(1, "ir hauppauge (rc6-mce): t%d vendor=%d 
dev=%d code=%d\n",
+   toggle, vendor, dev, code);
+   } else {
+   *ptoggle = 0;
+   *protocol = RC_TYPE_RC6_6A_32;
+   dprintk(1, "ir hauppauge (rc6-6a-32): vendor=%d dev=%d 
code=%d\n",
+   vendor, dev, code);
+   }
+
+   *scancode = RC_SCANCODE_RC6_6A(vendor, dev, code);
+
+   return 1;
+   }
+
+   return 0;
 }
 
 static int get_key_haup(struct IR_i2c *ir, enum rc_type *protocol,
u32 *scancode, u8 *toggle)
 {
-   return g

[PATCH] v4l-utils: ir-ctl: deal with consecutive pulses or spaces correctly

2016-09-19 Thread Sean Young
When sending a pulse-space file with consecutive spaces or pulses, add them
together correctly. For example:

pulse 100
space 150
space 100
pulse 150
pulse 200

Would send pulse 100, space 250, and pulse 350.

Signed-off-by: Sean Young <s...@mess.org>
---
 utils/ir-ctl/ir-ctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/utils/ir-ctl/ir-ctl.c b/utils/ir-ctl/ir-ctl.c
index 229330e..2f85e6d 100644
--- a/utils/ir-ctl/ir-ctl.c
+++ b/utils/ir-ctl/ir-ctl.c
@@ -211,7 +211,7 @@ static struct file *read_file(const char *fname)
fprintf(stderr, _("warning: %s:%d: 
leading space ignored\n"),
fname, lineno);
} else {
-   f->buf[len] += arg;
+   f->buf[len-1] += arg;
}
} else {
f->buf[len++] = arg;
@@ -220,7 +220,7 @@ static struct file *read_file(const char *fname)
expect_pulse = true;
} else if (strcmp(keyword, "pulse") == 0) {
if (!expect_pulse)
-   f->buf[len] += arg;
+   f->buf[len-1] += arg;
else
f->buf[len++] = arg;
expect_pulse = false;
-- 
2.7.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


Re: [PATCH v2 7/7] [media] rc: add support for IR LEDs driven through SPI

2016-09-02 Thread Sean Young
On Fri, Sep 02, 2016 at 02:27:08PM +0900, Andi Shyti wrote:
> > Thanks Andi, this is looking great!
> 
> Thanks Sean! With your reviews the whole thing looks much better
> now :)
> 
> I agree with all your points here, I will fix them. Can I add
> your reviewd-by?

Yes, please add it to this patch.

Thanks,

Sean
--
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 5/7] [media] ir-lirc-codec: don't wait any transmitting time for tx only devices

2016-09-02 Thread Sean Young
On Fri, Sep 02, 2016 at 02:16:27AM +0900, Andi Shyti wrote:
> Transmitters do not need to wait until the data has been sent
> (and of course received). Return before waiting.
> 
> Signed-off-by: Andi Shyti <andi.sh...@samsung.com>
> ---
>  drivers/media/rc/ir-lirc-codec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/rc/ir-lirc-codec.c 
> b/drivers/media/rc/ir-lirc-codec.c
> index c327730..d8953fb 100644
> --- a/drivers/media/rc/ir-lirc-codec.c
> +++ b/drivers/media/rc/ir-lirc-codec.c
> @@ -153,7 +153,7 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> const char __user *buf,
>   }
>  
>   ret = dev->tx_ir(dev, txbuf, count);
> - if (ret < 0)
> + if (ret < 0 || dev->driver_type == RC_DRIVER_IR_RAW_TX)

Just because a driver only does transmit doesn't mean its transmit ABI
should change.

Now this bit of code is pretty horrible. It ensures that the call to write()
takes at least as long as the length of the transmit IR by sleeping. That's
not much of a guarantee that the IR has been sent.

Note that in the case of ir-spi, since your spi transfer is sync no sleep
should be introduced here.

The gap calculation in lirc checks that if the call to write() took _longer_
than expected wait before sending the next IR code (when either multiple
IR codes or repeats are specified). Introducing the sleep in the kernel
here does not help at all, lirc already ensures that it waits as long as
the IR is long (see schedule_repeat_timer in lirc).

This change was introduced in 3.10, commit f8e00d5. 


Sean
--
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 3/7] [media] rc-core: add support for IR raw transmitters

2016-09-01 Thread Sean Young
On Fri, Sep 02, 2016 at 02:16:25AM +0900, Andi Shyti wrote:
> IR raw transmitter driver type is specified in the enum
> rc_driver_type as RC_DRIVER_IR_RAW_TX which includes all those
> devices that transmit raw stream of bit to a receiver.
> 
> The data are provided by userspace applications, therefore they
> don't need any input device allocation, but still they need to be
> registered as raw devices.
> 
> Suggested-by: Sean Young <s...@mess.org>
> Signed-off-by: Andi Shyti <andi.sh...@samsung.com>
> ---
>  drivers/media/rc/rc-main.c | 39 +++
>  include/media/rc-core.h|  9 ++---
>  2 files changed, 29 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 7961083..c3c1f68 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -1361,20 +1361,24 @@ struct rc_dev *rc_allocate_device(enum rc_driver_type 
> type)
>   if (!dev)
>   return NULL;
>  
> - dev->input_dev = input_allocate_device();
> - if (!dev->input_dev) {
> - kfree(dev);
> - return NULL;
> - }
> + if (type != RC_DRIVER_IR_RAW_TX) {
> + dev->input_dev = input_allocate_device();
> + if (!dev->input_dev) {
> + kfree(dev);
> + return NULL;
> + }
> +
> + dev->input_dev->getkeycode = ir_getkeycode;
> + dev->input_dev->setkeycode = ir_setkeycode;
> + input_set_drvdata(dev->input_dev, dev);
>  
> - dev->input_dev->getkeycode = ir_getkeycode;
> - dev->input_dev->setkeycode = ir_setkeycode;
> - input_set_drvdata(dev->input_dev, dev);
> + setup_timer(>timer_keyup, ir_timer_keyup,
> + (unsigned long)dev);
>  
> - spin_lock_init(>rc_map.lock);
> - spin_lock_init(>keylock);
> + spin_lock_init(>rc_map.lock);
> + spin_lock_init(>keylock);
> + }
>   mutex_init(>lock);
> - setup_timer(>timer_keyup, ir_timer_keyup, (unsigned long)dev);
>  
>   dev->dev.type = _dev_type;
>   dev->dev.class = _class;
> @@ -1474,7 +1478,7 @@ out_table:
>  
>  static void rc_free_rx_device(struct rc_dev *dev)
>  {
> - if (!dev)
> + if (!dev || dev->driver_type == RC_DRIVER_IR_RAW_TX)
>   return;
>  
>   ir_free_table(>rc_map);
> @@ -1522,11 +1526,14 @@ int rc_register_device(struct rc_dev *dev)

An tx-only device shouldn't have the sysfs attribute protocol, that
should be handled here too.

>   dev->input_name ?: "Unspecified device", path ?: "N/A");
>   kfree(path);
>  
> - rc = rc_setup_rx_device(dev);
> - if (rc)
> - goto out_dev;
> + if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
> + rc = rc_setup_rx_device(dev);
> + if (rc)
> + goto out_dev;
> + }
>  
> - if (dev->driver_type == RC_DRIVER_IR_RAW) {
> + if (dev->driver_type == RC_DRIVER_IR_RAW ||
> + dev->driver_type == RC_DRIVER_IR_RAW_TX) {
>   if (!raw_init) {
>   request_module_nowait("ir-lirc-codec");
>   raw_init = true;
> diff --git a/include/media/rc-core.h b/include/media/rc-core.h
> index 4fc60dd..56e33c1 100644
> --- a/include/media/rc-core.h
> +++ b/include/media/rc-core.h
> @@ -32,13 +32,16 @@ do {  
> \
>  /**
>   * enum rc_driver_type - type of the RC output
>   *
> - * @RC_DRIVER_SCANCODE:  Driver or hardware generates a scancode
> - * @RC_DRIVER_IR_RAW:Driver or hardware generates pulse/space 
> sequences.
> - *   It needs a Infra-Red pulse/space decoder
> + * @RC_DRIVER_SCANCODE:   Driver or hardware generates a scancode
> + * @RC_DRIVER_IR_RAW: Driver or hardware generates pulse/space 
> sequences.
> + *It needs a Infra-Red pulse/space decoder
> + * @RC_DRIVER_IR_RAW_TX: Device transmitter only,
> +  driver requires pulce/spce data sequence.
>   */
>  enum rc_driver_type {
>   RC_DRIVER_SCANCODE = 0,
>   RC_DRIVER_IR_RAW,
> + RC_DRIVER_IR_RAW_TX,
>  };
>  
>  /**
> -- 
> 2.9.3
--
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 1/7] [media] rc-main: assign driver type during allocation

2016-09-01 Thread Sean Young
On Fri, Sep 02, 2016 at 02:16:23AM +0900, Andi Shyti wrote:
> The driver type can be assigned immediately when an RC device
> requests to the framework to allocate the device.
> 
> This is an 'enum rc_driver_type' data type and specifies whether
> the device is a raw receiver or scancode receiver. The type will
> be given as parameter to the rc_allocate_device device.
> 
> Change accordingly all the drivers calling rc_allocate_device()
> so that the device type is specified during the rc device
> allocation. Whenever the device type is not specified, it will be
> set as RC_DRIVER_SCANCODE which was the default '0' value.
> 
> Suggested-by: Sean Young <s...@mess.org>
> Signed-off-by: Andi Shyti <andi.sh...@samsung.com>
> ---

...

> diff --git a/drivers/media/pci/cx88/cx88-input.c 
> b/drivers/media/pci/cx88/cx88-input.c
> index 3f1342c..e52bf69 100644
> --- a/drivers/media/pci/cx88/cx88-input.c
> +++ b/drivers/media/pci/cx88/cx88-input.c
> @@ -271,7 +271,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev 
> *pci)
>*/
>  
>   ir = kzalloc(sizeof(*ir), GFP_KERNEL);
> - dev = rc_allocate_device();
> + dev = rc_allocate_device(RC_DRIVER_IR_RAW);
>   if (!ir || !dev)
>   goto err_out_free;
>  

If ir->sampling = 0 then it should be RC_DRIVER_SCANCODE.


> @@ -481,7 +481,6 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev 
> *pci)
>   dev->scancode_mask = hardware_mask;
>  
>   if (ir->sampling) {
> - dev->driver_type = RC_DRIVER_IR_RAW;
>   dev->timeout = 10 * 1000 * 1000; /* 10 ms */
>   } else {
>   dev->driver_type = RC_DRIVER_SCANCODE;

That assignment shouldn't really be there any more.


> diff --git a/drivers/media/pci/saa7134/saa7134-input.c 
> b/drivers/media/pci/saa7134/saa7134-input.c
> index c8042c3..e9d4a47 100644
> --- a/drivers/media/pci/saa7134/saa7134-input.c
> +++ b/drivers/media/pci/saa7134/saa7134-input.c
> @@ -849,7 +849,7 @@ int saa7134_input_init1(struct saa7134_dev *dev)
>   }
>  
>   ir = kzalloc(sizeof(*ir), GFP_KERNEL);
> - rc = rc_allocate_device();
> + rc = rc_allocate_device(RC_DRIVER_SCANCODE);
>   if (!ir || !rc) {
>   err = -ENOMEM;
>   goto err_out_free;

This is not correct, I'm afraid. If you look at the code you can see that
if raw_decode is true, then it should be RC_DRIVER_IR_RAW.


Sean
--
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 7/7] [media] rc: add support for IR LEDs driven through SPI

2016-09-01 Thread Sean Young
Thanks Andi, this is looking great!

On Fri, Sep 02, 2016 at 02:16:29AM +0900, Andi Shyti wrote:
> The ir-spi is a simple device driver which supports the
> connection between an IR LED and the MOSI line of an SPI device.
> 
> The driver, indeed, uses the SPI framework to stream the raw data
> provided by userspace through an rc character device. The chardev
> is handled by the LIRC framework and its functionality basically
> provides:
> 
>  - write: the driver gets a pulse/space signal and translates it
>to a binary signal that will be streamed to the IR led through
>the SPI framework.
>  - set frequency: sets the frequency whith which the data should
>be sent. This is handle with ioctl with the
>LIRC_SET_SEND_CARRIER flag (as per lirc documentation)
>  - set duty cycle: this is also handled with ioctl with the
>LIRC_SET_SEND_DUTY_CYCLE flag. The driver handles duty cycles
>of 50%, 60%, 70%, 75%, 80% and 90%, calculated on 16bit data.
> 
> The character device is created under /dev/lircX name, where X is
> and ID assigned by the LIRC framework.
> 
> Example of usage:
> 
> fd = open("/dev/lirc0", O_RDWR);
> if (fd < 0)
> return -1;
> 
> val = 608000;
> ret = ioctl(fd, LIRC_SET_SEND_CARRIER, );
> if (ret < 0)
> return -1;
> 
>   val = 60;
> ret = ioctl(fd, LIRC_SET_SEND_DUTY_CYCLE, );
> if (ret < 0)
> return -1;
> 
> n = write(fd, buffer, BUF_LEN);
> if (n < 0 || n != BUF_LEN)
> ret = -1;
> 
> close(fd);
> 
> Signed-off-by: Andi Shyti 
> ---
>  drivers/media/rc/Kconfig  |   9 ++
>  drivers/media/rc/Makefile |   1 +
>  drivers/media/rc/ir-spi.c | 221 
> ++
>  3 files changed, 231 insertions(+)
>  create mode 100644 drivers/media/rc/ir-spi.c
> 
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 370e16e..207dfcc 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -261,6 +261,15 @@ config IR_REDRAT3
>  To compile this driver as a module, choose M here: the
>  module will be called redrat3.
>  
> +config IR_SPI
> + tristate "SPI connected IR LED"
> + depends on SPI && LIRC
> + ---help---
> +   Say Y if you want to use an IR LED connected through SPI bus.
> +
> +   To compile this driver as a module, choose M here: the module will be
> +   called ir-spi.
> +
>  config IR_STREAMZAP
>   tristate "Streamzap PC Remote IR Receiver"
>   depends on USB_ARCH_HAS_HCD
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 379a5c0..1417c8d 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
>  obj-$(CONFIG_IR_ENE) += ene_ir.o
>  obj-$(CONFIG_IR_REDRAT3) += redrat3.o
>  obj-$(CONFIG_IR_RX51) += ir-rx51.o
> +obj-$(CONFIG_IR_SPI) += ir-spi.o
>  obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
>  obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
>  obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
> diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
> new file mode 100644
> index 000..34d5a0c
> --- /dev/null
> +++ b/drivers/media/rc/ir-spi.c
> @@ -0,0 +1,221 @@
> +/*
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + * Author: Andi Shyti 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * SPI driven IR LED device driver
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IR_SPI_DRIVER_NAME   "ir-spi"
> +
> +/* pulse value for different duty cycles */
> +#define IR_SPI_PULSE_DC_50   0xff00
> +#define IR_SPI_PULSE_DC_60   0xfc00
> +#define IR_SPI_PULSE_DC_70   0xf800
> +#define IR_SPI_PULSE_DC_75   0xf000
> +#define IR_SPI_PULSE_DC_80   0xc000
> +#define IR_SPI_PULSE_DC_90   0x8000
> +
> +/* duty cycles values */
> +#define IR_SPI_DUTY_CYCLE_50 50
> +#define IR_SPI_DUTY_CYCLE_60 60
> +#define IR_SPI_DUTY_CYCLE_70 70
> +#define IR_SPI_DUTY_CYCLE_75 75
> +#define IR_SPI_DUTY_CYCLE_80 80
> +#define IR_SPI_DUTY_CYCLE_90 90

Not sure what these defines are for. 50 = 50?

> +
> +#define IR_SPI_DEFAULT_FREQUENCY 38000
> +#define IR_SPI_BIT_PER_WORD  8
> +#define IR_SPI_MAX_BUFSIZE4096
> +
> +struct ir_spi_data {
> + u32 freq;
> + u8 duty_cycle;
> + bool negated;
> +
> + u16 tx_buf[IR_SPI_MAX_BUFSIZE];
> + u16 pulse;
> + u16 space;
> +
> + struct rc_dev *rc;
> + struct spi_device *spi;
> + struct regulator *regulator;
> +};
> +
> +static int ir_spi_tx(struct rc_dev 

Re: [RFC 5/7] [media] ir-lirc-codec: do not handle any buffer for raw transmitters

2016-07-21 Thread Sean Young
Hi Andi,

On Thu, Jul 21, 2016 at 09:48:12AM +0900, Andi Shyti wrote:
> > > Raw transmitters receive the data which need to be sent to
> > > receivers from userspace as stream of bits, they don't require
> > > any handling from the lirc framework.
> > 
> > No drivers of type RC_DRIVER_IR_RAW_TX should handle tx just like any
> > other device, so data should be provided as an array of u32 alternating
> > pulse-space. If your device does not handle input like that then convert
> > it into that format in the driver. Every other driver has to do some
> > sort of conversion of that kind.
> 
> I don't see anything wrong here, that's how it works for example
> in Tizen or in Android for the boards I'm on: userspace sends a
> stream of bits that are then submitted to the IR as they are.

This introduces a new, incompatible api with no way of detecting it.

It's not a good format. For example the leading pulse (9ms) for nec ir
with a carrier of 38000 will be 342 bits. With the pulse-space format
it will be 32 bits.

Doing the conversion in kernel space will be cheap.

> If I change it to only pulse-space domain, then I wouldn't
> provide support for those platforms. Eventually I can add a new
> protocol.

But this is forcing an new, incompatible api onto the rest of us. 

This is the code in tizen:

https://build.tizen.org/package/rdiff?linkrev=base=device-manager-plugin-exynos5433=Tizen%3AIVI=2

If this patch was merged as-is tizen would have to be changed anyway
to use different ioctls. If that is true, can it switch to use 
pulse-space format in the same change? If LIRC_GET_FREQUENCY fails then
it would be a main-line kernel, else the existent driver.

I could not find the code in android. It might be useful to see so we
can find a solution that works for everyone.


Sean
--
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: [RFC 7/7] [media] rc: add support for IR LEDs driven through SPI

2016-07-21 Thread Sean Young
Hi Andi,

On Thu, Jul 21, 2016 at 10:09:26AM +0900, Andi Shyti wrote:
> > > + ret = regulator_enable(idata->regulator);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + mutex_lock(>mutex);
> > > + idata->xfer.len = n;
> > > + idata->xfer.tx_buf = buffer;
> > > + mutex_unlock(>mutex);
> > 
> > I'm not convinced the locking works here. You want to guard against 
> > someone modifying xfer while you are sending (so in spi_sync_transfer), 
> > which this locking is not doing. You could declare a 
> > local "struct spi_transfer xfer" and avoid the mutex altogether.
> 
> I cannot declare xfer locally because the spi framework needs
> a statically allocated xfer, so that either I dynamically
> allocate it in the function or I declare it global in idata.

It can be stack allocated for sync transfers. You might want to lock
the spi bus.

> With the mutex I would like to prevent different tasks to change
> the value at the same time, it's an easy case, it shouldn't make
> much difference.

That's cargo-cult locking. It does not achieve anything.


Sean
--
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/2] [media] redrat3: remove hw_timeout member

2016-07-20 Thread Sean Young
This is a duplicate of the timeout in rc_dev.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/redrat3.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 399f44d..4739bce 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -188,9 +188,6 @@ struct redrat3_dev {
/* usb dma */
dma_addr_t dma_in;
 
-   /* rx signal timeout */
-   u32 hw_timeout;
-
/* Is the device currently transmitting?*/
bool transmitting;
 
@@ -372,7 +369,7 @@ static void redrat3_process_ir_data(struct redrat3_dev *rr3)
/* add a trailing space */
rawir.pulse = false;
rawir.timeout = true;
-   rawir.duration = US_TO_NS(rr3->hw_timeout);
+   rawir.duration = rr3->rc->timeout;
dev_dbg(dev, "storing trailing timeout with duration %d\n",
rawir.duration);
ir_raw_event_store_with_filter(rr3->rc, );
@@ -495,10 +492,9 @@ static int redrat3_set_timeout(struct rc_dev *rc_dev, 
unsigned int timeoutns)
dev_dbg(dev, "set ir parm timeout %d ret 0x%02x\n",
be32_to_cpu(*timeout), ret);
 
-   if (ret == sizeof(*timeout)) {
-   rr3->hw_timeout = timeoutns / 1000;
+   if (ret == sizeof(*timeout))
ret = 0;
-   } else if (ret >= 0)
+   else if (ret >= 0)
ret = -EIO;
 
kfree(timeout);
@@ -889,7 +885,7 @@ static struct rc_dev *redrat3_init_rc_dev(struct 
redrat3_dev *rr3)
rc->allowed_protocols = RC_BIT_ALL;
rc->min_timeout = MS_TO_NS(RR3_RX_MIN_TIMEOUT);
rc->max_timeout = MS_TO_NS(RR3_RX_MAX_TIMEOUT);
-   rc->timeout = US_TO_NS(rr3->hw_timeout);
+   rc->timeout = US_TO_NS(redrat3_get_timeout(rr3));
rc->s_timeout = redrat3_set_timeout;
rc->tx_ir = redrat3_transmit_ir;
rc->s_tx_carrier = redrat3_set_tx_carrier;
@@ -1000,9 +996,6 @@ static int redrat3_dev_probe(struct usb_interface *intf,
if (retval < 0)
goto error;
 
-   /* store current hardware timeout, in µs */
-   rr3->hw_timeout = redrat3_get_timeout(rr3);
-
/* default.. will get overridden by any sends with a freq defined */
rr3->carrier = 38000;
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/2] [media] redrat3: hardware-specific parameters

2016-07-20 Thread Sean Young
Add these options as module parameters for now; should other drivers
need similar options we could add it to the LIRC api.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/redrat3.c | 50 +-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 4739bce..68df9d7 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -124,6 +124,41 @@
 #define USB_RR3USB_PRODUCT_ID  0x0001
 #define USB_RR3IIUSB_PRODUCT_ID0x0005
 
+
+/*
+ * The redrat3 encodes an IR signal as set of different lengths and a set
+ * of indices into those lengths. This sets how much two lengths must
+ * differ before they are considered distinct, the value is specified
+ * in microseconds.
+ * Default 5, value 0 to 127.
+ */
+static int length_fuzz = 5;
+module_param(length_fuzz, uint, 0644);
+MODULE_PARM_DESC(length_fuzz, "Length Fuzz (0-127)");
+
+/*
+ * When receiving a continuous ir stream (for example when a user is
+ * holding a button down on a remote), this specifies the minimum size
+ * of a space when the redrat3 sends a irdata packet to the host. Specified
+ * in miliseconds. Default value 18ms.
+ * The value can be between 2 and 30 inclusive.
+ */
+static int minimum_pause = 18;
+module_param(minimum_pause, uint, 0644);
+MODULE_PARM_DESC(minimum_pause, "Minimum Pause in ms (2-30)");
+
+/*
+ * The carrier frequency is measured during the first pulse of the IR
+ * signal. The larger the number of periods used To measure, the more
+ * accurate the result is likely to be, however some signals have short
+ * initial pulses, so in some case it may be necessary to reduce this value.
+ * Default 8, value 1 to 255.
+ */
+static int periods_measure_carrier = 8;
+module_param(periods_measure_carrier, uint, 0644);
+MODULE_PARM_DESC(periods_measure_carrier, "Number of Periods to Measure 
Carrier (1-255)");
+
+
 struct redrat3_header {
__be16 length;
__be16 transfer_type;
@@ -525,12 +560,25 @@ static void redrat3_reset(struct redrat3_dev *rr3)
 RR3_CPUCS_REG_ADDR, 0, val, len, HZ * 25);
dev_dbg(dev, "reset returned 0x%02x\n", rc);
 
-   *val = 5;
+   *val = length_fuzz;
rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
 USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
 RR3_IR_IO_LENGTH_FUZZ, 0, val, len, HZ * 25);
dev_dbg(dev, "set ir parm len fuzz %d rc 0x%02x\n", *val, rc);
 
+   *val = (65536 - (minimum_pause * 2000)) / 256;
+   rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
+USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+RR3_IR_IO_MIN_PAUSE, 0, val, len, HZ * 25);
+   dev_dbg(dev, "set ir parm min pause %d rc 0x%02x\n", *val, rc);
+
+   *val = periods_measure_carrier;
+   rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
+USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+RR3_IR_IO_PERIODS_MF, 0, val, len, HZ * 25);
+   dev_dbg(dev, "set ir parm periods measure carrier %d rc 0x%02x", *val,
+   rc);
+
*val = RR3_DRIVER_MAXLENS;
rc = usb_control_msg(udev, txpipe, RR3_SET_IR_PARAM,
 USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
-- 
2.7.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] ir-ctl: give proper error message if transmitter does not exist

2016-07-20 Thread Sean Young
If a transmitter does not exist when setting using -e, you get the error:

warning: /dev/lirc0: failed to set send transmitters: Success

Signed-off-by: Sean Young <s...@mess.org>
---
 utils/ir-ctl/ir-ctl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/utils/ir-ctl/ir-ctl.c b/utils/ir-ctl/ir-ctl.c
index 05b46a3..229330e 100644
--- a/utils/ir-ctl/ir-ctl.c
+++ b/utils/ir-ctl/ir-ctl.c
@@ -516,7 +516,9 @@ static int lirc_options(struct arguments *args, int fd, 
unsigned features)
if (args->emitters) {
if (features & LIRC_CAN_SET_TRANSMITTER_MASK) {
rc = ioctl(fd, LIRC_SET_TRANSMITTER_MASK, 
>emitters);
-   if (rc)
+   if (rc > 0)
+   fprintf(stderr, _("warning: %s: failed to set 
send transmitters: only %d available\n"), dev, rc);
+   else if (rc < 0)
fprintf(stderr, _("warning: %s: failed to set 
send transmitters: %m\n"), dev);
} else
fprintf(stderr, _("warning: %s: does not support 
setting send transmitters\n"), dev);
-- 
2.7.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


Re: [RFC 7/7] [media] rc: add support for IR LEDs driven through SPI

2016-07-19 Thread Sean Young
On Wed, Jul 20, 2016 at 12:56:58AM +0900, Andi Shyti wrote:
> The ir-spi is a simple device driver which supports the
> connection between an IR LED and the MOSI line of an SPI device.
> 
> The driver, indeed, uses the SPI framework to stream the raw data
> provided by userspace through a character device. The chardev is
> handled by the LIRC framework and its functionality basically
> provides:
> 
>  - raw write: data to be sent to the SPI and then streamed to the
>MOSI line;
>  - set frequency: sets the frequency whith which the data should
>be sent;
> 
> The character device is created under /dev/lircX name, where X is
> and ID assigned by the LIRC framework.
> 
> Example of usage:
> 
> fd = open("/dev/lirc0", O_RDWR);
> if (fd < 0)
> return -1;
> 
> val = 608000;
> ret = ioctl(fd, LIRC_SET_SEND_CARRIER, );
> if (ret < 0)
> return -1;
> 
> n = write(fd, buffer, BUF_LEN);
> if (n < 0 || n != BUF_LEN)
> ret = -1;
> 
> close(fd);
> 
> Signed-off-by: Andi Shyti 
> ---
>  drivers/media/rc/Kconfig  |   9 
>  drivers/media/rc/Makefile |   1 +
>  drivers/media/rc/ir-spi.c | 133 
> ++
>  3 files changed, 143 insertions(+)
>  create mode 100644 drivers/media/rc/ir-spi.c
> 
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index bd4d685..dacaa29 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -261,6 +261,15 @@ config IR_REDRAT3
>  To compile this driver as a module, choose M here: the
>  module will be called redrat3.
>  
> +config IR_SPI
> + tristate "SPI connected IR LED"
> + depends on SPI && LIRC
> + ---help---
> +   Say Y if you want to use an IR LED connected through SPI bus.
> +
> +   To compile this driver as a module, choose M here: the module will be
> +   called ir-spi.
> +
>  config IR_STREAMZAP
>   tristate "Streamzap PC Remote IR Receiver"
>   depends on USB_ARCH_HAS_HCD
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 379a5c0..1417c8d 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
>  obj-$(CONFIG_IR_ENE) += ene_ir.o
>  obj-$(CONFIG_IR_REDRAT3) += redrat3.o
>  obj-$(CONFIG_IR_RX51) += ir-rx51.o
> +obj-$(CONFIG_IR_SPI) += ir-spi.o
>  obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
>  obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
>  obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
> diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
> new file mode 100644
> index 000..7b6f344
> --- /dev/null
> +++ b/drivers/media/rc/ir-spi.c
> @@ -0,0 +1,133 @@
> +/*
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + * Author: Andi Shyti 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * SPI driven IR LED device driver
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IR_SPI_DRIVER_NAME   "ir-spi"
> +
> +#define IR_SPI_DEFAULT_FREQUENCY 38000
> +#define IR_SPI_BIT_PER_WORD  8
> +
> +struct ir_spi_data {
> + struct rc_dev *rc;
> + struct spi_device *spi;
> + struct spi_transfer xfer;
> + struct mutex mutex;
> + struct regulator *regulator;
> +};
> +
> +static int ir_spi_tx(struct rc_dev *dev, unsigned *buffer, unsigned n)
> +{
> + int ret;
> + struct ir_spi_data *idata = (struct ir_spi_data *) dev->priv;

No cast needed.

> +
> + ret = regulator_enable(idata->regulator);
> + if (ret)
> + return ret;
> +
> + mutex_lock(>mutex);
> + idata->xfer.len = n;
> + idata->xfer.tx_buf = buffer;
> + mutex_unlock(>mutex);

I'm not convinced the locking works here. You want to guard against 
someone modifying xfer while you are sending (so in spi_sync_transfer), 
which this locking is not doing. You could declare a 
local "struct spi_transfer xfer" and avoid the mutex altogether.

As discussed here you should be converting from pulse-space also.

> +
> + ret = spi_sync_transfer(idata->spi, >xfer, 1);
> + if (ret)
> + dev_err(>spi->dev, "unable to deliver the signal\n");
> +
> + regulator_disable(idata->regulator);
> +
> + return ret;
> +}
> +
> +static int ir_spi_set_tx_carrier(struct rc_dev *dev, u32 carrier)
> +{
> + struct ir_spi_data *idata = (struct ir_spi_data *) dev->priv;

No cast needed here.

> +
> + if (!carrier)
> + return -EINVAL;
> +
> + mutex_lock(>mutex);
> + idata->xfer.speed_hz = carrier;
> + mutex_unlock(>mutex);
> +
> + return 0;
> +}
> +
> +static int ir_spi_probe(struct spi_device *spi)
> +{
> +

Re: [RFC 5/7] [media] ir-lirc-codec: do not handle any buffer for raw transmitters

2016-07-19 Thread Sean Young
On Wed, Jul 20, 2016 at 12:56:56AM +0900, Andi Shyti wrote:
> Raw transmitters receive the data which need to be sent to
> receivers from userspace as stream of bits, they don't require
> any handling from the lirc framework.

No drivers of type RC_DRIVER_IR_RAW_TX should handle tx just like any
other device, so data should be provided as an array of u32 alternating
pulse-space. If your device does not handle input like that then convert
it into that format in the driver. Every other driver has to do some
sort of conversion of that kind.

Thanks

Sean


> 
> Signed-off-by: Andi Shyti <andi.sh...@samsung.com>
> ---
>  drivers/media/rc/ir-lirc-codec.c | 30 +++---
>  1 file changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/rc/ir-lirc-codec.c 
> b/drivers/media/rc/ir-lirc-codec.c
> index 5effc65..80e94b6 100644
> --- a/drivers/media/rc/ir-lirc-codec.c
> +++ b/drivers/media/rc/ir-lirc-codec.c
> @@ -121,17 +121,6 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> const char __user *buf,
>   if (!lirc)
>   return -EFAULT;
>  
> - if (n < sizeof(unsigned) || n % sizeof(unsigned))
> - return -EINVAL;
> -
> - count = n / sizeof(unsigned);
> - if (count > LIRCBUF_SIZE || count % 2 == 0)
> - return -EINVAL;
> -
> - txbuf = memdup_user(buf, n);
> - if (IS_ERR(txbuf))
> - return PTR_ERR(txbuf);
> -
>   dev = lirc->dev;
>   if (!dev) {
>   ret = -EFAULT;
> @@ -143,6 +132,25 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
> const char __user *buf,
>   goto out;
>   }
>  
> + if (dev->driver_type == RC_DRIVER_IR_RAW_TX) {
> + txbuf = memdup_user(buf, n);
> + if (IS_ERR(txbuf))
> + return PTR_ERR(txbuf);
> +
> + return dev->tx_ir(dev, txbuf, n);
> + }
> +
> + if (n < sizeof(unsigned) || n % sizeof(unsigned))
> + return -EINVAL;
> +
> + count = n / sizeof(unsigned);
> + if (count > LIRCBUF_SIZE || count % 2 == 0)
> + return -EINVAL;
> +
> + txbuf = memdup_user(buf, n);
> + if (IS_ERR(txbuf))
> + return PTR_ERR(txbuf);
> +
>   for (i = 0; i < count; i++) {
>   if (txbuf[i] > IR_MAX_DURATION / 1000 - duration || !txbuf[i]) {
>   ret = -EINVAL;
> -- 
> 2.8.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
--
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: [RFC 3/7] [media] rc-core: add support for IR raw transmitters

2016-07-19 Thread Sean Young
On Wed, Jul 20, 2016 at 12:56:54AM +0900, Andi Shyti wrote:
> IR raw transmitter driver type is specified in the enum
> rc_driver_type as RC_DRIVER_IR_RAW_TX which includes all those
> devices that transmit raw stream of bit to a receiver.
> 
> The data are provided by userspace applications, therefore they
> don't need any input device allocation, but still they need to be
> registered as raw devices.
> 
> Suggested-by: Sean Young <s...@mess.org>
> Signed-off-by: Andi Shyti <andi.sh...@samsung.com>
> ---
>  drivers/media/rc/rc-main.c | 35 +++
>  include/media/rc-core.h|  1 +
>  2 files changed, 24 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index ac91157..f555f38 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -1354,20 +1354,24 @@ struct rc_dev *rc_allocate_device(enum rc_driver_type 
> type)
>   if (!dev)
>   return NULL;
>  
> - dev->input_dev = input_allocate_device();
> - if (!dev->input_dev) {
> - kfree(dev);
> - return NULL;
> - }
> + if (type != RC_DRIVER_IR_RAW_TX) {
> + dev->input_dev = input_allocate_device();
> + if (!dev->input_dev) {
> + kfree(dev);
> + return NULL;
> + }
>  
> - dev->input_dev->getkeycode = ir_getkeycode;
> - dev->input_dev->setkeycode = ir_setkeycode;
> - input_set_drvdata(dev->input_dev, dev);
> + dev->input_dev->getkeycode = ir_getkeycode;
> + dev->input_dev->setkeycode = ir_setkeycode;
> + input_set_drvdata(dev->input_dev, dev);
>  
> - spin_lock_init(>rc_map.lock);
> - spin_lock_init(>keylock);
> + setup_timer(>timer_keyup, ir_timer_keyup,
> + (unsigned long)dev);
> +
> + spin_lock_init(>rc_map.lock);
> + spin_lock_init(>keylock);
> + }
>   mutex_init(>lock);
> - setup_timer(>timer_keyup, ir_timer_keyup, (unsigned long)dev);
>  
>   dev->dev.type = _dev_type;
>   dev->dev.class = _class;
> @@ -1515,7 +1519,14 @@ int rc_register_device(struct rc_dev *dev)
>   dev->input_name ?: "Unspecified device", path ?: "N/A");
>   kfree(path);
>  
> - if (dev->driver_type == RC_DRIVER_IR_RAW) {
> + if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
> + rc = rc_setup_rx_device(dev);
> + if (rc)
> + goto out_dev;
> + }
> +
> + if (dev->driver_type == RC_DRIVER_IR_RAW ||
> + dev->driver_type == RC_DRIVER_IR_RAW_TX) {

Here the if is wrong. It should be 
"if (dev->driver_type != RC_DRIVER_IR_RAW_TX)". Note that as result
the decoder thread is not started, so patch 4 won't be needed either.


>   if (!raw_init) {
>   request_module_nowait("ir-lirc-codec");
>   raw_init = true;
> diff --git a/include/media/rc-core.h b/include/media/rc-core.h
> index c6bf1ef..77b0893 100644
> --- a/include/media/rc-core.h
> +++ b/include/media/rc-core.h
> @@ -32,6 +32,7 @@ do {
> \
>  enum rc_driver_type {
>   RC_DRIVER_SCANCODE = 0, /* Driver or hardware generates a scancode */
>   RC_DRIVER_IR_RAW,   /* Needs a Infra-Red pulse/space decoder */
> + RC_DRIVER_IR_RAW_TX,/* Device is transmitter, driver handles raw */

The comment should really mention the lack of receiver.

--
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: [RFC 1/7] [media] rc-main: assign driver type during allocation

2016-07-19 Thread Sean Young
On Wed, Jul 20, 2016 at 12:56:52AM +0900, Andi Shyti wrote:
> The driver type can be assigned immediately when an RC device
> requests to the framework to allocate the device.
> 
> This is an 'enum rc_driver_type' data type and specifies whether
> the device is a raw receiver or scancode receiver. The type will
> be given as parameter to the rc_allocate_device device.

This patch is good, but it does unfortunately break all the other
rc-core drivers, as now rc_allocate_device() needs argument. All
drivers will need a simple change in this patch.

Also note that there lots of issues that checkpatch.pl would pick
in these series.

> 
> Suggested-by: Sean Young <s...@mess.org>
> Signed-off-by: Andi Shyti <andi.sh...@samsung.com>
> ---
>  drivers/media/rc/rc-main.c | 4 +++-
>  include/media/rc-core.h| 2 +-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 7dfc7c2..6403674 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -1346,7 +1346,7 @@ static struct device_type rc_dev_type = {
>   .uevent = rc_dev_uevent,
>  };
>  
> -struct rc_dev *rc_allocate_device(void)
> +struct rc_dev *rc_allocate_device(enum rc_driver_type type)
>  {
>   struct rc_dev *dev;
>  
> @@ -1373,6 +1373,8 @@ struct rc_dev *rc_allocate_device(void)
>   dev->dev.class = _class;
>   device_initialize(>dev);
>  
> + dev->driver_type = type;
> +
>   __module_get(THIS_MODULE);
>   return dev;
>  }
> diff --git a/include/media/rc-core.h b/include/media/rc-core.h
> index b6586a9..c6bf1ef 100644
> --- a/include/media/rc-core.h
> +++ b/include/media/rc-core.h
> @@ -185,7 +185,7 @@ struct rc_dev {
>   * Remote Controller, at sys/class/rc.
>   */
>  
> -struct rc_dev *rc_allocate_device(void);
> +struct rc_dev *rc_allocate_device(enum rc_driver_type);
>  void rc_free_device(struct rc_dev *dev);
>  int rc_register_device(struct rc_dev *dev);
>  void rc_unregister_device(struct rc_dev *dev);
> -- 
> 2.8.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
--
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 03/20] [media] lirc.h: remove several unused ioctls

2016-07-12 Thread Sean Young
On Tue, Jul 12, 2016 at 02:35:56PM +0100, Sean Young wrote:
> On Tue, Jul 12, 2016 at 10:23:00AM -0300, Mauro Carvalho Chehab wrote:
> > Em Tue, 12 Jul 2016 14:14:06 +0100
> > Sean Young <s...@mess.org> escreveu:
> > > On Tue, Jul 12, 2016 at 09:41:57AM -0300, Mauro Carvalho Chehab wrote:
> -snip-
> > > > -#define LIRC_SET_REC_DUTY_CYCLE_IOW('i', 0x0016, __u32)  
> > > 
> > > Also remove LIRC_CAN_SET_REC_DUTY_CYCLE and 
> > > LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE.
> > 
> > Removing the "LIRC_CAN" macros can break userspace, as some app could
> > be using it to print the LIRC features. That's why I opted to keep
> > them, but to document that those features are unused - this is at
> > the next patch (04/20).
> 
> How is that different from removing the ioctls? Might as well go the whole
> hog.

Ah you meant that if someone later adds a new feature then we might reuse
an existing bit. Oops, sorry.

> Also note that LIRC_CAN_SET_REC_DUTY_CYCLE has the same value as
> LIRC_CAN_MEASURE_CARRIER, so if some userspace program uses this it might
> end up in the mistaken belief its supports LIRC_CAN_SET_REC_DUTY_CYCLE.

So there is an argument for removing LIRC_CAN_SET_REC_DUTY_CYCLE, but
that should be a separate patch.


Sean
--
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 03/20] [media] lirc.h: remove several unused ioctls

2016-07-12 Thread Sean Young
On Tue, Jul 12, 2016 at 10:23:00AM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 12 Jul 2016 14:14:06 +0100
> Sean Young <s...@mess.org> escreveu:
> > On Tue, Jul 12, 2016 at 09:41:57AM -0300, Mauro Carvalho Chehab wrote:
-snip-
> > > -#define LIRC_SET_REC_DUTY_CYCLE_IOW('i', 0x0016, __u32)  
> > 
> > Also remove LIRC_CAN_SET_REC_DUTY_CYCLE and 
> > LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE.
> 
> Removing the "LIRC_CAN" macros can break userspace, as some app could
> be using it to print the LIRC features. That's why I opted to keep
> them, but to document that those features are unused - this is at
> the next patch (04/20).

How is that different from removing the ioctls? Might as well go the whole
hog.

Also note that LIRC_CAN_SET_REC_DUTY_CYCLE has the same value as
LIRC_CAN_MEASURE_CARRIER, so if some userspace program uses this it might
end up in the mistaken belief its supports LIRC_CAN_SET_REC_DUTY_CYCLE.


Sean
--
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 03/20] [media] lirc.h: remove several unused ioctls

2016-07-12 Thread Sean Young
On Tue, Jul 12, 2016 at 09:41:57AM -0300, Mauro Carvalho Chehab wrote:
> While reviewing the documentation gaps on LIRC, it was
> noticed that several ioctls aren't used by any LIRC drivers
> (nor at staging or mainstream).
> 
> It doesn't make sense to document them, as they're not used
> anywhere. So, let's remove those from the lirc header.

Good to see these go.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  include/uapi/linux/lirc.h | 39 ++-
>  1 file changed, 2 insertions(+), 37 deletions(-)
> 
> diff --git a/include/uapi/linux/lirc.h b/include/uapi/linux/lirc.h
> index 4b3ab2966b5a..991ab4570b8e 100644
> --- a/include/uapi/linux/lirc.h
> +++ b/include/uapi/linux/lirc.h
> @@ -90,20 +90,11 @@
>  
>  #define LIRC_GET_SEND_MODE _IOR('i', 0x0001, __u32)
>  #define LIRC_GET_REC_MODE  _IOR('i', 0x0002, __u32)
> -#define LIRC_GET_SEND_CARRIER  _IOR('i', 0x0003, __u32)
> -#define LIRC_GET_REC_CARRIER   _IOR('i', 0x0004, __u32)
> -#define LIRC_GET_SEND_DUTY_CYCLE   _IOR('i', 0x0005, __u32)
> -#define LIRC_GET_REC_DUTY_CYCLE_IOR('i', 0x0006, __u32)
>  #define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, __u32)
>  
>  #define LIRC_GET_MIN_TIMEOUT   _IOR('i', 0x0008, __u32)
>  #define LIRC_GET_MAX_TIMEOUT   _IOR('i', 0x0009, __u32)
>  
> -#define LIRC_GET_MIN_FILTER_PULSE  _IOR('i', 0x000a, __u32)
> -#define LIRC_GET_MAX_FILTER_PULSE  _IOR('i', 0x000b, __u32)
> -#define LIRC_GET_MIN_FILTER_SPACE  _IOR('i', 0x000c, __u32)
> -#define LIRC_GET_MAX_FILTER_SPACE  _IOR('i', 0x000d, __u32)
> -
>  /* code length in bits, currently only for LIRC_MODE_LIRCCODE */
>  #define LIRC_GET_LENGTH_IOR('i', 0x000f, __u32)
>  
> @@ -113,7 +104,6 @@
>  #define LIRC_SET_SEND_CARRIER  _IOW('i', 0x0013, __u32)
>  #define LIRC_SET_REC_CARRIER   _IOW('i', 0x0014, __u32)
>  #define LIRC_SET_SEND_DUTY_CYCLE   _IOW('i', 0x0015, __u32)
> -#define LIRC_SET_REC_DUTY_CYCLE_IOW('i', 0x0016, __u32)

Also remove LIRC_CAN_SET_REC_DUTY_CYCLE and 
LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE.

>  #define LIRC_SET_TRANSMITTER_MASK  _IOW('i', 0x0017, __u32)
>  
>  /*
> @@ -127,42 +117,17 @@
>  #define LIRC_SET_REC_TIMEOUT_REPORTS   _IOW('i', 0x0019, __u32)
>  
>  /*
> - * pulses shorter than this are filtered out by hardware (software
> - * emulation in lirc_dev?)
> - */
> -#define LIRC_SET_REC_FILTER_PULSE  _IOW('i', 0x001a, __u32)
> -/*
> - * spaces shorter than this are filtered out by hardware (software
> - * emulation in lirc_dev?)
> - */
> -#define LIRC_SET_REC_FILTER_SPACE  _IOW('i', 0x001b, __u32)
> -/*
> - * if filter cannot be set independently for pulse/space, this should
> - * be used
> - */
> -#define LIRC_SET_REC_FILTER_IOW('i', 0x001c, __u32)

Also remove LIRC_CAN_SET_REC_FILTER.
> -
> -/*
>   * if enabled from the next key press on the driver will send
>   * LIRC_MODE2_FREQUENCY packets
>   */
>  #define LIRC_SET_MEASURE_CARRIER_MODE_IOW('i', 0x001d, __u32)
>  
>  /*
> - * to set a range use
> - * LIRC_SET_REC_DUTY_CYCLE_RANGE/LIRC_SET_REC_CARRIER_RANGE with the
> - * lower bound first and later
> - * LIRC_SET_REC_DUTY_CYCLE/LIRC_SET_REC_CARRIER with the upper bound
> + * to set a range use LIRC_SET_REC_CARRIER_RANGE with the
> + * lower bound first and later LIRC_SET_REC_CARRIER with the upper bound
>   */
> -
> -#define LIRC_SET_REC_DUTY_CYCLE_RANGE  _IOW('i', 0x001e, __u32)
>  #define LIRC_SET_REC_CARRIER_RANGE _IOW('i', 0x001f, __u32)
>  
> -#define LIRC_NOTIFY_DECODE _IO('i', 0x0020)

Also remove LIRC_CAN_NOTIFY_DECODE.

> -
> -#define LIRC_SETUP_START   _IO('i', 0x0021)
> -#define LIRC_SETUP_END _IO('i', 0x0022)
> -
>  #define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, __u32)
>  
>  #endif

Sean
--
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 08/20] [media] doc-rst: document ioctl LIRC_GET_REC_MODE

2016-07-12 Thread Sean Young
On Tue, Jul 12, 2016 at 09:42:02AM -0300, Mauro Carvalho Chehab wrote:
> Move the documentation of this ioctl from lirc_ioctl to its
> own file, and add a short description about the pulse mode
> used by IR RX.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  Documentation/media/uapi/rc/lirc-get-rec-mode.rst  | 59 
> ++
>  .../media/uapi/rc/lirc_device_interface.rst|  1 +
>  Documentation/media/uapi/rc/lirc_ioctl.rst |  9 
>  3 files changed, 60 insertions(+), 9 deletions(-)
>  create mode 100644 Documentation/media/uapi/rc/lirc-get-rec-mode.rst
> 
> diff --git a/Documentation/media/uapi/rc/lirc-get-rec-mode.rst 
> b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
> new file mode 100644
> index ..d46a488594c9
> --- /dev/null
> +++ b/Documentation/media/uapi/rc/lirc-get-rec-mode.rst
> @@ -0,0 +1,59 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _lirc_get_rec_mode:
> +
> +***
> +ioctl LIRC_GET_REC_MODE
> +***
> +
> +Name
> +
> +
> +LIRC_GET_REC_MODE - Get supported receive modes.
> +
> +Synopsis
> +
> +
> +.. cpp:function:: int ioctl( int fd, int request, __u32 rx_modes)
> +
> +Arguments
> +=
> +
> +``fd``
> +File descriptor returned by open().
> +
> +``request``
> +LIRC_GET_REC_MODE
> +
> +``rx_modes``
> +Bitmask with the supported transmit modes.
> +
> +Description
> +===
> +
> +Get supported receive modes.
> +
> +Supported receive modes
> +===
> +
> +.. _lirc-mode-mode2:
> +
> +``LIRC_MODE_MODE2``
> +
> +The driver returns a sequence of pulse and space codes to userspace.
> +
> +.. _lirc-mode-lirccode:
> +
> +``LIRC_MODE_LIRCCODE``
> +
> +The IR signal is decoded internally by the receiver. The LIRC interface
> +returns the scancode as an integer value. This is the usual mode used
> +by several TV media cards.

Actually rc devices that produce scancodes (rather than raw IR) do have not
have an associated lirc device so no LIRC_MODE_LIRCCODE there. The exception 
to this is the lirc_sasem and lirc_zilog drivers in staging; those two are the 
only drivers that use LIRC_MODE_LIRCCODE at all.

The lirc_sasem driver should be ported to rc-core, but I've never been able
to find the hardware for it. When it is ported it won't need LIRCCODE any
more.

The lirc_zilog driver is just for sending and also should be ported to 
rc-core. The hardware supports sending raw IR, I just do not know how so
I can't port it.


Sean
--
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/5] [media] redrat3: fix timeout handling

2016-07-10 Thread Sean Young
The redrat3 sends an usb packet to the host either when the minimum pause
or the timeout occurs, so we can always add a trailing space in our
processing.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/redrat3.c | 48 +++---
 1 file changed, 11 insertions(+), 37 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 6adea78..1e65f7a 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -188,8 +188,7 @@ struct redrat3_dev {
/* usb dma */
dma_addr_t dma_in;
 
-   /* rx signal timeout timer */
-   struct timer_list rx_timeout;
+   /* rx signal timeout */
u32 hw_timeout;
 
/* Is the device currently transmitting?*/
@@ -330,22 +329,11 @@ static u32 redrat3_us_to_len(u32 microsec)
return result ? result : 1;
 }
 
-/* timer callback to send reset event */
-static void redrat3_rx_timeout(unsigned long data)
-{
-   struct redrat3_dev *rr3 = (struct redrat3_dev *)data;
-
-   dev_dbg(rr3->dev, "calling ir_raw_event_reset\n");
-   ir_raw_event_reset(rr3->rc);
-}
-
 static void redrat3_process_ir_data(struct redrat3_dev *rr3)
 {
DEFINE_IR_RAW_EVENT(rawir);
struct device *dev;
-   unsigned i, trailer = 0;
-   unsigned sig_size, single_len, offset, val;
-   unsigned long delay;
+   unsigned int i, sig_size, single_len, offset, val;
u32 mod_freq;
 
if (!rr3) {
@@ -355,10 +343,6 @@ static void redrat3_process_ir_data(struct redrat3_dev 
*rr3)
 
dev = rr3->dev;
 
-   /* Make sure we reset the IR kfifo after a bit of inactivity */
-   delay = usecs_to_jiffies(rr3->hw_timeout);
-   mod_timer(>rx_timeout, jiffies + delay);
-
mod_freq = redrat3_val_to_mod_freq(>irdata);
dev_dbg(dev, "Got mod_freq of %u\n", mod_freq);
 
@@ -376,9 +360,6 @@ 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 = (rawir.duration > IR_MAX_DURATION) ?
 IR_MAX_DURATION : rawir.duration;
@@ -388,18 +369,13 @@ static void redrat3_process_ir_data(struct redrat3_dev 
*rr3)
ir_raw_event_store_with_filter(rr3->rc, );
}
 
-   /* add a trailing space, if need be */
-   if (i % 2) {
-   rawir.pulse = false;
-   /* this duration is made up, and may not be ideal... */
-   if (trailer < US_TO_NS(1000))
-   rawir.duration = US_TO_NS(2800);
-   else
-   rawir.duration = trailer;
-   dev_dbg(dev, "storing trailing space with duration %d\n",
-   rawir.duration);
-   ir_raw_event_store_with_filter(rr3->rc, );
-   }
+   /* add a trailing space */
+   rawir.pulse = false;
+   rawir.timeout = true;
+   rawir.duration = US_TO_NS(rr3->hw_timeout);
+   dev_dbg(dev, "storing trailing timeout with duration %d\n",
+   rawir.duration);
+   ir_raw_event_store_with_filter(rr3->rc, );
 
dev_dbg(dev, "calling ir_raw_event_handle\n");
ir_raw_event_handle(rr3->rc);
@@ -880,7 +856,7 @@ static struct rc_dev *redrat3_init_rc_dev(struct 
redrat3_dev *rr3)
rc->priv = rr3;
rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
-   rc->timeout = US_TO_NS(2750);
+   rc->timeout = US_TO_NS(rr3->hw_timeout);
rc->tx_ir = redrat3_transmit_ir;
rc->s_tx_carrier = redrat3_set_tx_carrier;
rc->driver_name = DRIVER_NAME;
@@ -990,7 +966,7 @@ static int redrat3_dev_probe(struct usb_interface *intf,
if (retval < 0)
goto error;
 
-   /* store current hardware timeout, in us, will use for kfifo resets */
+   /* store current hardware timeout, in µs */
rr3->hw_timeout = redrat3_get_timeout(rr3);
 
/* default.. will get overridden by any sends with a freq defined */
@@ -1026,7 +1002,6 @@ static int redrat3_dev_probe(struct usb_interface *intf,
retval = -ENOMEM;
goto led_free_error;
}
-   setup_timer(>rx_timeout, redrat3_rx_timeout, (unsigned long)rr3);
 
/* we can register the device now, as it is ready */
usb_set_intfdata(intf, rr3);
@@ -1055,7 +1030,6 @@ static void redrat3_dev_disconnect(struct usb_interface 
*intf)
usb_set_intfdata(intf, NULL);
rc_unregister_device(rr3->rc);
led_classdev_unregister

[PATCH 4/5] [media] redrat3: make hardware timeout configurable

2016-07-10 Thread Sean Young
Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/ir-lirc-codec.c |  5 -
 drivers/media/rc/redrat3.c   | 34 ++
 include/media/rc-core.h  |  3 +++
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 5effc65..c327730 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -292,7 +292,10 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
tmp > dev->max_timeout)
return -EINVAL;
 
-   dev->timeout = tmp;
+   if (dev->s_timeout)
+   ret = dev->s_timeout(dev, tmp);
+   if (!ret)
+   dev->timeout = tmp;
break;
 
case LIRC_SET_REC_TIMEOUT_REPORTS:
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 1e65f7a..399f44d 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -475,6 +475,37 @@ static u32 redrat3_get_timeout(struct redrat3_dev *rr3)
return timeout;
 }
 
+static int redrat3_set_timeout(struct rc_dev *rc_dev, unsigned int timeoutns)
+{
+   struct redrat3_dev *rr3 = rc_dev->priv;
+   struct usb_device *udev = rr3->udev;
+   struct device *dev = rr3->dev;
+   u32 *timeout;
+   int ret;
+
+   timeout = kmalloc(sizeof(*timeout), GFP_KERNEL);
+   if (!timeout)
+   return -ENOMEM;
+
+   *timeout = cpu_to_be32(redrat3_us_to_len(timeoutns / 1000));
+   ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), RR3_SET_IR_PARAM,
+USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+RR3_IR_IO_SIG_TIMEOUT, 0, timeout, sizeof(*timeout),
+HZ * 25);
+   dev_dbg(dev, "set ir parm timeout %d ret 0x%02x\n",
+   be32_to_cpu(*timeout), ret);
+
+   if (ret == sizeof(*timeout)) {
+   rr3->hw_timeout = timeoutns / 1000;
+   ret = 0;
+   } else if (ret >= 0)
+   ret = -EIO;
+
+   kfree(timeout);
+
+   return ret;
+}
+
 static void redrat3_reset(struct redrat3_dev *rr3)
 {
struct usb_device *udev = rr3->udev;
@@ -856,7 +887,10 @@ static struct rc_dev *redrat3_init_rc_dev(struct 
redrat3_dev *rr3)
rc->priv = rr3;
rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
+   rc->min_timeout = MS_TO_NS(RR3_RX_MIN_TIMEOUT);
+   rc->max_timeout = MS_TO_NS(RR3_RX_MAX_TIMEOUT);
rc->timeout = US_TO_NS(rr3->hw_timeout);
+   rc->s_timeout = redrat3_set_timeout;
rc->tx_ir = redrat3_transmit_ir;
rc->s_tx_carrier = redrat3_set_tx_carrier;
rc->driver_name = DRIVER_NAME;
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index 0f77b3d..b69d946 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -119,6 +119,7 @@ enum rc_filter_type {
  * @s_carrier_report: enable carrier reports
  * @s_filter: set the scancode filter
  * @s_wakeup_filter: set the wakeup scancode filter
+ * @s_timeout: set hardware timeout in ns
  */
 struct rc_dev {
struct device   dev;
@@ -174,6 +175,8 @@ struct rc_dev {
struct rc_scancode_filter 
*filter);
int (*s_wakeup_filter)(struct rc_dev *dev,
   struct 
rc_scancode_filter *filter);
+   int (*s_timeout)(struct rc_dev *dev,
+unsigned int timeout);
 };
 
 #define to_rc_dev(d) container_of(d, struct rc_dev, dev)
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 5/5] [media] redrat3: add sysfs attributes for hardware specific options

2016-07-10 Thread Sean Young
Signed-off-by: Sean Young <s...@mess.org>
---
 Documentation/ABI/testing/sysfs-class-rc-redrat3 |  33 
 drivers/media/rc/redrat3.c   | 200 +++
 2 files changed, 233 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-rc-redrat3

diff --git a/Documentation/ABI/testing/sysfs-class-rc-redrat3 
b/Documentation/ABI/testing/sysfs-class-rc-redrat3
new file mode 100644
index 000..33a24fa
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-rc-redrat3
@@ -0,0 +1,33 @@
+What:  /sys/class/rc/rcN/length_fuzz
+Date:  Jul 2016
+KernelVersion: 4.8
+Contact:   Mauro Carvalho Chehab <m.che...@samsung.com>
+Description:
+   The redrat3 encodes an IR signal as set of different lengths
+   and a set of indices into those lengths. Writing this file
+   sets how much two lengths must differ before they are
+   considered distinct, the value is specified in microseconds.
+   Default 5, value 0 to 127.
+
+What:  /sys/class/rc/rcN/min_pause
+Date:  Jul 2016
+KernelVersion: 4.8
+Contact:   Mauro Carvalho Chehab <m.che...@samsung.com>
+Description:
+   When receiving a continuous ir stream (for example when a user
+   is holding a button down on a remote), this specifies the
+   minimum size of a space when the redrat3 sends a irdata packet
+   to the host. Specified in miliseconds. Default value 18ms.
+   The value can be between 2 and 30 inclusive.
+
+What:  /sys/class/rc/rcN/periods_measure_carrier
+Date:  Jul 2016
+KernelVersion: 4.8
+Contact:   Mauro Carvalho Chehab <m.che...@samsung.com>
+Description:
+   The carrier frequency is measured during the first pulse of
+   the IR signal. The larger the number of periods used To
+   measure, the more accurate the result is likely to be, however
+   some signals have short initial pulses, so in some case it
+   may be necessary for applications to reduce this value.
+   Default 8, value 1 to 255.
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 399f44d..8365547 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -860,6 +860,195 @@ static void redrat3_led_complete(struct urb *urb)
atomic_dec(>flash);
 }
 
+static ssize_t min_pause_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t len)
+{
+   struct rc_dev *rc_dev = to_rc_dev(dev);
+   struct redrat3_dev *rr3 = rc_dev->priv;
+   struct usb_device *udev = rr3->udev;
+   long value;
+   u8 *pause;
+   int rc;
+
+   rc = kstrtol(buf, 0, );
+   if (rc)
+   return rc;
+
+   if (value < 2 || value > 30)
+   return -EINVAL;
+
+   pause = kmalloc(sizeof(*pause), GFP_KERNEL);
+   if (!pause)
+   return -ENOMEM;
+
+   *pause = (65536 - (value * 2000)) / 256;
+   rc = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), RR3_SET_IR_PARAM,
+USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+RR3_IR_IO_MIN_PAUSE, 0, pause, sizeof(*pause), HZ * 25);
+   dev_dbg(dev, "set ir parm min pause %d rc 0x%02x\n", *pause, rc);
+   if (rc == sizeof(*pause))
+   rc = len;
+
+   kfree(pause);
+
+   return rc;
+}
+
+static ssize_t min_pause_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct rc_dev *rc_dev = to_rc_dev(dev);
+   struct redrat3_dev *rr3 = rc_dev->priv;
+   struct usb_device *udev = rr3->udev;
+   int rc;
+   u8 *pause;
+
+   pause = kmalloc(sizeof(*pause), GFP_KERNEL);
+   if (!pause)
+   return -ENOMEM;
+
+   rc = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), RR3_GET_IR_PARAM,
+USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
+RR3_IR_IO_MIN_PAUSE, 0, pause, sizeof(*pause), HZ * 25);
+   dev_dbg(dev, "get ir parm len pause %d rc 0x%02x\n", *pause, rc);
+   if (rc == sizeof(*pause))
+   rc = sprintf(buf, "%d\n", (65536 - 256 * *pause) / 2000);
+
+   kfree(pause);
+
+   return rc;
+}
+
+static ssize_t length_fuzz_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t len)
+{
+   struct rc_dev *rc_dev = to_rc_dev(dev);
+   struct redrat3_dev *rr3 = rc_dev->priv;
+   struct usb_device *udev = rr3->udev;
+   long value;
+   u8 *fuzz;
+   int rc;
+
+   rc = kstrtol(buf, 0, );
+   if (rc)
+   return rc;
+
+   if (value < 0 || value > 

[PATCH] [V4L-UTILS] ir-ctl: add new tool for sending & receiving raw IR

2016-07-10 Thread Sean Young
Currently v4l-utils has no tooling provided for receiving and sending
raw IR using the lirc interface. Some of this can be done using various
tools from the user-space lirc package, but not everything is covered.

We want to be able to do the following:
 - List all the features that a lirc device provides
 - Set all possible receiving and sending parameters
 - Send raw IR, formatted as a text file
 - Record raw IR, with output in the same format as for sending
 - Testbed for lirc drivers. Driver misbehaviour is reported

The need for this is not new. The manufacturer of the IguanaWorks IR
device have a similar tool which is IguanaIR specific:

http://www.iguanaworks.net/2012/igclient-examples/

Also RedRat3 provide a similar tools but this uses a signal database
for sending IR, and is redrat specific.

http://www.redrat.co.uk/software/redrat-linux-ir-tools/

Lirc provides a tool for reading raw IR but no method of sending it.

http://www.lirc.org/html/mode2.html

None of these provides full coverage of the basic raw IR lirc interface,
hence v4l-utils seems like logical place to provide this functionality. It
can be used as a tool for testing features of lirc drivers.

Signed-off-by: Sean Young <s...@mess.org>
---
 configure.ac |   2 +
 include/media/lirc.h | 168 +++
 utils/Makefile.am|   1 +
 utils/ir-ctl/.gitignore  |   2 +
 utils/ir-ctl/Makefile.am |   6 +
 utils/ir-ctl/ir-ctl.1.in | 192 
 utils/ir-ctl/ir-ctl.c| 759 +++
 v4l-utils.spec.in|   6 +-
 8 files changed, 1134 insertions(+), 2 deletions(-)
 create mode 100644 include/media/lirc.h
 create mode 100644 utils/ir-ctl/.gitignore
 create mode 100644 utils/ir-ctl/Makefile.am
 create mode 100644 utils/ir-ctl/ir-ctl.1.in
 create mode 100644 utils/ir-ctl/ir-ctl.c

diff --git a/configure.ac b/configure.ac
index 2616f92..41ab97b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -24,6 +24,7 @@ AC_CONFIG_FILES([Makefile
utils/decode_tm6000/Makefile
utils/dvb/Makefile
utils/keytable/Makefile
+   utils/ir-ctl/Makefile
utils/cx18-ctl/Makefile
utils/ivtv-ctl/Makefile
utils/media-ctl/Makefile
@@ -59,6 +60,7 @@ AC_CONFIG_FILES([Makefile
utils/v4l2-compliance/v4l2-compliance.1
utils/v4l2-ctl/v4l2-ctl.1
utils/keytable/ir-keytable.1
+   utils/ir-ctl/ir-ctl.1
utils/dvb/dvb-fe-tool.1
utils/dvb/dvbv5-scan.1
utils/dvb/dvb-format-convert.1
diff --git a/include/media/lirc.h b/include/media/lirc.h
new file mode 100644
index 000..4b3ab29
--- /dev/null
+++ b/include/media/lirc.h
@@ -0,0 +1,168 @@
+/*
+ * lirc.h - linux infrared remote control header file
+ * last modified 2010/07/13 by Jarod Wilson
+ */
+
+#ifndef _LINUX_LIRC_H
+#define _LINUX_LIRC_H
+
+#include 
+#include 
+
+#define PULSE_BIT   0x0100
+#define PULSE_MASK  0x00FF
+
+#define LIRC_MODE2_SPACE 0x
+#define LIRC_MODE2_PULSE 0x0100
+#define LIRC_MODE2_FREQUENCY 0x0200
+#define LIRC_MODE2_TIMEOUT   0x0300
+
+#define LIRC_VALUE_MASK  0x00FF
+#define LIRC_MODE2_MASK  0xFF00
+
+#define LIRC_SPACE(val) (((val)_VALUE_MASK) | LIRC_MODE2_SPACE)
+#define LIRC_PULSE(val) (((val)_VALUE_MASK) | LIRC_MODE2_PULSE)
+#define LIRC_FREQUENCY(val) (((val)_VALUE_MASK) | LIRC_MODE2_FREQUENCY)
+#define LIRC_TIMEOUT(val) (((val)_VALUE_MASK) | LIRC_MODE2_TIMEOUT)
+
+#define LIRC_VALUE(val) ((val)_VALUE_MASK)
+#define LIRC_MODE2(val) ((val)_MODE2_MASK)
+
+#define LIRC_IS_SPACE(val) (LIRC_MODE2(val) == LIRC_MODE2_SPACE)
+#define LIRC_IS_PULSE(val) (LIRC_MODE2(val) == LIRC_MODE2_PULSE)
+#define LIRC_IS_FREQUENCY(val) (LIRC_MODE2(val) == LIRC_MODE2_FREQUENCY)
+#define LIRC_IS_TIMEOUT(val) (LIRC_MODE2(val) == LIRC_MODE2_TIMEOUT)
+
+/* used heavily by lirc userspace */
+#define lirc_t int
+
+/*** lirc compatible hardware features ***/
+
+#define LIRC_MODE2SEND(x) (x)
+#define LIRC_SEND2MODE(x) (x)
+#define LIRC_MODE2REC(x) ((x) << 16)
+#define LIRC_REC2MODE(x) ((x) >> 16)
+
+#define LIRC_MODE_RAW  0x0001
+#define LIRC_MODE_PULSE0x0002
+#define LIRC_MODE_MODE20x0004
+#define LIRC_MODE_LIRCCODE 0x0010
+
+
+#define LIRC_CAN_SEND_RAW  LIRC_MODE2SEND(LIRC_MODE_RAW)
+#define LIRC_CAN_SEND_PULSELIRC_MODE2SEND(LIRC_MODE_PULSE)
+#define LIRC_CAN_SEND_MODE2LIRC_MODE2SEND(LIRC_MODE_MODE2)
+#define LIRC_CAN_SEND_LIRCCODE LIRC_MODE2SEND(LIRC_MODE_LIRCCODE)
+
+#define LIRC_CAN_SEND_MASK 0x003f
+
+#define LIRC_CAN_SET_SEND_CARRIER  0x0100
+#define LIRC_CAN_SET_SEND_DUTY_CYCLE   0x0200
+#define LIRC_CAN_SET_TRANSMITTER_MASK  0x0400
+
+#define LIRC_CAN_REC_RAW   LIRC_MODE2REC(LIRC_MODE_RAW)
+#define LIRC_CAN_REC_PULSE LIRC_MODE2REC(LIRC_MODE_PULSE)
+#define LIRC_CAN_REC_MODE2

[PATCH 2/5] [media] rc: make s_tx_carrier consistent

2016-07-10 Thread Sean Young
LIRC_SET_SEND_CARRIER should return 0 on success or -errno.

Signed-off-by: Sean Young <s...@mess.org>
---
 Documentation/DocBook/media/v4l/lirc_device_interface.xml | 2 +-
 drivers/media/rc/ene_ir.c | 2 +-
 drivers/media/rc/iguanair.c   | 2 +-
 drivers/media/rc/mceusb.c | 2 +-
 drivers/media/rc/redrat3.c| 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/lirc_device_interface.xml 
b/Documentation/DocBook/media/v4l/lirc_device_interface.xml
index 34cada2..71f9dbb 100644
--- a/Documentation/DocBook/media/v4l/lirc_device_interface.xml
+++ b/Documentation/DocBook/media/v4l/lirc_device_interface.xml
@@ -157,7 +157,7 @@ on working with the default settings initially.
   
 LIRC_SET_{SEND,REC}_CARRIER
 
-  Set send/receive carrier (in Hz).
+  Set send/receive carrier (in Hz). Return 0 on success.
 
   
   
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index 8d77e1c..d1c61cd 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -904,7 +904,7 @@ static int ene_set_tx_carrier(struct rc_dev *rdev, u32 
carrier)
 
dbg("TX: out of range %d-%d kHz carrier",
2000 / ENE_CIRMOD_PRD_MIN, 2000 / ENE_CIRMOD_PRD_MAX);
-   return -1;
+   return -EINVAL;
}
 
dev->tx_period = period;
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index ee60e17..5f63454 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -330,7 +330,7 @@ static int iguanair_set_tx_carrier(struct rc_dev *dev, 
uint32_t carrier)
 
mutex_unlock(>lock);
 
-   return carrier;
+   return 0;
 }
 
 static int iguanair_set_tx_mask(struct rc_dev *dev, uint32_t mask)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 0d1da2c..c6d3325 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -936,7 +936,7 @@ static int mceusb_set_tx_carrier(struct rc_dev *dev, u32 
carrier)
 
}
 
-   return carrier;
+   return 0;
 }
 
 /*
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index ec74244..6adea78 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -708,7 +708,7 @@ static int redrat3_set_tx_carrier(struct rc_dev *rcdev, u32 
carrier)
 
rr3->carrier = carrier;
 
-   return carrier;
+   return 0;
 }
 
 static int redrat3_transmit_ir(struct rc_dev *rcdev, unsigned *txbuf,
-- 
2.7.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 1/5] [media] rc: make s_tx_mask consistent

2016-07-10 Thread Sean Young
When s_tx_mask is given an invalid bitmask, the number of transmitters
should be returned. See the LIRC_SET_TRANSMITTER_MASK lirc ioctl
documentation.

Signed-off-by: Sean Young <s...@mess.org>
---
 drivers/media/rc/mceusb.c  | 6 ++
 drivers/media/rc/winbond-cir.c | 4 
 2 files changed, 10 insertions(+)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 35155ae..0d1da2c 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -881,6 +881,12 @@ static int mceusb_set_tx_mask(struct rc_dev *dev, u32 mask)
 {
struct mceusb_dev *ir = dev->priv;
 
+   /* return number of transmitters */
+   int emitters = ir->num_txports ? ir->num_txports : 2;
+
+   if (mask >= (1 << emitters))
+   return emitters;
+
if (ir->flags.tx_mask_normal)
ir->tx_mask = mask;
else
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index d839f73..95ae60e 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -615,6 +615,10 @@ wbcir_txmask(struct rc_dev *dev, u32 mask)
unsigned long flags;
u8 val;
 
+   /* return the number of transmitters */
+   if (mask > 15)
+   return 4;
+
/* Four outputs, only one output can be enabled at a time */
switch (mask) {
case 0x1:
-- 
2.7.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


Re: [PATCH] media: rc: nuvoton: decrease size of raw event fifo

2016-07-06 Thread Sean Young
On Tue, Jul 05, 2016 at 07:48:34PM +0200, Heiner Kallweit wrote:
> Am 05.07.2016 um 11:17 schrieb Sean Young:
> > On Tue, Jul 05, 2016 at 08:05:16AM +0200, Heiner Kallweit wrote:
> >> Am 04.07.2016 um 23:06 schrieb Sean Young:
> >>> On Mon, Jul 04, 2016 at 10:51:50PM +0200, Heiner Kallweit wrote:
> >>>> Am 04.07.2016 um 22:13 schrieb Sean Young:
> >>>>> On Wed, May 18, 2016 at 10:29:41PM +0200, Heiner Kallweit wrote:
> >>>>>> This chip has a 32 byte HW FIFO only. Therefore the default fifo size
> >>>>>> of 512 raw events is not needed and can be significantly decreased.
> >>>>>>
> >>>>>> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com>
> >>>>>
> >>>>> The 32 byte hardware queue is read from an interrupt handler and added
> >>>>> to the kfifo. The kfifo is read by the decoders in a seperate kthread
> >>>>> (in ir_raw_event_thread). If we have a long IR (e.g. nec which has 
> >>>>> 66 edges) and the kthread is not scheduled in time (e.g. high load), 
> >>>>> will
> >>>>> we not end up with an overflow in the kfifo and unable to decode it?
> >>>>>
> >>>> The interrupt handler is triggered latest when 24 bytes have been read.
> >>>> (at least that's how the chip gets configured at the moment)
> >>>> This gives the decoder thread at least 8 bytes time to process the
> >>>> kfifo. This should be sufficient even under high load.
> >>>
> >>> No, it gives the interrupt handler at least 8 bytes time to read the
> >>> hardware fifo (and add it to the kfifo). There are no guarantees about
> >>> when the decoder kthread runs (which reads the kfifo).
> >>>
> >>> To put it another way, in the nuvoton interrupt handler, you call 
> >>> ir_raw_event_handle() which does a wake_up_process(). That puts the
> >>> decoder process (it has a pid) in a runnable state and it will run at
> >>> some future time.
> >>>
> >> You're right, that's the more precise description.
> >> These 8 bytes time give the decoder process few msec's to start.
> >> (Not sure wheter there's any protocol resulting in much shorter time.)
> >> At least during my tests this was always sufficient.
> > 
> > So worst case scenario with NEC IR (I have not checked all ir protocols).
> > 1. 32 bytes of IR read from hardware fifo.
> > 2. IR in the middle of series of 1s (two edges, 1.125ms each)
> > 3. After 13.5ms interrupt is triggered again as 12 new bits generated 24 
> > edges
> > 4. Decoder thread has not run and emptied the fifo.
> > 5. kfifo overflow and IR cannot be decoded; key lost
> > 
> At least in the nuvoton driver the decoder thread is started whenever
> something was read from the hw fifo and written to kfifo.
> -> call to ir_raw_event_handle() at the end of nvt_process_rx_ir_data
> It doesn't wait for the end of an IR packet.
> Means in your example the decoder thread would be started after step 1
> and whenever the hw fifo reaches the threshold to generate an irq.

No the IR decoder thread is put in a runnable state in the interrupt handler 
(i.e. in step 1).  It doesn't mean it will run in time (so within 13.5ms)
necessarily. That depends on the scheduler.

Now finding some hard numbers for scheduling latency (under high load
of course) is proving to be difficult. Does anyone know what sort of spikes
we should cater for?


Sean
--
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 PULL FOR v4.8] Various dvb/rc fixes/improvements

2016-07-05 Thread Sean Young
On Tue, Jul 05, 2016 at 12:25:17AM +0200, Hans Verkuil wrote:
> On 07/04/2016 10:19 PM, Sean Young wrote:
> > On Mon, Jul 04, 2016 at 01:54:56PM +0200, Hans Verkuil wrote:
> >> Mauro,
> >>
> >> As requested, I'm helping out with reducing the backlog.
> >>
> >> Regards,
> >>
> >>Hans
> >>
> >> The following changes since commit 
> >> ab46f6d24bf57ddac0f5abe2f546a78af57b476c:
> >>
> >>   [media] videodev2.h: Fix V4L2_PIX_FMT_YUV411P description (2016-06-28 
> >> 11:54:52 -0300)
> >>
> >> are available in the git repository at:
> >>
> >>   git://linuxtv.org/hverkuil/media_tree.git for-v4.8f
> >>
> >> for you to fetch changes up to 920be8ec8843d42ef3181f9a9fb988c49481b165:
> >>
> >>   media: rc: nuvoton: remove two unused elements in struct nvt_dev 
> >> (2016-07-04 13:26:37 +0200)
> >>
> >> 
> >> Antti Palosaari (14):
> >>   si2168: add support for newer firmwares
> >>   si2168: do not allow driver unbind
> >>   si2157: do not allow driver unbind
> >>   m88ds3103: remove useless most significant bit clear
> >>   m88ds3103: calculate DiSEqC message sending time
> >>   m88ds3103: improve ts clock setting
> >>   m88ds3103: use Hz instead of kHz on calculations
> >>   m88ds3103: refactor firmware download
> >>   af9033: move statistics to read_status()
> >>   af9033: do not allow driver unbind
> >>   it913x: do not allow driver unbind
> >>   rtl2830: do not allow driver unbind
> >>   rtl2830: move statistics to read_status()
> >>   rtl2832: do not allow driver unbind
> >>
> >> Heiner Kallweit (12):
> >>   media: rc: make fifo size for raw events configurable via rc_dev
> 
> I kept this one,
> 
> >>   media: rc: nuvoton: decrease size of raw event fifo
> 
> but dropped this one from the pull request until this is resolved.

Both should be dropped as the idea itself is broken.


Sean
--
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: nuvoton: decrease size of raw event fifo

2016-07-05 Thread Sean Young
On Tue, Jul 05, 2016 at 08:05:16AM +0200, Heiner Kallweit wrote:
> Am 04.07.2016 um 23:06 schrieb Sean Young:
> > On Mon, Jul 04, 2016 at 10:51:50PM +0200, Heiner Kallweit wrote:
> >> Am 04.07.2016 um 22:13 schrieb Sean Young:
> >>> On Wed, May 18, 2016 at 10:29:41PM +0200, Heiner Kallweit wrote:
> >>>> This chip has a 32 byte HW FIFO only. Therefore the default fifo size
> >>>> of 512 raw events is not needed and can be significantly decreased.
> >>>>
> >>>> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com>
> >>>
> >>> The 32 byte hardware queue is read from an interrupt handler and added
> >>> to the kfifo. The kfifo is read by the decoders in a seperate kthread
> >>> (in ir_raw_event_thread). If we have a long IR (e.g. nec which has 
> >>> 66 edges) and the kthread is not scheduled in time (e.g. high load), will
> >>> we not end up with an overflow in the kfifo and unable to decode it?
> >>>
> >> The interrupt handler is triggered latest when 24 bytes have been read.
> >> (at least that's how the chip gets configured at the moment)
> >> This gives the decoder thread at least 8 bytes time to process the
> >> kfifo. This should be sufficient even under high load.
> > 
> > No, it gives the interrupt handler at least 8 bytes time to read the
> > hardware fifo (and add it to the kfifo). There are no guarantees about
> > when the decoder kthread runs (which reads the kfifo).
> > 
> > To put it another way, in the nuvoton interrupt handler, you call 
> > ir_raw_event_handle() which does a wake_up_process(). That puts the
> > decoder process (it has a pid) in a runnable state and it will run at
> > some future time.
> > 
> You're right, that's the more precise description.
> These 8 bytes time give the decoder process few msec's to start.
> (Not sure wheter there's any protocol resulting in much shorter time.)
> At least during my tests this was always sufficient.

So worst case scenario with NEC IR (I have not checked all ir protocols).
1. 32 bytes of IR read from hardware fifo.
2. IR in the middle of series of 1s (two edges, 1.125ms each)
3. After 13.5ms interrupt is triggered again as 12 new bits generated 24 edges
4. Decoder thread has not run and emptied the fifo.
5. kfifo overflow and IR cannot be decoded; key lost

> However if you think 32 bytes might be too small as kfifo size I'd
> also be fine with increasing it. The result should still be better
> than the default size of 512.

So this depends on how many edges an remote could possible generate and
how often the kthread will be scheduled to read it. For example I have
a remote which repeats the entire nec code after 20ms if you hold a
button down. That's about 800 edges per second, so with a kfifo of 512
the kthread would have to be scheduled twice a second.

I think we should stick to the default of 512.


Sean
--
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: nuvoton: decrease size of raw event fifo

2016-07-04 Thread Sean Young
On Mon, Jul 04, 2016 at 10:51:50PM +0200, Heiner Kallweit wrote:
> Am 04.07.2016 um 22:13 schrieb Sean Young:
> > On Wed, May 18, 2016 at 10:29:41PM +0200, Heiner Kallweit wrote:
> >> This chip has a 32 byte HW FIFO only. Therefore the default fifo size
> >> of 512 raw events is not needed and can be significantly decreased.
> >>
> >> Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com>
> > 
> > The 32 byte hardware queue is read from an interrupt handler and added
> > to the kfifo. The kfifo is read by the decoders in a seperate kthread
> > (in ir_raw_event_thread). If we have a long IR (e.g. nec which has 
> > 66 edges) and the kthread is not scheduled in time (e.g. high load), will
> > we not end up with an overflow in the kfifo and unable to decode it?
> > 
> The interrupt handler is triggered latest when 24 bytes have been read.
> (at least that's how the chip gets configured at the moment)
> This gives the decoder thread at least 8 bytes time to process the
> kfifo. This should be sufficient even under high load.

No, it gives the interrupt handler at least 8 bytes time to read the
hardware fifo (and add it to the kfifo). There are no guarantees about
when the decoder kthread runs (which reads the kfifo).

To put it another way, in the nuvoton interrupt handler, you call 
ir_raw_event_handle() which does a wake_up_process(). That puts the
decoder process (it has a pid) in a runnable state and it will run at
some future time.


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


<    4   5   6   7   8   9   10   11   >