date:20100908

Hi Mauro,

I guess I better get off my behind and commit the changes to support large
scancodes, or they will not make to 2.6.37 either... There isn't much
changes, except I followed David's suggestion and changed boolean index
field into u8 flags field. Still, please glance it over once again and
shout if you see something you do not like.

Jiri, how do you want to handle the changes to HID? I could either push
them through my tree together with the first patch or you can push through
yours once the first change hits mainline.

Mauro, the same question goes for media/IR patch.

David, I suppose you still have the winbond remote so you could test
changes to winbond-cir driver.

Ville, do you still have the hardware to try our ati_remote2 changes?

Thanks!

-- 
Dmitry
--
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/6] Input: sparse-keymap - switch to using new keycode interface

Switch sparse keymap library to use new style of getkeycode and
setkeycode methods to allow retrieving and setting keycodes not
only by their scancodes but also by index.

Signed-off-by: Dmitry Torokhov d...@mail.ru
---

 drivers/input/sparse-keymap.c |   81 +
 1 files changed, 65 insertions(+), 16 deletions(-)

diff --git a/drivers/input/sparse-keymap.c b/drivers/input/sparse-keymap.c
index 0142483..a29a7812 100644
--- a/drivers/input/sparse-keymap.c
+++ b/drivers/input/sparse-keymap.c
@@ -22,6 +22,37 @@ MODULE_DESCRIPTION(Generic support for sparse keymaps);
 MODULE_LICENSE(GPL v2);
 MODULE_VERSION(0.1);
 
+static unsigned int sparse_keymap_get_key_index(struct input_dev *dev,
+   const struct key_entry *k)
+{
+   struct key_entry *key;
+   unsigned int idx = 0;
+
+   for (key = dev-keycode; key-type != KE_END; key++) {
+   if (key-type == KE_KEY) {
+   if (key == k)
+   break;
+   idx++;
+   }
+   }
+
+   return idx;
+}
+
+static struct key_entry *sparse_keymap_entry_by_index(struct input_dev *dev,
+ unsigned int index)
+{
+   struct key_entry *key;
+   unsigned int key_cnt = 0;
+
+   for (key = dev-keycode; key-type != KE_END; key++)
+   if (key-type == KE_KEY)
+   if (key_cnt++ == index)
+   return key;
+
+   return NULL;
+}
+
 /**
  * sparse_keymap_entry_from_scancode - perform sparse keymap lookup
  * @dev: Input device using sparse keymap
@@ -64,16 +95,36 @@ struct key_entry *sparse_keymap_entry_from_keycode(struct 
input_dev *dev,
 }
 EXPORT_SYMBOL(sparse_keymap_entry_from_keycode);
 
+static struct key_entry *sparse_keymap_locate(struct input_dev *dev,
+   const struct input_keymap_entry *ke)
+{
+   struct key_entry *key;
+   unsigned int scancode;
+
+   if (ke-flags  INPUT_KEYMAP_BY_INDEX)
+   key = sparse_keymap_entry_by_index(dev, ke-index);
+   else if (input_scancode_to_scalar(ke, scancode) == 0)
+   key = sparse_keymap_entry_from_scancode(dev, scancode);
+   else
+   key = NULL;
+
+   return key;
+}
+
 static int sparse_keymap_getkeycode(struct input_dev *dev,
-   unsigned int scancode,
-   unsigned int *keycode)
+   struct input_keymap_entry *ke)
 {
const struct key_entry *key;
 
if (dev-keycode) {
-   key = sparse_keymap_entry_from_scancode(dev, scancode);
+   key = sparse_keymap_locate(dev, ke);
if (key  key-type == KE_KEY) {
-   *keycode = key-keycode;
+   ke-keycode = key-keycode;
+   if (!(ke-flags  INPUT_KEYMAP_BY_INDEX))
+   ke-index =
+   sparse_keymap_get_key_index(dev, key);
+   ke-len = sizeof(key-code);
+   memcpy(ke-scancode, key-code, sizeof(key-code));
return 0;
}
}
@@ -82,20 +133,19 @@ static int sparse_keymap_getkeycode(struct input_dev *dev,
 }
 
 static int sparse_keymap_setkeycode(struct input_dev *dev,
-   unsigned int scancode,
-   unsigned int keycode)
+   const struct input_keymap_entry *ke,
+   unsigned int *old_keycode)
 {
struct key_entry *key;
-   int old_keycode;
 
if (dev-keycode) {
-   key = sparse_keymap_entry_from_scancode(dev, scancode);
+   key = sparse_keymap_locate(dev, ke);
if (key  key-type == KE_KEY) {
-   old_keycode = key-keycode;
-   key-keycode = keycode;
-   set_bit(keycode, dev-keybit);
-   if (!sparse_keymap_entry_from_keycode(dev, old_keycode))
-   clear_bit(old_keycode, dev-keybit);
+   *old_keycode = key-keycode;
+   key-keycode = ke-keycode;
+   set_bit(ke-keycode, dev-keybit);
+   if (!sparse_keymap_entry_from_keycode(dev, 
*old_keycode))
+   clear_bit(*old_keycode, dev-keybit);
return 0;
}
}
@@ -159,15 +209,14 @@ int sparse_keymap_setup(struct input_dev *dev,
 
dev-keycode = map;
dev-keycodemax = map_size;
-   dev-getkeycode = sparse_keymap_getkeycode;
-   dev-setkeycode = sparse_keymap_setkeycode;
+   dev-getkeycode_new = sparse_keymap_getkeycode;
+   dev-setkeycode_new =

[PATCH 1/6] Input: add support for large scancodes

From: Mauro Carvalho Chehab mche...@redhat.com

Several devices use a high number of bits for scancodes. One important
group is the Remote Controllers. Some new protocols like RC-6 define a
scancode space of 64 bits.

The current EVIO[CS]GKEYCODE ioctls allow replace the scancode/keycode
translation tables, but it is limited to up to 32 bits for scancode.

Also, if userspace wants to clean the existing table, replacing it by
a new one, it needs to run a loop calling the ioctls over the entire
sparse scancode space.

To solve those problems, this patch extends the ioctls to allow drivers
handle scancodes up to 32 bytes long (the length could be extended in
the future should such need arise) and allow userspace to query and set
scancode to keycode mappings not only by scancode but also by index.

Compatibility code were also added to handle the old format of
EVIO[CS]GKEYCODE ioctls.

Folded fixes by:
- Dan Carpenter: locking fixes for the original implementation
- Jarod Wilson: fix crash when setting keycode and wiring up get/set
handlers in original implementation.
- Dmitry Torokhov: rework to consolidate old and new scancode handling,
   provide options to act either by index or scancode.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Dan Carpenter erro...@gmail.com
Signed-off-by: Jarod Wilson ja...@redhat.com
Signed-off-by: Dmitry Torokhov d...@mail.ru
---

 drivers/char/keyboard.c |   31 ++--
 drivers/input/evdev.c   |  100 
 drivers/input/input.c   |  192 +++
 include/linux/input.h   |   55 +++--
 4 files changed, 292 insertions(+), 86 deletions(-)

diff --git a/drivers/char/keyboard.c b/drivers/char/keyboard.c
index a7ca752..e95d787 100644
--- a/drivers/char/keyboard.c
+++ b/drivers/char/keyboard.c
@@ -175,8 +175,7 @@ EXPORT_SYMBOL_GPL(unregister_keyboard_notifier);
  */
 
 struct getset_keycode_data {
-   unsigned int scancode;
-   unsigned int keycode;
+   struct input_keymap_entry ke;
int error;
 };
 
