[PATCH 8/8] rc-core: initialize rc-core earlier if built-in
rc-core is a subsystem so it should be registered earlier if built into the kernel. Signed-off-by: David Härdeman --- drivers/media/rc/rc-main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index ec7311f..8134bd8 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -1327,7 +1327,7 @@ static void __exit rc_core_exit(void) rc_map_unregister(&empty_map); } -module_init(rc_core_init); +subsys_initcall(rc_core_init); module_exit(rc_core_exit); int rc_core_debug;/* ir_debug level (0,1,2) */ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] rc-core: rename ir_input_class to rc_class
The name is already misleading and will be more so in the future as the
connection to the input subsystem is obscured away further.
Signed-off-by: David Härdeman
---
drivers/media/rc/rc-main.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index d29818c..ec7311f 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -849,14 +849,14 @@ static void ir_close(struct input_dev *idev)
}
/* class for /sys/class/rc */
-static char *ir_devnode(struct device *dev, umode_t *mode)
+static char *rc_devnode(struct device *dev, umode_t *mode)
{
return kasprintf(GFP_KERNEL, "rc/%s", dev_name(dev));
}
-static struct class ir_input_class = {
+static struct class rc_class = {
.name = "rc",
- .devnode= ir_devnode,
+ .devnode= rc_devnode,
};
/*
@@ -1137,7 +1137,7 @@ struct rc_dev *rc_allocate_device(void)
setup_timer(&dev->timer_keyup, ir_timer_keyup, (unsigned long)dev);
dev->dev.type = &rc_dev_type;
- dev->dev.class = &ir_input_class;
+ dev->dev.class = &rc_class;
device_initialize(&dev->dev);
__module_get(THIS_MODULE);
@@ -1310,7 +1310,7 @@ EXPORT_SYMBOL_GPL(rc_unregister_device);
static int __init rc_core_init(void)
{
- int rc = class_register(&ir_input_class);
+ int rc = class_register(&rc_class);
if (rc) {
printk(KERN_ERR "rc_core: unable to register rc class\n");
return rc;
@@ -1323,7 +1323,7 @@ static int __init rc_core_init(void)
static void __exit rc_core_exit(void)
{
- class_unregister(&ir_input_class);
+ class_unregister(&rc_class);
rc_map_unregister(&empty_map);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] rc-core: merge rc5 and streamzap decoders
Now that the protocol is part of the scancode, it is pretty easy to merge
the rc5 and streamzap decoders. An additional advantage is that the decoder
is now stricter as it waits for the trailing silence before determining that
a command is a valid rc5/streamzap command (which avoids collisions that I've
seen with e.g. Sony protocols).
Signed-off-by: David Härdeman
---
drivers/media/rc/Kconfig| 12 --
drivers/media/rc/Makefile |1
drivers/media/rc/ir-rc5-decoder.c | 51 ++
drivers/media/rc/ir-rc5-sz-decoder.c| 154 ---
drivers/media/rc/keymaps/rc-streamzap.c |4 -
drivers/media/rc/rc-core-priv.h |8 --
drivers/media/rc/streamzap.c| 10 --
7 files changed, 31 insertions(+), 209 deletions(-)
delete mode 100644 drivers/media/rc/ir-rc5-sz-decoder.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 4682a5a..d700b1d 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -84,18 +84,6 @@ config IR_SONY_DECODER
Enable this option if you have an infrared remote control which
uses the Sony protocol, and you need software decoding support.
-config IR_RC5_SZ_DECODER
- tristate "Enable IR raw decoder for the RC-5 (streamzap) protocol"
- depends on RC_CORE
- select BITREVERSE
- default y
-
- ---help---
- Enable this option if you have IR with RC-5 (streamzap) protocol,
- and if the IR is decoded in software. (The Streamzap PC Remote
- uses an IR protocol that is almost standard RC-5, but not quite,
- as it uses an additional bit).
-
config IR_SANYO_DECODER
tristate "Enable IR raw decoder for the Sanyo protocol"
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 56bacf0..9f56774 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
obj-$(CONFIG_IR_JVC_DECODER) += ir-jvc-decoder.o
obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o
-obj-$(CONFIG_IR_RC5_SZ_DECODER) += ir-rc5-sz-decoder.o
obj-$(CONFIG_IR_SANYO_DECODER) += ir-sanyo-decoder.o
obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
diff --git a/drivers/media/rc/ir-rc5-decoder.c
b/drivers/media/rc/ir-rc5-decoder.c
index ddbf9bf..9594b8f 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -1,6 +1,7 @@
-/* ir-rc5-decoder.c - handle RC5(x) IR Pulse/Space protocol
+/* ir-rc5-decoder.c - decoder for RC5(x) and StreamZap protocols
*
* Copyright (C) 2010 by Mauro Carvalho Chehab
+ * Copyright (C) 2010 by Jarod Wilson
*
* 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
@@ -13,23 +14,22 @@
*/
/*
- * This code handles 14 bits RC5 protocols and 20 bits RC5x protocols.
- * There are other variants that use a different number of bits.
- * This is currently unsupported.
- * It considers a carrier of 36 kHz, with a total of 14/20 bits, where
- * the first two bits are start bits, and a third one is a filing bit
+ * This decoder handles the 14 bit RC5 protocol, 15 bit "StreamZap" protocol
+ * and 20 bit RC5x protocol.
*/
#include "rc-core-priv.h"
#include
#define RC5_NBITS 14
+#define RC5_SZ_NBITS 15
#define RC5X_NBITS 20
#define CHECK_RC5X_NBITS 8
#define RC5_UNIT 88 /* ns */
#define RC5_BIT_START (1 * RC5_UNIT)
#define RC5_BIT_END(1 * RC5_UNIT)
#define RC5X_SPACE (4 * RC5_UNIT)
+#define RC5_TRAILER(10 * RC5_UNIT) /* In reality, approx 100 */
enum rc5_state {
STATE_INACTIVE,
@@ -80,12 +80,15 @@ again:
data->state = STATE_BIT_START;
data->count = 1;
- /* We just need enough bits to get to STATE_CHECK_RC5X */
- data->wanted_bits = RC5X_NBITS;
decrease_duration(&ev, RC5_BIT_START);
goto again;
case STATE_BIT_START:
+ if (!ev.pulse && geq_margin(ev.duration, RC5_TRAILER, RC5_UNIT
/ 2)) {
+ data->state = STATE_FINISHED;
+ goto again;
+ }
+
if (!eq_margin(ev.duration, RC5_BIT_START, RC5_UNIT / 2))
break;
@@ -100,9 +103,7 @@ again:
if (!is_transition(&ev, &dev->raw->prev_ev))
break;
- if (data->count == data->wanted_bits)
- data->state = STATE_FINISHED;
- else if (data->count == CHECK_RC5X_NBITS)
+ if (data->count == CHECK_RC5X_NBITS)
data->state = STATE_CHECK_RC5X;
else
[PATCH 5/8] rc-core: use the full 32 bits for NEC scancodes
Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
and the nec decoder without any loss of functionality.
In order to maintain backwards compatibility, some heuristics are added
in rc-main.c to convert scancodes to NEC32 as necessary. No conversion
is made for the newer "rc_keymap_entry" based ioctls.
Signed-off-by: David Härdeman
---
drivers/media/rc/ir-nec-decoder.c | 28 +++-
drivers/media/rc/rc-main.c | 36 ++-
drivers/media/usb/dvb-usb-v2/af9015.c | 22 +--
drivers/media/usb/dvb-usb-v2/az6007.c | 16 +++---
drivers/media/usb/dvb-usb-v2/it913x.c | 15 +
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 21 +++---
include/media/rc-map.h | 11 -
7 files changed, 68 insertions(+), 81 deletions(-)
diff --git a/drivers/media/rc/ir-nec-decoder.c
b/drivers/media/rc/ir-nec-decoder.c
index 61fa889..0b98f8f 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -50,7 +50,6 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
struct nec_dec *data = &dev->raw->nec;
u32 scancode;
u8 address, not_address, command, not_command;
- bool send_32bits = false;
if (!(dev->enabled_protocols & RC_BIT_NEC))
return 0;
@@ -163,33 +162,14 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
command = bitrev8((data->bits >> 8) & 0xff);
not_command = bitrev8((data->bits >> 0) & 0xff);
- if ((command ^ not_command) != 0xff) {
- IR_dprintk(1, "NEC checksum error: received 0x%08x\n",
- data->bits);
- send_32bits = true;
- }
-
- if (send_32bits) {
- /* NEC transport, but modified protocol, used by at
-* least Apple and TiVo remotes */
- scancode = data->bits;
- IR_dprintk(1, "NEC (modified) scancode 0x%08x\n",
scancode);
- } else if ((address ^ not_address) != 0xff) {
- /* Extended NEC */
- scancode = address << 16 |
- not_address << 8 |
- command;
- IR_dprintk(1, "NEC (Ext) scancode 0x%06x\n", scancode);
- } else {
- /* Normal NEC */
- scancode = address << 8 | command;
- IR_dprintk(1, "NEC scancode 0x%04x\n", scancode);
- }
+ scancode = address << 24 | not_address << 16 |
+ command << 8 | not_command;
+ IR_dprintk(1, "NEC scancode 0x%08x\n", scancode);
if (data->is_nec_x)
data->necx_repeat = true;
- rc_keydown(dev, RC_TYPE_NEC, scancode, 0);
+ rc_keydown(dev, RC_TYPE_NEC, RC_SCANCODE_NEC32(scancode), 0);
data->state = STATE_INACTIVE;
return 0;
}
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index b111500..d29818c 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -324,6 +324,30 @@ static unsigned int ir_establish_scancode(struct rc_dev
*dev,
}
/**
+ * to_nec32() - helper function to try to convert misc NEC scancodes to NEC32
+ * @orig: original scancode
+ * @return:NEC32 scancode
+ *
+ * This helper routine is used to provide backwards compatibility.
+ */
+static u64 to_nec32(u64 orig)
+{
+ u8 b3 = (u8)(orig >> 16);
+ u8 b2 = (u8)(orig >> 8);
+ u8 b1 = (u8)(orig >> 0);
+
+ if (orig <= 0x)
+ /* Plain old NEC */
+ return b2 << 24 | ((u8)~b2) << 16 | b1 << 8 | ((u8)~b1);
+ else if (orig <= 0xff)
+ /* NEC extended */
+ return b3 << 24 | b2 << 16 | b1 << 8 | ((u8)~b1);
+ else
+ /* NEC32 */
+ return orig;
+}
+
+/**
* ir_setkeycode() - set a keycode in the scancode->keycode table
* @idev: the struct input_dev device descriptor
* @scancode: the desired scancode
@@ -371,6 +395,9 @@ static int ir_setkeycode(struct input_dev *idev,
else
entry.protocol = RC_TYPE_OTHER;
+ if (entry.protocol == RC_TYPE_NEC)
+ entry.scancode = to_nec32(entry.scancode);
+
index = ir_establish_scancode(rdev, rc_map, &entry, true);
if (index >= rc_map->len) {
retval = -ENOMEM;
@@ -430,8 +457,12 @@ static int ir_setkeytable(struct rc_dev *dev,
rc_map->size, rc_map->alloc);
for (i = 0; i < from->size; i++) {
+ if (from->rc_type == RC_TYPE_N
[PATCH 2/8] winbond-cir: asynchronous tx
Change winbond-cir's tx support to be asynchronous and not to mess with
the TX buffer. Essentially the winbond-cir counterpart to the patch
Sean Young sent for iguanair.
Signed-off-by: David Härdeman
---
drivers/media/rc/winbond-cir.c | 47 +++-
1 file changed, 18 insertions(+), 29 deletions(-)
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 29e6769..30ae1f2 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -180,7 +180,6 @@ enum wbcir_rxstate {
enum wbcir_txstate {
WBCIR_TXSTATE_INACTIVE = 0,
WBCIR_TXSTATE_ACTIVE,
- WBCIR_TXSTATE_DONE,
WBCIR_TXSTATE_ERROR
};
@@ -216,7 +215,6 @@ struct wbcir_data {
u32 txlen;
u32 txoff;
u32 *txbuf;
- wait_queue_head_t txwaitq;
u8 txmask;
u32 txcarrier;
};
@@ -424,11 +422,11 @@ wbcir_irq_tx(struct wbcir_data *data)
if (data->txstate == WBCIR_TXSTATE_ERROR)
/* Clear TX underrun bit */
outb(WBCIR_TX_UNDERRUN, data->sbase +
WBCIR_REG_SP3_ASCR);
- else
- data->txstate = WBCIR_TXSTATE_DONE;
wbcir_set_irqmask(data, WBCIR_IRQ_RX | WBCIR_IRQ_ERR);
led_trigger_event(data->txtrigger, LED_OFF);
- wake_up(&data->txwaitq);
+ kfree(data->txbuf);
+ data->txbuf = NULL;
+ data->txstate = WBCIR_TXSTATE_INACTIVE;
} else if (data->txoff == data->txlen) {
/* At the end of transmission, tell the hw before last byte */
outsb(data->sbase + WBCIR_REG_SP3_TXDATA, bytes, used - 1);
@@ -579,43 +577,37 @@ wbcir_txmask(struct rc_dev *dev, u32 mask)
}
static int
-wbcir_tx(struct rc_dev *dev, unsigned *buf, unsigned count)
+wbcir_tx(struct rc_dev *dev, unsigned *b, unsigned count)
{
struct wbcir_data *data = dev->priv;
+ unsigned *buf;
unsigned i;
unsigned long flags;
+ buf = kmalloc(count * sizeof(*b), GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ /* Convert values to multiples of 10us */
+ for (i = 0; i < count; i++)
+ buf[i] = DIV_ROUND_CLOSEST(b[i], 10);
+
/* Not sure if this is possible, but better safe than sorry */
spin_lock_irqsave(&data->spinlock, flags);
if (data->txstate != WBCIR_TXSTATE_INACTIVE) {
spin_unlock_irqrestore(&data->spinlock, flags);
+ kfree(buf);
return -EBUSY;
}
- /* Convert values to multiples of 10us */
- for (i = 0; i < count; i++)
- buf[i] = DIV_ROUND_CLOSEST(buf[i], 10);
-
/* Fill the TX fifo once, the irq handler will do the rest */
data->txbuf = buf;
data->txlen = count;
data->txoff = 0;
wbcir_irq_tx(data);
- /* Wait for the TX to complete */
- while (data->txstate == WBCIR_TXSTATE_ACTIVE) {
- spin_unlock_irqrestore(&data->spinlock, flags);
- wait_event(data->txwaitq, data->txstate !=
WBCIR_TXSTATE_ACTIVE);
- spin_lock_irqsave(&data->spinlock, flags);
- }
-
/* We're done */
- if (data->txstate == WBCIR_TXSTATE_ERROR)
- count = -EAGAIN;
- data->txstate = WBCIR_TXSTATE_INACTIVE;
- data->txbuf = NULL;
spin_unlock_irqrestore(&data->spinlock, flags);
-
return count;
}
@@ -927,13 +919,11 @@ wbcir_init_hw(struct wbcir_data *data)
ir_raw_event_reset(data->dev);
ir_raw_event_handle(data->dev);
- /*
-* Check TX state, if we did a suspend/resume cycle while TX was
-* active, we will have a process waiting in txwaitq.
-*/
+ /* Clear TX state */
if (data->txstate == WBCIR_TXSTATE_ACTIVE) {
- data->txstate = WBCIR_TXSTATE_ERROR;
- wake_up(&data->txwaitq);
+ kfree(data->txbuf);
+ data->txbuf = NULL;
+ data->txstate = WBCIR_TXSTATE_INACTIVE;
}
/* Enable interrupts */
@@ -974,7 +964,6 @@ wbcir_probe(struct pnp_dev *device, const struct
pnp_device_id *dev_id)
pnp_set_drvdata(device, data);
spin_lock_init(&data->spinlock);
- init_waitqueue_head(&data->txwaitq);
data->ebase = pnp_port_start(device, 0);
data->wbase = pnp_port_start(device, 1);
data->sbase = pnp_port_start(device, 2);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] winbond-cir: correctness fix
This is a minor correctness fix for the duration calculation in winbond-cir (the read value should be incremented by one). Signed-off-by: David Härdeman --- drivers/media/rc/winbond-cir.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c index 54ee348..29e6769 100644 --- a/drivers/media/rc/winbond-cir.c +++ b/drivers/media/rc/winbond-cir.c @@ -358,7 +358,7 @@ wbcir_irq_rx(struct wbcir_data *data, struct pnp_dev *device) if (data->rxstate == WBCIR_RXSTATE_ERROR) continue; rawir.pulse = irdata & 0x80 ? false : true; - rawir.duration = US_TO_NS((irdata & 0x7F) * 10); + rawir.duration = US_TO_NS(((irdata & 0x7F) + 1) * 10); ir_raw_event_store_with_filter(data->dev, &rawir); } -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] rc-core: patches for 3.7
This is two minor winbond-cir fixes as well as the first six patches from my previous patchbomb. The latter have been modified so that backwards compatibility is retained as much as possible (the format of the sysfs files do not change for example). --- David Härdeman (8): winbond-cir: correctness fix winbond-cir: asynchronous tx rc-core: add separate defines for protocol bitmaps and numbers rc-core: don't throw away protocol information rc-core: use the full 32 bits for NEC scancodes rc-core: merge rc5 and streamzap decoders rc-core: rename ir_input_class to rc_class rc-core: initialize rc-core earlier if built-in drivers/media/common/siano/smsir.c |2 drivers/media/i2c/ir-kbd-i2c.c | 26 +- drivers/media/pci/bt8xx/bttv-input.c | 15 + drivers/media/pci/cx18/cx18-i2c.c|2 drivers/media/pci/cx23885/cx23885-input.c|6 drivers/media/pci/cx88/cx88-input.c | 18 + drivers/media/pci/dm1105/dm1105.c|3 drivers/media/pci/ivtv/ivtv-i2c.c|8 - drivers/media/pci/saa7134/saa7134-input.c|8 - drivers/media/pci/ttpci/budget-ci.c |7 - drivers/media/rc/Kconfig | 12 - drivers/media/rc/Makefile|1 drivers/media/rc/ati_remote.c| 15 + drivers/media/rc/ene_ir.c|2 drivers/media/rc/fintek-cir.c|2 drivers/media/rc/gpio-ir-recv.c |2 drivers/media/rc/iguanair.c |2 drivers/media/rc/imon.c | 50 ++-- drivers/media/rc/ir-jvc-decoder.c|6 drivers/media/rc/ir-lirc-codec.c |4 drivers/media/rc/ir-mce_kbd-decoder.c|4 drivers/media/rc/ir-nec-decoder.c| 32 -- drivers/media/rc/ir-raw.c|2 drivers/media/rc/ir-rc5-decoder.c| 64 +++-- drivers/media/rc/ir-rc5-sz-decoder.c | 154 --- drivers/media/rc/ir-rc6-decoder.c| 54 ++-- drivers/media/rc/ir-sanyo-decoder.c |6 drivers/media/rc/ir-sony-decoder.c | 17 + drivers/media/rc/ite-cir.c |2 drivers/media/rc/keymaps/rc-imon-mce.c |2 drivers/media/rc/keymaps/rc-rc6-mce.c|2 drivers/media/rc/keymaps/rc-streamzap.c |4 drivers/media/rc/mceusb.c|2 drivers/media/rc/nuvoton-cir.c |2 drivers/media/rc/rc-core-priv.h |9 - drivers/media/rc/rc-loopback.c |2 drivers/media/rc/rc-main.c | 354 ++ drivers/media/rc/redrat3.c |2 drivers/media/rc/streamzap.c | 12 - drivers/media/rc/ttusbir.c |2 drivers/media/rc/winbond-cir.c | 51 +--- drivers/media/usb/cx231xx/cx231xx-input.c|2 drivers/media/usb/dvb-usb-v2/af9015.c| 24 +- drivers/media/usb/dvb-usb-v2/af9035.c|4 drivers/media/usb/dvb-usb-v2/anysee.c|5 drivers/media/usb/dvb-usb-v2/az6007.c| 19 + drivers/media/usb/dvb-usb-v2/dvb_usb.h |2 drivers/media/usb/dvb-usb-v2/it913x.c| 22 +- drivers/media/usb/dvb-usb-v2/lmedm04.c |4 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 26 +- drivers/media/usb/dvb-usb/dib0700.h |2 drivers/media/usb/dvb-usb/dib0700_core.c | 18 + drivers/media/usb/dvb-usb/dib0700_devices.c | 156 ++- drivers/media/usb/dvb-usb/dvb-usb.h |4 drivers/media/usb/dvb-usb/pctv452e.c | 15 + drivers/media/usb/dvb-usb/technisat-usb2.c |2 drivers/media/usb/dvb-usb/ttusb2.c |4 drivers/media/usb/em28xx/em28xx-cards.c | 15 + drivers/media/usb/em28xx/em28xx-input.c | 44 ++- drivers/media/usb/em28xx/em28xx.h|1 drivers/media/usb/hdpvr/hdpvr-i2c.c |2 drivers/media/usb/pvrusb2/pvrusb2-i2c-core.c |4 drivers/media/usb/tm6000/tm6000-cards.c |2 drivers/media/usb/tm6000/tm6000-input.c | 80 -- include/media/ir-kbd-i2c.h |2 include/media/rc-core.h | 32 ++ include/media/rc-map.h | 86 +- 67 files changed, 797 insertions(+), 750 deletions(-) delete mode 100644 drivers/media/rc/ir-rc5-sz-decoder.c -- 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
[PATCH 2/6] drivers/media/platform/mx2_emmaprp.c: adjust inconsistent IS_ERR and PTR_ERR
From: Julia Lawall
Change the call to IS_ERR to test the value that was just initialized and
is returned using PTR_ERR.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression e,e1;
@@
(
if (IS_ERR(e)) { ... PTR_ERR(e) ... }
|
if (IS_ERR(e=e1)) { ... PTR_ERR(e) ... }
|
*if (IS_ERR(e))
{ ...
* PTR_ERR(e1)
... }
)
//
Signed-off-by: Julia Lawall
---
drivers/media/platform/mx2_emmaprp.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/platform/mx2_emmaprp.c
b/drivers/media/platform/mx2_emmaprp.c
index dab380a..2be1bb1 100644
--- a/drivers/media/platform/mx2_emmaprp.c
+++ b/drivers/media/platform/mx2_emmaprp.c
@@ -908,9 +908,8 @@ static int emmaprp_probe(struct platform_device *pdev)
}
pcdev->clk_emma_ahb = devm_clk_get(&pdev->dev, "ahb");
- if (IS_ERR(pcdev->clk_emma_ipg)) {
+ if (IS_ERR(pcdev->clk_emma_ahb))
return PTR_ERR(pcdev->clk_emma_ahb);
- }
irq_emma = platform_get_irq(pdev, 0);
res_emma = platform_get_resource(pdev, IORESOURCE_MEM, 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Aug 25 19:00:20 CEST 2012 git hash:79e8c7bebb467bbc3f2514d75bba669a3f354324 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-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-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: 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-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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
Compiling v4l-dvb.git-modules for stock kernel without media_build
Hi list, Not so long ago I used a special version of v4l-dvb.git (v3,2 + a patch) on my system together with a debian stock kernel. It worked. Now I update my system and thus the kernel and what I did last time doesn't seem to work any longer: 1) checkout v3.2 of v4l-dvb.git and apply my path 2) get .config, .kernelvariables and Module.symvers from linux- headers-3.2.0-3-amd64 (which corresponds to my running kernel) 3) make oldconfig modules_prepare in v4l-dvb.git 4) make M=drivers/media 5) install all the .ko into /lib/modules 6) depmod -a 7) reboot Now I have the following symptoms: a) for the 3 PCI-cards I have the b2c2-flexcop-pci charged automatically but it fails to initialize the devices and bails out with -22 b) the USB-device is not triggering the loading of its driver and upon a modprobe it doesn't get claimed. Something is wrong, but I don't know what. Could it be the symbol versions? Thanks for any hints. -- Patrick. -- To unsubscribe from this list: send the line "unsubscribe 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 9/9] videobuf2-core: Change vb2_queue_init return type to void
On Sat, 25 Aug 2012 13:12:01 -0300
Ezequiel Garcia wrote:
> The mentioned BUG_ON() are these:
>
> void vb2_queue_init(struct vb2_queue *q)
> {
> BUG_ON(!q);
> BUG_ON(!q->ops);
> BUG_ON(!q->mem_ops);
> BUG_ON(!q->type);
> BUG_ON(!q->io_modes);
> [...]
>
> Unless I'm overlooking something they look fine to me,
> since vb2_queue should always be prepared by the driver.
http://permalink.gmane.org/gmane.linux.kernel/1347333 is, I believe, the
definitive word on this kind of use of BUG_ON()...
jon
--
To unsubscribe from this list: send the line "unsubscribe 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 9/9] videobuf2-core: Change vb2_queue_init return type to void
(Ccing videobuf2 authors)
On Sat, Aug 25, 2012 at 12:28 PM, Jonathan Corbet wrote:
> On Sat, 25 Aug 2012 00:09:06 -0300
> Ezequiel Garcia wrote:
>
>> -int vb2_queue_init(struct vb2_queue *q)
>> +void vb2_queue_init(struct vb2_queue *q)
>> {
>> BUG_ON(!q);
>> BUG_ON(!q->ops);
>
> If this change goes through in this form, you can add my ack for the
> Marvell piece. But I have to wonder...might it not be better to retain
> the return value and use it to return -EINVAL instead of the seven BUG_ON()
> calls found in that function? It shouldn't be necessary to bring things
> down in this situation, and, who knows, one of those might just be turned
> into a DOS vector with some driver someday.
>
The mentioned BUG_ON() are these:
void vb2_queue_init(struct vb2_queue *q)
{
BUG_ON(!q);
BUG_ON(!q->ops);
BUG_ON(!q->mem_ops);
BUG_ON(!q->type);
BUG_ON(!q->io_modes);
[...]
Unless I'm overlooking something they look fine to me,
since vb2_queue should always be prepared by the driver.
On the other hand, it seems these BUG_ON are inherited from videobuf1
(see videobuf_queue_core_init).
Marek, Pawel: What do you think?
Thanks,
Ezequiel.
--
To unsubscribe from this list: send the line "unsubscribe 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 9/9] videobuf2-core: Change vb2_queue_init return type to void
On Sat, 25 Aug 2012 00:09:06 -0300
Ezequiel Garcia wrote:
> -int vb2_queue_init(struct vb2_queue *q)
> +void vb2_queue_init(struct vb2_queue *q)
> {
> BUG_ON(!q);
> BUG_ON(!q->ops);
If this change goes through in this form, you can add my ack for the
Marvell piece. But I have to wonder...might it not be better to retain
the return value and use it to return -EINVAL instead of the seven BUG_ON()
calls found in that function? It shouldn't be necessary to bring things
down in this situation, and, who knows, one of those might just be turned
into a DOS vector with some driver someday.
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
unsubscribe -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] iguanair: do not modify transmit buffer
Since commit "[media] rc-core: move timeout and checks to lirc", the
incoming buffer is used after the driver transmits.
Signed-off-by: Sean Young
---
drivers/media/rc/iguanair.c | 51 +++--
1 file changed, 21 insertions(+), 30 deletions(-)
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index 66ba237..1e4c68a 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -334,21 +334,34 @@ static int iguanair_set_tx_mask(struct rc_dev *dev,
uint32_t mask)
static int iguanair_tx(struct rc_dev *dev, unsigned *txbuf, unsigned count)
{
struct iguanair *ir = dev->priv;
- uint8_t space, *payload;
- unsigned i, size, rc, bytes;
+ uint8_t space;
+ unsigned i, size, periods, bytes;
+ int rc;
struct send_packet *packet;
mutex_lock(&ir->lock);
+ packet = kmalloc(sizeof(*packet) + ir->bufsize, GFP_KERNEL);
+ if (!packet) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
/* convert from us to carrier periods */
- for (i = size = 0; i < count; i++) {
- txbuf[i] = DIV_ROUND_CLOSEST(txbuf[i] * ir->carrier, 100);
- bytes = (txbuf[i] + 126) / 127;
+ for (i = space = size = 0; i < count; i++) {
+ periods = DIV_ROUND_CLOSEST(txbuf[i] * ir->carrier, 100);
+ bytes = DIV_ROUND_UP(periods, 127);
if (size + bytes > ir->bufsize) {
count = i;
break;
}
- size += bytes;
+ while (periods > 127) {
+ packet->payload[size++] = 127 | space;
+ periods -= 127;
+ }
+
+ packet->payload[size++] = periods | space;
+ space ^= 0x80;
}
if (count == 0) {
@@ -356,12 +369,6 @@ static int iguanair_tx(struct rc_dev *dev, unsigned
*txbuf, unsigned count)
goto out;
}
- packet = kmalloc(sizeof(*packet) + size, GFP_KERNEL);
- if (!packet) {
- rc = -ENOMEM;
- goto out;
- }
-
packet->header.start = 0;
packet->header.direction = DIR_OUT;
packet->header.cmd = CMD_SEND;
@@ -370,26 +377,11 @@ static int iguanair_tx(struct rc_dev *dev, unsigned
*txbuf, unsigned count)
packet->busy7 = ir->busy7;
packet->busy4 = ir->busy4;
- space = 0;
- payload = packet->payload;
-
- for (i = 0; i < count; i++) {
- unsigned periods = txbuf[i];
-
- while (periods > 127) {
- *payload++ = 127 | space;
- periods -= 127;
- }
-
- *payload++ = periods | space;
- space ^= 0x80;
- }
-
if (ir->receiver_on) {
rc = iguanair_receiver(ir, false);
if (rc) {
dev_warn(ir->dev, "disable receiver before transmit
failed\n");
- goto out_kfree;
+ goto out;
}
}
@@ -405,9 +397,8 @@ static int iguanair_tx(struct rc_dev *dev, unsigned *txbuf,
unsigned count)
dev_warn(ir->dev, "re-enable receiver after transmit
failed\n");
}
-out_kfree:
- kfree(packet);
out:
+ kfree(packet);
mutex_unlock(&ir->lock);
return rc ? rc : count;
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] rc: do not sleep when the driver blocks on IR completion
On Sat, Aug 25, 2012 at 11:25:26AM +0200, David Härdeman wrote: > On Sat, Aug 25, 2012 at 12:26:25AM +0100, Sean Young wrote: > >On Sat, Aug 25, 2012 at 12:05:18AM +0200, David Härdeman wrote: > >> On Thu, Aug 23, 2012 at 10:18:35PM +0100, Sean Young wrote: > >> >Some drivers wait for the IR device to complete sending before > >> >returning, so sleeping should not be done. > >> > >> I'm not quite sure what the purpose is. Even if a driver waits for TX to > >> finish, the lirc imposed sleep isn't harmful in any way. > > > >Due to rounding errors, clock skew and different start times, the sleep > >might be waiting for a different amount of time than the hardware took > >to send it. The sleep is a bit of a kludge, let alone if the driver > >can wait for the hardware to tell you when it's done. > > I don't see the sleep as much of a problem right now. Whether the > hardware says its done or if we simulate the same thing in the lirc > layer, the entire concept is a bit of a kludge :) It's not making it any better. > >Also, your change calculates the amount of us to sleep after transmission, > >so if the transmission buffer was modified by the driver, the calculated > >sleep might not make sense. Both winbond-cir and iguanair do this. > > Oh, right, I'd overlooked this. I have written patches for winbond-cir > (which makes it asynchronous and leaves the txbuffer alone) and iguanair > (to leave the txbuffer alone). I'll post them sometime today when I've > done some more tests. If this is the solution we're going for, then I've got a patch for iguanair which leaves the txbuffer alone and is ready and tested. I'll send it out in the next half hour. Sean -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] rc: do not sleep when the driver blocks on IR completion
On Sat, Aug 25, 2012 at 12:26:25AM +0100, Sean Young wrote: >On Sat, Aug 25, 2012 at 12:05:18AM +0200, David Härdeman wrote: >> On Thu, Aug 23, 2012 at 10:18:35PM +0100, Sean Young wrote: >> >Some drivers wait for the IR device to complete sending before >> >returning, so sleeping should not be done. >> >> I'm not quite sure what the purpose is. Even if a driver waits for TX to >> finish, the lirc imposed sleep isn't harmful in any way. > >Due to rounding errors, clock skew and different start times, the sleep >might be waiting for a different amount of time than the hardware took >to send it. The sleep is a bit of a kludge, let alone if the driver >can wait for the hardware to tell you when it's done. I don't see the sleep as much of a problem right now. Whether the hardware says its done or if we simulate the same thing in the lirc layer, the entire concept is a bit of a kludge :) >Also, your change calculates the amount of us to sleep after transmission, >so if the transmission buffer was modified by the driver, the calculated >sleep might not make sense. Both winbond-cir and iguanair do this. Oh, right, I'd overlooked this. I have written patches for winbond-cir (which makes it asynchronous and leaves the txbuffer alone) and iguanair (to leave the txbuffer alone). I'll post them sometime today when I've done some more tests. >> As far as I can tell, the iguanair driver waits for the usb packet to be >> submitted, not for IR TX to finish. > >The iguanair driver waits for the ack from the device (which is an urb >you receive from the device), which is sent once the IR has been >transmitted. The firmware source code is available. Ah, I see. -- 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: [RFC API] Renumber subdev ioctls
Hi Hans, On Wed, Aug 22, 2012 at 10:52:02AM +0200, Hans Verkuil wrote: > On Tue August 21 2012 12:44:15 Sakari Ailus wrote: > > Hi Hans, > > > > On Tue, Aug 21, 2012 at 08:39:53AM +0200, Hans Verkuil wrote: ... > > > Currently I've chosen ioctl numbers that are not used by V4L2 (there are a > > > number of 'holes' in the ioctl list). > > > > > > If people think it is not worth the effort, then so be it. But if we do > > > want > > > to do this, then we can't wait any longer. > > > > One option would be to start using a new type for the new IOCTLs but leave > > the existing ones as they are. The end result would be less elegant since > > the subdev IOCTLs would use two different types but OTOH the V4L2 IOCTLs are > > being used on subdevs as-is, too. This would at least prevent future clashes > > in IOCTL codes between V4L2 and subdev interfaces. > > I don't really like that idea. > > I thought that Laurent's proposal of creating SUBDEV aliases of reused V4L2 > ioctls had merit. That way v4l2-subdev.h would give a nice overview of > which V4L2 ioctls are supported by the subdev API. Currently no such overview > exists to my knowledge. We do --- it's the big switch in v4lw-ioctl.c. If that is to be improved that should be done IMO to the official Linux media infrastructure API spec. > With regards to adding pad fields to the existing control structs: that won't > work with queryctrl: the reserved fields are output fields only, there is no > requirement that apps have to zero them, so you can't use them to enumerate > controls for a particular pad. > > A new queryctrl ioctl would have to be created for that. So if we need this > functionality, then I believe it is better to combine that with a new > queryctrl ioctl. Ack. Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe 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: Core + Radio profile
On Sat August 25 2012 02:37:15 Andy Walls wrote: > On Wed, 2012-08-22 at 11:40 +0200, Hans Verkuil wrote: > > Hi all! > > > > The v4l2-compliance utility checks whether device drivers follows the V4L2 > > specification. What is missing are 'profiles' detailing what device drivers > > should and shouldn't implement for particular device classes. > > > >This has been discussed several times, but until now no attempt was made to > > actually write this down. > > Hi Hans, > > Excellent! > > Profiles of what to implement from a large, complex, option-filled > standard are a great way to increase interoperability. In our case the > "standard" is the V4L2 specification. The interoperability we need to > increase is between user-space applications (MythTV, tvtime, VLC, > mplayer, gstreamer, cheese, Ekiga, ZoneMinder, Kaffeine, ) and the > kernel device drivers. > > I know of two viewpoints from which profiles are documented: > > 1. how an as-built system complies with and implement options from a > stanadrd, and > > 2. how future systems and systems in development should implement a > standard and its options > > For linux-media purposes, profiling from viewpoint #1 is a bit of a > waste: the v4l2-compliance tool essentially auto generates the profiles > plus at least some of the existing user applications are already aware > of driver quirks. > > I think documenting the profiles from the 2nd viewpoint is what we want. > (Which is what you are proposing.) > > Such profiles should state unequviocally: > > 1. the optional features from the standard/spec that are required to be > implemented > > 2. any optional features from the standard/spec that are required *not* > to be implemented > > 3. the mandatory features from the standard/spec that are expected to be > implemented > > 4. any mandatory portions of the specification that are specifically not > to be used (Probably only needed for profiles trying to ensure the > broadest interoperability). > > Hopefully, specifying the above in profiles removes all the guess-work > about what is to be implemented, so that application <-> kernel driver > combinations will be broadly interoperable. > > > > > This RFC is my attempt to start this process by describing three profiles: > > the core profile that all drivers must adhere to, a profile for a radio > > receiver and a profile for a radio transmitter. > > I was thinking that profiles based on applications types might be more > useful, but then I saw that applications were basically already handling > different device types differently. So prfoiles for hardware device > types seems the reasonable choice. > > MythTV seems to care about 4 classes of device > http://www.mythtv.org/wiki/Video_capture_card > > Analog Framebuffer > Analog Hardware Encoder > Digital Capture > Digital Tuner > > VLC seems to be similar to MythTV in terms of classes: > http://www.videolan.org/doc/streaming-howto/en/images/global-diagram.jpg > > I suppose there would also be profiles to support device classes for: > > webcams > webcams that provide video in a container format (AVI, MJPEG, whatever) > integrated cameras (I'm thinking smart-phones, but I'm out of my depth > here) Looking at the current set of V4L drivers I come up with the following profiles: - Core Profile (mandatory for all) - Radio Receiver Profile (with optional RDS support (sub-profile?)) - Radio Transmitter Profile (with optional RDS support) - Webcam Profile - Video Capture Profile (with optional tuner/overlay/vbi support) - Video Output Profile (with optional vbi support) - Memory-to-Memory Profile (for hardware codecs) - Complex Profile (for SoCs with complex video hardware requiring the use of the Media Controller API and a supporting library) I wonder if e.g. optional tuner support and similar optional features should be defined as full profiles or as sub-profiles. In theory it is possible to have, say, a device that just captures VBI and no video. So there is something to be said for making it a full profile and allow drivers to support multiple profiles (although not all combinations are allowed). > > > I assume you are designing the Core profile to be a minimum subset > profile upon which all other profiles build. Yes. > > > > Missing in this RFC is a description of how tuner ownership is handled if a > > tuner is shared between a radio and video driver. This will be discussed > > during the workshop next week. > > IMO, that is a specification issue, and not an issue to be solved in a > profile. I have a narrow view the profiles are intended to fix > interoperability problems, and they are not to levy new, unprecedented > requirements on behaviour. > > > > I am not certain where these profile descriptions should go. Should we add > > this to DocBook, or describe it in Documentation/video4linux? Or perhaps > > somehow add it to v4l2-compliance, since that tool effectively verifies >
Re: [v3 1/1] driver-core: Shut up dev_dbg_reatelimited() without DEBUG
--- On Fri, 24/8/12, Hiroshi Doyu wrote:
> From: Hiroshi Doyu
> Subject: [v3 1/1] driver-core: Shut up dev_dbg_reatelimited() without DEBUG
> To: "gre...@linuxfoundation.org"
> Cc: "linux-ker...@vger.kernel.org" ,
> "ht...@users.sourceforge.net" ,
> "linux-media@vger.kernel.org" ,
> "j...@perches.com" , "linux-te...@vger.kernel.org"
> , "cr...@iki.fi"
> Date: Friday, 24 August, 2012, 5:35
> dev_dbg_reatelimited() without DEBUG
> printed "217078 callbacks
> suppressed". This shouldn't print anything without DEBUG.
>
> With CONFIG_DYNAMIC_DEBUG, the print should be configured as
> expected.
>
> Signed-off-by: Hiroshi Doyu
> Reported-by: Hin-Tak Leung
> Tested-by: Antti Palosaari
> Acked-by: Hin-Tak Leung
Tested-by: Hin-Tak Leung
Went ahead and patched my 2.5.x distro kernel-devel package header, and it
works as expected. Apologies about the red-herring with media_build (for those
who are not familar with it, = "back-port" wrapper package for building new DVB
modules against older kernels).
The distro kernel-devel headers is per installed distro kernel so will be
replaced in a week or two... no permanent demage done :-).
> ---
> include/linux/device.h | 62
> +--
> 1 files changed, 38 insertions(+), 24 deletions(-)
>
> diff --git a/include/linux/device.h
> b/include/linux/device.h
> index 9648331..bb6ffcb 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -932,6 +932,32 @@ int _dev_info(const struct device *dev,
> const char *fmt, ...)
>
> #endif
>
> +/*
> + * Stupid hackaround for existing uses of non-printk uses
> dev_info
> + *
> + * Note that the definition of dev_info below is actually
> _dev_info
> + * and a macro is used to avoid redefining dev_info
> + */
> +
> +#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt,
> ##arg)
> +
> +#if defined(CONFIG_DYNAMIC_DEBUG)
> +#define dev_dbg(dev, format, ...)
> \
> +do {
>
> \
> + dynamic_dev_dbg(dev, format,
> ##__VA_ARGS__); \
> +} while (0)
> +#elif defined(DEBUG)
> +#define dev_dbg(dev, format, arg...)
> \
> + dev_printk(KERN_DEBUG, dev, format,
> ##arg)
> +#else
> +#define dev_dbg(dev, format, arg...)
> \
> +({
>
> \
> + if (0)
>
> \
> +
> dev_printk(KERN_DEBUG, dev, format,
> ##arg); \
> + 0;
>
> \
> +})
> +#endif
> +
> #define dev_level_ratelimited(dev_level, dev, fmt,
> ...)
> \
> do {
>
>
> \
> static
> DEFINE_RATELIMIT_STATE(_rs,
> \
> @@ -955,33 +981,21 @@ do {
>
>
> \
> dev_level_ratelimited(dev_notice, dev,
> fmt, ##__VA_ARGS__)
> #define dev_info_ratelimited(dev, fmt,
> ...)
> \
> dev_level_ratelimited(dev_info, dev,
> fmt, ##__VA_ARGS__)
> +#if defined(CONFIG_DYNAMIC_DEBUG) || defined(DEBUG)
> #define dev_dbg_ratelimited(dev, fmt,
> ...)
> \
> - dev_level_ratelimited(dev_dbg, dev, fmt,
> ##__VA_ARGS__)
> -
> -/*
> - * Stupid hackaround for existing uses of non-printk uses
> dev_info
> - *
> - * Note that the definition of dev_info below is actually
> _dev_info
> - * and a macro is used to avoid redefining dev_info
> - */
> -
> -#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt,
> ##arg)
> -
> -#if defined(CONFIG_DYNAMIC_DEBUG)
> -#define dev_dbg(dev, format, ...)
> \
> -do {
>
> \
> - dynamic_dev_dbg(dev, format,
> ##__VA_ARGS__); \
> +do {
>
>
> \
> + static
> DEFINE_RATELIMIT_STATE(_rs,
> \
> +
>
> DEFAULT_RATELIMIT_INTERVAL, \
> +
>
> DEFAULT_RATELIMIT_BURST);
> \
> +
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,
> fmt);
> \
> + if (unlikely(descriptor.flags &
> _DPRINTK_FLAGS_PRINT) && \
> +
> __ratelimit(&_rs))
>
> \
> +
> __dynamic_pr_debug(&descriptor,
> pr_fmt(fmt), \
> +
>
> ##__VA_ARGS__);
> \
> } while (0)
> -#elif defined(DEBUG)
> -#define dev_dbg(dev, format, arg...)
> \
> - dev_printk(KERN_DEBUG, dev, format,
> ##arg)
> #else
> -#define dev_dbg(dev, format, arg...)
> \
> -({
>
> \
> - if (0)
>
> \
> -
> dev_printk(KERN_DEBUG, dev, format,
> ##arg); \
> - 0;
>
> \
> -})
> +#define dev_dbg_ratelimited(dev, fmt,
> ...)
> \
> + no_printk(KERN_DEBUG pr_fmt(fmt),
> ##__VA_ARGS__)
> #endif
>
> #ifdef VERBOSE_DEBUG
> --
> 1.7.5.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
