RE: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
Hi,
> -Original Message-
> From: Jonghun Han [mailto:jonghun@samsung.com]
>
> Hi,
>
> Kamil Debski wrote:
>
>
>
> > +/* Reqeust buffers */
> > +static int vidioc_reqbufs(struct file *file, void *priv,
> > + struct v4l2_requestbuffers
> *reqbufs)
> > +{
> > + struct s5p_mfc_dev *dev = video_drvdata(file);
> > + struct s5p_mfc_ctx *ctx = priv;
> > + int ret = 0;
> > + unsigned long flags;
> > +
> > + mfc_debug_enter();
> > + mfc_debug("Memory type: %d\n", reqbufs->memory);
> > + if (reqbufs->memory != V4L2_MEMORY_MMAP) {
> > + mfc_err("Only V4L2_MEMORY_MAP is supported.\n");
> > + return -EINVAL;
> > + }
> > + if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > + /* Can only request buffers after an instance has been
> opened.*/
> > + if (ctx->state == MFCINST_DEC_GOT_INST) {
> > + /* Decoding */
> > + if (ctx->output_state != QUEUE_FREE) {
> > + mfc_err("Bufs have already been
> requested.\n");
> > + return -EINVAL;
> > + }
> > + ret = vb2_reqbufs(&ctx->vq_src, reqbufs);
> > + if (ret) {
> > + mfc_err("vb2_reqbufs on output failed.\n");
> > + return ret;
> > + }
> > + mfc_debug("vb2_reqbufs: %d\n", ret);
> > + ctx->output_state = QUEUE_BUFS_REQUESTED;
> > + }
> > + } else if (reqbufs->type ==
> > V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> > + if (ctx->capture_state != QUEUE_FREE) {
> > + mfc_err("Bufs have already been requested.\n");
> > + return -EINVAL;
> > + }
> > + ctx->capture_state = QUEUE_BUFS_REQUESTED;
> > + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> > + if (ret) {
> > + mfc_err("vb2_reqbufs on capture failed.\n");
> > + return ret;
> > + }
> > + if (reqbufs->count < ctx->dpb_count) {
> > + mfc_err("Not enough buffers allocated.\n");
> > + reqbufs->count = 0;
> > + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> > + return -ENOMEM;
> > + }
> > + ctx->total_dpb_count = reqbufs->count;
> > + ret = s5p_mfc_alloc_dec_buffers(ctx);
> > + if (ret) {
> > + mfc_err("Failed to allocate decoding buffers.\n");
> > + reqbufs->count = 0;
> > + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> > + return -ENOMEM;
> > + }
> > + if (ctx->dst_bufs_cnt == ctx->total_dpb_count) {
> > + ctx->capture_state = QUEUE_BUFS_MMAPED;
> > + } else {
> > + mfc_err("Not all buffers passed to buf_init.\n");
> > + reqbufs->count = 0;
> > + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> > + s5p_mfc_release_dec_buffers(ctx);
> > + return -ENOMEM;
> > + }
> > + if (s5p_mfc_ctx_ready(ctx)) {
> > + spin_lock_irqsave(&dev->condlock, flags);
> > + set_bit(ctx->num, &dev->ctx_work_bits);
> > + spin_unlock_irqrestore(&dev->condlock, flags);
> > + }
> > + s5p_mfc_try_run(dev);
> > + s5p_mfc_wait_for_done_ctx(ctx,
> > +
> > S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET, 1);
> > + }
> > + mfc_debug_leave();
> > + return ret;
> > +}
>
> I don't know how to handle the followings.
>
> So I suggest that in reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT case,
> how about return -EINVAL if reqbufs->count is bigger than 1.
>
> Because if reqbufs->count is bigger than 1, it is hard to handle the
> encoded
> input stream.
>
> For example: Dynamic resolution change
> Dynamic resolution change means that resolution can be changed at any
> I-frame with header on the fly during streaming.
>
> MFC H/W can detect it after getting decoding command from the driver.
> If the dynamic resolution change is detected by MFC H/W,
> driver should let application know the fact to do the following
> Sequence 1
> by application.
>
> Sequence 1:
> streamoff -> munmap -> reqbufs(0) -> S_FMT(changed resolution) ->
> querybuf
> -> mmap -> re-QBUF with the I-frame -> STREAMON -> ...
>
> Why it is hard to handle the encoded input stream in multiple input
> stream
> case is the following Sequence 2.
>
> Sequence 2:
> QBUF(0) -> QBUF(1: resolution changed I-frame) -> QBUF(2: already
> changed)
> -> QBUF(3: already changed) -> DQBUF(0) -> DQBUF(1): return fail -> ...
>
> Application cannot know the resolution change in the QBUF ioctl.
> Driver will return 0 at the QBUF because all parameters are fine.
> But after sending the decode command to MFC H/W, driver ca
Query for inter-process buffer sharing
Hello, How do you think about adding a new callback function which makes allocator for vb2 fill the reserved field in v4l2_buffer as below. As-Is: VIDIOC_QUERYBUF -> v4l2_m2m_querybuf -> vb2_querybuf -> __fill_v4l2_buffer To-Be: VIDIOC_QUERYBUF -> v4l2_m2m_querybuf -> vb2_querybuf -> __fill_v4l2_buffer + vb2_mem_ops.fill_v4l2_buffer I want to use the reserved field as for process unique key to share the buffer between inter-process. When I want to send a buffer which is allocated by A device to other process, I want to get the process unique key from VIDIOC_QUERYBUF. The process which gets the process unique key from other process will make user virtual address from the key in any other way. And then send it to B device using QBUF with USERPTR buffer type. How do you think about this concept ? Process A Process B 1. VIDIOC_QUERYBUF to get the process unique key 2. VIDIOC_DQBUF 3. Send the process unique key to Process B --->Process unique key 4. Make a user virtual address from the process unique key 5. VIDIOC_QBUF with user virtual address 6. find the paddr or device address from the user virtual addr. in videobuf2 7. H/W operation. SCM_RIGHTS can be the solution for inter-process buffer sharing. http://blog.toidinamai.de/en/programming/SCM_RIGHTS But it has risk that other process can also control the device using the shared file descriptor. So I'm trying to make another solution. Best regards, -- To unsubscribe from this list: send the line "unsubscribe 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][rfc] media, video, stv06xx, pb0100: Don't potentially deref NULL in pb0100_start().
usb_altnum_to_altsetting() may return NULL. If it does we'll dereference a NULL pointer in drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c::pb0100_start(). As far as I can tell there's not really anything more sensible than -ENODEV that we can return in that situation, but I'm not at all intimate with this code so I'd like a bit of review/comments on this before it's applied. Anyway, here's a proposed patch. Signed-off-by: Jesper Juhl --- stv06xx_pb0100.c |2 ++ 1 file changed, 2 insertions(+) compile tested only. diff --git a/drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c b/drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c index ac47b4c..75a5b9c 100644 --- a/drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c +++ b/drivers/media/video/gspca/stv06xx/stv06xx_pb0100.c @@ -217,6 +217,8 @@ static int pb0100_start(struct sd *sd) intf = usb_ifnum_to_if(sd->gspca_dev.dev, sd->gspca_dev.iface); alt = usb_altnum_to_altsetting(intf, sd->gspca_dev.alt); + if (!alt) + return -ENODEV; packet_size = le16_to_cpu(alt->endpoint[0].desc.wMaxPacketSize); /* If we don't have enough bandwidth use a lower framerate */ -- Jesper Juhl http://www.chaosbits.net/ Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please. -- To unsubscribe from this list: send the line "unsubscribe 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] v4l-dvb daily build: WARNINGS
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:Thu Jan 13 19:00:38 CET 2011 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 A linux-media.tar.bz2 archive with the latest media git sources that can be used with the media_build tree is available here: http://www.xs4all.nl/~hverkuil/logs/Thursday-linux-media.tar.bz2 Rename to linux-media.tar.bz2, put it in the media_build/linux directory, go to the directory and type 'make untar'. 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
[PATCH 1/3] [media] saa7134: Fix analog mode for Kworld SBTVD
There were some issues at tda8290 that were preventing this device
to work. Now that those fixes were fixed, we can enable analog
mode.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index e7aa588..b242600 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -5179,18 +5179,8 @@ struct saa7134_board saa7134_boards[] = {
[SAA7134_BOARD_KWORLD_PCI_SBTVD_FULLSEG] = {
.name = "Kworld PCI SBTVD/ISDB-T Full-Seg Hybrid",
.audio_clock= 0x00187de7,
-#if 0
- /*
-* FIXME: Analog mode doesn't work, if digital is enabled. The proper
-* fix is to use tda8290 driver, but Kworld seems to use an
-* unsupported version of tda8295.
-*/
- .tuner_type = TUNER_NXP_TDA18271, /*
TUNER_PHILIPS_TDA8290 */
- .tuner_addr = 0x60,
-#else
- .tuner_type = UNSET,
+ .tuner_type = TUNER_PHILIPS_TDA8290,
.tuner_addr = ADDR_UNSET,
-#endif
.radio_type = UNSET,
.radio_addr = ADDR_UNSET,
.gpiomask = 0x8e054000,
@@ -5201,6 +5191,7 @@ struct saa7134_board saa7134_boards[] = {
.vmux = 1,
.amux = TV,
.tv = 1,
+ .gpio = 0x4000,
#if 0 /* FIXME */
}, {
.name = name_comp1,
@@ -7659,36 +7650,11 @@ int saa7134_board_init2(struct saa7134_dev *dev)
break;
}
case SAA7134_BOARD_KWORLD_PCI_SBTVD_FULLSEG:
- {
- struct i2c_msg msg = { .addr = 0x4b, .flags = 0 };
- int i;
- static u8 buffer[][2] = {
- {0x30, 0x31},
- {0xff, 0x00},
- {0x41, 0x03},
- {0x41, 0x1a},
- {0xff, 0x02},
- {0x34, 0x00},
- {0x45, 0x97},
- {0x45, 0xc1},
- };
saa_writel(SAA7134_GPIO_GPMODE0 >> 2, 0x4000);
saa_writel(SAA7134_GPIO_GPSTATUS0 >> 2, 0x4000);
- /*
-* FIXME: identify what device is at addr 0x4b and what means
-* this initialization
-*/
- for (i = 0; i < ARRAY_SIZE(buffer); i++) {
- msg.buf = &buffer[i][0];
- msg.len = ARRAY_SIZE(buffer[0]);
- if (i2c_transfer(&dev->i2c_adap, &msg, 1) != 1)
- printk(KERN_WARNING
- "%s: Unable to enable tuner(%i).\n",
- dev->name, i);
- }
+ saa7134_set_gpio(dev, 27, 0);
break;
- }
} /* switch() */
/* initialize tuner */
diff --git a/drivers/media/video/saa7134/saa7134-dvb.c
b/drivers/media/video/saa7134/saa7134-dvb.c
index 3315a48..064bf2c 100644
--- a/drivers/media/video/saa7134/saa7134-dvb.c
+++ b/drivers/media/video/saa7134/saa7134-dvb.c
@@ -236,7 +236,7 @@ static struct tda18271_std_map mb86a20s_tda18271_std_map = {
static struct tda18271_config kworld_tda18271_config = {
.std_map = &mb86a20s_tda18271_std_map,
- .gate= TDA18271_GATE_DIGITAL,
+ .gate= TDA18271_GATE_ANALOG,
};
static const struct mb86a20s_config kworld_mb86a20s_config = {
@@ -623,37 +623,6 @@ static struct tda827x_config tda827x_cfg_2_sw42 = {
/* -- */
-static int __kworld_sbtvd_i2c_gate_ctrl(struct saa7134_dev *dev, int enable)
-{
- unsigned char initmsg[] = {0x45, 0x97};
- unsigned char msg_enable[] = {0x45, 0xc1};
- unsigned char msg_disable[] = {0x45, 0x81};
- struct i2c_msg msg = {.addr = 0x4b, .flags = 0, .buf = initmsg, .len =
2};
-
- if (i2c_transfer(&dev->i2c_adap, &msg, 1) != 1) {
- wprintk("could not access the I2C gate\n");
- return -EIO;
- }
- if (enable)
- msg.buf = msg_enable;
- else
- msg.buf = msg_disable;
- if (i2c_transfer(&dev->i2c_adap, &msg, 1) != 1) {
- wprintk("could not access the I2C gate\n");
- return -EIO;
- }
- msleep(20);
- return 0;
-}
-static int kworld_sbtvd_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
-{
- struct saa7134_dev *dev = fe->dvb->priv;
-
- return __kworld_sbtvd_i2c_gate_ctrl(dev, enable);
-}
-
-/* -- */
-
static struct tda1004x_config tda827x_lifeview_config = {
.demod_address = 0x08,
.invert= 1,
@@ -1660,7 +1629,6 @@ static int dv
[PATCH 3/3] [media] tda8290: Fix a bug if no tuner is detected
If tda8290 is detected, but no tuner is found, the driver will do bad things: tuner 2-0060: chip found @ 0xc0 (saa7133[0]) tda829x 2-0060: could not clearly identify tuner address, defaulting to 60 tda829x 2-0060: tuner access failed! BUG: unable to handle kernel NULL pointer dereference at 0020 IP: [] set_audio+0x47/0x170 [tda8290] PGD 1187b0067 PUD 11771e067 PMD 0 Oops: 0002 [#1] SMP last sysfs file: /sys/module/i2c_core/initstate CPU 0 Modules linked in: tda8290(U) tea5767(U) tuner(U) ir_lirc_codec(U) lirc_dev(U) ir_sony_decoder(U) ir_jvc_decoder(U) ir_rc6_decoder(U) ir_rc5_decoder(U) saa7134(+)(U) v4l2_common(U) ir_nec_decoder(U) videodev(U) v4l2_compat_ioctl32(U) rc_core(U) videobuf_dma_sg(U) videobuf_core(U) tveeprom(U) ebtable_nat ebtables xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table xt_physdev iptable_filter ip_tables ip6t_REJECT ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log parport kvm_intel kvm uinput floppy tpm_infineon wmi sg serio_raw iTCO_wdt iTCO_vendor_support tg3 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc i7core_edac edac_core nouveau Modules linked in: tda8290(U) tea5767(U) tuner(U) ir_lirc_codec(U) lirc_dev(U) ir_sony_decoder(U) ir_jvc_decoder(U) ir_rc6_decoder(U) ir_rc5_decoder(U) saa7134(+)(U) v4l2_common(U) ir_nec_decoder(U) videodev(U) v4l2_compat_ioctl32(U) rc_core(U) videobuf_dma_sg(U) videobuf_core(U) tveeprom(U) ebtable_nat ebtables xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table xt_physdev iptable_filter ip_tables ip6t_REJECT ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log parport kvm_intel kvm uinput floppy tpm_infineon wmi sg serio_raw iTCO_wdt iTCO_vendor_support tg3 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc i7core_edac edac_core nouveau ttm drm_kms_helper drm i2c_algo_bit video output i2c_core ext3 jbd mbcache firewire_ohci firewire_core crc! _itu_t sr_mod cdrom sd_mod crc_t10dif ahci dm_mod [last unloaded: microcode] Pid: 9497, comm: modprobe Not tainted 2.6.32-72.el6.x86_64 #1 HP Z400 Workstation RIP: 0010:[] [] set_audio+0x47/0x170 [tda8290] RSP: 0018:88010ba01b28 EFLAGS: 00010206 RAX: 00ff RBX: 880119522800 RCX: 0002 RDX: 3be0 RSI: 88010ba01bb8 RDI: RBP: 88010ba01b28 R08: 0002 R09: R10: R11: R12: R13: 88010ba01bb8 R14: 1900 R15: 1900 FS: 7f4b96b3d700() GS:88002820() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0020 CR3: 00011866c000 CR4: 26f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 9497, threadinfo 88010ba0, task 880100708a70) Stack: 88010ba01b98 a048c95b 88010ba01b78 0060 <0> 000e 001d a03ec838 <0> 88010abac240 880119522800 880119522800 880119522bc0 Call Trace: [] tda8295_set_params+0x3b/0x210 [tda8290] [] ? v4l2_i2c_new_subdev_cfg+0x88/0xc0 [v4l2_common] [] set_freq+0x128/0x2f0 [tuner] [] tuner_s_std+0xc4/0x740 [tuner] [] saa7134_set_tvnorm_hw+0x2d6/0x3d0 [saa7134] [] set_tvnorm+0xd5/0x100 [saa7134] [] saa7134_video_init2+0x1d/0x50 [saa7134] [] saa7134_initdev+0x6e1/0xb1d [saa7134] [] ? kobject_get+0x1a/0x30 [] local_pci_probe+0x17/0x20 [] pci_device_probe+0x101/0x120 [] ? driver_sysfs_add+0x62/0x90 [] driver_probe_device+0xa0/0x2a0 [] __driver_attach+0xab/0xb0 [] ? __driver_attach+0x0/0xb0 [] bus_for_each_dev+0x64/0x90 [] driver_attach+0x1e/0x20 [] bus_add_driver+0x200/0x300 [] driver_register+0x76/0x140 [] ? printk+0x41/0x46 [] __pci_register_driver+0x56/0xd0 [] ? saa7134_init+0x0/0x4f [saa7134] [] saa7134_init+0x4d/0x4f [saa7134] [] do_one_initcall+0x3c/0x1d0 [] sys_init_module+0xdf/0x250 [] system_call_fastpath+0x16/0x1b Code: 20 01 49 c7 c0 c9 ec 48 a0 83 7e 04 01 74 2d 8b 0d 3f 2f 00 00 85 c9 0f 85 d7 00 00 00 c9 c3 0f 1f 44 00 00 a9 03 00 01 00 74 61 47 20 02 83 7e 04 01 49 c7 c0 cc ec 48 a0 75 d3 0f b6 47 22 RIP [] set_audio+0x47/0x170 [tda8290] RSP CR2: 0020 This happens because some I2C callbacks actually depend on having the driver entirely initialized. To avoid this OOPS, just clean the I2C callbacks, as if no device were detected. Cc: Michael Krufky Signed-off-by: Mauro Carvalho Chehab diff --
[PATCH 2/3] [media] tda8290: Make all read operations atomic
Read operations should be preceeded by a write operation. However,
nothing prevents that an I2C operation could happen between the two
transactions.
To avoid that problem, use an unique I2C transfer for both parts of
the I2C transaction.
Cc: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/common/tuners/tda8290.c
b/drivers/media/common/tuners/tda8290.c
index c9062ce..5f889c1 100644
--- a/drivers/media/common/tuners/tda8290.c
+++ b/drivers/media/common/tuners/tda8290.c
@@ -95,8 +95,7 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe, int
close)
msleep(20);
} else {
msg = disable;
- tuner_i2c_xfer_send(&priv->i2c_props, msg, 1);
- tuner_i2c_xfer_recv(&priv->i2c_props, &msg[1], 1);
+ tuner_i2c_xfer_send_recv(&priv->i2c_props, msg, 1, &msg[1], 1);
buf[2] = msg[1];
buf[2] &= ~0x04;
@@ -239,13 +238,15 @@ static void tda8290_set_params(struct dvb_frontend *fe,
fe->ops.tuner_ops.set_analog_params(fe, params);
for (i = 0; i < 3; i++) {
- tuner_i2c_xfer_send(&priv->i2c_props, &addr_pll_stat, 1);
- tuner_i2c_xfer_recv(&priv->i2c_props, &pll_stat, 1);
+ tuner_i2c_xfer_send_recv(&priv->i2c_props,
+&addr_pll_stat, 1, &pll_stat, 1);
if (pll_stat & 0x80) {
- tuner_i2c_xfer_send(&priv->i2c_props, &addr_adc_sat, 1);
- tuner_i2c_xfer_recv(&priv->i2c_props, &adc_sat, 1);
- tuner_i2c_xfer_send(&priv->i2c_props, &addr_agc_stat,
1);
- tuner_i2c_xfer_recv(&priv->i2c_props, &agc_stat, 1);
+ tuner_i2c_xfer_send_recv(&priv->i2c_props,
+&addr_adc_sat, 1,
+&adc_sat, 1);
+ tuner_i2c_xfer_send_recv(&priv->i2c_props,
+&addr_agc_stat, 1,
+&agc_stat, 1);
tuner_dbg("tda8290 is locked, AGC: %d\n", agc_stat);
break;
} else {
@@ -259,20 +260,22 @@ static void tda8290_set_params(struct dvb_frontend *fe,
agc_stat, adc_sat, pll_stat & 0x80);
tuner_i2c_xfer_send(&priv->i2c_props, gainset_2, 2);
msleep(100);
- tuner_i2c_xfer_send(&priv->i2c_props, &addr_agc_stat, 1);
- tuner_i2c_xfer_recv(&priv->i2c_props, &agc_stat, 1);
- tuner_i2c_xfer_send(&priv->i2c_props, &addr_pll_stat, 1);
- tuner_i2c_xfer_recv(&priv->i2c_props, &pll_stat, 1);
+ tuner_i2c_xfer_send_recv(&priv->i2c_props,
+&addr_agc_stat, 1, &agc_stat, 1);
+ tuner_i2c_xfer_send_recv(&priv->i2c_props,
+&addr_pll_stat, 1, &pll_stat, 1);
if ((agc_stat > 115) || !(pll_stat & 0x80)) {
tuner_dbg("adjust gain, step 2. Agc: %d, lock: %d\n",
agc_stat, pll_stat & 0x80);
if (priv->cfg.agcf)
priv->cfg.agcf(fe);
msleep(100);
- tuner_i2c_xfer_send(&priv->i2c_props, &addr_agc_stat,
1);
- tuner_i2c_xfer_recv(&priv->i2c_props, &agc_stat, 1);
- tuner_i2c_xfer_send(&priv->i2c_props, &addr_pll_stat,
1);
- tuner_i2c_xfer_recv(&priv->i2c_props, &pll_stat, 1);
+ tuner_i2c_xfer_send_recv(&priv->i2c_props,
+&addr_agc_stat, 1,
+&agc_stat, 1);
+ tuner_i2c_xfer_send_recv(&priv->i2c_props,
+&addr_pll_stat, 1,
+&pll_stat, 1);
if((agc_stat > 115) || !(pll_stat & 0x80)) {
tuner_dbg("adjust gain, step 3. Agc: %d\n",
agc_stat);
tuner_i2c_xfer_send(&priv->i2c_props,
adc_head_12, 2);
@@ -284,10 +287,12 @@ static void tda8290_set_params(struct dvb_frontend *fe,
/* l/ l' deadlock? */
if(priv->tda8290_easy_mode & 0x60) {
- tuner_i2c_xfer_send(&priv->i2c_props, &addr_adc_sat, 1);
- tuner_i2c_xfer_recv(&priv->i2c_props, &adc_sat, 1);
- tuner_i2c_xfer_send(&priv->i2c_props, &addr_pll_stat, 1);
- tuner_i2c_xfer_recv(&priv->i2c_props, &pll_stat, 1);
+ tuner_i2c_xfer_send_recv(&priv->i2c_props,
+&addr_adc_sat, 1,
+&adc_sat, 1);
+
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Thu, 13 Jan 2011 12:07:34 -0500, Devin Heitmueller wrote: > On Thu, Jan 13, 2011 at 11:48 AM, Jean Delvare wrote: > > On Thu, 13 Jan 2011 11:34:42 -0500, Andy Walls wrote: > >> How should clock stretches by slaves be handled using i2c-algo-bit? > > > > It is already handled. But hdpvr-i2c doesn't use i2c-algo-bit. I2C > > support is done with USB commands instead. Maybe the hardware > > implementation doesn't support clock stretching by slaves. Apparently > > it doesn't support repeated start conditions either, so it wouldn't > > surprise me. > > The hardware implementation does support clock stretching, or else it > wouldn't be working under Windows. I think your conclusion is too fast and possibly incorrect. The traces Andy pointed us too earlier suggest that the windows driver is also "polling" the Zilog after the send operation to figure out when it is available again. If the Zilog was stretching the clock and the master was seeing that, it wouldn't return until the clock is released, so no polling would be necessary. So, either the Zilog isn't stretching the clock in the standard way, or the master doesn't notice. > That said, it's possible that the > driver for the i2c master isn't checking the proper bits to detect the > clock stretch. I haven't personally looked at the code for the i2c > master, so I cannot say one way or the other. If you're talking about hdpvr-i2c, it's sending USB commands, so it doesn't seem like we have much control over what happens behind the scene. If there is any way to improve its reliability, that will require external knowledge. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Thu, Jan 13, 2011 at 11:48 AM, Jean Delvare wrote: > On Thu, 13 Jan 2011 11:34:42 -0500, Andy Walls wrote: >> How should clock stretches by slaves be handled using i2c-algo-bit? > > It is already handled. But hdpvr-i2c doesn't use i2c-algo-bit. I2C > support is done with USB commands instead. Maybe the hardware > implementation doesn't support clock stretching by slaves. Apparently > it doesn't support repeated start conditions either, so it wouldn't > surprise me. The hardware implementation does support clock stretching, or else it wouldn't be working under Windows. That said, it's possible that the driver for the i2c master isn't checking the proper bits to detect the clock stretch. I haven't personally looked at the code for the i2c master, so I cannot say one way or the other. The Zilog is a pretty nasty beast, and for various reasons it is especially problematic on the HD-PVR due to some issues I cannot really get into on a public forum. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Thu, Jan 13, 2011 at 11:34 AM, Andy Walls wrote: > Devin, > > You've seen the clock stretch with your I2C analyzer? The Beagle I was using when I did the captures doesn't show clock stretch. My "Logic" logic analyzer does, but I wasn't using that at the time. That said, I can say with some authority that the Zilog does put the bus into a busy state after certain operations (such as setting the send bit). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
Jean, Yes, however, I asked because ivtv and cx18 use i2c-algo-bit and also provide Zilog z8 IR I2C clients for lirc_zilog to use. So if those get clock stretch handling "for free", that's great. Regards, Andy Jean Delvare wrote: >On Thu, 13 Jan 2011 11:34:42 -0500, Andy Walls wrote: >> How should clock stretches by slaves be handled using i2c-algo-bit? > >It is already handled. But hdpvr-i2c doesn't use i2c-algo-bit. I2C >support is done with USB commands instead. Maybe the hardware >implementation doesn't support clock stretching by slaves. Apparently >it doesn't support repeated start conditions either, so it wouldn't >surprise me. > >-- >Jean Delvare >-- >To unsubscribe from this list: send the line "unsubscribe linux-media" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Thu, 13 Jan 2011 11:34:42 -0500, Andy Walls wrote: > How should clock stretches by slaves be handled using i2c-algo-bit? It is already handled. But hdpvr-i2c doesn't use i2c-algo-bit. I2C support is done with USB commands instead. Maybe the hardware implementation doesn't support clock stretching by slaves. Apparently it doesn't support repeated start conditions either, so it wouldn't surprise me. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
Devin,
You've seen the clock stretch with your I2C analyzer?
Jean,
How should clock stretches by slaves be handled using i2c-algo-bit?
Regards,
Andy
Devin Heitmueller wrote:
>On Thu, Jan 13, 2011 at 8:21 AM, Jean Delvare wrote:
>> My bet is that register at 0x00 is a control register, and writing bit
>> 7 (value 0x80) makes the chip busy enough that it can't process I2C
>> requests at the same time. The following naks would be until the
>> chip is operational again.
>
>Correct. Poking bit 7 of 0xE0:00 triggers the "send" for all the
>bytes that were previously loaded into the device. It puts the chip
>into a busy state, doing an i2c clock stretch until it is available
>again. During that time it cannot see any i2c traffic, which is why
>you are getting NAKs.
>
>Devin
>
>--
>Devin J. Heitmueller - Kernel Labs
>http://www.kernellabs.com
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: [GIT PATCHES FOR 2.6.38] gspca for_2.6.38
On Thu, 13 Jan 2011 12:38:04 +0100 Antonio Ospite wrote: > > Jean-François Moine (9): > [...] > > gspca - ov534: Use the new video control mechanism > > In this commit, is there a reason why you didn't rename also > sd_setagc() into setagc() like for the other functions? > > I am going to test the changes and report back if there's anything > more, I like the cleanup tho. Hi Antonio, With the new video control mechanism, the '.set_control' function is called only when capture is active. Otherwise, the '.set' function is called in any case, and here, it activates/inactivates the auto white balance control... Oh, I forgot to disable the awb when the agc is disabled! Thank you for reporting any problem. BTW, the webcam 06f8:3002 which had been removed some time ago is being tested. I will add it to this subdriver as soon as it works correctly. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SilverCrest USB 2.0 Video Grabber VG 2000 USB-Id. eb1a:2863, em28xx module - information update
Hello, the device still does not work with my linux boxes. With new installed openSuSE 11.3 System Linux trixi 2.6.34.7-0.7- desktop #1 SMP PREEMPT 2010-12-13 11:13:53 +0100 x86_64 x86_64 x86_64 GNU/Linux. The informations about the Video Grabber VG 2000 changed. Therefore I have updatet and extended the description on http://www.linuxtv.org/wiki/index.php/SilverCrest_USB_2.0_Video_Grabber_VG_2000. I do not know, if there is anything missing or what else can I do in order to assist the developers. Best regards Martin -- "A PC without Windows is like a chocolate cake without mustard." Johannes Bauer -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Thu, Jan 13, 2011 at 8:21 AM, Jean Delvare wrote: > My bet is that register at 0x00 is a control register, and writing bit > 7 (value 0x80) makes the chip busy enough that it can't process I2C > requests at the same time. The following naks would be until the > chip is operational again. Correct. Poking bit 7 of 0xE0:00 triggers the "send" for all the bytes that were previously loaded into the device. It puts the chip into a busy state, doing an i2c clock stretch until it is available again. During that time it cannot see any i2c traffic, which is why you are getting NAKs. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Wed, 05 Jan 2011 20:02:41 -0200, Mauro Carvalho Chehab wrote:
> Em 05-01-2011 19:51, Jean Delvare escreveu:
> > If you have specific cases you don't know how to solve, please point me
> > to them and I'll take a look.
>
> You can take a look at saa7134-cards.c, for example. saa7134_tuner_setup()
> has several examples. It starts with this one:
>
> switch (dev->board) {
> case SAA7134_BOARD_BMK_MPEX_NOTUNER:
> case SAA7134_BOARD_BMK_MPEX_TUNER:
> /* Checks if the device has a tuner at 0x60 addr
> If the device doesn't have a tuner, TUNER_ABSENT
> will be used at tuner_type, avoiding loading tuner
> without needing it
>*/
> dev->i2c_client.addr = 0x60;
> board = (i2c_master_recv(&dev->i2c_client, &buf, 0) < 0)
> ? SAA7134_BOARD_BMK_MPEX_NOTUNER
> : SAA7134_BOARD_BMK_MPEX_TUNER;
>
> In this specific case, it is simply a probe for a device at address 0x60, but
This call to i2c_master_recv() could be replaced easily with
i2c_transfer(), which doesn't require an i2c_client.
Alternatively, you could delay the probe until you are ready to
instantiate the tuner device, and use i2c_new_device() when you're sure
it's there, and i2c_new_probed_device() when you aren't. This would be
nicer, but this also requires non-trivial changes.
> there are more complex cases there, with eeprom reads and/or some random init
> that happens before actually attaching some driver at the i2c address.
> It is known to work, but it sounds like a hack.
For eeprom reads, I would definitely recommend getting a clean
i2c_client from i2c-core using i2c_new_dummy() or i2c_new_device().
For "random init", well, I guess each case is different, so I can't
make a general statement.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Wed, 05 Jan 2011 19:46:20 -0500, Andy Walls wrote: > If you look at more of the dumps, it appears that accesses to I2C > addresses 0x70 and 0x71 can be interleaved, so it looks like the > IR.ir_lock might not be needed. Although looking further I see this: > > 2.035mS: 70 W 61 00 00 00 . . . > 10.887mS: 70 W 00 40 @ > 10.012mS: 70 W 00 > 681uS: 70 r A0 > 717uS: 70 W 00 80 . > 18.808mS: 70 W -nak- > 1.393mS: 70 W -nak- > 1.393mS: 70 W -nak- > 1.396mS: 70 W -nak- > 1.393mS: 70 W -nak- > 1.393mS: 70 W -nak- > [...] > 1.393mS: 70 W -nak- > 1.477mS: 71 W -nak- > 1.391mS: 71 W -nak- > 1.393mS: 71 W -nak- > 1.393mS: 71 W -nak- > 1.391mS: 71 W -nak- > 1.438mS: 71 W 00 > 681uS: 71 r 00 00 00 00 00 00 . . . . . > 51.079mS: 70 W 00 > 681uS: 70 r 80 > > Which seems to indicate that actions taken on the Transmit side of the > chip can cause it to go unresponsive for both Tx and Rx. The "goto > done;" statement that was in lirc_zilog skips the code that deals with > those -nak- for the HD PVR. My bet is that register at 0x00 is a control register, and writing bit 7 (value 0x80) makes the chip busy enough that it can't process I2C requests at the same time. The following naks would be until the chip is operational again. In fact, the "waiting" code in lirc_zilog.c:send_code() makes a lot of sense, and I wouldn't skip it: if the device is busy, you don't want to return immediately, otherwise a subsequent request will fail. The failure documented for the HD PVR simply suggests that the wait loop isn't long enough. It is 20 * 50 ms currently, i.e. 1 second total, maybe this isn't sufficient. Have you ever tried a longer delay? -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe 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 PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates
Em 13-01-2011 10:13, Andrzej Pietrasiewicz escreveu: > Hello again, Mauro, > > On Thursday, January 13, 2011 9:46 AM Andrzej Pietrasiewicz wrote: > >> >> Hello Mauro, >> >> On Wednesday, January 12, 2011 9:24 PM Mauro Carvalho Chehab wrote: >>> >>> Em 12-01-2011 08:25, Marek Szyprowski escreveu: Hello Mauro, I've rebased our fimc and saa patches onto >>> http://linuxtv.org/git/mchehab/experimental.git vb2_test branch. The last 2 patches are for SAA7134 driver and are only to show that >>> videobuf2-dma-sg works correctly. >>> >>> On my first test with saa7134, it hanged. It seems that the code >>> reached a dead lock. >>> >>> On my test environment, I'm using a remote machine, without monitor. >>> My test is using >>> qv4l2 via a remote X server. Using a remote X server is an >> interesting >>> test, as it will likely loose some frames, increasing the probability >>> of races and dead locks. >>> >> >> We did a similar test using a remote machine and qv4l2 with X >> forwarding. >> Both userptr and mmap worked. Read does not work because it is not >> implemented, but there was no freeze anyway, just green screen in >> qv4l2. >> However, we set "Capture Image Formats" to "YUV - 4:2:2 packed, YUV", >> "TV Standard" to "PAL". I enclose a (lengthy) log for reference - it is >> a log of a short session when modules where loaded, qv4l2 started, >> userptr mode run for a while and then mmap mode run for a while. >> >> We did it on a 32-bit system. We are going to repeat the test on a 64- >> bit system, it just takes some time to set it up. Perhaps this is the >> difference. > > We did the test on a 64-bit system, both locally and with X forwarding to a > remote machine. It works in both cases. > Our TV card is "Avermedia AverTV Super 007" pure analog. Yours is a hybrid > analog/ISDB card. Does your card work with videobuf 1? Yes, it works (well, sort of - there's a problem a the tuner driver that I didn't fix yet, so, I'm receiving just static on it, but yet, it is a stream, and this works fine with videobuf1). > Perhaps you could do > such a test: please use code from the commit f73e66a8e91e4ebb "v4l: saa7134: > remove radio, vbi, mpeg, input, alsa, tvaudio, saa6752hs support" and see if > you TV card works with videobuf (not videobuf2)? Ok, I'll do that, or maybe I'll just replace by an analog-only board. 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 PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates
Em 13-01-2011 06:46, Andrzej Pietrasiewicz escreveu: > Hello Mauro, > > On Wednesday, January 12, 2011 9:24 PM Mauro Carvalho Chehab wrote: >> >> Em 12-01-2011 08:25, Marek Szyprowski escreveu: >>> Hello Mauro, >>> >>> I've rebased our fimc and saa patches onto >> http://linuxtv.org/git/mchehab/experimental.git >>> vb2_test branch. >>> >>> The last 2 patches are for SAA7134 driver and are only to show that >> videobuf2-dma-sg works >>> correctly. >> >> On my first test with saa7134, it hanged. It seems that the code >> reached a dead lock. >> >> On my test environment, I'm using a remote machine, without monitor. My >> test is using >> qv4l2 via a remote X server. Using a remote X server is an interesting >> test, as it will >> likely loose some frames, increasing the probability of races and dead >> locks. >> > > We did a similar test using a remote machine and qv4l2 with X forwarding. > Both userptr and mmap worked. Read does not work because it is not > implemented, but there was no freeze anyway, just green screen in qv4l2. > However, we set "Capture Image Formats" to "YUV - 4:2:2 packed, YUV", "TV > Standard" to "PAL". I enclose a (lengthy) log for reference - it is a log of > a short session when modules where loaded, qv4l2 started, userptr mode run > for a while and then mmap mode run for a while. > > We did it on a 32-bit system. We are going to repeat the test on a 64-bit > system, it just takes some time to set it up. Perhaps this is the > difference. Yeah, I tested where with PAL/M and 64-bits, but I don't think that the hangs have something due to 64 bits. It is probably because of the high delay introduced by using the 100 Mbps Ethernet connection to display the stream. This introduces a high delay (the max frame rate drops from 30 fps to about 6 fps on my setup). So, qv4l2 will loose frames. This increases the possibility of a race between qbuf/dqbuf. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] addition to v2.6.35_i2c_new_probed_device.patch (was: Re: Debug code in HG repositories)
Em 13-01-2011 02:43, Vincent McIntyre escreveu: > On 1/12/11, Mauro Carvalho Chehab wrote: > >>> which on the face of it suggests >>> btty-input.c > > already handled, my mistake. > >>> cx88-input.c > the search string was in a comment > >>> hdpvr-i2c.c > see below > > >> I have no time currently to touch on it, since I still have lots of patches >> to >> take a look and submit for the merge window. So, if you have some time, >> could you please prepare and submit a patch fixing it? > > This seems to be a relatively simple patch, inline below. > This is against the linux-media tree, I could not figure out how > to turn it into a clean patch of > media_build/backports/v2.6.35_i2c_new_probed_device.patch > I did look for guidance on how to do this in > media_build/README.patches but could not find anything that looked > relevant. Well, there are two ways for doing it: 1) with two copies of linux/, one without your changes, and the other with your changes; 2) you may create a temporary tree, just to do your patch. That's the way I use. To avoid causing any confusion, I generally create the second tree with mercurial. Something like: $ cd media_build/linux/ $ hg init $ hg add * $ hg commit Then, I change the files, and I do: $ hg diff > ../backports/my_new_patch.patch In this specific case, before actually changing the files, I would do: $ patch -p1 -i ../backports/v2.6.35_i2c_new_probed_device.patch -R $ hg commit $ patch -p1 -i ../backports/v2.6.35_i2c_new_probed_device.patch $ hg diff > ../backports/v2.6.35_i2c_new_probed_device.patch > The code now compiles for me but I don't know if it will actually > work, I don't have the hardware. Ok, I did the above procedure, adding your patch to the diff. Please test. Thanks, 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: OMAP3 ISP and tvp5151 driver.
Hi all, 2011/1/12 Laurent Pinchart : > Hi Enric, > > On Wednesday 12 January 2011 12:58:04 Enric Balletbò i Serra wrote: >> Hi all, >> >> As explained in my first mail I would like port the tvp515x driver to >> new media framework, I'm a newbie with the v4l2 API and of course with >> the new media framework API, so sorry if next questions are stupid or >> trivial (please, patience with me). >> >> My idea is follow this link schem: >> >> --- >> >> - | | | 1 >> >> | --> | OMAP3 ISP CCDC OUTPUT | >> | TVP515x | 0 | -> | 0 | OMAP3 ISP CCDC --- | >> >> >> | | | 2 | >> --- > > ASCII art would look much better if you drew it in a non-proportional font, > with 80 character per line at most. > >> Where: >> * TVP515x is /dev/v4l-subdev8 c 81 15 >> * OMAP3 ISP CCDC is /dev/v4l-subdev2 c 81 4 >> * OMAP3 ISP CCDC OUTPUT is /dev/video2 c 81 5 >> >> Then activate these links with >> >> ./media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 >> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' >> Resetting all links to disabled >> Setting up link 16:0 -> 5:0 [1] >> Setting up link 5:1 -> 6:0 [1] >> >> I'm on the right way or I'm completely lost ? > > That's correct. > >> I think the next step is adapt the tvp515x driver to new media >> framework, I'm not sure how to do this, someone can give some points ? > > You need to implement subdev pad operations. get_fmt and set_fmt are required. I configured the TVP5151 to 8-bit 4:2:3 YCbCr output format. Is 8-bit 4:2:3 YCbCr output format implemented in OMAP3 ISP CCDC ? > >> Once this is done, I suppose I can test using gstreamer, for example >> using something like this. >> >> gst-launch v4l2src device=/dev/video2 ! ffmpegcolorspace ! xvimagesink >> >> I'm right in this point ? > > You need to specify the format explicitly. It must be identical to the format > configured on pad CCDC:1. Can you give me an example using gstreamer ? Running yavta I get # ./yavta -f SGRBG10 -s 720x525 -n 4 --capture=4 --skip 3 -F /dev/video2 Device /dev/video2 opened: OMAP3 ISP CCDC output (media). Video format set: width: 720 height: 525 buffer size: 756000 Video format: BA10 (30314142) 720x525 4 buffers requested. length: 756000 offset: 0 Buffer 0 mapped at address 0x400f2000. length: 756000 offset: 757760 Buffer 1 mapped at address 0x40385000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x40466000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x405ed000. Unable to start streaming: 22. Unable to dequeue buffer (22). 4 buffers released. I know the format is not correct, but, is the "Unable to start streaming: 22" error related to the format or is related to another problem ? Thanks in advance, Enric > > -- > Regards, > > Laurent Pinchart > -- To unsubscribe from this list: send the line "unsubscribe 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 PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates
Em 13-01-2011 01:05, Pawel Osciak escreveu: > Hi Mauro, > > On Wed, Jan 12, 2011 at 10:49, Mauro Carvalho Chehab > wrote: >> Em 12-01-2011 08:25, Marek Szyprowski escreveu: >>> Hello Mauro, >>> >>> I've rebased our fimc and saa patches onto >>> http://linuxtv.org/git/mchehab/experimental.git >>> vb2_test branch. >> >> Thanks! >> >> As before, I'll be commenting the patches as I'll be seeing any issues. >> >>> Pawel Osciak (2): >>> Fix mmap() example in the V4L2 API DocBook >> >> In fact, the check for retval < 0 instead of retval == -1 is not a fix. >> According with >> mmap man pages: >>RETURN VALUE >> On success, mmap() returns a pointer to the mapped area. On >> error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno >> is set appropriately. On success, munmap() returns 0, on >> failure -1, and errno is set (probably to EINVAL). >> >> The change is not wrong, as -1 is lower than 0, but using -1 is more >> compliant with >> libc. So, I'll be applying just the CodingStyle fixes on it. > > Sorry, but I think you got it wrong. The example is called "mmap() > example". But I did not change return value checking of mmap() calls. > I changed return value checking of ioctl() calls. So I believe the > patch is correct. >From ioctl man page: RETURN VALUE Usually, on success zero is returned. A few ioctl() requests use the return value as an output parameter and return a non-negative value on success. On error, -1 is returned, and errno is set appropriately. So, at least on glibc, it will return -1 for errors, storing the error code at errno var, and 0 for OK. Several V4L2 applications do error checks with -1. So, if some non-glibc implementation is returning a different return value, that means that several V4L applications will not work properly. Do you know any case where ioctl is implemented on a different way? 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 PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates
Hello again, Mauro, On Thursday, January 13, 2011 9:46 AM Andrzej Pietrasiewicz wrote: > > Hello Mauro, > > On Wednesday, January 12, 2011 9:24 PM Mauro Carvalho Chehab wrote: > > > > Em 12-01-2011 08:25, Marek Szyprowski escreveu: > > > Hello Mauro, > > > > > > I've rebased our fimc and saa patches onto > > http://linuxtv.org/git/mchehab/experimental.git > > > vb2_test branch. > > > > > > The last 2 patches are for SAA7134 driver and are only to show that > > videobuf2-dma-sg works > > > correctly. > > > > On my first test with saa7134, it hanged. It seems that the code > > reached a dead lock. > > > > On my test environment, I'm using a remote machine, without monitor. > > My test is using > > qv4l2 via a remote X server. Using a remote X server is an > interesting > > test, as it will likely loose some frames, increasing the probability > > of races and dead locks. > > > > We did a similar test using a remote machine and qv4l2 with X > forwarding. > Both userptr and mmap worked. Read does not work because it is not > implemented, but there was no freeze anyway, just green screen in > qv4l2. > However, we set "Capture Image Formats" to "YUV - 4:2:2 packed, YUV", > "TV Standard" to "PAL". I enclose a (lengthy) log for reference - it is > a log of a short session when modules where loaded, qv4l2 started, > userptr mode run for a while and then mmap mode run for a while. > > We did it on a 32-bit system. We are going to repeat the test on a 64- > bit system, it just takes some time to set it up. Perhaps this is the > difference. We did the test on a 64-bit system, both locally and with X forwarding to a remote machine. It works in both cases. Our TV card is "Avermedia AverTV Super 007" pure analog. Yours is a hybrid analog/ISDB card. Does your card work with videobuf 1? Perhaps you could do such a test: please use code from the commit f73e66a8e91e4ebb "v4l: saa7134: remove radio, vbi, mpeg, input, alsa, tvaudio, saa6752hs support" and see if you TV card works with videobuf (not videobuf2)? Andrzej -- To unsubscribe from this list: send the line "unsubscribe 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 PATCHES FOR 2.6.38] gspca for_2.6.38
On Thu, 13 Jan 2011 11:59:53 +0100 Jean-Francois Moine wrote: > The following changes since commit > 353b61709a555fab9745cb7aea18e1c376c413ce: > > [media] radio-si470x: Always report support for RDS (2011-01-11 14:44:28 > -0200) > > are available in the git repository at: > git://linuxtv.org/jfrancois/gspca.git for_2.6.38 > Hi Jean-François, I had a look at the ov534 changes. > Jean-François Moine (9): [...] > gspca - ov534: Use the new video control mechanism In this commit, is there a reason why you didn't rename also sd_setagc() into setagc() like for the other functions? I am going to test the changes and report back if there's anything more, I like the cleanup tho. Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgp2QgWA1sUVW.pgp Description: PGP signature
Logitech C910 camera problem
Hello, I'm trying to get working two Logitech C910 cameras in one computer and I'm unable to do it. I connect both cameras to one USB controller and first camera is starting capture without problem, but when I try to start second camera during first camera is running, I get message in log "uvcvideo: Failed to submit URB 0" and capturing fails. I have discussed this problem on quickcamteam forum and it seems, that there is problem with uvcvideo driver for this camera. Thank you Radek Masin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.38] gspca for_2.6.38
The following changes since commit 353b61709a555fab9745cb7aea18e1c376c413ce: [media] radio-si470x: Always report support for RDS (2011-01-11 14:44:28 -0200) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.38 Jean-François Moine (9): gspca: Version change. gspca: Remove __devinit, __devinitconst and __devinitdata gspca: Remove useless instructions gspca - ov519: Cleanup source and add a comment gspca - ov534: Clearer debug messages gspca - ov534: Propagate errors to higher level gspca - ov534: Use the new video control mechanism gspca - sonixj: Infrared bug fix and enhancement gspca - sonixj: Add LED (illuminator) control to the webcam 0c45:614a. drivers/media/video/gspca/benq.c |2 +- drivers/media/video/gspca/conex.c|4 +- drivers/media/video/gspca/cpia1.c|2 +- drivers/media/video/gspca/etoms.c|4 +- drivers/media/video/gspca/finepix.c |2 +- drivers/media/video/gspca/gl860/gl860.c |2 +- drivers/media/video/gspca/gspca.c|2 +- drivers/media/video/gspca/jeilinj.c |2 +- drivers/media/video/gspca/jpeg.h |4 +- drivers/media/video/gspca/konica.c |2 +- drivers/media/video/gspca/m5602/m5602_core.c |2 +- drivers/media/video/gspca/mars.c |2 +- drivers/media/video/gspca/mr97310a.c |2 +- drivers/media/video/gspca/ov519.c|8 +- drivers/media/video/gspca/ov534.c| 473 +++--- drivers/media/video/gspca/ov534_9.c |2 +- drivers/media/video/gspca/pac207.c |2 +- drivers/media/video/gspca/pac7302.c |4 +- drivers/media/video/gspca/pac7311.c |4 +- drivers/media/video/gspca/sn9c2028.c |2 +- drivers/media/video/gspca/sn9c20x.c |2 +- drivers/media/video/gspca/sonixb.c |4 +- drivers/media/video/gspca/sonixj.c | 92 +++--- drivers/media/video/gspca/spca1528.c |2 +- drivers/media/video/gspca/spca500.c |2 +- drivers/media/video/gspca/spca501.c |2 +- drivers/media/video/gspca/spca505.c |2 +- drivers/media/video/gspca/spca508.c |2 +- drivers/media/video/gspca/spca561.c |2 +- drivers/media/video/gspca/sq905.c|2 +- drivers/media/video/gspca/sq905c.c |2 +- drivers/media/video/gspca/sq930x.c |2 +- drivers/media/video/gspca/stk014.c |2 +- drivers/media/video/gspca/stv0680.c |2 +- drivers/media/video/gspca/stv06xx/stv06xx.c |2 +- drivers/media/video/gspca/sunplus.c |2 +- drivers/media/video/gspca/t613.c |2 +- drivers/media/video/gspca/tv8532.c |2 +- drivers/media/video/gspca/vc032x.c |2 +- drivers/media/video/gspca/xirlink_cit.c |2 +- drivers/media/video/gspca/zc3xx.c|2 +- 41 files changed, 218 insertions(+), 443 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe 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 v6 3/4] MFC: Add MFC 5.1 V4L2 driver
Hi,
Kamil Debski wrote:
> +/* Reqeust buffers */
> +static int vidioc_reqbufs(struct file *file, void *priv,
> + struct v4l2_requestbuffers
*reqbufs)
> +{
> + struct s5p_mfc_dev *dev = video_drvdata(file);
> + struct s5p_mfc_ctx *ctx = priv;
> + int ret = 0;
> + unsigned long flags;
> +
> + mfc_debug_enter();
> + mfc_debug("Memory type: %d\n", reqbufs->memory);
> + if (reqbufs->memory != V4L2_MEMORY_MMAP) {
> + mfc_err("Only V4L2_MEMORY_MAP is supported.\n");
> + return -EINVAL;
> + }
> + if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + /* Can only request buffers after an instance has been
opened.*/
> + if (ctx->state == MFCINST_DEC_GOT_INST) {
> + /* Decoding */
> + if (ctx->output_state != QUEUE_FREE) {
> + mfc_err("Bufs have already been
requested.\n");
> + return -EINVAL;
> + }
> + ret = vb2_reqbufs(&ctx->vq_src, reqbufs);
> + if (ret) {
> + mfc_err("vb2_reqbufs on output failed.\n");
> + return ret;
> + }
> + mfc_debug("vb2_reqbufs: %d\n", ret);
> + ctx->output_state = QUEUE_BUFS_REQUESTED;
> + }
> + } else if (reqbufs->type ==
> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> + if (ctx->capture_state != QUEUE_FREE) {
> + mfc_err("Bufs have already been requested.\n");
> + return -EINVAL;
> + }
> + ctx->capture_state = QUEUE_BUFS_REQUESTED;
> + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> + if (ret) {
> + mfc_err("vb2_reqbufs on capture failed.\n");
> + return ret;
> + }
> + if (reqbufs->count < ctx->dpb_count) {
> + mfc_err("Not enough buffers allocated.\n");
> + reqbufs->count = 0;
> + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> + return -ENOMEM;
> + }
> + ctx->total_dpb_count = reqbufs->count;
> + ret = s5p_mfc_alloc_dec_buffers(ctx);
> + if (ret) {
> + mfc_err("Failed to allocate decoding buffers.\n");
> + reqbufs->count = 0;
> + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> + return -ENOMEM;
> + }
> + if (ctx->dst_bufs_cnt == ctx->total_dpb_count) {
> + ctx->capture_state = QUEUE_BUFS_MMAPED;
> + } else {
> + mfc_err("Not all buffers passed to buf_init.\n");
> + reqbufs->count = 0;
> + ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> + s5p_mfc_release_dec_buffers(ctx);
> + return -ENOMEM;
> + }
> + if (s5p_mfc_ctx_ready(ctx)) {
> + spin_lock_irqsave(&dev->condlock, flags);
> + set_bit(ctx->num, &dev->ctx_work_bits);
> + spin_unlock_irqrestore(&dev->condlock, flags);
> + }
> + s5p_mfc_try_run(dev);
> + s5p_mfc_wait_for_done_ctx(ctx,
> +
> S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET, 1);
> + }
> + mfc_debug_leave();
> + return ret;
> +}
I don't know how to handle the followings.
So I suggest that in reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT case,
how about return -EINVAL if reqbufs->count is bigger than 1.
Because if reqbufs->count is bigger than 1, it is hard to handle the encoded
input stream.
For example: Dynamic resolution change
Dynamic resolution change means that resolution can be changed at any
I-frame with header on the fly during streaming.
MFC H/W can detect it after getting decoding command from the driver.
If the dynamic resolution change is detected by MFC H/W,
driver should let application know the fact to do the following Sequence 1
by application.
Sequence 1:
streamoff -> munmap -> reqbufs(0) -> S_FMT(changed resolution) -> querybuf
-> mmap -> re-QBUF with the I-frame -> STREAMON -> ...
Why it is hard to handle the encoded input stream in multiple input stream
case is the following Sequence 2.
Sequence 2:
QBUF(0) -> QBUF(1: resolution changed I-frame) -> QBUF(2: already changed)
-> QBUF(3: already changed) -> DQBUF(0) -> DQBUF(1): return fail -> ...
Application cannot know the resolution change in the QBUF ioctl.
Driver will return 0 at the QBUF because all parameters are fine.
But after sending the decode command to MFC H/W, driver can know that the
I-frame needs to change resolution.
In that case driver can return error at the DQBUF of the buffer.
In the sequence 2, application can know the resolution change in the
DQBUF(1)
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
Hi Andy, On Wed, 05 Jan 2011 20:20:35 -0500, Andy Walls wrote: > The cx18 driver has a function scope i2c_client for reading the EEPROM, > and there's a good reason for it. We don't want to register the EEPROM > with the I2C system and make it visible to the rest of the system, > including i2c-dev and user-space tools. To avoid EEPROM corruption, > it's better keep communication with EEPROMs to a very limited scope. Note that it is possible to declare a read-only EEPROM, so that user-space has no chance to write to it. If you really don't want user-space to touch it, the best approach is i2c_new_dummy(), because it will mark the slave address as busy, preventing i2c-dev from accessing it (unless the user forces access - but then he/she is obviously on his/her own...) The i2c_client provided by i2c_new_dummy() can be unregistered at the end of the function which needs it, or kept for the lifetime of the driver, as you prefer. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe 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: Memory sharing issue by application on V4L2 based device driver with system mmu.
Sorry for late reply. Samsung SoC C210 has many multimedia IPs. Each IP has its own MMU named SYSTEM MMU like CPU's MMU. So it can handle discontiguous memory using device own virtual address. What Inki Dae wants to discuss is how to allocate the memory and how to share it with other multimedia IPs. Thank you for interesting. Best regards, > -Original Message- > From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev- > ow...@vger.kernel.org] On Behalf Of Konrad Rzeszutek Wilk > Sent: Wednesday, January 12, 2011 2:35 AM > To: Jonghun Han > Cc: 'InKi Dae'; linux-media@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > 'linux-fbdev'; kyungmin.p...@samsung.com > Subject: Re: Memory sharing issue by application on V4L2 based device driver > with system mmu. > > > .. snip.. > > But 64KB or 1MB physically contiguous memory is better than 4KB page > > in the point of performance. > > Could you explain that in more details please? I presume you are talking about a > CPU that has a MMU unit, right? > -- > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" 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