@@ -184,32 +183,50 @@ static int getkeycode_helper(struct input_handle *handle, 
void *data)
 {
struct getset_keycode_data *d = data;
 
-   d-error = input_get_keycode(handle-dev, d-scancode, d-keycode);
+   d-error = input_get_keycode(handle-dev, d-ke);
 
return d-error == 0; /* stop as soon as we successfully get one */
 }
 
 int getkeycode(unsigned int scancode)
 {
-   struct getset_keycode_data d = { scancode, 0, -ENODEV };
+   struct getset_keycode_data d = {
+   .ke = {
+   .flags  = 0,
+   .len= sizeof(scancode),
+   .keycode= 0,
+   },
+   .error  = -ENODEV,
+   };
+
+   memcpy(d.ke.scancode, scancode, sizeof(scancode));
 
input_handler_for_each_handle(kbd_handler, d, getkeycode_helper);
 
-   return d.error ?: d.keycode;
+   return d.error ?: d.ke.keycode;
 }
 
 static int setkeycode_helper(struct input_handle *handle, void *data)
 {
struct getset_keycode_data *d = data;
 
-   d-error = input_set_keycode(handle-dev, d-scancode, d-keycode);
+   d-error = input_set_keycode(handle-dev, d-ke);
 
return d-error == 0; /* stop as soon as we successfully set one */
 }
 
 int setkeycode(unsigned int scancode, unsigned int keycode)
 {
-   struct getset_keycode_data d = { scancode, keycode, -ENODEV };
+   struct getset_keycode_data d = {
+   .ke = {
+   .flags  = 0,
+   .len= sizeof(scancode),
+   .keycode= keycode,
+   },
+   .error  = -ENODEV,
+   };
+
+   memcpy(d.ke.scancode, scancode, sizeof(scancode));
 
input_handler_for_each_handle(kbd_handler, d, setkeycode_helper);
 
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index c908c5f..1ce9bf6 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -534,6 +534,80 @@ static int handle_eviocgbit(struct input_dev *dev,
 }
 #undef OLD_KEY_MAX
 
+static int evdev_handle_get_keycode(struct input_dev *dev,
+   void __user *p, size_t size)
+{
+   struct input_keymap_entry ke;
+   int error;
+
+   memset(ke, 0, sizeof(ke));
+
+   if (size == sizeof(unsigned int[2])) {
+   /* legacy case */
+   int __user *ip = (int __user *)p;
+
+   if (copy_from_user(ke.scancode, p, sizeof(unsigned int)))
+   return -EFAULT;
+
+   ke.len = sizeof(unsigned int);
+   ke.flags = 0;
+
+   error = input_get_keycode(dev, ke);
+   if (error)
+   return error;
+
+   if (put_user(ke.keycode, ip + 1))
+   return -EFAULT;
+
+   } else {
+

[PATCH 4/6] Input: winbond-cir - switch to using new keycode interface

Switch the code to use new style of getkeycode and setkeycode
methods to allow retrieving and setting keycodes not only by
their scancodes but also by index.

Signed-off-by: Dmitry Torokhov d...@mail.ru
---

 drivers/input/misc/winbond-cir.c |  248 +-
 1 files changed, 163 insertions(+), 85 deletions(-)

diff --git a/drivers/input/misc/winbond-cir.c b/drivers/input/misc/winbond-cir.c
index 64f1de7..6a69067 100644
--- a/drivers/input/misc/winbond-cir.c
+++ b/drivers/input/misc/winbond-cir.c
@@ -172,7 +172,6 @@ enum wbcir_protocol {
 #define WBCIR_MAX_IDLE_BYTES   10
 
 static DEFINE_SPINLOCK(wbcir_lock);
-static DEFINE_RWLOCK(keytable_lock);
 
 struct wbcir_key {
u32 scancode;
@@ -184,7 +183,7 @@ struct wbcir_keyentry {
struct list_head list;
 };
 
-static struct wbcir_key rc6_def_keymap[] = {
+static const struct wbcir_key rc6_def_keymap[] = {
{ 0x800F0400, KEY_NUMERIC_0 },
{ 0x800F0401, KEY_NUMERIC_1 },
{ 0x800F0402, KEY_NUMERIC_2 },
@@ -365,88 +364,152 @@ wbcir_to_rc6cells(u8 val)
  *
  */
 
-static unsigned int
-wbcir_do_getkeycode(struct wbcir_data *data, u32 scancode)
+static struct wbcir_keyentry *
+wbcir_keyentry_by_scancode(struct wbcir_data *data, u32 scancode)
 {
struct wbcir_keyentry *keyentry;
-   unsigned int keycode = KEY_RESERVED;
-   unsigned long flags;
 
-   read_lock_irqsave(keytable_lock, flags);
+   list_for_each_entry(keyentry, data-keytable, list)
+   if (keyentry-key.scancode == scancode)
+   return keyentry;
+
+   return NULL;
+}
+
+static struct wbcir_keyentry *
+wbcir_keyentry_by_index(struct wbcir_data *data, unsigned int index)
+{
+   struct wbcir_keyentry *keyentry;
+   unsigned int cur_idx = 0;
+
+   list_for_each_entry(keyentry, data-keytable, list)
+   if (cur_idx++ == index)
+   return keyentry;
+
+   return NULL;
+}
+
+static struct wbcir_keyentry *
+wbcir_lookup_keyentry(struct wbcir_data *data,
+ const struct input_keymap_entry *ke)
+{
+   struct wbcir_keyentry *keyentry;
+   unsigned int scancode;
+
+   if (ke-flags  INPUT_KEYMAP_BY_INDEX)
+   keyentry = wbcir_keyentry_by_index(data, ke-index);
+   else if (input_scancode_to_scalar(ke, scancode) == 0)
+   keyentry = wbcir_keyentry_by_scancode(data, scancode);
+   else
+   keyentry = NULL;
+
+   return keyentry;
+
+}
+
+static unsigned int
+wbcir_keyentry_get_index(struct wbcir_data *data,
+const struct wbcir_keyentry *keyentry)
+{
+   struct wbcir_keyentry *k;
+   int idx = 0;
 
-   list_for_each_entry(keyentry, data-keytable, list) {
-   if (keyentry-key.scancode == scancode) {
-   keycode = keyentry-key.keycode;
+   list_for_each_entry(k, data-keytable, list) {
+   if (k == keyentry)
break;
-   }
+   idx++;
}
 
-   read_unlock_irqrestore(keytable_lock, flags);
-   return keycode;
+   return idx;
 }
 
 static int
-wbcir_getkeycode(struct input_dev *dev,
-unsigned int scancode, unsigned int *keycode)
+wbcir_getkeycode(struct input_dev *dev, struct input_keymap_entry *ke)
 {
struct wbcir_data *data = input_get_drvdata(dev);
+   const struct wbcir_keyentry *keyentry;
+
+   keyentry = wbcir_lookup_keyentry(data, ke);
+   if (keyentry) {
+   ke-keycode = keyentry-key.keycode;
+   if (!(ke-flags  INPUT_KEYMAP_BY_INDEX))
+   ke-index = wbcir_keyentry_get_index(data, keyentry);
+   ke-len = sizeof(keyentry-key.scancode);
+   memcpy(ke-scancode, keyentry-key.scancode,
+   sizeof(keyentry-key.scancode));
+
+   return 0;
+   }
 
-   *keycode = wbcir_do_getkeycode(data, scancode);
-   return 0;
+   return -EINVAL;
 }
 
 static int
 wbcir_setkeycode(struct input_dev *dev,
-unsigned int scancode, unsigned int keycode)
+const struct input_keymap_entry *ke,
+unsigned int *old_keycode)
 {
struct wbcir_data *data = input_get_drvdata(dev);
struct wbcir_keyentry *keyentry;
-   struct wbcir_keyentry *new_keyentry;
-   unsigned long flags;
-   unsigned int old_keycode = KEY_RESERVED;
-
-   new_keyentry = kmalloc(sizeof(*new_keyentry), GFP_KERNEL);
-   if (!new_keyentry)
-   return -ENOMEM;
+   unsigned int scancode;
 
-   write_lock_irqsave(keytable_lock, flags);
+   *old_keycode = KEY_RESERVED;
 
-   list_for_each_entry(keyentry, data-keytable, list) {
-   if (keyentry-key.scancode != scancode)
-   continue;
+   if

[PATCH 5/6] Input: ati-remote2 - switch to using new keycode interface

Switch the code to use new style of getkeycode and setkeycode
methods to allow retrieving and setting keycodes not only by
their scancodes but also by index.

Signed-off-by: Dmitry Torokhov d...@mail.ru
---

 drivers/input/misc/ati_remote2.c |   93 +++---
 1 files changed, 65 insertions(+), 28 deletions(-)

diff --git a/drivers/input/misc/ati_remote2.c b/drivers/input/misc/ati_remote2.c
index 2325765..b2e0d82 100644
--- a/drivers/input/misc/ati_remote2.c
+++ b/drivers/input/misc/ati_remote2.c
@@ -483,51 +483,88 @@ static void ati_remote2_complete_key(struct urb *urb)
 }
 
 static int ati_remote2_getkeycode(struct input_dev *idev,
- unsigned int scancode, unsigned int *keycode)
+ struct input_keymap_entry *ke)
 {
struct ati_remote2 *ar2 = input_get_drvdata(idev);
unsigned int mode;
-   int index;
+   int offset;
+   unsigned int index;
+   unsigned int scancode;
+
+   if (ke-flags  INPUT_KEYMAP_BY_INDEX) {
+   index = ke-index;
+   if (index = (ATI_REMOTE2_MODES - 1) *
+   ARRAY_SIZE(ati_remote2_key_table))
+   return -EINVAL;
+
+   mode = ke-index / ARRAY_SIZE(ati_remote2_key_table);
+   offset = ke-index % ARRAY_SIZE(ati_remote2_key_table);
+   scancode = (mode  8) + ati_remote2_key_table[offset].hw_code;
+   } else {
+   if (input_scancode_to_scalar(ke, scancode))
+   return -EINVAL;
+
+   mode = scancode  8;
+   if (mode  ATI_REMOTE2_PC)
+   return -EINVAL;
+
+   offset = ati_remote2_lookup(scancode  0xff);
+   if (offset  0)
+   return -EINVAL;
+
+   index = mode * ARRAY_SIZE(ati_remote2_key_table) + offset;
+   }
 
-   mode = scancode  8;
-   if (mode  ATI_REMOTE2_PC || !((1  mode)  ar2-mode_mask))
-   return -EINVAL;
+   ke-keycode = ar2-keycode[mode][offset];
+   ke-len = sizeof(scancode);
+   memcpy(ke-scancode, scancode, sizeof(scancode));
+   ke-index = index;
 
-   index = ati_remote2_lookup(scancode  0xFF);
-   if (index  0)
-   return -EINVAL;
-
-   *keycode = ar2-keycode[mode][index];
return 0;
 }
 
 static int ati_remote2_setkeycode(struct input_dev *idev,
- unsigned int scancode, unsigned int keycode)
+ const struct input_keymap_entry *ke,
+ unsigned int *old_keycode)
 {
struct ati_remote2 *ar2 = input_get_drvdata(idev);
-   unsigned int mode, old_keycode;
-   int index;
-
-   mode = scancode  8;
-   if (mode  ATI_REMOTE2_PC || !((1  mode)  ar2-mode_mask))
-   return -EINVAL;
-
-   index = ati_remote2_lookup(scancode  0xFF);
-   if (index  0)
-   return -EINVAL;
+   unsigned int mode;
+   int offset;
+   unsigned int index;
+   unsigned int scancode;
+
+   if (ke-flags  INPUT_KEYMAP_BY_INDEX) {
+   if (ke-index = (ATI_REMOTE2_MODES - 1) *
+   ARRAY_SIZE(ati_remote2_key_table))
+   return -EINVAL;
+
+   mode = ke-index / ARRAY_SIZE(ati_remote2_key_table);
+   offset = ke-index % ARRAY_SIZE(ati_remote2_key_table);
+   } else {
+   if (input_scancode_to_scalar(ke, scancode))
+   return -EINVAL;
+
+   mode = scancode  8;
+   if (mode  ATI_REMOTE2_PC)
+   return -EINVAL;
+
+   offset = ati_remote2_lookup(scancode  0xff);
+   if (offset  0)
+   return -EINVAL;
+   }
 
-   old_keycode = ar2-keycode[mode][index];
-   ar2-keycode[mode][index] = keycode;
-   __set_bit(keycode, idev-keybit);
+   *old_keycode = ar2-keycode[mode][offset];
+   ar2-keycode[mode][offset] = ke-keycode;
+   __set_bit(ke-keycode, idev-keybit);
 
for (mode = 0; mode  ATI_REMOTE2_MODES; mode++) {
for (index = 0; index  ARRAY_SIZE(ati_remote2_key_table); 
index++) {
-   if (ar2-keycode[mode][index] == old_keycode)
+   if (ar2-keycode[mode][index] == *old_keycode)
return 0;
}
}
 
-   __clear_bit(old_keycode, idev-keybit);
+   __clear_bit(*old_keycode, idev-keybit);
 
return 0;
 }
@@ -575,8 +612,8 @@ static int ati_remote2_input_init(struct ati_remote2 *ar2)
idev-open = ati_remote2_open;
idev-close = ati_remote2_close;
 
-   idev-getkeycode = ati_remote2_getkeycode;
-   idev-setkeycode = ati_remote2_setkeycode;
+   idev-getkeycode_new = ati_remote2_getkeycode;
+   idev-setkeycode_new = ati_remote2_setkeycode;

[PATCH 6/6] Input: media/IR - switch to using new keycode interface

Switch the code to use new style of getkeycode and setkeycode
methods to allow retrieving and setting keycodes not only by
their scancodes but also by index.

Signed-off-by: Dmitry Torokhov d...@mail.ru
---

 drivers/media/IR/ir-keytable.c |  393 +++-
 include/media/rc-map.h |2 
 2 files changed, 263 insertions(+), 132 deletions(-)

diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 7e82a9d..5ca36a4 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -25,14 +25,56 @@
 #define IR_KEYPRESS_TIMEOUT 250
 
 /**
+ * ir_create_table() - initializes a scancode table
+ * @rc_tab:the ir_scancode_table to initialize
+ * @name:  name to assign to the table
+ * @ir_type:   ir type to assign to the new table
+ * @size:  initial size of the table
+ * @return:zero on success or a negative error code
+ *
+ * This routine will initialize the ir_scancode_table and will allocate
+ * memory to hold at least the specified number elements.
+ */
+static int ir_create_table(struct ir_scancode_table *rc_tab,
+  const char *name, u64 ir_type, size_t size)
+{
+   rc_tab-name = name;
+   rc_tab-ir_type = ir_type;
+   rc_tab-alloc = roundup_pow_of_two(size * sizeof(struct ir_scancode));
+   rc_tab-size = rc_tab-alloc / sizeof(struct ir_scancode);
+   rc_tab-scan = kmalloc(rc_tab-alloc, GFP_KERNEL);
+   if (!rc_tab-scan)
+   return -ENOMEM;
+
+   IR_dprintk(1, Allocated space for %u keycode entries (%u bytes)\n,
+  rc_tab-size, rc_tab-alloc);
+   return 0;
+}
+
+/**
+ * ir_free_table() - frees memory allocated by a scancode table
+ * @rc_tab:the table whose mappings need to be freed
+ *
+ * This routine will free memory alloctaed for key mappings used by given
+ * scancode table.
+ */
+static void ir_free_table(struct ir_scancode_table *rc_tab)
+{
+   rc_tab-size = 0;
+   kfree(rc_tab-scan);
+   rc_tab-scan = NULL;
+}
+
+/**
  * ir_resize_table() - resizes a scancode table if necessary
  * @rc_tab:the ir_scancode_table to resize
+ * @gfp_flags: gfp flags to use when allocating memory
  * @return:zero on success or a negative error code
  *
  * This routine will shrink the ir_scancode_table if it has lots of
  * unused entries and grow it if it is full.
  */
-static int ir_resize_table(struct ir_scancode_table *rc_tab)
+static int ir_resize_table(struct ir_scancode_table *rc_tab, gfp_t gfp_flags)
 {
unsigned int oldalloc = rc_tab-alloc;
unsigned int newalloc = oldalloc;
@@ -57,7 +99,7 @@ static int ir_resize_table(struct ir_scancode_table *rc_tab)
if (newalloc == oldalloc)
return 0;
 
-   newscan = kmalloc(newalloc, GFP_ATOMIC);
+   newscan = kmalloc(newalloc, gfp_flags);
if (!newscan) {
IR_dprintk(1, Failed to kmalloc %u bytes\n, newalloc);
return -ENOMEM;
@@ -72,26 +114,78 @@ static int ir_resize_table(struct ir_scancode_table 
*rc_tab)
 }
 
 /**
- * ir_do_setkeycode() - internal function to set a keycode in the
- * scancode-keycode table
+ * ir_update_mapping() - set a keycode in the scancode-keycode table
  * @dev:   the struct input_dev device descriptor
- * @rc_tab:the struct ir_scancode_table to set the keycode in
- * @scancode:  the scancode for the ir command
- * @keycode:   the keycode for the ir command
- * @resize:whether the keytable may be shrunk
- * @return:-EINVAL if the keycode could not be inserted, otherwise zero.
+ * @rc_tab:scancode table to be adjusted
+ * @index: index of the mapping that needs to be updated
+ * @keycode:   the desired keycode
+ * @return:previous keycode assigned to the mapping
+ *
+ * This routine is used to update scancode-keycopde mapping at given
+ * position.
+ */
+static unsigned int ir_update_mapping(struct input_dev *dev,
+ struct ir_scancode_table *rc_tab,
+ unsigned int index,
+ unsigned int new_keycode)
+{
+   int old_keycode = rc_tab-scan[index].keycode;
+   int i;
+
+   /* Did the user wish to remove the mapping? */
+   if (new_keycode == KEY_RESERVED || new_keycode == KEY_UNKNOWN) {
+   IR_dprintk(1, #%d: Deleting scan 0x%04x\n,
+  index, rc_tab-scan[index].scancode);
+   rc_tab-len--;
+   memmove(rc_tab-scan[index], rc_tab-scan[index+ 1],
+   (rc_tab-len - index) * sizeof(struct ir_scancode));
+   } else {
+   IR_dprintk(1, #%d: %s scan 0x%04x with key 0x%04x\n,
+  index,
+  old_keycode == KEY_RESERVED ? New : Replacing,
+  rc_tab-scan[index].scancode, new_keycode);
+   rc_tab-scan[index].keycode = new_keycode;
+

[PATCH 3/6] Input: hid-input - switch to using new keycode interface

Switch HID code to use new style of getkeycode and setkeycode
methods to allow retrieving and setting keycodes not only by
their scancodes but also by index.

Signed-off-by: Dmitry Torokhov d...@mail.ru
---

 drivers/hid/hid-input.c |  103 ---
 1 files changed, 70 insertions(+), 33 deletions(-)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 6c03dcc..b12c07e 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -68,39 +68,49 @@ static const struct {
 #define map_key_clear(c)   hid_map_usage_clear(hidinput, usage, bit, \
max, EV_KEY, (c))
 
-static inline int match_scancode(unsigned int code, unsigned int scancode)
+static bool match_scancode(struct hid_usage *usage,
+  unsigned int cur_idx, unsigned int scancode)
 {
-   if (scancode == 0)
-   return 1;
-
-   return (code  (HID_USAGE_PAGE | HID_USAGE)) == scancode;
+   return (usage-hid  (HID_USAGE_PAGE | HID_USAGE)) == scancode;
 }
 
-static inline int match_keycode(unsigned int code, unsigned int keycode)
+static bool match_keycode(struct hid_usage *usage,
+ unsigned int cur_idx, unsigned int keycode)
 {
-   if (keycode == 0)
-   return 1;
+   return usage-code == keycode;
+}
 
-   return code == keycode;
+static bool match_index(struct hid_usage *usage,
+   unsigned int cur_idx, unsigned int idx)
+{
+   return cur_idx == idx;
 }
 
+typedef bool (*hid_usage_cmp_t)(struct hid_usage *usage,
+   unsigned int cur_idx, unsigned int val);
+
 static struct hid_usage *hidinput_find_key(struct hid_device *hid,
-  unsigned int scancode,
-  unsigned int keycode)
+  hid_usage_cmp_t match,
+  unsigned int value,
+  unsigned int *usage_idx)
 {
-   int i, j, k;
+   unsigned int i, j, k, cur_idx = 0;
struct hid_report *report;
struct hid_usage *usage;
 
for (k = HID_INPUT_REPORT; k = HID_OUTPUT_REPORT; k++) {
list_for_each_entry(report, hid-report_enum[k].report_list, 
list) {
for (i = 0; i  report-maxfield; i++) {
-   for ( j = 0; j  report-field[i]-maxusage; 
j++) {
+   for (j = 0; j  report-field[i]-maxusage; 
j++) {
usage = report-field[i]-usage + j;
-   if (usage-type == EV_KEY 
-   match_scancode(usage-hid, 
scancode) 
-   match_keycode(usage-code, 
keycode))
-   return usage;
+   if (usage-type == EV_KEY) {
+   if (match(usage, cur_idx, 
value)) {
+   if (usage_idx)
+   *usage_idx = 
cur_idx;
+   return usage;
+   }
+   cur_idx++;
+   }
}
}
}
@@ -108,39 +118,66 @@ static struct hid_usage *hidinput_find_key(struct 
hid_device *hid,
return NULL;
 }
 
+static struct hid_usage *hidinput_locate_usage(struct hid_device *hid,
+   const struct input_keymap_entry *ke,
+   unsigned int *index)
+{
+   struct hid_usage *usage;
+   unsigned int scancode;
+
+   if (ke-flags  INPUT_KEYMAP_BY_INDEX)
+   usage = hidinput_find_key(hid, match_index, ke-index, index);
+   else if (input_scancode_to_scalar(ke, scancode) == 0)
+   usage = hidinput_find_key(hid, match_scancode, scancode, index);
+   else
+   usage = NULL;
+
+   return usage;
+}
+
 static int hidinput_getkeycode(struct input_dev *dev,
-  unsigned int scancode, unsigned int *keycode)
+  struct input_keymap_entry *ke)
 {
struct hid_device *hid = input_get_drvdata(dev);
struct hid_usage *usage;
+   unsigned int scancode, index;
 
-   usage = hidinput_find_key(hid, scancode, 0);
+   usage = hidinput_locate_usage(hid, ke, index);
if (usage) {
-   *keycode = usage-code;
+   ke-keycode = usage-code;
+   ke-index = index;
+   scancode = usage-hid  (HID_USAGE_PAGE | HID_USAGE);
+   ke-len = sizeof(scancode);
+

Re: [PATCH] Illuminators and status LED controls

2010-09-08 Thread Eduardo Valentin

Hello,

On Wed, Sep 08, 2010 at 04:16:48AM +0200, ext Eino-Ville Talvala wrote:
 
  This is probably a bit OT, but these sorts of indicator LEDs can get quite 
 complicated.
 
 As part of our FCamera sample program on the Nokia N900 (which uses V4L2 way 
 down there), we wanted to reprogram the front indicator LED to flash exactly 
 when a picture is taken.  The N900 front LED is quite a programmable beast 
 [1], with a dedicated microcontroller (the lp5521) that runs little programs 
 that define the blink patterns for the RGB LED.
 
 I'm not really suggesting that the V4L2 control should be able to handle this 
 sort of an LED, but as these sorts of things get cheaper, it may become a 
 case of 'why not?' for manufacturers putting in more complex RGB LEDs.   And 
 if you don't want to encapsulate all that in V4L2, it may be better to leave 
 it to other APIs at some point of complexity (the current lp5521 driver seems 
 to have a sysfs-only interface for now for the programmable patterns, and the 
 standard LED API otherwise)
 
 [1] http://wiki.maemo.org/LED_patterns

Well, that's exactly why duplicating API's is usually a bad idea. If the thing 
start to get complex, having only one place to hold
the mess is better than keeping it into two (or more) different places. This 
will become worst and worst. I mean, why do we want two
different APIs to control same stuff?

And yes, application developers must use the correct API to control stuff. Why 
should kernel duplicate interfaces just because
user land don't want to use two different interfaces? Doesn't this sound a bit 
... strange at least?

 
 Eino-Ville Talvala
 Computer Graphics Lab
 Stanford University
 
 On 9/7/2010 1:33 PM, Andy Walls wrote:
  It has already been discussed.  Please check the list archives for the past 
  few days.


OK, will search the logs. But you should probably add some sort of reasoning in 
your patch
description, explaining why you are duplicating interfaces.

 
  Do you know of any V4L2 application developer or development team that 
  prefers to use a separate API just to turn lights on and off, when all 
  other aspects of the incoming video are controlled with the V4L2 control 
  API?
 
  (That question is mostly rhetorical, but I'd still actually be interested 
  from video app developers.)
 
  Regards,
  Andy
 
  Eduardo Valentin eduardo.valen...@nokia.com wrote:
 
  Hello,
 
  On Mon, Sep 06, 2010 at 08:11:05PM +0200, ext Jean-Francois Moine wrote:
  Hi,
 
  This new proposal cancels the previous 'LED control' patch.
 
  Cheers.
 
  -- 
  Ken ar c'hentañ   | ** Breizh ha Linux atav! **
  Jef   |   http://moinejf.free.fr/
  Apologies if this has been already discussed but,
  doesn't this patch duplicates the same feature present
  nowadays under include/linux/leds.h ??
 
  I mean, if you want to control leds, I think we already have that API, no?
 
  BR,
 
  ---
  Eduardo Valentin
  --
  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
  N�r��y���b�X��ǧv�^�)޺{.n�+{���bj)���w*jg����ݢj/���z�ޖ��2�ޙ)ߡ�a�����G���h��j:+v���w�٥
 

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

Re: [PATCH 0/6] Large scancode handling

2010-09-08 Thread Jiri Kosina

On Wed, 8 Sep 2010, Dmitry Torokhov wrote:

 Hi Mauro,
 
 I guess I better get off my behind and commit the changes to support large
 scancodes, or they will not make to 2.6.37 either... There isn't much
 changes, except I followed David's suggestion and changed boolean index
 field into u8 flags field. Still, please glance it over once again and
 shout if you see something you do not like.
 
 Jiri, how do you want to handle the changes to HID? I could either push
 them through my tree together with the first patch or you can push through
 yours once the first change hits mainline.

I think that there will unlikely be any conflict in .37 merge window in 
this area (and if there were, I'll sort it out).

So please add

Acked-by: Jiri Kosina jkos...@suse.cz

to the hid-input.c bits and feel free to take it through your tree, if it 
is convenient for you.

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
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

First DVB-T2 tuner announced - Hauppauge PCTV Nanostick T2 290e

2010-09-08 Thread Steve Kerrison

Hauppauge has released details of its first DVB-T2 tuner at IFA. Some
scarce details are here:

http://www.wegotserved.com/2010/09/04/ifa-2010-hauppauge-announces-freeview-hd-dvbt2-tuner-pc/

along with a datasheet (without very much data) here:

http://www.wegotserved.com/2010/09/06/ifa-2010-pctv-nanostick-t2-290e-freeview-hd-tuner-full-specs-data-sheet/

Only 720p video support is claimed, but that can't be anything to do
with receiving the mux so I suspect that's a software limitation in the
bundled player.

Does anyone have (or have a means of getting) more info on the internals
of this stick to aid Linux development? I will be attempting to acquire
one of these at first release in October, and will do what I can, from
USB snooping through to module development - as far as my time and skill
can muster.

Regards,
Steve Kerrison.

--
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] V4L/DVB: radio-si4713: Add regulator framework support

2010-09-08 Thread Eduardo Valentin

Hello,

On Wed, Sep 08, 2010 at 07:59:38AM +0200, Jarkko Nikula wrote:
 Hi
 
 On Tue, 7 Sep 2010 22:49:49 +0300
 Eduardo Valentin eduardo.valen...@nokia.com wrote:
 
  Hello Jarkko,
  
  On Sun, Jun 13, 2010 at 08:09:28PM +0200, Jarkko Nikula wrote:
   Convert the driver to use regulator framework instead of set_power 
   callback.
   This with gpio_reset platform data provide cleaner way to manage chip VIO,
   VDD and reset signal inside the driver.
   
   Signed-off-by: Jarkko Nikula jhnik...@gmail.com
   Cc: Eduardo Valentin eduardo.valen...@nokia.com
   ---
   I don't have specifications for this chip so I don't know how long the
   reset signal must be active after power-up. I used 50 us from Maemo
   kernel sources for Nokia N900 and I can successfully enable-disable
   transmitter on N900 with vdd power cycling.
   ---
drivers/media/radio/radio-si4713.c |   20 ++-
drivers/media/radio/si4713-i2c.c   |   48 
   ---
drivers/media/radio/si4713-i2c.h   |3 +-
include/media/si4713.h |3 +-
  
  Could you please elaborate a bit more on the fact that you have put vio on
  the platform driver and vdd on the i2c driver?
  
 This is good question and let me explain. The regulator management
 division between these two files were based on my assumption that only
 VIO is needed and must be on before probing the chip on I2C bus.
 
 Another assumption was that only VDD can realistically be managed
 runtime in si4713_powerup function. I think usually IO voltages cannot
 be shutdown even in suspend while the system is powered so I let the
 driver to keep the VIO enabled as long as the module is loaded.

OK. I kinda agree with you in this reasoning.

My concern here is that splitting the regulator usage into two entities
could cause some troubles.

The background here you are probably missing is that the split between
i2c and platform drivers. That has been done because we were thinking also
in the situation where the si4713 i2c driver could be used without the
platform driver. I mean, the i2c code could be re-used for instance by
other v4l2 driver, if that is driving a device which has also si4713.
So, in this sense, the current platform is essentially a wrapper.
And if you split the regulator usage in that way,
we would probably be loosing that.

And apart from that, it is also bad from the regfw point of view as well.
I believe the idea is that the driver itself must take care of all needed
regulators. The way you have done, looks like the platform driver needs only
VIO and the i2c needs only VDD. And to my understanding, the i2c needs both
in order to work. So, my suggestion is to move everything to the i2c driver.

 
 
 -- 
 Jarkko

---
Eduardo Valentin
--
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] Don't identify PV SBTVD Hybrid as a DibCom device

As reported by Carlos, Prolink Pixelview SBTVD Hybrid is based on
Conexant cx231xx + Fujitsu 86A20S demodulator. However, both shares
the same USB ID. So, we need to use USB bcdDevice, in order to
properly discover what's the board.

We know for sure that bcd 0x100 is used for a dib0700 device, while
bcd 0x4001 is used for a cx23102 device. This patch reserves two ranges,
the first one from 0x-0x3f00 for dib0700, and the second from
0x4000-0x4fff for cx231xx devices.

This may need fixes in the future, as we get access to other devices.

Thanks-to: Carlos Americo Domiciano c_domici...@yahoo.com.br
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c 
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index f634d2e..ce66c5a 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -1781,7 +1781,7 @@ struct usb_device_id dib0700_usb_id_table[] = {
 /* 60 */{ USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_T_XXS_2) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK807XPVR) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK807XP) },
-   { USB_DEVICE(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD) },
+   { USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x000, 
0x3f00) },
{ USB_DEVICE(USB_VID_EVOLUTEPC, USB_PID_TVWAY_PLUS) },
 /* 65 */{ USB_DEVICE(USB_VID_PINNACLE, USB_PID_PINNACLE_PCTV73ESE) },
{ USB_DEVICE(USB_VID_PINNACLE,  USB_PID_PINNACLE_PCTV282E) },
diff --git a/drivers/media/video/cx231xx/Makefile 
b/drivers/media/video/cx231xx/Makefile
index 755dd0c..6f2b573 100644
--- a/drivers/media/video/cx231xx/Makefile
+++ b/drivers/media/video/cx231xx/Makefile
@@ -11,4 +11,5 @@ EXTRA_CFLAGS += -Idrivers/media/video
 EXTRA_CFLAGS += -Idrivers/media/common/tuners
 EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
 EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
+EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-usb
 
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c 
b/drivers/media/video/cx231xx/cx231xx-cards.c
index 6bdc0ef..5b7c9a9 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -32,6 +32,7 @@
 #include media/v4l2-chip-ident.h
 
 #include media/cx25840.h
+#include dvb-usb-ids.h
 #include xc5000.h
 
 #include cx231xx.h
@@ -175,6 +176,8 @@ struct usb_device_id cx231xx_id_table[] = {
 .driver_info = CX231XX_BOARD_CNXT_RDE_250},
{USB_DEVICE(0x0572, 0x58A1),
 .driver_info = CX231XX_BOARD_CNXT_RDU_250},
+   {USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 
0x4000,0x4fff),
+.driver_info = CX231XX_BOARD_UNKNOWN},
{},
 };
 
--
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] V4L/DVB: radio-si4713: Add regulator framework support

2010-09-08 Thread Jarkko Nikula

On Wed, 8 Sep 2010 15:11:36 +0300
Eduardo Valentin eduardo.valen...@nokia.com wrote:

 The background here you are probably missing is that the split between
 i2c and platform drivers. That has been done because we were thinking also
 in the situation where the si4713 i2c driver could be used without the
 platform driver. I mean, the i2c code could be re-used for instance by
 other v4l2 driver, if that is driving a device which has also si4713.
 So, in this sense, the current platform is essentially a wrapper.
 And if you split the regulator usage in that way,
 we would probably be loosing that.
 
This is good to know. In that sense it would be good to have some
common place for managing the VIO here.

 And apart from that, it is also bad from the regfw point of view as well.
 I believe the idea is that the driver itself must take care of all needed
 regulators. The way you have done, looks like the platform driver needs only
 VIO and the i2c needs only VDD. And to my understanding, the i2c needs both
 in order to work. So, my suggestion is to move everything to the i2c driver.
 
Problem of course is that the chip cannot be probed if the VIO is
missing so it must be on before the chip is probed. Quite many i2c
drivers seems to rely that the VIO is on before probing. Therefore I
did here the VIO enable in platform driver as there were this instance
on top of i2c driver. I think perfect solution would require some sort
of support to i2c core.


-- 
Jarkko
--
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] V4L/DVB: cx88: Fix some gcc warnings

drivers/media/video/cx88/cx88-dsp.c: In function ‘detect_a2_a2m_eiaj’:
drivers/media/video/cx88/cx88-dsp.c:158: warning: ‘carrier_freq’ may be used 
uninitialized in this function
drivers/media/video/cx88/cx88-dsp.c:158: warning: ‘stereo_freq’ may be used 
uninitialized in this function
drivers/media/video/cx88/cx88-dsp.c:158: warning: ‘dual_freq’ may be used 
uninitialized in this function

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/video/cx88/cx88-dsp.c 
b/drivers/media/video/cx88/cx88-dsp.c
index e1d6eef..2e6a92f 100644
--- a/drivers/media/video/cx88/cx88-dsp.c
+++ b/drivers/media/video/cx88/cx88-dsp.c
@@ -175,13 +175,7 @@ static s32 detect_a2_a2m_eiaj(struct cx88_core *core, s16 
x[], u32 N)
stereo_freq = FREQ_EIAJ_STEREO;
dual_freq = FREQ_EIAJ_DUAL;
break;
-   case WW_NONE:
-   case WW_BTSC:
-   case WW_I:
-   case WW_L:
-   case WW_I2SPT:
-   case WW_FM:
-   case WW_I2SADC:
+   default:
printk(KERN_WARNING %s/0: unsupported audio mode %d for %s\n,
   core-name, core-tvaudio, __func__);
return UNSET;
-- 
1.7.1


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

[PATCH 2/2] V4L/DVB: cx25821: fix gcc warning when compiled with allyesconfig

drivers/staging/cx25821/cx25821-alsa.c:632: warning: ‘cx25821_audio_pci_tbl’ 
defined but not used

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/staging/cx25821/cx25821-alsa.c 
b/drivers/staging/cx25821/cx25821-alsa.c
index a43b188..095562c 100644
--- a/drivers/staging/cx25821/cx25821-alsa.c
+++ b/drivers/staging/cx25821/cx25821-alsa.c
@@ -629,7 +629,7 @@ static int snd_cx25821_pcm(struct cx25821_audio_dev *chip, 
int device,
  * Only boards with eeprom and byte 1 at eeprom=1 have it
  */
 
-static struct pci_device_id cx25821_audio_pci_tbl[] __devinitdata = {
+static const struct pci_device_id cx25821_audio_pci_tbl[] __devinitdata = {
{0x14f1, 0x0920, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{0,}
 };
-- 
1.7.1

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

Re: [PATCH 1/5] rc-code: merge and rename ir-core

Em 07-09-2010 18:51, David Härdeman escreveu:
 This patch merges the files which makes up ir-core and renames the
 resulting module to rc-core. IMHO this makes it much easier to hack
 on the core module since all code is in one file.
 
 This also allows some simplification of ir-core-priv.h as fewer internal
 functions need to be exposed.

I'm not sure about this patch. Big files tend to be harder to maintain,
as it takes more time to find the right functions inside it. Also, IMO, 
it makes sense to keep the raw-event code on a separate file.

Anyway, if we apply this patch right now, it will cause merge conflicts with
the input tree, due to the get/setkeycodebig patches, and with some other
patches that are pending merge/review. The better is to apply such patch
just after the release of 2.6.37-rc1, after having all those conflicts
solved.

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

Re: [PATCH 1/2] ir-core: centralize sysfs raw decoder enabling/disabling

2010-09-08 Thread Brian Rogers


 On 06/13/2010 01:29 PM, David Härdeman wrote:

diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index daf33c1..7ae5662 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -33,122 +33,178 @@ static struct class ir_input_class = {
  };

  /**
- * show_protocol() - shows the current IR protocol
+ * show_protocols() - shows the current IR protocol(s)
   * @d:the device descriptor
   * @mattr:the device attribute struct (unused)
   * @buf:  a pointer to the output buffer
   *
- * This routine is a callback routine for input read the IR protocol type.
- * it is trigged by reading /sys/class/rc/rc?/current_protocol.
- * It returns the protocol name, as understood by the driver.
+ * This routine is a callback routine for input read the IR protocol type(s).
+ * it is trigged by reading /sys/class/rc/rc?/protocols.
+ * It returns the protocol names of supported protocols.
+ * Enabled protocols are printed in brackets.
   */
-static ssize_t show_protocol(struct device *d,
-struct device_attribute *mattr, char *buf)
+static ssize_t show_protocols(struct device *d,
+ struct device_attribute *mattr, char *buf)
  {
-   char *s;
struct ir_input_dev *ir_dev = dev_get_drvdata(d);
-   u64 ir_type = ir_dev-rc_tab.ir_type;
-
-   IR_dprintk(1, Current protocol is %lld\n, (long long)ir_type);
-
-   /* FIXME: doesn't support multiple protocols at the same time */
-   if (ir_type == IR_TYPE_UNKNOWN)
-   s = Unknown;
-   else if (ir_type == IR_TYPE_RC5)
-   s = rc-5;
-   else if (ir_type == IR_TYPE_NEC)
-   s = nec;
-   else if (ir_type == IR_TYPE_RC6)
-   s = rc6;
-   else if (ir_type == IR_TYPE_JVC)
-   s = jvc;
-   else if (ir_type == IR_TYPE_SONY)
-   s = sony;
-   else
-   s = other;
+   u64 allowed, enabled;
+   char *tmp = buf;
+
+   if (ir_dev-props-driver_type == RC_DRIVER_SCANCODE) {


This change introduced an oops for me. On my saa7134 MSI TV Anywhere 
Plus, ir_dev-props is null, so dereferencing it causes the following 
while attempting to read /sys/devices/virtual/rc/rc0/protocols:


[  601.632041] BUG: unable to handle kernel NULL pointer dereference at 
(null)

[  601.632061] IP: [a00f43b5] show_protocols+0x25/0x120 [ir_core]
[  601.632079] PGD 7b181067 PUD 7bafe067 PMD 0
[  601.632093] Oops:  [#1] SMP
[  601.632103] last sysfs file: /sys/devices/virtual/rc/rc0/protocols
[  601.632111] CPU 0
[  601.632115] Modules linked in: binfmt_misc rfcomm parport_pc ppdev 
sco bnep l2cap saa7134_alsa arc4 rc_msi_tvanywhere_plus ir_kbd_i2c 
advantechwdt tda827x rt2500pci rt2x00pci rt2x00lib snd_intel8x0 tda8290 
snd_ac97_codec led_class ac97_bus tuner snd_seq_midi snd_rawmidi 
ir_lirc_codec lirc_dev mac80211 cfg80211 snd_seq_midi_event 
ir_sony_decoder ir_jvc_decoder saa7134 v4l2_common videodev v4l1_compat 
v4l2_compat_ioctl32 psmouse serio_raw ir_rc6_decoder snd_pcm snd_seq lp 
shpchp eeprom_93cx6 btusb snd_timer snd_seq_device videobuf_dma_sg 
ir_rc5_decoder snd videobuf_core ir_nec_decoder ir_common ir_core 
tveeprom soundcore edac_core bluetooth snd_page_alloc parport 
i2c_nforce2 k8temp edac_mce_amd usbhid hid btrfs zlib_deflate crc32c 
libcrc32c sata_nv forcedeth pata_amd

[  601.632319]
[  601.632335] Pid: 2928, comm: cat Not tainted 
2.6.36-rc3-00185-gd56557a #2 KN9 Series(NF-CK804)/Unknow
[  601.632368] RIP: 0010:[a00f43b5]  [a00f43b5] 
show_protocols+0x25/0x120 [ir_core]

[  601.632404] RSP: 0018:88007bb93e38  EFLAGS: 00010282
[  601.632423] RAX: 88007bb6e000 RBX: a00f5ee0 RCX: 
a00f4390
[  601.632444] RDX:  RSI: a00f5ee0 RDI: 
88007bb6e000
[  601.632465] RBP: 88007bb93e68 R08: 88007bb6e010 R09: 
8164ab40
[  601.632486] R10:  R11: 0246 R12: 
88007c928000
[  601.632507] R13: 8000 R14: 0246d000 R15: 
88007c8798a0
[  601.632529] FS:  7fe7aa26c700() GS:880001e0() 
knlGS:

[  601.632561] CS:  0010 DS:  ES:  CR0: 80050033
[  601.632580] CR2:  CR3: 7b19f000 CR4: 
06f0
[  601.632601] DR0:  DR1:  DR2: 

[  601.632623] DR3:  DR6: 0ff0 DR7: 
0400
[  601.632644] Process cat (pid: 2928, threadinfo 88007bb92000, task 
88007bcd2dc0)

[  601.632675] Stack:
[  601.632689]   a00f5ee0 88007bb93f48 
8000
[  601.632713] 0 0246d000 88007c8798a0 88007bb93e98 
813816e7
[  601.632750] 0 88007bb93e88 8110681e 88007bb93e98 
88007c8798c0

[  601.632797] Call Trace:
[  601.632819]  [813816e7] dev_attr_show+0x27/0x50
[  601.632842]  [8110681e] ?

Re: [PATCH 1/5] rc-code: merge and rename ir-core

On Wed, Sep 08, 2010 at 10:42:10AM -0300, Mauro Carvalho Chehab wrote:
 Em 07-09-2010 18:51, David Härdeman escreveu:
  This patch merges the files which makes up ir-core and renames the
  resulting module to rc-core. IMHO this makes it much easier to hack
  on the core module since all code is in one file.
  
  This also allows some simplification of ir-core-priv.h as fewer internal
  functions need to be exposed.
 
 I'm not sure about this patch. Big files tend to be harder to maintain,
 as it takes more time to find the right functions inside it. Also, IMO, 
 it makes sense to keep the raw-event code on a separate file.

There's definitely a balance to be struck between file size and file
count. Having all the relevant code in one file definitely has its
advantage in that its easier to jump around from function to function and
trace code paths taken, but I can see the argument for isolating the raw
event handling code a bit too, especially if its going to be further
expanded, which I believe is likely the case. So I guess I'm on the
fence here. :)

 Anyway, if we apply this patch right now, it will cause merge conflicts with
 the input tree, due to the get/setkeycodebig patches, and with some other
 patches that are pending merge/review. The better is to apply such patch
 just after the release of 2.6.37-rc1, after having all those conflicts
 solved.

The imon patch that moves mouse/panel/knob input to its own input device
should be possible to take in advance of everything else, more or less,
though I need to finish actually testing it out (and should probably make
some further imon fixes for issues listed in a kernel.org bugzilla, the
number of which escapes me at the moment).

-- 
Jarod Wilson
ja...@redhat.com

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

Re: [PATCH 1/2] ir-core: centralize sysfs raw decoder enabling/disabling

On Wed, Sep 08, 2010 at 07:04:03AM -0700, Brian Rogers wrote:
  On 06/13/2010 01:29 PM, David Härdeman wrote:
 diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
 index daf33c1..7ae5662 100644
 --- a/drivers/media/IR/ir-sysfs.c
 +++ b/drivers/media/IR/ir-sysfs.c
 @@ -33,122 +33,178 @@ static struct class ir_input_class = {
   };
 
   /**
 - * show_protocol() - shows the current IR protocol
 + * show_protocols() - shows the current IR protocol(s)
* @d: the device descriptor
* @mattr: the device attribute struct (unused)
* @buf:   a pointer to the output buffer
*
 - * This routine is a callback routine for input read the IR protocol type.
 - * it is trigged by reading /sys/class/rc/rc?/current_protocol.
 - * It returns the protocol name, as understood by the driver.
 + * This routine is a callback routine for input read the IR protocol 
 type(s).
 + * it is trigged by reading /sys/class/rc/rc?/protocols.
 + * It returns the protocol names of supported protocols.
 + * Enabled protocols are printed in brackets.
*/
 -static ssize_t show_protocol(struct device *d,
 - struct device_attribute *mattr, char *buf)
 +static ssize_t show_protocols(struct device *d,
 +  struct device_attribute *mattr, char *buf)
   {
 -char *s;
  struct ir_input_dev *ir_dev = dev_get_drvdata(d);
 -u64 ir_type = ir_dev-rc_tab.ir_type;
 -
 -IR_dprintk(1, Current protocol is %lld\n, (long long)ir_type);
 -
 -/* FIXME: doesn't support multiple protocols at the same time */
 -if (ir_type == IR_TYPE_UNKNOWN)
 -s = Unknown;
 -else if (ir_type == IR_TYPE_RC5)
 -s = rc-5;
 -else if (ir_type == IR_TYPE_NEC)
 -s = nec;
 -else if (ir_type == IR_TYPE_RC6)
 -s = rc6;
 -else if (ir_type == IR_TYPE_JVC)
 -s = jvc;
 -else if (ir_type == IR_TYPE_SONY)
 -s = sony;
 -else
 -s = other;
 +u64 allowed, enabled;
 +char *tmp = buf;
 +
 +if (ir_dev-props-driver_type == RC_DRIVER_SCANCODE) {
 
 This change introduced an oops for me. On my saa7134 MSI TV Anywhere
 Plus, ir_dev-props is null, so dereferencing it causes the
 following while attempting to read
 /sys/devices/virtual/rc/rc0/protocols:
 
 [  601.632041] BUG: unable to handle kernel NULL pointer dereference
 at (null)
 [  601.632061] IP: [a00f43b5] show_protocols+0x25/0x120 [ir_core]
 [  601.632079] PGD 7b181067 PUD 7bafe067 PMD 0
 [  601.632093] Oops:  [#1] SMP
 [  601.632103] last sysfs file: /sys/devices/virtual/rc/rc0/protocols
 [  601.632111] CPU 0
 [  601.632115] Modules linked in: binfmt_misc rfcomm parport_pc
 ppdev sco bnep l2cap saa7134_alsa arc4 rc_msi_tvanywhere_plus
 ir_kbd_i2c advantechwdt tda827x rt2500pci rt2x00pci rt2x00lib
 snd_intel8x0 tda8290 snd_ac97_codec led_class ac97_bus tuner
 snd_seq_midi snd_rawmidi ir_lirc_codec lirc_dev mac80211 cfg80211
 snd_seq_midi_event ir_sony_decoder ir_jvc_decoder saa7134
 v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 psmouse
 serio_raw ir_rc6_decoder snd_pcm snd_seq lp shpchp eeprom_93cx6
 btusb snd_timer snd_seq_device videobuf_dma_sg ir_rc5_decoder snd
 videobuf_core ir_nec_decoder ir_common ir_core tveeprom soundcore
 edac_core bluetooth snd_page_alloc parport i2c_nforce2 k8temp
 edac_mce_amd usbhid hid btrfs zlib_deflate crc32c libcrc32c sata_nv
 forcedeth pata_amd
 [  601.632319]
 [  601.632335] Pid: 2928, comm: cat Not tainted
 2.6.36-rc3-00185-gd56557a #2 KN9 Series(NF-CK804)/Unknow
 [  601.632368] RIP: 0010:[a00f43b5]  [a00f43b5]
 show_protocols+0x25/0x120 [ir_core]
 [  601.632404] RSP: 0018:88007bb93e38  EFLAGS: 00010282
 [  601.632423] RAX: 88007bb6e000 RBX: a00f5ee0 RCX:
 a00f4390
 [  601.632444] RDX:  RSI: a00f5ee0 RDI:
 88007bb6e000
 [  601.632465] RBP: 88007bb93e68 R08: 88007bb6e010 R09:
 8164ab40
 [  601.632486] R10:  R11: 0246 R12:
 88007c928000
 [  601.632507] R13: 8000 R14: 0246d000 R15:
 88007c8798a0
 [  601.632529] FS:  7fe7aa26c700() GS:880001e0()
 knlGS:
 [  601.632561] CS:  0010 DS:  ES:  CR0: 80050033
 [  601.632580] CR2:  CR3: 7b19f000 CR4:
 06f0
 [  601.632601] DR0:  DR1:  DR2:
 
 [  601.632623] DR3:  DR6: 0ff0 DR7:
 0400
 [  601.632644] Process cat (pid: 2928, threadinfo 88007bb92000,
 task 88007bcd2dc0)
 [  601.632675] Stack:
 [  601.632689]   a00f5ee0 88007bb93f48
 8000
 [  601.632713] 0 0246d000 88007c8798a0
 88007bb93e98 813816e7
 [  601.632750] 0 88007bb93e88 8110681e
 88007bb93e98 88007c8798c0
 [  601.632797] Call Trace:
 [  601.632819]  [813816e7]

[Patch] Correct Signal Strength values for STB0899

2010-09-08 Thread Newsy Paper

Hi,

first of all I have to say that this patch is not from me.
It's from rotor-0.1.4mh-v1.2.tar.gz
Thx to the author of that patch and the modified rotor Plugin. I think he's a 
friend of Mike Booth

I think it should be included into s2-liplianin.
With this patch all dvb-s and dvb-s2 signal strength values are scaled 
correctly.

kind regards


Newsy



STB0899_signal_strength_v3patch
Description: Binary data

Re: [PATCH 0/6] Large scancode handling

On Wed, Sep 08, 2010 at 11:48:50AM +0200, Jiri Kosina wrote:
 On Wed, 8 Sep 2010, Dmitry Torokhov wrote:
 
  Hi Mauro,
  
  I guess I better get off my behind and commit the changes to support large
  scancodes, or they will not make to 2.6.37 either... There isn't much
  changes, except I followed David's suggestion and changed boolean index
  field into u8 flags field. Still, please glance it over once again and
  shout if you see something you do not like.
  
  Jiri, how do you want to handle the changes to HID? I could either push
  them through my tree together with the first patch or you can push through
  yours once the first change hits mainline.
 
 I think that there will unlikely be any conflict in .37 merge window in 
 this area (and if there were, I'll sort it out).
 
 So please add
 
   Acked-by: Jiri Kosina jkos...@suse.cz
 
 to the hid-input.c bits and feel free to take it through your tree, if it 
 is convenient for you.

It'll conflict a little bith with the tivo slide patch I posted yesterday,
but mostly just minor context changes. I can redo that patch on top of
these changes if that's preferred.

-- 
Jarod Wilson
ja...@redhat.com

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

Re: [PATCH] af9015: add USB ID for Terratec Cinergy T Stick RC MKII

Em 25-08-2010 10:58, Antti Palosaari escreveu:
 Heissan Stefan,
 
 On 08/25/2010 04:08 PM, Stefan Lippers-Hollmann wrote:
 Adding the USB ID for my TerraTec Electronic GmbH Cinergy T RC MKII
 [0ccd:0097] and hooking it up into af9015, on top of your new NXP TDA18218
 patches, makes it work for me.
 
 Patch is OK, I have just similar patch waiting here...
 
 Acked-by: Antti Palosaari cr...@iki.fi
 
 I have been waiting Mauro commit for TDA18218 driver which I send about 2 
 weeks ago. And few others too for the MXL5007T based devices. Mauro when you 
 will commit TDA18218?

I've committed it this week.  Sorry for being late about that. I was very busy
with some other pending work. 

This patch caused a minor merge conflict. I just fixed it and merged it on my 
tree.

 
 Just the shipped IR remote control doesn't seem to create keycode events
 yet (tested with different remote=%d parameters), are there any hints to
 add support for that?
 
 My next plan is to move that remote controller to the new remote core system. 
 I have done some tests and I can now read out raw remote codes from the 
 device.

That's great news. 

 Before that you can add keymap for that remote. There is many ways to get 
 keycodes; 
 1) USB-sniff, 2) dump from Windows driver, 3) read from af9015 memory, 4) use 
 some other IR receiver...
 
 regards
 Antti
 
 Signed-off-by: Stefan Lippers-Hollmanns@gmx.de
 ---

 This depends on the git pull request NXP TDA18218 silicon tuner driver
 from Antti Palosaaricr...@iki.fi  and does not apply to -stable:
   * NXP TDA18218 silicon tuner driver
   * af9013: add support for tda18218 silicon tuner
   * af9015: add support for tda18218 silicon tuner
 

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

Re: [PATCH 0/6] Large scancode handling

On Wed, Sep 08, 2010 at 12:41:38AM -0700, Dmitry Torokhov wrote:
 Hi Mauro,
 
 I guess I better get off my behind and commit the changes to support large
 scancodes, or they will not make to 2.6.37 either... There isn't much
 changes, except I followed David's suggestion and changed boolean index
 field into u8 flags field. Still, please glance it over once again and
 shout if you see something you do not like.
 
 Jiri, how do you want to handle the changes to HID? I could either push
 them through my tree together with the first patch or you can push through
 yours once the first change hits mainline.
 
 Mauro, the same question goes for media/IR patch.
 
 David, I suppose you still have the winbond remote so you could test
 changes to winbond-cir driver.

This'll be fun. :) David recently posted a patchset that among other
things, ports winbond-cir over to {ir,rc}-core to the tune of ~700 less
lines in winbond-cir.c. It also touches a fair amount of core bits, as
does a patchset posted by Maxim... I suspect this series should probably
go in first though.

 Ville, do you still have the hardware to try our ati_remote2 changes?

If not, I've got the hardware. (Speaking of which, porting ati_remote*
over to {ir,rc}-core is also on the TODO list, albeit with very very
low priority at the moment).

-- 
Jarod Wilson
ja...@redhat.com

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

Re: [PATCH 3/8] IR: fix duty cycle capability

On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
 Due to typo lirc bridge enabled wrong capability.

 Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
 ---
  drivers/media/IR/ir-lirc-codec.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

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

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

Re: [PATCH 4/8] IR: fix keys beeing stuck down forever.

On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
 The logic in ir_timer_keyup was inverted.

 In case that values aren't equal,
 the meaning of the time_is_after_eq_jiffies(ir-keyup_jiffies) is that
 ir-keyup_jiffies is after the the jiffies or equally that
 that jiffies are before the the ir-keyup_jiffies which is
 exactly the situation we want to avoid (that the timeout is in the future)
 Confusing Eh?

Yeah, seen time_is_{before,after}_jiffies use accidentally inverted a
couple of times... Kinda hints that we could use better names and/or
descriptions of the functions, but maybe people just need to read more
carefully (dunno, haven't looked to see what's there for usage
descriptions already)... Anyway.

 Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
 ---
  drivers/media/IR/ir-keytable.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

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

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

Re: [PATCH 5/8] IR: extend MCE keymap.

On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
 These keys are found on remote bundled with
 Toshiba Qosmio F50-10q.

 Found and tested by, Sami R maeses...@gmail.com

 Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
 ---
  drivers/media/IR/keymaps/rc-rc6-mce.c |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

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

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

Re: [PATCH 1/5] rc-code: merge and rename ir-core

Tag files and a decent editor are all one needs for full code navigation. The
kernel makefile already has a tags target to make the tags file.

Smaller files make for better logical isolation of functions, limiting
visibilty/scope, and faster compilation of a file (but maybe at the expense of
link time). That sort of isolation of functionality into smaller files also
makes the code more digestable for someone new looking at it, IMO.

Large files are good for a pile of stuff no one ever needs to look at again:
well tested code that has an expected low rate of change in the future.

Regards,
Andy

Jarod Wilson ja...@redhat.com wrote:

On Wed, Sep 08, 2010 at 10:42:10AM -0300, Mauro Carvalho Chehab wrote:
Em 07-09-2010 18:51, David Härdeman escreveu:
This patch merges the files which makes up ir-core and renames the
resulting module to rc-core. IMHO this makes it much easier to hack
on the core module since all code is in one file.

This also allows some simplification of ir-core-priv.h as fewer internal
functions need to be exposed.

I'm not sure about this patch. Big files tend to be harder to maintain,
as it takes more time to find the right functions inside it. Also, IMO,
it makes sense to keep the raw-event code on a separate file.

There's definitely a balance to be struck between file size and file
count. Having all the relevant code in one file definitely has its
advantage in that its easier to jump around from function to function and
trace code paths taken, but I can see the argument for isolating the raw
event handling code a bit too, especially if its going to be further
expanded, which I believe is likely the case. So I guess I'm on the
fence here. :)

Anyway, if we apply this patch right now, it will cause merge conflicts with
the input tree, due to the get/setkeycodebig patches, and with some other
patches that are pending merge/review. The better is to apply such patch
just after the release of 2.6.37-rc1, after having all those conflicts
solved.

The imon patch that moves mouse/panel/knob input to its own input device
should be possible to take in advance of everything else, more or less,
though I need to finish actually testing it out (and should probably make
some further imon fixes for issues listed in a kernel.org bugzilla, the
number of which escapes me at the moment).

--
Jarod Wilson
ja...@redhat.com

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w*jg����ݢj/���z�ޖ��2�ޙ�)ߡ�a�����G���h��j:+v���w��٥

Re: [PATCH 0/6] Large scancode handling

Em 08-09-2010 11:24, Jarod Wilson escreveu:
 On Wed, Sep 08, 2010 at 11:48:50AM +0200, Jiri Kosina wrote:
 On Wed, 8 Sep 2010, Dmitry Torokhov wrote:

 Hi Mauro,

 I guess I better get off my behind and commit the changes to support large
 scancodes, or they will not make to 2.6.37 either... There isn't much
 changes, except I followed David's suggestion and changed boolean index
 field into u8 flags field. Still, please glance it over once again and
 shout if you see something you do not like.

 Jiri, how do you want to handle the changes to HID? I could either push
 them through my tree together with the first patch or you can push through
 yours once the first change hits mainline.

 I think that there will unlikely be any conflict in .37 merge window in 
 this area (and if there were, I'll sort it out).

 So please add

  Acked-by: Jiri Kosina jkos...@suse.cz

 to the hid-input.c bits and feel free to take it through your tree, if it 
 is convenient for you.
 
 It'll conflict a little bith with the tivo slide patch I posted yesterday,
 but mostly just minor context changes. I can redo that patch on top of
 these changes if that's preferred.

I can handle those context changes when merging the patches at linux-next and
when merging upstream. We just need to sync in a way that Dmitry send his patch
series before mine when sending them to Linus, and I'll take care of fixing the
merge conflicts.

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

Re: [PATCH 0/6] Large scancode handling

On Wed, Sep 08, 2010 at 12:15:06PM -0300, Mauro Carvalho Chehab wrote:
 Em 08-09-2010 11:24, Jarod Wilson escreveu:
  On Wed, Sep 08, 2010 at 11:48:50AM +0200, Jiri Kosina wrote:
  On Wed, 8 Sep 2010, Dmitry Torokhov wrote:
 
  Hi Mauro,
 
  I guess I better get off my behind and commit the changes to support large
  scancodes, or they will not make to 2.6.37 either... There isn't much
  changes, except I followed David's suggestion and changed boolean index
  field into u8 flags field. Still, please glance it over once again and
  shout if you see something you do not like.
 
  Jiri, how do you want to handle the changes to HID? I could either push
  them through my tree together with the first patch or you can push through
  yours once the first change hits mainline.
 
  I think that there will unlikely be any conflict in .37 merge window in 
  this area (and if there were, I'll sort it out).
 
  So please add
 
 Acked-by: Jiri Kosina jkos...@suse.cz
 
  to the hid-input.c bits and feel free to take it through your tree, if it 
  is convenient for you.
  
  It'll conflict a little bith with the tivo slide patch I posted yesterday,
  but mostly just minor context changes. I can redo that patch on top of
  these changes if that's preferred.
 
 I can handle those context changes when merging the patches at linux-next and
 when merging upstream. We just need to sync in a way that Dmitry send his 
 patch
 series before mine when sending them to Linus, and I'll take care of fixing 
 the
 merge conflicts.

Ah, the specific conflicts I was referring here are confined to
drivers/hid/hid-input.c, and I sent the patch thinking it would go in via
the hid tree. It *is* for a remote, but its a pure HID device in this
case.

-- 
Jarod Wilson
ja...@redhat.com

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

Re: [PATCH 0/6] Large scancode handling

Em 08-09-2010 04:41, Dmitry Torokhov escreveu:
 Hi Mauro,
 
 I guess I better get off my behind and commit the changes to support large
 scancodes, or they will not make to 2.6.37 either... There isn't much
 changes, except I followed David's suggestion and changed boolean index
 field into u8 flags field. Still, please glance it over once again and
 shout if you see something you do not like.
 
 Jiri, how do you want to handle the changes to HID? I could either push
 them through my tree together with the first patch or you can push through
 yours once the first change hits mainline.
 
 Mauro, the same question goes for media/IR patch.

It seems easier if you apply them on your tree. I'm sure we won't have any
major conflicts, if we don't apply the big ir-rc renaming patch. I'll postpone
such patch to be applied after the merge upstream.

The patches look sane to me.

Acked-by: Mauro Carvalho Chehab mche...@redhat.com

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

Re: [PATCH 7/8] IR: extend ir_raw_event and do refactoring

On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
 Add new event types for timeout  carrier report
 Move timeout handling from ir_raw_event_store_with_filter to
 ir-lirc-codec, where it is really needed.
 Now lirc bridge ensures proper gap handling.
 Extend lirc bridge for carrier  timeout reports

 Note: all new ir_raw_event variables now should be initialized
 like that: DEFINE_IR_RAW_EVENT(ev);

 To clean an existing event, use init_ir_raw_event(ev);

 Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
 ---
  drivers/media/IR/ene_ir.c          |    4 +-
  drivers/media/IR/ir-core-priv.h    |   13 ++-
  drivers/media/IR/ir-jvc-decoder.c  |    5 +-
  drivers/media/IR/ir-lirc-codec.c   |   78 
 +++-
  drivers/media/IR/ir-nec-decoder.c  |    5 +-
  drivers/media/IR/ir-raw-event.c    |   45 +++-
  drivers/media/IR/ir-rc5-decoder.c  |    5 +-
  drivers/media/IR/ir-rc6-decoder.c  |    5 +-
  drivers/media/IR/ir-sony-decoder.c |    5 +-
  drivers/media/IR/mceusb.c          |    3 +-
  drivers/media/IR/streamzap.c       |    8 ++-
  include/media/ir-core.h            |   40 ---
  12 files changed, 153 insertions(+), 63 deletions(-)
...
 @@ -162,22 +164,48 @@ u32 ir_g_keycode_from_table(struct input_dev 
 *input_dev, u32 scancode);
  /* From ir-raw-event.c */

  struct ir_raw_event {
 -       unsigned                        pulse:1;
 -       unsigned                        duration:31;
 +       union {
 +               u32             duration;
 +
 +               struct {
 +                       u32     carrier;
 +                       u8      duty_cycle;
 +               };
 +       };
 +
 +       unsigned                pulse:1;
 +       unsigned                reset:1;
 +       unsigned                timeout:1;
 +       unsigned                carrier_report:1;
  };

I'm generally good with this entire patch, but the union usage looks a
bit odd, as the members aren't of the same size, which is generally
what I've come to expect looking at other code. I'd be inclined to
simply move duty_cycle out of the union and leave just duration and
carrier in it. However, as discussed on irc and upon looking at the
code, we don't actually do anything useful with duty_cycle yet, so
perhaps just cut it out entirely for the moment, and add it later when
its of use.

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

Re: [PATCH 0/6] Large scancode handling

On Wed, Sep 08, 2010 at 10:31:21AM -0400, Jarod Wilson wrote:
 On Wed, Sep 08, 2010 at 12:41:38AM -0700, Dmitry Torokhov wrote:
  Hi Mauro,
  
  I guess I better get off my behind and commit the changes to support large
  scancodes, or they will not make to 2.6.37 either... There isn't much
  changes, except I followed David's suggestion and changed boolean index
  field into u8 flags field. Still, please glance it over once again and
  shout if you see something you do not like.
  
  Jiri, how do you want to handle the changes to HID? I could either push
  them through my tree together with the first patch or you can push through
  yours once the first change hits mainline.
  
  Mauro, the same question goes for media/IR patch.
  
  David, I suppose you still have the winbond remote so you could test
  changes to winbond-cir driver.
 
 This'll be fun. :) David recently posted a patchset that among other
 things, ports winbond-cir over to {ir,rc}-core to the tune of ~700 less
 lines in winbond-cir.c. It also touches a fair amount of core bits, as
 does a patchset posted by Maxim... I suspect this series should probably
 go in first though.
 

Hmm, the only reason for conversion is that I want to do the back
converstion get/setkeycode_new-get/setkeycode sometimes around
2.6.37-rc2. So it should be perfectly fine for David's changes to go in
and I will just drop my patch completely.

  Ville, do you still have the hardware to try our ati_remote2 changes?
 
 If not, I've got the hardware. (Speaking of which, porting ati_remote*
 over to {ir,rc}-core is also on the TODO list, albeit with very very
 low priority at the moment).

Ok, then we'' pencil you in for testing if we do not hear from Ville ;)

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

Re: [PATCH 0/6] Large scancode handling

On Wed, Sep 08, 2010 at 05:25:13PM +0200, Jiri Kosina wrote:
 On Wed, 8 Sep 2010, Jarod Wilson wrote:
 
It'll conflict a little bith with the tivo slide patch I posted 
yesterday,
but mostly just minor context changes. I can redo that patch on top of
these changes if that's preferred.
   
   I can handle those context changes when merging the patches at linux-next 
   and
   when merging upstream. We just need to sync in a way that Dmitry send his 
   patch
   series before mine when sending them to Linus, and I'll take care of 
   fixing the
   merge conflicts.
  
  Ah, the specific conflicts I was referring here are confined to
  drivers/hid/hid-input.c, and I sent the patch thinking it would go in via
  the hid tree. It *is* for a remote, but its a pure HID device in this
  case.
 
 Umm, what patch are you talking about please? I don't seem to have 
 anything from you in my queue.
 

Depending on the extent of the patch in question I could take it through
my tree as well to avoid too much interdependencies between trees at
merge window time...

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

Re: [PATCH 0/6] Large scancode handling

On Wed, Sep 08, 2010 at 11:48:50AM +0200, Jiri Kosina wrote:
 On Wed, 8 Sep 2010, Dmitry Torokhov wrote:
 
  Hi Mauro,
  
  I guess I better get off my behind and commit the changes to support large
  scancodes, or they will not make to 2.6.37 either... There isn't much
  changes, except I followed David's suggestion and changed boolean index
  field into u8 flags field. Still, please glance it over once again and
  shout if you see something you do not like.
  
  Jiri, how do you want to handle the changes to HID? I could either push
  them through my tree together with the first patch or you can push through
  yours once the first change hits mainline.
 
 I think that there will unlikely be any conflict in .37 merge window in 
 this area (and if there were, I'll sort it out).
 
 So please add
 
   Acked-by: Jiri Kosina jkos...@suse.cz
 
 to the hid-input.c bits and feel free to take it through your tree, if it 
 is convenient for you.
 

Thanks Jiri.

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

Re: [PATCH 0/6] Large scancode handling

On Wed, Sep 08, 2010 at 05:25:13PM +0200, Jiri Kosina wrote:
 On Wed, 8 Sep 2010, Jarod Wilson wrote:
 
It'll conflict a little bith with the tivo slide patch I posted 
yesterday,
but mostly just minor context changes. I can redo that patch on top of
these changes if that's preferred.
   
   I can handle those context changes when merging the patches at linux-next 
   and
   when merging upstream. We just need to sync in a way that Dmitry send his 
   patch
   series before mine when sending them to Linus, and I'll take care of 
   fixing the
   merge conflicts.
  
  Ah, the specific conflicts I was referring here are confined to
  drivers/hid/hid-input.c, and I sent the patch thinking it would go in via
  the hid tree. It *is* for a remote, but its a pure HID device in this
  case.
 
 Umm, what patch are you talking about please? I don't seem to have 
 anything from you in my queue.

Gah. I suck. Forgot to cc you on it.

http://www.spinics.net/lists/linux-input/msg11007.html

Can resend and/or bounce you a copy if need be.

-- 
Jarod Wilson
ja...@redhat.com

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

[PATCH] V4L/DVB: rc-core: increase repeat time

As reported by Anton Blanchard an...@samba.org, double IR events on
2.6.36-rc2 and a DViCO FusionHDTV DVB-T Dual Express are happening:

[ 1351.032084] ir_keydown: i2c IR (FusionHDTV): key down event, key 0x0067, 
scancode 0x0051
[ 1351.281284] ir_keyup: keyup key 0x0067

ie one key down event and one key up event 250ms later.

So, we need to increase the repeat timeout, to avoid this bug to hit.

As we're doing it at core, this fix is not needed anymore at dib0700 driver.

Thanks-to: Anton Blanchard an...@samba.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 7e82a9d..d00ef19 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -510,6 +510,13 @@ int __ir_input_register(struct input_dev *input_dev,
   (ir_dev-props  ir_dev-props-driver_type == 
RC_DRIVER_IR_RAW) ?
 in raw mode : );
 
+   /*
+* Default delay of 250ms is too short for some protocols, expecially
+* since the timeout is currently set to 250ms. Increase it to 500ms,
+* to avoid wrong repetition of the keycodes.
+*/
+   input_dev-rep[REP_DELAY] = 500;
+
return 0;
 
 out_event:
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c 
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index fe81834..48397f1 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -673,9 +673,6 @@ static int dib0700_probe(struct usb_interface *intf,
else
dev-props.rc.core.bulk_mode = false;
 
-   /* Need a higher delay, to avoid wrong repeat */
-   dev-rc_input_dev-rep[REP_DELAY] = 500;
-
dib0700_rc_setup(dev);
 
return 0;
-- 
1.7.1

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

[PATCH] V4L/DVB: rc-core: increase repeat time

As reported by Anton Blanchard an...@samba.org, double IR events on
2.6.36-rc2 and a DViCO FusionHDTV DVB-T Dual Express are happening:

[ 1351.032084] ir_keydown: i2c IR (FusionHDTV): key down event, key 0x0067, 
scancode 0x0051
[ 1351.281284] ir_keyup: keyup key 0x0067

ie one key down event and one key up event 250ms later.

So, we need to increase the repeat timeout, to avoid this bug to hit.

As we're doing it at core, this fix is not needed anymore at dib0700 driver.

Thanks-to: Anton Blanchard an...@samba.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 7e82a9d..d00ef19 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -510,6 +510,13 @@ int __ir_input_register(struct input_dev *input_dev,
   (ir_dev-props  ir_dev-props-driver_type == 
RC_DRIVER_IR_RAW) ?
 in raw mode : );
 
+   /*
+* Default delay of 250ms is too short for some protocols, expecially
+* since the timeout is currently set to 250ms. Increase it to 500ms,
+* to avoid wrong repetition of the keycodes.
+*/
+   input_dev-rep[REP_DELAY] = 500;
+
return 0;
 
 out_event:
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c 
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index fe81834..48397f1 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -673,9 +673,6 @@ static int dib0700_probe(struct usb_interface *intf,
else
dev-props.rc.core.bulk_mode = false;
 
-   /* Need a higher delay, to avoid wrong repeat */
-   dev-rc_input_dev-rep[REP_DELAY] = 500;
-
dib0700_rc_setup(dev);
 
return 0;
-- 
1.7.1

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

Re: IR code autorepeat issue?

Em 29-08-2010 12:44, Mauro Carvalho Chehab escreveu:
 Em 29-08-2010 03:40, Anton Blanchard escreveu:

 I'm seeing double IR events on 2.6.36-rc2 and a DViCO FusionHDTV DVB-T Dual
 Express.
 There's one issue on touching on this constant: it is currently just one 
 global 
 timeout value that will be used by all protocols. This timeout should be 
 enough to
 retrieve and proccess the repeat key event on all protocols, and on all 
 devices, or 
 we'll need to do a per-protocol (and eventually per device) timeout init. 
 From 
 http://www.sbprojects.com/knowledge/ir/ir.htm, we see that NEC prococol uses 
 110 ms
 for repeat code, and we need some aditional time to wake up the decoding 
 task. I'd
 say that anything lower than 150-180ms would risk to not decode repeat events 
 with
 NEC.
 
 I got exactly the same problem when adding RC CORE support at the dib0700 
 driver. At
 that driver, there's an additional time of sending/receiving URB's from USB. 
 So, we
 probably need a higher timeout. Even so, I tried to reduce the timeout to 
 200ms or 150ms 
 (not sure), but it didn't work. So, I ended by just patching the dibcom 
 driver to do 
 dev-rep[REP_DELAY] = 500:

Ok, just sent a patch adding it to rc-core, and removing from dib0700 driver.

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

Re: [PATCH] Illuminators and status LED controls

On Wed, 2010-09-08 at 10:59 +0300, Eduardo Valentin wrote:
 Hello,
 
 On Wed, Sep 08, 2010 at 04:16:48AM +0200, ext Eino-Ville Talvala wrote:
  
   This is probably a bit OT, but these sorts of indicator LEDs can get quite 
  complicated.
  
  As part of our FCamera sample program on the Nokia N900 (which uses
 V4L2 way down there), we wanted to reprogram the front indicator LED
 to flash exactly when a picture is taken.
   The N900 front LED is quite a programmable beast [1], with a
 dedicated microcontroller (the lp5521) that runs little programs that
 define the blink patterns for the RGB LED.
  
  I'm not really suggesting that the V4L2 control should be able to
 handle this sort of an LED, but as these sorts of things get cheaper,
 it may become a case of 'why not?' for manufacturers putting in more
 complex RGB LEDs.   And if you don't want to encapsulate all that in
 V4L2, it may be better to leave it to other APIs at some point of
 complexity (the current lp5521 driver seems to have a sysfs-only
 interface for now for the programmable patterns, and the standard LED
 API otherwise)
  
  [1] http://wiki.maemo.org/LED_patterns
 
 Well, that's exactly why duplicating API's is usually a bad idea. If
 the thing start to get complex, having only one place to hold
 the mess is better than keeping it into two (or more) different
 places. This will become worst and worst. I mean, why do we want two
 different APIs to control same stuff?

For the case when requiring an application to use two separate APIs adds
more complexity for application developer than it alleviates.

Let's be more specific about stuff that may need to be controlled:

1. Illuminators with control lines directly tied to a camera's bridge or
sensor chip

2. Simple status LEDs tied directly to a camera's bridge or sensor chip
(maybe with a simple hardware assisted blink)

3. Generically connected LEDs (some platform GPIO chip or
microcontroller somewhere) with blinking or PWM intensity under CPU or
microcontroller control.

Number 1  2 above certainly apply to consumer desktop devices.

Number 3 is likely common on embedded devices.



Incandescent and Halogen lamps that effect an image coming into a camera
are *not* LEDs that blink or flash automatically based on driver or
system trigger events.  They are components of a video capture system
with which a human attempts to adjust the appearance of an image of a
subject by changing the subject's environment.  These illuminators are
not some generically connected device, but controlled by GPIO's on the
camera's bridge or sensor chip itself.  Such an illuminator will
essentially be used only in conjunction with the camera.

Status LEDs integrated into webcam devices that are not generically
connected devices but controlled with GPIOs on the camera's bridge or
sensor chip will also essentially be used only in conjunction with the
camera.

Turning these sorts camera specific illuminators and LEDs on an off
should be as simple to implement for an application developer as it is
to grasp the concept of turning a light bulb on and off.


The LED interface seems more appropriate to use when the LEDs are
connected more generically and will likely be used more generically,
such as in an embedded system.



 And yes, application developers must use the correct API to control
 stuff.

  Why should kernel duplicate interfaces just because
 user land don't want to use two different interfaces? Doesn't this sound a 
 bit ... strange at least?

Why should the kernel push multiple APIs on application developers to
control a complex federation of small devices all connected behind a
single bridge chip, which the user perceives as a single device?  (BTW a
USB microscope is such a federation which doesn't work at all without
proper subject illumination.)

V4L2 controls are how desktop V4L2 applications currently control
aspects of a incoming image.  Forcing the use of the LED interface in
sysfs to control one aspect of that would be a departure from the norm
for the existing V4L2 desktop applications.

Forcing the use of the LED interface also brings along the complication
of proper association of the illuminator or LED sysfs control node to
the proper video capture/control device node.  I have a laptop with a
built in webcam with a status LED and a USB connected microscope with
two illuminators.  What are the steps for an application to discover the
correct light for the video device and what settings that light is
capable of: using V4L2 controls? using the LED interface?

With the V4L2 controls, association to the correct video devices is no
effort, and current v4l2 control handling code in applications like
v4l2-ctl and qv4l2 can discover the controls and their metadata and
present the control in a UI with no changes to the application.

How does one go about associating LEDs and Illuminators to video device
nodes using the LED sysfs interface?  I'm betting it's not as simple for
applications that use V4L2

Re: [PATCH 7/8] IR: extend ir_raw_event and do refactoring

On Wed, 2010-09-08 at 11:26 -0400, Jarod Wilson wrote:
 On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky maximlevit...@gmail.com 
 wrote:
  Add new event types for timeout  carrier report
  Move timeout handling from ir_raw_event_store_with_filter to
  ir-lirc-codec, where it is really needed.
  Now lirc bridge ensures proper gap handling.
  Extend lirc bridge for carrier  timeout reports
 
  Note: all new ir_raw_event variables now should be initialized
  like that: DEFINE_IR_RAW_EVENT(ev);
 
  To clean an existing event, use init_ir_raw_event(ev);
 
  Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
  ---
   drivers/media/IR/ene_ir.c  |4 +-
   drivers/media/IR/ir-core-priv.h|   13 ++-
   drivers/media/IR/ir-jvc-decoder.c  |5 +-
   drivers/media/IR/ir-lirc-codec.c   |   78 
  +++-
   drivers/media/IR/ir-nec-decoder.c  |5 +-
   drivers/media/IR/ir-raw-event.c|   45 +++-
   drivers/media/IR/ir-rc5-decoder.c  |5 +-
   drivers/media/IR/ir-rc6-decoder.c  |5 +-
   drivers/media/IR/ir-sony-decoder.c |5 +-
   drivers/media/IR/mceusb.c  |3 +-
   drivers/media/IR/streamzap.c   |8 ++-
   include/media/ir-core.h|   40 ---
   12 files changed, 153 insertions(+), 63 deletions(-)
 ...
  @@ -162,22 +164,48 @@ u32 ir_g_keycode_from_table(struct input_dev 
  *input_dev, u32 scancode);
   /* From ir-raw-event.c */
 
   struct ir_raw_event {
  -   unsignedpulse:1;
  -   unsignedduration:31;
  +   union {
  +   u32 duration;
  +
  +   struct {
  +   u32 carrier;
  +   u8  duty_cycle;
  +   };
  +   };
  +
  +   unsignedpulse:1;
  +   unsignedreset:1;
  +   unsignedtimeout:1;
  +   unsignedcarrier_report:1;
   };
 
 I'm generally good with this entire patch, but the union usage looks a
 bit odd, as the members aren't of the same size, which is generally
 what I've come to expect looking at other code.

Having a union with different sized members is perfectly valid C code. 

Just look at the definition of the XEvent in Xlib.h.  The int type; is
smaller than everything, and the XAnyEvent is smaller than the other
event types.

The size of the union will be the size of its largest member.



  I'd be inclined to
 simply move duty_cycle out of the union and leave just duration and
 carrier in it.

That's not necessary and it could be confusing depending on where you
put duty_cycle.

Regards,
Andy

  However, as discussed on irc and upon looking at the
 code, we don't actually do anything useful with duty_cycle yet, so
 perhaps just cut it out entirely for the moment, and add it later when
 its of use.
 


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

Re: [PATCH 0/6] Large scancode handling

On Wed, Sep 08, 2010 at 12:09:08PM -0400, Jarod Wilson wrote:
 On Wed, Sep 08, 2010 at 05:25:13PM +0200, Jiri Kosina wrote:
  On Wed, 8 Sep 2010, Jarod Wilson wrote:
  
 It'll conflict a little bith with the tivo slide patch I posted 
 yesterday,
 but mostly just minor context changes. I can redo that patch on top of
 these changes if that's preferred.

I can handle those context changes when merging the patches at 
linux-next and
when merging upstream. We just need to sync in a way that Dmitry send 
his patch
series before mine when sending them to Linus, and I'll take care of 
fixing the
merge conflicts.
   
   Ah, the specific conflicts I was referring here are confined to
   drivers/hid/hid-input.c, and I sent the patch thinking it would go in via
   the hid tree. It *is* for a remote, but its a pure HID device in this
   case.
  
  Umm, what patch are you talking about please? I don't seem to have 
  anything from you in my queue.
 
 Gah. I suck. Forgot to cc you on it.
 
 http://www.spinics.net/lists/linux-input/msg11007.html
 
 Can resend and/or bounce you a copy if need be.
 

Hmm, I do not see anything in there that would conflict with my
changes...

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

Re: [PATCH 0/6] Large scancode handling

On Wed, Sep 08, 2010 at 09:56:07AM -0700, Dmitry Torokhov wrote:
 On Wed, Sep 08, 2010 at 12:09:08PM -0400, Jarod Wilson wrote:
  On Wed, Sep 08, 2010 at 05:25:13PM +0200, Jiri Kosina wrote:
   On Wed, 8 Sep 2010, Jarod Wilson wrote:
   
  It'll conflict a little bith with the tivo slide patch I posted 
  yesterday,
  but mostly just minor context changes. I can redo that patch on top 
  of
  these changes if that's preferred.
 
 I can handle those context changes when merging the patches at 
 linux-next and
 when merging upstream. We just need to sync in a way that Dmitry send 
 his patch
 series before mine when sending them to Linus, and I'll take care of 
 fixing the
 merge conflicts.

Ah, the specific conflicts I was referring here are confined to
drivers/hid/hid-input.c, and I sent the patch thinking it would go in 
via
the hid tree. It *is* for a remote, but its a pure HID device in this
case.
   
   Umm, what patch are you talking about please? I don't seem to have 
   anything from you in my queue.
  
  Gah. I suck. Forgot to cc you on it.
  
  http://www.spinics.net/lists/linux-input/msg11007.html
  
  Can resend and/or bounce you a copy if need be.
  
 
 Hmm, I do not see anything in there that would conflict with my
 changes...

Sorry, yeah, it *should* be solely context conflicts due to line offsets
and other misc drift, no functional conflicts with your changes.


-- 
Jarod Wilson
ja...@redhat.com

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

Re: [linux-dvb] [Patch] Correct Signal Strength values for STB0899

2010-09-08 Thread Goga777

 first of all I have to say that this patch is not from me.
 It's from rotor-0.1.4mh-v1.2.tar.gz
 Thx to the author of that patch and the modified rotor Plugin. I think he's a 
 friend of Mike Booth
 
 I think it should be included into s2-liplianin.
 With this patch all dvb-s and dvb-s2 signal strength values are scaled 
 correctly.


FYI - this patch from Russian DVB VDR forum. Author is dimka_9
http://linuxdvb.org.ru/wbb/index.php?page=ThreadpostID=11883#post11883


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

Re: [linux-dvb] [Patch] Correct Signal Strength values for STB0899

2010-09-08 Thread Newsy Paper

thx Goga and thx to dimka_9 for his great work.

I hope those guys will include it in the driver

regards

Newsy

--- Goga777 goga...@bk.ru schrieb am Mi, 8.9.2010:

 Von: Goga777 goga...@bk.ru
 Betreff: Re: [linux-dvb] [Patch] Correct Signal Strength values for STB0899
 An: linux-...@linuxtv.org
 CC: linux-media@vger.kernel.org
 Datum: Mittwoch, 8. September, 2010 19:47 Uhr
  first of all I have to say that
 this patch is not from me.
  It's from rotor-0.1.4mh-v1.2.tar.gz
  Thx to the author of that patch and the modified rotor
 Plugin. I think he's a friend of Mike Booth
  
  I think it should be included into s2-liplianin.
  With this patch all dvb-s and dvb-s2 signal strength
 values are scaled correctly.
 
 
 FYI - this patch from Russian DVB VDR forum. Author is
 dimka_9
 http://linuxdvb.org.ru/wbb/index.php?page=ThreadpostID=11883#post11883
 
 
 Goga
 
 ___
 linux-dvb users mailing list
 For V4L/DVB development, please use instead linux-media@vger.kernel.org
 linux-...@linuxtv.org
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
 


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

Re: [linux-dvb] [Patch] Correct Signal Strength values for STB0899

2010-09-08 Thread Goga777

Приветствую, Newsy

no, I'm not author of patch , no need to include me in drivers.

btw - can anybody else test this patch ? Igor Liplianin is waiting for 
additional feedback 

Goga


 thx Goga and thx to dimka_9 for his great work.
 
 I hope those guys will include it in the driver
 
 regards
 
 Newsy
 
 --- Goga777 goga...@bk.ru schrieb am Mi, 8.9.2010:
 
  Von: Goga777 goga...@bk.ru
  Betreff: Re: [linux-dvb] [Patch] Correct Signal Strength values for STB0899
  An: linux-...@linuxtv.org
  CC: linux-media@vger.kernel.org
  Datum: Mittwoch, 8. September, 2010 19:47 Uhr
   first of all I have to say that
  this patch is not from me.
   It's from rotor-0.1.4mh-v1.2.tar.gz
   Thx to the author of that patch and the modified rotor
  Plugin. I think he's a friend of Mike Booth
   
   I think it should be included into s2-liplianin.
   With this patch all dvb-s and dvb-s2 signal strength
  values are scaled correctly.
  
  
  FYI - this patch from Russian DVB VDR forum. Author is
  dimka_9
  http://linuxdvb.org.ru/wbb/index.php?page=ThreadpostID=11883#post11883
--
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

Kernel Oops with Kernel 2.6.32

2010-09-08 Thread Christoph Pleger

Hello,

I am running a Debian 2.6.32-Kernel (which by the way contains a lot of 
unresolved symbols in many dvb modules). As this kernel does not support my 
WinTV Nova-T USB-Stick, I downloaded the latest sources via the web interface 
from linuxtv.org, compiled the sources and installed the resulting modules.

When I now connect the USB stick, the DVB modules are loaded correctly, but 
when I start an application to watch TV, I get a Kernel Oops.

These lines from my kern.log show the kernel actions when connecting the 
device:

 Sep  8 19:51:16 superstar kernel: [ 3480.084012] usb 2-5: new high speed USB 
device using ehci_hcd and address 3
Sep  8 19:51:16 superstar kernel: [ 3480.217755] usb 2-5: New USB device 
found, idVendor=2040, idProduct=7050
Sep  8 19:51:16 superstar kernel: [ 3480.217758] usb 2-5: New USB device 
strings: Mfr=1, Product=2, SerialNumber=3
Sep  8 19:51:16 superstar kernel: [ 3480.217760] usb 2-5: Product: Nova-T 
Stick
Sep  8 19:51:16 superstar kernel: [ 3480.217761] usb 2-5: Manufacturer: 
Hauppauge
Sep  8 19:51:16 superstar kernel: [ 3480.217762] usb 2-5: SerialNumber: 
00
Sep  8 19:51:16 superstar kernel: [ 3480.217849] usb 2-5: configuration #1 
chosen from 1 choice
Sep  8 19:51:16 superstar kernel: [ 3480.332785] dib0700: loaded with support 
for 14 different device-types
Sep  8 19:51:16 superstar kernel: [ 3480.333846] dvb-usb: found a 'Hauppauge 
Nova-T Stick' in cold state, will try to load a firmware
Sep  8 19:51:16 superstar kernel: [ 3480.333851] usb 2-5: firmware: requesting 
dvb-usb-dib0700-1.20.fw
Sep  8 19:51:16 superstar kernel: [ 3480.439083] dvb-usb: downloading firmware 
from file 'dvb-usb-dib0700-1.20.fw'
Sep  8 19:51:17 superstar kernel: [ 3480.640502] dib0700: firmware started 
successfully.
Sep  8 19:51:17 superstar kernel: [ 3481.144141] dvb-usb: found a 'Hauppauge 
Nova-T Stick' in warm state.
Sep  8 19:51:17 superstar kernel: [ 3481.144540] dvb-usb: will pass the 
complete MPEG2 transport stream to the software demuxer.
Sep  8 19:51:17 superstar kernel: [ 3481.144639] DVB: registering new adapter 
(Hauppauge Nova-T Stick)
Sep  8 19:51:17 superstar kernel: [ 3481.480505] DVB: registering adapter 0 
frontend 0 (DiBcom 7000MA/MB/PA/PB/MC)...
Sep  8 19:51:17 superstar kernel: [ 3481.498377] MT2060: successfully 
identified (IF1 = 1218)
Sep  8 19:51:18 superstar kernel: [ 3481.975455] input: IR-receiver inside an 
USB DVB receiver as /devices/pci:00/:00:02.1/usb2/2-5/input/input6
Sep  8 19:51:18 superstar kernel: [ 3481.975500] dvb-usb: schedule remote 
query interval to 50 msecs.
Sep  8 19:51:18 superstar kernel: [ 3481.975503] dvb-usb: Hauppauge Nova-T 
Stick successfully initialized and connected.
Sep  8 19:51:18 superstar kernel: [ 3481.975777] usbcore: registered new 
interface driver dvb_usb_dib0700


These lines from my kern.log show the Oops event:
Sep  8 19:51:28 superstar kernel: [ 3492.321914] BUG: unable to handle kernel 
NULL pointer dereference at 0012
Sep  8 19:51:28 superstar kernel: [ 3492.321920] IP: [a015e3db] 
i2c_transfer+0x1c/0xc0 [i2c_core]
Sep  8 19:51:28 superstar kernel: [ 3492.321928] PGD 1b8e69067 PUD 1b8e6a067 
PMD 0
Sep  8 19:51:28 superstar kernel: [ 3492.321932] Oops:  [#1] SMP
Sep  8 19:51:28 superstar kernel: [ 3492.321934] last sysfs 
file: /sys/devices/pci:00/:00:02.1/usb2/2-5/input/input6/capabilities/sw
Sep  8 19:51:28 superstar kernel: [ 3492.321936] CPU 0
Sep  8 19:51:28 superstar kernel: [ 3492.321938] Modules linked in: mt2060 
dvb_usb_dib0700 dib7000p dib0090 dib7000m dib0070 dvb_usb dib8000 dvb_core 
dib30
00mc dibx000_common fglrx(P) binfmt_misc rfcomm l2cap crc16 bluetooth rfkill 
vboxnetadp vboxnetflt vboxdrv battery ppdev lp ext3 jbd mbcache xfs exportfs 
r
eiserfs hwmon_vid eeprom firewire_sbp2 firewire_core crc_itu_t loop 
snd_hda_codec_atihdmi parport_pc parport psmouse evdev serio_raw 
snd_emu10k1_synth snd_
emux_synth snd_seq_virmidi snd_seq_midi_emul snd_hda_intel snd_hda_codec 
snd_emu10k1 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_seq_midi 
snd_pcm
 snd_rawmidi snd_util_mem asus_atk0110 snd_seq_midi_event snd_hwdep snd_seq 
snd_timer snd_seq_device emu10k1_gp pcspkr gameport snd snd_page_alloc 
soundcor
e k8temp edac_core edac_mce_amd button processor i2c_nforce2 i2c_core jfs 
dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sg sr_mod cdrom sd_mod 
crc_t10
dif ata_generic floppy fan pata_amd sata_nv ehci_hcd ohci_hcd libata thermal 
forcedeth thermal_sys scsi_mod usbcore nls_base [last unloaded: 
scsi_wait_scan
]
Sep  8 19:51:28 superstar kernel: [ 3492.321984] Pid: 26841, comm: kaffeine 
Tainted: P   2.6.32-bpo.5-amd64 #1 System Product Name
Sep  8 19:51:28 superstar kernel: [ 3492.321986] RIP: 0010:
[a015e3db]  [a015e3db] i2c_transfer+0x1c/0xc0 [i2c_core]
Sep  8 19:51:28 superstar kernel: [ 3492.321990] RSP: 0018:8801b95d9ba8  
EFLAGS: 00010292
Sep  8 19:51:28 superstar kernel: [ 3492.321992] RAX: 8801b95d9c08

Re: [PATCH v9 1/4] V4L2: Add seek spacing and FM RX class.

Em 30-08-2010 08:38, Matti J. Aaltonen escreveu:
 Add spacing field to v4l2_hw_freq_seek, add V4L2_CAP_RAW_RDS_ONLY
 to driver capabilities and also add FM RX class to control classes.
 
 Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
 ---
  drivers/media/video/v4l2-ctrls.c |   12 
  include/linux/videodev2.h|   16 +++-
  2 files changed, 27 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/media/video/v4l2-ctrls.c 
 b/drivers/media/video/v4l2-ctrls.c
 index ea8d32c..15749f1 100644
 --- a/drivers/media/video/v4l2-ctrls.c
 +++ b/drivers/media/video/v4l2-ctrls.c
 @@ -216,6 +216,12 @@ const char **v4l2_ctrl_get_menu(u32 id)
   75 useconds,
   NULL,
   };
 + static const char *fm_band[] = {
 + 87.5 - 108. MHz,
 + 76. - 90. MHz, Japan,
 + 65. - 74. MHz, OIRT,
 + NULL,
 + };
  
   switch (id) {
   case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
 @@ -256,6 +262,8 @@ const char **v4l2_ctrl_get_menu(u32 id)
   return colorfx;
   case V4L2_CID_TUNE_PREEMPHASIS:
   return tune_preemphasis;
 + case V4L2_CID_FM_BAND:
 + return fm_band;
   default:
   return NULL;
   }
 @@ -386,6 +394,8 @@ const char *v4l2_ctrl_get_name(u32 id)
   case V4L2_CID_TUNE_PREEMPHASIS: return Pre-emphasis settings;
   case V4L2_CID_TUNE_POWER_LEVEL: return Tune Power Level;
   case V4L2_CID_TUNE_ANTENNA_CAPACITOR:   return Tune Antenna Capacitor;
 + case V4L2_CID_FM_RX_CLASS:  return FM Radio Tuner 
 Controls;

 + case V4L2_CID_FM_BAND:  return FM Band;


There's no need for a FM control, as there's already an ioctl pair that allows 
get/set the frequency
bandwidth: VIDIOC_S_TUNER and VIDIOC_G_TUNER. So, the entire patch here seems 
uneeded/unwanted.
  
   default:
   return NULL;
 @@ -448,6 +458,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
 v4l2_ctrl_type *type,
   case V4L2_CID_EXPOSURE_AUTO:
   case V4L2_CID_COLORFX:
   case V4L2_CID_TUNE_PREEMPHASIS:
 + case V4L2_CID_FM_BAND:
   *type = V4L2_CTRL_TYPE_MENU;
   break;
   case V4L2_CID_RDS_TX_PS_NAME:
 @@ -458,6 +469,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
 v4l2_ctrl_type *type,
   case V4L2_CID_CAMERA_CLASS:
   case V4L2_CID_MPEG_CLASS:
   case V4L2_CID_FM_TX_CLASS:
 + case V4L2_CID_FM_RX_CLASS:
   *type = V4L2_CTRL_TYPE_CTRL_CLASS;
   /* You can neither read not write these */
   *flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
 diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
 index 61490c6..7d6511e 100644
 --- a/include/linux/videodev2.h
 +++ b/include/linux/videodev2.h
 @@ -244,6 +244,7 @@ struct v4l2_capability {
  #define V4L2_CAP_VIDEO_OUTPUT_OVERLAY0x0200  /* Can do video 
 output overlay */
  #define V4L2_CAP_HW_FREQ_SEEK0x0400  /* Can do hardware 
 frequency seek  */
  #define V4L2_CAP_RDS_OUTPUT  0x0800  /* Is an RDS encoder */
 +#define V4L2_CAP_RAW_RDS_ONLY0x1000  /* Does not 
 interpret RDS data */
  
  #define V4L2_CAP_TUNER   0x0001  /* has a tuner */
  #define V4L2_CAP_AUDIO   0x0002  /* has audio 
 support */
 @@ -930,6 +931,7 @@ struct v4l2_ext_controls {
  #define V4L2_CTRL_CLASS_MPEG 0x0099  /* MPEG-compression controls */
  #define V4L2_CTRL_CLASS_CAMERA 0x009a/* Camera class controls */
  #define V4L2_CTRL_CLASS_FM_TX 0x009b /* FM Modulator control class */
 +#define V4L2_CTRL_CLASS_FM_RX 0x009c /* FM Tuner control class */
  
  #define V4L2_CTRL_ID_MASK  (0x0fff)
  #define V4L2_CTRL_ID2CLASS(id)((id)  0x0fffUL)
 @@ -1328,6 +1330,17 @@ enum v4l2_preemphasis {
  #define V4L2_CID_TUNE_POWER_LEVEL(V4L2_CID_FM_TX_CLASS_BASE + 
 113)
  #define V4L2_CID_TUNE_ANTENNA_CAPACITOR  
 (V4L2_CID_FM_TX_CLASS_BASE + 114)
  
 +/* FM Tuner class control IDs */
 +#define V4L2_CID_FM_RX_CLASS_BASE(V4L2_CTRL_CLASS_FM_RX | 0x900)
 +#define V4L2_CID_FM_RX_CLASS (V4L2_CTRL_CLASS_FM_RX | 1)
 +
 +#define V4L2_CID_FM_BAND (V4L2_CID_FM_RX_CLASS_BASE + 1)
 +enum v4l2_fm_band {
 + V4L2_FM_BAND_OTHER  = 0,
 + V4L2_FM_BAND_JAPAN  = 1,
 + V4L2_FM_BAND_OIRT   = 2
 +};
 +
  /*
   *   T U N I N G
   */
 @@ -1392,7 +1405,8 @@ struct v4l2_hw_freq_seek {
   enum v4l2_tuner_type  type;
   __u32 seek_upward;
   __u32 wrap_around;
 - __u32 reserved[8];
 + __u32 spacing;
 + __u32 reserved[7];
  };
  
  /*

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a

Re: [PATCH v9 4/4] Documentation: v4l: Add hw_seek spacing and FM_RX class

Em 30-08-2010 08:38, Matti J. Aaltonen escreveu:
 Add a couple of words about the spacing field in the HW seek struct,
 about the V4L2_CAP_RAW_RDS_ONLY capability flag and about the
 new FM RX control class.

Same comment as patch 1/4: FM bandwidth can already be defined via 
VIDIOC_[G|S]_TUNER.
So, this patch is just creating a duplicated API for something already defined.

 
 Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
 ---
  Documentation/DocBook/v4l/controls.xml |   71 
 
  Documentation/DocBook/v4l/dev-rds.xml  |5 ++
  .../DocBook/v4l/vidioc-s-hw-freq-seek.xml  |   10 ++-
  3 files changed, 84 insertions(+), 2 deletions(-)
 
 diff --git a/Documentation/DocBook/v4l/controls.xml 
 b/Documentation/DocBook/v4l/controls.xml
 index 8408caa..e9512eb 100644
 --- a/Documentation/DocBook/v4l/controls.xml
 +++ b/Documentation/DocBook/v4l/controls.xml
 @@ -2088,6 +2088,77 @@ manually or automatically if set to zero. Unit, range 
 and step are driver-specif
  paraFor more details about RDS specification, refer to
  xref linkend=en50067 / document, from CENELEC./para
  /section
 +section id=fm-rx-controls
 +  titleFM Tuner Control Reference/title
 +
 +  paraThe FM Tuner (FM_RX) class includes controls for common features 
 of
 +devices that are capable of receiving FM transmissions. Currently this class 
 includes a parameter
 +defining the FM radio band being used./para
 +
 +  table pgwide=1 frame=none id=fm-rx-control-id
 +  titleFM_RX Control IDs/title
 +
 +  tgroup cols=4
 + colspec colname=c1 colwidth=1* /
 + colspec colname=c2 colwidth=6* /
 + colspec colname=c3 colwidth=2* /
 + colspec colname=c4 colwidth=6* /
 + spanspec namest=c1 nameend=c2 spanname=id /
 + spanspec namest=c2 nameend=c4 spanname=descr /
 + thead
 +   row
 + entry spanname=id align=leftID/entry
 + entry align=leftType/entry
 +   /rowrow rowsep=1entry spanname=descr 
 align=leftDescription/entry
 +   /row
 + /thead
 + tbody valign=top
 +   rowentry/entry/row
 +   row
 + entry 
 spanname=idconstantV4L2_CID_FM_RX_CLASS/constantnbsp;/entry
 + entryclass/entry
 +   /rowrowentry spanname=descrThe FM_RX class
 +descriptor. Calling VIDIOC-QUERYCTRL; for this control will return a
 +description of this control class./entry
 +   /row
 +   row
 + entry 
 spanname=idconstantV4L2_CID_FM_RX_BAND/constantnbsp;/entry
 + entryinteger/entry
 +   /row
 +   row id=v4l2-fm_rx_bandentry spanname=descrConfigures the FM 
 radio
 +frequency range being used. Currently there are three bands in use, see  
 ulink
 +url=http://en.wikipedia.org/wiki/FM_broadcasting;Wikipedia/ulink.
 +Usually 87.5 to 108.0 MHz is used, or some portion thereof, with a few 
 exceptions:
 +In Japan, the band 76-90 MHz is used and in the former Soviet republics
 +and some Eastern European countries, the older 65-74 MHz band,
 +referred also to as the OIRT band, is still used.
 +
 +The enumnbsp; v4l2_fm_rx_band defines possible values for the FM band. They 
 are:/entry
 + /rowrow
 + entrytbl spanname=descr cols=2
 +   tbody valign=top
 + row
 +   
 entryconstantV4L2_FM_BAND_OTHER/constantnbsp;/entry
 +   entryFrequencies from 87.5 to 108.0 MHz/entry
 + /row
 + row
 +   
 entryconstantV4L2_FM_BAND_JAPAN/constantnbsp;/entry
 +   entryfrom 65 to 74 MHz/entry
 + /row
 + row
 +   
 entryconstantV4L2_FM_BAND_OIRT/constantnbsp;/entry
 +   entryfrom 65 to 74 MHz/entry
 + /row
 +   /tbody
 + /entrytbl
 +
 +   /row
 +   rowentry/entry/row
 + /tbody
 +  /tgroup
 +  /table
 +
 +/section
  /section
  
!--
 diff --git a/Documentation/DocBook/v4l/dev-rds.xml 
 b/Documentation/DocBook/v4l/dev-rds.xml
 index 0869d70..39c89c2 100644
 --- a/Documentation/DocBook/v4l/dev-rds.xml
 +++ b/Documentation/DocBook/v4l/dev-rds.xml
 @@ -42,6 +42,11 @@ field of v4l2-modulator;.
  In order to enable the RDS transmission one must set the 
 constantV4L2_TUNER_SUB_RDS/constant
  bit in the structfieldtxsubchans/structfield field of 
 v4l2-modulator;./para
  
 +paraDevices capable of only passing through raw uninterpreted RDS data
 +set the flags as described above and in addition
 +set the constantV4L2_CAP_RAW_RDS_ONLY/constant flag in
 +the structfieldcapabilities/structfield field of v4l2-capability;
 +returned by the VIDIOC-QUERYCAP; ioctl./para
/section
  
section
 diff --git a/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml 
 b/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml
 index 14b3ec7..c30dcc4 100644
 --- a/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml
 +++ b/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml

Re: [PATCH v9 2/4] MFD: WL1273 FM Radio: MFD driver for the FM radio.

Em 30-08-2010 08:38, Matti J. Aaltonen escreveu:
 This is a parent for two child drivers: a V4L2 driver and
 an ALSA codec driver. The MFD part implements I2C communication
 to the device and provides a couple of functions that are called
 from both children.
 
 Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
 ---
  drivers/mfd/wl1273-core.c   |  612 
 +++
  include/linux/mfd/wl1273-core.h |  314 
 2 files changed, 926 insertions(+), 0 deletions(-)
  create mode 100644 drivers/mfd/wl1273-core.c
  create mode 100644 include/linux/mfd/wl1273-core.h
 
 diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
 new file mode 100644
 index 000..9fa3850
 --- /dev/null
 +++ b/drivers/mfd/wl1273-core.c
 @@ -0,0 +1,612 @@
 +/*
 + * MFD driver for wl1273 FM radio and audio codec submodules.
 + *
 + * Author:   Matti Aaltonen matti.j.aalto...@nokia.com
 + *
 + * Copyright:   (C) 2010 Nokia Corporation
 + *
 + * 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.
 + *
 + * 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., 51 Franklin St, Fifth Floor, Boston, MA
 + * 02110-1301 USA
 + *
 + */
 +
 +#include linux/delay.h
 +#include linux/interrupt.h
 +#include linux/mfd/wl1273-core.h
 +#include linux/slab.h
 +#include media/v4l2-common.h
 +
 +#define DRIVER_DESC WL1273 FM Radio Core
 +
 +#define WL1273_IRQ_MASK   (WL1273_FR_EVENT   |   \
 +   WL1273_POW_ENB_EVENT)
 +
 +static const struct band_info bands[] = {
 + /* USA  Europe */
 + {
 + .bottom_frequency   = 87500,
 + .top_frequency  = 108000,
 + .band   = V4L2_FM_BAND_OTHER,
 + },
 + /* Japan */
 + {
 + .bottom_frequency   = 76000,
 + .top_frequency  = 9,
 + .band   = V4L2_FM_BAND_JAPAN,
 + },
 +};
 +
 +/*
 + * static unsigned char radio_band - Band
 + *
 + * The bands are 0 == USA-Europe, 1 == Japan. USA-Europe is the default.
 + */
 +static unsigned char radio_band;
 +module_param(radio_band, byte, 0);
 +MODULE_PARM_DESC(radio_band, Band: 0=USA-Europe, 1=Japan);

There's no need for a parameter to set the bandwidth.

 +
 +/*
 + * static unsigned int rds_buf - the number of RDS buffer blocks used.
 + *
 + * The default number is 100.
 + */
 +static unsigned int rds_buf = 100;
 +module_param(rds_buf, uint, 0);
 +MODULE_PARM_DESC(rds_buf, RDS buffer entries: *100*);

Hmm... it would be better to use, instead:

MODULE_PARM_DESC(rds_buf, Number of RDS buffer entries. Default = 100);

 +
 +int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
 +{
 + struct i2c_client *client = core-i2c_dev;
 + u8 b[2];
 + int r;
 +
 + r = i2c_smbus_read_i2c_block_data(client, reg, 2, b);
 + if (r != 2) {
 + dev_err(client-dev, %s: Read: %d fails.\n, __func__, reg);
 + return -EREMOTEIO;
 + }
 +
 + *value = (u16)b[0]  8 | b[1];
 +
 + return 0;
 +}
 +EXPORT_SYMBOL(wl1273_fm_read_reg);

Hmm... why do you need to export a symbol here? 

 +
 +int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
 +{
 + struct i2c_client *client = core-i2c_dev;
 + u8 buf[] = { (param  8)  0xff, param  0xff };
 + int r;
 +
 + r = i2c_smbus_write_i2c_block_data(client, cmd, 2, buf);
 + if (r) {
 + dev_err(client-dev, %s: Cmd: %d fails.\n, __func__, cmd);
 + return r;
 + }
 +
 + return 0;
 +}
 +EXPORT_SYMBOL(wl1273_fm_write_cmd);

Hmm... why do you need to export a symbol here? 

 +
 +int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
 +{
 + struct i2c_client *client = core-i2c_dev;
 + struct i2c_msg msg[1];
 + int r;
 +
 + msg[0].addr = client-addr;
 + msg[0].flags = 0;
 + msg[0].buf = data;
 + msg[0].len = len;
 +
 + r = i2c_transfer(client-adapter, msg, 1);
 +
 + if (r != 1) {
 + dev_err(client-dev, %s: write error.\n, __func__);
 + return -EREMOTEIO;
 + }
 +
 + return 0;
 +}
 +EXPORT_SYMBOL(wl1273_fm_write_data);

Hmm... why do you need to export a symbol here? 

 +
 +/**
 + * wl1273_fm_set_audio() -   Set audio mode.
 + * @core:A pointer to the device struct.
 + * @new_mode:The new audio mode.
 + *
 + * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG.
 + */
 +int

Re: [PATCH] Illuminators and status LED controls

2010-09-08 Thread Peter Korsgaard

 Andy == Andy Walls awa...@md.metrocast.net writes:

Hi,

 Andy Incandescent and Halogen lamps that effect an image coming into a
 Andy camera are *not* LEDs that blink or flash automatically based on
 Andy driver or system trigger events.  They are components of a video
 Andy capture system with which a human attempts to adjust the
 Andy appearance of an image of a subject by changing the subject's
 Andy environment.  These illuminators are not some generically
 Andy connected device, but controlled by GPIO's on the camera's bridge
 Andy or sensor chip itself.  Such an illuminator will essentially be
 Andy used only in conjunction with the camera.

Agreed.

 Andy Status LEDs integrated into webcam devices that are not generically
 Andy connected devices but controlled with GPIOs on the camera's bridge or
 Andy sensor chip will also essentially be used only in conjunction with the
 Andy camera.

Or for any other usage the user envision - E.G. I could imagine using
the status led of the webcam in my macbook for hard disk or wifi
activity. I'm sure other people can come up with more creative use cases
as well.

 Andy Turning these sorts camera specific illuminators and LEDs on an off
 Andy should be as simple to implement for an application developer as it is
 Andy to grasp the concept of turning a light bulb on and off.

The point is that the logic rarely needs to be in the v4l
applications. The status LEDs should by default go on when the v4l
device is active and go off again when not like it used to do. A v4l
application developer would normally not want to worry about such
things, and only care about the video data.

But if a user wants something special / non-standard, then it's just a
matter of changing LED trigger in /sys/class/leds/..

 Andy The LED interface seems more appropriate to use when the LEDs are
 Andy connected more generically and will likely be used more generically,
 Andy such as in an embedded system.

The LED subsystem certainly has it uses in embedded, but it's also used
on PCs - As an example the ath9k wireless driver exports a number of
LEDs. I find the situation with the wlan LEDs pretty comparable to
status LEDs on v4l devices.

  And yes, application developers must use the correct API to control
  stuff.

  Why should kernel duplicate interfaces just because
  user land don't want to use two different interfaces? Doesn't this sound a 
  bit ... strange at least?

 Andy Why should the kernel push multiple APIs on application developers to
 Andy control a complex federation of small devices all connected behind a
 Andy single bridge chip, which the user perceives as a single device?  (BTW a
 Andy USB microscope is such a federation which doesn't work at all without
 Andy proper subject illumination.)

Because that's the only sensible way to create a bunch of incompatible
custom interfaces  - E.G. a microphone built into a webcam is handled
through also, not v4l, so it works with any sound recording program.

 Andy V4L2 controls are how desktop V4L2 applications currently control
 Andy aspects of a incoming image.  Forcing the use of the LED interface in
 Andy sysfs to control one aspect of that would be a departure from the norm
 Andy for the existing V4L2 desktop applications.

 Andy Forcing the use of the LED interface also brings along the complication
 Andy of proper association of the illuminator or LED sysfs control node to
 Andy the proper video capture/control device node.  I have a laptop with a
 Andy built in webcam with a status LED and a USB connected microscope with
 Andy two illuminators.  What are the steps for an application to discover the
 Andy correct light for the video device and what settings that light is
 Andy capable of: using V4L2 controls? using the LED interface?

Again, for status LEDs I don't see any reason why a standard v4l tool
would care. As I mentioned above, illuminators are a different story
(comparable to a gain setting imho).

 Andy How does one go about associating LEDs and Illuminators to video device
 Andy nodes using the LED sysfs interface?  I'm betting it's not as simple for
 Andy applications that use V4L2 controls.

I would imagine each video device would have a (number of) triggers,
similar to how it's done for E.G. the wlan stuff - Something like
video0-active. The status LED of the video0 device would default to
that trigger.

 Andy I do not see how forcing applications to use a second control
 Andy API, with no clear video device node-led sysfs node association
 Andy semantics, reduces application complexity, when those
 Andy applications already support the V4L2 control API from which
 Andy application can generically discover controls and their metadata
 Andy and automatically know the associated video device.

Again, I see the sysfs LED interface for status LEDs as more of a
user/administrator interface than a programming API.

-- 
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line unsubscribe linux-media in

[cron job] v4l-dvb daily build 2.6.26 and up: ERRORS

2010-09-08 Thread Hans Verkuil

This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Wed Sep  8 19:00:12 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   15139:6e0befab696a
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328
gcc version:  i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os:  2.6.32.5

linux-2.6.32.6-armv5: WARNINGS
linux-2.6.33-armv5: OK
linux-2.6.34-armv5: WARNINGS
linux-2.6.35.3-armv5: WARNINGS
linux-2.6.36-rc2-armv5: ERRORS
linux-2.6.32.6-armv5-davinci: WARNINGS
linux-2.6.33-armv5-davinci: WARNINGS
linux-2.6.34-armv5-davinci: WARNINGS
linux-2.6.35.3-armv5-davinci: WARNINGS
linux-2.6.36-rc2-armv5-davinci: ERRORS
linux-2.6.32.6-armv5-ixp: WARNINGS
linux-2.6.33-armv5-ixp: WARNINGS
linux-2.6.34-armv5-ixp: WARNINGS
linux-2.6.35.3-armv5-ixp: WARNINGS
linux-2.6.36-rc2-armv5-ixp: ERRORS
linux-2.6.32.6-armv5-omap2: WARNINGS
linux-2.6.33-armv5-omap2: WARNINGS
linux-2.6.34-armv5-omap2: WARNINGS
linux-2.6.35.3-armv5-omap2: WARNINGS
linux-2.6.36-rc2-armv5-omap2: ERRORS
linux-2.6.26.8-i686: WARNINGS
linux-2.6.27.44-i686: WARNINGS
linux-2.6.28.10-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-rc2-i686: ERRORS
linux-2.6.32.6-m32r: WARNINGS
linux-2.6.33-m32r: OK
linux-2.6.34-m32r: WARNINGS
linux-2.6.35.3-m32r: WARNINGS
linux-2.6.36-rc2-m32r: ERRORS
linux-2.6.32.6-mips: WARNINGS
linux-2.6.33-mips: WARNINGS
linux-2.6.34-mips: WARNINGS
linux-2.6.35.3-mips: WARNINGS
linux-2.6.36-rc2-mips: ERRORS
linux-2.6.32.6-powerpc64: WARNINGS
linux-2.6.33-powerpc64: WARNINGS
linux-2.6.34-powerpc64: WARNINGS
linux-2.6.35.3-powerpc64: WARNINGS
linux-2.6.36-rc2-powerpc64: ERRORS
linux-2.6.26.8-x86_64: WARNINGS
linux-2.6.27.44-x86_64: WARNINGS
linux-2.6.28.10-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-rc2-x86_64: ERRORS
linux-git-Module.symvers: ERRORS
linux-git-armv5: ERRORS
linux-git-armv5-davinci: ERRORS
linux-git-armv5-ixp: ERRORS
linux-git-armv5-omap2: ERRORS
linux-git-i686: ERRORS
linux-git-m32r: ERRORS
linux-git-mips: ERRORS
linux-git-powerpc64: ERRORS
linux-git-x86_64: ERRORS
spec: ERRORS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The V4L-DVB specification from this daily build is here:

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

Re: [PATCH v9 3/4] V4L2: WL1273 FM Radio: Controls for the FM radio.

Em 30-08-2010 08:38, Matti J. Aaltonen escreveu:
 This driver implements V4L2 controls for the Texas Instruments
 WL1273 FM Radio.
 
 Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
 ---
  drivers/media/radio/Kconfig|   15 +
  drivers/media/radio/Makefile   |1 +
  drivers/media/radio/radio-wl1273.c | 1935 
 
  drivers/mfd/Kconfig|5 +
  drivers/mfd/Makefile   |2 +
  5 files changed, 1958 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/radio/radio-wl1273.c
 
 diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
 index 83567b8..209fd37 100644
 --- a/drivers/media/radio/Kconfig
 +++ b/drivers/media/radio/Kconfig
 @@ -452,4 +452,19 @@ config RADIO_TIMBERDALE
 found behind the Timberdale FPGA on the Russellville board.
 Enabling this driver will automatically select the DSP and tuner.
  
 +config RADIO_WL1273
 + tristate Texas Instruments WL1273 I2C FM Radio
 +depends on I2C  VIDEO_V4L2  SND
 + select FW_LOADER
 + ---help---
 +   Choose Y here if you have this FM radio chip.
 +
 +   In order to control your radio card, you will need to use programs
 +   that are compatible with the Video For Linux 2 API.  Information on
 +   this API and pointers to v4l2 programs may be found at
 +   file:Documentation/video4linux/API.html.
 +
 +   To compile this driver as a module, choose M here: the
 +   module will be called radio-wl1273.
 +
  endif # RADIO_ADAPTERS
 diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
 index f615583..d297074 100644
 --- a/drivers/media/radio/Makefile
 +++ b/drivers/media/radio/Makefile
 @@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
  obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
  obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
  obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
 +obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o
  

From what I saw, wl1273-core and radio-wl1273 are just part of the same radio 
driver.
So, the better would be to just merge them into one driver module, with 
something like:

obj-wl1273.o = radio-wl1273.o wl1273-core.o
obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o

And remove all those export_symbol' s from wl1273-core.

  EXTRA_CFLAGS += -Isound
 diff --git a/drivers/media/radio/radio-wl1273.c 
 b/drivers/media/radio/radio-wl1273.c
 new file mode 100644
 index 000..aa1eeed
 --- /dev/null
 +++ b/drivers/media/radio/radio-wl1273.c
 @@ -0,0 +1,1935 @@
 +/*
 + * Driver for the Texas Instruments WL1273 FM radio.
 + *
 + * Copyright (C) Nokia Corporation
 + * Author: Matti J. Aaltonen matti.j.aalto...@nokia.com
 + *
 + * 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.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 + */
 +
 +#include linux/delay.h
 +#include linux/firmware.h
 +#include linux/mfd/wl1273-core.h
 +#include linux/slab.h
 +#include media/v4l2-common.h
 +#include media/v4l2-ctrls.h
 +#include media/v4l2-device.h
 +#include media/v4l2-ioctl.h
 +
 +#define DRIVER_DESC Wl1273 FM Radio - V4L2

Why V4L2??? Just call it as Wl1273 FM Radio.

 +
 +#define WL1273_POWER_SET_OFF 0
 +#define WL1273_POWER_SET_FM  (1  0)
 +#define WL1273_POWER_SET_RDS (1  1)
 +#define WL1273_POWER_SET_RETENTION   (1  4)
 +
 +#define WL1273_PUPD_SET_OFF  0x00
 +#define WL1273_PUPD_SET_ON   0x01
 +#define WL1273_PUPD_SET_RETENTION0x10
 +
 +#define WL1273_FREQ(x)   (x * 1 / 625)
 +#define WL1273_INV_FREQ(x)   (x * 625 / 1)
 +
 +/*
 + * static int radio_nr - The number of the radio device
 + *
 + * The default is 0.
 + */
 +static int radio_nr = -1;
 +module_param(radio_nr, int, 0);
 +MODULE_PARM_DESC(radio_nr, Radio Nr);
 +
 +struct wl1273_device {
 + struct v4l2_ctrl_handler ctrl_handler;
 + struct v4l2_device v4l2dev;
 + struct video_device videodev;
 + struct device *dev;
 + struct wl1273_core *core;
 + struct file *owner;
 + char *write_buf;
 + unsigned int rds_users;
 +};
 +
 +static int wl1273_fm_set_tx_freq(struct wl1273_core *core, unsigned int freq)
 +{
 + int r = 0;
 +
 + if (freq  76000) {
 + dev_err(core-i2c_dev-dev,
 + Frequency out of range: %d  %d\n,
 + freq, core-bands[core-band].bottom_frequency);
 + return -ERANGE;
 +

Re: [PATCH] DiSEqC bug fixed for stv0288 based interfaces

Em 01-09-2010 09:35, Josef Pavlik escreveu:
 Fixed problem with DiSEqC communication. The message was wrongly modulated, 
 so the DiSEqC switch was not work.
 
 This patch fixes DiSEqC messages, simple tone burst and tone on/off. 
 I verified it with osciloscope against the DiSEqC documentation.
 
 Interface: PCI DVB-S TV tuner TeVii S420
 Kernel: 2.6.32-24-generic (UBUNTU 10.4)
 
 Signed-off-by: Josef Pavlik jo...@pavlik.it

Patch doesn't apply against the latest version, at my -git tree. 
Not sure if the bugs you're pointing were already fixed.

Cheers,
Mauro.
 
 
 
 
 diff --git a/drivers/media/dvb/frontends/stv0288.c 
 b/drivers/media/dvb/frontends/stv0288.c
 index 2930a5d..6a32535 100644
 --- a/drivers/media/dvb/frontends/stv0288.c
 +++ b/drivers/media/dvb/frontends/stv0288.c
 @@ -6,6 +6,8 @@
 Copyright (C) 2008 Igor M. Liplianin liplia...@me.by
 Removed stb6000 specific tuner code and revised some
 procedures.
 +   2010-09-01 Josef Pavlik jo...@pavlik.it
 +   Fixed diseqc_msg, diseqc_burst and set_tone problems
 
 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
 @@ -156,14 +158,13 @@ static int stv0288_send_diseqc_msg(struct dvb_frontend 
 *fe,
 
 stv0288_writeregI(state, 0x09, 0);
 msleep(30);
 -   stv0288_writeregI(state, 0x05, 0x16);
 +   stv0288_writeregI(state, 0x05, 0x12); /* modulated mode, single shot 
 */
 
 for (i = 0; i  m-msg_len; i++) {
 if (stv0288_writeregI(state, 0x06, m-msg[i]))
 return -EREMOTEIO;
 -   msleep(12);
 }
 -
 +   msleep(m-msg_len*12);
 return 0;
  }
 
 @@ -174,13 +175,14 @@ static int stv0288_send_diseqc_burst(struct 
 dvb_frontend *fe,
 
 dprintk(%s\n, __func__);
 
 -   if (stv0288_writeregI(state, 0x05, 0x16))/* burst mode */
 +   if (stv0288_writeregI(state, 0x05, 0x03)) /* simple tone burst 
 mode, single shot */
 return -EREMOTEIO;
 
 if (stv0288_writeregI(state, 0x06, burst == SEC_MINI_A ? 0x00 : 0xff))
 return -EREMOTEIO;
 
 -   if (stv0288_writeregI(state, 0x06, 0x12))
 +   msleep(15);
 +   if (stv0288_writeregI(state, 0x05, 0x12))
 return -EREMOTEIO;
 
 return 0;
 @@ -192,18 +194,19 @@ static int stv0288_set_tone(struct dvb_frontend *fe, 
 fe_sec_tone_mode_t tone)
 
 switch (tone) {
 case SEC_TONE_ON:
 -   if (stv0288_writeregI(state, 0x05, 0x10))/* burst mode */
 +   if (stv0288_writeregI(state, 0x05, 0x10))/* burst mode, 
 continuous carrier */
 return -EREMOTEIO;
 -   return stv0288_writeregI(state, 0x06, 0xff);
 +   break;
 
 case SEC_TONE_OFF:
 -   if (stv0288_writeregI(state, 0x05, 0x13))/* burst mode */
 +   if (stv0288_writeregI(state, 0x05, 0x12))/* burst mode off*/
 return -EREMOTEIO;
 -   return stv0288_writeregI(state, 0x06, 0x00);
 +   break;
 
 default:
 return -EINVAL;
 }
 +   return 0;
  }
 
  static u8 stv0288_inittab[] = {
 --
 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] Illuminators and status LED controls

2010-09-08 Thread Alex Deucher

On Wed, Sep 8, 2010 at 2:58 PM, Peter Korsgaard jac...@sunsite.dk wrote:
 Andy == Andy Walls awa...@md.metrocast.net writes:

 Hi,

  Andy Incandescent and Halogen lamps that effect an image coming into a
  Andy camera are *not* LEDs that blink or flash automatically based on
  Andy driver or system trigger events.  They are components of a video
  Andy capture system with which a human attempts to adjust the
  Andy appearance of an image of a subject by changing the subject's
  Andy environment.  These illuminators are not some generically
  Andy connected device, but controlled by GPIO's on the camera's bridge
  Andy or sensor chip itself.  Such an illuminator will essentially be
  Andy used only in conjunction with the camera.

 Agreed.

  Andy Status LEDs integrated into webcam devices that are not generically
  Andy connected devices but controlled with GPIOs on the camera's bridge or
  Andy sensor chip will also essentially be used only in conjunction with the
  Andy camera.

 Or for any other usage the user envision - E.G. I could imagine using
 the status led of the webcam in my macbook for hard disk or wifi
 activity. I'm sure other people can come up with more creative use cases
 as well.

  Andy Turning these sorts camera specific illuminators and LEDs on an off
  Andy should be as simple to implement for an application developer as it is
  Andy to grasp the concept of turning a light bulb on and off.

 The point is that the logic rarely needs to be in the v4l
 applications. The status LEDs should by default go on when the v4l
 device is active and go off again when not like it used to do. A v4l
 application developer would normally not want to worry about such
 things, and only care about the video data.

 But if a user wants something special / non-standard, then it's just a
 matter of changing LED trigger in /sys/class/leds/..

I agree with Peter here.  I don't see why a video app would care about
blinking an LED while capturing.  I suspect most apps won't bother to
implement it, or it will be a card specific mess (depending on what
the hw actually provides).  Shouldn't the driver just turn it on or
blink it when capturing is active or whatever.  Why should apps care?
Plus, each app may implement some different behavior or some may not
implement it at all which will further confuse users.

Alex


  Andy The LED interface seems more appropriate to use when the LEDs are
  Andy connected more generically and will likely be used more generically,
  Andy such as in an embedded system.

 The LED subsystem certainly has it uses in embedded, but it's also used
 on PCs - As an example the ath9k wireless driver exports a number of
 LEDs. I find the situation with the wlan LEDs pretty comparable to
 status LEDs on v4l devices.

   And yes, application developers must use the correct API to control
   stuff.

   Why should kernel duplicate interfaces just because
   user land don't want to use two different interfaces? Doesn't this sound 
 a bit ... strange at least?

  Andy Why should the kernel push multiple APIs on application developers to
  Andy control a complex federation of small devices all connected behind a
  Andy single bridge chip, which the user perceives as a single device?  (BTW 
 a
  Andy USB microscope is such a federation which doesn't work at all without
  Andy proper subject illumination.)

 Because that's the only sensible way to create a bunch of incompatible
 custom interfaces  - E.G. a microphone built into a webcam is handled
 through also, not v4l, so it works with any sound recording program.

  Andy V4L2 controls are how desktop V4L2 applications currently control
  Andy aspects of a incoming image.  Forcing the use of the LED interface in
  Andy sysfs to control one aspect of that would be a departure from the norm
  Andy for the existing V4L2 desktop applications.

  Andy Forcing the use of the LED interface also brings along the complication
  Andy of proper association of the illuminator or LED sysfs control node to
  Andy the proper video capture/control device node.  I have a laptop with a
  Andy built in webcam with a status LED and a USB connected microscope with
  Andy two illuminators.  What are the steps for an application to discover 
 the
  Andy correct light for the video device and what settings that light is
  Andy capable of: using V4L2 controls? using the LED interface?

 Again, for status LEDs I don't see any reason why a standard v4l tool
 would care. As I mentioned above, illuminators are a different story
 (comparable to a gain setting imho).

  Andy How does one go about associating LEDs and Illuminators to video device
  Andy nodes using the LED sysfs interface?  I'm betting it's not as simple 
 for
  Andy applications that use V4L2 controls.

 I would imagine each video device would have a (number of) triggers,
 similar to how it's done for E.G. the wlan stuff - Something like
 video0-active. The status LED of the video0 device would default to
 that

Re: [RESEND][PATCH 1/2] media: Add timberdale video-in driver

Em 02-09-2010 08:56, Richard Röjfors escreveu:
 This patch adds the timberdale video-in driver.
 
 The video IP of timberdale delivers the video data via DMA.
 The driver uses the DMA api to handle DMA transfers, and make use
 of the V4L2 video buffers to handle buffers against user space.
 
 If available the driver uses an encoder to get/set the video standard
 
 Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
 ---
 diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
 index f6e4d04..1afbe26 100644
 --- a/drivers/media/video/Kconfig
 +++ b/drivers/media/video/Kconfig
 @@ -734,6 +734,15 @@ config VIDEO_HEXIUM_GEMINI
 To compile this driver as a module, choose M here: the
 module will be called hexium_gemini.
  
 +config VIDEO_TIMBERDALE
 + tristate Support for timberdale Video In/LogiWIN
 + depends on VIDEO_V4L2  I2C
 + select TIMB_DMA
 + select VIDEO_ADV7180
 + select VIDEOBUF_DMA_CONTIG
 + ---help---
 + Add support for the Video In peripherial of the timberdale FPGA.
 +
  source drivers/media/video/cx88/Kconfig
  
  source drivers/media/video/cx23885/Kconfig
 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
 index 40f98fb..c93af35 100644
 --- a/drivers/media/video/Makefile
 +++ b/drivers/media/video/Makefile
 @@ -109,6 +109,7 @@ obj-$(CONFIG_VIDEO_CPIA2) += cpia2/
  obj-$(CONFIG_VIDEO_MXB) += mxb.o
  obj-$(CONFIG_VIDEO_HEXIUM_ORION) += hexium_orion.o
  obj-$(CONFIG_VIDEO_HEXIUM_GEMINI) += hexium_gemini.o
 +obj-$(CONFIG_VIDEO_TIMBERDALE)   += timblogiw.o
  
  obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
  obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
 diff --git a/drivers/media/video/timblogiw.c b/drivers/media/video/timblogiw.c
 new file mode 100644
 index 000..1ccc620
 --- /dev/null
 +++ b/drivers/media/video/timblogiw.c
 @@ -0,0 +1,877 @@
 +/*
 + * timblogiw.c timberdale FPGA LogiWin Video In driver
 + * Copyright (c) 2009-2010 Intel Corporation
 + *
 + * 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.
 + *
 + * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
 + */
 +
 +/* Supports:
 + * Timberdale FPGA LogiWin Video In
 + */
 +
 +#include linux/version.h
 +#include linux/platform_device.h
 +#include linux/slab.h
 +#include linux/dmaengine.h
 +#include linux/scatterlist.h
 +#include linux/interrupt.h
 +#include linux/list.h
 +#include linux/i2c.h
 +#include media/v4l2-ioctl.h
 +#include media/v4l2-device.h
 +#include media/videobuf-dma-contig.h
 +#include media/timb_video.h
 +
 +#define DRIVER_NAME  timb-video
 +
 +#define TIMBLOGIWIN_NAME Timberdale Video-In
 +#define TIMBLOGIW_VERSION_CODE   0x04
 +
 +#define TIMBLOGIW_LINES_PER_DESC 44
 +#define TIMBLOGIW_MAX_VIDEO_MEM  16
 +
 +#define TIMBLOGIW_VIDEO_FORMAT   V4L2_PIX_FMT_UYVY

Hmm... why are you using a constant here? Does this device provide the standard 
UYVY fourcc
format, or does it have a different (proprietary) format?

If it uses the standard format, just use the standard definition. Otherwise, we 
need to add a
new format to the V4L2 API, to make sure that userspace applications and libv4l 
will properly
handle it.

 +
 +#define TIMBLOGIW_HAS_DECODER(lw)(lw-pdata.encoder.module_name)
 +
 +
 +struct timblogiw {
 + struct video_device video_dev;
 + struct v4l2_device  v4l2_dev; /* mutual exclusion */
 + struct mutexlock;
 + struct device   *dev;
 + struct timb_video_platform_data pdata;
 + struct v4l2_subdev  *sd_enc;/* encoder */
 + boolopened;
 +};
 +
 +struct timblogiw_tvnorm {
 + v4l2_std_id std;
 + u16 width;
 + u16 height;
 + u8  fps;
 +};
 +
 +struct timblogiw_fh {
 + struct videobuf_queue   vb_vidq;
 + struct timblogiw_tvnorm const   *cur_norm;
 + struct list_headcapture;
 + struct dma_chan *chan;
 + spinlock_t  queue_lock; /* mutual exclusion */
 + unsigned intframe_count;
 +};
 +
 +struct timblogiw_buffer {
 + /* common v4l buffer stuff -- must be first */
 + struct videobuf_buffer  vb;
 + struct scatterlist  sg[16];
 + dma_cookie_tcookie;
 + struct timblogiw_fh *fh;
 +};
 +
 +const struct timblogiw_tvnorm

Re: [RESEND][PATCH 0/2] media, mfd: Add timberdale video-in driver

Em 02-09-2010 08:56, Richard Röjfors escreveu:
 To follow are two patches.
 
 The first adds the timberdale video-in driver to the media tree.
 
 The second adds it to the timberdale MFD driver.
 
 Samuel and Mauro hope you can support and solve the potential merge
 issue between your two trees.

If the conflicts are trivial, I can handle when merging upstream.
 
 Thanks
 --Richard
 

--
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/PATCH 1/8] drivers:media:video: Adding new CIDs for FM RX ctls

Em 02-09-2010 12:57, raja_m...@ti.com escreveu:
 From: Raja Mani raja_m...@ti.com
 
 Add support for the following new Control IDs (CID)
V4L2_CID_FM_RX_CLASS- FM RX Tuner controls
V4L2_CID_FM_BAND- FM band

Hmm... both you and Matti are adding _the_same_ ioctls on different patchsets?
Please, coordinate between yourself to avoid duplicated/conflicted patches.

V4L2_CID_RSSI_THRESHOLD - RSSI Threshold
V4L2_CID_TUNE_AF- Alternative Frequency
 
 Signed-off-by: Raja Mani raja_m...@ti.com
 Signed-off-by: Pramodh AG pramodh...@ti.com
 ---
  drivers/media/video/v4l2-common.c |   16 
  1 files changed, 16 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/media/video/v4l2-common.c 
 b/drivers/media/video/v4l2-common.c
 index 4e53b0b..33c3037 100644
 --- a/drivers/media/video/v4l2-common.c
 +++ b/drivers/media/video/v4l2-common.c
 @@ -354,6 +354,12 @@ const char **v4l2_ctrl_get_menu(u32 id)
   75 useconds,
   NULL,
   };
 + static const char *fm_band[] = {
 + 87.5 - 108. MHz,
 + 76. - 90. MHz, Japan,
 + 65. - 74. MHz, OIRT,
 + NULL,
 + };

Already NACKED at Matti's patchset. I'll review/comment the other ioctls 
together with the DocBook spec file.
  
   switch (id) {
   case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
 @@ -394,6 +400,8 @@ const char **v4l2_ctrl_get_menu(u32 id)
   return colorfx;
   case V4L2_CID_TUNE_PREEMPHASIS:
   return tune_preemphasis;
 + case V4L2_CID_FM_BAND:
 + return fm_band;
   default:
   return NULL;
   }
 @@ -520,6 +528,10 @@ const char *v4l2_ctrl_get_name(u32 id)
   case V4L2_CID_TUNE_PREEMPHASIS: return Pre-emphasis settings;
   case V4L2_CID_TUNE_POWER_LEVEL: return Tune Power Level;
   case V4L2_CID_TUNE_ANTENNA_CAPACITOR:   return Tune Antenna Capacitor;
 + case V4L2_CID_FM_RX_CLASS:  return FM Radio Tuner Controls;
 + case V4L2_CID_FM_BAND:  return FM Band;
 + case V4L2_CID_RSSI_THRESHOLD:   return RSSI Threshold;
 + case V4L2_CID_TUNE_AF:  return Alternative Frequency;
  
   default:
   return NULL;
 @@ -585,6 +597,9 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, 
 s32 min, s32 max, s32 ste
   case V4L2_CID_EXPOSURE_AUTO:
   case V4L2_CID_COLORFX:
   case V4L2_CID_TUNE_PREEMPHASIS:
 + case V4L2_CID_FM_BAND:
 + case V4L2_CID_RSSI_THRESHOLD:
 + case V4L2_CID_TUNE_AF:
   qctrl-type = V4L2_CTRL_TYPE_MENU;
   step = 1;
   break;
 @@ -596,6 +611,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, 
 s32 min, s32 max, s32 ste
   case V4L2_CID_CAMERA_CLASS:
   case V4L2_CID_MPEG_CLASS:
   case V4L2_CID_FM_TX_CLASS:
 + case V4L2_CID_FM_RX_CLASS:
   qctrl-type = V4L2_CTRL_TYPE_CTRL_CLASS;
   qctrl-flags |= V4L2_CTRL_FLAG_READ_ONLY;
   min = max = step = def = 0;

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

Re: [RFC/PATCH 2/8] include:linux:videodev2: Define new CIDs for FM RX ctls

Em 02-09-2010 12:57, raja_m...@ti.com escreveu:
 From: Raja Mani raja_m...@ti.com
 
 Extend V4L2 CID list to support
1) FM RX Tuner controls
2) FM band
3) RSSI Threshold
4) Alternative Frequency

Hmm... no DocBooks for RSSI and Alternative Frequency... How do you expect me 
to review
new API additions if you aren't properly documenting and justifying the need 
for those
additions?

Cheers,
Mauro
 
 Signed-off-by: Raja Mani raja_m...@ti.com
 Signed-off-by: Pramodh AG pramodh...@ti.com
 ---
  include/linux/videodev2.h |   18 ++
  1 files changed, 18 insertions(+), 0 deletions(-)
 
 diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
 index 7c99acf..2798137 100644
 --- a/include/linux/videodev2.h
 +++ b/include/linux/videodev2.h
 @@ -964,6 +964,7 @@ struct v4l2_writeback_ioctl_data {
  #define V4L2_CTRL_CLASS_MPEG 0x0099  /* MPEG-compression controls */
  #define V4L2_CTRL_CLASS_CAMERA 0x009a/* Camera class controls */
  #define V4L2_CTRL_CLASS_FM_TX 0x009b /* FM Modulator control class */
 +#define V4L2_CTRL_CLASS_FM_RX 0x009c /* FM Tuner control class */
  
  #define V4L2_CTRL_ID_MASK  (0x0fff)
  #define V4L2_CTRL_ID2CLASS(id)((id)  0x0fffUL)
 @@ -1362,6 +1363,23 @@ enum v4l2_preemphasis {
  #define V4L2_CID_TUNE_POWER_LEVEL(V4L2_CID_FM_TX_CLASS_BASE + 
 113)
  #define V4L2_CID_TUNE_ANTENNA_CAPACITOR  
 (V4L2_CID_FM_TX_CLASS_BASE + 114)
  
 +/* FM Tuner class control IDs */
 +#define V4L2_CID_FM_RX_CLASS_BASE(V4L2_CTRL_CLASS_FM_RX | 0x900)
 +#define V4L2_CID_FM_RX_CLASS (V4L2_CTRL_CLASS_FM_RX | 1)
 +
 +#define V4L2_CID_FM_BAND (V4L2_CID_FM_RX_CLASS_BASE + 1)
 +enum v4l2_fm_band {
 + V4L2_FM_BAND_OTHER  = 0,
 + V4L2_FM_BAND_JAPAN  = 1,
 + V4L2_FM_BAND_OIRT   = 2
 +};
 +#define V4L2_CID_RSSI_THRESHOLD  
 (V4L2_CID_FM_RX_CLASS_BASE + 2)
 +#define V4L2_CID_TUNE_AF (V4L2_CID_FM_RX_CLASS_BASE + 3)
 +enum v4l2_tune_af {
 + V4L2_FM_AF_OFF  = 0,
 + V4L2_FM_AF_ON   = 1
 +};
 +
  /*
   *   T U N I N G
   */

--
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/PATCH 3/8] drivers:staging:ti-st: Sources for FM TX

Em 02-09-2010 12:57, raja_m...@ti.com escreveu:
 From: Raja Mani raja_m...@ti.com
 
 This has implementation of FM TX functionality (for Wl127x and WL128x
 chip) which are listed below,
 
 1) frequency set.
 2) stereo/nono mode selection.
 3) RDS config.
 4) mute/unmute mode config.
 5) power level config.
 6) preemphasis filter config, etc.
 
 This will work on top of TI Shared Transport driver. It communicates with
 TI FM V4L2 module and TI FM Common module to perform the actual FM TX 
 operation.
 
 Signed-off-by: Raja Mani raja_m...@ti.com
 Signed-off-by: Pramodh AG pramodh...@ti.com
 ---
  drivers/staging/ti-st/fmdrv_tx.c |  391 
 ++
  drivers/staging/ti-st/fmdrv_tx.h |   37 
  2 files changed, 428 insertions(+), 0 deletions(-)
  create mode 100644 drivers/staging/ti-st/fmdrv_tx.c
  create mode 100644 drivers/staging/ti-st/fmdrv_tx.h
 
 diff --git a/drivers/staging/ti-st/fmdrv_tx.c 
 b/drivers/staging/ti-st/fmdrv_tx.c
 new file mode 100644
 index 000..55bf89a
 --- /dev/null
 +++ b/drivers/staging/ti-st/fmdrv_tx.c
 @@ -0,0 +1,391 @@
 +/*
 + *  FM Driver for Connectivity chip of Texas Instruments.
 + *  This sub-module of FM driver implements FM TX functionality.
 + *
 + *  Copyright (C) 2010 Texas Instruments
 + *
 + *  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.
 + *
 + *  This program is distributed in the hope that it will be useful,
 + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + *  GNU General Public License for more details.
 + *
 + *  You should have received a copy of the GNU General Public License
 + *  along with this program; if not, write to the Free Software
 + *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 + *
 + */
 +
 +#include linux/delay.h
 +#include fmdrv.h
 +#include fmdrv_common.h
 +#include fmdrv_tx.h

