RE: [PATCHv8 00/12] Contiguous Memory Allocator
Hello, On Wednesday, January 12, 2011 8:04 PM Nicolas Pitre wrote: > On Wed, 12 Jan 2011, Marek Szyprowski wrote: > > > I understand that modifying L1 page tables is definitely not a proper way of > > handling this. It simply costs too much. But what if we consider that the > > DMA > > memory can be only allocated from a specific range of the system memory? > > Assuming that this range of memory is known during the boot time, it CAN be > > mapped with two-level of tables in MMU. First level mapping will stay the > > same all the time for all processes, but it would be possible to unmap the > > pages required for DMA from the second level mapping what will be visible > > from all the processes at once. > > How much memory are we talking about? What is the typical figure? One typical scenario we would like to support is full-hd decoding. One frame is about 4MB (1920x1080x2 ~= 4MB). Depending on the codec, it may require up to 15 buffers what gives about 60MB. This simple calculation does not include memory for the framebuffer, temporary buffers for the hardware codec and buffers for the stream. > > Is there any reason why such solution won't work? > > It could work indeed. > > One similar solution that is already in place is to use highmem for that > reclaimable DMA memory. It is easy to ensure affected highmem pages are > not mapped in kernel space. And you can decide at boot time how many > highmem pages you want even if the system has less that 1GB of RAM. Hmmm, right, this might also help solving the problem. Best regards -- Marek Szyprowski 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
RE: Enable IR on hdpvr
On Thu, 2011-01-13 at 02:16 +, Jason Gauthier wrote: > >> I've got two hdpvrs. Whenever you're ready to extend your testing, > >> I'm happy to extend that functional testing. I didn't get a chance to > >> look at the FC14 patch yet (busy couple of days), but I will hold off > >> now, anyway! > > >If all goes well, with Jarrod's change, you should be able to test the > >hdpvr module with the ir-kbd-i2c module and test IR Rx. > > >Strictly speaking, lirc_zilog needs some rework to use the kernel > >internal interfaces properly. It might still work, but don't be > >surprised if it doesn't. > > >I might get to working on lirc_zilog tonight, but otherwise not until > >this weekend. > > Sounds good. Will give any feedback I can! Is Tx completely a no show > at this point? No, it might work. It's hard to tell, but you best course of action is to load the hdpvr driver and then load the lirc_zilog module and *do not* unload it. The major lirc_zilog problem is *double* registration of the Tx and Rx interfaces due to an old design in lirc_zilog.c:ir_probe(). Other subtle problems I noticed were pointer use after kfree() and not deallocating everything properly on module unload. How will those affect you? I don't know... Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Enable IR on hdpvr
On Wed, 2011-01-12 at 18:45 -0500, Andy Walls wrote: > If all goes well, with Jarrod's change, you should be able to test the > hdpvr module with the ir-kbd-i2c module and test IR Rx. FYI, I have (re)confirmed that ir-kbd-i2c and cx18, in a bleeding-edge development kernel, still work with the Zilog Z8 IR Rx on the HVR-1600. It's nice to have a known working baseline. > Strictly speaking, lirc_zilog needs some rework to use the kernel > internal interfaces properly. It might still work, but don't be > surprised if it doesn't. > > I might get to working on lirc_zilog tonight, but otherwise not until > this weekend. lirc_zilog got a little work tonight: http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8 My changes make it slightly *more* broken in some respects. :D At least what needs to be reworked is now becoming easier to see and address. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] addition to v2.6.35_i2c_new_probed_device.patch (was: Re: Debug code in HG repositories)
On 1/12/11, Mauro Carvalho Chehab wrote: >> which on the face of it suggests >> btty-input.c already handled, my mistake. >> cx88-input.c the search string was in a comment >> hdpvr-i2c.c see below > I have no time currently to touch on it, since I still have lots of patches > to > take a look and submit for the merge window. So, if you have some time, > could you please prepare and submit a patch fixing it? This seems to be a relatively simple patch, inline below. This is against the linux-media tree, I could not figure out how to turn it into a clean patch of media_build/backports/v2.6.35_i2c_new_probed_device.patch I did look for guidance on how to do this in media_build/README.patches but could not find anything that looked relevant. The code now compiles for me but I don't know if it will actually work, I don't have the hardware. Cheers Vince Signed-off-by: Vince McIntyre --- drivers/media/video/hdpvr/hdpvr-i2c.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c b/drivers/media/video/hdpvr/hdpvr-i2c.c index 24966aa..129639a 100644 --- a/drivers/media/video/hdpvr/hdpvr-i2c.c +++ b/drivers/media/video/hdpvr/hdpvr-i2c.c @@ -59,7 +59,7 @@ static int hdpvr_new_i2c_ir(struct hdpvr_device *dev, struct i2c_adapter *adap, break; } - return i2c_new_probed_device(adap, &info, addr_list, NULL) == NULL ? + return i2c_new_probed_device(adap, &info, addr_list) == NULL ? -1 : 0; } -- 1.7.0.4 From 1b44e5c3b2886224042d9c20649311c231db3ccd Mon Sep 17 00:00:00 2001 From: Vince McIntyre Date: Thu, 13 Jan 2011 15:30:13 +1100 Subject: [PATCH] To compile against 2.6.32, drop extra arg when calling i2c_new_probed_device() Signed-off-by: Vince McIntyre --- drivers/media/video/hdpvr/hdpvr-i2c.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c b/drivers/media/video/hdpvr/hdpvr-i2c.c index 24966aa..129639a 100644 --- a/drivers/media/video/hdpvr/hdpvr-i2c.c +++ b/drivers/media/video/hdpvr/hdpvr-i2c.c @@ -59,7 +59,7 @@ static int hdpvr_new_i2c_ir(struct hdpvr_device *dev, struct i2c_adapter *adap, break; } - return i2c_new_probed_device(adap, &info, addr_list, NULL) == NULL ? + return i2c_new_probed_device(adap, &info, addr_list) == NULL ? -1 : 0; } -- 1.7.0.4
[PATCH] tm6000: rework init code
Hi
Rework device init part. Move common code part to a function.
Usefull for register multiple devices like video, radio, vbi etc.
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
index 8fe017c..4d866cc 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -1450,29 +1450,55 @@ static struct video_device tm6000_template = {
* --
*/
-int tm6000_v4l2_register(struct tm6000_core *dev)
+static struct video_device *vdev_init(struct tm6000_core *dev,
+ const struct video_device
+ *template, const char *type_name)
{
- int ret = -1;
struct video_device *vfd;
vfd = video_device_alloc();
- if(!vfd) {
+ if (NULL == vfd)
+ return NULL;
+
+ *vfd = *template;
+ vfd->v4l2_dev = &dev->v4l2_dev;
+ vfd->release = video_device_release;
+ vfd->debug = tm6000_debug;
+ vfd->lock = &dev->lock;
+
+ snprintf(vfd->name, sizeof(vfd->name), "%s %s", dev->name, type_name);
+
+ video_set_drvdata(vfd, dev);
+ return vfd;
+}
+
+int tm6000_v4l2_register(struct tm6000_core *dev)
+{
+ int ret = -1;
+
+ dev->vfd = vdev_init(dev, &tm6000_template, "video");
+
+ if (!dev->vfd) {
+ printk(KERN_INFO "%s: can't register video device\n",
+ dev->name);
return -ENOMEM;
}
- dev->vfd = vfd;
/* init video dma queues */
INIT_LIST_HEAD(&dev->vidq.active);
INIT_LIST_HEAD(&dev->vidq.queued);
- memcpy(dev->vfd, &tm6000_template, sizeof(*(dev->vfd)));
- dev->vfd->debug = tm6000_debug;
- dev->vfd->lock = &dev->lock;
+ ret = video_register_device(dev->vfd, VFL_TYPE_GRABBER, video_nr);
- vfd->v4l2_dev = &dev->v4l2_dev;
- video_set_drvdata(vfd, dev);
+ if (ret < 0) {
+ printk(KERN_INFO "%s: can't register video device\n",
+ dev->name);
+ return ret;
+ }
+
+ printk(KERN_INFO "%s: registered device %s\n",
+ dev->name, video_device_node_name(dev->vfd));
- ret = video_register_device(dev->vfd, VFL_TYPE_GRABBER, video_nr);
printk(KERN_INFO "Trident TVMaster TM5600/TM6000/TM6010 USB2 board
(Load status: %d)\n", ret);
return ret;
}
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
With my best regards, Dmitry.
diff --git a/drivers/staging/tm6000/tm6000-video.c b/drivers/staging/tm6000/tm6000-video.c
index 8fe017c..4d866cc 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -1450,29 +1450,55 @@ static struct video_device tm6000_template = {
* --
*/
-int tm6000_v4l2_register(struct tm6000_core *dev)
+static struct video_device *vdev_init(struct tm6000_core *dev,
+ const struct video_device
+ *template, const char *type_name)
{
- int ret = -1;
struct video_device *vfd;
vfd = video_device_alloc();
- if(!vfd) {
+ if (NULL == vfd)
+ return NULL;
+
+ *vfd = *template;
+ vfd->v4l2_dev = &dev->v4l2_dev;
+ vfd->release = video_device_release;
+ vfd->debug = tm6000_debug;
+ vfd->lock = &dev->lock;
+
+ snprintf(vfd->name, sizeof(vfd->name), "%s %s", dev->name, type_name);
+
+ video_set_drvdata(vfd, dev);
+ return vfd;
+}
+
+int tm6000_v4l2_register(struct tm6000_core *dev)
+{
+ int ret = -1;
+
+ dev->vfd = vdev_init(dev, &tm6000_template, "video");
+
+ if (!dev->vfd) {
+ printk(KERN_INFO "%s: can't register video device\n",
+ dev->name);
return -ENOMEM;
}
- dev->vfd = vfd;
/* init video dma queues */
INIT_LIST_HEAD(&dev->vidq.active);
INIT_LIST_HEAD(&dev->vidq.queued);
- memcpy(dev->vfd, &tm6000_template, sizeof(*(dev->vfd)));
- dev->vfd->debug = tm6000_debug;
- dev->vfd->lock = &dev->lock;
+ ret = video_register_device(dev->vfd, VFL_TYPE_GRABBER, video_nr);
- vfd->v4l2_dev = &dev->v4l2_dev;
- video_set_drvdata(vfd, dev);
+ if (ret < 0) {
+ printk(KERN_INFO "%s: can't register video device\n",
+ dev->name);
+ return ret;
+ }
+
+ printk(KERN_INFO "%s: registered device %s\n",
+ dev->name, video_device_node_name(dev->vfd));
- ret = video_register_device(dev->vfd, VFL_TYPE_GRABBER, video_nr);
printk(KERN_INFO "Trident TVMaster TM5600/TM6000/TM6010 USB2 board (Load status: %d)\n", ret);
return ret;
}
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
Re: [GIT PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates
Hi Mauro, On Wed, Jan 12, 2011 at 10:49, Mauro Carvalho Chehab wrote: > Em 12-01-2011 08:25, Marek Szyprowski escreveu: >> Hello Mauro, >> >> I've rebased our fimc and saa patches onto >> http://linuxtv.org/git/mchehab/experimental.git >> vb2_test branch. > > Thanks! > > As before, I'll be commenting the patches as I'll be seeing any issues. > >> Pawel Osciak (2): >> Fix mmap() example in the V4L2 API DocBook > > In fact, the check for retval < 0 instead of retval == -1 is not a fix. > According with > mmap man pages: > RETURN VALUE > On success, mmap() returns a pointer to the mapped area. On > error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno > is set appropriately. On success, munmap() returns 0, on > failure -1, and errno is set (probably to EINVAL). > > The change is not wrong, as -1 is lower than 0, but using -1 is more > compliant with > libc. So, I'll be applying just the CodingStyle fixes on it. Sorry, but I think you got it wrong. The example is called "mmap() example". But I did not change return value checking of mmap() calls. I changed return value checking of ioctl() calls. So I believe the patch is correct. -- Best regards, Pawel Osciak -- 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: Enable IR on hdpvr
>> I've got two hdpvrs. Whenever you're ready to extend your testing, >> I'm happy to extend that functional testing. I didn't get a chance to >> look at the FC14 patch yet (busy couple of days), but I will hold off >> now, anyway! >If all goes well, with Jarrod's change, you should be able to test the >hdpvr module with the ir-kbd-i2c module and test IR Rx. >Strictly speaking, lirc_zilog needs some rework to use the kernel >internal interfaces properly. It might still work, but don't be >surprised if it doesn't. >I might get to working on lirc_zilog tonight, but otherwise not until >this weekend. Sounds good. Will give any feedback I can! Is Tx completely a no show at this point? From my circle of friends that use the hdpvr, they all use the Tx for channel changing to cable boxes. This small sample might not be indicative of the larger hdpvr user base, though! :) -- 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: Enable IR on hdpvr
On Wed, 2011-01-12 at 13:49 +, Jason Gauthier wrote: > >> > >> Bah. Yeah, sorry, that wasn't the current patch in Fedora 14. This is: > >> > >> http://wilsonet.com/jarod/lirc_misc/hdpvr-ir/hdpvr-ir-enable-2.patch > >> > >> Its atop the F14 2.6.35.10 kernel, which has a fairly recent v4l/dvb > >> backport on top of it, so it should be pretty close to matching the > >> current v4l/dvb code... > > >With the help of Andy Walls and Jean Delvare, I think we've hashed > out an updated patch that will work sitting atop the current v4l/dvb > hdpvr code, but I'm only just now getting around to compile->testing > it, and its past my bedtime, so it'll be tomorrow before I can do any > sort of functional testing (but hey, due to the snow, I'll be working > from home tomorrow, where my hdpvr happens to be...). > > I've got two hdpvrs. Whenever you're ready to extend your testing, > I'm happy to extend that functional testing. I didn't get a chance to > look at the FC14 patch yet (busy couple of days), but I will hold off > now, anyway! If all goes well, with Jarrod's change, you should be able to test the hdpvr module with the ir-kbd-i2c module and test IR Rx. Strictly speaking, lirc_zilog needs some rework to use the kernel internal interfaces properly. It might still work, but don't be surprised if it doesn't. I might get to working on lirc_zilog tonight, but otherwise not until this weekend. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dib7000m/p: struct alignment fix
Em 12-01-2011 11:17, Robin Humble escreveu: > Hi, > > this is basically a re-post of > http://www.linuxtv.org/pipermail/linux-dvb/2010-September/032744.html > which fixes an Oops when tuning eg. AVerMedia DVB-T Volar, Hauppauge > Nova-T, Winfast DTV. it seems to be quite commonly reported on this list. > > [ 809.128579] BUG: unable to handle kernel NULL pointer dereference at > 0012 > [ 809.128586] IP: [] i2c_transfer+0x16/0x124 [i2c_core] > [ 809.128598] PGD 669a7067 PUD 79e5f067 PMD 0 > [ 809.128604] Oops: [#1] SMP > [ 809.128608] last sysfs file: > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > [ 809.128612] CPU 0 > [ 809.128614] Modules linked in: tcp_lp fuse coretemp hwmon_vid > cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 > ip6table_filter ip6_tables ipv6 xfs exportfs uinput mt2060 mxl5005s af9013 > dvb_usb_dib0700 ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder > dib7000p dib0090 dib7000m dvb_usb_af9015 dib0070 dvb_usb dib8000 dvb_core > dib3000mc ir_rc6_decoder dibx000_common snd_hda_codec_intelhdmi > ir_rc5_decoder snd_hda_codec_realtek snd_hda_intel ir_nec_decoder > snd_hda_codec ldusb i2c_i801 snd_hwdep snd_seq snd_seq_device rc_core atl1 > asus_atk0110 snd_pcm snd_timer mii snd soundcore snd_page_alloc iTCO_wdt > iTCO_vendor_support microcode raid456 async_raid6_recov async_pq raid6_pq > async_xor xor async_memcpy async_tx raid1 ata_generic firewire_ohci pata_acpi > firewire_core crc_itu_t pata_jmicron i915 drm_kms_helper drm i2c_algo_bit > i2c_core video output [last unloaded: scsi_wait_scan] > [ 809.128692] > [ 809.128696] Pid: 2525, comm: tzap Not tainted 2.6.35.10-72.fc14.x86_64 #1 > P5E-VM HDMI/P5E-VM HDMI > [ 809.128700] RIP: 0010:[] [] > i2c_transfer+0x16/0x124 [i2c_core] > [ 809.128708] RSP: 0018:880064a83ae8 EFLAGS: 00010296 > [ 809.128712] RAX: 880064a83b58 RBX: 00eb RCX: > > [ 809.128715] RDX: 0002 RSI: 880064a83b38 RDI: > 0002 > [ 809.128718] RBP: 880064a83b28 R08: 880079bcf7c0 R09: > 5d80 > [ 809.128721] R10: 0005 R11: 4a38 R12: > 0001 > [ 809.128725] R13: R14: c900237e8000 R15: > c90023907000 > [ 809.128729] FS: 7f2ff2dd3720() GS:88000200() > knlGS: > [ 809.128732] CS: 0010 DS: ES: CR0: 80050033 > [ 809.128736] CR2: 0012 CR3: 7830d000 CR4: > 06f0 > [ 809.128739] DR0: DR1: DR2: > > [ 809.128743] DR3: DR6: 0ff0 DR7: > 0400 > [ 809.128746] Process tzap (pid: 2525, threadinfo 880064a82000, task > 8800379745c0) > [ 809.128749] Stack: > [ 809.128751] 880064a83af8 8103c142 880079c41a90 > 00eb > [ 809.128757] <0> 0001 c900237e8000 > c90023907000 > [ 809.128762] <0> 880064a83b88 a0407124 00020030 > 880064a83b68 > [ 809.128768] Call Trace: > [ 809.128776] [] ? need_resched+0x23/0x2d > [ 809.128783] [] dib7000p_read_word+0x6d/0xbc [dib7000p] > [ 809.128789] [] ? usb_submit_urb+0x2f8/0x33a > [ 809.128795] [] dib7000p_pid_filter_ctrl+0x2d/0x90 > [dib7000p] > [ 809.128802] [] stk70x0p_pid_filter_ctrl+0x19/0x1e > [dvb_usb_dib0700] > [ 809.128809] [] dvb_usb_ctrl_feed+0xd7/0x123 [dvb_usb] > [ 809.128815] [] dvb_usb_start_feed+0x13/0x15 [dvb_usb] > [ 809.128825] [] dmx_ts_feed_start_filtering+0x7d/0xd1 > [dvb_core] > [ 809.128833] [] dvb_dmxdev_start_feed.clone.1+0xbd/0xeb > [dvb_core] > [ 809.128841] [] dvb_dmxdev_filter_start+0x2cf/0x31b > [dvb_core] > [ 809.128847] [] ? _raw_spin_lock_irq+0x1f/0x21 > [ 809.128854] [] dvb_demux_do_ioctl+0x27b/0x4c0 > [dvb_core] > [ 809.128859] [] ? should_resched+0xe/0x2e > [ 809.128867] [] dvb_usercopy+0xe4/0x16b [dvb_core] > [ 809.128874] [] ? dvb_demux_do_ioctl+0x0/0x4c0 > [dvb_core] > [ 809.128881] [] ? inode_has_perm.clone.20+0x79/0x8f > [ 809.128886] [] ? remove_wait_queue+0x35/0x41 > [ 809.128891] [] ? _raw_spin_unlock_irqrestore+0x17/0x19 > [ 809.128898] [] dvb_demux_ioctl+0x15/0x19 [dvb_core] > [ 809.128903] [] vfs_ioctl+0x36/0xa7 > [ 809.128908] [] do_vfs_ioctl+0x468/0x49b > [ 809.128912] [] sys_ioctl+0x56/0x79 > [ 809.128917] [] system_call_fastpath+0x16/0x1b > [ 809.128920] Code: 89 55 f8 48 83 c7 58 48 c7 c2 47 32 01 a0 e8 92 09 2c > e1 c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 > <48> 8b 47 10 48 89 fb 49 89 f6 41 89 d7 48 83 38 00 0f 84 92 00 > [ 809.128965] RIP [] i2c_transfer+0x16/0x124 [i2c_core] > [ 809.128973] RSP > [ 809.128975] CR2: 0012 > [ 809.128979] ---[ end trace 6919129d55f94398 ]--- > > this Oops occurs for me on all >2.6.32 kernels, inc
Rv: Re: CyberLink video grabber 2.0
Dear linux media developers, here is the output of my "lsusb -v -d 1d19:6105": Bus 001 Device 007: ID 1d19:6105 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1d19 idProduct 0x6105 bcdDevice2.00 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 97 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 5 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 5 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5
Re: [GIT PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates
Em 12-01-2011 08:25, Marek Szyprowski escreveu: > Hello Mauro, > > I've rebased our fimc and saa patches onto > http://linuxtv.org/git/mchehab/experimental.git > vb2_test branch. > > The last 2 patches are for SAA7134 driver and are only to show that > videobuf2-dma-sg works > correctly. On my first test with saa7134, it hanged. It seems that the code reached a dead lock. On my test environment, I'm using a remote machine, without monitor. My test is using qv4l2 via a remote X server. Using a remote X server is an interesting test, as it will likely loose some frames, increasing the probability of races and dead locks. That's what happened: Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.16 loaded saa7130/34: w/o radio and vbi saa7133[0]: found at :37:09.0, rev: 209, irq: 21, latency: 32, mmio: 0xfb000 saa7133[0]: subsystem: 17de:b136, board: Kworld PCI SBTVD/ISDB-T Full-Seg Hybri] saa7133[0]: board init: gpio is 4000 hwinit1 IRQ 21/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]/irq: no (more) work saa7133[0]: i2c eeprom 00: de 17 36 b1 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: ff ff ff ff ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 03 03 ff 01 03 08 ff 01 90 ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff 1c 00 c0 ff 1c 01 00 ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Chip ID is not zero. It is not a TEA5767 tuner 2-0060: chip found @ 0xc0 (saa7133[0]) tda18271 2-0060: creating new instance TDA18271HD/C2 detected @ 2-0060 hwinit2 tda18271: performing RF tracking filter calibration tda18271: RF tracking filter calibration complete DCSDT: pll: not locked, sync: no, norm: (no signal) saa7133[0]: registered device video0 [v4l2] saa7134_dvb: disagrees about version of symbol videobuf_dvb_alloc_frontend saa7134_dvb: Unknown symbol videobuf_dvb_alloc_frontend saa7134_dvb: Unknown symbol saa7134_ts_register saa7134_dvb: disagrees about version of symbol videobuf_dvb_get_frontend saa7134_dvb: Unknown symbol videobuf_dvb_get_frontend saa7134_dvb: disagrees about version of symbol videobuf_queue_sg_init saa7134_dvb: Unknown symbol videobuf_queue_sg_init saa7134_dvb: disagrees about version of symbol saa7134_set_gpio saa7134_dvb: Unknown symbol saa7134_set_gpio saa7134_dvb: Unknown symbol saa7134_ts_qops saa7134_dvb: Unknown symbol saa7134_ts_unregister saa7134_alsa: Unknown symbol saa7134_tvaudio_setmute saa7134_alsa: Unknown symbol saa_dsp_writel saa7134_alsa: disagrees about version of symbol saa7134_boards saa7134_alsa: Unknown symbol saa7134_boards saa7134_alsa: disagrees about version of symbol saa7134_dmasound_init saa7134_alsa: Unknown symbol saa7134_dmasound_init saa7134_alsa: disagrees about version of symbol saa7134_dmasound_exit saa7134_alsa: Unknown symbol saa7134_dmasound_exit saa7134_alsa: disagrees about version of symbol saa7134_set_dmabits saa7134_alsa: Unknown symbol saa7134_set_dmabits saa7134_reqbufs: 880051ecd528 880051d2fd48 queue_setup vb2_dma_sg_alloc: Allocated buffer of 304 pages saa7134_querybuf: 880051ecd528 880051d2fd48 saa7134_reqbufs: 880051ecd528 880051d2fd48 vb2_dma_sg_put: Freeing buffer of 304 pages queue_setup saa7134_reqbufs: 880051ecd528 880051d2fd48 queue_setup vb2_dma_sg_alloc: Allocated buffer of 304 pages vb2_dma_sg_alloc: Allocated buffer of 304 pages vb2_dma_sg_alloc: Allocated buffer of 304 pages saa7134_querybuf: 880051ecd528 880051d2fd48 vb2_common_vm_open: 880067d1b178, refcount: 1, vma: 7fa8e0d67000-7fa8e0e9700 saa7134_querybuf: 880051ecd528 880051d2fd48 vb2_common_vm_open: 8800a21cb278, refcount: 1, vma: 7fa8e0c37000-7fa8e0d6700 saa7134_querybuf: 880051ecd528 880051d2fd48 vb2_common_vm_open: 880067c84ef8, refcount: 1, vma: 7fa8e0b07000-7fa8e0c3700 saa7134_qbuf: 880051ecd528 880051d2fd48 buffer_prepare: sglist:c90005139000 num_pages:304 saa7134_qbuf: 880051ecd528 880051d2fd48 buffer_prepare: sglist:c900051ab000 num_pages:304 saa7134_qbuf: 880051ecd528 880051d2fd48 buffer_prepare: sglist:c900051bf
RE: [PATCHv8 00/12] Contiguous Memory Allocator
On Wed, 12 Jan 2011, Marek Szyprowski wrote: > I understand that modifying L1 page tables is definitely not a proper way of > handling this. It simply costs too much. But what if we consider that the DMA > memory can be only allocated from a specific range of the system memory? > Assuming that this range of memory is known during the boot time, it CAN be > mapped with two-level of tables in MMU. First level mapping will stay the > same all the time for all processes, but it would be possible to unmap the > pages required for DMA from the second level mapping what will be visible > from all the processes at once. How much memory are we talking about? What is the typical figure? > Is there any reason why such solution won't work? It could work indeed. One similar solution that is already in place is to use highmem for that reclaimable DMA memory. It is easy to ensure affected highmem pages are not mapped in kernel space. And you can decide at boot time how many highmem pages you want even if the system has less that 1GB of RAM. Nicolas -- 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: [PATCHv8 00/12] Contiguous Memory Allocator
Hello, I'm sorry for the delay. Just got back from my holidays and getting thought the mails. On Thursday, December 23, 2010 2:45 PM Russell King - ARM Linux wrote: > On Thu, Dec 23, 2010 at 02:09:44PM +0100, Marek Szyprowski wrote: > > Hello, > > > > On Thursday, December 23, 2010 1:19 PM Russell King - ARM Linux wrote: > > > > > On Thu, Dec 23, 2010 at 11:58:08AM +0100, Marek Szyprowski wrote: > > > > Actually this contiguous memory allocator is a better replacement for > > > > alloc_pages() which is used by dma_alloc_coherent(). It is a generic > > > > framework that is not tied only to ARM architecture. > > > > > > ... which is open to abuse. What I'm trying to find out is - if it > > > can't be used for DMA, what is it to be used for? > > > > > > Or are we inventing an everything-but-ARM framework? > > > > We are trying to get something that really works and SOLVES some of the > > problems with real devices that require contiguous memory for DMA. > > So, here you've confirmed that it's for DMA. Right, otherwise it wouldn't really make much sense. Note that our proposal already works for non-arm platforms. > > > > > In other words, do we _actually_ have a use for this which doesn't > > > > > involve doing something like allocating 32MB of memory from it, > > > > > remapping it so that it's DMA coherent, and then performing DMA > > > > > on the resulting buffer? > > > > > > > > This is an arm specific problem, also related to dma_alloc_coherent() > > > > allocator. To be 100% conformant with ARM specification we would > > > > probably need to unmap all pages used by the dma_coherent allocator > > > > from the LOW MEM area. This is doable, but completely not related > > > > to the CMA and this patch series. > > > > > > You've already been told why we can't unmap pages from the kernel > > > direct mapping. > > > > It requires some amount of work but I see no reason why we shouldn't be > > able to unmap that pages to stay 100% conformant with ARM spec. > > I have considered - and tried - to do that with the dma_alloc_coherent() > spec, but it is NOT POSSIBLE to do so - too many factors stand in the > way of making it work, such as the need bring the system to a complete > halt to modify all the L1 page tables and broadcast the TLB operations > to invalidate the old mappings. None of that can be done from all the > contexts under which dma_alloc_coherent() is called from. I understand that this requires a lot of work, but I still think this might be possible to get it working with some additional constraints. I understand that modifying L1 page tables is definitely not a proper way of handling this. It simply costs too much. But what if we consider that the DMA memory can be only allocated from a specific range of the system memory? Assuming that this range of memory is known during the boot time, it CAN be mapped with two-level of tables in MMU. First level mapping will stay the same all the time for all processes, but it would be possible to unmap the pages required for DMA from the second level mapping what will be visible from all the processes at once. Is there any reason why such solution won't work? Best regards -- Marek Szyprowski 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
Re: [GIT PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates
Em 12-01-2011 08:25, Marek Szyprowski escreveu: > Hello Mauro, > > I've rebased our fimc and saa patches onto > http://linuxtv.org/git/mchehab/experimental.git > vb2_test branch. Thanks! As before, I'll be commenting the patches as I'll be seeing any issues. > Pawel Osciak (2): > Fix mmap() example in the V4L2 API DocBook In fact, the check for retval < 0 instead of retval == -1 is not a fix. According with mmap man pages: RETURN VALUE On success, mmap() returns a pointer to the mapped area. On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is set appropriately. On success, munmap() returns 0, on failure -1, and errno is set (probably to EINVAL). The change is not wrong, as -1 is lower than 0, but using -1 is more compliant with libc. So, I'll be applying just the CodingStyle fixes on it. 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
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Jan 12 19:00:53 CET 2011 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 A linux-media.tar.bz2 archive with the latest media git sources that can be used with the media_build tree is available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday-linux-media.tar.bz2 Rename to linux-media.tar.bz2, put it in the media_build/linux directory, go to the directory and type 'make untar'. The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] ir-kbd-i2c: Make IR debug messages more useful
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c
index c87b6bc..b173e40 100644
--- a/drivers/media/video/ir-kbd-i2c.c
+++ b/drivers/media/video/ir-kbd-i2c.c
@@ -244,15 +244,17 @@ static void ir_key_poll(struct IR_i2c *ir)
static u32 ir_key, ir_raw;
int rc;
- dprintk(2,"ir_poll_key\n");
+ dprintk(3, "%s\n", __func__);
rc = ir->get_key(ir, &ir_key, &ir_raw);
if (rc < 0) {
dprintk(2,"error\n");
return;
}
- if (rc)
+ if (rc) {
+ dprintk(1, "%s: keycode = 0x%04x\n", __func__, ir_key);
rc_keydown(ir->rc, ir_key, 0);
+ }
}
static void ir_work(struct work_struct *work)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] em28xx: Fix IR support for WinTV USB2
Due to a lack of a break inside the switch, it were getting the wrong keytable and get_key function. Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/em28xx/em28xx-cards.c b/drivers/media/video/em28xx/em28xx-cards.c index 099d5df..ba03a44 100644 --- a/drivers/media/video/em28xx/em28xx-cards.c +++ b/drivers/media/video/em28xx/em28xx-cards.c @@ -2437,6 +2437,7 @@ void em28xx_register_i2c_ir(struct em28xx *dev) dev->init_data.ir_codes = RC_MAP_RC5_HAUPPAUGE_NEW; dev->init_data.get_key = em28xx_get_key_em_haup; dev->init_data.name = "i2c IR (EM2840 Hauppauge)"; + break; case EM2820_BOARD_LEADTEK_WINFAST_USBII_DELUXE: dev->init_data.ir_codes = RC_MAP_WINFAST_USBII_DELUXE; dev->init_data.get_key = em28xx_get_key_winfast_usbii_deluxe; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] rc-dib0700-nec: Fix keytable for Pixelview SBTVD
dib0700 now outputs NEC extended keycodes. Fix the keytable to reflect that.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/rc/keymaps/rc-dib0700-nec.c
b/drivers/media/rc/keymaps/rc-dib0700-nec.c
index c59851b..7a5f530 100644
--- a/drivers/media/rc/keymaps/rc-dib0700-nec.c
+++ b/drivers/media/rc/keymaps/rc-dib0700-nec.c
@@ -19,35 +19,35 @@
static struct rc_map_table dib0700_nec_table[] = {
/* Key codes for the Pixelview SBTVD remote */
- { 0x8613, KEY_MUTE },
- { 0x8612, KEY_POWER },
- { 0x8601, KEY_1 },
- { 0x8602, KEY_2 },
- { 0x8603, KEY_3 },
- { 0x8604, KEY_4 },
- { 0x8605, KEY_5 },
- { 0x8606, KEY_6 },
- { 0x8607, KEY_7 },
- { 0x8608, KEY_8 },
- { 0x8609, KEY_9 },
- { 0x8600, KEY_0 },
- { 0x860d, KEY_CHANNELUP },
- { 0x8619, KEY_CHANNELDOWN },
- { 0x8610, KEY_VOLUMEUP },
- { 0x860c, KEY_VOLUMEDOWN },
+ { 0x866b13, KEY_MUTE },
+ { 0x866b12, KEY_POWER },
+ { 0x866b01, KEY_1 },
+ { 0x866b02, KEY_2 },
+ { 0x866b03, KEY_3 },
+ { 0x866b04, KEY_4 },
+ { 0x866b05, KEY_5 },
+ { 0x866b06, KEY_6 },
+ { 0x866b07, KEY_7 },
+ { 0x866b08, KEY_8 },
+ { 0x866b09, KEY_9 },
+ { 0x866b00, KEY_0 },
+ { 0x866b0d, KEY_CHANNELUP },
+ { 0x866b19, KEY_CHANNELDOWN },
+ { 0x866b10, KEY_VOLUMEUP },
+ { 0x866b0c, KEY_VOLUMEDOWN },
- { 0x860a, KEY_CAMERA },
- { 0x860b, KEY_ZOOM },
- { 0x861b, KEY_BACKSPACE },
- { 0x8615, KEY_ENTER },
+ { 0x866b0a, KEY_CAMERA },
+ { 0x866b0b, KEY_ZOOM },
+ { 0x866b1b, KEY_BACKSPACE },
+ { 0x866b15, KEY_ENTER },
- { 0x861d, KEY_UP },
- { 0x861e, KEY_DOWN },
- { 0x860e, KEY_LEFT },
- { 0x860f, KEY_RIGHT },
+ { 0x866b1d, KEY_UP },
+ { 0x866b1e, KEY_DOWN },
+ { 0x866b0e, KEY_LEFT },
+ { 0x866b0f, KEY_RIGHT },
- { 0x8618, KEY_RECORD },
- { 0x861a, KEY_STOP },
+ { 0x866b18, KEY_RECORD },
+ { 0x866b1a, KEY_STOP },
/* Key codes for the EvolutePC TVWay+ remote */
{ 0x7a00, KEY_MENU },
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] dib0700: Fix IR keycode handling
Fixes Fedora 14 bug: https://bugzilla.redhat.com/show_bug.cgi?id=667157
There are a few bugs at the code that generates the scancode at dib0700:
- RC keycode is wrong (it outputs a 24 bits keycode);
- NEC extended outputs a keycode that have endiannes issues;
- keycode tables for NEC extended remotes need to be updated.
The last issue need to be done as we get reports, as we don't have
the complete NEC-extended keycodes at the dibcom table.
This patch fixes the first two issues.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 8ca48f7..98ffb40 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -514,8 +514,8 @@ struct dib0700_rc_response {
union {
u16 system16;
struct {
- u8 system;
u8 not_system;
+ u8 system;
};
};
u8 data;
@@ -575,7 +575,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
if ((poll_reply->system ^ poll_reply->not_system) != 0xff) {
deb_data("NEC extended protocol\n");
/* NEC extended code - 24 bits */
- keycode = poll_reply->system16 << 8 | poll_reply->data;
+ keycode = be16_to_cpu(poll_reply->system16) << 8 |
poll_reply->data;
} else {
deb_data("NEC normal protocol\n");
/* normal NEC code - 16 bits */
@@ -587,7 +587,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
deb_data("RC5 protocol\n");
/* RC5 Protocol */
toggle = poll_reply->report_id;
- keycode = poll_reply->system16 << 8 | poll_reply->data;
+ keycode = poll_reply->system << 8 | poll_reply->data;
break;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates
On 01/11/2011 10:57 PM, Mauro Carvalho Chehab wrote: > Em 03-01-2011 14:48, Sylwester Nawrocki escreveu: >> Hi Mauro, >> >> Please pull from our tree for the following items: >> >> 4. s5p-fimc driver conversion to Videbuf2 and multiplane ext. and various >> driver updates and bugfixes, >> 5. Siliconfile NOON010PC30 sensor subdev driver, > > Those patches seem ok. I have just a couple comments about them. See bellow. > > After having them solved, please send the patches against my vb2 test tree: > > git://linuxtv.org/mchehab/experimental.git vb2_test > > I've tested already vb2 with vivi. I'll be testing them now with saa7134. > After testing it, I'll give you a feedback about vb2 and, if ok, I'll merge > both multiplane and vb2 on my main tree. > >> Hyunwoong Kim (5): >>[media] s5p-fimc: fix the value of YUV422 1-plane formats > > I don't have an arm cross-compilation handy, but... that means that, before > this > patch, compilation were broken? If so, please, don't do that, as it breaks > bisect. > Instead, merge the patch withthe one that broke compilation. No, the purpose of this patch is to only change the values programmed into the H/W registers. The patch summary line seem not to be too accurate. This patch doesn't fix any compilation problems. I always try to test the patches against compilation breakage one by one. But this time unfortunately I didn't do enough tests of the mem2mem conversion changes when sending the pull request. Regards, Sylwester -- 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
RFC: Extending the format setting ioctls for raw image sensors
Introduction The image sensors used in camera phones are quite smart these days and thanks to the new Media Controller API they are now controlled as subdevs from userspace. SMIA++ compatible sensors support things like: - Cropping (both analog and digital) - Binning (analog summing of adjacent pixels = downscaling) - Subsampling or skipping (= moire-prone downscaling) - Another type of downscaling which is more flexible. There are a lot of other controls as well but handling these three are complicated enough for one discussion thread. It would be nice to just set some size via S_FMT and let the sensor driver figure it all out, but it is not that simple. Let's take a hypothetical 3 MP sensor as an example. The sensor area is 2048x1536. To produce different kinds of output sizes, the above parameters have to be set. For instance 2-by-2 binning would produce 1024x768 and 4-by-4 binning would produce 512x384. You could also use 4-by-2 binning and 1-by-2 subsampling to produce 512x384. Or you could use the more flexible scaler. Depending on what you choose, the image quality may be different, image timings will change and possibly even power consumption will change. Because of this, we want to give userspace full freedom to control every parameter of the sensor and keep the driver as simple and as generic as possible. I heard the FCam guys were doing something like this already but I don't know how much of a hack their system is. Problem with current API There are only two subdev pad ioctls to set these things: S_FMT for size and S_CROP for one type of crop only. More is needed or this interface has to be extended somehow to allow these controls to be set. The additions could be either new ioctls or new V4L2 controls. Constraints for new controls - Not all binning types are supported by all SMIA++ sensors. For instance only 1-by-1, 2-by-1 and 4-by-2 may be supported instead of continuously variable X-by-Y binning. - Subsampling takes 4 parameters: x,y even increment and x,y odd increment. This allows more flexibility in picking the bayer elements (the components of your output GRBG quad don't need to be next to each other on the sensor chip) - The downscaler in SMIA++ is weird. It only allows N/M downscaling where M is fixed at 16 and N >= 16. Example: setting N=17 on the abobe 3MP sensor would produce 1927x1445 (rounded) and N=32 would produce 1024x768 at the output. Perhaps using 16:16 or 8:24 fixed point for this control would be flexible enough? - The downscaler also has two modes: horizontal only and horizontal+vertical. There is no vertical only mode in SMIA++. In the H+V case the scale factor for both directions is the same. They cannot be set separately for SMIA++ sensors. Conclusion == So, how should the ioctls/controls for these parameters be created? Do we extend S_FMT with flag to set different "kinds" of formats or create new V4L2 controls? If new controls, how should they be arranged/named? We don't want to create yet another set of incompatible private ioctls. This stuff should be standardised and be as generic as possible so that other sensor types/drivers can use it as well. Comments? Regards, Antti Koskipää Nokia Corporation, MeeGo R&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
driver for Cinergy Hybrid T USB XS FM
Devin, driver for Cinergy Hybrid T USB XS FMis still planned to be developed, or you think it will notbe developedanymore? Thanks Adriano -- 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
CyberLink video grabber 2.0
Dear all, I have bought a CyberLink video grabber 2.0. when I put in the console the code lsusb,=20 the result is this: ID 1d19:6105 can you tell me what driver should I try? -- 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: Enable IR on hdpvr
>> >> Bah. Yeah, sorry, that wasn't the current patch in Fedora 14. This is: >> >> http://wilsonet.com/jarod/lirc_misc/hdpvr-ir/hdpvr-ir-enable-2.patch >> >> Its atop the F14 2.6.35.10 kernel, which has a fairly recent v4l/dvb >> backport on top of it, so it should be pretty close to matching the >> current v4l/dvb code... >With the help of Andy Walls and Jean Delvare, I think we've hashed out an >updated patch that will work sitting atop the current v4l/dvb hdpvr code, but >I'm only just now getting around to compile->testing it, and its past my >bedtime, so it'll be tomorrow before I can do any sort of functional testing >(but hey, due to the snow, I'll be working from home tomorrow, where my hdpvr >happens to be...). I've got two hdpvrs. Whenever you're ready to extend your testing, I'm happy to extend that functional testing. I didn't get a chance to look at the FC14 patch yet (busy couple of days), but I will hold off now, anyway! -- 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] dib7000m/p: struct alignment fix
Hi, this is basically a re-post of http://www.linuxtv.org/pipermail/linux-dvb/2010-September/032744.html which fixes an Oops when tuning eg. AVerMedia DVB-T Volar, Hauppauge Nova-T, Winfast DTV. it seems to be quite commonly reported on this list. [ 809.128579] BUG: unable to handle kernel NULL pointer dereference at 0012 [ 809.128586] IP: [] i2c_transfer+0x16/0x124 [i2c_core] [ 809.128598] PGD 669a7067 PUD 79e5f067 PMD 0 [ 809.128604] Oops: [#1] SMP [ 809.128608] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq [ 809.128612] CPU 0 [ 809.128614] Modules linked in: tcp_lp fuse coretemp hwmon_vid cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 xfs exportfs uinput mt2060 mxl5005s af9013 dvb_usb_dib0700 ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder dib7000p dib0090 dib7000m dvb_usb_af9015 dib0070 dvb_usb dib8000 dvb_core dib3000mc ir_rc6_decoder dibx000_common snd_hda_codec_intelhdmi ir_rc5_decoder snd_hda_codec_realtek snd_hda_intel ir_nec_decoder snd_hda_codec ldusb i2c_i801 snd_hwdep snd_seq snd_seq_device rc_core atl1 asus_atk0110 snd_pcm snd_timer mii snd soundcore snd_page_alloc iTCO_wdt iTCO_vendor_support microcode raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t pata_jmicron i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] [ 809.128692] [ 809.128696] Pid: 2525, comm: tzap Not tainted 2.6.35.10-72.fc14.x86_64 #1 P5E-VM HDMI/P5E-VM HDMI [ 809.128700] RIP: 0010:[] [] i2c_transfer+0x16/0x124 [i2c_core] [ 809.128708] RSP: 0018:880064a83ae8 EFLAGS: 00010296 [ 809.128712] RAX: 880064a83b58 RBX: 00eb RCX: [ 809.128715] RDX: 0002 RSI: 880064a83b38 RDI: 0002 [ 809.128718] RBP: 880064a83b28 R08: 880079bcf7c0 R09: 5d80 [ 809.128721] R10: 0005 R11: 4a38 R12: 0001 [ 809.128725] R13: R14: c900237e8000 R15: c90023907000 [ 809.128729] FS: 7f2ff2dd3720() GS:88000200() knlGS: [ 809.128732] CS: 0010 DS: ES: CR0: 80050033 [ 809.128736] CR2: 0012 CR3: 7830d000 CR4: 06f0 [ 809.128739] DR0: DR1: DR2: [ 809.128743] DR3: DR6: 0ff0 DR7: 0400 [ 809.128746] Process tzap (pid: 2525, threadinfo 880064a82000, task 8800379745c0) [ 809.128749] Stack: [ 809.128751] 880064a83af8 8103c142 880079c41a90 00eb [ 809.128757] <0> 0001 c900237e8000 c90023907000 [ 809.128762] <0> 880064a83b88 a0407124 00020030 880064a83b68 [ 809.128768] Call Trace: [ 809.128776] [] ? need_resched+0x23/0x2d [ 809.128783] [] dib7000p_read_word+0x6d/0xbc [dib7000p] [ 809.128789] [] ? usb_submit_urb+0x2f8/0x33a [ 809.128795] [] dib7000p_pid_filter_ctrl+0x2d/0x90 [dib7000p] [ 809.128802] [] stk70x0p_pid_filter_ctrl+0x19/0x1e [dvb_usb_dib0700] [ 809.128809] [] dvb_usb_ctrl_feed+0xd7/0x123 [dvb_usb] [ 809.128815] [] dvb_usb_start_feed+0x13/0x15 [dvb_usb] [ 809.128825] [] dmx_ts_feed_start_filtering+0x7d/0xd1 [dvb_core] [ 809.128833] [] dvb_dmxdev_start_feed.clone.1+0xbd/0xeb [dvb_core] [ 809.128841] [] dvb_dmxdev_filter_start+0x2cf/0x31b [dvb_core] [ 809.128847] [] ? _raw_spin_lock_irq+0x1f/0x21 [ 809.128854] [] dvb_demux_do_ioctl+0x27b/0x4c0 [dvb_core] [ 809.128859] [] ? should_resched+0xe/0x2e [ 809.128867] [] dvb_usercopy+0xe4/0x16b [dvb_core] [ 809.128874] [] ? dvb_demux_do_ioctl+0x0/0x4c0 [dvb_core] [ 809.128881] [] ? inode_has_perm.clone.20+0x79/0x8f [ 809.128886] [] ? remove_wait_queue+0x35/0x41 [ 809.128891] [] ? _raw_spin_unlock_irqrestore+0x17/0x19 [ 809.128898] [] dvb_demux_ioctl+0x15/0x19 [dvb_core] [ 809.128903] [] vfs_ioctl+0x36/0xa7 [ 809.128908] [] do_vfs_ioctl+0x468/0x49b [ 809.128912] [] sys_ioctl+0x56/0x79 [ 809.128917] [] system_call_fastpath+0x16/0x1b [ 809.128920] Code: 89 55 f8 48 83 c7 58 48 c7 c2 47 32 01 a0 e8 92 09 2c e1 c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 <48> 8b 47 10 48 89 fb 49 89 f6 41 89 d7 48 83 38 00 0f 84 92 00 [ 809.128965] RIP [] i2c_transfer+0x16/0x124 [i2c_core] [ 809.128973] RSP [ 809.128975] CR2: 0012 [ 809.128979] ---[ end trace 6919129d55f94398 ]--- this Oops occurs for me on all >2.6.32 kernels, including the current linux-media dvb git tree, and Fedora (13,14) kernels. Ubuntu has a bug open for the issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/654791 but the disable pid filtering workaround one person uses there doesn't work f
Re: OMAP3 ISP and tvp5151 driver.
Hi Enric, On Wednesday 12 January 2011 12:58:04 Enric Balletbò i Serra wrote: > Hi all, > > As explained in my first mail I would like port the tvp515x driver to > new media framework, I'm a newbie with the v4l2 API and of course with > the new media framework API, so sorry if next questions are stupid or > trivial (please, patience with me). > > My idea is follow this link schem: > > --- > > - || | 1 > > | --> | OMAP3 ISP CCDC OUTPUT | > | TVP515x | 0 | -> | 0 | OMAP3 ISP CCDC --- | > > > || | 2 | > --- ASCII art would look much better if you drew it in a non-proportional font, with 80 character per line at most. > Where: > * TVP515x is /dev/v4l-subdev8 c 81 15 > * OMAP3 ISP CCDC is /dev/v4l-subdev2 c 81 4 > * OMAP3 ISP CCDC OUTPUT is /dev/video2 c 81 5 > > Then activate these links with > > ./media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 > ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' > Resetting all links to disabled > Setting up link 16:0 -> 5:0 [1] > Setting up link 5:1 -> 6:0 [1] > > I'm on the right way or I'm completely lost ? That's correct. > I think the next step is adapt the tvp515x driver to new media > framework, I'm not sure how to do this, someone can give some points ? You need to implement subdev pad operations. get_fmt and set_fmt are required. > Once this is done, I suppose I can test using gstreamer, for example > using something like this. > >gst-launch v4l2src device=/dev/video2 ! ffmpegcolorspace ! xvimagesink > > I'm right in this point ? You need to specify the format explicitly. It must be identical to the format configured on pad CCDC:1. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 ISP and tvp5151 driver.
Hi all, As explained in my first mail I would like port the tvp515x driver to new media framework, I'm a newbie with the v4l2 API and of course with the new media framework API, so sorry if next questions are stupid or trivial (please, patience with me). My idea is follow this link schem: --- - || | 1 | --> | OMAP3 ISP CCDC OUTPUT | | TVP515x | 0 | -> | 0 | OMAP3 ISP CCDC --- | || | 2 | --- Where: * TVP515x is /dev/v4l-subdev8 c 81 15 * OMAP3 ISP CCDC is /dev/v4l-subdev2 c 81 4 * OMAP3 ISP CCDC OUTPUT is /dev/video2 c 81 5 Then activate these links with ./media-ctl -r -l '"tvp5150 2-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' Resetting all links to disabled Setting up link 16:0 -> 5:0 [1] Setting up link 5:1 -> 6:0 [1] I'm on the right way or I'm completely lost ? I think the next step is adapt the tvp515x driver to new media framework, I'm not sure how to do this, someone can give some points ? Once this is done, I suppose I can test using gstreamer, for example using something like this. gst-launch v4l2src device=/dev/video2 ! ffmpegcolorspace ! xvimagesink I'm right in this point ? Any help will be apreciated. Thanks in advance, Enric 2010/12/28 Laurent Pinchart : > Hi Enric, > > On Monday 27 December 2010 17:24:13 Enric Balletbò i Serra wrote: >> Hello all, >> >> I'm new on media and camera, I try to use the OMAP3 ISP driver on >> OMAP3530 with media framework. I've a TVP5151 connected on ISP port >> though the parallel interface on own custom board >> >> Against which repository/branch should I start the development ? > > The most up-to-date code is located in the media-0004-omap3isp branch of the > http://git.linuxtv.org/pinchartl/media.git repository. > >> Should I port tvp5150 driver to new tvp5151 device and new media >> framework ? > > That would be great :-) > >> Any driver as reference ? > > The MT9T001 and MT9V032 drivers in the media-0005-sensors branch. I haven't > tested the MT9T001 driver recently, so my advice would be to use the MT9V032 > driver. > >> Hopefully, somebody can give me some tips. Thanks > > -- > Regards, > > Laurent Pinchart > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Fix capture issues for non 8-bit per pixel formats
If the camera was set to output formats like RGB565 YUYV or SBGGR10,
the resulting image was scrambled due to erroneous interpretations of
horizontal parameter's units.
This patch in fourcc_to_ipu_pix, eliminate also the pixel formats mappings
that, first are not used within mainline code and second, standing at
the datasheets, they will not work properly:
The IPU internal bus support only the following data formatting
(44.1.1.3 Data Flows and Formats):
1 YUV 4:4:4 or RGB-8 bits per color component
2 YUV 4:4:4 or RGB-10 bits per color component
3 Generic data (from sensor to the system memory only)
And format conversions are done:
- from memory: de-packing from other formats to IPU supported ones
- to memory: packing in the inverse order.
So, assigning a packing/depacking strategy to the IPU for that formats
will produce a packing to memory and not the inverse.
In the end in mx3_camera_get_formats, is fixed an erroneous debug message
that try to shows info from an invalid xlate pointer.
Signed-off-by: Alberto Panizzo
---
drivers/media/video/mx3_camera.c | 66 +
1 files changed, 51 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index b9cb4a4..6b9d019 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -324,14 +324,10 @@ static enum pixel_fmt fourcc_to_ipu_pix(__u32 fourcc)
{
/* Add more formats as need arises and test possibilities appear... */
switch (fourcc) {
- case V4L2_PIX_FMT_RGB565:
- return IPU_PIX_FMT_RGB565;
case V4L2_PIX_FMT_RGB24:
return IPU_PIX_FMT_RGB24;
- case V4L2_PIX_FMT_RGB332:
- return IPU_PIX_FMT_RGB332;
- case V4L2_PIX_FMT_YUV422P:
- return IPU_PIX_FMT_YVU422P;
+ case V4L2_PIX_FMT_UYVY:
+ case V4L2_PIX_FMT_RGB565:
default:
return IPU_PIX_FMT_GENERIC;
}
@@ -359,9 +355,31 @@ static void mx3_videobuf_queue(struct videobuf_queue *vq,
/* This is the configuration of one sg-element */
video->out_pixel_fmt= fourcc_to_ipu_pix(fourcc);
- video->out_width= icd->user_width;
- video->out_height = icd->user_height;
- video->out_stride = icd->user_width;
+
+ if (video->out_pixel_fmt == IPU_PIX_FMT_GENERIC) {
+ /*
+* If the IPU DMA channel is configured to transport
+* generic 8-bit data, we have to set up correctly the
+* geometry parameters upon the current pixel format.
+* So, since the DMA horizontal parameters are expressed
+* in bytes not pixels, convert these in the right unit.
+*/
+ int bytes_per_line = soc_mbus_bytes_per_line(icd->user_width,
+ icd->current_fmt->host_fmt);
+ BUG_ON(bytes_per_line <= 0);
+
+ video->out_width= bytes_per_line;
+ video->out_height = icd->user_height;
+ video->out_stride = bytes_per_line;
+ } else {
+ /*
+* For IPU known formats the pixel unit will be managed
+* successfully by the IPU code
+*/
+ video->out_width= icd->user_width;
+ video->out_height = icd->user_height;
+ video->out_stride = icd->user_width;
+ }
#ifdef DEBUG
/* helps to see what DMA actually has written */
@@ -734,18 +752,36 @@ static int mx3_camera_get_formats(struct
soc_camera_device *icd, unsigned int id
if (xlate) {
xlate->host_fmt = fmt;
xlate->code = code;
+ dev_dbg(dev, "Providing format %c%c%c%c in pass-through mode\n",
+ (fmt->fourcc >> (0*8)) & 0xFF,
+ (fmt->fourcc >> (1*8)) & 0xFF,
+ (fmt->fourcc >> (2*8)) & 0xFF,
+ (fmt->fourcc >> (3*8)) & 0xFF);
xlate++;
- dev_dbg(dev, "Providing format %x in pass-through mode\n",
- xlate->host_fmt->fourcc);
}
return formats;
}
static void configure_geometry(struct mx3_camera_dev *mx3_cam,
- unsigned int width, unsigned int height)
+ unsigned int width, unsigned int height,
+ enum v4l2_mbus_pixelcode code)
{
u32 ctrl, width_field, height_field;
+ const struct soc_mbus_pixelfmt *fmt;
+
+ fmt = soc_mbus_get_fmtdesc(code);
+ BUG_ON(!fmt);
+
+ if (fourcc_to_ipu_pix(fmt->fourcc) == IPU_PIX_FMT_GENERIC) {
+ /*
+* As the CSI will be configured to output BAYER, here
+* the width parameter count the number of samples to
+
[PATCH 1/2] soc_mediabus: export a useful method to obtain the number of samples that makes up a pixel format
Signed-off-by: Alberto Panizzo
---
drivers/media/video/soc_mediabus.c | 14 ++
include/media/soc_mediabus.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/soc_mediabus.c
b/drivers/media/video/soc_mediabus.c
index 9139121..5bba424 100644
--- a/drivers/media/video/soc_mediabus.c
+++ b/drivers/media/video/soc_mediabus.c
@@ -132,6 +132,20 @@ static const struct soc_mbus_pixelfmt mbus_fmt[] = {
},
};
+s32 soc_mbus_samples_per_pixel(const struct soc_mbus_pixelfmt *mf)
+{
+ switch (mf->packing) {
+ case SOC_MBUS_PACKING_NONE:
+ case SOC_MBUS_PACKING_EXTEND16:
+ return 1;
+ case SOC_MBUS_PACKING_2X8_PADHI:
+ case SOC_MBUS_PACKING_2X8_PADLO:
+ return 2;
+ }
+ return -EINVAL;
+}
+EXPORT_SYMBOL(soc_mbus_samples_per_pixel);
+
s32 soc_mbus_bytes_per_line(u32 width, const struct soc_mbus_pixelfmt *mf)
{
switch (mf->packing) {
diff --git a/include/media/soc_mediabus.h b/include/media/soc_mediabus.h
index 037cd7b..f21cbd0 100644
--- a/include/media/soc_mediabus.h
+++ b/include/media/soc_mediabus.h
@@ -61,5 +61,6 @@ struct soc_mbus_pixelfmt {
const struct soc_mbus_pixelfmt *soc_mbus_get_fmtdesc(
enum v4l2_mbus_pixelcode code);
s32 soc_mbus_bytes_per_line(u32 width, const struct soc_mbus_pixelfmt *mf);
+s32 soc_mbus_samples_per_pixel(const struct soc_mbus_pixelfmt *mf);
#endif
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix the way mx3_camera manage non 8-bpp pixel formats
This patch series enable the mx3_camera driver to manage correctly pixel formats like RGB565 UYVY and SBGGR10 This patch series applies to the staging/for_2.6.38-rc1 and I hope it will reach the mainline in one of the .38-rcN Best regards, Alberto! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PATCHES FOR 2.6.38] Videbuf2 framework, NOON010PC30 sensor driver and s5p-fimc updates
Hello Mauro,
I've rebased our fimc and saa patches onto
http://linuxtv.org/git/mchehab/experimental.git
vb2_test branch.
The last 2 patches are for SAA7134 driver and are only to show that
videobuf2-dma-sg works
correctly.
The following changes since commit 15af3ad8cafe8028f09d1b6c014bb2e997937694:
[media] vb2 core: Fix a few printk warnings (2011-01-11 18:19:24 -0200)
are available in the git repository at:
git://git.infradead.org/users/kmpark/linux-2.6-samsung vb2_test
Andrzej Pietrasiewicz (2):
v4l: saa7134: remove radio, vbi, mpeg, input, alsa, tvaudio, saa6752hs
support
v4l: saa7134: quick and dirty port to videobuf2
Hyunwoong Kim (5):
[media] s5p-fimc: fix the value of YUV422 1-plane formats
[media] s5p-fimc: Configure scaler registers depending on FIMC version
[media] s5p-fimc: update checking scaling ratio range
[media] s5p-fimc: Support stop_streaming and job_abort
[media] s5p-fimc: fix MSCTRL.FIFO_CTRL for performance enhancement
Marek Szyprowski (2):
v4l: mem2mem: port to videobuf2
v4l: mem2mem: port m2m_testdev to vb2
Pawel Osciak (2):
Fix mmap() example in the V4L2 API DocBook
Add multi-planar API documentation
Sungchun Kang (1):
[media] s5p-fimc: fimc_stop_capture bug fix
Sylwester Nawrocki (14):
v4l: Add multiplanar format fourccs for s5p-fimc driver
v4l: Add DocBook documentation for YU12M, NV12M image formats
[media] s5p-fimc: Porting to videobuf 2
[media] s5p-fimc: Conversion to multiplanar formats
[media] s5p-fimc: Use v4l core mutex in ioctl and file operations
[media] s5p-fimc: Rename s3c_fimc* to s5p_fimc*
[media] s5p-fimc: Derive camera bus width from mediabus pixelcode
[media] s5p-fimc: Enable interworking without subdev s_stream
[media] s5p-fimc: Use default input DMA burst count
[media] s5p-fimc: Enable simultaneous rotation and flipping
[media] s5p-fimc: Add control of the external sensor clock
[media] s5p-fimc: Move scaler details handling to the register API file
[media] Add chip identity for NOON010PC30 camera sensor
[media] Add v4l2 subdev driver for NOON010PC30L image sensor
Documentation/DocBook/media-entities.tmpl |8 +
Documentation/DocBook/v4l/common.xml |2 +
Documentation/DocBook/v4l/compat.xml | 11 +
Documentation/DocBook/v4l/dev-capture.xml | 13 +-
Documentation/DocBook/v4l/dev-output.xml | 13 +-
Documentation/DocBook/v4l/func-mmap.xml | 10 +-
Documentation/DocBook/v4l/func-munmap.xml |3 +-
Documentation/DocBook/v4l/io.xml | 287 -
Documentation/DocBook/v4l/pixfmt-nv12m.xml| 154 +++
Documentation/DocBook/v4l/pixfmt-yuv420m.xml | 162 +++
Documentation/DocBook/v4l/pixfmt.xml | 118 ++-
Documentation/DocBook/v4l/planar-apis.xml | 81 ++
Documentation/DocBook/v4l/v4l2.xml| 21 +-
Documentation/DocBook/v4l/vidioc-enum-fmt.xml |2 +
Documentation/DocBook/v4l/vidioc-g-fmt.xml| 15 +-
Documentation/DocBook/v4l/vidioc-qbuf.xml | 24 +-
Documentation/DocBook/v4l/vidioc-querybuf.xml | 14 +-
Documentation/DocBook/v4l/vidioc-querycap.xml | 24 +-
drivers/media/video/Kconfig | 12 +-
drivers/media/video/Makefile |1 +
drivers/media/video/mem2mem_testdev.c | 227 ++---
drivers/media/video/noon010pc30.c | 792 ++
drivers/media/video/s5p-fimc/fimc-capture.c | 550 ++
drivers/media/video/s5p-fimc/fimc-core.c | 872 ---
drivers/media/video/s5p-fimc/fimc-core.h | 134 ++--
drivers/media/video/s5p-fimc/fimc-reg.c | 199 ++--
drivers/media/video/s5p-fimc/regs-fimc.h | 29 +-
drivers/media/video/saa7134/Kconfig |2 +-
drivers/media/video/saa7134/Makefile |8 +-
drivers/media/video/saa7134/saa7134-cards.c | 1415 +
drivers/media/video/saa7134/saa7134-core.c| 466 +++--
drivers/media/video/saa7134/saa7134-video.c | 854 ++--
drivers/media/video/saa7134/saa7134.h | 48 +-
drivers/media/video/v4l2-mem2mem.c| 232 ++--
include/linux/videodev2.h |7 +
include/media/noon010pc30.h | 28 +
include/media/{s3c_fimc.h => s5p_fimc.h} | 20 +-
include/media/v4l2-chip-ident.h |3 +
include/media/v4l2-mem2mem.h | 56 +-
39 files changed, 3961 insertions(+), 2956 deletions(-)
create mode 100644 Documentation/DocBook/v4l/pixfmt-nv12m.xml
create mode 100644 Documentation/DocBook/v4l/pixfmt-yuv420m.xml
create mode 100644 Documentation/DocBook/v4l/planar-apis.xml
create mode 100644 drivers/media/video/noon010pc30.c
create mode 100644 include/media/noon010pc30.h
rename include/media/{s3c_fimc.h => s5p_fimc.h} (75%)
--
To unsubscribe from this list: send the line "unsubscribe linux-me
Re: [RFC] Cropping and scaling with subdev pad-level operations
Hi Sylwester, On Wednesday 12 January 2011 00:31:26 Sylwester Nawrocki wrote: > On 01/06/2011 04:33 PM, Laurent Pinchart wrote: [snip] > > When the stream is off, we have two options: > > > > - Handle crop rectangle modifications the same way as when the stream is > > on. This is cleaner, but bring one drawback. The user can't set the crop > > rectangle to 500x500 and output size to 750x750 directly. No matter > > whether the crop rectangle or output size is set first, the intermediate > > 500x5000/4000x4000 or 4000x4000/750x750 combination are invalid. An > > extra step will be needed: the crop rectangle will first be set to > > 1000x1000, the output size will then be set to 750x750, and the crop > > rectangle will finally be set to 500x500. That won't make life easy for > > userspace applications. > > > > - Modify the output size when the crop rectangle is set. With this > > option, the output size is automatically set to the crop rectangle size > > when the crop rectangle is changed. With the above example, setting the > > crop rectangle to 500x500 will automatically set the output size to > > 500x500, and the user will then just have to set the output size to > > 750x750. > > IMO, with the second option at some point it might get difficult to > determine in the application which parameters in the driver may change > when the application tries to change some parameter. I would expect the > side effects to be as local as possible so the application could possibly > get notified about them without additional steps. I quite agree with that. Otherwise applications will need to guess what the side effects are, and they will end up hardcoding behaviours depending on the device model. That's bad. > > The second option has a major drawback as well, as there's no way for > > applications to query the minimum/maximum zoom factor. With the first > > option an application can set the desired output size, and then set a > > very small crop rectangle to retrieve the minimum allowed crop rectangle > > (and thus the maximum zoom factor). With the second option the output > > size will be changed when the crop rectangle is set, so this isn't > > possible anymore. > > > > Retrieving the maximum zoom factor in the stream off state is an > > application requirement to be able to display the zoom level on a GUI > > (with a slider for instance). > > In the Samsung S5P FIMC driver minimum and maximum scaling ratios are 1/64 > and 64. So the scaling limits bite a bit less than in your case in typical > applications, the problem remains still same though. > The driver uses the v4l2 mem-to-mem framework so it may be considered much > as your resizer example with an input and output pad. The FIMC H/W supports > cropping at the scaler input and also an effective output rectangle can be > positioned within the output buffer. The latter allows e.g. placing the > video window at the arbitrary position on a framebuffer. > > Currently, with the mem-to-mem driver the application is required to set > the format at the device input and output first (V4L2_BUF_TYPE_OUTPUT and > *_CAPTURE stream respectively). The relation between both image formats, > i.e. scaling ratio was not being checked in s_fmt because it also depended > on whether the rotator was enabled or not. So the check was postponed to > actual transaction setup/start. This seems wrong to me and I want to change > it so the scaler limits are checked in try/set_fmt, try/set_crop > and s_control(ROTATION). > > Then when the crop rectangle is set it is being checked for the scaling > ratio limit against current crop/full window size at the opposite side > of the scaler. When a scaling ratio is not within the supported range an > error is returned. The crop window is adjusted in s_crop only when the > device's alignment requirements would not have been fulfilled. But I am > going to change that so the crop rectangle is adjusted according to the > resizer limits as well, without changing the effective image size at the > opposite side of the scaler. So that's option number 1. I think it's the best one (unless we can find a better option 3, such as setting formats and crop rectangles on multiple pads atomically). > > The OMAP3 ISP resizer currently implements the second option, and I'll > > modify it to implement the first option. The drawback is that some > > crop/output combinations will require an extra step to be achieved. I'd > > like your opinion on this issue. Is the behaviour described in option > > one acceptable ? Should the API be extended/modified to make it simpler > > for applications to configure the various sizes in the image pipeline ? > > Are we all doomed and will we have > > Not sure if it is a good idea, but with the introduction of the pad > operations maybe it is worth to introduce some flags to vidioc_try/s_crop > selecting the exact behavior? However current struct v4l2_crop is rather > resistant to any backward compatible extensions. I'
Re: [RFC] Cropping and scaling with subdev pad-level operations
Hi, On Tuesday 11 January 2011 20:06:52 Eino-Ville Talvala wrote: > On 1/6/2011 7:33 AM, Laurent Pinchart wrote: > > Hi everybody, > > ... > > > The OMAP3 ISP resizer currently implements the second option, and I'll > > modify it to implement the first option. The drawback is that some > > crop/output combinations will require an extra step to be achieved. I'd > > like your opinion on this issue. Is the behaviour described in option > > one acceptable ? Should the API be extended/modified to make it simpler > > for applications to configure the various sizes in the image pipeline ? > > Are we all doomed and will we have to use a crop/scale API that nobody > > will ever understand ? :-) > > I'm personally a big fan of having some way to atomically set multiple > settings at once, exactly to avoid these sorts of problems. The > fundamental problem here is that the interface implicitly assumes that > every intermediate state has to be a valid one, when during device > configuration most states are transitory because the application hasn't > finished configuring the pipeline/sensor/etc, and the state shouldn't > get vetted and adjusted until the configuration is complete. Agreed, that's the exact cause of the problem. > The VIDOC_S_EXT_CTRLS seems like a reasonable solution - can't something > like that apply to the subdev interfaces? (Or am I missing something > beyond that?) I haven't thought about setting multiple formats in one go, but the idea is definitely worth a thought. It shouldn't be too difficult to implement, but we need to define proper semantics. I'd like to hear about other's opinions. > Similar issues have cropped up for us with other interdependent settings > like exposure time/frame duration, or the cropping/scaling options found > directly on the mt9p031 sensor, which are quite analogous to your issue > - there's 1-4x scaling and a selectable ROI, which interact, especially > during streaming when a constant output size has to be maintained. What > I ended up doing was effectively hacking in an atomic control update > procedure for the old v4l2_int_device stuff (very hacky), but then I > didn't have to worry about it any more. > > In general, I'd be worried if executing the same stream of control > updates in a different order gave a different final result. With atomic > updates, you'd still have to decide how to round to the closest valid > state, but at least it'd be consistent. Thanks a lot for sharing your thoughts. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
