Re: [PATCH] Add support for AUX_PLL on cx2583x chips
On Sat, 2010-07-10 at 20:02 +0200, Sven Barth wrote:
This adds support for the AUX_PLL in cx2583x chips which is available in
those although the audio part of the chip is not.
The AUX_PLL is used at least by Terratec in their Grabster AV400 device.
Signed-off-by: Sven Barth pascaldra...@googlemail.com
Acked-By: Mike Isely is...@pobox.com
Reviewed-by: Andy Walls awa...@md.metrocast.net
Acked-by: Andy Walls awa...@md.metrocast.net
From my recollection of our previous emails, this patch looks right and
is the right approach.
Regards,
Andy
diff -aur v4l-src/linux/drivers/media/video/cx25840//cx25840-audio.c
v4l-build/linux/drivers/media/video/cx25840//cx25840-audio.c
--- v4l-src/linux/drivers/media/video/cx25840//cx25840-audio.c
2009-10-18 21:08:26.497700904 +0200
+++ v4l-build/linux/drivers/media/video/cx25840//cx25840-audio.c
2010-07-09 22:35:31.067718241 +0200
@@ -438,41 +438,45 @@
{
struct cx25840_state *state = to_state(i2c_get_clientdata(client));
- /* assert soft reset */
- cx25840_and_or(client, 0x810, ~0x1, 0x01);
-
- /* stop microcontroller */
- cx25840_and_or(client, 0x803, ~0x10, 0);
-
- /* Mute everything to prevent the PFFT! */
- cx25840_write(client, 0x8d3, 0x1f);
-
- if (state-aud_input == CX25840_AUDIO_SERIAL) {
- /* Set Path1 to Serial Audio Input */
- cx25840_write4(client, 0x8d0, 0x01011012);
-
- /* The microcontroller should not be started for the
- * non-tuner inputs: autodetection is specific for
- * TV audio. */
- } else {
- /* Set Path1 to Analog Demod Main Channel */
- cx25840_write4(client, 0x8d0, 0x1f063870);
- }
+if (!is_cx2583x(state)) {
+ /* assert soft reset */
+ cx25840_and_or(client, 0x810, ~0x1, 0x01);
+
+ /* stop microcontroller */
+ cx25840_and_or(client, 0x803, ~0x10, 0);
+
+ /* Mute everything to prevent the PFFT! */
+ cx25840_write(client, 0x8d3, 0x1f);
+
+ if (state-aud_input == CX25840_AUDIO_SERIAL) {
+ /* Set Path1 to Serial Audio Input */
+ cx25840_write4(client, 0x8d0, 0x01011012);
+
+ /* The microcontroller should not be started for the
+ * non-tuner inputs: autodetection is specific for
+ * TV audio. */
+ } else {
+ /* Set Path1 to Analog Demod Main Channel */
+ cx25840_write4(client, 0x8d0, 0x1f063870);
+ }
+}
set_audclk_freq(client, state-audclk_freq);
- if (state-aud_input != CX25840_AUDIO_SERIAL) {
- /* When the microcontroller detects the
- * audio format, it will unmute the lines */
- cx25840_and_or(client, 0x803, ~0x10, 0x10);
- }
-
- /* deassert soft reset */
- cx25840_and_or(client, 0x810, ~0x1, 0x00);
-
- /* Ensure the controller is running when we exit */
- if (is_cx2388x(state) || is_cx231xx(state))
- cx25840_and_or(client, 0x803, ~0x10, 0x10);
+if (!is_cx2583x(state)) {
+ if (state-aud_input != CX25840_AUDIO_SERIAL) {
+ /* When the microcontroller detects the
+ * audio format, it will unmute the lines */
+ cx25840_and_or(client, 0x803, ~0x10, 0x10);
+ }
+
+ /* deassert soft reset */
+ cx25840_and_or(client, 0x810, ~0x1, 0x00);
+
+ /* Ensure the controller is running when we exit */
+ if (is_cx2388x(state) || is_cx231xx(state))
+ cx25840_and_or(client, 0x803, ~0x10, 0x10);
+}
}
static int get_volume(struct i2c_client *client)
diff -aur v4l-src/linux/drivers/media/video/cx25840//cx25840-core.c
v4l-build/linux/drivers/media/video/cx25840//cx25840-core.c
--- v4l-src/linux/drivers/media/video/cx25840//cx25840-core.c 2010-06-26
17:56:26.238525747 +0200
+++ v4l-build/linux/drivers/media/video/cx25840//cx25840-core.c
2010-07-09 23:28:36.784067005 +0200
@@ -691,6 +691,11 @@
}
cx25840_and_or(client, 0x401, ~0x60, 0);
cx25840_and_or(client, 0x401, ~0x60, 0x60);
+
+/* Don't write into audio registers on cx2583x chips */
+if (is_cx2583x(state))
+ return;
+
cx25840_and_or(client, 0x810, ~0x01, 1);
if (state-radio) {
@@ -849,10 +854,8 @@
state-vid_input = vid_input;
state-aud_input = aud_input;
- if (!is_cx2583x(state)) {
- cx25840_audio_set_path(client);
- input_change(client);
- }
+ cx25840_audio_set_path(client);
+ input_change(client);
if (is_cx2388x(state)) {
/* Audio channel 1 src : Parallel 1 */
@@ -1482,8 +1485,6 @@
struct cx25840_state *state =
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Jul 10 19:00:19 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/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
Mantis driver patch: use interrupt for I2C traffic instead of busy registry polling
Hi
Here is a maybe too ugly patch for direct inclusion:
The code should be reworked to be nicer first.
This seems to work though.
What do you think the idea?
Problem:
I figured out that Mantis I2C read and write functions do busy waiting,
by reading via PCI bus a 32 bit word about 350 times in a tight loop.
I suspected that PCI DMA transfer from Mantis card to
CPU memory might get disturbed (FRTG DMA error message by Mantis)
because this heavy polling might cause the RISC processor's
DMA transfer to slow down so much, that there
comes glitches into the DVB stream (some internal FIFO gets full).
So that's why I wrote this patch: by reducing PCI bus contention,
the RISC DMA transfer should be more robust.
The heavy I2C command seems to be that dvb_core checks whether FE_LOCK
still holds.
I think that DVB card's I2C transfers aren't so performance critical,
that the heavy PCI contention by polling is justified. Or is it?
I looked at saa7146_i2c.c from Linux kernel, how to use
wait_event_interruptible_timeout.
Signed-off-by: Marko M Ristola marko.rist...@kolumbus.fi
Regards,
Marko Ristola
diff --git a/drivers/media/dvb/mantis/mantis_cards.c
b/drivers/media/dvb/mantis/mantis_cards.c
index cf4b39f..56c5c30 100644
--- a/drivers/media/dvb/mantis/mantis_cards.c
+++ b/drivers/media/dvb/mantis/mantis_cards.c
@@ -58,7 +58,7 @@ static int devs;
#define DRIVER_NAMEMantis
-static char *label[10] = {
+static char *label[11] = {
DMA,
IRQ-0,
IRQ-1,
@@ -68,6 +68,7 @@ static char *label[10] = {
PPERR,
FTRGT,
RISCI,
+I2CDONE,
RACK
};
@@ -137,8 +138,15 @@ static irqreturn_t mantis_irq_handler(int irq, void
*dev_id)
mantis-finished_block = (stat MANTIS_INT_RISCSTAT) 28;
tasklet_schedule(mantis-tasklet);
}
-if (stat MANTIS_INT_I2CDONE) {
-dprintk(MANTIS_DEBUG, 0, %s, label[9]);
+if (stat (MANTIS_INT_I2CDONE | MANTIS_INT_I2CRACK)) {
+if (stat MANTIS_INT_I2CDONE) {
+dprintk(MANTIS_DEBUG, 0, %s, label[9]);
+mantis-i2c_status |= MANTIS_INT_I2CDONE;
+}
+if (stat MANTIS_INT_I2CRACK) {
+dprintk(MANTIS_DEBUG, 0, %s, label[10]);
+mantis-i2c_status |= MANTIS_INT_I2CRACK;
+}
wake_up(mantis-i2c_wq);
}
mmwrite(stat, MANTIS_INT_STAT);
diff --git a/drivers/media/dvb/mantis/mantis_common.h
b/drivers/media/dvb/mantis/mantis_common.h
index d0b645a..3773ad0 100644
--- a/drivers/media/dvb/mantis/mantis_common.h
+++ b/drivers/media/dvb/mantis/mantis_common.h
@@ -77,7 +77,8 @@
enum mantis_i2c_mode {
MANTIS_PAGE_MODE = 0,
-MANTIS_BYTE_MODE,
+MANTIS_BYTE_MODE = 1,
+MANTIS_IRQ_PAGE_MODE = 2,
};
struct mantis_pci;
@@ -136,6 +137,7 @@ struct mantis_pci {
struct i2c_adapteradapter;
inti2c_rc;
+inti2c_status;
wait_queue_head_ti2c_wq;
struct mutexi2c_lock;
diff --git a/drivers/media/dvb/mantis/mantis_i2c.c
b/drivers/media/dvb/mantis/mantis_i2c.c
index 7870bcf..76de8f8 100644
--- a/drivers/media/dvb/mantis/mantis_i2c.c
+++ b/drivers/media/dvb/mantis/mantis_i2c.c
@@ -38,6 +38,8 @@
static int mantis_i2c_read(struct mantis_pci *mantis, const struct
i2c_msg *msg)
{
u32 rxd, i, stat, trials;
+u32 intstat;
+long timeout;
dprintk(MANTIS_INFO, 0, %s: Address=[0x%02x] R[ ,
__func__, msg-addr);
@@ -51,27 +53,53 @@ static int mantis_i2c_read(struct mantis_pci
*mantis, const struct i2c_msg *msg)
if (i == (msg-len - 1))
rxd = ~MANTIS_I2C_STOP;
-mmwrite(MANTIS_INT_I2CDONE, MANTIS_INT_STAT);
+mantis-i2c_status = 0;
+intstat = MANTIS_INT_I2CDONE | MANTIS_INT_I2CRACK;
+mmwrite(intstat, MANTIS_INT_STAT);
mmwrite(rxd, MANTIS_I2CDATA_CTL);
/* wait for xfer completion */
-for (trials = 0; trials TRIALS; trials++) {
-stat = mmread(MANTIS_INT_STAT);
-if (stat MANTIS_INT_I2CDONE)
-break;
+if (mantis-hwconfig-i2c_mode == MANTIS_IRQ_PAGE_MODE) {
+timeout = HZ / 64;
+timeout = wait_event_interruptible_timeout(mantis-i2c_wq,
mantis-i2c_status MANTIS_INT_I2CDONE, timeout);
+if (timeout == -ERESTARTSYS) {
+dprintk(MANTIS_DEBUG, 1, Mantis I2C read: got
-ERESTARTSYS.\n);
+return -ERESTARTSYS;
+} if (timeout == 0L) {
+dprintk(MANTIS_DEBUG, 1, Mantis I2C read: waiting
I2CDONE failed.\n);
+return -EIO;
+}
+dprintk(MANTIS_TMG, 0, I2CDONE: time remained %ld/%d
jiffies\n, timeout, HZ / 64);
+} else {
+for (trials = 0; trials TRIALS; trials++) {
+stat = mmread(MANTIS_INT_STAT);
+if (stat MANTIS_INT_I2CDONE)
+break;
+}
+dprintk(MANTIS_TMG, 0, I2CDONE: trials=%d\n, trials);
}
-
Re: 2.6.35-rc4 doesn't play well with TerraTec cinergyT2
2010/7/5 Jan Willies j...@willies.info: I'm running 2.6.35-rc4 and get this with a TerraTec cinergyT2: Jul 5 10:03:03 htpc kernel: dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm state. Jul 5 10:03:05 htpc kernel: dvb-usb: bulk message failed: -110 (2/0) Jul 5 10:03:05 htpc kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jul 5 10:03:05 htpc kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jul 5 10:03:05 htpc kernel: DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver) Jul 5 10:03:07 htpc kernel: dvb-usb: bulk message failed: -110 (1/0) Jul 5 10:03:07 htpc kernel: DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver)... Jul 5 10:03:07 htpc kernel: input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:04.1/usb1/1-2/input/input4 Jul 5 10:03:07 htpc kernel: dvb-usb: schedule remote query interval to 50 msecs. Jul 5 10:03:09 htpc kernel: dvb-usb: bulk message failed: -110 (2/0) Jul 5 10:03:09 htpc kernel: dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully initialized and connected. Jul 5 10:03:09 htpc kernel: dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully initialized and connected. Jul 5 10:03:09 htpc kernel: usbcore: registered new interface driver cinergyT2 Jul 5 10:03:11 htpc kernel: dvb-usb: bulk message failed: -110 (1/0) Jul 5 10:03:13 htpc kernel: dvb-usb: bulk message failed: -110 (1/0) Jul 5 10:03:15 htpc kernel: dvb-usb: bulk message failed: -110 (1/0) Jul 5 10:03:17 htpc kernel: dvb-usb: bulk message failed: -110 (1/0) Jul 5 10:03:19 htpc kernel: dvb-usb: bulk message failed: -110 (1/0) Jul 5 10:03:22 htpc kernel: dvb-usb: bulk message failed: -110 (1/0) Jul 5 10:03:22 htpc kernel: usbcore: deregistering interface driver cinergyT2 Jul 5 10:03:22 htpc kernel: dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully deinitialized and disconnected. 2.6.35-rc3 was ok. Is this a known regression or am I doing something wrong? Now I'm getting these messages with my distros kernel too (2.6.33.6-147.fc13.i686), along with a call trace: dvb-usb: recv bulk message failed: -75 dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (9/0) cinergyT2: cinergyt2_fe_set_frontend() Failed! err=-110 dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (2/0) dvb-usb: error while enabling fifo. dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (2/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) dvb-usb: bulk message failed: -110 (1/0) usbcore: deregistering interface driver cinergyT2 dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully deinitialized and disconnected. dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm state. dvb-usb: bulk message failed: -110 (2/0) dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver) dvb-usb: bulk message failed: -110 (1/0) DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver)... input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:06.1/usb2/2-1/input/input4 dvb-usb: schedule remote query interval to 50 msecs. dvb-usb: bulk message failed: -110 (2/0) dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully initialized and
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Sat, Jul 10, 2010 at 5:36 AM, Jean-Francois Moine moin...@free.fr wrote: So, the GPIO register is the second one of the bridge. It is initialized at line 71 of sonixj.c. May you change it from 0x40 to 0x44? (see attached diff) I've compiled the driver with this updated setting and it appears to be the same. The microphone works initially, until video is loaded. $ dmesg | grep gspca [ 22.141766] gspca: main v2.9.0 registered [ 22.163928] gspca-2.9.50: probing 045e:00f7 [ 22.181869] gspca-2.9.50: video0 created [ 22.181872] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 22.181894] gspca-2.9.50: 045e:00f7 bad interface 1 [ 22.181902] gspca-2.9.50: 045e:00f7 bad interface 2 [ 544.774056] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 546.318045] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 Is this change from 0x40 to 0x44 intended to fix the bad interface messages as well as the mic becoming disabled? Also, is a reboot after installing these drivers and changes required? I'm only curious because it takes so much longer to test changes. Thanks. -- Kyle Baker -- To unsubscribe from this list: send the line unsubscribe 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 FOR 2.6.36] uvc: Move constants and structures definitions to linux/usb/video.h
On Sat, Jul 10, 2010 at 08:03:20PM +0200, Laurent Pinchart wrote: The UVC host and gadget drivers both define constants and structures in private header files. Move all those definitions to linux/usb/video.h where they can be shared by the two drivers (and be available for userspace applications). Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro, please take this one, feel free to add: Signed-off-by: Greg Kroah-Hartman gre...@suse.de to it as well. Let me know when it hits your tree, so I know to drop it from mine. thanks, greg k-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: Question about BTTV-video controls whitecrush upper/lower
Andy Walls schrieb: On Tue, 2010-07-06 at 13:27 +0200, Frank Schaefer wrote: Hi, there are two video controls in the Bttv-driver called whitecrush upper and whitecrush lower. But what does whitecrush mean ? Is it the same as white noise ? The german KDE translators are currently trying to translate these strings... White Crush is Conexant's term for adapting to nonstandard or varying Sync to White level voltage differences of the incoming video signal. It's basically an adaptive AGC to prevent blooming of the video signal due to very high Luminance levels. The public BT878A datasheet has terse descriptions of what the registers settings do: they are basically upper and lower thresholds to determine when to adapt the automatic gain control. The public CX25840 datasheet gives a better written description of white crush in section 3.4.9: http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf I'm actually surprised the bttv driver has those presented as user controls at all. Regards, Andy Thank you Andy, that really helps a lot ! Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-ci_init-fix-new
Mauro, please pull fixed tree: http://udev.netup.ru/hg/v4l-dvb-aospan-ci_init-fix-new/ This is very urgent fix. Thanks to Dan Carpentererro...@gmail.com for patch. Thanks ! On 05.06.2010 16:05, Dan Carpenter wrote: videobuf_dvb_register_bus() returns negative error codes on failure. This was introduced in e4425eab6b2: V4L/DVB: cx23885: Check register errors. Signed-off-by: Dan Carpentererro...@gmail.com --- I don't have the hardware to test this, but it looks reversed. diff --git a/drivers/media/video/cx23885/cx23885-dvb.c b/drivers/media/video/cx23885/cx23885-dvb.c index 0a199d7..bf7c328 100644 --- a/drivers/media/video/cx23885/cx23885-dvb.c +++ b/drivers/media/video/cx23885/cx23885-dvb.c @@ -991,7 +991,7 @@ static int dvb_register(struct cx23885_tsport *port) ret = videobuf_dvb_register_bus(port-frontends, THIS_MODULE, port, dev-pci-dev, adapter_nr, 0, cx23885_dvb_fe_ioctl_override); - if (!ret) + if (ret 0) return ret; /* init CI MAC */ -- Abylai Ospanaos...@netup.ru NetUP 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
[Q]: anybody here knows about this DVB-S2 card?
Hi all, I found this link on a forum: http://www.anysee.com/eng/product/anyseeE30PS2Plus.php which, after more information seems to be a stv0903 based card with CI which is tested (from the info given by the forum guy) at 45MS/s for DVB-S2 (the saint-Graal for me to get my HD pay channels here ;-) So my question: does anybody here know about this card and if there is a driver somewhere? TIA, Bye Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DVBWorldDTV DVB-S2 PCIe 2006?
Hi all, just going on my quest for dvb-s2 card supporting 45MS/s rate for DVB-S2 QPSK. Does this card work reliably (CI included)? And if you know of others working reliably (with or without CI) let me know please. TIA Bye Manu -- To unsubscribe from this list: send the line unsubscribe 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] Added Technisat Skystar USB HD CI
Em 06-07-2010 07:23, Renzo Dani escreveu:
From: Renzo Dani aro...@gmail.com
Signed-off-by: Renzo Dani aro...@gmail.com
---
drivers/media/dvb/dvb-usb/az6027.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/az6027.c
b/drivers/media/dvb/dvb-usb/az6027.c
index d7290b2..445851a 100644
--- a/drivers/media/dvb/dvb-usb/az6027.c
+++ b/drivers/media/dvb/dvb-usb/az6027.c
@@ -1103,13 +1103,23 @@ static struct dvb_usb_device_properties
az6027_properties = {
.rc_query = az6027_rc_query,
.i2c_algo = az6027_i2c_algo,
- .num_device_descs = 1,
+ .num_device_descs = 3,
Your patch is not based on the current verson of az6027 driver. It currently
have
5 devices, and it includes 2 Terratec and 2 Technisat USB ID's:
static struct usb_device_id az6027_usb_table[] = {
{ USB_DEVICE(USB_VID_AZUREWAVE, USB_PID_AZUREWAVE_AZ6027) },
{ USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_DVBS2CI_V1) },
{ USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_DVBS2CI_V2) },
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V1) },
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V2) },
{ },
};
The corresponding USB ID's for those devices, according with
drivers/media/dvb/dvb-usb/dvb-usb-ids.h, are:
#define USB_PID_TERRATEC_DVBS2CI_V1 0x10a4
#define USB_PID_TERRATEC_DVBS2CI_V2 0x10ac
#define USB_PID_TECHNISAT_USB2_HDCI_V1 0x0001
#define USB_PID_TECHNISAT_USB2_HDCI_V2 0x0002
.devices = {
{
.name = AZUREWAVE DVB-S/S2 USB2.0 (AZ6027),
.cold_ids = { az6027_usb_table[0], NULL },
.warm_ids = { NULL },
},
+ {
+ .name = Terratec DVB 2 CI,
+ .cold_ids = { az6027_usb_table[1], NULL },
Your patch should be adding a new USB ID entry at az6027_usb_table.
+ .warm_ids = { NULL },
+ },
+ {
+ .name = TechniSat SkyStar USB 2 HD CI (AZ6027),
+ .cold_ids = { az6027_usb_table[2], NULL },
+ .warm_ids = { NULL },
+ },
{ NULL },
}
};
@@ -1118,7 +1128,7 @@ static struct dvb_usb_device_properties
az6027_properties = {
static struct usb_driver az6027_usb_driver = {
.name = dvb_usb_az6027,
.probe = az6027_usb_probe,
- .disconnect = az6027_usb_disconnect,
+ .disconnect = az6027_usb_disconnect,
.id_table = az6027_usb_table,
};
Please check if the existing USB ID's correspond to the devices that you're
adding. If not, please rebase your patch against devel/for_v2.6.36 branch of my
git tree, at http://git.linuxtv.org/v4l-dvb.git.
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: [git:v4l-dvb/other] V4L/DVB: ivtv: use kthread_worker instead of workqueue
On Tue, 2010-07-06 at 03:51 +0200, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/v4l-dvb.git tree: Subject: V4L/DVB: ivtv: use kthread_worker instead of workqueue Author: Tejun Heo t...@kernel.org Date:Mon Jun 28 18:03:50 2010 -0300 Upcoming workqueue updates will no longer guarantee fixed workqueue to worker kthread association, so giving RT priority to the irq worker won't work. Use kthread_worker which guarantees specific kthread association instead. This also makes setting the priority cleaner. Signed-off-by: Tejun Heo t...@kernel.org Reviewed-by: Andy Walls awa...@md.metrocast.net Acked-by: Andy Walls awa...@md.metrocast.net Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Mauro, Please revert this or keep it from going upstream. It relies on at least on other patch by Tejun. If this patch is committed alone to the ivtv driver, it will break compilation of ivtv. I'm OK with Tejun getting this patch committed upstream together with his complete workqueue patchset. Otherwise we''ll have some coordination to go through when the workqueue patches go upstream. That could be hard for everyone, since my response time lately has been rather slow. 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: Status of the patches under review at LMML (60 patches)
On Tue, 2010-07-06 at 10:06 -0300, Mauro Carvalho Chehab wrote: This is the summary of the patches that are currently under review at Linux Media Mailing List linux-media@vger.kernel.org. Each patch is represented by its submission date, the subject (up to 70 chars) and the patchwork link (if submitted via email). P.S.: This email is c/c to the developers where some action is expected. If you were copied, please review the patches, acking/nacking or submitting an update. == Andy Walls awa...@radix.net and Aleksandr Piskunov aleksandr.v.pisku...@gmail.com are discussing around the solution == Oct,11 2009: AVerTV MCE 116 Plus radio http://patchwork.kernel.org/patch/52981 == Waiting for Andy Walls awa...@md.metrocast.net == At the end of the thread both Aleksandr and I concluded that adding 50 ms or more to each frequency change was not a good thing to do. Please mark this patach not to be merged. There is not alternative solution at the moment. Apr,10 2010: cx18: missing audio for analog recordings http://patchwork.kernel.org/patch/91879 The patch at patchwork is obsolete. Please mark it not to be merged. The audio problem still exists and I was working a solution with Mark Lord testing, but I haven't done any work on it for a few months. The current fix, for NTSC with BTSC audio, is at least the first two of the three patches here: http://linuxtv.org/hg/~awalls/cx18-audio2/ Mark reported the 3rd patch broke things. Anyone with access to a bona-fide BTSC stereo broadcast signal (which a STB will not produce) feel free to test. On a general note for all CX2584x and CX23418 audio standard auto-detection problems: without the problem analog signals and detailed specifications on the Merlin audio decoder core, I am not in a good position to fix these audio standard detection problems with these devices. 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: [git:v4l-dvb/other] V4L/DVB: ivtv: use kthread_worker instead of workqueue
On Sat, 2010-07-10 at 09:53 -0300, Mauro Carvalho Chehab wrote: Em 10-07-2010 09:33, Andy Walls escreveu: On Tue, 2010-07-06 at 03:51 +0200, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/v4l-dvb.git tree: Subject: V4L/DVB: ivtv: use kthread_worker instead of workqueue Author: Tejun Heo t...@kernel.org Date:Mon Jun 28 18:03:50 2010 -0300 Upcoming workqueue updates will no longer guarantee fixed workqueue to worker kthread association, so giving RT priority to the irq worker won't work. Use kthread_worker which guarantees specific kthread association instead. This also makes setting the priority cleaner. Signed-off-by: Tejun Heo t...@kernel.org Reviewed-by: Andy Walls awa...@md.metrocast.net Acked-by: Andy Walls awa...@md.metrocast.net Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Mauro, Please revert this or keep it from going upstream. I already did it locally at commit 635c644cdd1557a69e99bda0dcadaf006b66d432. I just forgot to push it to the linuxtv repository ;) I just updated upstream with this patch and another set of commits I did here. :( Hmmm. I should really read my personal email more frequently than every few days. Is there anything you need me to do to help fix this? Provide my SOB on a reversion patch? Submit a reversion patch with an explanation and my SOB? Let me know. I should be available most of today (EDT timezone). 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: [RFC/PATCH v2 6/7] v4l: subdev: Events support
Em 09-07-2010 12:31, Laurent Pinchart escreveu:
From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Provide v4l2_subdevs with v4l2_event support. Subdev drivers only need very
little to support events.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Signed-off-by: David Cohen david.co...@nokia.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/video4linux/v4l2-framework.txt | 18 +++
drivers/media/video/v4l2-subdev.c| 71
+-
include/media/v4l2-subdev.h | 10
3 files changed, 98 insertions(+), 1 deletions(-)
diff --git a/Documentation/video4linux/v4l2-framework.txt
b/Documentation/video4linux/v4l2-framework.txt
index 9c3f33c..89bd881 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -347,6 +347,24 @@ VIDIOC_TRY_EXT_CTRLS
controls can be also be accessed through one (or several) V4L2 device
nodes.
+VIDIOC_DQEVENT
+VIDIOC_SUBSCRIBE_EVENT
+VIDIOC_UNSUBSCRIBE_EVENT
+
+ The events ioctls are identical to the ones defined in V4L2. They
+ behave identically, with the only exception that they deal only with
+ events generated by the sub-device. Depending on the driver, those
+ events can also be reported by one (or several) V4L2 device nodes.
+
+ Sub-device drivers that want to use events need to set the
+ V4L2_SUBDEV_USES_EVENTS v4l2_subdev::flags and initialize
+ v4l2_subdev::nevents to events queue depth before registering the
+ sub-device. After registration events can be queued as usual on the
+ v4l2_subdev::devnode device node.
+
+ To properly support events, the poll() file operation is also
+ implemented.
+
I2C sub-device drivers
--
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index 0ebd760..31bec67 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -18,26 +18,64 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#include linux/types.h
#include linux/ioctl.h
+#include linux/slab.h
+#include linux/types.h
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-fh.h
+#include media/v4l2-event.h
static int subdev_open(struct file *file)
{
struct video_device *vdev = video_devdata(file);
struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
+ struct v4l2_fh *vfh;
+ int ret;
if (!sd-initialized)
return -EAGAIN;
+ vfh = kzalloc(sizeof(*vfh), GFP_KERNEL);
+ if (vfh == NULL)
+ return -ENOMEM;
+
+ ret = v4l2_fh_init(vfh, vdev);
+ if (ret)
+ goto err;
Why to allocate/init the file handler for devices that don't need it?
I would just move the above logic to happen only if V4L2_SUBDEV_FL_HAS_EVENTS.
+
+ if (sd-flags V4L2_SUBDEV_FL_HAS_EVENTS) {
+ ret = v4l2_event_init(vfh);
+ if (ret)
+ goto err;
+
+ ret = v4l2_event_alloc(vfh, sd-nevents);
+ if (ret)
+ goto err;
+ }
+
+ v4l2_fh_add(vfh);
+ file-private_data = vfh;
+
return 0;
+
+err:
+ v4l2_fh_exit(vfh);
+ kfree(vfh);
+
+ return ret;
}
static int subdev_close(struct file *file)
{
+ struct v4l2_fh *vfh = file-private_data;
+
+ v4l2_fh_del(vfh);
+ v4l2_fh_exit(vfh);
+ kfree(vfh);
+
return 0;
}
@@ -45,6 +83,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int
cmd, void *arg)
{
struct video_device *vdev = video_devdata(file);
struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
+ struct v4l2_fh *fh = file-private_data;
switch (cmd) {
case VIDIOC_QUERYCTRL:
@@ -68,6 +107,18 @@ static long subdev_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
case VIDIOC_TRY_EXT_CTRLS:
return v4l2_subdev_call(sd, core, try_ext_ctrls, arg);
+ case VIDIOC_DQEVENT:
+ if (!(sd-flags V4L2_SUBDEV_FL_HAS_EVENTS))
+ return -ENOIOCTLCMD;
+
+ return v4l2_event_dequeue(fh, arg, file-f_flags O_NONBLOCK);
+
+ case VIDIOC_SUBSCRIBE_EVENT:
+ return v4l2_subdev_call(sd, core, subscribe_event, fh, arg);
+
+ case VIDIOC_UNSUBSCRIBE_EVENT:
+ return v4l2_subdev_call(sd, core, unsubscribe_event, fh, arg);
Hmm... shouldn't it test also for V4L2_SUBDEV_FL_HAS_EVENTS?
I would do, instead:
if (fh) {
switch(cmd) {
/* FH events logic */
}
}
+
default:
return -ENOIOCTLCMD;
}
@@ -81,11 +132,29 @@ static long subdev_ioctl(struct file
Re: [RFC/PATCH v2 7/7] v4l: subdev: Generic ioctl support
Em 09-07-2010 12:31, Laurent Pinchart escreveu: Instead of returning an error when receiving an ioctl call with an unsupported command, forward the call to the subdev core::ioctl handler. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/video4linux/v4l2-framework.txt |5 + drivers/media/video/v4l2-subdev.c|2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 89bd881..581e7db 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -365,6 +365,11 @@ VIDIOC_UNSUBSCRIBE_EVENT To properly support events, the poll() file operation is also implemented. +Private ioctls + + All ioctls not in the above list are passed directly to the sub-device + driver through the core::ioctl operation. + I2C sub-device drivers -- diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index 31bec67..ce47772 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -120,7 +120,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) return v4l2_subdev_call(sd, core, unsubscribe_event, fh, arg); default: - return -ENOIOCTLCMD; + return v4l2_subdev_call(sd, core, ioctl, cmd, arg); } return 0; Hmm... private ioctls at subdev... I'm not sure if I like this idea. I prefer to merge this patch only after having a driver actually needing it, after discussing why not using a standard ioctl for that 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: [git:v4l-dvb/other] V4L/DVB: ivtv: use kthread_worker instead of workqueue
Em 10-07-2010 10:07, Andy Walls escreveu: On Sat, 2010-07-10 at 09:53 -0300, Mauro Carvalho Chehab wrote: Em 10-07-2010 09:33, Andy Walls escreveu: On Tue, 2010-07-06 at 03:51 +0200, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/v4l-dvb.git tree: Subject: V4L/DVB: ivtv: use kthread_worker instead of workqueue Author: Tejun Heo t...@kernel.org Date:Mon Jun 28 18:03:50 2010 -0300 Upcoming workqueue updates will no longer guarantee fixed workqueue to worker kthread association, so giving RT priority to the irq worker won't work. Use kthread_worker which guarantees specific kthread association instead. This also makes setting the priority cleaner. Signed-off-by: Tejun Heo t...@kernel.org Reviewed-by: Andy Walls awa...@md.metrocast.net Acked-by: Andy Walls awa...@md.metrocast.net Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Mauro, Please revert this or keep it from going upstream. I already did it locally at commit 635c644cdd1557a69e99bda0dcadaf006b66d432. I just forgot to push it to the linuxtv repository ;) I just updated upstream with this patch and another set of commits I did here. :( Hmmm. I should really read my personal email more frequently than every few days. Is there anything you need me to do to help fix this? Provide my SOB on a reversion patch? Submit a reversion patch with an explanation and my SOB? Let me know. I should be available most of today (EDT timezone). For linux-next, I'll probably just send both patches, since it makes my life easier, but my intention is to just remove the two patches at the next submission window. So, feel free to ping me just after 2.6.35 launch, if you want me to remember about that ;) 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: Status of the patches under review at LMML (60 patches)
Em 09-07-2010 16:39, Sven Barth escreveu:
Hi!
On 08.07.2010 05:31, Mike Isely wrote:
These are cx25840 patches and I'm not the maintainer of that module. I
can't really speak to the correctness of the changes. Best I can do is
to try the patch with a few pvrusb2-driven devices here that use the
cx25840 module. I've done that now (HVR-1950 and PVR-USB2 model 24012)
and everything continues to work fine.
I also retested the patch (with the recent v4l changes) and my device
continues to work as expected (using your current snapshot from July, Mike :)
).
Note, this part of the patch:
int hw_fix = state-pvr150_workaround;
-
-if (std == V4L2_STD_NTSC_M_JP) {
+if (std == V4L2_STD_NTSC_M_JP) {
/* Japan uses EIAJ audio standard */
cx25840_write(client, 0x808, hw_fix ? 0x2f : 0xf7);
} else if (std == V4L2_STD_NTSC_M_KR) {
is a whitespace-only change which introduces a bogus tab and messes up
the indentation of that opening if-statement. It should probably be
removed from the patch.
I wonder how that came in there... my excuses for this (and also the removed
new line some lines below that).
Other than that, you have my ack:
Acked-By: Mike Iselyis...@pobox.com
-Mike
Hmm... I've read a bit in the wiki about submitting patches and read that one
should sign-off his/her patches... as I didn't do that back then (as I
thought that patch would be open for discussion ^^ - note to self: add RFC
next time), should I resend the patch with a comment and the sign-off (and
excluding the indentation mistake) or should I just send a sign-off in
reference to this patch? Or something else?
Just replying with your Signed-off-by is enough, but, as there's that small
fix, the better is if you
could send a new email, adding Mike's ack.
Regards,
Sven
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v4] Multi-plane buffer support for V4L2 API
Hi Pawel,
Looks good, but I have a few small suggestions:
On Friday 09 July 2010 20:59:45 Pawel Osciak wrote:
Hello,
This is the fourth version of the multi-plane API extensions proposal.
I think that we have reached a stage at which it is more or less finalized.
Rationale can be found at the beginning of the original thread:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11212
===
I. Multiplanar API description/negotiation
===
1. Maximum number of planes
--
We've chosen the maximum number of planes to be 8 per buffer:
+#define VIDEO_MAX_PLANES 8
2. Capability checks
--
If a driver supports multiplanar API, it can turn on one (or both) of the
new capability flags:
+/* Is a video capture device that supports multiplanar formats */
+#define V4L2_CAP_VIDEO_CAPTURE_MPLANE 0x1000
+/* Is a video output device that supports multiplanar formats */
+#define V4L2_CAP_VIDEO_OUTPUT_MPLANE 0x2000
- any combination of those flags is valid;
- any combinations with the old, non-multiplanar V4L2_CAP_VIDEO_CAPTURE and
V4L2_CAP_VIDEO_OUTPUT flags are also valid;
- the new flags indicate, that a driver supports the new API, but it does NOT
have to actually use multiplanar formats; it is perfectly possible and valid
to use the new API for 1-plane buffers as well;
using the new API for both 1-planar and n-planar formats makes the
applications simpler, as they do not have to fall back to the old API in the
former case.
3. Describing multiplanar formats
--
To describe multiplanar formats, we have to extend the format struct:
struct v4l2_format {
enum v4l2_buf_type type;
union {
struct v4l2_pix_format pix; /*
V4L2_BUF_TYPE_VIDEO_CAPTURE */
+ struct v4l2_pix_format_mplane mp_pix; /*
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE */
I would probably go with pix_mp to be consistent with the name of the struct.
struct v4l2_window win; /*
V4L2_BUF_TYPE_VIDEO_OVERLAY */
struct v4l2_vbi_format vbi; /*
V4L2_BUF_TYPE_VBI_CAPTURE */
struct v4l2_sliced_vbi_format sliced; /*
V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
__u8raw_data[200]; /* user-defined */
} fmt;
};
We need a new buffer type to recognize when to use mp_pix instead of pix.
Or, actually, two buffer types, for both OUTPUT and CAPTURE:
enum v4l2_buf_type {
/* ... */
+ V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
+ V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 10,
/* ... */
};
For those buffer types, we use struct v4l2_pix_format_mplane:
+/**
+ * struct v4l2_pix_format_mplane - multiplanar format definition
+ * @pix_fmt: definition of an image format for all planes
+ * @plane_fmt: per-plane information
+ */
+struct v4l2_pix_format_mplane {
+ struct v4l2_pix_format pix_fmt;
+ struct v4l2_plane_formatplane_fmt[VIDEO_MAX_PLANES];
+} __attribute__ ((packed));
How do you know how many planes there are? I wonder whether it wouldn't be
smarter
to just copy the relevant fields from struct v4l2_pix_format to struct
v4l2_pix_format_mplane
instead of embedded that struct. That way you can 1) add a 'planes' field and
2) get rid
of the no longer needed bytesperline and sizeimage fields. And I think the priv
field
should also go, just have a reserved[2] instead.
The pix_fmt member is to be used in the same way as in the old API. Its
fields:
- width, height, field, colorspace, priv retain their old meaning;
- pixelformat is still fourcc, but new fourcc values have to be introduced
for multiplanar formats;
- bytesperline, sizeimage lose their meanings and are replaced by their
counterparts in the new, per-plane format struct.
The plane format struct is as follows:
+/**
+ * struct v4l2_plane_format - additional, per-plane format definition
+ * @sizeimage: maximum size in bytes required for data, for which
+ * this plane will be used
+ * @bytesperline: distance in bytes between the leftmost pixels in two
+ * adjacent lines
+ */
+struct v4l2_plane_format {
+ __u32 sizeimage;
+ __u16 bytesperline;
+ __u16 reserved[7];
+} __attribute__ ((packed));
Note that bytesperline is u16 now, but that shouldn't hurt.
Fitting everything into v4l2_format's union (which is 200 bytes long):
v4l2_pix_format shouldn't be larger than 40 bytes.
8 * struct v4l2_plane_format + struct v4l2_pix_format = 8 * 20 + 40 = 200
4. Format enumeration
--
struct v4l2_fmtdesc,
Re: [RFC/PATCH v2 7/7] v4l: subdev: Generic ioctl support
On Saturday 10 July 2010 16:08:46 Mauro Carvalho Chehab wrote: Em 09-07-2010 12:31, Laurent Pinchart escreveu: Instead of returning an error when receiving an ioctl call with an unsupported command, forward the call to the subdev core::ioctl handler. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/video4linux/v4l2-framework.txt |5 + drivers/media/video/v4l2-subdev.c|2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 89bd881..581e7db 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -365,6 +365,11 @@ VIDIOC_UNSUBSCRIBE_EVENT To properly support events, the poll() file operation is also implemented. +Private ioctls + + All ioctls not in the above list are passed directly to the sub-device + driver through the core::ioctl operation. + I2C sub-device drivers -- diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index 31bec67..ce47772 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -120,7 +120,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) return v4l2_subdev_call(sd, core, unsubscribe_event, fh, arg); default: - return -ENOIOCTLCMD; + return v4l2_subdev_call(sd, core, ioctl, cmd, arg); } return 0; Hmm... private ioctls at subdev... I'm not sure if I like this idea. I prefer to merge this patch only after having a driver actually needing it, after discussing why not using a standard ioctl for that driver. Part of the reason for making these subdev device nodes is to actually allow private ioctls (after properly discussing it and with documentation). SoCs tend to have a lot of very hardware specific features that do not translate to generic ioctls. Until now these are either ignored or handled through custom drivers, but but it is much better to handle them in a 'controlled' fashion. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe 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 v2 0/7] V4L2 subdev userspace API
Looks good, I have no comments for this patch series. Regards, Hans On Friday 09 July 2010 17:31:45 Laurent Pinchart wrote: Hi everybody, Here's the second version of the V4L2 subdev userspace API patches. Comments received on the first version have been incorporated, with the exception of the video_usercopy usage as this is still under discussion. A problem with module reference counting has also been solved by setting the owner of the subdev device node to the subdev driver, not videodev.ko. This required a change to the v4l2_i2c_new_subdev_board function prototype, and thus a modification to the radio-si4713 driver. Due to the fast review (thanks everybody) I haven't had time to finish the media controller core patches, but they will arrive soon. Laurent Pinchart (6): v4l: subdev: Don't require core operations v4l: Merge v4l2_i2c_new_subdev_cfg and v4l2_i2c_new_subdev v4l: subdev: Add device node support v4l: subdev: Uninline the v4l2_subdev_init function v4l: subdev: Control ioctls support v4l: subdev: Generic ioctl support Sakari Ailus (1): v4l: subdev: Events support Documentation/video4linux/v4l2-framework.txt | 57 + drivers/media/radio/radio-si4713.c |2 +- drivers/media/video/Makefile |2 +- drivers/media/video/soc_camera.c |2 +- drivers/media/video/v4l2-common.c| 22 ++-- drivers/media/video/v4l2-dev.c | 27 ++--- drivers/media/video/v4l2-device.c| 25 - drivers/media/video/v4l2-subdev.c| 172 ++ include/media/v4l2-common.h | 21 +--- include/media/v4l2-dev.h | 18 +++- include/media/v4l2-subdev.h | 40 --- 11 files changed, 326 insertions(+), 62 deletions(-) create mode 100644 drivers/media/video/v4l2-subdev.c -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe 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 v2 7/7] v4l: subdev: Generic ioctl support
Em 10-07-2010 13:31, Hans Verkuil escreveu: On Saturday 10 July 2010 16:08:46 Mauro Carvalho Chehab wrote: Em 09-07-2010 12:31, Laurent Pinchart escreveu: Hmm... private ioctls at subdev... I'm not sure if I like this idea. I prefer to merge this patch only after having a driver actually needing it, after discussing why not using a standard ioctl for that driver. Part of the reason for making these subdev device nodes is to actually allow private ioctls (after properly discussing it and with documentation). SoCs tend to have a lot of very hardware specific features that do not translate to generic ioctls. Until now these are either ignored or handled through custom drivers, but but it is much better to handle them in a 'controlled' fashion. I understand that SoC's may have lots of features that are currently not being exposed, but if they'll be either be shown as CTRL or as new ioctls need further discussions. That's why I prefer to receive this patch in a patch series where such needed is required. 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
[PATCH] Add support for AUX_PLL on cx2583x chips
This adds support for the AUX_PLL in cx2583x chips which is available in
those although the audio part of the chip is not.
The AUX_PLL is used at least by Terratec in their Grabster AV400 device.
Signed-off-by: Sven Barth pascaldra...@googlemail.com
Acked-By: Mike Isely is...@pobox.com
diff -aur v4l-src/linux/drivers/media/video/cx25840//cx25840-audio.c
v4l-build/linux/drivers/media/video/cx25840//cx25840-audio.c
--- v4l-src/linux/drivers/media/video/cx25840//cx25840-audio.c
2009-10-18 21:08:26.497700904 +0200
+++ v4l-build/linux/drivers/media/video/cx25840//cx25840-audio.c
2010-07-09 22:35:31.067718241 +0200
@@ -438,41 +438,45 @@
{
struct cx25840_state *state = to_state(i2c_get_clientdata(client));
- /* assert soft reset */
- cx25840_and_or(client, 0x810, ~0x1, 0x01);
-
- /* stop microcontroller */
- cx25840_and_or(client, 0x803, ~0x10, 0);
-
- /* Mute everything to prevent the PFFT! */
- cx25840_write(client, 0x8d3, 0x1f);
-
- if (state-aud_input == CX25840_AUDIO_SERIAL) {
- /* Set Path1 to Serial Audio Input */
- cx25840_write4(client, 0x8d0, 0x01011012);
-
- /* The microcontroller should not be started for the
-* non-tuner inputs: autodetection is specific for
-* TV audio. */
- } else {
- /* Set Path1 to Analog Demod Main Channel */
- cx25840_write4(client, 0x8d0, 0x1f063870);
- }
+if (!is_cx2583x(state)) {
+ /* assert soft reset */
+ cx25840_and_or(client, 0x810, ~0x1, 0x01);
+
+ /* stop microcontroller */
+ cx25840_and_or(client, 0x803, ~0x10, 0);
+
+ /* Mute everything to prevent the PFFT! */
+ cx25840_write(client, 0x8d3, 0x1f);
+
+ if (state-aud_input == CX25840_AUDIO_SERIAL) {
+ /* Set Path1 to Serial Audio Input */
+ cx25840_write4(client, 0x8d0, 0x01011012);
+
+ /* The microcontroller should not be started for the
+* non-tuner inputs: autodetection is specific for
+* TV audio. */
+ } else {
+ /* Set Path1 to Analog Demod Main Channel */
+ cx25840_write4(client, 0x8d0, 0x1f063870);
+ }
+}
set_audclk_freq(client, state-audclk_freq);
- if (state-aud_input != CX25840_AUDIO_SERIAL) {
- /* When the microcontroller detects the
-* audio format, it will unmute the lines */
- cx25840_and_or(client, 0x803, ~0x10, 0x10);
- }
-
- /* deassert soft reset */
- cx25840_and_or(client, 0x810, ~0x1, 0x00);
-
- /* Ensure the controller is running when we exit */
- if (is_cx2388x(state) || is_cx231xx(state))
- cx25840_and_or(client, 0x803, ~0x10, 0x10);
+if (!is_cx2583x(state)) {
+ if (state-aud_input != CX25840_AUDIO_SERIAL) {
+ /* When the microcontroller detects the
+* audio format, it will unmute the lines */
+ cx25840_and_or(client, 0x803, ~0x10, 0x10);
+ }
+
+ /* deassert soft reset */
+ cx25840_and_or(client, 0x810, ~0x1, 0x00);
+
+ /* Ensure the controller is running when we exit */
+ if (is_cx2388x(state) || is_cx231xx(state))
+ cx25840_and_or(client, 0x803, ~0x10, 0x10);
+}
}
static int get_volume(struct i2c_client *client)
diff -aur v4l-src/linux/drivers/media/video/cx25840//cx25840-core.c
v4l-build/linux/drivers/media/video/cx25840//cx25840-core.c
--- v4l-src/linux/drivers/media/video/cx25840//cx25840-core.c 2010-06-26
17:56:26.238525747 +0200
+++ v4l-build/linux/drivers/media/video/cx25840//cx25840-core.c
2010-07-09 23:28:36.784067005 +0200
@@ -691,6 +691,11 @@
}
cx25840_and_or(client, 0x401, ~0x60, 0);
cx25840_and_or(client, 0x401, ~0x60, 0x60);
+
+/* Don't write into audio registers on cx2583x chips */
+if (is_cx2583x(state))
+ return;
+
cx25840_and_or(client, 0x810, ~0x01, 1);
if (state-radio) {
@@ -849,10 +854,8 @@
state-vid_input = vid_input;
state-aud_input = aud_input;
- if (!is_cx2583x(state)) {
- cx25840_audio_set_path(client);
- input_change(client);
- }
+ cx25840_audio_set_path(client);
+ input_change(client);
if (is_cx2388x(state)) {
/* Audio channel 1 src : Parallel 1 */
@@ -1482,8 +1485,6 @@
struct cx25840_state *state = to_state(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (is_cx2583x(state))
- return -EINVAL;
return set_input(client, state-vid_input, input);
}
@@ -1492,8 +1493,7 @@
struct
[PATCH FOR 2.6.36] uvc: Move constants and structures definitions to linux/usb/video.h
The UVC host and gadget drivers both define constants and structures in
private header files. Move all those definitions to linux/usb/video.h
where they can be shared by the two drivers (and be available for
userspace applications).
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvcvideo.h | 19 --
drivers/usb/gadget/f_uvc.c | 16 +-
drivers/usb/gadget/f_uvc.h | 352 +---
drivers/usb/gadget/uvc.h | 36
drivers/usb/gadget/webcam.c| 24 +-
include/linux/usb/video.h | 397
6 files changed, 418 insertions(+), 426 deletions(-)
This patch replaces
usb-uvc-move-constants-and-structures-definitions-to-linux-usb-video.h.patch
from Greg Kroah-Hartman's patches.git tree. It fixes the conflicts between the
original patch and commits c3810b43416155d040a200e7a7301f379c8ae8a0 and
da1df555fcbb98a9d2054304ea54545d9ff523cf in the v4l-dvb.git tree.
Regards,
Laurent Pinchart
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index 47b20e7..ac27245 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -196,25 +196,6 @@ struct uvc_device;
/* TODO: Put the most frequently accessed fields at the beginning of
* structures to maximize cache efficiency.
*/
-struct uvc_streaming_control {
- __u16 bmHint;
- __u8 bFormatIndex;
- __u8 bFrameIndex;
- __u32 dwFrameInterval;
- __u16 wKeyFrameRate;
- __u16 wPFrameRate;
- __u16 wCompQuality;
- __u16 wCompWindowSize;
- __u16 wDelay;
- __u32 dwMaxVideoFrameSize;
- __u32 dwMaxPayloadTransferSize;
- __u32 dwClockFrequency;
- __u8 bmFramingInfo;
- __u8 bPreferedVersion;
- __u8 bMinVersion;
- __u8 bMaxVersion;
-};
-
struct uvc_control_info {
struct list_head list;
struct list_head mappings;
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index fc2611f..b6aed97 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -61,12 +61,12 @@ static struct usb_gadget_strings *uvc_function_strings[] = {
#define UVC_INTF_VIDEO_STREAMING 1
static struct usb_interface_assoc_descriptor uvc_iad __initdata = {
- .bLength= USB_DT_INTERFACE_ASSOCIATION_SIZE,
+ .bLength= sizeof(uvc_iad),
.bDescriptorType= USB_DT_INTERFACE_ASSOCIATION,
.bFirstInterface= 0,
.bInterfaceCount= 2,
.bFunctionClass = USB_CLASS_VIDEO,
- .bFunctionSubClass = 0x03,
+ .bFunctionSubClass = UVC_SC_VIDEO_INTERFACE_COLLECTION,
.bFunctionProtocol = 0x00,
.iFunction = 0,
};
@@ -78,7 +78,7 @@ static struct usb_interface_descriptor uvc_control_intf
__initdata = {
.bAlternateSetting = 0,
.bNumEndpoints = 1,
.bInterfaceClass= USB_CLASS_VIDEO,
- .bInterfaceSubClass = 0x01,
+ .bInterfaceSubClass = UVC_SC_VIDEOCONTROL,
.bInterfaceProtocol = 0x00,
.iInterface = 0,
};
@@ -106,7 +106,7 @@ static struct usb_interface_descriptor
uvc_streaming_intf_alt0 __initdata = {
.bAlternateSetting = 0,
.bNumEndpoints = 0,
.bInterfaceClass= USB_CLASS_VIDEO,
- .bInterfaceSubClass = 0x02,
+ .bInterfaceSubClass = UVC_SC_VIDEOSTREAMING,
.bInterfaceProtocol = 0x00,
.iInterface = 0,
};
@@ -118,7 +118,7 @@ static struct usb_interface_descriptor
uvc_streaming_intf_alt1 __initdata = {
.bAlternateSetting = 1,
.bNumEndpoints = 1,
.bInterfaceClass= USB_CLASS_VIDEO,
- .bInterfaceSubClass = 0x02,
+ .bInterfaceSubClass = UVC_SC_VIDEOSTREAMING,
.bInterfaceProtocol = 0x00,
.iInterface = 0,
};
@@ -603,15 +603,15 @@ uvc_bind_config(struct usb_configuration *c,
/* Validate the descriptors. */
if (control == NULL || control[0] == NULL ||
- control[0]-bDescriptorSubType != UVC_DT_HEADER)
+ control[0]-bDescriptorSubType != UVC_VC_HEADER)
goto error;
if (fs_streaming == NULL || fs_streaming[0] == NULL ||
- fs_streaming[0]-bDescriptorSubType != UVC_DT_INPUT_HEADER)
+ fs_streaming[0]-bDescriptorSubType != UVC_VS_INPUT_HEADER)
goto error;
if (hs_streaming == NULL || hs_streaming[0] == NULL ||
- hs_streaming[0]-bDescriptorSubType != UVC_DT_INPUT_HEADER)
+ hs_streaming[0]-bDescriptorSubType != UVC_VS_INPUT_HEADER)
goto error;
uvc-desc.control = control;
diff --git a/drivers/usb/gadget/f_uvc.h b/drivers/usb/gadget/f_uvc.h
index 8a5db7c..e18a663 100644
---