Where are those headers? Please send your patch series on an order that helps 
the
reviewers to understand the logic, sending first things first.

I'm not seeing the patches that are adding those include files, making hard to
understand the remaining patches of this series.

 +
 +int fm_tx_set_stereo_mono(struct fmdrv_ops *fmdev, unsigned short mode)
 +{
 + unsigned short payload;
 + int ret = 0;
 +
 + if (fmdev-curr_fmmode != FM_MODE_TX) {
 + ret = -EPERM;
 + goto exit;
 + }
 + if (fmdev-tx_data.aud_mode == mode)
 + goto exit;
 +
 + pr_debug(stereo mode: %d, (int)mode);
 +
 + /* Set Stereo/Mono mode */
 + FM_STORE_LE16_TO_BE16(payload, (1 - mode));
 + ret = fmc_send_cmd(fmdev, MONO_SET, payload, sizeof(payload),
 + fmdev-maintask_completion, NULL, NULL);
 + FM_CHECK_SEND_CMD_STATUS(ret);
 +
 + fmdev-tx_data.aud_mode = mode;
 +exit:
 + return ret;
 +}
 +
 +static int __set_rds_text(struct fmdrv_ops *fmdev, unsigned char *rds_text)
 +{
 + unsigned short payload;
 + int ret;
 +
 + ret = fmc_send_cmd(fmdev, RDS_DATA_SET, rds_text, strlen(rds_text),
 + fmdev-maintask_completion, NULL, NULL);
 + FM_CHECK_SEND_CMD_STATUS(ret);
 +
 + /* Scroll mode */
 + FM_STORE_LE16_TO_BE16(payload, (unsigned short)0x1);
 + ret = fmc_send_cmd(fmdev, DISPLAY_MODE_SET, payload, sizeof(payload),
 + fmdev-maintask_completion, NULL, NULL);
 + FM_CHECK_SEND_CMD_STATUS(ret);
 +
 + return 0;
 +}
 +
 +static int __set_rds_data_mode(struct fmdrv_ops *fmdev, unsigned char mode)
 +{
 + unsigned short payload;
 + int ret;
 +
 + /* Setting unique PI TODO: how unique? */
 + FM_STORE_LE16_TO_BE16(payload, (unsigned short)0xcafe);
 + ret = fmc_send_cmd(fmdev, PI_SET, payload, sizeof(payload),
 + fmdev-maintask_completion, NULL, NULL);
 + FM_CHECK_SEND_CMD_STATUS(ret);
 +
 + /* Set decoder id */
 + FM_STORE_LE16_TO_BE16(payload, (unsigned short)0xa);
 + ret = fmc_send_cmd(fmdev, DI_SET, payload, sizeof(payload),
 + fmdev-maintask_completion, NULL, NULL);
 + FM_CHECK_SEND_CMD_STATUS(ret);
 +
 + /* TODO: RDS_MODE_GET? */
 + return 0;
 +}
 +
 +static int __set_rds_len(struct fmdrv_ops *fmdev, unsigned char type,
 + unsigned short len)
 +{
 + unsigned short payload;
 + int ret;
 +
 + len |= type  8;
 + FM_STORE_LE16_TO_BE16(payload, len);
 + ret = fmc_send_cmd(fmdev, LENGHT_SET, payload, sizeof(payload),
 + fmdev-maintask_completion, NULL, NULL);
 +
 + FM_CHECK_SEND_CMD_STATUS(ret);
 +
 + /* TODO: LENGHT_GET? */
 + return 0;
 +}
 +
 +int fm_tx_set_rds_mode(struct fmdrv_ops *fmdev, unsigned char rds_en_dis)
 +{
 + unsigned

Re: [PATCH] added support for DM040832731 DVB-S USB BOX - Correction

Em 29-07-2010 15:16, Mauro Carvalho Chehab escreveu:
 Em 16-07-2010 10:43, Malcolm Priestley escreveu:
 DVB USB Driver for DM04 LME2510 + LG TDQY - P001F =(TDA8263 + TDA10086H)

 Corrected patch error.

 Signed-off-by: Malcolm Priestley tvbox...@gmail.com
 
 Hi Malcom,
 
 Please read the developers section of our Wiki page for instructions on how 
 to submit
 a driver:
   http://linuxtv.org/wiki/index.php/Developer_Section
 
 In special, you need to read what's inside Submiting your work in order to 
 fix some
 troubles I identified on your driver.

Not sure why, but I lost the email where you submitted your new driver on my 
inbox. I got it
from patchwork and applied.

Em 08-09-2010 18:01, Mauro Carvalho Chehab escreveu:
 This is an automatic generated email to let you know that the following patch 
 were queued at the 
 http://git.linuxtv.org/media-tree.git tree:
 
 Subject: V4L/DVB: Support or LME2510(C) DM04/QQBOX USB DVB-S BOXES
 Author:  Malcolm Priestley tvbox...@gmail.com
 Date:Thu Sep 2 17:29:30 2010 -0300
 
 DM04/QQBOX DVB-S USB BOX with LME2510C+SHARP:BS2F7HZ7395 or 
 LME2510+LGTDQT-P001F tuner.
 
 [mche...@redhat.com: Fix merge conflicts/compilation and CodingStyle issues]

There were some API changes at USB, and a few trivial CodingStyle issues.

I didn't double checked if all those patchwork patches you've mentioned were 
applied. For sure
I've applied the other patch from you adding the frontend.

Please double check if everything is ok and ping me, if I missed something.

 Signed-off-by: Malcolm Priestley tvbox...@gmail.com
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 
  Documentation/dvb/get_dvb_firmware|   46 ++-
  Documentation/dvb/lmedm04.txt |   55 ++
  drivers/media/IR/keymaps/Makefile |1 +
  drivers/media/IR/keymaps/rc-lme2510.c |   68 +++
  drivers/media/dvb/dvb-usb/Kconfig |   11 +
  drivers/media/dvb/dvb-usb/Makefile|3 +
  drivers/media/dvb/dvb-usb/lmedm04.c   |  936 
 +
  drivers/media/dvb/dvb-usb/lmedm04.h   |  187 +++
  include/media/rc-map.h|1 +
  9 files changed, 1307 insertions(+), 1 deletions(-)
 
 ---
 
 http://git.linuxtv.org/media-tree.git?a=commitdiff;h=0a11672a8a3431296ed99be16e7cb57bc004e080
 
 diff --git a/Documentation/dvb/get_dvb_firmware 
 b/Documentation/dvb/get_dvb_firmware
 index 350959f..59690de 100644
 --- a/Documentation/dvb/get_dvb_firmware
 +++ b/Documentation/dvb/get_dvb_firmware
 @@ -26,7 +26,8 @@ use IO::Handle;
   dec3000s, vp7041, dibusb, nxt2002, nxt2004,
   or51211, or51132_qam, or51132_vsb, bluebird,
   opera1, cx231xx, cx18, cx23885, pvrusb2, mpc718,
 - af9015, ngene, az6027);
 + af9015, ngene, az6027, lme2510_lg, lme2510c_s7395,
 + lme2510c_s7395_old);
  
  # Check args
  syntax() if (scalar(@ARGV) != 1);
 @@ -584,6 +585,49 @@ sub az6027{
  
  $firmware;
  }
 +
 +sub lme2510_lg {
 +my $sourcefile = LMEBDA_DVBS.sys;
 +my $hash = fc6017ad01e79890a97ec53bea157ed2;
 +my $outfile = dvb-usb-lme2510-lg.fw;
 +my $hasho = caa065d5fdbd2c09ad57b399bbf55cad;
 +
 +checkstandard();
 +
 +verify($sourcefile, $hash);
 +extract($sourcefile, 4168, 3841, $outfile);
 +verify($outfile, $hasho);
 +$outfile;
 +}
 +
 +sub lme2510c_s7395 {
 +my $sourcefile = US2A0D.sys;
 +my $hash = b0155a8083fb822a3bd47bc360e74601;
 +my $outfile = dvb-usb-lme2510c-s7395.fw;
 +my $hasho = 3a3cf1aeebd17b6ddc04cebe131e94cf;
 +
 +checkstandard();
 +
 +verify($sourcefile, $hash);
 +extract($sourcefile, 37248, 3720, $outfile);
 +verify($outfile, $hasho);
 +$outfile;
 +}
 +
 +sub lme2510c_s7395_old {
 +my $sourcefile = LMEBDA_DVBS7395C.sys;
 +my $hash = 7572ae0eb9cdf91baabd7c0ba9e09b31;
 +my $outfile = dvb-usb-lme2510c-s7395.fw;
 +my $hasho = 90430c5b435eb5c6f88fd44a9d950674;
 +
 +checkstandard();
 +
 +verify($sourcefile, $hash);
 +extract($sourcefile, 4208, 3881, $outfile);
 +verify($outfile, $hasho);
 +$outfile;
 +}
 +
  # ---
  # Utilities
  
 diff --git a/Documentation/dvb/lmedm04.txt b/Documentation/dvb/lmedm04.txt
 new file mode 100644
 index 000..4bde457
 --- /dev/null
 +++ b/Documentation/dvb/lmedm04.txt
 @@ -0,0 +1,55 @@
 +To extract firmware for the DM04/QQBOX you need to copy the
 +following file(s) to this directory.
 +
 +for DM04+/QQBOX LME2510C (Sharp 7395 Tuner)
 +---
 +
 +The Sharp 7395 driver can be found in windows/system32/driver
 +
 +US2A0D.sys (dated 17 Mar 2009)
 +
 +
 +and run
 +./get_dvb_firmware lme2510c_s7395
 +
 + will produce
 + dvb-usb-lme2510c-s7395.fw
 +
 +An alternative but older firmware can be found on the driver
 +disk DVB-S_EN_3.5A in BDADriver/driver
 +
 +LMEBDA_DVBS7395C.sys (dated 18 Jan 2008)
 +
 +and run
 +./get_dvb_firmware lme2510c_s7395_old
 +
 +

