Re: saa7134 (not very) new board 5168:0307
hermann pitton a écrit : Hi Tom, Am Mittwoch, den 23.12.2009, 13:17 +0100 schrieb tomloh...@gmail.com: Some news, Hi hermann, we are this results : with &tda827x_cfg_0, &tda827x_cfg_1 or &tda827x_cfg_2 we have a perfect image without sound on the analogic part (test with mplayer), a partial result with dvb-t : we need to initialize first with analogic (with cold boot, the card doesn't work on dvb) but only for few seconds(sound and image are ok) then re-initialize with analogic, work for few seconds on dvb and then nothing maybe i am wrong but, the sound part for analogic is a problem of redirection, isn't it ? fixed here are our configuration for this card : in saa7134-dvb.c static struct tda1004x_config tda827x_flydvbtduo_medion_config = { .demod_address = 0x08, .invert= 1, .invert_oclk = 0, .xtal_freq = TDA10046_XTAL_16M, .agc_config= TDA10046_AGC_TDA827X, .gpio_config = TDA10046_GP01_I, .if_freq = TDA10046_FREQ_045, .i2c_gate = 0x4b, .tuner_address = 0x61, .antenna_switch = 2, .request_firmware = philips_tda1004x_request_firmware }; case SAA7134_BOARD_FLYDVBTDUO_MEDION: if (configure_tda827x_fe(dev, &tda827x_flydvbtduo_medion_config, &tda827x_cfg_2) < 0) goto dettach_frontend; break; default: wprintk("Huh? unknown DVB card?\n"); break; in saa7134-cards.c [SAA7134_BOARD_FLYDVBTDUO_MEDION] = { .name = "LifeView FlyDVB-T DUO Medion", .audio_clock= 0x00187de7, change with 0x0020 and there is a perfect sound :) fine. In README.saa7134 since Gerd wrote it the first time ;) .tuner_type = TUNER_PHILIPS_TDA8290, .radio_type = UNSET, .tuner_addr= ADDR_UNSET, .radio_addr= ADDR_UNSET, .gpiomask= 0x0020, .mpeg = SAA7134_MPEG_DVB, .inputs = {{ .name = name_tv, .vmux = 1, .amux = TV, .gpio = 0x20, /* GPIO21=High for TV input */ .tv = 1, },{ .name = name_comp1,/* Composite signal on S-Video input */ .vmux = 3, .amux = LINE1, },{ .name = name_svideo,/* S-Video signal on S-Video input */ .vmux = 8, .amux = LINE1, }}, .radio = { .name = name_radio, .amux = TV, .gpio = 0x00,/* GPIO21=Low for FM radio antenna */ }, .vendor = PCI_VENDOR_ID_PHILIPS, .device = PCI_DEVICE_ID_PHILIPS_SAA7133, .subvendor= 0x5168, .subdevice= 0x0307, /* LR307-N */ .driver_data = SAA7134_BOARD_FLYDVBTDUO_MEDION, case SAA7134_BOARD_FLYDVBTDUO_MEDION: { /* this is a hybrid board, initialize to analog mode * and configure firmware eeprom address */ u8 data[] = { 0x3c, 0x33, 0x60}; struct i2c_msg msg = {.addr=0x08, .flags=0, .buf=data, .len = sizeof(data)}; i2c_transfer(&dev->i2c_adap, &msg, 1); break; What can we do to have dvb fully supported ? Can someone point me in the right direction ? hi hermann Hmmm, is there not anything with i2c_debug=1 before it fails after a few seconds? will post this Gpio pins can trigger cascades of switches, so to know the gpio status of the card for working DVB-T on m$ might still be a desire. Maybe chips power off. will post the results of dscaler Also, for 99.99% only a shot at the dark side of the moon before ever seen, but I would also try to force TS_SERIAL to have it visited. Cheers, Hermann Thanks for you answer Cheers Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2.1 1/2] V4L: Add memory-to-memory device helper framework for V4L2.
On Wed, 2009-12-23 at 14:17 +0100, Pawel Osciak wrote: > A mem-to-mem device is a device that uses memory buffers passed by > userspace applications for both source and destination data. This is > different from existing drivers, which use memory buffers for only one > of those at once. > > In terms of V4L2 such a device would be both of OUTPUT and CAPTURE type. > Although no such devices are present in the V4L2 framework, a demand for such > a model exists, e.g. for 'resizer devices'. > > This patch also adds a separate kconfig submenu for mem-to-mem V4L devices. > > Signed-off-by: Pawel Osciak > Signed-off-by: Marek Szyprowski > Reviewed-by: Kyungmin Park Pawel, I did find a few things that I want to mention. (If you think I'm wrong on something feel free to say so, I was interrupted several times when lpoking things over.) > --- > drivers/media/video/Kconfig| 14 + > drivers/media/video/Makefile |2 + > drivers/media/video/v4l2-mem2mem.c | 671 > > include/media/v4l2-mem2mem.h | 153 > 4 files changed, 840 insertions(+), 0 deletions(-) > create mode 100644 drivers/media/video/v4l2-mem2mem.c > create mode 100644 include/media/v4l2-mem2mem.h > > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig > index 2f83be7..4e97dcf 100644 > --- a/drivers/media/video/Kconfig > +++ b/drivers/media/video/Kconfig > @@ -45,6 +45,10 @@ config VIDEO_TUNER > tristate > depends on MEDIA_TUNER > > +config V4L2_MEM2MEM_DEV > + tristate > + depends on VIDEOBUF_GEN > + > # > # Multimedia Video device configuration > # > @@ -1075,3 +1079,13 @@ config USB_S2255 > > endif # V4L_USB_DRIVERS > endif # VIDEO_CAPTURE_DRIVERS > + > +menuconfig V4L_MEM2MEM_DRIVERS > + bool "Memory-to-memory multimedia devices" > + depends on VIDEO_V4L2 > + default n > + ---help--- > + Say Y here to enable selecting drivers for V4L devices that > + use system memory for both source and destination buffers, as opposed > + to capture and output drivers, which use memory buffers for just > + one of those. > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > index 2af68ee..9fe7d40 100644 > --- a/drivers/media/video/Makefile > +++ b/drivers/media/video/Makefile > @@ -115,6 +115,8 @@ obj-$(CONFIG_VIDEOBUF_VMALLOC) += videobuf-vmalloc.o > obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o > obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o > > +obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o > + > obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o > > obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o > diff --git a/drivers/media/video/v4l2-mem2mem.c > b/drivers/media/video/v4l2-mem2mem.c > new file mode 100644 > index 000..417ee2c > --- /dev/null > +++ b/drivers/media/video/v4l2-mem2mem.c > @@ -0,0 +1,671 @@ > +/* > + * Memory-to-memory device framework for Video for Linux 2. > + * > + * Helper functions for devices that use memory buffers for both source > + * and destination. > + * > + * Copyright (c) 2009 Samsung Electronics Co., Ltd. > + * Pawel Osciak, > + * Marek Szyprowski, > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by the > + * Free Software Foundation; either version 2 of the > + * License, or (at your option) any later version > + */ > + > +#include > +#include > +#include > +#include > + > +MODULE_DESCRIPTION("Mem to mem device framework for V4L2"); > +MODULE_AUTHOR("Pawel Osciak, "); > +MODULE_LICENSE("GPL"); > + > +static int debug; > +module_param(debug, int, 0644); > + > +#define dprintk(fmt, arg...) do {\ > + if (debug >= 1)\ > + printk(KERN_DEBUG "%s: " fmt, __func__, ## arg); } while (0) > + > + > +/* The instance is already queued on the jobqueue */ > +#define TRANS_QUEUED (1 << 0) > +/* The instance is currently running in hardware */ > +#define TRANS_RUNNING(1 << 1) > + > + > +/* Offset base for buffers on the destination queue - used to distinguish > + * between source and destination buffers when mmapping - they receive the > same > + * offsets but for different queues */ > +#define DST_QUEUE_OFF_BASE (TASK_SIZE / 2) > + > + > +struct v4l2_m2m_dev { > + /* Currently running instance */ > + struct v4l2_m2m_ctx *curr_ctx; > + /* Instances queued to run */ > + struct list_headjobqueue; > + spinlock_t job_spinlock; > + > + struct v4l2_m2m_ops *m2m_ops; > +}; > + > +static inline > +struct v4l2_m2m_queue_ctx *get_queue_ctx(struct v4l2_m2m_ctx *m2m_ctx, > + enum v4l2_buf_type type) > +{ > + switch (type) { > + case V4L2_BUF_TYPE_VIDEO_CAPTURE: > + return &m2m_ctx->cap_q_ctx; > + case V4L2_BUF_TYPE_VIDEO_OUTPUT: > + return &m2m_ctx->out_q_ctx; > + default: > + printk(KE
[RFC] dvb-apps ported for ISDB-T
I wrote several patches those days in order to allow dvb-apps to properly parse ISDB-T channel.conf. On ISDB-T, there are several new parameters, so the parsing is more complex than all the other currently supported video standards. I've added the changes at: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/ I've merged there Patrick's dvb-apps-isdbt tree. While there, I fixed a few bugs I noticed on the parser and converted it to work with the DVB API v5 headers that are bundled together with dvb-apps. This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones there can now be removed. TODO: = The new ISDB-T parameters are parsed, but I haven't add yet a code to make them to be used; There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the segment parameters. Currently, the parser will fail if those parameters are found. gnutv is still reporting ISDB-T as "DVB-T". needs to review the other applications. Please review. If everything is right, I intend to commit it likely next week at dvb-apps. 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: Which modules for the VP-2033? Where is the module "mantis.ko"?
On sre, 2009-12-23 at 23:24 +0400, Manu Abraham wrote: > > Aljaz, do you have the module mantis.ko? > There was a build issue when i posted the link originally, but it had > been fixed.. > > m...@manu-04:/stor/work/merge/v4l-dvb/v4l> ls *.ko |grep mantis > mantis_core.ko > mantis.ko > Yup, I have both of them. I just compiled http://jusst.de/hg/v4l-dvb again and the result is (depmode -a was run): - ir-common.ko is under drivers/media/common (not drivers/media/IR like Igor suggested but that is probably because it's a different repository). - mantis.ko and mantis_core.ko are under drivers/media/dvb/mantis The modules loaded are: mantis 14728 0 mantis_core23909 12 mantis ir_common 27005 1 mantis_core mb86a1616598 1 mantis tda100214822 1 mantis tda100235823 1 mantis zl10353 5893 1 mantis stv0299 7860 1 mantis dvb_core 75201 2 mantis_core,stv0299 kernel log has only these lines on mantis: Mantis :03:07.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 DVB: registering new adapter (Mantis DVB adapter) DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... and that's it. No VP-2040 to be seen anywhere and it's not there even if I do cat /proc/bus/input/devices (used to be one of the inputs). So I guess this is now the work in progress if I understand correctly or should the input be recognized regardless? Just to confirm on the autoload: no, it does not happen by default. I have to manually put modules under /etc/modules to load them on startup. Regards, Aljaz -- 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: saa7134 (not very) new board 5168:0307
Hi Tom, Am Mittwoch, den 23.12.2009, 13:17 +0100 schrieb tomloh...@gmail.com: > Some news, > > Hi hermann, > > > > we are this results : > > > > with > > > > &tda827x_cfg_0, &tda827x_cfg_1 or &tda827x_cfg_2 > > > > > we have a perfect image without sound on the analogic part (test with > > mplayer), > > a partial result with dvb-t : we need to initialize first with > > analogic (with cold boot, the card doesn't work on dvb) > > but only for few seconds(sound and image are ok) then re-initialize > > with analogic, work for few seconds on dvb and then nothing > > > maybe i am wrong but, the sound part for analogic is a problem of > > redirection, isn't it ? > fixed > > > > here are our configuration for this card : > > > > in saa7134-dvb.c > > > > static struct tda1004x_config tda827x_flydvbtduo_medion_config = { > > .demod_address = 0x08, > > .invert= 1, > > .invert_oclk = 0, > > .xtal_freq = TDA10046_XTAL_16M, > > .agc_config= TDA10046_AGC_TDA827X, > > .gpio_config = TDA10046_GP01_I, > > .if_freq = TDA10046_FREQ_045, > > .i2c_gate = 0x4b, > > .tuner_address = 0x61, > > .antenna_switch = 2, > > .request_firmware = philips_tda1004x_request_firmware > > }; > > > > case SAA7134_BOARD_FLYDVBTDUO_MEDION: > > if (configure_tda827x_fe(dev, &tda827x_flydvbtduo_medion_config, > > &tda827x_cfg_2) < 0) > > goto dettach_frontend; > > break; > > default: > > wprintk("Huh? unknown DVB card?\n"); > > break; > > > > > > in saa7134-cards.c > > > >[SAA7134_BOARD_FLYDVBTDUO_MEDION] = { > >.name = "LifeView FlyDVB-T DUO Medion", > > > > >.audio_clock= 0x00187de7, > change with 0x0020 and there is a perfect sound :) fine. In README.saa7134 since Gerd wrote it the first time ;) > >.tuner_type = TUNER_PHILIPS_TDA8290, > >.radio_type = UNSET, > >.tuner_addr= ADDR_UNSET, > >.radio_addr= ADDR_UNSET, > >.gpiomask= 0x0020, > >.mpeg = SAA7134_MPEG_DVB, > >.inputs = {{ > >.name = name_tv, > >.vmux = 1, > >.amux = TV, > >.gpio = 0x20, /* GPIO21=High for TV input */ > >.tv = 1, > >},{ > >.name = name_comp1,/* Composite signal on S-Video input */ > >.vmux = 3, > >.amux = LINE1, > >},{ > >.name = name_svideo,/* S-Video signal on S-Video input */ > >.vmux = 8, > >.amux = LINE1, > >}}, > >.radio = { > >.name = name_radio, > >.amux = TV, > >.gpio = 0x00,/* GPIO21=Low for FM radio antenna */ > >}, > > > > > > .vendor = PCI_VENDOR_ID_PHILIPS, > >.device = PCI_DEVICE_ID_PHILIPS_SAA7133, > >.subvendor= 0x5168, .subdevice= 0x0307, > > /* LR307-N */ .driver_data = > > SAA7134_BOARD_FLYDVBTDUO_MEDION, > > > > case SAA7134_BOARD_FLYDVBTDUO_MEDION: > >{ > >/* this is a hybrid board, initialize to analog mode > > * and configure firmware eeprom address > > */ > >u8 data[] = { 0x3c, 0x33, 0x60}; > >struct i2c_msg msg = {.addr=0x08, .flags=0, .buf=data, .len = > > sizeof(data)}; > >i2c_transfer(&dev->i2c_adap, &msg, 1); > >break; > > > > > > > > > > What can we do to have dvb fully supported ? > Can someone point me in the right direction ? > > Hmmm, is there not anything with i2c_debug=1 before it fails after a few seconds? Gpio pins can trigger cascades of switches, so to know the gpio status of the card for working DVB-T on m$ might still be a desire. Maybe chips power off. Also, for 99.99% only a shot at the dark side of the moon before ever seen, but I would also try to force TS_SERIAL to have it visited. Cheers, Hermann -- 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: flicker/jumpy at the bottom of the video
Hi, one of the sensors managed by the gspca_gl860 has some weird resolutions : 800 x 598 and 1600 x 1198. To set these resolutions to 800 x 600 and 1600 x 1200 causes a flickering effect because of both missing lines of data from the sensor. Thus a stupid question, does the resolutions are these chip are well known ? O. Lorin 2009/12/22, Jean-Francois Moine : > On Mon, 23 Nov 2009 15:00:09 +0530 (IST) > Purushottam R S wrote: > >> I am using latest gspca driver from dvb for camera driver. But I see >> bottom of the video has flickering/jumping effect. >> >> I have "Zippys" web camera, which is from Z-Star. I have loaded the >> following drivers. >> 1. gspca_zc3xx 44832 0 - Live 0xbf01f000 >> 2. gspca_main 23840 1 gspca_zc3xx, Live 0xbf014000 >> 3. videodev 36672 1 gspca_main, Live 0xbf006000 >> 4. v4l1_compat 14788 1 videodev, Live 0xbf00 >> >> But otherwise there is no issue with video. > > Hello Purush, > > Sorry for the delay. We know that some webcams with Z-Star chips have > such a problem, but it is a hardware problem and we did not find yet a > way to fix it correctly... > > Best regards. > > -- > 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [ARM] samsung-rotator: Add Samsung S3C/S5P rotator driver
Hello, On Wed, Dec 23, 2009 at 1:08 PM, Pawel Osciak wrote: > The rotator device present on Samsung S3C and S5P series SoCs allows image > rotation and flipping. It requires contiguous memory buffers to operate, > as it does not have scatter-gather support. It is also an example of > a memory-to-memory device, and so uses the mem-2-mem device V4L2 framework. [...] > + > +static const struct v4l2_file_operations s3c_rotator_fops = { > + .owner = THIS_MODULE, > + .open = s3c_rotator_open, > + .release = s3c_rotator_release, > + .poll = s3c_rotator_poll, > + .ioctl = video_ioctl2, > + .mmap = s3c_rotator_mmap, > +}; > + > +static struct video_device m2mtest_videodev = { > + .name = S3C_ROTATOR_NAME, > + .fops = &s3c_rotator_fops, > + .ioctl_ops = &s3c_rotator_ioctl_ops, > + .minor = -1, > + .release = video_device_release, > +}; > + > +static struct v4l2_m2m_ops m2m_ops = { > + .device_run = device_run, > + .job_abort = job_abort, > +}; > + > +static int s3c_rotator_probe(struct platform_device *pdev) > +{ > + struct s3c_rotator_dev *dev; > + struct video_device *vfd; > + struct resource *res; > + int ret = -ENOENT; Here ^^^ (see below please for comments) > + > + dev = kzalloc(sizeof *dev, GFP_KERNEL); > + if (!dev) > + return -ENOMEM; > + > + spin_lock_init(&dev->irqlock); > + ret = -ENOENT; It's probably bad pedantic part of me speaking but looks like you set ret equals to -ENOENT two times. Most likely you don't need assignment second time. > + dev->irq = platform_get_irq(pdev, 0); > + if (dev->irq <= 0) { > + dev_err(&pdev->dev, "Failed to acquire irq\n"); > + goto free_dev; > + } > + > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (!res) { > + dev_err(&pdev->dev, > + "Failed to acquire memory region resource\n"); > + goto free_irq; > + } > + > + dev->regs_res = request_mem_region(res->start, resource_size(res), > + dev_name(&pdev->dev)); > + if (!dev->regs_res) { > + dev_err(&pdev->dev, "Failed to reserve memory region\n"); > + goto free_irq; > + } > + > + dev->regs_base = ioremap(res->start, resource_size(res)); > + if (!dev->regs_base) { > + dev_err(&pdev->dev, "Ioremap failed\n"); > + ret = -ENXIO; > + goto rel_res; > + } > + > + ret = request_irq(dev->irq, s3c_rotator_isr, 0, > + S3C_ROTATOR_NAME, dev); > + if (ret) { > + dev_err(&pdev->dev, "Requesting irq failed\n"); > + goto regs_unmap; > + } > + > + ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev); > + if (ret) > + goto regs_unmap; > + > + atomic_set(&dev->num_inst, 0); > + > + vfd = video_device_alloc(); > + if (!vfd) { > + v4l2_err(&dev->v4l2_dev, "Failed to allocate video device\n"); > + goto unreg_dev; > + } > + > + *vfd = m2mtest_videodev; > + > + ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0); > + if (ret) { > + v4l2_err(&dev->v4l2_dev, "Failed to register video device\n"); > + goto rel_vdev; > + } > + > + video_set_drvdata(vfd, dev); > + snprintf(vfd->name, sizeof(vfd->name), "%s", m2mtest_videodev.name); > + dev->vfd = vfd; > + v4l2_info(&dev->v4l2_dev, > + "Device registered as /dev/video%d\n", vfd->num); > + > + platform_set_drvdata(pdev, dev); > + > + dev->m2m_dev = v4l2_m2m_init(&m2m_ops); > + if (IS_ERR(dev->m2m_dev)) { > + v4l2_err(&dev->v4l2_dev, "Failed to init mem2mem device\n"); > + ret = PTR_ERR(dev->m2m_dev); > + goto err_m2m; > + } > + > + return 0; > + > +err_m2m: > + video_unregister_device(dev->vfd); > +rel_vdev: > + video_device_release(vfd); > +unreg_dev: > + v4l2_device_unregister(&dev->v4l2_dev); > +regs_unmap: > + iounmap(dev->regs_base); > +rel_res: > + release_resource(dev->regs_res); > + kfree(dev->regs_res); > +free_irq: > + free_irq(dev->irq, dev); > +free_dev: > + kfree(dev); > + > + return ret; > +} > + > +static int s3c_rotator_remove(struct platform_device *pdev) > +{ > + struct s3c_rotator_dev *dev = > + (struct s3c_rotator_dev *)platform_get_drvdata(pdev); > + > + v4l2_info(&dev->v4l2_dev, "Removing %s\n", S3C_ROTATOR_NAME); > + > + v4l2_m2m_release(dev->m2m_dev); > + video_unregister_device(dev->vfd); > + v4l2_device_unregister(&dev->v4l2_dev); > + iounmap(
Re: Which modules for the VP-2033? Where is the module "mantis.ko"?
Manu Abraham schrieb: > On Thu, Dec 24, 2009 at 12:01 AM, Ruediger Dohmhardt > wrote: > >> Manu Abraham schrieb: >> >>> Hello Ruediger, >>> >>> On Wed, Dec 23, 2009 at 11:04 PM, Ruediger Dohmhardt >>> wrote: >>> >>> Aljaž Prusnik schrieb: > If using the http://jusst.de/hg/v4l-dvb tree, everything compiles ok, > module loads, but there is no remote anywhere (there is an IR folder > with the ir-common.ko file, under common there is not). > > > > Aljaz, do you have the module mantis.ko? Ruediger >>> There was a build issue when i posted the link originally, but it had >>> been fixed.. >>> >>> >>> >> Yupp, it works now! >> >> I just downloaded version 2315248f648c. It compiles fine on Suse 11.1 and >> it works here with vdr-1.7.10 and xineliboutput (from CVS). >> >> However, as Aljaž also noted, the driver does not "autoload". >> I need to do modprobe mantis.ko. >> >> Manu, this used to work, but I do not remember when the "autoload was lost". >> > > > Have you run depmod ? > Yes, I did depmod -a several times. Actually, if I were to miss a "depmod" than also the command modprobe mantis would not work, because the module would not be found. Ruediger -- 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: Which modules for the VP-2033? Where is the module "mantis.ko"?
On Thu, Dec 24, 2009 at 12:01 AM, Ruediger Dohmhardt wrote: > Manu Abraham schrieb: >> Hello Ruediger, >> >> On Wed, Dec 23, 2009 at 11:04 PM, Ruediger Dohmhardt >> wrote: >> >>> Aljaž Prusnik schrieb: >>> If using the http://jusst.de/hg/v4l-dvb tree, everything compiles ok, module loads, but there is no remote anywhere (there is an IR folder with the ir-common.ko file, under common there is not). >>> Aljaz, do you have the module mantis.ko? >>> >>> Ruediger >>> >>> >> >> There was a build issue when i posted the link originally, but it had >> been fixed.. >> >> > Yupp, it works now! > > I just downloaded version 2315248f648c. It compiles fine on Suse 11.1 and > it works here with vdr-1.7.10 and xineliboutput (from CVS). > > However, as Aljaž also noted, the driver does not "autoload". > I need to do modprobe mantis.ko. > > Manu, this used to work, but I do not remember when the "autoload was lost". Have you run depmod ? Regards, 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: Which modules for the VP-2033? Where is the module "mantis.ko"?
Manu Abraham schrieb: > Hello Ruediger, > > On Wed, Dec 23, 2009 at 11:04 PM, Ruediger Dohmhardt > wrote: > >> Aljaž Prusnik schrieb: >> >>> If using the http://jusst.de/hg/v4l-dvb tree, everything compiles ok, >>> module loads, but there is no remote anywhere (there is an IR folder >>> with the ir-common.ko file, under common there is not). >>> >>> >>> >> Aljaz, do you have the module mantis.ko? >> >> Ruediger >> >> > > There was a build issue when i posted the link originally, but it had > been fixed.. > > Yupp, it works now! I just downloaded version 2315248f648c. It compiles fine on Suse 11.1 and it works here with vdr-1.7.10 and xineliboutput (from CVS). However, as Aljaž also noted, the driver does not "autoload". I need to do modprobe mantis.ko. Manu, this used to work, but I do not remember when the "autoload was lost". Ciao Ruediger D. -- 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: Which modules for the VP-2033? Where is the module "mantis.ko"?
Hello Ruediger, On Wed, Dec 23, 2009 at 11:04 PM, Ruediger Dohmhardt wrote: > Aljaž Prusnik schrieb: >> >> If using the http://jusst.de/hg/v4l-dvb tree, everything compiles ok, >> module loads, but there is no remote anywhere (there is an IR folder >> with the ir-common.ko file, under common there is not). >> >> > Aljaz, do you have the module mantis.ko? > > Ruediger > There was a build issue when i posted the link originally, but it had been fixed.. m...@manu-04:/stor/work/merge/v4l-dvb/v4l> ls *.ko |grep mantis mantis_core.ko mantis.ko Dec 12 01:18:25 manu-04 kernel: [168362.291827] found a VP-2033 PCI DVB-C device on (06:01.0), Dec 12 01:18:25 manu-04 kernel: [168362.291842] Mantis :06:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 Dec 12 01:18:25 manu-04 kernel: [168362.291848] Mantis :06:01.0: enabling bus mastering Dec 12 01:18:25 manu-04 kernel: [168362.291876] Mantis Rev 1 [1822:0008], irq: 17, latency: 64 Dec 12 01:18:25 manu-04 kernel: [168362.291881] memory: 0x0, mmio: 0xf875e000 Dec 12 01:18:25 manu-04 kernel: [168362.292577] i2c-adapter i2c-7: adapter [Mantis I2C] registered Dec 12 01:18:25 manu-04 kernel: [168362.292586] i2c-adapter i2c-7: master_xfer[0] W, addr=0x50, len=1 Dec 12 01:18:25 manu-04 kernel: [168362.292590] i2c-adapter i2c-7: master_xfer[1] R, addr=0x50, len=6 Dec 12 01:18:25 manu-04 kernel: [168362.292593] mantis_i2c_write: Address=[0x50] [ 08 ] Dec 12 01:18:25 manu-04 kernel: [168362.292813] mantis_i2c_read: Address=[0x50] [ 00 08 ca 19 ea ee ] Dec 12 01:18:25 manu-04 kernel: [168362.293539] MAC Address=[00:08:ca:19:ea:ee] Dec 12 01:18:25 manu-04 kernel: [168362.293565] mantis_alloc_buffers (0): DMA=0x2c5 cpu=0xc2c5 size=65536 Dec 12 01:18:25 manu-04 kernel: [168362.293571] mantis_alloc_buffers (0): RISC=0x31e36000 cpu=0xf1e36000 size=1000 Dec 12 01:18:25 manu-04 kernel: [168362.293575] DVB: registering new adapter (Mantis DVB adapter) Dec 12 01:18:26 manu-04 kernel: [168363.172508] vp2033_frontend_init (0): Probing for CU1216 (DVB-C) Dec 12 01:18:26 manu-04 kernel: [168363.172515] i2c-adapter i2c-7: master_xfer[0] W, addr=0x50, len=1 Dec 12 01:18:26 manu-04 kernel: [168363.172519] i2c-adapter i2c-7: master_xfer[1] R, addr=0x50, len=1 Dec 12 01:18:26 manu-04 kernel: [168363.172522] mantis_i2c_write: Address=[0x50] [ ff ] Dec 12 01:18:26 manu-04 kernel: [168363.172741] mantis_i2c_read: Address=[0x50] [ 22 ] Dec 12 01:18:26 manu-04 kernel: [168363.172967] i2c-adapter i2c-7: master_xfer[0] W, addr=0x0c, len=1 Dec 12 01:18:26 manu-04 kernel: [168363.172970] i2c-adapter i2c-7: master_xfer[1] R, addr=0x0c, len=1 Dec 12 01:18:26 manu-04 kernel: [168363.172973] mantis_i2c_write: Address=[0x0c] [ 1a ] Dec 12 01:18:26 manu-04 kernel: [168363.173194] mantis_i2c_read: Address=[0x0c] [ 7c ] Dec 12 01:18:26 manu-04 kernel: [168363.173416] TDA10021: i2c-addr = 0x0c, id = 0x7c Dec 12 01:18:26 manu-04 kernel: [168363.173419] vp2033_frontend_init (0): found Philips CU1216 DVB-C frontend (TDA10021) @ 0x0c Dec 12 01:18:26 manu-04 kernel: [168363.173422] vp2033_frontend_init (0): Mantis DVB-C Philips CU1216 frontend attach success Dec 12 01:18:26 manu-04 kernel: [168363.173428] DVB: registering adapter 0 frontend 0 (Philips TDA10021 DVB-C)... Dec 12 01:18:26 manu-04 kernel: [168363.173549] mantis_uart_init (0): Initializing UART @ 9600 bps NONE parity Dec 12 01:18:26 manu-04 kernel: [168363.175459] mantis_uart_work (0): UART BUF:0 <3f> The IR stuff needs a bit more work, which I will be pushing out, later .. Regards, 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
[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:Wed Dec 23 19:00:13 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13842:4506e2d54126 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: ERRORS linux-2.6.28-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30-i686: ERRORS linux-2.6.31-i686: ERRORS linux-2.6.32-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS spec: OK sparse (linux-2.6.32): ERRORS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which modules for the VP-2033? Where is the module "mantis.ko"?
Aljaž Prusnik schrieb: > > If using the http://jusst.de/hg/v4l-dvb tree, everything compiles ok, > module loads, but there is no remote anywhere (there is an IR folder > with the ir-common.ko file, under common there is not). > > Aljaz, do you have the module mantis.ko? Ruediger -- 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] Davinci VPFE Capture: Add Suspend/Resume Support
> -Original Message- > From: Karicheri, Muralidharan > Sent: Monday, December 21, 2009 7:00 PM > To: Hiremath, Vaibhav; linux-media@vger.kernel.org > Cc: hverk...@xs4all.nl > Subject: RE: [PATCH] Davinci VPFE Capture: Add Suspend/Resume > Support > > Vaibhav, > > Did you address my comments against this patch? What was > the resolution. I haven't seen any response from you. Please > forward me any response that you had sent. > [Hiremath, Vaibhav] Your comment was, > >> For this and below, You are using every 4th location in the array > >> for saving register values which is not necessary if you use > >> something like. > >> ccdc_ctx[CCDC_PCR >> 2] = regr(CCDC_PCR); > >> ccdc_ctx[CCDC_SYN_MODE >> 2] = regr(CCDC_SYN_MODE); > >> Any reason why you do this way? Actually the main reason why I did not do this was "VP_OUT" register, the VP_OUT offset is 0x94. But I think I can do something like you suggested for others and for VP_OUT will anyway will come to last. I will incorporate the change in next post. Thanks, Vaibhav > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > phone: 301-407-9583 > email: m-kariche...@ti.com > >-Original Message- > >From: Hiremath, Vaibhav > >Sent: Monday, December 21, 2009 1:29 AM > >To: Karicheri, Muralidharan; linux-media@vger.kernel.org > >Cc: hverk...@xs4all.nl > >Subject: RE: [PATCH] Davinci VPFE Capture: Add Suspend/Resume > Support > > > >> -Original Message- > >> From: Karicheri, Muralidharan > >> Sent: Friday, November 20, 2009 3:31 AM > >> To: Hiremath, Vaibhav; linux-media@vger.kernel.org > >> Cc: hverk...@xs4all.nl > >> Subject: RE: [PATCH] Davinci VPFE Capture: Add Suspend/Resume > >> Support > >> > >> Vaibhav, > >> > >> I have some comments. I have tested this patch for normal > >> use case of tvp5146 capture on DM355. It looks ok. We > >> don't have support for power management on DM355. So I couldn't > >> test the suspend & resume operations. > >> > >[Hiremath, Vaibhav] Murali, > > > >If you don't any further comments/analysis, this patch should go > in. I will > >resubmit the patch against the tip. > > > >Thanks, > >Vaibhav > > > >> > > >> > struct ccdc_hw_device { > >> >diff --git a/drivers/media/video/davinci/dm644x_ccdc.c > >> >b/drivers/media/video/davinci/dm644x_ccdc.c > >> >index 5dff8d9..fdab823 100644 > >> >--- a/drivers/media/video/davinci/dm644x_ccdc.c > >> >+++ b/drivers/media/video/davinci/dm644x_ccdc.c > >> >@@ -88,6 +88,10 @@ static void *__iomem ccdc_base_addr; > >> > static int ccdc_addr_size; > >> > static enum vpfe_hw_if_type ccdc_if_type; > >> > > >> >+#define CCDC_SZ_REGS SZ_1K > >> >+ > >> >+static u32 ccdc_ctx[CCDC_SZ_REGS / sizeof(u32)]; > >> > >> The last register is at 0x94 on DM6446. So do we need 256 > >> entries when we have only 37 registers? > >> > >> >+ > >> > /* register access routines */ > >> > static inline u32 regr(u32 offset) > >> > { > >> >@@ -834,6 +838,87 @@ static int ccdc_set_hw_if_params(struct > >> >vpfe_hw_if_param *params) > >> > return 0; > >> > } > >> > > >> >+static void ccdc_save_context(void) > >> >+{ > >> >+ ccdc_ctx[CCDC_PCR] = regr(CCDC_PCR); > >> > >> > >> For this and below, You are using every 4th location in the array > >> for saving register values which is not necessary if you use > >> something like. > >> ccdc_ctx[CCDC_PCR >> 2] = regr(CCDC_PCR); > >> ccdc_ctx[CCDC_SYN_MODE >> 2] = regr(CCDC_SYN_MODE); > >> Any reason why you do this way? > >> > >> >+ ccdc_ctx[CCDC_SYN_MODE] = regr(CCDC_SYN_MODE); > >> >+ ccdc_ctx[CCDC_HD_VD_WID] = regr(CCDC_HD_VD_WID); > >> >+ ccdc_ctx[CCDC_PIX_LINES] = regr(CCDC_PIX_LINES); > >> >+ ccdc_ctx[CCDC_HORZ_INFO] = regr(CCDC_HORZ_INFO); > >> >+ ccdc_ctx[CCDC_VERT_START] = regr(CCDC_VERT_START); > >> >+ ccdc_ctx[CCDC_VERT_LINES] = regr(CCDC_VERT_LINES); > >> >+ ccdc_ctx[CCDC_CULLING] = regr(CCDC_CULLING); > >> >+ ccdc_ctx[CCDC_HSIZE_OFF] = regr(CCDC_HSIZE_OFF); > >> >+ ccdc_ctx[CCDC_SDOFST] = regr(CCDC_SDOFST); > >> >+ ccdc_ctx[CCDC_SDR_ADDR] = regr(CCDC_SDR_ADDR); > >> >+ ccdc_ctx[CCDC_CLAMP] = regr(CCDC_CLAMP); > >> >+ ccdc_ctx[CCDC_DCSUB] = regr(CCDC_DCSUB); > >> >+ ccdc_ctx[CCDC_COLPTN] = regr(CCDC_COLPTN); > >> >+ ccdc_ctx[CCDC_BLKCMP] = regr(CCDC_BLKCMP); > >> >+ ccdc_ctx[CCDC_FPC] = regr(CCDC_FPC); > >> >+ ccdc_ctx[CCDC_FPC_ADDR] = regr(CCDC_FPC_ADDR); > >> >+ ccdc_ctx[CCDC_VDINT] = regr(CCDC_VDINT); > >> >+ ccdc_ctx[CCDC_ALAW] = regr(CCDC_ALAW); > >> >+ ccdc_ctx[CCDC_REC656IF] = regr(CCDC_REC656IF); > >> >+ ccdc_ctx[CCDC_CCDCFG] = regr(CCDC_CCDCFG); > >> >+ ccdc_ctx[CCDC_FMTCFG] = regr(CCDC_FMTCFG); > >> >+ ccdc_ctx[CCDC_FMT_HORZ] = regr(CCDC_FMT_HORZ); > >> >+ ccdc_ctx[CCDC_FMT_VERT] = regr(CCDC_FMT_VERT); > >> >+ ccdc_ctx[CCDC_FMT_ADDR0] = regr(CCDC_FMT_ADDR0); > >> >+ ccdc_ctx[CCDC_FMT_ADDR1] = regr(CCDC_FMT_ADDR1); > >> >+ ccdc_ctx[CCDC_FMT_ADDR2] = regr(CCDC_FMT_ADDR2); > >> >+ ccdc_ctx[CCDC_FMT_ADDR3] = regr(CCDC_FMT_ADDR3); > >> >+ ccdc_ctx[CCDC_FMT_ADDR4] = regr
Re: Which modules for the VP-2033? Where is the module "mantis.ko"?
On sre, 2009-12-23 at 17:53 +0200, Igor M. Liplianin wrote: > Since module ir-common.ko moved to IR directory just remove old one. > > rm /lib/modules/$(uname -r)/kernel/drivers/media/common/ir-common.ko > > Also it would be good to do > > make remove > > Then again build and install drivers. > Ok. There was no common folder in the above path. Anyway, I did rm and make remove and did a new build (2.6.33-rc1). First, there were warnings: WARNING: "ir_input_register" [/mnt/storage/temp/technisat/s2-liplianin/v4l/saa7134.ko] undefined! WARNING: "ir_input_unregister" [/mnt/storage/temp/technisat/s2-liplianin/v4l/saa7134.ko] undefined! WARNING: "ir_input_register" [/mnt/storage/temp/technisat/s2-liplianin/v4l/mantis.ko] undefined! WARNING: "ir_input_register" [/mnt/storage/temp/technisat/s2-liplianin/v4l/ir-kbd-i2c.ko] undefined! WARNING: "ir_input_unregister" [/mnt/storage/temp/technisat/s2-liplianin/v4l/ir-kbd-i2c.ko] undefined! WARNING: "ir_core_debug" [/mnt/storage/temp/technisat/s2-liplianin/v4l/ir-common.ko] undefined! WARNING: "ir_g_keycode_from_table" [/mnt/storage/temp/technisat/s2-liplianin/v4l/ir-common.ko] undefined! WARNING: "ir_input_register" [/mnt/storage/temp/technisat/s2-liplianin/v4l/em28xx.ko] undefined! WARNING: "ir_input_unregister" [/mnt/storage/temp/technisat/s2-liplianin/v4l/em28xx.ko] undefined! WARNING: "ir_input_register" [/mnt/storage/temp/technisat/s2-liplianin/v4l/cx88xx.ko] undefined! WARNING: "ir_input_unregister" [/mnt/storage/temp/technisat/s2-liplianin/v4l/cx88xx.ko] undefined! WARNING: "ir_input_register" [/mnt/storage/temp/technisat/s2-liplianin/v4l/cx23885.ko] undefined! WARNING: "ir_input_unregister" [/mnt/storage/temp/technisat/s2-liplianin/v4l/cx23885.ko] undefined! WARNING: "ir_input_register" [/mnt/storage/temp/technisat/s2-liplianin/v4l/bttv.ko] undefined! WARNING: "ir_input_unregister" [/mnt/storage/temp/technisat/s2-liplianin/v4l/bttv.ko] undefined! Then I restarted the machine and this is in the kernel log: ir_common: Unknown symbol ir_g_keycode_from_table ir_common: Unknown symbol ir_core_debug + no mantis module loaded. I have the IR folder under lib/modules where ir-common.ko resides. In the common folder there is no file ir-common.ko. If I do manual loading, I get: sudo modprobe mantis WARNING: Error inserting mb86a16 (/lib/modules/2.6.33-rc1/kernel/drivers/media/dvb/frontends/mb86a16.ko): Unknown symbol in module, or unknown parameter (see dmesg) FATAL: Error inserting mantis (/lib/modules/2.6.33-rc1/kernel/drivers/media/dvb/mantis/mantis.ko): Unknown symbol in module, or unknown parameter (see dmesg) dmesg says: [ 289.939402] ir_common: Unknown symbol ir_g_keycode_from_table [ 289.939690] ir_common: Unknown symbol ir_core_debug This is the s2-liplianin tree. If using the http://jusst.de/hg/v4l-dvb tree, everything compiles ok, module loads, but there is no remote anywhere (there is an IR folder with the ir-common.ko file, under common there is not). Aljaz -- 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
videobuf-dma-contig.c cached user mapping
Hi, I would like to add support for cached user mapping to videobuf-dma-contig.c. For enabling this, "vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);" line should be removed. But now we should ensure user mapping cache coherency. For that, for a camera we should : - invalidate cache before dma operation (to have not old buffer data in the cache) - forbid the user to access the buffer during the dma operation (to not pollute the cache) Is it possible ? How can we achieve that ? I see sync method, that seems only called after frame capture ? Thanks, Matthieu -- 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: Which modules for the VP-2033? Where is the module "mantis.ko"?
On 23 декабря 2009 16:30:16 Aljaž Prusnik wrote: > In the same vein, I'm interested in this one, namely: > > I have tried the http://jusst.de/hg/v4l-dvb, since recently the > liplianin mantis driver is not working (unknown symbols...). > > However, the problems I have as opposed to the previously working driver > are: > - the module does not install in a way it gets autoloaded on startup - I > have to manually add it (modprobe) or put it into /etc/modules (debian) > - while the card itself works, I don't have IR functionality anymore. > > >From what I gather from the kernel log, the input line > > input: Mantis VP-2040 IR Receiver as /devices/virtual/input/input4 > > just doesn't exist anymore. Further more the whole bunch is missing: > > mantis_ca_init (0): Registering EN50221 device > mantis_ca_init (0): Registered EN50221 device > mantis_hif_init (0): Adapter(0) Initializing Mantis Host Interface > input: Mantis VP-2040 IR Receiver as /devices/virtual/input/input4 > Creating IR device irrcv0 > > > I tried 2.6.32 kernel which worked before, now I'm using 2.6.33-rc1 > where I had to comment out #include the from the > v4l-dvb/v4l/config-compat.h. > > > Any ideas how to get the comfort back? ;) > > Regards, > Aljaz > > > > -- > 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 Since module ir-common.ko moved to IR directory just remove old one. rm /lib/modules/$(uname -r)/kernel/drivers/media/common/ir-common.ko Also it would be good to do make remove Then again build and install drivers. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v2 4/6] V4L - vpfe_capture - bug fixes and enhancements
Hans, The change is because of the void * type that we use. Since ccdc parameter structures are different for different IPs, a constant type for this arg is not possible. The ccdc driver needs the pointer to structure. But the v4l2 core tries to copies 4 bytes of data from the void * pointed location which is not what we want. I am sure this code will change once we have a device node available for ccdc on which case, this ioctl will be handled by the ccdc sub device node. The long term goal is to convert ccdc/isif drivers to sub device and pass this user ioctl to that sub device node. But currently we don't have support for device nodes for sub devices. I think that is needed for this conversion to be complete. >BTW, does this patch series rely on the patches in my v4l-dvb-davinci tree? >Or are these independent patches? Yes, this is dependent on my earlier patch. I had asked Mauro to merge that patch to linux-next, but still waiting Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com >-Original Message- >From: Hans Verkuil [mailto:hverk...@xs4all.nl] >Sent: Wednesday, December 23, 2009 9:24 AM >To: Karicheri, Muralidharan >Cc: linux-media@vger.kernel.org; khil...@deeprootsystems.com; Hiremath, >Vaibhav; Nori, Sekhar; davinci-linux-open-sou...@linux.davincidsp.com >Subject: Re: [PATCH - v2 4/6] V4L - vpfe_capture - bug fixes and >enhancements > >Hi Murali, > >Sorry for the long delay in reviewing this patch series. I've been very >busy, >first at work, and now for Christmas preparations (and occasionally I'd >like >to relax as well :-) ). > >I'm OK with the other patches in this series, but I do have a few comments >on this one: I noticed that you added a wrapper function for video_ioctl2. >I don't quite understand why. > >BTW, does this patch series rely on the patches in my v4l-dvb-davinci tree? >Or are these independent patches? Is it because the experimental >VPFE_CMD_S/G_CCDC_RAW_PARAMS ioctls are used with different argument >pointers? >I mean, currently the arg is a void * instead of a properly typed argument. > >However, if it always uses the same type, then you should use that type in >_IOR/_IOW and use video_ioctl2 directly so that the core framework will do >the >user-to-kernelspace conversion (and vv) for you. > >Regards, > > Hans > >On Saturday 19 December 2009 00:58:25 m-kariche...@ti.com wrote: >> From: Muralidharan Karicheri >> >> Updated based on comments against v1 of the patch >> >> Added a experimental IOCTL, to read the CCDC parameters. >> Default handler was not getting the original pointer from the core. >> So a wrapper function added to handle the default handler properly. >> Also fixed a bug in the probe() in the linux-next tree >> >> Reviewed-by: Hans Verkuil >> Signed-off-by: Muralidharan Karicheri >> --- >> Applies to linux-next of v4l-dvb >> drivers/media/video/davinci/vpfe_capture.c | 120 +- >-- >> include/media/davinci/vpfe_capture.h | 12 ++- >> 2 files changed, 81 insertions(+), 51 deletions(-) >> >> diff --git a/drivers/media/video/davinci/vpfe_capture.c >b/drivers/media/video/davinci/vpfe_capture.c >> index 9e3a531..99ffc62 100644 >> --- a/drivers/media/video/davinci/vpfe_capture.c >> +++ b/drivers/media/video/davinci/vpfe_capture.c >> @@ -758,12 +758,83 @@ static unsigned int vpfe_poll(struct file *file, >poll_table *wait) >> return 0; >> } >> >> +static long vpfe_param_handler(struct file *file, void *priv, >> +int cmd, void *param) >> +{ >> +struct vpfe_device *vpfe_dev = video_drvdata(file); >> +int ret = 0; >> + >> +v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_param_handler\n"); >> + >> +if (NULL == param) { >> +v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, >> +"Invalid user ptr\n"); >> +return -EINVAL; >> +} >> + >> +if (vpfe_dev->started) { >> +/* only allowed if streaming is not started */ >> +v4l2_err(&vpfe_dev->v4l2_dev, "device already started\n"); >> +return -EBUSY; >> +} >> + >> +switch (cmd) { >> +case VPFE_CMD_S_CCDC_RAW_PARAMS: >> +v4l2_warn(&vpfe_dev->v4l2_dev, >> + "VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n"); >> +ret = mutex_lock_interruptible(&vpfe_dev->lock); >> +if (ret) >> +return ret; >> +ret = ccdc_dev->hw_ops.set_params(param); >> +if (ret) { >> +v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, >> +"Error in setting parameters in CCDC\n"); >> +goto unlock_out; >> +} >> + >> +if (vpfe_get_ccdc_image_format(vpfe_dev, &vpfe_dev->fmt) < 0) { >> +v4l2_err(&vpfe_dev->v4l2_dev, >> +"Invalid image format at CCDC\n"); >> +ret = -
Re: [PATCH/RFC v2.1 0/2] Mem-to-mem device framework
On Wednesday 23 December 2009 14:17:32 Pawel Osciak wrote: > Hello, > > this is the second version of the proposed implementation for mem-to-mem > memory > device framework. Your comments are very welcome. Hi Pawel, Thank you for working on this! It's much appreciated. Now I've noticed that patches regarding memory-to-memory and memory pool tend to get very few comments. I suspect that the main reason is that these are SoC-specific features that do not occur in consumer-type products. So most v4l developers do not have the interest and motivation (and time!) to look into this. I'm CC-ing this reply to developers from Intel, TI, Nokia and Renesas in the hope that they will find some time to review and think about this since this will affect all of them. One thing that I am missing is a high-level overview of what we want. Currently there are patches/RFCs floating around for memory-to-memory support, multiplanar support and memory-pool support. What I would like to see is a RFC that ties this all together from the point of view of the public API. I.e. what are the requirements? Possibly solutions? Open questions? Forget about how to implement it for the moment, that will follow from the chosen solutions. Note that I would suggest though that the memory-pool part is split into two parts: how to actually allocate the memory is pretty much separate from how v4l will use it. The actual allocation part is probably quite complex and might even be hardware dependent and should be discussed separately. But how to use it is something that can be discussed without needing to know how it was allocated. The lack of discussion in this area does worry me a bit. IMHO this is a very important area that needs a lot more work. The initiative should be with the SoC companies and right now it seems only Samsung is active. BTW, what is the status of the multiplanar RFC? I later realized that that RFC might be very useful for adding meta-data to buffers. There are several cases where that is useful: sensors that provide meta-data when capturing a frame and imagepipelines (particularly in memory-to-memory cases) that want to have all parameters as part of the meta-data associated with the image. There may well be more of those. Regards, Hans > > In v2.1: > I am very sorry for the resend, but somehow an orphaned endif found its way to > Kconfig during the rebase. > > Changes since v1: > - v4l2_m2m_buf_queue() now requires m2m_ctx as its argument > - video_queue private data stores driver private data > - a new submenu in kconfig for mem-to-mem devices > - minor rebase leftovers cleanup > > A second patch series followed v2 with a new driver for a real device - > Samsung S3C/S5P image rotator, utilizing this framework. > > > This series contains: > > [PATCH v2.1 1/2] V4L: Add memory-to-memory device helper framework for V4L2. > [PATCH v2.1 2/2] V4L: Add a mem-to-mem V4L2 framework test device. > [EXAMPLE v2] Mem-to-mem userspace test application. > > > Previous discussion and RFC on this topic: > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/10668 > > > A mem-to-mem device is a device that uses memory buffers passed by > userspace applications for both source and destination. This is > different from existing drivers that use memory buffers for only one > of those at once. > In terms of V4L2 such a device would be both of OUTPUT and CAPTURE type. > Although no such devices are present in the V4L2 framework, a demand for such > a model exists, e.g. for 'resizer devices'. > > > --- > Mem-to-mem devices > --- > In the previous discussion we concluded that we should use one video node with > two queues, an output (V4L2_BUF_TYPE_VIDEO_OUTPUT) queue for source buffers > and > a capture queue (V4L2_BUF_TYPE_VIDEO_CAPTURE) for destination buffers. > > > Each instance has its own set of queues: 2 videobuf_queues, each with a ready > buffer queue, managed by the framework. Everything is encapsulated in the > queue context struct: > > struct v4l2_m2m_queue_ctx { > struct videobuf_queue q; > /* ... */ > /* Queue for buffers ready to be processed as soon as this > * instance receives access to the device */ > struct list_headrdy_queue; > /* ... */ > }; > > struct v4l2_m2m_ctx { > /* ... */ > /* Capture (output to memory) queue context */ > struct v4l2_m2m_queue_ctx cap_q_ctx; > > /* Output (input from memory) queue context */ > struct v4l2_m2m_queue_ctx out_q_ctx; > /* ... */ > }; > > Streamon can be called for all instances and will not sleep if another > instance > is streaming. > > vidioc_querycap() should report V4L2_CAP_VIDEO_CAPTURE | > V4L2_CAP_VIDEO_OUTPUT. > > -
Re: Which modules for the VP-2033? Where is the module "mantis.ko"?
In the same vein, I'm interested in this one, namely: I have tried the http://jusst.de/hg/v4l-dvb, since recently the liplianin mantis driver is not working (unknown symbols...). However, the problems I have as opposed to the previously working driver are: - the module does not install in a way it gets autoloaded on startup - I have to manually add it (modprobe) or put it into /etc/modules (debian) - while the card itself works, I don't have IR functionality anymore. >From what I gather from the kernel log, the input line input: Mantis VP-2040 IR Receiver as /devices/virtual/input/input4 just doesn't exist anymore. Further more the whole bunch is missing: mantis_ca_init (0): Registering EN50221 device mantis_ca_init (0): Registered EN50221 device mantis_hif_init (0): Adapter(0) Initializing Mantis Host Interface input: Mantis VP-2040 IR Receiver as /devices/virtual/input/input4 Creating IR device irrcv0 I tried 2.6.32 kernel which worked before, now I'm using 2.6.33-rc1 where I had to comment out #include the from the v4l-dvb/v4l/config-compat.h. Any ideas how to get the comfort back? ;) Regards, Aljaz -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - v2 4/6] V4L - vpfe_capture - bug fixes and enhancements
Hi Murali, Sorry for the long delay in reviewing this patch series. I've been very busy, first at work, and now for Christmas preparations (and occasionally I'd like to relax as well :-) ). I'm OK with the other patches in this series, but I do have a few comments on this one: I noticed that you added a wrapper function for video_ioctl2. I don't quite understand why. BTW, does this patch series rely on the patches in my v4l-dvb-davinci tree? Or are these independent patches? Is it because the experimental VPFE_CMD_S/G_CCDC_RAW_PARAMS ioctls are used with different argument pointers? I mean, currently the arg is a void * instead of a properly typed argument. However, if it always uses the same type, then you should use that type in _IOR/_IOW and use video_ioctl2 directly so that the core framework will do the user-to-kernelspace conversion (and vv) for you. Regards, Hans On Saturday 19 December 2009 00:58:25 m-kariche...@ti.com wrote: > From: Muralidharan Karicheri > > Updated based on comments against v1 of the patch > > Added a experimental IOCTL, to read the CCDC parameters. > Default handler was not getting the original pointer from the core. > So a wrapper function added to handle the default handler properly. > Also fixed a bug in the probe() in the linux-next tree > > Reviewed-by: Hans Verkuil > Signed-off-by: Muralidharan Karicheri > --- > Applies to linux-next of v4l-dvb > drivers/media/video/davinci/vpfe_capture.c | 120 > +--- > include/media/davinci/vpfe_capture.h | 12 ++- > 2 files changed, 81 insertions(+), 51 deletions(-) > > diff --git a/drivers/media/video/davinci/vpfe_capture.c > b/drivers/media/video/davinci/vpfe_capture.c > index 9e3a531..99ffc62 100644 > --- a/drivers/media/video/davinci/vpfe_capture.c > +++ b/drivers/media/video/davinci/vpfe_capture.c > @@ -758,12 +758,83 @@ static unsigned int vpfe_poll(struct file *file, > poll_table *wait) > return 0; > } > > +static long vpfe_param_handler(struct file *file, void *priv, > + int cmd, void *param) > +{ > + struct vpfe_device *vpfe_dev = video_drvdata(file); > + int ret = 0; > + > + v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_param_handler\n"); > + > + if (NULL == param) { > + v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, > + "Invalid user ptr\n"); > + return -EINVAL; > + } > + > + if (vpfe_dev->started) { > + /* only allowed if streaming is not started */ > + v4l2_err(&vpfe_dev->v4l2_dev, "device already started\n"); > + return -EBUSY; > + } > + > + switch (cmd) { > + case VPFE_CMD_S_CCDC_RAW_PARAMS: > + v4l2_warn(&vpfe_dev->v4l2_dev, > + "VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n"); > + ret = mutex_lock_interruptible(&vpfe_dev->lock); > + if (ret) > + return ret; > + ret = ccdc_dev->hw_ops.set_params(param); > + if (ret) { > + v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, > + "Error in setting parameters in CCDC\n"); > + goto unlock_out; > + } > + > + if (vpfe_get_ccdc_image_format(vpfe_dev, &vpfe_dev->fmt) < 0) { > + v4l2_err(&vpfe_dev->v4l2_dev, > + "Invalid image format at CCDC\n"); > + ret = -EINVAL; > + } > +unlock_out: > + mutex_unlock(&vpfe_dev->lock); > + break; > + case VPFE_CMD_G_CCDC_RAW_PARAMS: > + v4l2_warn(&vpfe_dev->v4l2_dev, > + "VPFE_CMD_G_CCDC_RAW_PARAMS: experimental ioctl\n"); > + if (!ccdc_dev->hw_ops.get_params) { > + ret = -EINVAL; > + break; > + } > + ret = ccdc_dev->hw_ops.get_params(param); > + if (ret) { > + v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, > + "Error in getting parameters from CCDC\n"); > + } > + break; > + default: > + ret = -EINVAL; > + break; > + } > + return ret; > +} > + > +static long vpfe_ioctl(struct file *file, unsigned int cmd, unsigned long > arg) > +{ > + if (cmd == VPFE_CMD_S_CCDC_RAW_PARAMS || > + cmd == VPFE_CMD_G_CCDC_RAW_PARAMS) > + return vpfe_param_handler(file, file->private_data, cmd, > + (void *)arg); > + return video_ioctl2(file, cmd, arg); > +} > + > /* vpfe capture driver file operations */ > static const struct v4l2_file_operations vpfe_fops = { > .owner = THIS_MODULE, > .open = vpfe_open, > .release = vpfe_release, > - .unlocked_ioctl = video_ioctl2, > + .unlocked_ioctl = vpfe_ioctl, > .mmap = vpfe_mmap, > .poll = vpfe_poll > }; > @@ -1681,50 +1752,6 @@ u
[EXAMPLE v2] Mem-to-mem userspace test application.
This is an example application for testing mem-to-mem framework using mem2mem-testdev device. It is intended to be executed multiple times in parallel to test multi-instance operation and scheduling. Each process can be configured differently using command-line arguments. The application opens video test device and framebuffer, sets up params, queues src/dst buffers and displays processed results on the framebuffer. Configurable parameters: starting point on the framebuffer, width/height of buffers, transaction length (in buffers), transaction duration, total number of frames to be processed. Tested on a 800x480 framebuffer with the following script: #!/bin/bash for i in {0..3} do ((x=$i * 100)) ./process-vmalloc 0 $(($i + 1)) $((2000 - $i * 500)) $((($i+1) * 4)) \ $x $x 100 100 & done Signed-off-by: Pawel Osciak Reviewed-by: Kyungmin Park --- --- /dev/null 2009-11-17 07:51:25.574927259 +0100 +++ process-vmalloc.c 2009-11-26 11:00:26.0 +0100 @@ -0,0 +1,420 @@ +/** + * process-vmalloc.c + * Capture+output (process) V4L2 device tester. + * + * Pawel Osciak, p.osc...@samsung.com + * 2009, Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include +#include + +#include + +#define V4L2_CID_TRANS_TIME_MSEC(V4L2_CID_PRIVATE_BASE) +#define V4L2_CID_TRANS_NUM_BUFS (V4L2_CID_PRIVATE_BASE + 1) + +#define VIDEO_DEV_NAME "/dev/video0" +#define FB_DEV_NAME"/dev/fb0" +#define NUM_BUFS 4 +#define NUM_FRAMES 16 + +#define perror_exit(cond, func)\ + if (cond) {\ + fprintf(stderr, "%s:%d: ", __func__, __LINE__);\ + perror(func);\ + exit(EXIT_FAILURE);\ + } + +#define error_exit(cond, func)\ + if (cond) {\ + fprintf(stderr, "%s:%d: failed\n", func, __LINE__);\ + exit(EXIT_FAILURE);\ + } + +#define perror_ret(cond, func)\ + if (cond) {\ + fprintf(stderr, "%s:%d: ", __func__, __LINE__);\ + perror(func);\ + return ret;\ + } + +#define memzero(x)\ + memset(&(x), 0, sizeof (x)); + +#define PROCESS_DEBUG 1 +#ifdef PROCESS_DEBUG +#define debug(msg, ...)\ + fprintf(stderr, "%s: " msg, __func__, ##__VA_ARGS__); +#else +#define debug(msg, ...) +#endif + +static int vid_fd, fb_fd; +static void *fb_addr; +static char *p_src_buf[NUM_BUFS], *p_dst_buf[NUM_BUFS]; +static size_t src_buf_size[NUM_BUFS], dst_buf_size[NUM_BUFS]; +static uint32_t num_src_bufs = 0, num_dst_bufs = 0; + +/* Command-line params */ +int initial_delay = 0; +int fb_x, fb_y, width, height; +int translen = 1; +/* For displaying multi-buffer transaction simulations, indicates current + * buffer in an ongoing transaction */ +int curr_buf = 0; +int transtime = 1000; +int num_frames = 0; +off_t fb_off, fb_line_w, fb_buf_w; +struct fb_var_screeninfo fbinfo; + +static void init_video_dev(void) +{ + int ret; + struct v4l2_capability cap; + struct v4l2_format fmt; + struct v4l2_control ctrl; + + vid_fd = open(VIDEO_DEV_NAME, O_RDWR | O_NONBLOCK, 0); + perror_exit(vid_fd < 0, "open"); + + ctrl.id = V4L2_CID_TRANS_TIME_MSEC; + ctrl.value = transtime; + ret = ioctl(vid_fd, VIDIOC_S_CTRL, &ctrl); + perror_exit(ret != 0, "ioctl"); + + ctrl.id = V4L2_CID_TRANS_NUM_BUFS; + ctrl.value = translen; + ret = ioctl(vid_fd, VIDIOC_S_CTRL, &ctrl); + perror_exit(ret != 0, "ioctl"); + + ret = ioctl(vid_fd, VIDIOC_QUERYCAP, &cap); + perror_exit(ret != 0, "ioctl"); + + if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE)) { + fprintf(stderr, "Device does not support capture\n"); + exit(EXIT_FAILURE); + } + if (!(cap.capabilities & V4L2_CAP_VIDEO_OUTPUT)) { + fprintf(stderr, "Device does not support output\n"); + exit(EXIT_FAILURE); + } + + /* Set format for capture */ + fmt.type= V4L2_BUF_TYPE_VIDEO_CAPTURE; + fmt.fmt.pix.width = width; + fmt.fmt.pix.height = height; + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB565X; + fmt.fmt.pix.field = V4L2_FIELD_ANY; + + ret = ioctl(vid_fd, VIDIOC_S_FMT, &fmt); + perror_exit(ret != 0, "ioctl"); + + /* The same format for output */ + fmt.type = V4L2_BUF_TYPE_VIDEO_OUTPUT; + fmt.fmt.pix.width = width; + fmt.fmt.pix.height = height; + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB565X; + fmt.fmt.pix.field = V4L2_FIELD_ANY; + + ret = ioctl(vid_fd, VIDIOC_S_FMT, &f
[PATCH v2.1 1/2] V4L: Add memory-to-memory device helper framework for V4L2.
A mem-to-mem device is a device that uses memory buffers passed by userspace applications for both source and destination data. This is different from existing drivers, which use memory buffers for only one of those at once. In terms of V4L2 such a device would be both of OUTPUT and CAPTURE type. Although no such devices are present in the V4L2 framework, a demand for such a model exists, e.g. for 'resizer devices'. This patch also adds a separate kconfig submenu for mem-to-mem V4L devices. Signed-off-by: Pawel Osciak Signed-off-by: Marek Szyprowski Reviewed-by: Kyungmin Park --- drivers/media/video/Kconfig| 14 + drivers/media/video/Makefile |2 + drivers/media/video/v4l2-mem2mem.c | 671 include/media/v4l2-mem2mem.h | 153 4 files changed, 840 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/v4l2-mem2mem.c create mode 100644 include/media/v4l2-mem2mem.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 2f83be7..4e97dcf 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -45,6 +45,10 @@ config VIDEO_TUNER tristate depends on MEDIA_TUNER +config V4L2_MEM2MEM_DEV + tristate + depends on VIDEOBUF_GEN + # # Multimedia Video device configuration # @@ -1075,3 +1079,13 @@ config USB_S2255 endif # V4L_USB_DRIVERS endif # VIDEO_CAPTURE_DRIVERS + +menuconfig V4L_MEM2MEM_DRIVERS + bool "Memory-to-memory multimedia devices" + depends on VIDEO_V4L2 + default n + ---help--- + Say Y here to enable selecting drivers for V4L devices that + use system memory for both source and destination buffers, as opposed + to capture and output drivers, which use memory buffers for just + one of those. diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 2af68ee..9fe7d40 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -115,6 +115,8 @@ obj-$(CONFIG_VIDEOBUF_VMALLOC) += videobuf-vmalloc.o obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o +obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o + obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o diff --git a/drivers/media/video/v4l2-mem2mem.c b/drivers/media/video/v4l2-mem2mem.c new file mode 100644 index 000..417ee2c --- /dev/null +++ b/drivers/media/video/v4l2-mem2mem.c @@ -0,0 +1,671 @@ +/* + * Memory-to-memory device framework for Video for Linux 2. + * + * Helper functions for devices that use memory buffers for both source + * and destination. + * + * Copyright (c) 2009 Samsung Electronics Co., Ltd. + * Pawel Osciak, + * Marek Szyprowski, + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the + * License, or (at your option) any later version + */ + +#include +#include +#include +#include + +MODULE_DESCRIPTION("Mem to mem device framework for V4L2"); +MODULE_AUTHOR("Pawel Osciak, "); +MODULE_LICENSE("GPL"); + +static int debug; +module_param(debug, int, 0644); + +#define dprintk(fmt, arg...) do {\ + if (debug >= 1)\ + printk(KERN_DEBUG "%s: " fmt, __func__, ## arg); } while (0) + + +/* The instance is already queued on the jobqueue */ +#define TRANS_QUEUED (1 << 0) +/* The instance is currently running in hardware */ +#define TRANS_RUNNING (1 << 1) + + +/* Offset base for buffers on the destination queue - used to distinguish + * between source and destination buffers when mmapping - they receive the same + * offsets but for different queues */ +#define DST_QUEUE_OFF_BASE (TASK_SIZE / 2) + + +struct v4l2_m2m_dev { + /* Currently running instance */ + struct v4l2_m2m_ctx *curr_ctx; + /* Instances queued to run */ + struct list_headjobqueue; + spinlock_t job_spinlock; + + struct v4l2_m2m_ops *m2m_ops; +}; + +static inline +struct v4l2_m2m_queue_ctx *get_queue_ctx(struct v4l2_m2m_ctx *m2m_ctx, +enum v4l2_buf_type type) +{ + switch (type) { + case V4L2_BUF_TYPE_VIDEO_CAPTURE: + return &m2m_ctx->cap_q_ctx; + case V4L2_BUF_TYPE_VIDEO_OUTPUT: + return &m2m_ctx->out_q_ctx; + default: + printk(KERN_ERR "Invalid buffer type\n"); + return NULL; + } +} + +/** + * v4l2_m2m_get_vq() - return videobuf_queue for the given type + */ +struct videobuf_queue *v4l2_m2m_get_vq(struct v4l2_m2m_ctx *m2m_ctx, + enum v4l2_buf_type type) +{ + struct v4l2_m2m_queue_ctx *q_ctx; + + q_ctx = get_queue_ctx(m2m_ctx, type); + if (!q_ctx) + return NULL; + + return &q_ctx->q; +} +
[PATCH v2.1 2/2] V4L: Add a mem-to-mem V4L2 framework test device.
This is a virtual device driver for testing the mem-to-mem V4L2 framework. It simulates a device that uses memory buffers for both source and destination, processes the data and issues an "IRQ" (simulated by a timer). The device is capable of multi-instance, multi-buffer-per-transaction operation (via the mem2mem framework). Signed-off-by: Pawel Osciak Signed-off-by: Marek Szyprowski Reviewed-by: Kyungmin Park --- drivers/media/video/Kconfig | 14 + drivers/media/video/Makefile |1 + drivers/media/video/mem2mem_testdev.c | 1052 + 3 files changed, 1067 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mem2mem_testdev.c diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 4e97dcf..4e7d703 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1089,3 +1089,17 @@ menuconfig V4L_MEM2MEM_DRIVERS use system memory for both source and destination buffers, as opposed to capture and output drivers, which use memory buffers for just one of those. + +if V4L_MEM2MEM_DRIVERS + +config VIDEO_MEM2MEM_TESTDEV + tristate "Virtual test device for mem2mem framework" + depends on VIDEO_DEV && VIDEO_V4L2 + select VIDEOBUF_VMALLOC + select V4L2_MEM2MEM_DEV + default n + ---help--- + This is a virtual test device for the memory-to-memory driver + framework. + +endif # V4L_MEM2MEM_DRIVERS diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 9fe7d40..8667f1c 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -149,6 +149,7 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/ obj-$(CONFIG_VIDEO_CX18) += cx18/ obj-$(CONFIG_VIDEO_VIVI) += vivi.o +obj-$(CONFIG_VIDEO_MEM2MEM_TESTDEV) += mem2mem_testdev.o obj-$(CONFIG_VIDEO_CX23885) += cx23885/ obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o diff --git a/drivers/media/video/mem2mem_testdev.c b/drivers/media/video/mem2mem_testdev.c new file mode 100644 index 000..ea54a68 --- /dev/null +++ b/drivers/media/video/mem2mem_testdev.c @@ -0,0 +1,1052 @@ +/* + * A virtual v4l2-mem2mem example device. + * + * This is a virtual device driver for testing the mem-to-mem V4L2 framework. + * It simulates a device that uses memory buffers for both source and + * destination, processes the data and issues an "IRQ" (simulated by a timer). + * The device is capable of multi-instance, multi-buffer-per-transaction + * operation (via the mem2mem framework). + * + * Copyright (c) 2009 Samsung Electronics Co., Ltd. + * Pawel Osciak, + * Marek Szyprowski, + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the + * License, or (at your option) any later version + */ +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#define MEM2MEM_TEST_MODULE_NAME "mem2mem-testdev" + +MODULE_DESCRIPTION("Virtual device for mem2mem framework testing"); +MODULE_AUTHOR("Pawel Osciak, "); +MODULE_LICENSE("GPL"); + + +#define MIN_W 32 +#define MIN_H 32 +#define MAX_W 640 +#define MAX_H 480 +#define DIM_ALIGN_MASK 0x08 /* 8-alignment for dimensions */ + +/* Flags that indicate a format can be used for capture/output */ +#define MEM2MEM_CAPTURE(1 << 0) +#define MEM2MEM_OUTPUT (1 << 1) + +#define MEM2MEM_MAX_INSTANCES 10 +#define MEM2MEM_NAME "m2m-testdev" + +/* Per queue */ +#define MEM2MEM_DEF_NUM_BUFS 32 +/* In bytes, per queue */ +#define MEM2MEM_VID_MEM_LIMIT (16 * 1024 * 1024) + +/* Default transaction time in msec */ +#define MEM2MEM_DEF_TRANSTIME 1000 +/* Default number of buffers per transaction */ +#define MEM2MEM_DEF_TRANSLEN 1 +#define MEM2MEM_COLOR_STEP (0xff >> 4) +#define MEM2MEM_NUM_TILES 10 + +#define dprintk(dev, fmt, arg...) \ + v4l2_dbg(1, 1, &dev->v4l2_dev, "%s: " fmt, __func__, ## arg) + + +void m2mtest_dev_release(struct device *dev) +{} + +static struct platform_device m2mtest_pdev = { + .name = MEM2MEM_NAME, + .dev.release= m2mtest_dev_release, +}; + +struct m2mtest_fmt { + char*name; + u32 fourcc; /* v4l2 format id */ + int depth; + /* Types the format can be used for */ + u32 types; +}; + +static struct m2mtest_fmt formats[] = { + { + .name = "RGB565 (BE)", + .fourcc = V4L2_PIX_FMT_RGB565X, /* rggg gggb */ + .depth = 16, + /* Both capture and output format */ + .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT, + }, + { + .name = "4:2:2, packed, YUYV", + .fourcc = V4L2_PIX_FMT_YUYV, + .depth = 16, + /* Output-only format */ + .types = MEM2
[PATCH/RFC v2.1 0/2] Mem-to-mem device framework
Hello, this is the second version of the proposed implementation for mem-to-mem memory device framework. Your comments are very welcome. In v2.1: I am very sorry for the resend, but somehow an orphaned endif found its way to Kconfig during the rebase. Changes since v1: - v4l2_m2m_buf_queue() now requires m2m_ctx as its argument - video_queue private data stores driver private data - a new submenu in kconfig for mem-to-mem devices - minor rebase leftovers cleanup A second patch series followed v2 with a new driver for a real device - Samsung S3C/S5P image rotator, utilizing this framework. This series contains: [PATCH v2.1 1/2] V4L: Add memory-to-memory device helper framework for V4L2. [PATCH v2.1 2/2] V4L: Add a mem-to-mem V4L2 framework test device. [EXAMPLE v2] Mem-to-mem userspace test application. Previous discussion and RFC on this topic: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/10668 A mem-to-mem device is a device that uses memory buffers passed by userspace applications for both source and destination. This is different from existing drivers that use memory buffers for only one of those at once. In terms of V4L2 such a device would be both of OUTPUT and CAPTURE type. Although no such devices are present in the V4L2 framework, a demand for such a model exists, e.g. for 'resizer devices'. --- Mem-to-mem devices --- In the previous discussion we concluded that we should use one video node with two queues, an output (V4L2_BUF_TYPE_VIDEO_OUTPUT) queue for source buffers and a capture queue (V4L2_BUF_TYPE_VIDEO_CAPTURE) for destination buffers. Each instance has its own set of queues: 2 videobuf_queues, each with a ready buffer queue, managed by the framework. Everything is encapsulated in the queue context struct: struct v4l2_m2m_queue_ctx { struct videobuf_queue q; /* ... */ /* Queue for buffers ready to be processed as soon as this * instance receives access to the device */ struct list_headrdy_queue; /* ... */ }; struct v4l2_m2m_ctx { /* ... */ /* Capture (output to memory) queue context */ struct v4l2_m2m_queue_ctx cap_q_ctx; /* Output (input from memory) queue context */ struct v4l2_m2m_queue_ctx out_q_ctx; /* ... */ }; Streamon can be called for all instances and will not sleep if another instance is streaming. vidioc_querycap() should report V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT. --- Queuing and dequeuing buffers --- Applications can queue as many buffers as they want and it is not required to queue an equal number of source and destination buffers. If there is not enough buffers of any type, a new transaction will simply not be scheduled. --- Source and destination formats --- Should be set per queue. A helper function to access queues depending on the passed type - v4l2_m2m_get_vq() - is supplied. Most of the format-handling code is normally located in drivers anyway. The only exception is the "field" member of the videobuf_queue struct, which has to be set directly. It breaks encapsulation a little bit, but nothing can be done with it. --- Scheduling --- Requirements/assumptions: 1. More than one instance can be open at the same time. 2. Each instance periodically receives exclusive access to the device, performs an operation (operations) and yields back the device in a state that allows other instances to use it. 3. When an instance gets access to the device, it performs a "transaction"/"job". A transaction/job is defined as the shortest operation that cannot/should not be further divided without having to restart it from scratch, or without having to perform expensive reconfiguration of a device, etc. 4. Transactions can use multiple source/destination buffers. 5. Only a driver can tell when it is ready to perform a transaction, so a optional callback is provided for that purpose (job_ready()). There are three common requirements for a transaction to be ready to run: - at least one source buffer ready - at least one destination buffer ready - streaming on - (optional) driver-specific requirements (driver-specific callback function) So when buffers are queued by qbuf() or streaming is turned on with streamon(), the framework calls v4l2_m2m_try_schedule(). v4l2_m2m_try_schedule() 1. Checks for the above conditions. 2. Checks f
[PATCH 3/3] [V4L/DVB] gspca: Storage class should be before const qualifier
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: Tobias Klauser Cc: Erik Andren Cc: Jean-Francois Moine --- drivers/media/video/gspca/m5602/m5602_mt9m111.c |2 +- drivers/media/video/gspca/m5602/m5602_ov7660.c |2 +- drivers/media/video/gspca/m5602/m5602_ov7660.h |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/gspca/m5602/m5602_mt9m111.c b/drivers/media/video/gspca/m5602/m5602_mt9m111.c index 8d071df..3285957 100644 --- a/drivers/media/video/gspca/m5602/m5602_mt9m111.c +++ b/drivers/media/video/gspca/m5602/m5602_mt9m111.c @@ -48,7 +48,7 @@ static struct v4l2_pix_format mt9m111_modes[] = { } }; -const static struct ctrl mt9m111_ctrls[] = { +static const struct ctrl mt9m111_ctrls[] = { #define VFLIP_IDX 0 { { diff --git a/drivers/media/video/gspca/m5602/m5602_ov7660.c b/drivers/media/video/gspca/m5602/m5602_ov7660.c index 2a28b74..62c1cbf 100644 --- a/drivers/media/video/gspca/m5602/m5602_ov7660.c +++ b/drivers/media/video/gspca/m5602/m5602_ov7660.c @@ -33,7 +33,7 @@ static int ov7660_set_hflip(struct gspca_dev *gspca_dev, __s32 val); static int ov7660_get_vflip(struct gspca_dev *gspca_dev, __s32 *val); static int ov7660_set_vflip(struct gspca_dev *gspca_dev, __s32 val); -const static struct ctrl ov7660_ctrls[] = { +static const struct ctrl ov7660_ctrls[] = { #define GAIN_IDX 1 { { diff --git a/drivers/media/video/gspca/m5602/m5602_ov7660.h b/drivers/media/video/gspca/m5602/m5602_ov7660.h index f5588eb..4d9dcf2 100644 --- a/drivers/media/video/gspca/m5602/m5602_ov7660.h +++ b/drivers/media/video/gspca/m5602/m5602_ov7660.h @@ -94,7 +94,7 @@ int ov7660_start(struct sd *sd); int ov7660_stop(struct sd *sd); void ov7660_disconnect(struct sd *sd); -const static struct m5602_sensor ov7660 = { +static const struct m5602_sensor ov7660 = { .name = "ov7660", .i2c_slave_id = 0x42, .i2c_regW = 1, -- 1.6.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [V4L/DVB] rj54n1cb0: Storage class should be before const qualifier
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: Tobias Klauser --- drivers/media/video/rj54n1cb0c.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/video/rj54n1cb0c.c b/drivers/media/video/rj54n1cb0c.c index 7e42989..900c60a 100644 --- a/drivers/media/video/rj54n1cb0c.c +++ b/drivers/media/video/rj54n1cb0c.c @@ -165,7 +165,7 @@ struct rj54n1_reg_val { u8 val; }; -const static struct rj54n1_reg_val bank_4[] = { +static const struct rj54n1_reg_val bank_4[] = { {0x417, 0}, {0x42c, 0}, {0x42d, 0xf0}, @@ -186,7 +186,7 @@ const static struct rj54n1_reg_val bank_4[] = { {0x4fe, 2}, }; -const static struct rj54n1_reg_val bank_5[] = { +static const struct rj54n1_reg_val bank_5[] = { {0x514, 0}, {0x516, 0}, {0x518, 0}, @@ -207,7 +207,7 @@ const static struct rj54n1_reg_val bank_5[] = { {0x5fe, 2}, }; -const static struct rj54n1_reg_val bank_7[] = { +static const struct rj54n1_reg_val bank_7[] = { {0x70a, 0}, {0x714, 0xff}, {0x715, 0xff}, @@ -215,7 +215,7 @@ const static struct rj54n1_reg_val bank_7[] = { {0x7FE, 2}, }; -const static struct rj54n1_reg_val bank_8[] = { +static const struct rj54n1_reg_val bank_8[] = { {0x800, 0x00}, {0x801, 0x01}, {0x802, 0x61}, @@ -403,12 +403,12 @@ const static struct rj54n1_reg_val bank_8[] = { {0x8FE, 2}, }; -const static struct rj54n1_reg_val bank_10[] = { +static const struct rj54n1_reg_val bank_10[] = { {0x10bf, 0x69} }; /* Clock dividers - these are default register values, divider = register + 1 */ -const static struct rj54n1_clock_div clk_div = { +static const struct rj54n1_clock_div clk_div = { .ratio_tg = 3 /* default: 5 */, .ratio_t= 4 /* default: 1 */, .ratio_r= 4 /* default: 0 */, -- 1.6.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [V4L/DVB] dvb-usb-friio: Storage class should be before const qualifier
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: Tobias Klauser --- drivers/media/dvb/dvb-usb/friio-fe.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/friio-fe.c b/drivers/media/dvb/dvb-usb/friio-fe.c index ebb7b9f..d14bd22 100644 --- a/drivers/media/dvb/dvb-usb/friio-fe.c +++ b/drivers/media/dvb/dvb-usb/friio-fe.c @@ -366,7 +366,7 @@ static u8 init_code[][2] = { {0x76, 0x0C}, }; -const static int init_code_len = sizeof(init_code) / sizeof(u8[2]); +static const int init_code_len = sizeof(init_code) / sizeof(u8[2]); static int jdvbt90502_init(struct dvb_frontend *fe) { -- 1.6.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134 (not very) new board 5168:0307
Some news, Hi hermann, we are this results : with &tda827x_cfg_0, &tda827x_cfg_1 or &tda827x_cfg_2 we have a perfect image without sound on the analogic part (test with mplayer), a partial result with dvb-t : we need to initialize first with analogic (with cold boot, the card doesn't work on dvb) but only for few seconds(sound and image are ok) then re-initialize with analogic, work for few seconds on dvb and then nothing maybe i am wrong but, the sound part for analogic is a problem of redirection, isn't it ? fixed here are our configuration for this card : in saa7134-dvb.c static struct tda1004x_config tda827x_flydvbtduo_medion_config = { .demod_address = 0x08, .invert= 1, .invert_oclk = 0, .xtal_freq = TDA10046_XTAL_16M, .agc_config= TDA10046_AGC_TDA827X, .gpio_config = TDA10046_GP01_I, .if_freq = TDA10046_FREQ_045, .i2c_gate = 0x4b, .tuner_address = 0x61, .antenna_switch = 2, .request_firmware = philips_tda1004x_request_firmware }; case SAA7134_BOARD_FLYDVBTDUO_MEDION: if (configure_tda827x_fe(dev, &tda827x_flydvbtduo_medion_config, &tda827x_cfg_2) < 0) goto dettach_frontend; break; default: wprintk("Huh? unknown DVB card?\n"); break; in saa7134-cards.c [SAA7134_BOARD_FLYDVBTDUO_MEDION] = { .name = "LifeView FlyDVB-T DUO Medion", .audio_clock= 0x00187de7, change with 0x0020 and there is a perfect sound :) .tuner_type = TUNER_PHILIPS_TDA8290, .radio_type = UNSET, .tuner_addr= ADDR_UNSET, .radio_addr= ADDR_UNSET, .gpiomask= 0x0020, .mpeg = SAA7134_MPEG_DVB, .inputs = {{ .name = name_tv, .vmux = 1, .amux = TV, .gpio = 0x20, /* GPIO21=High for TV input */ .tv = 1, },{ .name = name_comp1,/* Composite signal on S-Video input */ .vmux = 3, .amux = LINE1, },{ .name = name_svideo,/* S-Video signal on S-Video input */ .vmux = 8, .amux = LINE1, }}, .radio = { .name = name_radio, .amux = TV, .gpio = 0x00,/* GPIO21=Low for FM radio antenna */ }, .vendor = PCI_VENDOR_ID_PHILIPS, .device = PCI_DEVICE_ID_PHILIPS_SAA7133, .subvendor= 0x5168, .subdevice= 0x0307, /* LR307-N */ .driver_data = SAA7134_BOARD_FLYDVBTDUO_MEDION, case SAA7134_BOARD_FLYDVBTDUO_MEDION: { /* this is a hybrid board, initialize to analog mode * and configure firmware eeprom address */ u8 data[] = { 0x3c, 0x33, 0x60}; struct i2c_msg msg = {.addr=0x08, .flags=0, .buf=data, .len = sizeof(data)}; i2c_transfer(&dev->i2c_adap, &msg, 1); break; What can we do to have dvb fully supported ? Can someone point me in the right direction ? thanks in advance, Cheers, Thomas -- 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
Error during compile on Fedora 11, revision after 13823
Hi, I'm trying to compile v4l on Fedora 11, latest available RPM kernel, but there are many problem. I've tried to go in the past with revision (hg update ), and the last revision I can compile without problem is 13823. Is this a know bug/error due to have not last kernel? Thanks for the help you can provide, Sebastian P.S.: here are more information about compiling process and error received: Kernel version: Linux localhost 2.6.30.9-102.fc11.i686.PAE #1 SMP Fri Dec 4 00:19:26 EST 2009 i686 i686 i386 GNU/Linux Revison 13840 CC [M] /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.o /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:20:23: error: sound/aci.h: No such file or directory /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c: In function 'pcm20_mute': /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:46: error: implicit declaration of function 'snd_aci_cmd' /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:46: error: 'ACI_SET_TUNERMUTE' undeclared (first use in this function) /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:46: error: (Each undeclared identifier is reported only once /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:46: error: for each function it appears in.) /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c: In function 'pcm20_stereo': /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:51: error: 'ACI_SET_TUNERMONO' undeclared (first use in this function) /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c: In function 'pcm20_setfreq': /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:63: error: dereferencing pointer to incomplete type /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:63: error: dereferencing pointer to incomplete type /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:70: error: 'ACI_WRITE_TUNE' undeclared (first use in this function) /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c: In function 'pcm20_init': /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:225: error: implicit declaration of function 'snd_aci_get_aci' /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:225: warning: assignment makes pointer from integer without a cast make[3]: *** [/home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.o] Error 1 make[2]: *** [_module_/home/sebhack/src/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.30.9-102.fc11.i686.PAE' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/sebhack/src/v4l-dvb/v4l' make: *** [all] Error 2 Revison 13830 CC [M] /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.o /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:20:23: error: sound/aci.h: No such file or directory /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c: In function 'pcm20_mute': /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:46: error: implicit declaration of function 'snd_aci_cmd' /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:46: error: 'ACI_SET_TUNERMUTE' undeclared (first use in this function) /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:46: error: (Each undeclared identifier is reported only once /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:46: error: for each function it appears in.) /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c: In function 'pcm20_stereo': /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:51: error: 'ACI_SET_TUNERMONO' undeclared (first use in this function) /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c: In function 'pcm20_setfreq': /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:63: error: dereferencing pointer to incomplete type /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:63: error: dereferencing pointer to incomplete type /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:70: error: 'ACI_WRITE_TUNE' undeclared (first use in this function) /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c: In function 'pcm20_init': /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:225: error: implicit declaration of function 'snd_aci_get_aci' /home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.c:225: warning: assignment makes pointer from integer without a cast make[3]: *** [/home/sebhack/src/v4l-dvb/v4l/radio-miropcm20.o] Error 1 make[2]: *** [_module_/home/sebhack/src/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.30.9-102.fc11.i686.PAE' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/sebhack/src/v4l-dvb/v4l' make: *** [all] Error 2 Revison 13825 CC [M] /home/sebhack/src/v4l-dvb/v4l/au0828-cards.o In file included from /home/sebhack/src/v4l-dvb/v4l/dmxdev.h:33, from /home/sebhack/src/v4l-dvb/v4l/au0828.h:29, from /home/sebhack/src/v4l-dvb/v4l/au0828-cards.c:22: /home/sebhack/src/v4l-dvb/v4l/compat.h:396: error: redefinition of 'usb_endpoint_type' include/linux/usb/ch9.h:376: note: previous definition of 'usb_endpoint_type' was here make[3]: *** [/home/sebhack/src/v4l-dvb/v4l/au0828-cards.o] Error 1 make[2]: *** [_module_/home/sebhack/src/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.30.9-102.fc1
Re: [RFC v2 4/7] V4L: Events: Add backend
Hi Andy, Andy Walls wrote: +int v4l2_event_pending(struct v4l2_fh *fh) +{ + struct v4l2_events *events =&fh->events; + unsigned long flags; + int ret; + + spin_lock_irqsave(&events->lock, flags); + ret = !list_empty(&events->available); + spin_unlock_irqrestore(&events->lock, flags); + + return ret; +} +EXPORT_SYMBOL_GPL(v4l2_event_pending); Hi Sakari, Disabling and restoring local interrupts to check if any events are pending seems excessive. Since you added an atomic_t with the number of events available in patch 5/7, why don't you just check that atomic_t here? Thanks for the comments! I'll put the fix to patch 5. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [ARM] samsung-rotator: Add Samsung S3C/S5P rotator driver
The rotator device present on Samsung S3C and S5P series SoCs allows image rotation and flipping. It requires contiguous memory buffers to operate, as it does not have scatter-gather support. It is also an example of a memory-to-memory device, and so uses the mem-2-mem device V4L2 framework. Signed-off-by: Pawel Osciak Signed-off-by: Sylwester Nawrocki Reviewed-by: Marek Szyprowski Reviewed-by: Kyungmin Park --- drivers/media/video/Kconfig | 10 + drivers/media/video/Makefile |2 + drivers/media/video/samsung-rotator/Makefile |1 + drivers/media/video/samsung-rotator/s3c_rotator.c | 1026 + 4 files changed, 1039 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/samsung-rotator/Makefile create mode 100644 drivers/media/video/samsung-rotator/s3c_rotator.c diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 6fe4b53..b6040bd 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1100,4 +1100,14 @@ config VIDEO_MEM2MEM_TESTDEV This is a virtual test device for the memory-to-memory driver framework. +config VIDEO_SAMSUNG_ROTATOR + tristate "Samsung S3C/S5P embedded image rotator" + depends on VIDEO_V4L2 + select VIDEOBUF_DMA_CONTIG + select V4L2_MEM2MEM_DEV + default n + help + An image rotator device present on Samsung S3C and S5P series SoCs + allows image rotation and flipping. + endif # V4L_MEM2MEM_DRIVERS diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 8667f1c..72196df 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -172,6 +172,8 @@ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o obj-$(CONFIG_ARCH_DAVINCI) += davinci/ +obj-$(CONFIG_VIDEO_SAMSUNG_ROTATOR)+= samsung-rotator/ + EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core EXTRA_CFLAGS += -Idrivers/media/dvb/frontends EXTRA_CFLAGS += -Idrivers/media/common/tuners diff --git a/drivers/media/video/samsung-rotator/Makefile b/drivers/media/video/samsung-rotator/Makefile new file mode 100644 index 000..9ce9ee9 --- /dev/null +++ b/drivers/media/video/samsung-rotator/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_SAMSUNG_ROTATOR) += s3c_rotator.o diff --git a/drivers/media/video/samsung-rotator/s3c_rotator.c b/drivers/media/video/samsung-rotator/s3c_rotator.c new file mode 100644 index 000..83f9059 --- /dev/null +++ b/drivers/media/video/samsung-rotator/s3c_rotator.c @@ -0,0 +1,1026 @@ +/* + * Samsung S3C/S5P image rotator driver. + * + * Copyright (c) 2009 Samsung Electronics Co., Ltd. + * Pawel Osciak, + * Sylwester Nawrocki, + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the + * License, or (at your option) any later version + */ +#include +#include +#include +#include +#include + +#include +#include + +#include +#include + +#include + +#define S3C_ROTATOR_NAME "s3c-rotator" +#define S3C_ROTATOR_MEM_LIMIT (16 * 1024 * 1024) +#define S3C_ROTATOR_MAX_WIDTH 2048 +#define S3C_ROTATOR_MAX_HEIGHT 2048 + +/*#define S3C_ROTATOR_DEBUG_REGWRITE*/ +#ifdef S3C_ROTATOR_DEBUG_REGWRITE +#undef writel +#define writel(v, r) do { \ + printk(KERN_DEBUG "%s: %08x => %p\n", __func__, (unsigned int)v, r); \ + __raw_writel(v, r); } while(0) +#endif /* S3C_ROTATOR_DEBUG_REGWRITE */ + +#define V4L2_CID_PRIVATE_ROTATE (V4L2_CID_PRIVATE_BASE + 0) + +struct s3c_rotator_fmt { + char*name; + u32 fourcc; + u32 depth; +}; + +/* Input/output formats (no conversion) */ +static struct s3c_rotator_fmt formats[] = { + { + .name = "4:2:2, packed, YUYV", + .fourcc = V4L2_PIX_FMT_YUYV, + .depth = 16, + }, + { + .name = "4:2:0, planar YUV", + .fourcc = V4L2_PIX_FMT_YUV420, + .depth = 12, + }, + { + .name = "BGR565X", + .fourcc = V4L2_PIX_FMT_RGB565X, + .depth = 16, + }, + { + .name = "BGRA", + .fourcc = V4L2_PIX_FMT_BGR32, + .depth = 32, + }, +}; + +#define NUM_FORMATS ARRAY_SIZE(formats) + +/* + * The device can only do one operation at a time, + * i.e. simultaneous rotation + flip is not possible + */ +static struct v4l2_queryctrl s3c_rotator_ctrls[] = { + { + .id = V4L2_CID_HFLIP, + .type = V4L2_CTRL_TYPE_BOOLEAN, + .name = "Horizontal flip", + .minimum= 0, + .maximum= 1, + .default_value = 0, + }, + { + .id = V4L2_CID_VFLIP, + .type = V4L2_CTRL_TYPE_BOOLEAN
[EXAMPLE] S3C/S5P image rotator test application
This is an example application for testing the S3C/S5P rotator device. It uses framebuffer memory for its source and destination buffers, as the device requires them to be in contiguous memory. Source image is read from a file passed as an argument and saved to another file, which name is also passed as an argument. Configurable parameters: video_node in_file, out_file, format, width, height, rotation, flip Where: video_node: video node number in_file/out_file: source/destination raw image data format: 0: 420, 1: 422, 2: 565, 3: 888 width/height: dimensions of both images rotation: 90, 180, 270 flip (when rotation==0): 1: horizontal, 2: vertical --- --- /dev/null 2009-11-17 07:51:25.574927259 +0100 +++ rotator-dma-contig.c2009-12-22 17:22:25.0 +0100 @@ -0,0 +1,375 @@ +/* + * Samsung S3C/S5P image rotator test application. + * + * Copyright (c) 2009 Samsung Electronics Co., Ltd. + * Pawel Osciak, + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the + * License, or (at your option) any later version + */ +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#define VIDEO_DEV_NAME "/dev/video" +#define FB_DEV_NAME"/dev/fb0" + +#define NUM_SRC_BUFS 1 +#define NUM_DST_BUFS 1 + +#define V4L2_CID_PRIVATE_ROTATE (V4L2_CID_PRIVATE_BASE + 0) + +#define perror_exit(cond, func)\ + if (cond) {\ + fprintf(stderr, "%s:%d: ", __func__, __LINE__);\ + perror(func);\ + exit(EXIT_FAILURE);\ + } + +#define error_exit(cond, msg)\ + if (cond) {\ + fprintf(stderr, "%s:%d: " msg "\n", __func__, __LINE__);\ + exit(EXIT_FAILURE);\ + } + +#define perror_ret(cond, func)\ + if (cond) {\ + fprintf(stderr, "%s:%d: ", __func__, __LINE__);\ + perror(func);\ + return ret;\ + } + +#define memzero(x)\ + memset(&(x), 0, sizeof (x)); + +#ifdef _DEBUG +#define debug(msg, ...)\ + fprintf(stderr, "%s: " msg, __func__, ##__VA_ARGS__); +#else +#define debug(msg, ...) +#endif + +struct buffer { + char *addr; + unsigned long size; + unsigned int index; +}; + +static int vid_fd, fb_fd, src_fd, dst_fd; +static void *fb_addr, *src_addr, *dst_addr; +static char *in_file, *out_file; +static int width, height; +static off_t fb_line_w, fb_buf_w, fb_size; +static struct fb_var_screeninfo fbinfo; +static int in_size; +static int vid_node = 0; +static int format, framesize, rotation, flip; + +static void set_rotation(int angle) +{ + struct v4l2_control ctrl; + int ret; + + memzero(ctrl); + ctrl.id = V4L2_CID_PRIVATE_ROTATE; + ctrl.value = angle; + ret = ioctl(vid_fd, VIDIOC_S_CTRL, &ctrl); + perror_exit(ret != 0, "ioctl"); +} + +static void set_flip(int flip) +{ + struct v4l2_control ctrl; + int ret; + + memzero(ctrl); + switch (flip) { + case 1: + ctrl.id = V4L2_CID_HFLIP; + break; + case 2: + ctrl.id = V4L2_CID_VFLIP; + break; + default: + error_exit(1, "Invalid params\n"); + } + + ctrl.value = 1; + + ret = ioctl(vid_fd, VIDIOC_S_CTRL, &ctrl); + perror_exit(ret != 0, "ioctl"); +} + +static void set_fmt(uint32_t format) +{ + struct v4l2_format fmt; + int ret; + long page_size; + + memzero(fmt); + switch (format) { + case 0: + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; + framesize = width * height * 2; + fb_buf_w = width * 2; + break; + case 1: + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUV420; + framesize = (width * height * 3) / 2; + fb_buf_w = width * 3 / 2; + break; + case 2: + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB565X; + framesize = width * height * 2; + fb_buf_w = width * 2; + break; + case 3: + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_BGR32; + framesize = width * height * 4; + fb_buf_w = width * 4; + break; + default: + error_exit(1, "Invalid params\n"); + break; + } + + page_size = sysconf(_SC_PAGESIZE); + framesize = (framesize + page_size - 1) & ~(page_size - 1); + debug("Framesize: %d\n", framesize); + + /* Set format for capture */ + fmt.type= V4L2_BUF_TYPE_VIDEO_CAPTURE; + fmt.fmt.pix.width = width; + fmt.fmt.pix.height = height; + fmt.fmt.pix.field = V4L2_FIELD_ANY; + +
[PATCH 0/2] [ARM] Add Samsung S3C/S5P image rotator driver
Hello, this is a driver for Samsung S3C/S5P series image rotator device driver. This driver utilizes the proposed memory-to-memory V4L2 framework, just posted by me in the previous patch series. An example application for testing the device is also included. This series contains: [PATCH 1/2] [ARM] samsung-rotator: Add rotator device platform definitions. [PATCH 2/2] [ARM] samsung-rotator: Add Samsung S3C/S5P rotator driver [EXAMPLE] S3C/S5P image rotator test application Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [ARM] samsung-rotator: Add rotator device platform definitions.
Add S3C/S5P rotator platform device. Signed-off-by: Pawel Osciak Signed-off-by: Sylwester Nawrocki Reviewed-by: Marek Szyprowski Reviewed-by: Kyungmin Park --- arch/arm/mach-s3c6400/include/mach/map.h |2 + arch/arm/plat-s3c/Kconfig |5 ++ arch/arm/plat-s3c/Makefile|1 + arch/arm/plat-s3c/dev-rotator.c | 42 + arch/arm/plat-s3c/include/plat/devs.h |2 + arch/arm/plat-s3c/include/plat/regs-rotator.h | 62 + 6 files changed, 114 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-s3c/dev-rotator.c create mode 100644 arch/arm/plat-s3c/include/plat/regs-rotator.h diff --git a/arch/arm/mach-s3c6400/include/mach/map.h b/arch/arm/mach-s3c6400/include/mach/map.h index 106ee13..718438e 100644 --- a/arch/arm/mach-s3c6400/include/mach/map.h +++ b/arch/arm/mach-s3c6400/include/mach/map.h @@ -40,6 +40,7 @@ #define S3C64XX_PA_NAND(0x7020) #define S3C64XX_PA_FB (0x7710) +#define S3C64XX_PA_ROTATOR (0x7720) #define S3C64XX_PA_USB_HSOTG (0x7C00) #define S3C64XX_PA_WATCHDOG(0x7E004000) #define S3C64XX_PA_SYSCON (0x7E00F000) @@ -85,5 +86,6 @@ #define S3C_PA_USBHOST S3C64XX_PA_USBHOST #define S3C_PA_USB_HSOTG S3C64XX_PA_USB_HSOTG #define S3C_VA_USB_HSPHY S3C64XX_VA_USB_HSPHY +#define S3C_PA_ROTATOR S3C64XX_PA_ROTATOR #endif /* __ASM_ARCH_6400_MAP_H */ diff --git a/arch/arm/plat-s3c/Kconfig b/arch/arm/plat-s3c/Kconfig index 9e9d028..668c80d 100644 --- a/arch/arm/plat-s3c/Kconfig +++ b/arch/arm/plat-s3c/Kconfig @@ -212,4 +212,9 @@ config S3C_DEV_NAND help Compile in platform device definition for NAND controller +config S3C_DEV_ROTATOR + bool + help + Compile in platform device definition for image rotator + endif diff --git a/arch/arm/plat-s3c/Makefile b/arch/arm/plat-s3c/Makefile index 50444da..a827cfe 100644 --- a/arch/arm/plat-s3c/Makefile +++ b/arch/arm/plat-s3c/Makefile @@ -43,3 +43,4 @@ obj-$(CONFIG_S3C_DEV_FB) += dev-fb.o obj-$(CONFIG_S3C_DEV_USB_HOST) += dev-usb.o obj-$(CONFIG_S3C_DEV_USB_HSOTG)+= dev-usb-hsotg.o obj-$(CONFIG_S3C_DEV_NAND) += dev-nand.o +obj-$(CONFIG_S3C_DEV_ROTATOR) += dev-rotator.o diff --git a/arch/arm/plat-s3c/dev-rotator.c b/arch/arm/plat-s3c/dev-rotator.c new file mode 100644 index 000..8409f70 --- /dev/null +++ b/arch/arm/plat-s3c/dev-rotator.c @@ -0,0 +1,42 @@ +/* + * Samsung S3C/S5P image rotator resource and device definitions. + * + * Copyright (c) 2009 Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the + * License, or (at your option) any later version + */ +#include +#include +#include +#include + +#include +#include +#include +#include + +static struct resource s3c_rotator_resource[] = { + [0] = { + .start = S3C_PA_ROTATOR, + .end= S3C_PA_ROTATOR + SZ_4K - 1, + .flags = IORESOURCE_MEM, + }, + [1] = { + .start = IRQ_ROTATOR, + .end= IRQ_ROTATOR, + .flags = IORESOURCE_IRQ, + } +}; + +struct platform_device s3c_device_rotator = { + .name = "s3c-rotator", + .id = -1, + .num_resources = ARRAY_SIZE(s3c_rotator_resource), + .resource = s3c_rotator_resource, +}; + +EXPORT_SYMBOL(s3c_device_rotator); + diff --git a/arch/arm/plat-s3c/include/plat/devs.h b/arch/arm/plat-s3c/include/plat/devs.h index 932cbbb..ff912a9 100644 --- a/arch/arm/plat-s3c/include/plat/devs.h +++ b/arch/arm/plat-s3c/include/plat/devs.h @@ -56,6 +56,8 @@ extern struct platform_device s3c_device_nand; extern struct platform_device s3c_device_usbgadget; extern struct platform_device s3c_device_usb_hsotg; +extern struct platform_device s3c_device_rotator; + /* s3c2440 specific devices */ #ifdef CONFIG_CPU_S3C2440 diff --git a/arch/arm/plat-s3c/include/plat/regs-rotator.h b/arch/arm/plat-s3c/include/plat/regs-rotator.h new file mode 100644 index 000..6cd1cc9 --- /dev/null +++ b/arch/arm/plat-s3c/include/plat/regs-rotator.h @@ -0,0 +1,62 @@ +/* + * Copyright (c) 2009 Samsung Electronics + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * S3C/S5P image rotator register map + */ + +#ifndef __ASM_ARCH_PLAT_S3C_ROTATOR_H +#define __ASM_ARCH_PLAT_S3C_ROTATOR_H __FILE__ + +#define S3C_ROT_SRC_WIDTH(x) (((x) << 0) & 0x) +#define S3C_ROT_SRC_HEIGHT(x) ((x) << 16) + +#define S3C_ROTATOR_CTRLREG_INT_MASK (1 << 24) +#define S3C_ROTATOR_CTRLRE
[EXAMPLE v2] Mem-to-mem userspace test application.
This is an example application for testing mem-to-mem framework using mem2mem-testdev device. It is intended to be executed multiple times in parallel to test multi-instance operation and scheduling. Each process can be configured differently using command-line arguments. The application opens video test device and framebuffer, sets up params, queues src/dst buffers and displays processed results on the framebuffer. Configurable parameters: starting point on the framebuffer, width/height of buffers, transaction length (in buffers), transaction duration, total number of frames to be processed. Tested on a 800x480 framebuffer with the following script: #!/bin/bash for i in {0..3} do ((x=$i * 100)) ./process-vmalloc 0 $(($i + 1)) $((2000 - $i * 500)) $((($i+1) * 4)) \ $x $x 100 100 & done Signed-off-by: Pawel Osciak Reviewed-by: Kyungmin Park --- --- /dev/null 2009-11-17 07:51:25.574927259 +0100 +++ process-vmalloc.c 2009-11-26 11:00:26.0 +0100 @@ -0,0 +1,420 @@ +/** + * process-vmalloc.c + * Capture+output (process) V4L2 device tester. + * + * Pawel Osciak, p.osc...@samsung.com + * 2009, Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include +#include + +#include + +#define V4L2_CID_TRANS_TIME_MSEC(V4L2_CID_PRIVATE_BASE) +#define V4L2_CID_TRANS_NUM_BUFS (V4L2_CID_PRIVATE_BASE + 1) + +#define VIDEO_DEV_NAME "/dev/video0" +#define FB_DEV_NAME"/dev/fb0" +#define NUM_BUFS 4 +#define NUM_FRAMES 16 + +#define perror_exit(cond, func)\ + if (cond) {\ + fprintf(stderr, "%s:%d: ", __func__, __LINE__);\ + perror(func);\ + exit(EXIT_FAILURE);\ + } + +#define error_exit(cond, func)\ + if (cond) {\ + fprintf(stderr, "%s:%d: failed\n", func, __LINE__);\ + exit(EXIT_FAILURE);\ + } + +#define perror_ret(cond, func)\ + if (cond) {\ + fprintf(stderr, "%s:%d: ", __func__, __LINE__);\ + perror(func);\ + return ret;\ + } + +#define memzero(x)\ + memset(&(x), 0, sizeof (x)); + +#define PROCESS_DEBUG 1 +#ifdef PROCESS_DEBUG +#define debug(msg, ...)\ + fprintf(stderr, "%s: " msg, __func__, ##__VA_ARGS__); +#else +#define debug(msg, ...) +#endif + +static int vid_fd, fb_fd; +static void *fb_addr; +static char *p_src_buf[NUM_BUFS], *p_dst_buf[NUM_BUFS]; +static size_t src_buf_size[NUM_BUFS], dst_buf_size[NUM_BUFS]; +static uint32_t num_src_bufs = 0, num_dst_bufs = 0; + +/* Command-line params */ +int initial_delay = 0; +int fb_x, fb_y, width, height; +int translen = 1; +/* For displaying multi-buffer transaction simulations, indicates current + * buffer in an ongoing transaction */ +int curr_buf = 0; +int transtime = 1000; +int num_frames = 0; +off_t fb_off, fb_line_w, fb_buf_w; +struct fb_var_screeninfo fbinfo; + +static void init_video_dev(void) +{ + int ret; + struct v4l2_capability cap; + struct v4l2_format fmt; + struct v4l2_control ctrl; + + vid_fd = open(VIDEO_DEV_NAME, O_RDWR | O_NONBLOCK, 0); + perror_exit(vid_fd < 0, "open"); + + ctrl.id = V4L2_CID_TRANS_TIME_MSEC; + ctrl.value = transtime; + ret = ioctl(vid_fd, VIDIOC_S_CTRL, &ctrl); + perror_exit(ret != 0, "ioctl"); + + ctrl.id = V4L2_CID_TRANS_NUM_BUFS; + ctrl.value = translen; + ret = ioctl(vid_fd, VIDIOC_S_CTRL, &ctrl); + perror_exit(ret != 0, "ioctl"); + + ret = ioctl(vid_fd, VIDIOC_QUERYCAP, &cap); + perror_exit(ret != 0, "ioctl"); + + if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE)) { + fprintf(stderr, "Device does not support capture\n"); + exit(EXIT_FAILURE); + } + if (!(cap.capabilities & V4L2_CAP_VIDEO_OUTPUT)) { + fprintf(stderr, "Device does not support output\n"); + exit(EXIT_FAILURE); + } + + /* Set format for capture */ + fmt.type= V4L2_BUF_TYPE_VIDEO_CAPTURE; + fmt.fmt.pix.width = width; + fmt.fmt.pix.height = height; + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB565X; + fmt.fmt.pix.field = V4L2_FIELD_ANY; + + ret = ioctl(vid_fd, VIDIOC_S_FMT, &fmt); + perror_exit(ret != 0, "ioctl"); + + /* The same format for output */ + fmt.type = V4L2_BUF_TYPE_VIDEO_OUTPUT; + fmt.fmt.pix.width = width; + fmt.fmt.pix.height = height; + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB565X; + fmt.fmt.pix.field = V4L2_FIELD_ANY; + + ret = ioctl(vid_fd, VIDIOC_S_FMT, &f
[PATCH v2 2/2] V4L: Add a mem-to-mem V4L2 framework test device.
This is a virtual device driver for testing the mem-to-mem V4L2 framework. It simulates a device that uses memory buffers for both source and destination, processes the data and issues an "IRQ" (simulated by a timer). The device is capable of multi-instance, multi-buffer-per-transaction operation (via the mem2mem framework). Signed-off-by: Pawel Osciak Signed-off-by: Marek Szyprowski Reviewed-by: Kyungmin Park --- drivers/media/video/Kconfig | 10 + drivers/media/video/Makefile |1 + drivers/media/video/mem2mem_testdev.c | 1052 + 3 files changed, 1063 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mem2mem_testdev.c diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index caefd7b..6fe4b53 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1090,4 +1090,14 @@ menuconfig V4L_MEM2MEM_DRIVERS to capture and output drivers, which use memory buffers for just one of those. +config VIDEO_MEM2MEM_TESTDEV + tristate "Virtual test device for mem2mem framework" + depends on VIDEO_DEV && VIDEO_V4L2 + select VIDEOBUF_VMALLOC + select V4L2_MEM2MEM_DEV + default n + ---help--- + This is a virtual test device for the memory-to-memory driver + framework. + endif # V4L_MEM2MEM_DRIVERS diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 9fe7d40..8667f1c 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -149,6 +149,7 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/ obj-$(CONFIG_VIDEO_CX18) += cx18/ obj-$(CONFIG_VIDEO_VIVI) += vivi.o +obj-$(CONFIG_VIDEO_MEM2MEM_TESTDEV) += mem2mem_testdev.o obj-$(CONFIG_VIDEO_CX23885) += cx23885/ obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o diff --git a/drivers/media/video/mem2mem_testdev.c b/drivers/media/video/mem2mem_testdev.c new file mode 100644 index 000..ea54a68 --- /dev/null +++ b/drivers/media/video/mem2mem_testdev.c @@ -0,0 +1,1052 @@ +/* + * A virtual v4l2-mem2mem example device. + * + * This is a virtual device driver for testing the mem-to-mem V4L2 framework. + * It simulates a device that uses memory buffers for both source and + * destination, processes the data and issues an "IRQ" (simulated by a timer). + * The device is capable of multi-instance, multi-buffer-per-transaction + * operation (via the mem2mem framework). + * + * Copyright (c) 2009 Samsung Electronics Co., Ltd. + * Pawel Osciak, + * Marek Szyprowski, + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the + * License, or (at your option) any later version + */ +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#define MEM2MEM_TEST_MODULE_NAME "mem2mem-testdev" + +MODULE_DESCRIPTION("Virtual device for mem2mem framework testing"); +MODULE_AUTHOR("Pawel Osciak, "); +MODULE_LICENSE("GPL"); + + +#define MIN_W 32 +#define MIN_H 32 +#define MAX_W 640 +#define MAX_H 480 +#define DIM_ALIGN_MASK 0x08 /* 8-alignment for dimensions */ + +/* Flags that indicate a format can be used for capture/output */ +#define MEM2MEM_CAPTURE(1 << 0) +#define MEM2MEM_OUTPUT (1 << 1) + +#define MEM2MEM_MAX_INSTANCES 10 +#define MEM2MEM_NAME "m2m-testdev" + +/* Per queue */ +#define MEM2MEM_DEF_NUM_BUFS 32 +/* In bytes, per queue */ +#define MEM2MEM_VID_MEM_LIMIT (16 * 1024 * 1024) + +/* Default transaction time in msec */ +#define MEM2MEM_DEF_TRANSTIME 1000 +/* Default number of buffers per transaction */ +#define MEM2MEM_DEF_TRANSLEN 1 +#define MEM2MEM_COLOR_STEP (0xff >> 4) +#define MEM2MEM_NUM_TILES 10 + +#define dprintk(dev, fmt, arg...) \ + v4l2_dbg(1, 1, &dev->v4l2_dev, "%s: " fmt, __func__, ## arg) + + +void m2mtest_dev_release(struct device *dev) +{} + +static struct platform_device m2mtest_pdev = { + .name = MEM2MEM_NAME, + .dev.release= m2mtest_dev_release, +}; + +struct m2mtest_fmt { + char*name; + u32 fourcc; /* v4l2 format id */ + int depth; + /* Types the format can be used for */ + u32 types; +}; + +static struct m2mtest_fmt formats[] = { + { + .name = "RGB565 (BE)", + .fourcc = V4L2_PIX_FMT_RGB565X, /* rggg gggb */ + .depth = 16, + /* Both capture and output format */ + .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT, + }, + { + .name = "4:2:2, packed, YUYV", + .fourcc = V4L2_PIX_FMT_YUYV, + .depth = 16, + /* Output-only format */ + .types = MEM2MEM_OUTPUT, + }, +}; + +/* Per-queue, driver-specific private data */ +struct m2mtest_q_data +{ +
[PATCH v2 1/2] V4L: Add memory-to-memory device helper framework for V4L2.
A mem-to-mem device is a device that uses memory buffers passed by userspace applications for both source and destination data. This is different from existing drivers, which use memory buffers for only one of those at once. In terms of V4L2 such a device would be both of OUTPUT and CAPTURE type. Although no such devices are present in the V4L2 framework, a demand for such a model exists, e.g. for 'resizer devices'. This patch also adds a separate kconfig submenu for mem-to-mem V4L devices. Signed-off-by: Pawel Osciak Signed-off-by: Marek Szyprowski Reviewed-by: Kyungmin Park --- drivers/media/video/Kconfig| 16 + drivers/media/video/Makefile |2 + drivers/media/video/v4l2-mem2mem.c | 671 include/media/v4l2-mem2mem.h | 153 4 files changed, 842 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/v4l2-mem2mem.c create mode 100644 include/media/v4l2-mem2mem.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 2f83be7..caefd7b 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -45,6 +45,10 @@ config VIDEO_TUNER tristate depends on MEDIA_TUNER +config V4L2_MEM2MEM_DEV + tristate + depends on VIDEOBUF_GEN + # # Multimedia Video device configuration # @@ -1075,3 +1079,15 @@ config USB_S2255 endif # V4L_USB_DRIVERS endif # VIDEO_CAPTURE_DRIVERS + +menuconfig V4L_MEM2MEM_DRIVERS + bool "Memory-to-memory multimedia devices" + depends on VIDEO_V4L2 + default n + ---help--- + Say Y here to enable selecting drivers for V4L devices that + use system memory for both source and destination buffers, as opposed + to capture and output drivers, which use memory buffers for just + one of those. + +endif # V4L_MEM2MEM_DRIVERS diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 2af68ee..9fe7d40 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -115,6 +115,8 @@ obj-$(CONFIG_VIDEOBUF_VMALLOC) += videobuf-vmalloc.o obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o +obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o + obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o diff --git a/drivers/media/video/v4l2-mem2mem.c b/drivers/media/video/v4l2-mem2mem.c new file mode 100644 index 000..417ee2c --- /dev/null +++ b/drivers/media/video/v4l2-mem2mem.c @@ -0,0 +1,671 @@ +/* + * Memory-to-memory device framework for Video for Linux 2. + * + * Helper functions for devices that use memory buffers for both source + * and destination. + * + * Copyright (c) 2009 Samsung Electronics Co., Ltd. + * Pawel Osciak, + * Marek Szyprowski, + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the + * License, or (at your option) any later version + */ + +#include +#include +#include +#include + +MODULE_DESCRIPTION("Mem to mem device framework for V4L2"); +MODULE_AUTHOR("Pawel Osciak, "); +MODULE_LICENSE("GPL"); + +static int debug; +module_param(debug, int, 0644); + +#define dprintk(fmt, arg...) do {\ + if (debug >= 1)\ + printk(KERN_DEBUG "%s: " fmt, __func__, ## arg); } while (0) + + +/* The instance is already queued on the jobqueue */ +#define TRANS_QUEUED (1 << 0) +/* The instance is currently running in hardware */ +#define TRANS_RUNNING (1 << 1) + + +/* Offset base for buffers on the destination queue - used to distinguish + * between source and destination buffers when mmapping - they receive the same + * offsets but for different queues */ +#define DST_QUEUE_OFF_BASE (TASK_SIZE / 2) + + +struct v4l2_m2m_dev { + /* Currently running instance */ + struct v4l2_m2m_ctx *curr_ctx; + /* Instances queued to run */ + struct list_headjobqueue; + spinlock_t job_spinlock; + + struct v4l2_m2m_ops *m2m_ops; +}; + +static inline +struct v4l2_m2m_queue_ctx *get_queue_ctx(struct v4l2_m2m_ctx *m2m_ctx, +enum v4l2_buf_type type) +{ + switch (type) { + case V4L2_BUF_TYPE_VIDEO_CAPTURE: + return &m2m_ctx->cap_q_ctx; + case V4L2_BUF_TYPE_VIDEO_OUTPUT: + return &m2m_ctx->out_q_ctx; + default: + printk(KERN_ERR "Invalid buffer type\n"); + return NULL; + } +} + +/** + * v4l2_m2m_get_vq() - return videobuf_queue for the given type + */ +struct videobuf_queue *v4l2_m2m_get_vq(struct v4l2_m2m_ctx *m2m_ctx, + enum v4l2_buf_type type) +{ + struct v4l2_m2m_queue_ctx *q_ctx; + + q_ctx = get_queue_ctx(m2m_ctx, type); + if (!q_ctx) + return NULL; +
[PATCH/RFC v2 0/2] Mem-to-mem device framework
Hello, this is the second version of the proposed implementation for mem-to-mem memory device framework. Your comments are very welcome. Changes since v1: - v4l2_m2m_buf_queue() now requires m2m_ctx as its argument - video_queue private data stores driver private data - a new submenu in kconfig for mem-to-mem devices - minor rebase leftovers cleanup A second patch series will follow (right after this one) with a new driver for a real device - Samsung S3C/S5P image rotator, utilizing this framework. This series contains: [PATCH v2 1/2] V4L: Add memory-to-memory device helper framework for V4L2. [PATCH v2 2/2] V4L: Add a mem-to-mem V4L2 framework test device. [EXAMPLE v2] Mem-to-mem userspace test application. Previous discussion and RFC on this topic: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/10668 A mem-to-mem device is a device that uses memory buffers passed by userspace applications for both source and destination. This is different from existing drivers that use memory buffers for only one of those at once. In terms of V4L2 such a device would be both of OUTPUT and CAPTURE type. Although no such devices are present in the V4L2 framework, a demand for such a model exists, e.g. for 'resizer devices'. --- Mem-to-mem devices --- In the previous discussion we concluded that we should use one video node with two queues, an output (V4L2_BUF_TYPE_VIDEO_OUTPUT) queue for source buffers and a capture queue (V4L2_BUF_TYPE_VIDEO_CAPTURE) for destination buffers. Each instance has its own set of queues: 2 videobuf_queues, each with a ready buffer queue, managed by the framework. Everything is encapsulated in the queue context struct: struct v4l2_m2m_queue_ctx { struct videobuf_queue q; /* ... */ /* Queue for buffers ready to be processed as soon as this * instance receives access to the device */ struct list_headrdy_queue; /* ... */ }; struct v4l2_m2m_ctx { /* ... */ /* Capture (output to memory) queue context */ struct v4l2_m2m_queue_ctx cap_q_ctx; /* Output (input from memory) queue context */ struct v4l2_m2m_queue_ctx out_q_ctx; /* ... */ }; Streamon can be called for all instances and will not sleep if another instance is streaming. vidioc_querycap() should report V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT. --- Queuing and dequeuing buffers --- Applications can queue as many buffers as they want and it is not required to queue an equal number of source and destination buffers. If there is not enough buffers of any type, a new transaction will simply not be scheduled. --- Source and destination formats --- Should be set per queue. A helper function to access queues depending on the passed type - v4l2_m2m_get_vq() - is supplied. Most of the format-handling code is normally located in drivers anyway. The only exception is the "field" member of the videobuf_queue struct, which has to be set directly. It breaks encapsulation a little bit, but nothing can be done with it. --- Scheduling --- Requirements/assumptions: 1. More than one instance can be open at the same time. 2. Each instance periodically receives exclusive access to the device, performs an operation (operations) and yields back the device in a state that allows other instances to use it. 3. When an instance gets access to the device, it performs a "transaction"/"job". A transaction/job is defined as the shortest operation that cannot/should not be further divided without having to restart it from scratch, or without having to perform expensive reconfiguration of a device, etc. 4. Transactions can use multiple source/destination buffers. 5. Only a driver can tell when it is ready to perform a transaction, so a optional callback is provided for that purpose (job_ready()). There are three common requirements for a transaction to be ready to run: - at least one source buffer ready - at least one destination buffer ready - streaming on - (optional) driver-specific requirements (driver-specific callback function) So when buffers are queued by qbuf() or streaming is turned on with streamon(), the framework calls v4l2_m2m_try_schedule(). v4l2_m2m_try_schedule() 1. Checks for the above conditions. 2. Checks for driver-specific conditions by calling job_ready() callback, if supplied. 3. If all the checks