Re: [PATCH 1/5] rc-code: merge and rename ir-core

On Wed, Sep 08, 2010 at 11:10:40AM -0400, Andy Walls wrote:
 Tag files and a decent editor are all one needs for full code 
 navigation.  The kernel makefile already has a tags target to make the 
 tags file.  

If you like to use tags, it won't be affected by many or few files so 
it's not an argument for either approach. 

 Smaller files make for better logical isolation of functions,limiting 
 visibilty/scope, 

Limiting visibility so that you'll have to add explicit declarations to 
ir-core-priv.h for inter-file function calls and functions that would 
otherwise be unnecessary (ir_raw_get_allowed_protocols() for example) 
doesn't sound like an advantage to me.

 and faster compilation of a file (but maybe at the expense of link 
 time).  

*sigh* compile times on my laptop:

rc-core.o   0.558s

ir-functions.o  0.321s
ir-sysfs.o  0.251s
ir-raw-event.o  0.397s
rc-map.o0.265s

 That sort of isolation of functionality into smaller files also makes 
 the code more digestable for someone new looking at it, IMO. 

First of all, I personally find it much easier to grok a new subsystem 
if the relevant parts are gathered into one file, both when I'm new to a 
subsystem and when I'm used to it. drivers/input/input.c and 
drivers/input/evdev.c come to mind as good examples.

But more importantly, how about focusing on the people actually writing 
patches for ir-core rather than hypotetical people?

-- 
David Härdeman
--
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/6] Input: winbond-cir - switch to using new keycode interface

On Wed, Sep 08, 2010 at 12:42:00AM -0700, Dmitry Torokhov wrote:
 Switch the code to use new style of getkeycode and setkeycode
 methods to allow retrieving and setting keycodes not only by
 their scancodes but also by index.
 
 Signed-off-by: Dmitry Torokhov d...@mail.ru
 ---
 
  drivers/input/misc/winbond-cir.c |  248 
 +-
  1 files changed, 163 insertions(+), 85 deletions(-)

Thanks for doing the conversion for me, but I think you can skip this 
patch. The driver will (if I understood your patchset correctly) still 
work with the old get/setkeycode ioctls and I have a patch lined up that 
converts winbond-cir.c to use ir-core which means all of the input 
related code is removed.


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

Re: [PATCH 1/2] ir-core: centralize sysfs raw decoder enabling/disabling

On Wed, Sep 08, 2010 at 10:16:13AM -0400, Jarod Wilson wrote:
 On Wed, Sep 08, 2010 at 07:04:03AM -0700, Brian Rogers wrote:
  ir_dev-raw is also null. If I check these pointers before using
  them, and bail out if both are null, then I get a working lircd, but
  of course the file /sys/devices/virtual/rc/rc0/protocols no longer
  does anything. On 2.6.35.4, the system never creates the
  /sys/class/rc/rc0/current_protocol file. Is it the case that the
  'protocols' file should never appear, because my card can't support
  this feature?
 
 Hm... So protocols is indeed intended for hardware that handles raw IR, as
 its a list of raw IR decoders available/enabled/disabled for the receiver.
 But some devices that do onboard decoding and deal with scancodes still
 need to support changing protocols, as they can be told decode rc5 or
 decode nec, etc... My memory is currently foggy on how it was exactly
 that it was supposed to be donee though. :) (Yet another reason I really
 need to poke at the imon driver code again).

This, and a raft of similar bugreports was one of the reasons I wrote 
the rc_dev patch (which gets rid of ir_dev-props, the source of many 
oopses by now).

Hardware decoders should work with the same sysfs file, the driver 
should set ir_dev-props-change_protocol (current) or 
rc-change_protocol (future) and it'll get notified when userspace 
interacts with the sysfs file and the hardware can then react 
accordingly. So the answer is yes - all hardware should have the file.

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

Re: [PATCH 1/5] rc-code: merge and rename ir-core

On Wed, Sep 08, 2010 at 10:42:10AM -0300, Mauro Carvalho Chehab wrote:
 Em 07-09-2010 18:51, David Härdeman escreveu:
  This patch merges the files which makes up ir-core and renames the
  resulting module to rc-core. IMHO this makes it much easier to hack
  on the core module since all code is in one file.
  
  This also allows some simplification of ir-core-priv.h as fewer internal
  functions need to be exposed.
 
 I'm not sure about this patch. Big files tend to be harder to maintain,
 as it takes more time to find the right functions inside it. Also, IMO, 
 it makes sense to keep the raw-event code on a separate file.

I don't find big files difficult (note: we're talking about 1300 lines 
here).  Rather the opposite, no hesitation about which files a given 
function originates from and all related code in one nice file. evdev.c 
and input.c are good precedents. But of course, it all boils down to a 
matter of personal taste.

 Anyway, if we apply this patch right now, it will cause merge conflicts with
 the input tree, due to the get/setkeycodebig patches, and with some other
 patches that are pending merge/review. The better is to apply such patch
 just after the release of 2.6.37-rc1, after having all those conflicts
 solved.

I agree that the big scancode patches from the input tree should go 
first. I keep updating my patchset as the media_tree (staging/v2.6.37 
branch) changes so I have no problem sending an updated patchset at a 
suitable time in the future.

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

Re: [linux-dvb] [Patch] Correct Signal Strength values for STB0899

2010-09-08 Thread Mike Booth

On Thu, 9 Sep 2010 03:51:06 you wrote:
 thx Goga and thx to dimka_9 for his great work.
 
 I hope those guys will include it in the driver
 
 regards
 
 Newsy
 
 --- Goga777 goga...@bk.ru schrieb am Mi, 8.9.2010:
  Von: Goga777 goga...@bk.ru
  Betreff: Re: [linux-dvb] [Patch] Correct Signal Strength values for
  STB0899 An: linux-...@linuxtv.org
  CC: linux-media@vger.kernel.org
  Datum: Mittwoch, 8. September, 2010 19:47 Uhr
  
   first of all I have to say that
  
  this patch is not from me.
  
   It's from rotor-0.1.4mh-v1.2.tar.gz
   Thx to the author of that patch and the modified rotor
  
  Plugin. I think he's a friend of Mike Booth
  
   I think it should be included into s2-liplianin.
   With this patch all dvb-s and dvb-s2 signal strength
  
  values are scaled correctly.
  
  
  FYI - this patch from Russian DVB VDR forum. Author is
  dimka_9
  http://linuxdvb.org.ru/wbb/index.php?page=ThreadpostID=11883#post11883
  
  
  Goga
  
  ___
  linux-dvb users mailing list
  For V4L/DVB development, please use instead linux-media@vger.kernel.org
  linux-...@linuxtv.org
  http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
 
 --
 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


We ( Mark and I) have been using dmka_9s patch for some months now haviong 
included it in rotor.

It works fine here and should be include inthe driver.

PS has anyone been able to fix BER and UNC?

Refard

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

Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver

Em 06-09-2010 18:26, Maxim Levitsky escreveu:
 Hi,
 
 Here is full overview of my patches:
 
 Patch #1 fixes races in ir thread.
 It fixes the case when ktherad_stop waits forever for the thread.
 This happens on module unload and therefore it never finishes.
 Sorry for introducing this bug.
 
 Patch #2, fixes a crash on my module load.
 It happens because ir core initializes the input device a bit early,
 therefore it could be accessed while still not set up.
 
 Patch #3 fixes a small typo in lirc code that makes it impossible to use tx 
 duty cycle setting.
 
 Patch #4 fixes a problem seen on my system that results in stuck down forever 
 key.
 
 Patch #5 adds few keys to MCE keymap that were found on laptop of an user I 
 tested this driver with
 
 Patch #6, is a combined update ti my driver. It contains lot of refactoring 
 thanks to docs I have now,
 and lot of fixes, and supports latest version of firmware (and I have 4 users 
 asking for that)
 It is quite huge, but it would be a tedios job to break it up. This can't 
 introduce regressions
 because the ene_ir was never released. In addition to that it was tested by 
 me and another two users.
 
 Patch #7 the really only patch that touches drivers I don't have does touch 
 the ir-core.
 It is quite small, and it adds a proper solution to dilema about what to do 
 with huge space between keypresses.
 Now this space is just truncated by the driver with timeout flag.
 The lirc codec then ensures that right sample is send to the lircd.
 Please review and test it.
 
 Patch #8 is very simple. It just builds on top of patch #7 and adds carrier 
 reports to ene driver.

For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's review 
also.

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

Re: [PATCH 7/8] IR: extend ir_raw_event and do refactoring

Em 06-09-2010 18:26, Maxim Levitsky escreveu:
 Add new event types for timeout  carrier report
 Move timeout handling from ir_raw_event_store_with_filter to
 ir-lirc-codec, where it is really needed.
 Now lirc bridge ensures proper gap handling.
 Extend lirc bridge for carrier  timeout reports
 
 Note: all new ir_raw_event variables now should be initialized
 like that: DEFINE_IR_RAW_EVENT(ev);
 
 To clean an existing event, use init_ir_raw_event(ev);
 
 Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
 ---
  drivers/media/IR/ene_ir.c  |4 +-
  drivers/media/IR/ir-core-priv.h|   13 ++-
  drivers/media/IR/ir-jvc-decoder.c  |5 +-
  drivers/media/IR/ir-lirc-codec.c   |   78 
 +++-
  drivers/media/IR/ir-nec-decoder.c  |5 +-
  drivers/media/IR/ir-raw-event.c|   45 +++-
  drivers/media/IR/ir-rc5-decoder.c  |5 +-
  drivers/media/IR/ir-rc6-decoder.c  |5 +-
  drivers/media/IR/ir-sony-decoder.c |5 +-
  drivers/media/IR/mceusb.c  |3 +-
  drivers/media/IR/streamzap.c   |8 ++-
  include/media/ir-core.h|   40 ---
  12 files changed, 153 insertions(+), 63 deletions(-)
 
 diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
 index 7880d9c..dc32509 100644
 --- a/drivers/media/IR/ene_ir.c
 +++ b/drivers/media/IR/ene_ir.c
 @@ -701,7 +701,7 @@ static irqreturn_t ene_isr(int irq, void *data)
   unsigned long flags;
   irqreturn_t retval = IRQ_NONE;
   struct ene_device *dev = (struct ene_device *)data;
 - struct ir_raw_event ev;
 + DEFINE_IR_RAW_EVENT(ev);
  
   spin_lock_irqsave(dev-hw_lock, flags);
  
 @@ -904,7 +904,7 @@ static int ene_set_learning_mode(void *data, int enable)
  }
  
  /* outside interface: enable or disable idle mode */
 -static void ene_rx_set_idle(void *data, int idle)
 +static void ene_rx_set_idle(void *data, bool idle)
  {
   struct ene_device *dev = (struct ene_device *)data;
  
 diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
 index 5d7e08f..2559e72 100644
 --- a/drivers/media/IR/ir-core-priv.h
 +++ b/drivers/media/IR/ir-core-priv.h
 @@ -82,6 +82,12 @@ struct ir_raw_event_ctrl {
   struct ir_input_dev *ir_dev;
   struct lirc_driver *drv;
   int carrier_low;
 +
 + ktime_t gap_start;
 + u64 gap_duration;
 + bool gap;
 + bool send_timeout_reports;
 +
   } lirc;
  };
  
 @@ -109,9 +115,14 @@ static inline void decrease_duration(struct ir_raw_event 
 *ev, unsigned duration)
   ev-duration -= duration;
  }
  
 +/* Returns true if event is normal pulse/space event */
 +static inline bool is_timing_event(struct ir_raw_event ev)
 +{
 + return !ev.carrier_report  !ev.reset;
 +}
 +
  #define TO_US(duration)  DIV_ROUND_CLOSEST((duration), 
 1000)
  #define TO_STR(is_pulse) ((is_pulse) ? pulse : space)
 -#define IS_RESET(ev) (ev.duration == 0)
  /*
   * Routines from ir-sysfs.c - Meant to be called only internally inside
   * ir-core
 diff --git a/drivers/media/IR/ir-jvc-decoder.c 
 b/drivers/media/IR/ir-jvc-decoder.c
 index 77a89c4..63dca6e 100644
 --- a/drivers/media/IR/ir-jvc-decoder.c
 +++ b/drivers/media/IR/ir-jvc-decoder.c
 @@ -50,8 +50,9 @@ static int ir_jvc_decode(struct input_dev *input_dev, 
 struct ir_raw_event ev)
   if (!(ir_dev-raw-enabled_protocols  IR_TYPE_JVC))
   return 0;
  
 - if (IS_RESET(ev)) {
 - data-state = STATE_INACTIVE;
 + if (!is_timing_event(ev)) {
 + if (ev.reset)
 + data-state = STATE_INACTIVE;
   return 0;
   }
  
 diff --git a/drivers/media/IR/ir-lirc-codec.c 
 b/drivers/media/IR/ir-lirc-codec.c
 index e63f757..0f40bc2 100644
 --- a/drivers/media/IR/ir-lirc-codec.c
 +++ b/drivers/media/IR/ir-lirc-codec.c
 @@ -32,6 +32,7 @@
  static int ir_lirc_decode(struct input_dev *input_dev, struct ir_raw_event 
 ev)
  {
   struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
 + struct lirc_codec *lirc = ir_dev-raw-lirc;
   int sample;
  
   if (!(ir_dev-raw-enabled_protocols  IR_TYPE_LIRC))
 @@ -40,21 +41,57 @@ static int ir_lirc_decode(struct input_dev *input_dev, 
 struct ir_raw_event ev)
   if (!ir_dev-raw-lirc.drv || !ir_dev-raw-lirc.drv-rbuf)
   return -EINVAL;
  
 - if (IS_RESET(ev))
 + /* Packet start */
 + if (ev.reset)
   return 0;
  
 - IR_dprintk(2, LIRC data transfer started (%uus %s)\n,
 -TO_US(ev.duration), TO_STR(ev.pulse));
 + /* Carrier reports */
 + if (ev.carrier_report) {
 + sample = LIRC_FREQUENCY(ev.carrier);
 +
 + /* Packet end */
 + } else if (ev.timeout) {
 +
 + if (lirc-gap)
 + return 0;
 +
 + lirc-gap_start = ktime_get();
 + lirc-gap = true;
 +

Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver

On Wed, Sep 08, 2010 at 06:54:02PM -0300, Mauro Carvalho Chehab wrote:
 Em 06-09-2010 18:26, Maxim Levitsky escreveu:
  Hi,
  
  Here is full overview of my patches:
  
  Patch #1 fixes races in ir thread.
  It fixes the case when ktherad_stop waits forever for the thread.
  This happens on module unload and therefore it never finishes.
  Sorry for introducing this bug.
  
  Patch #2, fixes a crash on my module load.
  It happens because ir core initializes the input device a bit early,
  therefore it could be accessed while still not set up.
  
  Patch #3 fixes a small typo in lirc code that makes it impossible to use tx 
  duty cycle setting.
  
  Patch #4 fixes a problem seen on my system that results in stuck down 
  forever key.
  
  Patch #5 adds few keys to MCE keymap that were found on laptop of an user I 
  tested this driver with
  
  Patch #6, is a combined update ti my driver. It contains lot of refactoring 
  thanks to docs I have now,
  and lot of fixes, and supports latest version of firmware (and I have 4 
  users asking for that)
  It is quite huge, but it would be a tedios job to break it up. This can't 
  introduce regressions
  because the ene_ir was never released. In addition to that it was tested by 
  me and another two users.
  
  Patch #7 the really only patch that touches drivers I don't have does touch 
  the ir-core.
  It is quite small, and it adds a proper solution to dilema about what to do 
  with huge space between keypresses.
  Now this space is just truncated by the driver with timeout flag.
  The lirc codec then ensures that right sample is send to the lircd.
  Please review and test it.
  
  Patch #8 is very simple. It just builds on top of patch #7 and adds carrier 
  reports to ene driver.
 
 For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's 
 review also.

I've finally got them all applied atop current media_tree staging/v2.6.37,
though none of the streamzap bits in patch 7 are applicable any longer.
Will try to get through looking and commenting (and testing) of the rest
of them tonight.


-- 
Jarod Wilson
ja...@redhat.com

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

Re: [PATCH 7/8] IR: extend ir_raw_event and do refactoring

On Wed, Sep 08, 2010 at 07:42:04PM -0300, Mauro Carvalho Chehab wrote:
 Em 06-09-2010 18:26, Maxim Levitsky escreveu:
  Add new event types for timeout  carrier report
  Move timeout handling from ir_raw_event_store_with_filter to
  ir-lirc-codec, where it is really needed.
  Now lirc bridge ensures proper gap handling.
  Extend lirc bridge for carrier  timeout reports
  
  Note: all new ir_raw_event variables now should be initialized
  like that: DEFINE_IR_RAW_EVENT(ev);
  
  To clean an existing event, use init_ir_raw_event(ev);
  
  Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
  ---
   drivers/media/IR/ene_ir.c  |4 +-
   drivers/media/IR/ir-core-priv.h|   13 ++-
   drivers/media/IR/ir-jvc-decoder.c  |5 +-
   drivers/media/IR/ir-lirc-codec.c   |   78 
  +++-
   drivers/media/IR/ir-nec-decoder.c  |5 +-
   drivers/media/IR/ir-raw-event.c|   45 +++-
   drivers/media/IR/ir-rc5-decoder.c  |5 +-
   drivers/media/IR/ir-rc6-decoder.c  |5 +-
   drivers/media/IR/ir-sony-decoder.c |5 +-
   drivers/media/IR/mceusb.c  |3 +-
   drivers/media/IR/streamzap.c   |8 ++-
   include/media/ir-core.h|   40 ---
   12 files changed, 153 insertions(+), 63 deletions(-)
  
  diff --git a/drivers/media/IR/ene_ir.c b/drivers/media/IR/ene_ir.c
  index 7880d9c..dc32509 100644
  --- a/drivers/media/IR/ene_ir.c
  +++ b/drivers/media/IR/ene_ir.c
  @@ -701,7 +701,7 @@ static irqreturn_t ene_isr(int irq, void *data)
  unsigned long flags;
  irqreturn_t retval = IRQ_NONE;
  struct ene_device *dev = (struct ene_device *)data;
  -   struct ir_raw_event ev;
  +   DEFINE_IR_RAW_EVENT(ev);
   
  spin_lock_irqsave(dev-hw_lock, flags);
   
  @@ -904,7 +904,7 @@ static int ene_set_learning_mode(void *data, int enable)
   }
   
   /* outside interface: enable or disable idle mode */
  -static void ene_rx_set_idle(void *data, int idle)
  +static void ene_rx_set_idle(void *data, bool idle)
   {
  struct ene_device *dev = (struct ene_device *)data;
   
  diff --git a/drivers/media/IR/ir-core-priv.h 
  b/drivers/media/IR/ir-core-priv.h
  index 5d7e08f..2559e72 100644
  --- a/drivers/media/IR/ir-core-priv.h
  +++ b/drivers/media/IR/ir-core-priv.h
  @@ -82,6 +82,12 @@ struct ir_raw_event_ctrl {
  struct ir_input_dev *ir_dev;
  struct lirc_driver *drv;
  int carrier_low;
  +
  +   ktime_t gap_start;
  +   u64 gap_duration;
  +   bool gap;
  +   bool send_timeout_reports;
  +
  } lirc;
   };
   
  @@ -109,9 +115,14 @@ static inline void decrease_duration(struct 
  ir_raw_event *ev, unsigned duration)
  ev-duration -= duration;
   }
   
  +/* Returns true if event is normal pulse/space event */
  +static inline bool is_timing_event(struct ir_raw_event ev)
  +{
  +   return !ev.carrier_report  !ev.reset;
  +}
  +
   #define TO_US(duration)DIV_ROUND_CLOSEST((duration), 
  1000)
   #define TO_STR(is_pulse)   ((is_pulse) ? pulse : space)
  -#define IS_RESET(ev)   (ev.duration == 0)
   /*
* Routines from ir-sysfs.c - Meant to be called only internally inside
* ir-core
  diff --git a/drivers/media/IR/ir-jvc-decoder.c 
  b/drivers/media/IR/ir-jvc-decoder.c
  index 77a89c4..63dca6e 100644
  --- a/drivers/media/IR/ir-jvc-decoder.c
  +++ b/drivers/media/IR/ir-jvc-decoder.c
  @@ -50,8 +50,9 @@ static int ir_jvc_decode(struct input_dev *input_dev, 
  struct ir_raw_event ev)
  if (!(ir_dev-raw-enabled_protocols  IR_TYPE_JVC))
  return 0;
   
  -   if (IS_RESET(ev)) {
  -   data-state = STATE_INACTIVE;
  +   if (!is_timing_event(ev)) {
  +   if (ev.reset)
  +   data-state = STATE_INACTIVE;
  return 0;
  }
   
  diff --git a/drivers/media/IR/ir-lirc-codec.c 
  b/drivers/media/IR/ir-lirc-codec.c
  index e63f757..0f40bc2 100644
  --- a/drivers/media/IR/ir-lirc-codec.c
  +++ b/drivers/media/IR/ir-lirc-codec.c
  @@ -32,6 +32,7 @@
   static int ir_lirc_decode(struct input_dev *input_dev, struct ir_raw_event 
  ev)
   {
  struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
  +   struct lirc_codec *lirc = ir_dev-raw-lirc;
  int sample;
   
  if (!(ir_dev-raw-enabled_protocols  IR_TYPE_LIRC))
  @@ -40,21 +41,57 @@ static int ir_lirc_decode(struct input_dev *input_dev, 
  struct ir_raw_event ev)
  if (!ir_dev-raw-lirc.drv || !ir_dev-raw-lirc.drv-rbuf)
  return -EINVAL;
   
  -   if (IS_RESET(ev))
  +   /* Packet start */
  +   if (ev.reset)
  return 0;
   
  -   IR_dprintk(2, LIRC data transfer started (%uus %s)\n,
  -  TO_US(ev.duration), TO_STR(ev.pulse));
  +   /* Carrier reports */
  +   if (ev.carrier_report) {
  +   sample = LIRC_FREQUENCY(ev.carrier);
  +
  +   /* Packet end */
  +   } else if (ev.timeout) {
  +
  +   if (lirc-gap)

Re: [PATCH 7/8] IR: extend ir_raw_event and do refactoring

Em 08-09-2010 19:49, David Härdeman escreveu:
 On Wed, Sep 08, 2010 at 07:42:04PM -0300, Mauro Carvalho Chehab wrote:
 Em 06-09-2010 18:26, Maxim Levitsky escreveu:
 diff --git a/drivers/media/IR/ir-rc6-decoder.c 
 b/drivers/media/IR/ir-rc6-decoder.c
 index f1624b8..d25da91 100644
 --- a/drivers/media/IR/ir-rc6-decoder.c
 +++ b/drivers/media/IR/ir-rc6-decoder.c
 @@ -85,8 +85,9 @@ static int ir_rc6_decode(struct input_dev *input_dev, 
 struct ir_raw_event ev)
 if (!(ir_dev-raw-enabled_protocols  IR_TYPE_RC6))
 return 0;
  
 -   if (IS_RESET(ev)) {
 -   data-state = STATE_INACTIVE;
 +   if (!is_timing_event(ev)) {
 +   if (ev.reset)

 Again, why do you need to test first for !is_timing_event()?
 
 Because the decoder should return early if the event is not a timing 
 event (the return 0 two lines below)...think carrier report event...

Yeah, I saw that. I was supposed to remove all the comments about that, but I
forgot to remove the last one ;)

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

Re: [PATCH 4/6] Input: winbond-cir - switch to using new keycode interface

On Wed, Sep 08, 2010 at 11:16:17PM +0200, David Härdeman wrote:
 On Wed, Sep 08, 2010 at 12:42:00AM -0700, Dmitry Torokhov wrote:
  Switch the code to use new style of getkeycode and setkeycode
  methods to allow retrieving and setting keycodes not only by
  their scancodes but also by index.
  
  Signed-off-by: Dmitry Torokhov d...@mail.ru
  ---
  
   drivers/input/misc/winbond-cir.c |  248 
  +-
   1 files changed, 163 insertions(+), 85 deletions(-)
 
 Thanks for doing the conversion for me, but I think you can skip this 
 patch. The driver will (if I understood your patchset correctly) still 
 work with the old get/setkeycode ioctls and I have a patch lined up that 
 converts winbond-cir.c to use ir-core which means all of the input 
 related code is removed.
 

Yes, it should still work with old get/setkeycode. What are the plans
for your patch? .37 or later?

-- 
Dmitry
--
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 7/8] IR: extend ir_raw_event and do refactoring

On Wed, 2010-09-08 at 13:27 -0400, Jarod Wilson wrote:
 On Wed, Sep 08, 2010 at 12:50:46PM -0400, Andy Walls wrote:
  On Wed, 2010-09-08 at 11:26 -0400, Jarod Wilson wrote:
   On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky maximlevit...@gmail.com 
   wrote:

   
   I'm generally good with this entire patch, but the union usage looks a
   bit odd, as the members aren't of the same size, which is generally
   what I've come to expect looking at other code.
  
  Having a union with different sized members is perfectly valid C code. 
  

 Yeah, no, I know that it'll work, just that most of the unions I've
 actually paid any attention to had members all of the same size. Seemed
 like sort of an unwritten rule for in-kernel use. But its probably just
 fine.

Well if it's an unwritten rule, not everyone is following it. :)
There are numerous counter-examples in include/linux/*.h .  Here are a
few easy to see ones:

include/linux/input.h:
union in struct ff_effect: ff_rumble vs. ff_periodic   

include/linux/i2c.h
union i2c_smbus_data: byte vs. word vs. block[]

include/linux/kfifo.h
DECLARE_KFIFO



I'd be inclined to
   simply move duty_cycle out of the union and leave just duration and
   carrier in it.
  
  That's not necessary and it could be confusing depending on where you
  put duty_cycle.
 
 There's that. But without having code that actually uses duty_cycle in a
 meaningful way yet, its hard to say for sure. If carrier and duty_cycle
 were only being sent out in their own events, you might actually want a
 union of duration, carrier and duty_cycle. Though I suspect we'll probably
 want to pass along carrier and duty_cycle at the same time.

I suspect you're right on that.  I don't have any experience with
hardware that can actually estimate carrier freq or duty cycle.  I
suspect they can be measured together using edge detection on both
rising and falling edges.

Regards,
Andy




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

Re: [PATCH 4/6] Input: winbond-cir - switch to using new keycode interface

On Wed, Sep 08, 2010 at 04:00:04PM -0700, Dmitry Torokhov wrote:
 On Wed, Sep 08, 2010 at 11:16:17PM +0200, David Härdeman wrote:
  On Wed, Sep 08, 2010 at 12:42:00AM -0700, Dmitry Torokhov wrote:
   Switch the code to use new style of getkeycode and setkeycode
   methods to allow retrieving and setting keycodes not only by
   their scancodes but also by index.
   
   Signed-off-by: Dmitry Torokhov d...@mail.ru
   ---
   
drivers/input/misc/winbond-cir.c |  248 
   +-
1 files changed, 163 insertions(+), 85 deletions(-)
  
  Thanks for doing the conversion for me, but I think you can skip this 
  patch. The driver will (if I understood your patchset correctly) still 
  work with the old get/setkeycode ioctls and I have a patch lined up that 
  converts winbond-cir.c to use ir-core which means all of the input 
  related code is removed.
  
 
 Yes, it should still work with old get/setkeycode. What are the plans
 for your patch? .37 or later?

Up to Mauro but I believe it's .37 (sometime after your input patches 
land).

-- 
David Härdeman
--
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/6] Input: winbond-cir - switch to using new keycode interface

Em 08-09-2010 20:09, David Härdeman escreveu:
 On Wed, Sep 08, 2010 at 04:00:04PM -0700, Dmitry Torokhov wrote:
 On Wed, Sep 08, 2010 at 11:16:17PM +0200, David Härdeman wrote:
 On Wed, Sep 08, 2010 at 12:42:00AM -0700, Dmitry Torokhov wrote:
 Switch the code to use new style of getkeycode and setkeycode
 methods to allow retrieving and setting keycodes not only by
 their scancodes but also by index.

 Signed-off-by: Dmitry Torokhov d...@mail.ru
 ---

  drivers/input/misc/winbond-cir.c |  248 
 +-
  1 files changed, 163 insertions(+), 85 deletions(-)

 Thanks for doing the conversion for me, but I think you can skip this 
 patch. The driver will (if I understood your patchset correctly) still 
 work with the old get/setkeycode ioctls and I have a patch lined up that 
 converts winbond-cir.c to use ir-core which means all of the input 
 related code is removed.


 Yes, it should still work with old get/setkeycode. What are the plans
 for your patch? .37 or later?
 
 Up to Mauro but I believe it's .37 (sometime after your input patches 
 land).

.37 seems feasible, if you submit your patch in time for review.

Maybe I should create a temporary staging tree for .37 with the input patches
applied there, to allow people to better review and test the rc patches with
everything applied.

Cheers,
Mauro.

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

Re: [PATCH 1/2] V4L/DVB: dib7770: enable the current mirror

Em 07-09-2010 12:58, Patrick Boettcher escreveu:
 Hi Mauro,
 
 On Tuesday 07 September 2010 17:50:45 pboettc...@kernellabs.com wrote:
 From: Olivier Grenie olivier.gre...@dibcom.fr

 To improve performance on DiB7770-devices enabling the current mirror
 is needed.

 This patch adds an option to the dib7000p-driver to do that and it
 creates a separate device-entry in dib0700-device to use those changes
 on hardware which is using the DiB7770.

 Cc: sta...@kernel.org

 Signed-off-by: Olivier Grenie olivier.gre...@dibcom.fr
 Signed-off-by: Patrick Boettcher patrick.boettc...@dibcom.fr
 ---
  drivers/media/dvb/dvb-usb/dib0700_devices.c |   53
 ++- drivers/media/dvb/frontends/dib7000p.c  | 
   2 +
  drivers/media/dvb/frontends/dib7000p.h  |3 ++
  3 files changed, 57 insertions(+), 1 deletions(-)
 
 This is the patch I was talking to you about in my last Email. This one needs 
 to be quickly applied to 2.6.35. Well ... quickly ... as soon as possible in  
 sense of when you have a free time slot.
 
 This patch help to optimize the performance of the DiB7770-chip which can be 
 found in several devices out there right now.
 
 It was tested and applied on 2.6.36-rc3, It should apply cleanly on 2.6.35.

Ok. Patch 2/2 is also important for -stable?

 
 Thanks in advance for your help,
 
 Patrick.

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

Re: [PATCH 7/8] IR: extend ir_raw_event and do refactoring

Em 08-09-2010 20:02, Andy Walls escreveu:
 On Wed, 2010-09-08 at 13:27 -0400, Jarod Wilson wrote:
 
  I'd be inclined to
 simply move duty_cycle out of the union and leave just duration and
 carrier in it.

 That's not necessary and it could be confusing depending on where you
 put duty_cycle.

 There's that. But without having code that actually uses duty_cycle in a
 meaningful way yet, its hard to say for sure. If carrier and duty_cycle
 were only being sent out in their own events, you might actually want a
 union of duration, carrier and duty_cycle. Though I suspect we'll probably
 want to pass along carrier and duty_cycle at the same time.
 
 I suspect you're right on that.  I don't have any experience with
 hardware that can actually estimate carrier freq or duty cycle.  I
 suspect they can be measured together using edge detection on both
 rising and falling edges.

As duty cycle is not currently used, the better is to just remove it from
the struct, adding it on a separate patch, together with a code that will
need it.

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

Re: [RFC/PATCH v4 03/11] media: Entities, pads and links

Em 20-08-2010 12:29, Laurent Pinchart escreveu:
 As video hardware pipelines become increasingly complex and
 configurable, the current hardware description through v4l2 subdevices
 reaches its limits. In addition to enumerating and configuring
 subdevices, video camera drivers need a way to discover and modify at
 runtime how those subdevices are connected. This is done through new
 elements called entities, pads and links.
 
 An entity is a basic media hardware building block. It can correspond to
 a large variety of logical blocks such as physical hardware devices
 (CMOS sensor for instance), logical hardware devices (a building block
 in a System-on-Chip image processing pipeline), DMA channels or physical
 connectors.
 
 A pad is a connection endpoint through which an entity can interact with
 other entities. Data (not restricted to video) produced by an entity
 flows from the entity's output to one or more entity inputs. Pads should
 not be confused with physical pins at chip boundaries.
 
 A link is a point-to-point oriented connection between two pads, either
 on the same entity or on different entities. Data flows from a source
 pad to a sink pad.
 
 Links are stored in the source entity. To make backwards graph walk
 faster, a copy of all links is also stored in the sink entity. The copy
 is known as a backlink and is only used to help graph traversal.
 
 The entity API is made of three functions:
 
 - media_entity_init() initializes an entity. The caller must provide an
 array of pads as well as an estimated number of links. The links array
 is allocated dynamically and will be reallocated if it grows beyond the
 initial estimate.
 
 - media_entity_cleanup() frees resources allocated for an entity. It
 must be called during the cleanup phase after unregistering the entity
 and before freeing it.
 
 - media_entity_create_link() creates a link between two entities. An
 entry in the link array of each entity is allocated and stores pointers
 to source and sink pads.
 
 When a media device is unregistered, all its entities are unregistered
 automatically.
 
 The code is based on Hans Verkuil hverk...@xs4all.nl initial work.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
 ---
  Documentation/media-framework.txt |  149 
 +
  drivers/media/Makefile|2 +-
  drivers/media/media-device.c  |   53 +
  drivers/media/media-entity.c  |  145 
  include/media/media-device.h  |   19 +
  include/media/media-entity.h  |   96 
  6 files changed, 463 insertions(+), 1 deletions(-)
  create mode 100644 drivers/media/media-entity.c
  create mode 100644 include/media/media-entity.h
 
 diff --git a/Documentation/media-framework.txt 
 b/Documentation/media-framework.txt
 index 89dc7ad..35d74e4 100644
 --- a/Documentation/media-framework.txt
 +++ b/Documentation/media-framework.txt
 @@ -35,6 +35,30 @@ belong to userspace.
  The media kernel API aims at solving those problems.
  
  
 +Abstract media device model
 +---
 +
 +Discovering a device internal topology, and configuring it at runtime, is one
 +of the goals of the media framework. To achieve this, hardware devices are
 +modeled as an oriented graph of building blocks called entities connected
 +through pads.
 +
 +An entity is a basic media hardware building block. It can correspond to
 +a large variety of logical blocks such as physical hardware devices
 +(CMOS sensor for instance), logical hardware devices (a building block
 +in a System-on-Chip image processing pipeline), DMA channels or physical
 +connectors.
 +
 +A pad is a connection endpoint through which an entity can interact with
 +other entities. Data (not restricted to video) produced by an entity
 +flows from the entity's output to one or more entity inputs. Pads should
 +not be confused with physical pins at chip boundaries.
 +
 +A link is a point-to-point oriented connection between two pads, either
 +on the same entity or on different entities. Data flows from a source
 +pad to a sink pad.
 +
 +
  Media device
  
  
 @@ -89,3 +113,128 @@ Drivers unregister media device instances by calling
  
  Unregistering a media device that hasn't been registered is *NOT* safe.
  
 +
 +Entities, pads and links
 +
 +
 +- Entities
 +
 +Entities are represented by a struct media_entity instance, defined in
 +include/media/media-entity.h. The structure is usually embedded into a
 +higher-level structure, such as a v4l2_subdev or video_device instance,
 +although drivers can allocate entities directly.
 +
 +Drivers initialize entities by calling
 +
 + media_entity_init(struct media_entity *entity, u16 num_pads,
 +   struct media_pad *pads, u16 extra_links);
 +
 +The media_entity name, type, flags, revision

Re: [RFC/PATCH v4 04/11] media: Entity graph traversal

Em 20-08-2010 12:29, Laurent Pinchart escreveu:
 From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
 
 Add media entity graph traversal. The traversal follows active links by
 depth first. Traversing graph backwards is prevented by comparing the next
 possible entity in the graph with the previous one. Multiply connected
 graphs are thus not supported.
 
 Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Vimarsh Zutshi vimarsh.zut...@nokia.com
 ---
  Documentation/media-framework.txt |   40 +
  drivers/media/media-entity.c  |  115 
 +
  include/media/media-entity.h  |   15 +
  3 files changed, 170 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/media-framework.txt 
 b/Documentation/media-framework.txt
 index 35d74e4..a599824 100644
 --- a/Documentation/media-framework.txt
 +++ b/Documentation/media-framework.txt
 @@ -238,3 +238,43 @@ Links have flags that describe the link capabilities and 
 state.
   MEDIA_LINK_FLAG_ACTIVE must also be set since an immutable link is
   always active.
  
 +
 +Graph traversal
 +---
 +
 +The media framework provides APIs to iterate over entities in a graph.
 +
 +To iterate over all entities belonging to a media device, drivers can use the
 +media_device_for_each_entity macro, defined in include/media/media-device.h.
 +
 + struct media_entity *entity;
 +
 + media_device_for_each_entity(entity, mdev) {
 + /* entity will point to each entity in turn */
 + ...
 + }
 +
 +Drivers might also need to iterate over all entities in a graph that can be
 +reached only through active links starting at a given entity. The media
 +framework provides a depth-first graph traversal API for that purpose.
 +
 +Note that graphs with cycles (whether directed or undirected) are *NOT*
 +supported by the graph traversal API.

Please document that a maximum depth exists to prevent loops, currently
defined as 16 (MEDIA_ENTITY_ENUM_MAX_DEPTH).

 +
 +Drivers initiate a graph traversal by calling
 +
 + media_entity_graph_walk_start(struct media_entity_graph *graph,
 +   struct media_entity *entity);
 +
 +The graph structure, provided by the caller, is initialized to start graph
 +traversal at the given entity.
 +
 +Drivers can then retrieve the next entity by calling
 +
 + media_entity_graph_walk_next(struct media_entity_graph *graph);
 +
 +When the graph traversal is complete the function will return NULL.
 +
 +Graph traversal can be interrupted at any moment. No cleanup function call is
 +required and the graph structure can be freed normally.
 +
 diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
 index 541063b..c277c18 100644
 --- a/drivers/media/media-entity.c
 +++ b/drivers/media/media-entity.c
 @@ -82,6 +82,121 @@ media_entity_cleanup(struct media_entity *entity)
  }
  EXPORT_SYMBOL(media_entity_cleanup);
  
 +/* 
 -
 + * Graph traversal
 + */
 +
 +static struct media_entity *
 +media_entity_other(struct media_entity *entity, struct media_link *link)
 +{
 + if (link-source-entity == entity)
 + return link-sink-entity;
 + else
 + return link-source-entity;
 +}
 +
 +/* push an entity to traversal stack */
 +static void stack_push(struct media_entity_graph *graph,
 +struct media_entity *entity)
 +{
 + if (graph-top == MEDIA_ENTITY_ENUM_MAX_DEPTH - 1) {
 + WARN_ON(1);
 + return;
 + }
 + graph-top++;
 + graph-stack[graph-top].link = 0;
 + graph-stack[graph-top].entity = entity;
 +}
 +
 +static struct media_entity *stack_pop(struct media_entity_graph *graph)
 +{
 + struct media_entity *entity;
 +
 + entity = graph-stack[graph-top].entity;
 + graph-top--;
 +
 + return entity;
 +}
 +
 +#define stack_peek(en)   ((en)-stack[(en)-top - 1].entity)
 +#define link_top(en) ((en)-stack[(en)-top].link)
 +#define stack_top(en)((en)-stack[(en)-top].entity)
 +
 +/**
 + * media_entity_graph_walk_start - Start walking the media graph at a given 
 entity
 + * @graph: Media graph structure that will be used to walk the graph
 + * @entity: Starting entity
 + *
 + * This function initializes the graph traversal structure to walk the 
 entities
 + * graph starting at the given entity. The traversal structure must not be
 + * modified by the caller during graph traversal. When done the structure can
 + * safely be freed.
 + */
 +void media_entity_graph_walk_start(struct media_entity_graph *graph,
 +struct media_entity *entity)
 +{
 + graph-top = 0;
 + graph-stack[graph-top].entity = NULL;
 + stack_push(graph, entity);
 +}
 +EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
 +
 +/**
 + *

Re: [RFC/PATCH v4 05/11] media: Reference count and power handling

Em 20-08-2010 12:29, Laurent Pinchart escreveu:
 From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
 
 Basically these are the interface functions:
 
 media_entity_get() - acquire entity
 media_entity_put() - release entity
 
   If the entity is of node type, the power change is distributed to
   all connected entities. For non-nodes it only affects that very
   node. A mutex is used to serialise access to the entity graph.
 
 In the background there's a depth-first search algorithm that traverses the
 active links in the graph. All these functions parse the graph to implement
 whatever they're to do.
 
 The module counters are increased/decreased in media_entity_get/put to
 prevent module unloading when an entity is referenced.
 
 Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
 ---
  Documentation/media-framework.txt |   37 +
  drivers/media/media-device.c  |1 +
  drivers/media/media-entity.c  |  146 
 +
  include/media/media-device.h  |4 +
  include/media/media-entity.h  |   15 
  5 files changed, 203 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/media-framework.txt 
 b/Documentation/media-framework.txt
 index a599824..59649e9 100644
 --- a/Documentation/media-framework.txt
 +++ b/Documentation/media-framework.txt
 @@ -278,3 +278,40 @@ When the graph traversal is complete the function will 
 return NULL.
  Graph traversal can be interrupted at any moment. No cleanup function call is
  required and the graph structure can be freed normally.
  
 +
 +Reference counting and power handling
 +-
 +
 +Before accessing type-specific entities operations (such as the V4L2
 +sub-device operations), drivers must acquire a reference to the entity. This
 +ensures that the entity will be powered on and ready to accept requests.
 +Similarly, after being done with an entity, drivers must release the
 +reference.
 +
 + media_entity_get(struct media_entity *entity)
 +
 +The function will increase the entity reference count. If the entity is a 
 node
 +(MEDIA_ENTITY_TYPE_NODE type), the reference count of all entities it is
 +connected to, both directly or indirectly, through active links is increased.
 +This ensures that the whole media pipeline will be ready to process
 +
 +Acquiring a reference to an entity increases the media device module 
 reference
 +count to prevent module unloading when an entity is being used.
 +
 +media_entity_get will return a pointer to the entity if successful, or NULL
 +otherwise.
 +
 + media_entity_put(struct media_entity *entity)
 +
 +The function will decrease the entity reference count and, for node entities,
 +like media_entity_get, the reference count of all connected entities. Calling
 +media_entity_put with a NULL argument is valid and will return immediately.
 +
 +When the first reference to an entity is acquired, or the last reference
 +released, the entity's set_power operation is called. Entity drivers must
 +implement the operation if they need to perform any power management task,
 +such as turning powers or clocks on or off. If no power management is
 +required, drivers don't need to provide a set_power operation. The operation
 +is allowed to fail when turning power on, in which case the media_entity_get
 +function will return NULL.

The idea of doing power management via media entity get/put doesn't seem right.
The mediabus interface and its usage should be optional, and only specialized
applications will likely implement it. If a refcount 0 means power off, it ends
that a device implementing the media bus will not work with V4L2 applications.

 +
 diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
 index eeb002e..c309d3c 100644
 --- a/drivers/media/media-device.c
 +++ b/drivers/media/media-device.c
 @@ -71,6 +71,7 @@ int __must_check media_device_register(struct media_device 
 *mdev)
   mdev-entity_id = 1;
   INIT_LIST_HEAD(mdev-entities);
   spin_lock_init(mdev-lock);
 + mutex_init(mdev-graph_mutex);
  
   /* Register the device node. */
   mdev-devnode.fops = media_device_fops;
 diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
 index c277c18..da4fef6 100644
 --- a/drivers/media/media-entity.c
 +++ b/drivers/media/media-entity.c
 @@ -21,6 +21,7 @@
  #include linux/module.h
  #include linux/slab.h
  #include media/media-entity.h
 +#include media/media-device.h
  
  /**
   * media_entity_init - Initialize a media entity
 @@ -194,6 +195,151 @@ media_entity_graph_walk_next(struct media_entity_graph 
 *graph)
  EXPORT_SYMBOL_GPL(media_entity_graph_walk_next);
  
  /* 
 -
 + * Power state handling
 + */
 +
 +/* Apply use count to an entity. */

Re: [RFC/PATCH v4 08/11] media: Links setup

Em 20-08-2010 12:29, Laurent Pinchart escreveu:
 Create the following ioctl and implement it at the media device level to
 setup links.
 
 - MEDIA_IOC_SETUP_LINK: Modify the properties of a given link
 
 The only property that can currently be modified is the ACTIVE link flag
 to activate/deactivate a link. Links marked with the IMMUTABLE link flag
 can not be activated or deactivated.
 
 Activating and deactivating a link has effects on entities' use count.
 Those changes are automatically propagated through the graph.

You need to address here the release() call: if the userspace application
dies or just exits, the device should be set into a sane state, e. g. devices
powered on should be turned off, and links activated by the application
should be de-activated.

 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
 Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
 ---
  Documentation/media-framework.txt |   81 ++-
  drivers/media/media-device.c  |   45 
  drivers/media/media-entity.c  |  208 
 +
  include/linux/media.h |1 +
  include/media/media-entity.h  |8 ++
  5 files changed, 340 insertions(+), 3 deletions(-)
 
 diff --git a/Documentation/media-framework.txt 
 b/Documentation/media-framework.txt
 index 74a137d..7894ef3 100644
 --- a/Documentation/media-framework.txt
 +++ b/Documentation/media-framework.txt
 @@ -278,6 +278,16 @@ When the graph traversal is complete the function will 
 return NULL.
  Graph traversal can be interrupted at any moment. No cleanup function call is
  required and the graph structure can be freed normally.
  
 +Helper functions can be used to find a link between two given pads, or a pad
 +connected to another pad through an active link
 +
 + media_entity_find_link(struct media_pad *source,
 +struct media_pad *sink);
 +
 + media_entity_remote_pad(struct media_pad *pad);
 +
 +Refer to the kerneldoc documentation for more information.
 +
  
  Reference counting and power handling
  -
 @@ -316,6 +326,46 @@ is allowed to fail when turning power on, in which case 
 the media_entity_get
  function will return NULL.
  
  
 +Links setup
 +---
 +
 +Link properties can be modified at runtime by calling
 +
 + media_entity_setup_link(struct media_link *link, u32 flags);
 +
 +The flags argument contains the requested new link flags.
 +
 +The only configurable property is the ACTIVE link flag to activate/deactivate
 +a link. Links marked with the IMMUTABLE link flag can not be activated or
 +deactivated.
 +
 +When a link is activated or deactivated, the media framework calls the
 +link_setup operation for the two entities at the source and sink of the link,
 +in that order. If the second link_setup call fails, another link_setup call 
 is
 +made on the first entity to restore the original link flags.
 +
 +Entity drivers must implement the link_setup operation if any of their links
 +is non-immutable. The operation must either configure the hardware or store
 +the configuration information to be applied later.
 +
 +Link activation must not have any side effect on other links. If an active
 +link at a sink pad prevents another link at the same pad from being
 +deactivated, the link_setup operation must return -EBUSY and can't implicitly
 +deactivate the first active link.
 +
 +Activating and deactivating a link has effects on entities' reference counts.
 +When two sub-graphs are connected, the reference count of each of them is
 +incremented by the total reference count of all node entities in the other
 +sub-graph. When two sub-graphs are disconnected, the reverse operation is
 +performed. In both cases the set_power operations are called accordingly,
 +ensuring that the link_setup calls are made with power active on the source
 +and sink entities.
 +
 +In other words, activating or deactivating a link propagates reference count
 +changes through the graph, and the final state is identical to what it would
 +have been if the link had been active or inactive from the start.
 +
 +
  Userspace application API
  -
  
 @@ -439,9 +489,6 @@ Valid entity flags are
  
   ioctl(int fd, int request, struct media_links_enum *argp);
  
 -Only forward links that originate at one of the entity's source pads are
 -returned during the enumeration process.
 -
  To enumerate pads and/or links for a given entity, applications set the 
 entity
  field of a media_links_enum structure and initialize the media_pad_desc and
  media_link_desc structure arrays pointed by the pads and links fields. They 
 then
 @@ -457,6 +504,9 @@ information about the entity's outbound links. The array 
 must have enough room
  to store all the entity's outbound links. The number of outbound links can be
  retrieved with the

Re: [RFC/PATCH v4 11/11] v4l: Make v4l2_subdev inherit from media_entity

Em 20-08-2010 12:29, Laurent Pinchart escreveu:
 V4L2 subdevices are media entities. As such they need to inherit from
 (include) the media_entity structure.
 
 When registering/unregistering the subdevice, the media entity is
 automatically registered/unregistered. The entity is acquired on device
 open and released on device close.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
 ---
  Documentation/video4linux/v4l2-framework.txt |   23 ++
  drivers/media/video/v4l2-device.c|   32 
 +-
  drivers/media/video/v4l2-subdev.c|   27 +-
  include/media/v4l2-subdev.h  |7 +
  4 files changed, 82 insertions(+), 7 deletions(-)
 
 diff --git a/Documentation/video4linux/v4l2-framework.txt 
 b/Documentation/video4linux/v4l2-framework.txt
 index 7ff4016..3416d93 100644
 --- a/Documentation/video4linux/v4l2-framework.txt
 +++ b/Documentation/video4linux/v4l2-framework.txt
 @@ -263,6 +263,26 @@ A sub-device driver initializes the v4l2_subdev struct 
 using:
  Afterwards you need to initialize subdev-name with a unique name and set the
  module owner. This is done for you if you use the i2c helper functions.
  
 +If integration with the media framework is needed, you must initialize the
 +media_entity struct embedded in the v4l2_subdev struct (entity field) by
 +calling media_entity_init():
 +
 + struct media_pad *pads = my_sd-pads;
 + int err;
 +
 + err = media_entity_init(sd-entity, npads, pads, 0);
 +
 +The pads array must have been previously initialized. There is no need to
 +manually set the struct media_entity type and name fields, but the revision
 +field must be initialized if needed.
 +
 +A reference to the entity will be automatically acquired/released when the
 +subdev device node (if any) is opened/closed.
 +
 +Don't forget to cleanup the media entity before the sub-device is destroyed:
 +
 + media_entity_cleanup(sd-entity);
 +
  A device (bridge) driver needs to register the v4l2_subdev with the
  v4l2_device:
  
 @@ -272,6 +292,9 @@ This can fail if the subdev module disappeared before it 
 could be registered.
  After this function was called successfully the subdev-dev field points to
  the v4l2_device.
  
 +If the v4l2_device parent device has a non-NULL mdev field, the sub-device
 +entity will be automatically registered with the media device.
 +
  You can unregister a sub-device using:
  
   v4l2_device_unregister_subdev(sd);
 diff --git a/drivers/media/video/v4l2-device.c 
 b/drivers/media/video/v4l2-device.c
 index 91452cd..4f74d01 100644
 --- a/drivers/media/video/v4l2-device.c
 +++ b/drivers/media/video/v4l2-device.c
 @@ -114,10 +114,11 @@ void v4l2_device_unregister(struct v4l2_device 
 *v4l2_dev)
  EXPORT_SYMBOL_GPL(v4l2_device_unregister);
  
  int v4l2_device_register_subdev(struct v4l2_device *v4l2_dev,
 - struct v4l2_subdev *sd)
 + struct v4l2_subdev *sd)
  {
 + struct media_entity *entity = sd-entity;
   struct video_device *vdev;
 - int ret = 0;
 + int ret;
  
   /* Check for valid input */
   if (v4l2_dev == NULL || sd == NULL || !sd-name[0])
 @@ -129,6 +130,15 @@ int v4l2_device_register_subdev(struct v4l2_device 
 *v4l2_dev,
   if (!try_module_get(sd-owner))
   return -ENODEV;
  
 + /* Register the entity. */
 + if (v4l2_dev-mdev) {
 + ret = media_device_register_entity(v4l2_dev-mdev, entity);
 + if (ret  0) {
 + module_put(sd-owner);
 + return ret;
 + }
 + }
 +
   sd-v4l2_dev = v4l2_dev;
   spin_lock(v4l2_dev-lock);
   list_add_tail(sd-list, v4l2_dev-subdevs);
 @@ -143,26 +153,36 @@ int v4l2_device_register_subdev(struct v4l2_device 
 *v4l2_dev,
   if (sd-flags  V4L2_SUBDEV_FL_HAS_DEVNODE) {
   ret = __video_register_device(vdev, VFL_TYPE_SUBDEV, -1, 1,
 sd-owner);
 - if (ret  0)
 + if (ret  0) {
   v4l2_device_unregister_subdev(sd);
 + return ret;
 + }
   }
  
 - return ret;
 + entity-v4l.major = VIDEO_MAJOR;
 + entity-v4l.minor = vdev-minor;

Hmm... it needs to check if entity is not null.

 + return 0;
  }
  EXPORT_SYMBOL_GPL(v4l2_device_register_subdev);
  
  void v4l2_device_unregister_subdev(struct v4l2_subdev *sd)
  {
 + struct v4l2_device *v4l2_dev;
 +
   /* return if it isn't registered */
   if (sd == NULL || sd-v4l2_dev == NULL)
   return;
  
 - spin_lock(sd-v4l2_dev-lock);
 + v4l2_dev = sd-v4l2_dev;
 +
 + spin_lock(v4l2_dev-lock);
   list_del(sd-list);
 - spin_unlock(sd-v4l2_dev-lock);
 + spin_unlock(v4l2_dev-lock);
   sd-v4l2_dev = NULL;

Re: [RFC/PATCH v4 00/11] Media controller (core and V4L2)

Em 20-08-2010 12:29, Laurent Pinchart escreveu:
 Hi everybody,
 
 Here's the fourth version of the media controller patches. All comments 
 received
 so far have hopefully been incorporated.
 
 Compared to the previous version, the patches have been rebased on top of 
 2.6.35
 and a MEDIA_IOC_DEVICE_INFO ioctl has been added.
 
 I won't submit a rebased version of the V4L2 API additions and OMAP3 ISP 
 patches
 right now. I will first clean up (and document) the V4L2 API additions 
 patches,
 and I will submit them as a proper RFC instead of sample code.

Hi Laurent,

Sorry for a late review on the media controller API. I got flooded by patches 
and
other work since the merge window. Anyway, just finished my review, and sent a
per-patch comment for most patches.

One general comment about it: the userspace API should be documented via 
DocBook, 
to be consistent with V4L2 and DVB API specs.

It should also be clear at the API specs there that not all media drivers will 
implement the media controller API, as its main focus is to allow better control
of SoC devices, where there are needs to control some intrinsic characteristics 
of 
parts of the devices, complementing the V4L2 spec. 

This means that it is needed to add some comments at the kernelspace API doc, 
saying that
the drivers implementing the media controller API are required to work properly 
even 
when userspace is not using the media controller API;

This also means that it is needed to add some comments at the userspace API 
doc, saying
that userspace applications should not assume that media drivers will implement 
the 
media controller API. So, userspace applications implementing the media 
controller 
and V4L2 API's are required to work properly if the device doesn't present a 
media 
controler API interface. It should also say that no driver should just 
implement the
media controller API.

 
 Laurent Pinchart (9):
   media: Media device node support
   media: Media device
   media: Entities, pads and links
   media: Media device information query
   media: Entities, pads and links enumeration
   media: Links setup
   v4l: Add a media_device pointer to the v4l2_device structure
   v4l: Make video_device inherit from media_entity
   v4l: Make v4l2_subdev inherit from media_entity
 
 Sakari Ailus (2):
   media: Entity graph traversal
   media: Reference count and power handling
 
  Documentation/media-framework.txt|  574 
  Documentation/video4linux/v4l2-framework.txt |   72 +++-
  drivers/media/Makefile   |8 +-
  drivers/media/media-device.c |  377 
  drivers/media/media-devnode.c|  310 +
  drivers/media/media-entity.c |  614 
 ++
  drivers/media/video/v4l2-dev.c   |   35 ++-
  drivers/media/video/v4l2-device.c|   45 ++-
  drivers/media/video/v4l2-subdev.c|   27 ++-
  include/linux/media.h|  105 +
  include/media/media-device.h |   90 
  include/media/media-devnode.h|   78 
  include/media/media-entity.h |  112 +
  include/media/v4l2-dev.h |6 +
  include/media/v4l2-device.h  |2 +
  include/media/v4l2-subdev.h  |7 +
  16 files changed, 2440 insertions(+), 22 deletions(-)
  create mode 100644 Documentation/media-framework.txt
  create mode 100644 drivers/media/media-device.c
  create mode 100644 drivers/media/media-devnode.c
  create mode 100644 drivers/media/media-entity.c
  create mode 100644 include/linux/media.h
  create mode 100644 include/media/media-device.h
  create mode 100644 include/media/media-devnode.h
  create mode 100644 include/media/media-entity.h
 

--
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] Illuminators and status LED controls

On Wed, 2010-09-08 at 15:27 -0400, Alex Deucher wrote:
 On Wed, Sep 8, 2010 at 2:58 PM, Peter Korsgaard jac...@sunsite.dk wrote:
  Andy == Andy Walls awa...@md.metrocast.net writes:
 
  Hi,
 
   Andy Incandescent and Halogen lamps that effect an image coming into a
   Andy camera are *not* LEDs that blink or flash automatically based on
   Andy driver or system trigger events.  They are components of a video
   Andy capture system with which a human attempts to adjust the
   Andy appearance of an image of a subject by changing the subject's
   Andy environment.  These illuminators are not some generically
   Andy connected device, but controlled by GPIO's on the camera's bridge
   Andy or sensor chip itself.  Such an illuminator will essentially be
   Andy used only in conjunction with the camera.
 
  Agreed.
 
   Andy Status LEDs integrated into webcam devices that are not generically
   Andy connected devices but controlled with GPIOs on the camera's bridge or
   Andy sensor chip will also essentially be used only in conjunction with 
  the
   Andy camera.
 
  Or for any other usage the user envision - E.G. I could imagine using
  the status led of the webcam in my macbook for hard disk or wifi
  activity. I'm sure other people can come up with more creative use cases
  as well.
 
   Andy Turning these sorts camera specific illuminators and LEDs on an off
   Andy should be as simple to implement for an application developer as it 
  is
   Andy to grasp the concept of turning a light bulb on and off.
 
  The point is that the logic rarely needs to be in the v4l
  applications. The status LEDs should by default go on when the v4l
  device is active and go off again when not like it used to do. A v4l
  application developer would normally not want to worry about such
  things, and only care about the video data.
 
  But if a user wants something special / non-standard, then it's just a
  matter of changing LED trigger in /sys/class/leds/..
 
 I agree with Peter here.  I don't see why a video app would care about
 blinking an LED while capturing.  I suspect most apps won't bother to
 implement it, or it will be a card specific mess (depending on what
 the hw actually provides).  Shouldn't the driver just turn it on or
 blink it when capturing is active or whatever.  Why should apps care?
 Plus, each app may implement some different behavior or some may not
 implement it at all which will further confuse users.
 
 Alex

Hi all,

I just got finished a prototype implementation of using the LED API for
the illuminators on the QX3 microscope, so I could learn about the
interface.  (No devices in any of my systems presented an led interface,
so I had.)  I'm too tired right now to discuss what I've found, but I'll
hopefully respond with my observations around noon EDT tomorrow.

Two patches - my previous one using the V4L2 control API, and this
second one using the LED API - can be found as the last two patches
here:

http://linuxtv.org/hg/~awalls/qx3/

$ diffstat qx3-lamp.diff
 cpia1.c |   73 ++--
 1 file changed, 62 insertions(+), 11 deletions(-)

$ diffstat qx3-ledapi.diff
 cpia1.c |  185 +++-
 1 file changed, 183 insertions(+), 2 deletions(-)

Regards,
Andy

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

Re: [PATCH 1/8] IR: plug races in IR raw thread.

On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
 Unfortunelly (my fault) the kernel thread that now handles IR processing
 has classical races in regard to wakeup and stop.
 This patch hopefully closes them all.
 Tested with module reload running in a loop, while receiver is blasted
 with IR data for 10 minutes.

 Signed-off-by: Maxim Levitsky maximlevit...@gmail.com

Took a while to unwind everything in ir_raw_event_thread() in my head,
but now that I think I have it sorted out, yeah, that looks like the
processing logic all remains the same, with the addition of locking
that should prevent the race (also heavily supported by your testing).

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

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

Re: [PATCH 2/8] IR: make sure we register the input device when it is safe to do so.

On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
 As soon as input device is registered, it might be accessed (and it is)
 This can trigger a hardware interrupt that can access
 not yet initialized ir-raw, (by sending a sample)

 This can be reproduced by holding down a remote button and reloading the 
 module.
 And this always crashes the systems where hardware decides to send an 
 interrupt
 right at the moment it is enabled.

 Signed-off-by: Maxim Levitsky maximlevit...@gmail.com

Finally got my head wrapped around this one too, and I do see the
problem, and this fix looks good to me.

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

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

Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver

On Wed, Sep 8, 2010 at 6:42 PM, Jarod Wilson ja...@redhat.com wrote:
 On Wed, Sep 08, 2010 at 06:54:02PM -0300, Mauro Carvalho Chehab wrote:
 Em 06-09-2010 18:26, Maxim Levitsky escreveu:
  Hi,
 
  Here is full overview of my patches:
 
  Patch #1 fixes races in ir thread.
  It fixes the case when ktherad_stop waits forever for the thread.
  This happens on module unload and therefore it never finishes.
  Sorry for introducing this bug.
 
  Patch #2, fixes a crash on my module load.
  It happens because ir core initializes the input device a bit early,
  therefore it could be accessed while still not set up.
 
  Patch #3 fixes a small typo in lirc code that makes it impossible to use 
  tx duty cycle setting.
 
  Patch #4 fixes a problem seen on my system that results in stuck down 
  forever key.
 
  Patch #5 adds few keys to MCE keymap that were found on laptop of an user 
  I tested this driver with
 
  Patch #6, is a combined update ti my driver. It contains lot of 
  refactoring thanks to docs I have now,
  and lot of fixes, and supports latest version of firmware (and I have 4 
  users asking for that)
  It is quite huge, but it would be a tedios job to break it up. This can't 
  introduce regressions
  because the ene_ir was never released. In addition to that it was tested 
  by me and another two users.
 
  Patch #7 the really only patch that touches drivers I don't have does 
  touch the ir-core.
  It is quite small, and it adds a proper solution to dilema about what to 
  do with huge space between keypresses.
  Now this space is just truncated by the driver with timeout flag.
  The lirc codec then ensures that right sample is send to the lircd.
  Please review and test it.
 
  Patch #8 is very simple. It just builds on top of patch #7 and adds 
  carrier reports to ene driver.

 For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's 
 review also.

 I've finally got them all applied atop current media_tree staging/v2.6.37,
 though none of the streamzap bits in patch 7 are applicable any longer.
 Will try to get through looking and commenting (and testing) of the rest
 of them tonight.

Also had to make a minor addition to the rc5-sz decoder (same change
as in the other decoders). Almost have all the requisite test kernels
for David's, Maxim's and Dmitry's patchsets built and installed, wish
my laptop was faster... Probably would have been faster to use a lab
box and copy data over. Oh well. So functional testing to hopefully
commence tomorrow morning.


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

Re: [PATCH 4/5] rc-core: make struct rc_dev the primary interface for rc drivers

On Tue, Sep 7, 2010 at 5:51 PM, David Härdeman da...@hardeman.nu wrote:
 This patch merges the ir_input_dev and ir_dev_props structs into a single
 struct called rc_dev. The drivers and various functions in rc-core used
 by the drivers are also changed to use rc_dev as the primary interface
 when dealing with rc-core.

 This means that the input_dev is abstracted away from the drivers which
 is necessary if we ever want to support multiple input devs per rc device.

 The new API is similar to what the input subsystem uses, i.e:
 rc_device_alloc()
 rc_device_free()
 rc_device_register()
 rc_device_unregister()

 Signed-off-by: David Härdeman da...@hardeman.nu

I've only looked at the core pieces of the patch and spot-checked the
drivers and decoders I'm most familiar with thus far, but I'm *very*
much in favor of this patch. The parts I've looked at are a very nice
improvement that greatly simplifies the interface, and should
eliminate multiple possible coding failure points and reduce
duplication (a few sections of imon, mceusb and streamzap all looked
pretty damned similar, this patch removes the bulk of that duplication
and abstracts it away). With the caveat that I haven't actually
functionally tested it yet, nor looked at every single bit of it:

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

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

Re: [PATCH 1/5] rc-code: merge and rename ir-core

On Wed, Sep 8, 2010 at 5:42 PM, David Härdeman da...@hardeman.nu wrote:
 On Wed, Sep 08, 2010 at 10:42:10AM -0300, Mauro Carvalho Chehab wrote:
 Em 07-09-2010 18:51, David Härdeman escreveu:
  This patch merges the files which makes up ir-core and renames the
  resulting module to rc-core. IMHO this makes it much easier to hack
  on the core module since all code is in one file.
 
  This also allows some simplification of ir-core-priv.h as fewer internal
  functions need to be exposed.

 I'm not sure about this patch. Big files tend to be harder to maintain,
 as it takes more time to find the right functions inside it. Also, IMO,
 it makes sense to keep the raw-event code on a separate file.

 I don't find big files difficult (note: we're talking about 1300 lines
 here).  Rather the opposite, no hesitation about which files a given
 function originates from and all related code in one nice file. evdev.c
 and input.c are good precedents. But of course, it all boils down to a
 matter of personal taste.

I think I have to finally admit that my personal taste tends toward
one big file in this particular case.

 Anyway, if we apply this patch right now, it will cause merge conflicts with
 the input tree, due to the get/setkeycodebig patches, and with some other
 patches that are pending merge/review. The better is to apply such patch
 just after the release of 2.6.37-rc1, after having all those conflicts
 solved.

 I agree that the big scancode patches from the input tree should go
 first. I keep updating my patchset as the media_tree (staging/v2.6.37
 branch) changes so I have no problem sending an updated patchset at a
 suitable time in the future.

Please feel free to add this to the subsequent refreshes:

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

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

Re: [PATCH 2/5] rc-core: remove remaining users of the ir-functions keyhandlers