[RFC PATCH] Rename video_device et al to v4l2_devnode
Most of the v4l2 framework has prefixes that start with v4l2_ except for struct video_device in v4l2-dev.c. This name is becoming very confusing since it closely resembles struct v4l2_device. Since video_device really represents a v4l2 device node I propose to rename it to v4l2_devnode and rename the v4l2-dev.[ch] to v4l2-devnode.[ch]. To make the transition easier I created a v4l2-dev.h that includes the new v4l2-devnode.h and #defines the old names to the new names. I also updated the documentation to reflect the new header and naming convention. The patches are here: http://git.linuxtv.org/hverkuil/v4l-dvb.git?a=shortlog;h=refs/heads/v4l2-devnode Hans Verkuil (18): v4l2-devnode: renamed from v4l2-dev videodev2.h: update comment v4l2 core: use v4l2-devnode.h instead of v4l2-dev.h v4l2: rename to_video_device to v4l2_devnode_from_device v4l2: rename video_device_alloc to v4l2_devnode_alloc v4l2: rename video_device_release_empty to v4l2_devnode_release_empty v4l2: rename video_device_release to v4l2_devnode_release v4l2: rename video_device_node_name to v4l2_devnode_name v4l2: rename video_register_device to v4l2_devnode_register v4l2: rename video_unregister_device to v4l2_devnode_unregister v4l2: rename video_is_registered to v4l2_devnode_is_registered v4l2: rename video_get/set_drvdata to v4l2_devnode_get/set_drvdata v4l2: rename video_devdata to v4l2_devnode_from_file v4l2: rename video_drvdata to v4l2_drvdata_from_file v4l2: rename video_device to v4l2_devnode tea575x: convert to v4l2-devnode.h v4l2: include v4l2-devnode.h instead of v4l2-dev.h v4l2: issue warning if v4l2-dev.h is included After converting all drivers I added a warning to v4l2-dev.h when it is used. This header can be removed completely after this series has been merged in the mainline 2.6.37 kernel. It's all pretty trivial but I think the new names are much more understandable and fit well within the v4l2 framework API. Comments? Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Rename video_device et al to v4l2_devnode
Sounds good to me. I'm not to sure why you even bothered with the backward compat on the names. I think it can only lead to trouble; but it does make merging out standing patchsets easier I guess. I haven't looked at the patchset, are there any other users outside the drivers/media tree? R, Andy Hans Verkuil hverk...@xs4all.nl wrote: Most of the v4l2 framework has prefixes that start with v4l2_ except for struct video_device in v4l2-dev.c. This name is becoming very confusing since it closely resembles struct v4l2_device. Since video_device really represents a v4l2 device node I propose to rename it to v4l2_devnode and rename the v4l2-dev.[ch] to v4l2-devnode.[ch]. To make the transition easier I created a v4l2-dev.h that includes the new v4l2-devnode.h and #defines the old names to the new names. I also updated the documentation to reflect the new header and naming convention. The patches are here: http://git.linuxtv.org/hverkuil/v4l-dvb.git?a=shortlog;h=refs/heads/v4l2-devnode Hans Verkuil (18): v4l2-devnode: renamed from v4l2-dev videodev2.h: update comment v4l2 core: use v4l2-devnode.h instead of v4l2-dev.h v4l2: rename to_video_device to v4l2_devnode_from_device v4l2: rename video_device_alloc to v4l2_devnode_alloc v4l2: rename video_device_release_empty to v4l2_devnode_release_empty v4l2: rename video_device_release to v4l2_devnode_release v4l2: rename video_device_node_name to v4l2_devnode_name v4l2: rename video_register_device to v4l2_devnode_register v4l2: rename video_unregister_device to v4l2_devnode_unregister v4l2: rename video_is_registered to v4l2_devnode_is_registered v4l2: rename video_get/set_drvdata to v4l2_devnode_get/set_drvdata v4l2: rename video_devdata to v4l2_devnode_from_file v4l2: rename video_drvdata to v4l2_drvdata_from_file v4l2: rename video_device to v4l2_devnode tea575x: convert to v4l2-devnode.h v4l2: include v4l2-devnode.h instead of v4l2-dev.h v4l2: issue warning if v4l2-dev.h is included After converting all drivers I added a warning to v4l2-dev.h when it is used. This header can be removed completely after this series has been merged in the mainline 2.6.37 kernel. It's all pretty trivial but I think the new names are much more understandable and fit well within the v4l2 framework API. Comments? Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Rename video_device et al to v4l2_devnode
On Sunday, September 26, 2010 14:17:48 Andy Walls wrote: Sounds good to me. I'm not to sure why you even bothered with the backward compat on the names. I think it can only lead to trouble; but it does make merging out standing patchsets easier I guess. It made the patches easier to do. Otherwise I would have to make one huge patch. Also upstream merging should be simplified if someone added new v4l drivers to staging that we don't have in our tree yet. Once it is upstreamed the compat header will be removed. I haven't looked at the patchset, are there any other users outside the drivers/media tree? UVC gadget drivers in usb/gadget and a v4l2 driver in sound/ (a radio tuner that's part of a sound card). And the v4l2 drivers in drivers/staging of course. Regards, Hans R, Andy Hans Verkuil hverk...@xs4all.nl wrote: Most of the v4l2 framework has prefixes that start with v4l2_ except for struct video_device in v4l2-dev.c. This name is becoming very confusing since it closely resembles struct v4l2_device. Since video_device really represents a v4l2 device node I propose to rename it to v4l2_devnode and rename the v4l2-dev.[ch] to v4l2-devnode.[ch]. To make the transition easier I created a v4l2-dev.h that includes the new v4l2-devnode.h and #defines the old names to the new names. I also updated the documentation to reflect the new header and naming convention. The patches are here: http://git.linuxtv.org/hverkuil/v4l-dvb.git?a=shortlog;h=refs/heads/v4l2-devnode Hans Verkuil (18): v4l2-devnode: renamed from v4l2-dev videodev2.h: update comment v4l2 core: use v4l2-devnode.h instead of v4l2-dev.h v4l2: rename to_video_device to v4l2_devnode_from_device v4l2: rename video_device_alloc to v4l2_devnode_alloc v4l2: rename video_device_release_empty to v4l2_devnode_release_empty v4l2: rename video_device_release to v4l2_devnode_release v4l2: rename video_device_node_name to v4l2_devnode_name v4l2: rename video_register_device to v4l2_devnode_register v4l2: rename video_unregister_device to v4l2_devnode_unregister v4l2: rename video_is_registered to v4l2_devnode_is_registered v4l2: rename video_get/set_drvdata to v4l2_devnode_get/set_drvdata v4l2: rename video_devdata to v4l2_devnode_from_file v4l2: rename video_drvdata to v4l2_drvdata_from_file v4l2: rename video_device to v4l2_devnode tea575x: convert to v4l2-devnode.h v4l2: include v4l2-devnode.h instead of v4l2-dev.h v4l2: issue warning if v4l2-dev.h is included After converting all drivers I added a warning to v4l2-dev.h when it is used. This header can be removed completely after this series has been merged in the mainline 2.6.37 kernel. It's all pretty trivial but I think the new names are much more understandable and fit well within the v4l2 framework API. Comments? Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.37] Move V4L2 locking into the core framework
Hi Mauro, These are the locking patches. It's based on my previous test tree, but with more testing with em28xx and radio-mr800 and some small tweaks relating to disconnect handling and video_is_registered(). I also removed the unused get_unmapped_area file op and I am now blocking any further (unlocked_)ioctl calls after the device node is unregistered. The only things an application can do legally after a disconnect is unmap() and close(). This patch series also contains a small em28xx fix that I found while testing the em28xx BKL removal patch. Regards, Hans The following changes since commit dace3857de7a16b83ae7d4e13c94de8e4b267d2a: Hans Verkuil (1): V4L/DVB: tvaudio: remove obsolete tda8425 initialization are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git bkl Hans Verkuil (10): v4l2-dev: after a disconnect any ioctl call will be blocked. v4l2-dev: remove get_unmapped_area v4l2: add core serialization lock. videobuf: prepare to make locking optional in videobuf videobuf: add ext_lock argument to the queue init functions videobuf: add queue argument to videobuf_waiton() vivi: remove BKL. em28xx: remove BKL. em28xx: the default std was not passed on to the subdevs radio-mr800: remove BKL Documentation/video4linux/v4l2-framework.txt | 25 +- drivers/media/common/saa7146_fops.c |2 +- drivers/media/common/saa7146_vbi.c|2 +- drivers/media/common/saa7146_video.c |2 +- drivers/media/radio/radio-mr800.c | 74 ++-- drivers/media/video/au0828/au0828-video.c |4 +- drivers/media/video/bt8xx/bttv-driver.c |4 +- drivers/media/video/bt8xx/bttv-risc.c |2 +- drivers/media/video/cx231xx/cx231xx-video.c |6 +- drivers/media/video/cx23885/cx23885-417.c |2 +- drivers/media/video/cx23885/cx23885-core.c|2 +- drivers/media/video/cx23885/cx23885-dvb.c |2 +- drivers/media/video/cx23885/cx23885-video.c |2 +- drivers/media/video/cx88/cx88-blackbird.c |2 +- drivers/media/video/cx88/cx88-core.c |2 +- drivers/media/video/cx88/cx88-dvb.c |2 +- drivers/media/video/cx88/cx88-video.c |4 +- drivers/media/video/em28xx/em28xx-video.c | 93 +++-- drivers/media/video/fsl-viu.c |2 +- drivers/media/video/mx1_camera.c |2 +- drivers/media/video/mx2_camera.c |2 +- drivers/media/video/mx3_camera.c |2 +- drivers/media/video/omap24xxcam.c |2 +- drivers/media/video/pxa_camera.c |2 +- drivers/media/video/s2255drv.c|2 +- drivers/media/video/saa7134/saa7134-core.c|2 +- drivers/media/video/saa7134/saa7134-dvb.c |2 +- drivers/media/video/saa7134/saa7134-empress.c |2 +- drivers/media/video/saa7134/saa7134-video.c |4 +- drivers/media/video/sh_mobile_ceu_camera.c|2 +- drivers/media/video/sh_vou.c |2 +- drivers/media/video/v4l2-dev.c| 110 ++-- drivers/media/video/v4l2-event.c |9 ++- drivers/media/video/v4l2-mem2mem.c|8 +- drivers/media/video/videobuf-core.c | 115 +++-- drivers/media/video/videobuf-dma-contig.c |9 +- drivers/media/video/videobuf-dma-sg.c |9 +- drivers/media/video/videobuf-dvb.c|2 +- drivers/media/video/videobuf-vmalloc.c|9 +- drivers/media/video/vivi.c| 17 ++-- drivers/media/video/zr364xx.c |2 +- drivers/staging/cx25821/cx25821-core.c|2 +- drivers/staging/cx25821/cx25821-video.c |2 +- drivers/staging/dt3155v4l/dt3155v4l.c |8 +- drivers/staging/tm6000/tm6000-video.c |2 +- include/media/v4l2-dev.h |5 +- include/media/videobuf-core.h | 19 - include/media/videobuf-dma-contig.h |3 +- include/media/videobuf-dma-sg.h |3 +- include/media/videobuf-vmalloc.h |3 +- 50 files changed, 282 insertions(+), 315 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Yakumo QuickStick DVB-T doesn't load firmware (SOLVED)
On Thu, Sep 23, 2010 at 12:56:23PM +0200, Petr Tomasek wrote: Hello! My Yakumo QuickStick suddenly stopped to work. It now doesn't load the firmware (i.e. it stays cold): XXX kernel: usb 1-3: new high speed USB device using ehci_hcd and address 10 XXX kernel: usb 1-3: New USB device found, idVendor=14ee, idProduct=0225 XXX kernel: usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 XXX dalet kernel: usb 1-3: configuration #1 chosen from 1 choice (I tried it on two systems, where it worked before. All Firmware files are in /lib/firmware). Is there anything I could do? Can I debug what's going on somehow? My current kernel: $ uname -a Linux dalet 2.6.32.21-166.fc12.i686.PAE #1 SMP Fri Aug 27 06:33:34 UTC 2010 i686 i686 i386 GNU/Linux The problem was, that the EEPROM bearing VID/PID was corrupted. I described the solution on my blog (in czech, but google-translate is your friend;) here: http://www.abclinuxu.cz/blog/vejsplechty/2010/9/oprava-yakumo-quickstick-dvb-t-pod-linuxem -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA -- 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] V4L/DVB: dib0700: Prevent NULL pointer dereference during probe
Commit 8dc09004978538d211ccc36b5046919489e30a55 assumes that dev-rc_input_dev is always set. It is, however, NULL if dvb-usb was loaded with option disable_rc_polling=1. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/dvb/dvb-usb/dib0700_core.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-2.6.36-rc5.orig/drivers/media/dvb/dvb-usb/dib0700_core.c 2010-09-24 17:17:16.0 +0200 +++ linux-2.6.36-rc5/drivers/media/dvb/dvb-usb/dib0700_core.c 2010-09-26 15:04:59.0 +0200 @@ -674,7 +674,8 @@ static int dib0700_probe(struct usb_inte dev-props.rc.core.bulk_mode = false; /* Need a higher delay, to avoid wrong repeat */ - dev-rc_input_dev-rep[REP_DELAY] = 500; + if (dev-rc_input_dev) + dev-rc_input_dev-rep[REP_DELAY] = 500; dib0700_rc_setup(dev); -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v1 0/9] Sub-device pad-level operations
Hi everybody, Here's the first version of the sub-device pad-level operations patches (this is actually not strictly true, as other versions have been posted before as sample code, but this one is the first version officially sent for public review). Anyway, try to enjoy the documentation (I've spent quite a lot of time on it, and it's not the most enjoyable part of kernel development, so be nice :-)). Guennadi, don't forget that you owe me a drink for documenting your media bus format codes :-) If you're careful enough during the review (I shouldn't have said that, it could have been a test) you will notice that the cropping behaviour on subdev output pads isn't defined. This one requires some brainstorming, which by definition I can't do alone. Comments are, as usual, more than welcome. The patches apply on top of the RFC/PATCH v3 V4L2 subdev userspace API and RFC/PATCH v5 Media controller (core and V4L2) patch series. They are available from the http://git.linuxtv.org/pinchartl/media.git git tree (media-000* branches). Antti Koskipaa (1): v4l: v4l2_subdev userspace crop API Laurent Pinchart (7): v4l: Move the media/v4l2-mediabus.h header to include/linux v4l: Group media bus pixel codes by types and sort them alphabetically v4l: Add 8-bit YUYV on 16-bit bus and SGRBG10 media bus pixel codes v4l: Add remaining RAW10 patterns w DPCM pixel code variants v4l: v4l2_subdev pad-level operations v4l: v4l2_subdev userspace format API v4l: v4l2_subdev userspace frame interval API Stanimir Varbanov (1): v4l: Create v4l2 subdev file handle structure Documentation/DocBook/Makefile |5 +- Documentation/DocBook/media-entities.tmpl | 26 + Documentation/DocBook/v4l/bayer.pdf| Bin 0 - 12116 bytes Documentation/DocBook/v4l/bayer.png| Bin 0 - 9725 bytes Documentation/DocBook/v4l/dev-subdev.xml | 300 + Documentation/DocBook/v4l/pipeline.png | Bin 0 - 12130 bytes Documentation/DocBook/v4l/subdev-formats.xml | 1282 Documentation/DocBook/v4l/v4l2.xml |7 + Documentation/DocBook/v4l/vidioc-streamon.xml |9 + .../v4l/vidioc-subdev-enum-frame-interval.xml | 147 +++ .../DocBook/v4l/vidioc-subdev-enum-frame-size.xml | 148 +++ .../DocBook/v4l/vidioc-subdev-enum-mbus-code.xml | 113 ++ Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml | 143 +++ Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml | 168 +++ .../DocBook/v4l/vidioc-subdev-g-frame-interval.xml | 135 ++ drivers/media/video/v4l2-subdev.c | 175 +++- include/linux/Kbuild |2 + include/linux/v4l2-mediabus.h | 91 ++ include/linux/v4l2-subdev.h| 141 +++ include/media/soc_mediabus.h |3 +- include/media/v4l2-mediabus.h | 53 +- include/media/v4l2-subdev.h| 53 + 22 files changed, 2919 insertions(+), 82 deletions(-) create mode 100644 Documentation/DocBook/v4l/bayer.pdf create mode 100644 Documentation/DocBook/v4l/bayer.png create mode 100644 Documentation/DocBook/v4l/dev-subdev.xml create mode 100644 Documentation/DocBook/v4l/pipeline.png create mode 100644 Documentation/DocBook/v4l/subdev-formats.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-frame-size.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-mbus-code.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml create mode 100644 include/linux/v4l2-mediabus.h create mode 100644 include/linux/v4l2-subdev.h -- 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
[RFC/PATCH 3/9] v4l: Add 8-bit YUYV on 16-bit bus and SGRBG10 media bus pixel codes
Add the following media bus format code definitions:
- V4L2_MBUS_FMT_SGRBG10_1X10 for 10-bit GRBG Bayer
- V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 for 10-bit DPCM compressed GRBG Bayer
- V4L2_MBUS_FMT_YUYV16_1X16 for 8-bit YUYV on 16-bit bus
- V4L2_MBUS_FMT_UYVY16_1X16 for 8-bit UYVY on 16-bit bus
- V4L2_MBUS_FMT_YVYU16_1X16 for 8-bit YVYU on 16-bit bus
- V4L2_MBUS_FMT_VYUY16_1X16 for 8-bit VYUY on 16-bit bus
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index bc637a5..9096ef0 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -48,6 +48,10 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_UYVY8_2X8 = 4,
V4L2_MBUS_FMT_YVYU8_2X8 = 3,
V4L2_MBUS_FMT_VYUY8_2X8 = 5,
+ V4L2_MBUS_FMT_YUYV8_1X16 = 24,
+ V4L2_MBUS_FMT_UYVY8_1X16 = 25,
+ V4L2_MBUS_FMT_YVYU8_1X16 = 26,
+ V4L2_MBUS_FMT_VYUY8_1X16 = 27,
/* Bayer */
V4L2_MBUS_FMT_SBGGR8_1X8 = 10,
V4L2_MBUS_FMT_SBGGR10_1X10 = 11,
@@ -57,8 +61,10 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 15,
V4L2_MBUS_FMT_SBGGR12_1X12 = 19,
V4L2_MBUS_FMT_SGRBG8_1X8 = 18,
+ V4L2_MBUS_FMT_SGRBG10_1X10 = 28,
+ V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 29,
/* Last - Update this when adding a new pixel code */
- V4L2_MBUS_FMT_LAST = 24,
+ V4L2_MBUS_FMT_LAST = 30,
};
/**
--
1.7.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 1/9] v4l: Move the media/v4l2-mediabus.h header to include/linux
The header defines the v4l2_mbus_framefmt structure which will be used
by the V4L2 subdevs userspace API.
Change the type of the v4l2_mbus_framefmt::code field to __u32, as enum
sizes can differ between different ABIs on the same architectures.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/Kbuild |1 +
include/linux/v4l2-mediabus.h | 70 +
include/media/soc_mediabus.h |3 +-
include/media/v4l2-mediabus.h | 53 +--
4 files changed, 73 insertions(+), 54 deletions(-)
create mode 100644 include/linux/v4l2-mediabus.h
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index f836ee4..38127c2 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -369,6 +369,7 @@ header-y += unistd.h
header-y += usbdevice_fs.h
header-y += utime.h
header-y += utsname.h
+header-y += v4l2-mediabus.h
header-y += veth.h
header-y += vhost.h
header-y += videodev.h
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
new file mode 100644
index 000..127512a
--- /dev/null
+++ b/include/linux/v4l2-mediabus.h
@@ -0,0 +1,70 @@
+/*
+ * Media Bus API header
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * 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.
+ */
+
+#ifndef __LINUX_V4L2_MEDIABUS_H
+#define __LINUX_V4L2_MEDIABUS_H
+
+#include linux/types.h
+#include linux/videodev2.h
+
+/*
+ * These pixel codes uniquely identify data formats on the media bus. Mostly
+ * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is
+ * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where the
+ * data format is fixed. Additionally, 2X8 means that one pixel is
transferred
+ * in two 8-bit samples, BE or LE specify in which order those samples are
+ * transferred over the bus: LE means that the least significant bits are
+ * transferred first, BE means that the most significant bits are transferred
+ * first, and PADHI and PADLO define which bits - low or high, in the
+ * incomplete high byte, are filled with padding bits.
+ */
+enum v4l2_mbus_pixelcode {
+ V4L2_MBUS_FMT_FIXED = 1,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YVYU8_2X8,
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_VYUY8_2X8,
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
+ V4L2_MBUS_FMT_RGB565_2X8_LE,
+ V4L2_MBUS_FMT_RGB565_2X8_BE,
+ V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_MBUS_FMT_SBGGR10_1X10,
+ V4L2_MBUS_FMT_GREY8_1X8,
+ V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
+ V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_MBUS_FMT_SBGGR12_1X12,
+ V4L2_MBUS_FMT_YUYV8_1_5X8,
+ V4L2_MBUS_FMT_YVYU8_1_5X8,
+ V4L2_MBUS_FMT_UYVY8_1_5X8,
+ V4L2_MBUS_FMT_VYUY8_1_5X8,
+};
+
+/**
+ * struct v4l2_mbus_framefmt - frame format on the media bus
+ * @width: frame width
+ * @height:frame height
+ * @code: data format code
+ * @field: used interlacing type
+ * @colorspace:colorspace of the data
+ */
+struct v4l2_mbus_framefmt {
+ __u32 width;
+ __u32 height;
+ __u32 code;
+ enum v4l2_field field;
+ enum v4l2_colorspacecolorspace;
+};
+
+#endif
diff --git a/include/media/soc_mediabus.h b/include/media/soc_mediabus.h
index 037cd7b..6243147 100644
--- a/include/media/soc_mediabus.h
+++ b/include/media/soc_mediabus.h
@@ -12,8 +12,7 @@
#define SOC_MEDIABUS_H
#include linux/videodev2.h
-
-#include media/v4l2-mediabus.h
+#include linux/v4l2-mediabus.h
/**
* enum soc_mbus_packing - data packing types on the media-bus
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index f0cf2e7..971c7fa 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -11,58 +11,7 @@
#ifndef V4L2_MEDIABUS_H
#define V4L2_MEDIABUS_H
-/*
- * These pixel codes uniquely identify data formats on the media bus. Mostly
- * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is
- * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where the
- * data format is fixed. Additionally, 2X8 means that one pixel is
transferred
- * in two 8-bit samples, BE or LE specify in which order those samples are
- * transferred over the bus: LE means that the least significant bits are
- * transferred first, BE means that the most significant bits are transferred
- * first, and PADHI and PADLO define which bits - low or high, in the
- * incomplete high byte, are filled with padding
[RFC/PATCH 8/9] v4l: v4l2_subdev userspace frame interval API
The three new ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL, VIDIOC_SUBDEV_G_FRAME_INTERVAL and VIDIOC_SUBDEV_S_FRAME_INTERVAL can be used to enumerate and configure a subdev's frame rate from userspace. Two new video::g/s_frame_interval subdev operations are introduced to support those ioctls. The existing video::g/s_parm operations are deprecated and shouldn't be used anymore. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- Documentation/DocBook/media-entities.tmpl |6 + Documentation/DocBook/v4l/v4l2.xml |2 + .../v4l/vidioc-subdev-enum-frame-interval.xml | 147 .../DocBook/v4l/vidioc-subdev-g-frame-interval.xml | 135 ++ drivers/media/video/v4l2-subdev.c | 16 ++ include/linux/v4l2-subdev.h| 36 + include/media/v4l2-subdev.h|7 + 7 files changed, 349 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 160bca6..71cdc75 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -89,7 +89,9 @@ !ENTITY VIDIOC-SUBDEV-ENUM-FRAME-SIZE link linkend='vidioc-subdev-enum-frame-size'constantVIDIOC_SUBDEV_ENUM_FRAME_SIZE/constant/link !ENTITY VIDIOC-SUBDEV-ENUM-MBUS-CODE link linkend='vidioc-subdev-enum-mbus-code'constantVIDIOC_SUBDEV_ENUM_MBUS_CODE/constant/link !ENTITY VIDIOC-SUBDEV-G-FMT link linkend='vidioc-subdev-g-fmt'constantVIDIOC_SUBDEV_G_FMT/constant/link +!ENTITY VIDIOC-SUBDEV-G-FRAME-INTERVAL link linkend='vidioc-subdev-g-frame-interval'constantVIDIOC_SUBDEV_G_FRAME_INTERVAL/constant/link !ENTITY VIDIOC-SUBDEV-S-FMT link linkend='vidioc-subdev-g-fmt'constantVIDIOC_SUBDEV_S_FMT/constant/link +!ENTITY VIDIOC-SUBDEV-S-FRAME-INTERVAL link linkend='vidioc-subdev-g-frame-interval'constantVIDIOC_SUBDEV_S_FRAME_INTERVAL/constant/link !ENTITY VIDIOC-TRY-ENCODER-CMD link linkend='vidioc-encoder-cmd'constantVIDIOC_TRY_ENCODER_CMD/constant/link !ENTITY VIDIOC-TRY-EXT-CTRLS link linkend='vidioc-g-ext-ctrls'constantVIDIOC_TRY_EXT_CTRLS/constant/link !ENTITY VIDIOC-TRY-FMT link linkend='vidioc-g-fmt'constantVIDIOC_TRY_FMT/constant/link @@ -190,6 +192,8 @@ !ENTITY v4l2-sliced-vbi-cap structnbsp;link linkend='v4l2-sliced-vbi-cap'v4l2_sliced_vbi_cap/link !ENTITY v4l2-sliced-vbi-data structnbsp;link linkend='v4l2-sliced-vbi-data'v4l2_sliced_vbi_data/link !ENTITY v4l2-sliced-vbi-format structnbsp;link linkend='v4l2-sliced-vbi-format'v4l2_sliced_vbi_format/link +!ENTITY v4l2-subdev-frame-interval structnbsp;link linkend='v4l2-subdev-frame-interval'v4l2_subdev_frame_interval/link +!ENTITY v4l2-subdev-frame-interval-enum structnbsp;link linkend='v4l2-subdev-frame-interval-enum'v4l2_subdev_frame_interval_enum/link !ENTITY v4l2-subdev-frame-size-enum structnbsp;link linkend='v4l2-subdev-frame-size-enum'v4l2_subdev_frame_size_enum/link !ENTITY v4l2-subdev-format structnbsp;link linkend='v4l2-subdev-format'v4l2_subdev_format/link !ENTITY v4l2-subdev-mbus-code-enum structnbsp;link linkend='v4l2-subdev-mbus-code-enum'v4l2_subdev_mbus_code_enum/link @@ -322,10 +326,12 @@ !ENTITY sub-reqbufs SYSTEM v4l/vidioc-reqbufs.xml !ENTITY sub-s-hw-freq-seek SYSTEM v4l/vidioc-s-hw-freq-seek.xml !ENTITY sub-streamon SYSTEM v4l/vidioc-streamon.xml +!ENTITY sub-subdev-enum-frame-interval SYSTEM v4l/vidioc-subdev-enum-frame-interval.xml !ENTITY sub-subdev-enum-frame-size SYSTEM v4l/vidioc-subdev-enum-frame-size.xml !ENTITY sub-subdev-enum-mbus-code SYSTEM v4l/vidioc-subdev-enum-mbus-code.xml !ENTITY sub-subdev-formats SYSTEM v4l/subdev-formats.xml !ENTITY sub-subdev-g-fmt SYSTEM v4l/vidioc-subdev-g-fmt.xml +!ENTITY sub-subdev-g-frame-interval SYSTEM v4l/vidioc-subdev-g-frame-interval.xml !ENTITY sub-capture-c SYSTEM v4l/capture.c.xml !ENTITY sub-keytable-c SYSTEM v4l/keytable.c.xml !ENTITY sub-v4l2grab-c SYSTEM v4l/v4l2grab.c.xml diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 3a59b82..7806562 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -470,9 +470,11 @@ and discussions on the V4L mailing list./revremark sub-reqbufs; sub-s-hw-freq-seek; sub-streamon; +sub-subdev-enum-frame-interval; sub-subdev-enum-frame-size; sub-subdev-enum-mbus-code; sub-subdev-g-fmt; +sub-subdev-g-frame-interval; sub-subscribe-event; !-- End of ioctls. -- sub-mmap; diff --git a/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml new file mode 100644 index 000..be73500 --- /dev/null
[RFC/PATCH 6/9] v4l: v4l2_subdev pad-level operations
Add a v4l2_subdev_pad_ops structure for the operations that need to be
performed at the pad level such as format-related operations.
The format at the output of a subdev usually depends on the format at
its input(s). The try format operation is thus not suitable for probing
format at individual pads, as it can't modify the device state and thus
can't remember the format probed at the input to compute the output
format.
To fix the problem, pass an extra argument to the get/set format
operations to select the 'probe' or 'active' format.
The probe format is used when probing the subdev. Setting the probe
format must not change the device configuration but can store data for
later reuse. Data storage is provided at the file-handle level so
applications probing the subdev concurently won't interfere with each
other.
The active format is used when configuring the subdev. It's identical to
the format handled by the usual get/set operations.
Pad format-related operations use v4l2_mbus_framefmt instead of
v4l2_format.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/media/v4l2-subdev.h | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 212fc54..8a278c2 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -42,6 +42,7 @@ struct v4l2_ctrl_handler;
struct v4l2_event_subscription;
struct v4l2_fh;
struct v4l2_subdev;
+struct v4l2_subdev_fh;
struct tuner_setup;
/* decode_vbi_line */
@@ -418,6 +419,20 @@ struct v4l2_subdev_ir_ops {
struct v4l2_subdev_ir_parameters *params);
};
+enum v4l2_subdev_format_whence {
+ V4L2_SUBDEV_FORMAT_PROBE = 0,
+ V4L2_SUBDEV_FORMAT_ACTIVE = 1,
+};
+
+struct v4l2_subdev_pad_ops {
+ int (*get_fmt)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ unsigned int pad, struct v4l2_mbus_framefmt *fmt,
+ enum v4l2_subdev_format_whence which);
+ int (*set_fmt)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ unsigned int pad, struct v4l2_mbus_framefmt *fmt,
+ enum v4l2_subdev_format_whence which);
+};
+
struct v4l2_subdev_ops {
const struct v4l2_subdev_core_ops *core;
const struct v4l2_subdev_tuner_ops *tuner;
@@ -426,6 +441,7 @@ struct v4l2_subdev_ops {
const struct v4l2_subdev_vbi_ops*vbi;
const struct v4l2_subdev_ir_ops *ir;
const struct v4l2_subdev_sensor_ops *sensor;
+ const struct v4l2_subdev_pad_ops*pad;
};
#define V4L2_SUBDEV_NAME_SIZE 32
--
1.7.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 4/9] v4l: Add remaining RAW10 patterns w DPCM pixel code variants
This adds following formats:
- V4L2_MBUS_FMT_SRGGB10_1X10
- V4L2_MBUS_FMT_SGBRG10_1X10
- V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8
- V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8
- V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8
Signed-off-by: Sergio Aguirre saagui...@ti.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 9096ef0..110db35 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -55,16 +55,21 @@ enum v4l2_mbus_pixelcode {
/* Bayer */
V4L2_MBUS_FMT_SBGGR8_1X8 = 10,
V4L2_MBUS_FMT_SBGGR10_1X10 = 11,
+ V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 = 30,
V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 16,
V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 14,
V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 17,
V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 15,
V4L2_MBUS_FMT_SBGGR12_1X12 = 19,
+ V4L2_MBUS_FMT_SGBRG10_1X10 = 31,
+ V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 32,
V4L2_MBUS_FMT_SGRBG8_1X8 = 18,
V4L2_MBUS_FMT_SGRBG10_1X10 = 28,
V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 29,
+ V4L2_MBUS_FMT_SRGGB10_1X10 = 33,
+ V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 = 34,
/* Last - Update this when adding a new pixel code */
- V4L2_MBUS_FMT_LAST = 30,
+ V4L2_MBUS_FMT_LAST = 35,
};
/**
--
1.7.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 5/9] v4l: Create v4l2 subdev file handle structure
From: Stanimir Varbanov svarba...@mm-sol.com
Used for storing subdev information per file handle and hold V4L2 file
handle.
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
Signed-off-by: Antti Koskipaa antti.koski...@nokia.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-subdev.c | 82 +
include/media/v4l2-subdev.h | 25 +++
2 files changed, 80 insertions(+), 27 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index 731dc12..d2891c1 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -30,38 +30,66 @@
#include media/v4l2-fh.h
#include media/v4l2-event.h
+static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev *sd)
+{
+ /* Allocate probe format and crop in the same memory block */
+ fh-probe_fmt = kzalloc((sizeof(*fh-probe_fmt) +
+ sizeof(*fh-probe_crop)) * sd-entity.num_pads,
+ GFP_KERNEL);
+ if (fh-probe_fmt == NULL)
+ return -ENOMEM;
+
+ fh-probe_crop = (struct v4l2_rect *)
+ (fh-probe_fmt + sd-entity.num_pads);
+
+ return 0;
+}
+
+static void subdev_fh_free(struct v4l2_subdev_fh *fh)
+{
+ kfree(fh-probe_fmt);
+ fh-probe_fmt = NULL;
+ fh-probe_crop = NULL;
+}
+
static int subdev_open(struct file *file)
{
struct video_device *vdev = video_devdata(file);
struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
+ struct v4l2_subdev_fh *subdev_fh;
struct media_entity *entity;
- struct v4l2_fh *vfh = NULL;
int ret;
if (!sd-initialized)
return -EAGAIN;
- if (sd-flags V4L2_SUBDEV_FL_HAS_EVENTS) {
- vfh = kzalloc(sizeof(*vfh), GFP_KERNEL);
- if (vfh == NULL)
- return -ENOMEM;
+ subdev_fh = kzalloc(sizeof(*subdev_fh), GFP_KERNEL);
+ if (subdev_fh == NULL)
+ return -ENOMEM;
- ret = v4l2_fh_init(vfh, vdev);
- if (ret)
- goto err;
+ ret = subdev_fh_init(subdev_fh, sd);
+ if (ret) {
+ kfree(subdev_fh);
+ return ret;
+ }
+
+ ret = v4l2_fh_init(subdev_fh-vfh, vdev);
+ if (ret)
+ goto err;
- ret = v4l2_event_init(vfh);
+ if (sd-flags V4L2_SUBDEV_FL_HAS_EVENTS) {
+ ret = v4l2_event_init(subdev_fh-vfh);
if (ret)
goto err;
- ret = v4l2_event_alloc(vfh, sd-nevents);
+ ret = v4l2_event_alloc(subdev_fh-vfh, sd-nevents);
if (ret)
goto err;
-
- v4l2_fh_add(vfh);
- file-private_data = vfh;
}
+ v4l2_fh_add(subdev_fh-vfh);
+ file-private_data = subdev_fh-vfh;
+
if (sd-v4l2_dev-mdev) {
entity = media_entity_get(sd-entity);
if (!entity) {
@@ -73,11 +101,10 @@ static int subdev_open(struct file *file)
return 0;
err:
- if (vfh != NULL) {
- v4l2_fh_del(vfh);
- v4l2_fh_exit(vfh);
- kfree(vfh);
- }
+ v4l2_fh_del(subdev_fh-vfh);
+ v4l2_fh_exit(subdev_fh-vfh);
+ subdev_fh_free(subdev_fh);
+ kfree(subdev_fh);
return ret;
}
@@ -87,15 +114,16 @@ static int subdev_close(struct file *file)
struct video_device *vdev = video_devdata(file);
struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
struct v4l2_fh *vfh = file-private_data;
+ struct v4l2_subdev_fh *subdev_fh = to_v4l2_subdev_fh(vfh);
if (sd-v4l2_dev-mdev)
media_entity_put(sd-entity);
- if (vfh != NULL) {
- v4l2_fh_del(vfh);
- v4l2_fh_exit(vfh);
- kfree(vfh);
- }
+ v4l2_fh_del(vfh);
+ v4l2_fh_exit(vfh);
+ subdev_fh_free(subdev_fh);
+ kfree(subdev_fh);
+ file-private_data = NULL;
return 0;
}
@@ -104,7 +132,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int
cmd, void *arg)
{
struct video_device *vdev = video_devdata(file);
struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
- struct v4l2_fh *fh = file-private_data;
+ struct v4l2_fh *vfh = file-private_data;
switch (cmd) {
case VIDIOC_QUERYCTRL:
@@ -132,13 +160,13 @@ static long subdev_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
if (!(sd-flags V4L2_SUBDEV_FL_HAS_EVENTS))
return -ENOIOCTLCMD;
- return v4l2_event_dequeue(fh, arg, file-f_flags O_NONBLOCK);
+ return v4l2_event_dequeue(vfh, arg, file-f_flags O_NONBLOCK);
case VIDIOC_SUBSCRIBE_EVENT:
- return v4l2_subdev_call(sd,
[RFC/PATCH 2/9] v4l: Group media bus pixel codes by types and sort them alphabetically
Adding new pixel codes at the end of the enumeration will soon create a
mess, so sort the pixel codes by type and then sort them alphabetically.
As the codes are part of the kernel ABI their value can't change when a
new code is inserted in the enumeration, so they are given an explicit
numerical value. When inserting a new pixel code developers must use and
update the V4L2_MBUS_FMT_LAST value.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h | 54
1 files changed, 32 insertions(+), 22 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 127512a..bc637a5 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -24,31 +24,41 @@
* transferred first, BE means that the most significant bits are transferred
* first, and PADHI and PADLO define which bits - low or high, in the
* incomplete high byte, are filled with padding bits.
+ *
+ * The pixel codes are grouped by types and (mostly) sorted alphabetically. As
+ * their value can't change when a new pixel code is inserted in the
+ * enumeration, they are explicitly given a numerical value. When inserting a
+ * new pixel code use and update the V4L2_MBUS_FMT_LAST value.
*/
enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_FIXED = 1,
- V4L2_MBUS_FMT_YUYV8_2X8,
- V4L2_MBUS_FMT_YVYU8_2X8,
- V4L2_MBUS_FMT_UYVY8_2X8,
- V4L2_MBUS_FMT_VYUY8_2X8,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
- V4L2_MBUS_FMT_RGB565_2X8_LE,
- V4L2_MBUS_FMT_RGB565_2X8_BE,
- V4L2_MBUS_FMT_SBGGR8_1X8,
- V4L2_MBUS_FMT_SBGGR10_1X10,
- V4L2_MBUS_FMT_GREY8_1X8,
- V4L2_MBUS_FMT_Y10_1X10,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
- V4L2_MBUS_FMT_SGRBG8_1X8,
- V4L2_MBUS_FMT_SBGGR12_1X12,
- V4L2_MBUS_FMT_YUYV8_1_5X8,
- V4L2_MBUS_FMT_YVYU8_1_5X8,
- V4L2_MBUS_FMT_UYVY8_1_5X8,
- V4L2_MBUS_FMT_VYUY8_1_5X8,
+ /* RGB */
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 7,
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 6,
+ V4L2_MBUS_FMT_RGB565_2X8_BE = 9,
+ V4L2_MBUS_FMT_RGB565_2X8_LE = 8,
+ /* YUV (including grey) */
+ V4L2_MBUS_FMT_GREY8_1X8 = 12,
+ V4L2_MBUS_FMT_Y10_1X10 = 13,
+ V4L2_MBUS_FMT_YUYV8_1_5X8 = 20,
+ V4L2_MBUS_FMT_YVYU8_1_5X8 = 21,
+ V4L2_MBUS_FMT_UYVY8_1_5X8 = 22,
+ V4L2_MBUS_FMT_VYUY8_1_5X8 = 23,
+ V4L2_MBUS_FMT_YUYV8_2X8 = 2,
+ V4L2_MBUS_FMT_UYVY8_2X8 = 4,
+ V4L2_MBUS_FMT_YVYU8_2X8 = 3,
+ V4L2_MBUS_FMT_VYUY8_2X8 = 5,
+ /* Bayer */
+ V4L2_MBUS_FMT_SBGGR8_1X8 = 10,
+ V4L2_MBUS_FMT_SBGGR10_1X10 = 11,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 16,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 14,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 17,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 15,
+ V4L2_MBUS_FMT_SBGGR12_1X12 = 19,
+ V4L2_MBUS_FMT_SGRBG8_1X8 = 18,
+ /* Last - Update this when adding a new pixel code */
+ V4L2_MBUS_FMT_LAST = 24,
};
/**
--
1.7.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 9/9] v4l: v4l2_subdev userspace crop API
From: Antti Koskipaa antti.koski...@nokia.com This patch adds the VIDIOC_SUBDEV_S_CROP and G_CROP ioctls to the userland API. CROPCAP is not implemented because it's redundant. Signed-off-by: Antti Koskipaa antti.koski...@nokia.com Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/media-entities.tmpl |4 + Documentation/DocBook/v4l/dev-subdev.xml | 33 + Documentation/DocBook/v4l/v4l2.xml |1 + Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml | 143 drivers/media/video/v4l2-subdev.c | 26 include/linux/v4l2-subdev.h| 15 ++ include/media/v4l2-subdev.h|4 + 7 files changed, 226 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 71cdc75..f2b0930 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -88,8 +88,10 @@ !ENTITY VIDIOC-S-TUNER link linkend='vidioc-g-tuner'constantVIDIOC_S_TUNER/constant/link !ENTITY VIDIOC-SUBDEV-ENUM-FRAME-SIZE link linkend='vidioc-subdev-enum-frame-size'constantVIDIOC_SUBDEV_ENUM_FRAME_SIZE/constant/link !ENTITY VIDIOC-SUBDEV-ENUM-MBUS-CODE link linkend='vidioc-subdev-enum-mbus-code'constantVIDIOC_SUBDEV_ENUM_MBUS_CODE/constant/link +!ENTITY VIDIOC-SUBDEV-G-CROP link linkend='vidioc-subdev-g-crop'constantVIDIOC_SUBDEV_G_CROP/constant/link !ENTITY VIDIOC-SUBDEV-G-FMT link linkend='vidioc-subdev-g-fmt'constantVIDIOC_SUBDEV_G_FMT/constant/link !ENTITY VIDIOC-SUBDEV-G-FRAME-INTERVAL link linkend='vidioc-subdev-g-frame-interval'constantVIDIOC_SUBDEV_G_FRAME_INTERVAL/constant/link +!ENTITY VIDIOC-SUBDEV-S-CROP link linkend='vidioc-subdev-g-crop'constantVIDIOC_SUBDEV_S_CROP/constant/link !ENTITY VIDIOC-SUBDEV-S-FMT link linkend='vidioc-subdev-g-fmt'constantVIDIOC_SUBDEV_S_FMT/constant/link !ENTITY VIDIOC-SUBDEV-S-FRAME-INTERVAL link linkend='vidioc-subdev-g-frame-interval'constantVIDIOC_SUBDEV_S_FRAME_INTERVAL/constant/link !ENTITY VIDIOC-TRY-ENCODER-CMD link linkend='vidioc-encoder-cmd'constantVIDIOC_TRY_ENCODER_CMD/constant/link @@ -195,6 +197,7 @@ !ENTITY v4l2-subdev-frame-interval structnbsp;link linkend='v4l2-subdev-frame-interval'v4l2_subdev_frame_interval/link !ENTITY v4l2-subdev-frame-interval-enum structnbsp;link linkend='v4l2-subdev-frame-interval-enum'v4l2_subdev_frame_interval_enum/link !ENTITY v4l2-subdev-frame-size-enum structnbsp;link linkend='v4l2-subdev-frame-size-enum'v4l2_subdev_frame_size_enum/link +!ENTITY v4l2-subdev-crop structnbsp;link linkend='v4l2-subdev-crop'v4l2_subdev_crop/link !ENTITY v4l2-subdev-format structnbsp;link linkend='v4l2-subdev-format'v4l2_subdev_format/link !ENTITY v4l2-subdev-mbus-code-enum structnbsp;link linkend='v4l2-subdev-mbus-code-enum'v4l2_subdev_mbus_code_enum/link !ENTITY v4l2-standard structnbsp;link linkend='v4l2-standard'v4l2_standard/link @@ -330,6 +333,7 @@ !ENTITY sub-subdev-enum-frame-size SYSTEM v4l/vidioc-subdev-enum-frame-size.xml !ENTITY sub-subdev-enum-mbus-code SYSTEM v4l/vidioc-subdev-enum-mbus-code.xml !ENTITY sub-subdev-formats SYSTEM v4l/subdev-formats.xml +!ENTITY sub-subdev-g-crop SYSTEM v4l/vidioc-subdev-g-crop.xml !ENTITY sub-subdev-g-fmt SYSTEM v4l/vidioc-subdev-g-fmt.xml !ENTITY sub-subdev-g-frame-interval SYSTEM v4l/vidioc-subdev-g-frame-interval.xml !ENTITY sub-capture-c SYSTEM v4l/capture.c.xml diff --git a/Documentation/DocBook/v4l/dev-subdev.xml b/Documentation/DocBook/v4l/dev-subdev.xml index 9a691f7..c57c62f 100644 --- a/Documentation/DocBook/v4l/dev-subdev.xml +++ b/Documentation/DocBook/v4l/dev-subdev.xml @@ -262,6 +262,39 @@ /para /section +section + titleCropping and scaling/title + + paraMany sub-devices support cropping frames on their input or output + pads (or possible even on both). Cropping is used to select the area of + interest in an image, typically on a video sensor or video decoder. It can + also be used as part of digital zoom implementations to select the area of + the image that will be scaled up./para + + paraCrop settings are defined by a crop rectangle and represented in a + v4l2-rect; by the coordinates of the top left corner and the rectangle + size. Both the coordinates and sizes are expressed in pixels./para + + paraThe crop rectangle is retrieved and set using the + VIDIOC-SUBDEV-G-CROP; and VIDIOC-SUBDEV-S-CROP; ioctls. Like for pad + formats, drivers store probe and active crop rectangles. The format + negotiation mechanism applies to crop settings as well./para + + paraOn input pads, cropping is applied relatively to the current pad + format. The pad format represents the image size as received by the + sub-device from the previous block
Re: Trouble building v4l-dvb
On Linux 2.6.28-19-generic the problem is tackled already: DVB_FIREDTV_IEEE1394: Requires at least kernel 2.6.30 On newer linux versions (I have tried Linux 2.6.32-24-generic) the problem is NOT that the modules dma is not present, it is just that the required header files are not present in /usr/include Another location mighte have been: ls -l /usr/src/linux-headers-2.6.28-19-generic/include/config/ieee1394 but that only contains: -rw-r--r-- 1 root root0 2010-09-16 18:25 dv1394.h drwxr-xr-x 3 root root 4096 2010-06-15 20:12 eth1394 -rw-r--r-- 1 root root0 2010-09-16 18:25 eth1394.h -rw-r--r-- 1 root root0 2010-09-16 18:25 ohci1394.h -rw-r--r-- 1 root root0 2010-09-16 18:25 pcilynx.h -rw-r--r-- 1 root root0 2010-09-16 18:25 rawio.h -rw-r--r-- 1 root root0 2010-09-16 18:25 sbp2.h -rw-r--r-- 1 root root0 2010-09-16 18:25 video1394.h Can you indicate where following files should be located ? dma.h csr1212.h highlevel.h In that case checking if the dma.h file is present might be the best way forward. I'll also file an ubuntu bug once I know what is missing where. I could not find an entry in launchpad on this issue yet. Mauro Carvalho Chehab wrote: Em 17-09-2010 08:08, Jan Hoogenraad escreveu: Thanks ! Indeed, the hack so that make allyesmod not select firedtv would be very helpful. that way, it is also clear that firedtv will not work on debian-like distros. Is there a way I cen help with that ? I have no experience with Kconfig, so it would be a learning experience for me. You don't need to look at Kconfig. there are some scripts under v4l/scripts that will deal with Kconfig dependencies. They are meant to identify kernel versions and features. Those scripts are, mainly: v4l/scripts/make_config_compat.pl - Checks for backported features, enabling workarounds at v4l/compat.h v4l/scripts/make_kconfig.pl - Generates a .config file that will compile with an older kernel v4l/scripts/make_makefile.pl - Generates a Makefile that will build/install/remove the kernel modules Basically, you need to add some intelligence to one of the above scripts (likely make_kconfig) to identify that the kernel has broken firewire headers, and disable its compilation, printing a warning message to the user. You'll find a logic at make_makefile.pl to detect an Ubuntu broken kernel that stores the in-kernel drivers at the wrong install place. I'm not sure if all Ubuntu kernels/versions do the same thing, nor if this is broken for all distro-variants. Perhaps you may use this logic at make_kconfig.pl. The logic assumes that broken distros are the ones that store V4L/DVB files at /lib/modules/\$(KERNELRELEASE)/ubuntu/media. This is probably not true for all broken distros (as Ubuntu clones - and maybe Debian - could have the same problem, but storing the media files on a different place), so you may need to generalize that logic, in order to cover any other distros that don't compile firewire. While you're there, the better is to also disable CONFIG_ALSA on Ubuntu, as the drivers won't work anyway. As we don't want to have complains from users about why driver foo is not compiling for me, IMO, it should be printing a warning message saying that compilation of ALSA/FIREWIRE drivers with that specific kernel version is not possible, due to the back packaging of kernel headers, recommending to the user to get a vanilla upstream kernel, if he needs one of the disabled drivers. Cheers, Mauro -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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
TeVii S660 continuity errors
Is anyone else having continuity problems with the S660? causing rare glitching on SD content, and glitching on HD content very often. Turning on the `disable_rc_polling' parameter for the dvb_usb module seems to help, but it's hard to tell for sure. Turning on the `dvb_demux_tscheck' parameter for the dvb_core module shows continuity counter errors every few seconds in the syslog, along with a peculiar callback ratelimit line before each set of continuity counter errors. Interestingly, the `expected' value is one away from the `got' value, doubtful it's just by chance? Here is a sample from the syslog: [51302.316543] TEI detected. PID=0x1c79 data1=0xfc [51302.316547] TS packet counter mismatch. PID=0x1c79 expected 0xd got 0xc [51302.316550] TEI detected. PID=0x7b6 data1=0xa7 [51302.316552] TS packet counter mismatch. PID=0x7b6 expected 0x2 got 0x8 [51302.316555] TEI detected. PID=0x1e4 data1=0xe1 [51302.316558] TEI detected. PID=0x1324 data1=0xd3 [51302.316561] TS packet counter mismatch. PID=0x1324 expected 0xb got 0x0 [51302.316564] TS packet counter mismatch. PID=0x1c2c expected 0x0 got 0xf [51302.316567] TS packet counter mismatch. PID=0x1f09 expected 0xc got 0xe [51307.329040] __ratelimit: 397 callbacks suppressed [51307.329044] TS packet counter mismatch. PID=0xfaf expected 0x1 got 0x0 [51307.339404] TS packet counter mismatch. PID=0x3fe expected 0x7 got 0x6 [51307.362671] TS packet counter mismatch. PID=0xfaf expected 0x1 got 0x0 [51307.367882] TS packet counter mismatch. PID=0x3fd expected 0x4 got 0x3 The bitrate is about 40 or 50Mbps, depending on what transponder is tuned. This is reported by the dvbcore driver in the syslog when the `dvb_demux_speedcheck' parameter is turned on. I've also experienced input lag, the computer locking up for a second or few, seemed to be during tuning. This seems similar to something that was reported by someone on this list in the past. Disabling RC polling seems to have helped with that. I'm using hts-tvheadend, and it reports continuity errors sometimes as well (though not as often as the driver does in the syslog). The frontend is XBMC on another computer, connected via wired ethernet. The S660 is connected directly via USB to a MacbookPro (Nvidia MCP79 chipset). The computer is running Debian sid 32bit (2.6.32-5-686) with s2-liplianin from yesterday, and the firmware from the 100315_Beta_linux_tevii_ds3000.rar drivers from tevii.com. I've also tried running with the drivers from that rar, to no avail. Everything works well (no glitching) in Windows 7 x64 with the `DVB-HD 2020100830.rar' drivers from tevii.com Is this some sort of timing issue? an issue with the USB bus being overloaded? (I've tried removing most of the usb modules, including ohci_hcd, hid, etc). How can I troubleshoot which driver is at fault? Is this a firmware issue? Can new firmware be extracted from the 20100830 Windows driver? How? Any help/suggestions appreciated. Thanks :) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 5/9] v4l: Create v4l2 subdev file handle structure
On Sunday, September 26, 2010 18:13:28 Laurent Pinchart wrote:
From: Stanimir Varbanov svarba...@mm-sol.com
Used for storing subdev information per file handle and hold V4L2 file
handle.
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
Signed-off-by: Antti Koskipaa antti.koski...@nokia.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-subdev.c | 82
+
include/media/v4l2-subdev.h | 25 +++
2 files changed, 80 insertions(+), 27 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index 731dc12..d2891c1 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -30,38 +30,66 @@
#include media/v4l2-fh.h
#include media/v4l2-event.h
+static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev *sd)
+{
+ /* Allocate probe format and crop in the same memory block */
+ fh-probe_fmt = kzalloc((sizeof(*fh-probe_fmt) +
+ sizeof(*fh-probe_crop)) * sd-entity.num_pads,
+ GFP_KERNEL);
+ if (fh-probe_fmt == NULL)
+ return -ENOMEM;
I really don't like the name 'probe' for this. I remember discussing it with
you,
Laurent, but I can't remember the word I came up with.
Can you remember what it was?
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/9] v4l: Group media bus pixel codes by types and sort them alphabetically
On Sunday, September 26, 2010 18:13:25 Laurent Pinchart wrote:
Adding new pixel codes at the end of the enumeration will soon create a
mess, so sort the pixel codes by type and then sort them alphabetically.
As the codes are part of the kernel ABI their value can't change when a
new code is inserted in the enumeration, so they are given an explicit
numerical value. When inserting a new pixel code developers must use and
update the V4L2_MBUS_FMT_LAST value.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h | 54
1 files changed, 32 insertions(+), 22 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 127512a..bc637a5 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -24,31 +24,41 @@
* transferred first, BE means that the most significant bits are
transferred
* first, and PADHI and PADLO define which bits - low or high, in the
* incomplete high byte, are filled with padding bits.
+ *
+ * The pixel codes are grouped by types and (mostly) sorted alphabetically.
As
+ * their value can't change when a new pixel code is inserted in the
+ * enumeration, they are explicitly given a numerical value. When inserting a
+ * new pixel code use and update the V4L2_MBUS_FMT_LAST value.
*/
enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_FIXED = 1,
- V4L2_MBUS_FMT_YUYV8_2X8,
- V4L2_MBUS_FMT_YVYU8_2X8,
- V4L2_MBUS_FMT_UYVY8_2X8,
- V4L2_MBUS_FMT_VYUY8_2X8,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
- V4L2_MBUS_FMT_RGB565_2X8_LE,
- V4L2_MBUS_FMT_RGB565_2X8_BE,
- V4L2_MBUS_FMT_SBGGR8_1X8,
- V4L2_MBUS_FMT_SBGGR10_1X10,
- V4L2_MBUS_FMT_GREY8_1X8,
- V4L2_MBUS_FMT_Y10_1X10,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
- V4L2_MBUS_FMT_SGRBG8_1X8,
- V4L2_MBUS_FMT_SBGGR12_1X12,
- V4L2_MBUS_FMT_YUYV8_1_5X8,
- V4L2_MBUS_FMT_YVYU8_1_5X8,
- V4L2_MBUS_FMT_UYVY8_1_5X8,
- V4L2_MBUS_FMT_VYUY8_1_5X8,
+ /* RGB */
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 7,
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 6,
+ V4L2_MBUS_FMT_RGB565_2X8_BE = 9,
+ V4L2_MBUS_FMT_RGB565_2X8_LE = 8,
+ /* YUV (including grey) */
+ V4L2_MBUS_FMT_GREY8_1X8 = 12,
+ V4L2_MBUS_FMT_Y10_1X10 = 13,
+ V4L2_MBUS_FMT_YUYV8_1_5X8 = 20,
+ V4L2_MBUS_FMT_YVYU8_1_5X8 = 21,
+ V4L2_MBUS_FMT_UYVY8_1_5X8 = 22,
+ V4L2_MBUS_FMT_VYUY8_1_5X8 = 23,
+ V4L2_MBUS_FMT_YUYV8_2X8 = 2,
+ V4L2_MBUS_FMT_UYVY8_2X8 = 4,
+ V4L2_MBUS_FMT_YVYU8_2X8 = 3,
+ V4L2_MBUS_FMT_VYUY8_2X8 = 5,
+ /* Bayer */
+ V4L2_MBUS_FMT_SBGGR8_1X8 = 10,
+ V4L2_MBUS_FMT_SBGGR10_1X10 = 11,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 16,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 14,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 17,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 15,
+ V4L2_MBUS_FMT_SBGGR12_1X12 = 19,
+ V4L2_MBUS_FMT_SGRBG8_1X8 = 18,
Why on earth would you want to keep the original values? It was internal only,
so no need to stick to the old values.
Just let RGB start at 1000, YUV at 2000 and Bayer at 3000 or something like
that.
+ /* Last - Update this when adding a new pixel code */
+ V4L2_MBUS_FMT_LAST = 24,
Why would you need this?
Regards,
Hans
};
/**
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/9] v4l: Group media bus pixel codes by types and sort them alphabetically
Hi Hans,
On Sunday 26 September 2010 19:29:53 Hans Verkuil wrote:
On Sunday, September 26, 2010 18:13:25 Laurent Pinchart wrote:
Adding new pixel codes at the end of the enumeration will soon create a
mess, so sort the pixel codes by type and then sort them alphabetically.
As the codes are part of the kernel ABI their value can't change when a
new code is inserted in the enumeration, so they are given an explicit
numerical value. When inserting a new pixel code developers must use and
update the V4L2_MBUS_FMT_LAST value.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h | 54
1 files changed, 32
insertions(+), 22 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h
b/include/linux/v4l2-mediabus.h index 127512a..bc637a5 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -24,31 +24,41 @@
* transferred first, BE means that the most significant bits are
transferred * first, and PADHI and PADLO define which bits - low
or high, in the * incomplete high byte, are filled with padding bits.
+ *
+ * The pixel codes are grouped by types and (mostly) sorted
alphabetically. As + * their value can't change when a new pixel code is
inserted in the + * enumeration, they are explicitly given a numerical
value. When inserting a + * new pixel code use and update the
V4L2_MBUS_FMT_LAST value.
*/
enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_FIXED = 1,
- V4L2_MBUS_FMT_YUYV8_2X8,
- V4L2_MBUS_FMT_YVYU8_2X8,
- V4L2_MBUS_FMT_UYVY8_2X8,
- V4L2_MBUS_FMT_VYUY8_2X8,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
- V4L2_MBUS_FMT_RGB565_2X8_LE,
- V4L2_MBUS_FMT_RGB565_2X8_BE,
- V4L2_MBUS_FMT_SBGGR8_1X8,
- V4L2_MBUS_FMT_SBGGR10_1X10,
- V4L2_MBUS_FMT_GREY8_1X8,
- V4L2_MBUS_FMT_Y10_1X10,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
- V4L2_MBUS_FMT_SGRBG8_1X8,
- V4L2_MBUS_FMT_SBGGR12_1X12,
- V4L2_MBUS_FMT_YUYV8_1_5X8,
- V4L2_MBUS_FMT_YVYU8_1_5X8,
- V4L2_MBUS_FMT_UYVY8_1_5X8,
- V4L2_MBUS_FMT_VYUY8_1_5X8,
+ /* RGB */
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 7,
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 6,
+ V4L2_MBUS_FMT_RGB565_2X8_BE = 9,
+ V4L2_MBUS_FMT_RGB565_2X8_LE = 8,
+ /* YUV (including grey) */
+ V4L2_MBUS_FMT_GREY8_1X8 = 12,
+ V4L2_MBUS_FMT_Y10_1X10 = 13,
+ V4L2_MBUS_FMT_YUYV8_1_5X8 = 20,
+ V4L2_MBUS_FMT_YVYU8_1_5X8 = 21,
+ V4L2_MBUS_FMT_UYVY8_1_5X8 = 22,
+ V4L2_MBUS_FMT_VYUY8_1_5X8 = 23,
+ V4L2_MBUS_FMT_YUYV8_2X8 = 2,
+ V4L2_MBUS_FMT_UYVY8_2X8 = 4,
+ V4L2_MBUS_FMT_YVYU8_2X8 = 3,
+ V4L2_MBUS_FMT_VYUY8_2X8 = 5,
+ /* Bayer */
+ V4L2_MBUS_FMT_SBGGR8_1X8 = 10,
+ V4L2_MBUS_FMT_SBGGR10_1X10 = 11,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 16,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 14,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 17,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 15,
+ V4L2_MBUS_FMT_SBGGR12_1X12 = 19,
+ V4L2_MBUS_FMT_SGRBG8_1X8 = 18,
Why on earth would you want to keep the original values? It was internal
only, so no need to stick to the old values.
Good point :-)
Just let RGB start at 1000, YUV at 2000 and Bayer at 3000 or something like
that.
+ /* Last - Update this when adding a new pixel code */
+ V4L2_MBUS_FMT_LAST = 24,
Why would you need this?
We've discussed this in the past. Keeping holes won't help, as we will have to
insert formats in places where we won't have holes sooner or later. We agreed
that it was better to keep the list organized by format, as that's easier to
read. V4L2_MBUS_FMT_LAST is thus a shortcut to avoid searching for the highest
format when adding a new one. As the constant itself isn't really needed, we
can keep the highest allocated format code in a comment instead.
--
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: [RFC/PATCH 5/9] v4l: Create v4l2 subdev file handle structure
Hi Hans,
On Sunday 26 September 2010 19:25:26 Hans Verkuil wrote:
On Sunday, September 26, 2010 18:13:28 Laurent Pinchart wrote:
From: Stanimir Varbanov svarba...@mm-sol.com
Used for storing subdev information per file handle and hold V4L2 file
handle.
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
Signed-off-by: Antti Koskipaa antti.koski...@nokia.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-subdev.c | 82
+ include/media/v4l2-subdev.h
| 25 +++
2 files changed, 80 insertions(+), 27 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c index 731dc12..d2891c1 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -30,38 +30,66 @@
#include media/v4l2-fh.h
#include media/v4l2-event.h
+static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev
*sd) +{
+ /* Allocate probe format and crop in the same memory block */
+ fh-probe_fmt = kzalloc((sizeof(*fh-probe_fmt) +
+ sizeof(*fh-probe_crop)) * sd-entity.num_pads,
+ GFP_KERNEL);
+ if (fh-probe_fmt == NULL)
+ return -ENOMEM;
I really don't like the name 'probe' for this. I remember discussing it
with you, Laurent, but I can't remember the word I came up with.
Can you remember what it was?
I remember a discussion, but we haven't agreed on a name. Do you dislike both
probe and active, or probe only ?
(BTW the name comes from the UVC spec, where a similar mechanism is used)
--
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: [RFC/PATCH 2/9] v4l: Group media bus pixel codes by types and sort them alphabetically
On Sunday, September 26, 2010 19:34:49 Laurent Pinchart wrote:
Hi Hans,
On Sunday 26 September 2010 19:29:53 Hans Verkuil wrote:
On Sunday, September 26, 2010 18:13:25 Laurent Pinchart wrote:
Adding new pixel codes at the end of the enumeration will soon create a
mess, so sort the pixel codes by type and then sort them alphabetically.
As the codes are part of the kernel ABI their value can't change when a
new code is inserted in the enumeration, so they are given an explicit
numerical value. When inserting a new pixel code developers must use and
update the V4L2_MBUS_FMT_LAST value.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h | 54
1 files changed, 32
insertions(+), 22 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h
b/include/linux/v4l2-mediabus.h index 127512a..bc637a5 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -24,31 +24,41 @@
* transferred first, BE means that the most significant bits are
transferred * first, and PADHI and PADLO define which bits - low
or high, in the * incomplete high byte, are filled with padding bits.
+ *
+ * The pixel codes are grouped by types and (mostly) sorted
alphabetically. As + * their value can't change when a new pixel code is
inserted in the + * enumeration, they are explicitly given a numerical
value. When inserting a + * new pixel code use and update the
V4L2_MBUS_FMT_LAST value.
*/
enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_FIXED = 1,
- V4L2_MBUS_FMT_YUYV8_2X8,
- V4L2_MBUS_FMT_YVYU8_2X8,
- V4L2_MBUS_FMT_UYVY8_2X8,
- V4L2_MBUS_FMT_VYUY8_2X8,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
- V4L2_MBUS_FMT_RGB565_2X8_LE,
- V4L2_MBUS_FMT_RGB565_2X8_BE,
- V4L2_MBUS_FMT_SBGGR8_1X8,
- V4L2_MBUS_FMT_SBGGR10_1X10,
- V4L2_MBUS_FMT_GREY8_1X8,
- V4L2_MBUS_FMT_Y10_1X10,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
- V4L2_MBUS_FMT_SGRBG8_1X8,
- V4L2_MBUS_FMT_SBGGR12_1X12,
- V4L2_MBUS_FMT_YUYV8_1_5X8,
- V4L2_MBUS_FMT_YVYU8_1_5X8,
- V4L2_MBUS_FMT_UYVY8_1_5X8,
- V4L2_MBUS_FMT_VYUY8_1_5X8,
+ /* RGB */
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 7,
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 6,
+ V4L2_MBUS_FMT_RGB565_2X8_BE = 9,
+ V4L2_MBUS_FMT_RGB565_2X8_LE = 8,
+ /* YUV (including grey) */
+ V4L2_MBUS_FMT_GREY8_1X8 = 12,
+ V4L2_MBUS_FMT_Y10_1X10 = 13,
+ V4L2_MBUS_FMT_YUYV8_1_5X8 = 20,
+ V4L2_MBUS_FMT_YVYU8_1_5X8 = 21,
+ V4L2_MBUS_FMT_UYVY8_1_5X8 = 22,
+ V4L2_MBUS_FMT_VYUY8_1_5X8 = 23,
+ V4L2_MBUS_FMT_YUYV8_2X8 = 2,
+ V4L2_MBUS_FMT_UYVY8_2X8 = 4,
+ V4L2_MBUS_FMT_YVYU8_2X8 = 3,
+ V4L2_MBUS_FMT_VYUY8_2X8 = 5,
+ /* Bayer */
+ V4L2_MBUS_FMT_SBGGR8_1X8 = 10,
+ V4L2_MBUS_FMT_SBGGR10_1X10 = 11,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 16,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 14,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 17,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 15,
+ V4L2_MBUS_FMT_SBGGR12_1X12 = 19,
+ V4L2_MBUS_FMT_SGRBG8_1X8 = 18,
Why on earth would you want to keep the original values? It was internal
only, so no need to stick to the old values.
Good point :-)
Just let RGB start at 1000, YUV at 2000 and Bayer at 3000 or something like
that.
+ /* Last - Update this when adding a new pixel code */
+ V4L2_MBUS_FMT_LAST = 24,
Why would you need this?
We've discussed this in the past. Keeping holes won't help, as we will have
to
insert formats in places where we won't have holes sooner or later. We agreed
that it was better to keep the list organized by format, as that's easier to
read. V4L2_MBUS_FMT_LAST is thus a shortcut to avoid searching for the
highest
format when adding a new one. As the constant itself isn't really needed, we
can keep the highest allocated format code in a comment instead.
I would definitely make it a comment. Actually, a counter should be kept per
section. It might actually be useful in the future if you can do something like:
if ((mbus_fmt MBUS_FMT_TYPE_MASK) == MBUS_FMT_TYPE_YUV)
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/9] v4l: Group media bus pixel codes by types and sort them alphabetically
Hi Hans,
On Sunday 26 September 2010 19:44:38 Hans Verkuil wrote:
On Sunday, September 26, 2010 19:34:49 Laurent Pinchart wrote:
On Sunday 26 September 2010 19:29:53 Hans Verkuil wrote:
On Sunday, September 26, 2010 18:13:25 Laurent Pinchart wrote:
Adding new pixel codes at the end of the enumeration will soon create
a mess, so sort the pixel codes by type and then sort them
alphabetically.
As the codes are part of the kernel ABI their value can't change when
a new code is inserted in the enumeration, so they are given an
explicit numerical value. When inserting a new pixel code developers
must use and update the V4L2_MBUS_FMT_LAST value.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h | 54
1 files changed, 32
insertions(+), 22 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h
b/include/linux/v4l2-mediabus.h index 127512a..bc637a5 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -24,31 +24,41 @@
* transferred first, BE means that the most significant bits are
transferred * first, and PADHI and PADLO define which bits -
low or high, in the * incomplete high byte, are filled with
padding bits.
+ *
+ * The pixel codes are grouped by types and (mostly) sorted
alphabetically. As + * their value can't change when a new pixel code
is inserted in the + * enumeration, they are explicitly given a
numerical value. When inserting a + * new pixel code use and update
the V4L2_MBUS_FMT_LAST value.
*/
enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_FIXED = 1,
- V4L2_MBUS_FMT_YUYV8_2X8,
- V4L2_MBUS_FMT_YVYU8_2X8,
- V4L2_MBUS_FMT_UYVY8_2X8,
- V4L2_MBUS_FMT_VYUY8_2X8,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
- V4L2_MBUS_FMT_RGB565_2X8_LE,
- V4L2_MBUS_FMT_RGB565_2X8_BE,
- V4L2_MBUS_FMT_SBGGR8_1X8,
- V4L2_MBUS_FMT_SBGGR10_1X10,
- V4L2_MBUS_FMT_GREY8_1X8,
- V4L2_MBUS_FMT_Y10_1X10,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
- V4L2_MBUS_FMT_SGRBG8_1X8,
- V4L2_MBUS_FMT_SBGGR12_1X12,
- V4L2_MBUS_FMT_YUYV8_1_5X8,
- V4L2_MBUS_FMT_YVYU8_1_5X8,
- V4L2_MBUS_FMT_UYVY8_1_5X8,
- V4L2_MBUS_FMT_VYUY8_1_5X8,
+ /* RGB */
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 7,
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 6,
+ V4L2_MBUS_FMT_RGB565_2X8_BE = 9,
+ V4L2_MBUS_FMT_RGB565_2X8_LE = 8,
+ /* YUV (including grey) */
+ V4L2_MBUS_FMT_GREY8_1X8 = 12,
+ V4L2_MBUS_FMT_Y10_1X10 = 13,
+ V4L2_MBUS_FMT_YUYV8_1_5X8 = 20,
+ V4L2_MBUS_FMT_YVYU8_1_5X8 = 21,
+ V4L2_MBUS_FMT_UYVY8_1_5X8 = 22,
+ V4L2_MBUS_FMT_VYUY8_1_5X8 = 23,
+ V4L2_MBUS_FMT_YUYV8_2X8 = 2,
+ V4L2_MBUS_FMT_UYVY8_2X8 = 4,
+ V4L2_MBUS_FMT_YVYU8_2X8 = 3,
+ V4L2_MBUS_FMT_VYUY8_2X8 = 5,
+ /* Bayer */
+ V4L2_MBUS_FMT_SBGGR8_1X8 = 10,
+ V4L2_MBUS_FMT_SBGGR10_1X10 = 11,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 16,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 14,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 17,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 15,
+ V4L2_MBUS_FMT_SBGGR12_1X12 = 19,
+ V4L2_MBUS_FMT_SGRBG8_1X8 = 18,
Why on earth would you want to keep the original values? It was
internal only, so no need to stick to the old values.
Good point :-)
Just let RGB start at 1000, YUV at 2000 and Bayer at 3000 or something
like that.
+ /* Last - Update this when adding a new pixel code */
+ V4L2_MBUS_FMT_LAST = 24,
Why would you need this?
We've discussed this in the past. Keeping holes won't help, as we will
have to insert formats in places where we won't have holes sooner or
later. We agreed that it was better to keep the list organized by
format, as that's easier to read. V4L2_MBUS_FMT_LAST is thus a shortcut
to avoid searching for the highest format when adding a new one. As the
constant itself isn't really needed, we can keep the highest allocated
format code in a comment instead.
I would definitely make it a comment.
OK.
Actually, a counter should be kept per section. It might actually be useful
in the future if you can do something like:
if ((mbus_fmt MBUS_FMT_TYPE_MASK) == MBUS_FMT_TYPE_YUV)
I'm not sure I like the concept of sections. How do you define what a section
is ?
--
Regards,
Laurent Pinchart
--
To
Re: [RFC/PATCH 5/9] v4l: Create v4l2 subdev file handle structure
On Sunday, September 26, 2010 19:35:49 Laurent Pinchart wrote:
Hi Hans,
On Sunday 26 September 2010 19:25:26 Hans Verkuil wrote:
On Sunday, September 26, 2010 18:13:28 Laurent Pinchart wrote:
From: Stanimir Varbanov svarba...@mm-sol.com
Used for storing subdev information per file handle and hold V4L2 file
handle.
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
Signed-off-by: Antti Koskipaa antti.koski...@nokia.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-subdev.c | 82
+ include/media/v4l2-subdev.h
| 25 +++
2 files changed, 80 insertions(+), 27 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c index 731dc12..d2891c1 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -30,38 +30,66 @@
#include media/v4l2-fh.h
#include media/v4l2-event.h
+static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev
*sd) +{
+ /* Allocate probe format and crop in the same memory block */
+ fh-probe_fmt = kzalloc((sizeof(*fh-probe_fmt) +
+ sizeof(*fh-probe_crop)) * sd-entity.num_pads,
+ GFP_KERNEL);
+ if (fh-probe_fmt == NULL)
+ return -ENOMEM;
I really don't like the name 'probe' for this. I remember discussing it
with you, Laurent, but I can't remember the word I came up with.
Can you remember what it was?
I remember a discussion, but we haven't agreed on a name. Do you dislike both
probe and active, or probe only ?
(BTW the name comes from the UVC spec, where a similar mechanism is used)
I'll see if I can dig it up in my irc logs tomorrow.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/9] v4l: Group media bus pixel codes by types and sort them alphabetically
On Sunday, September 26, 2010 19:51:22 Laurent Pinchart wrote:
Hi Hans,
On Sunday 26 September 2010 19:44:38 Hans Verkuil wrote:
On Sunday, September 26, 2010 19:34:49 Laurent Pinchart wrote:
On Sunday 26 September 2010 19:29:53 Hans Verkuil wrote:
On Sunday, September 26, 2010 18:13:25 Laurent Pinchart wrote:
Adding new pixel codes at the end of the enumeration will soon create
a mess, so sort the pixel codes by type and then sort them
alphabetically.
As the codes are part of the kernel ABI their value can't change when
a new code is inserted in the enumeration, so they are given an
explicit numerical value. When inserting a new pixel code developers
must use and update the V4L2_MBUS_FMT_LAST value.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h | 54
1 files changed, 32
insertions(+), 22 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h
b/include/linux/v4l2-mediabus.h index 127512a..bc637a5 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -24,31 +24,41 @@
* transferred first, BE means that the most significant bits are
transferred * first, and PADHI and PADLO define which bits -
low or high, in the * incomplete high byte, are filled with
padding bits.
+ *
+ * The pixel codes are grouped by types and (mostly) sorted
alphabetically. As + * their value can't change when a new pixel code
is inserted in the + * enumeration, they are explicitly given a
numerical value. When inserting a + * new pixel code use and update
the V4L2_MBUS_FMT_LAST value.
*/
enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_FIXED = 1,
- V4L2_MBUS_FMT_YUYV8_2X8,
- V4L2_MBUS_FMT_YVYU8_2X8,
- V4L2_MBUS_FMT_UYVY8_2X8,
- V4L2_MBUS_FMT_VYUY8_2X8,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
- V4L2_MBUS_FMT_RGB565_2X8_LE,
- V4L2_MBUS_FMT_RGB565_2X8_BE,
- V4L2_MBUS_FMT_SBGGR8_1X8,
- V4L2_MBUS_FMT_SBGGR10_1X10,
- V4L2_MBUS_FMT_GREY8_1X8,
- V4L2_MBUS_FMT_Y10_1X10,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
- V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
- V4L2_MBUS_FMT_SGRBG8_1X8,
- V4L2_MBUS_FMT_SBGGR12_1X12,
- V4L2_MBUS_FMT_YUYV8_1_5X8,
- V4L2_MBUS_FMT_YVYU8_1_5X8,
- V4L2_MBUS_FMT_UYVY8_1_5X8,
- V4L2_MBUS_FMT_VYUY8_1_5X8,
+ /* RGB */
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 7,
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 6,
+ V4L2_MBUS_FMT_RGB565_2X8_BE = 9,
+ V4L2_MBUS_FMT_RGB565_2X8_LE = 8,
+ /* YUV (including grey) */
+ V4L2_MBUS_FMT_GREY8_1X8 = 12,
+ V4L2_MBUS_FMT_Y10_1X10 = 13,
+ V4L2_MBUS_FMT_YUYV8_1_5X8 = 20,
+ V4L2_MBUS_FMT_YVYU8_1_5X8 = 21,
+ V4L2_MBUS_FMT_UYVY8_1_5X8 = 22,
+ V4L2_MBUS_FMT_VYUY8_1_5X8 = 23,
+ V4L2_MBUS_FMT_YUYV8_2X8 = 2,
+ V4L2_MBUS_FMT_UYVY8_2X8 = 4,
+ V4L2_MBUS_FMT_YVYU8_2X8 = 3,
+ V4L2_MBUS_FMT_VYUY8_2X8 = 5,
+ /* Bayer */
+ V4L2_MBUS_FMT_SBGGR8_1X8 = 10,
+ V4L2_MBUS_FMT_SBGGR10_1X10 = 11,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 16,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 14,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 17,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 15,
+ V4L2_MBUS_FMT_SBGGR12_1X12 = 19,
+ V4L2_MBUS_FMT_SGRBG8_1X8 = 18,
Why on earth would you want to keep the original values? It was
internal only, so no need to stick to the old values.
Good point :-)
Just let RGB start at 1000, YUV at 2000 and Bayer at 3000 or something
like that.
+ /* Last - Update this when adding a new pixel code */
+ V4L2_MBUS_FMT_LAST = 24,
Why would you need this?
We've discussed this in the past. Keeping holes won't help, as we will
have to insert formats in places where we won't have holes sooner or
later. We agreed that it was better to keep the list organized by
format, as that's easier to read. V4L2_MBUS_FMT_LAST is thus a shortcut
to avoid searching for the highest format when adding a new one. As the
constant itself isn't really needed, we can keep the highest allocated
format code in a comment instead.
I would definitely make it a comment.
OK.
Actually, a counter should be kept per section. It might actually be useful
in the future if you can do something like:
if ((mbus_fmt MBUS_FMT_TYPE_MASK) == MBUS_FMT_TYPE_YUV)
I'm not sure I like the concept of
Re: [PATCH] DiSEqC bug fixed for stv0288 based interfaces
Hi Josef
This patch does work and has been tested in my driver.
However, your patch was still corrupt, here is a cleaned up version.
I have had to shorten some quotes in some lines to within 80 characters
Tested-by: Malcolm Priestley tvbox...@gmail.com
It is also in my own hg tree at
http://mercurial.intuxication.org/hg/tvboxspy/rev/666fe763c5f6
diff --git a/drivers/media/dvb/frontends/stv0288.c
b/drivers/media/dvb/frontends/stv0288.c
index 2930a5d..6cd442e 100644
--- a/drivers/media/dvb/frontends/stv0288.c
+++ b/drivers/media/dvb/frontends/stv0288.c
@@ -6,6 +6,8 @@
Copyright (C) 2008 Igor M. Liplianin liplia...@me.by
Removed stb6000 specific tuner code and revised some
procedures.
+ 2010-09-01 Josef Pavlik jo...@pavlik.it
+ Fixed diseqc_msg, diseqc_burst and set_tone problems
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
@@ -156,14 +158,13 @@ static int stv0288_send_diseqc_msg(struct dvb_frontend
*fe,
stv0288_writeregI(state, 0x09, 0);
msleep(30);
- stv0288_writeregI(state, 0x05, 0x16);
+ stv0288_writeregI(state, 0x05, 0x12);/* modulated mode, single shot */
for (i = 0; i m-msg_len; i++) {
if (stv0288_writeregI(state, 0x06, m-msg[i]))
return -EREMOTEIO;
- msleep(12);
}
-
+ msleep(m-msg_len*12);
return 0;
}
@@ -174,13 +175,14 @@ static int stv0288_send_diseqc_burst(struct dvb_frontend
*fe,
dprintk(%s\n, __func__);
- if (stv0288_writeregI(state, 0x05, 0x16))/* burst mode */
- return -EREMOTEIO;
-
- if (stv0288_writeregI(state, 0x06, burst == SEC_MINI_A ? 0x00 : 0xff))
+ if (stv0288_writeregI(state, 0x05, 0x03))/* burst mode, single shot */
+ return -EREMOTEIO;
+
+ if (stv0288_writeregI(state, 0x06, burst == SEC_MINI_A ? 0x00 : 0xff))
return -EREMOTEIO;
- if (stv0288_writeregI(state, 0x06, 0x12))
+ msleep(15);
+ if (stv0288_writeregI(state, 0x05, 0x12))
return -EREMOTEIO;
return 0;
@@ -192,18 +194,19 @@ static int stv0288_set_tone(struct dvb_frontend *fe,
fe_sec_tone_mode_t tone)
switch (tone) {
case SEC_TONE_ON:
- if (stv0288_writeregI(state, 0x05, 0x10))/* burst mode */
+ if (stv0288_writeregI(state, 0x05, 0x10))/* cont carrier */
return -EREMOTEIO;
- return stv0288_writeregI(state, 0x06, 0xff);
+ break;
case SEC_TONE_OFF:
- if (stv0288_writeregI(state, 0x05, 0x13))/* burst mode */
+ if (stv0288_writeregI(state, 0x05, 0x12))/* burst mode off*/
return -EREMOTEIO;
- return stv0288_writeregI(state, 0x06, 0x00);
+ break;
default:
return -EINVAL;
}
+ return 0;
}
static u8 stv0288_inittab[] = {
sorry, but something eats the leading spaces (but no the tabs) in the inlined
patch making it unusable, so please use the attached one.
-
on Sep 12, 2010, at 13:30, I wrote:
seems that the patch was corrupted by the kmail used for the post (missing
space before the last close bracket resulting corrupted patch)
the corrected patch follows (and I'm sending it with another mail program)
Signed-off-by: Josef Pavlik jo...@pavlik.it
-
diff --git a/drivers/media/dvb/frontends/stv0288.c
b/drivers/media/dvb/frontends/stv0288.c
index 2930a5d..6cd442e 100644
--- a/drivers/media/dvb/frontends/stv0288.c
+++ b/drivers/media/dvb/frontends/stv0288.c
@@ -6,6 +6,8 @@
Copyright (C) 2008 Igor M. Liplianin liplia...@me.by
Removed stb6000 specific tuner code and revised some
procedures.
+2010-09-01 Josef Pavlik jo...@pavlik.it
+Fixed diseqc_msg, diseqc_burst and set_tone problems
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
@@ -156,14 +158,13 @@ static int stv0288_send_diseqc_msg(struct dvb_frontend
*fe,
stv0288_writeregI(state, 0x09, 0);
msleep(30);
- stv0288_writeregI(state, 0x05, 0x16);
+ stv0288_writeregI(state, 0x05, 0x12); /* modulated mode, single shot
*/
for (i = 0; i m-msg_len; i++) {
if (stv0288_writeregI(state, 0x06, m-msg[i]))
return -EREMOTEIO;
- msleep(12);
}
-
+msleep(m-msg_len*12);
return 0;
}
@@ -174,13 +175,14 @@ static int stv0288_send_diseqc_burst(struct
dvb_frontend
*fe,
dprintk(%s\n, __func__);
- if (stv0288_writeregI(state, 0x05, 0x16))/* burst mode */
- return
Re: [RFC/PATCH 8/9] v4l: v4l2_subdev userspace frame interval API
On Sunday, September 26, 2010 18:13:31 Laurent Pinchart wrote: The three new ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL, VIDIOC_SUBDEV_G_FRAME_INTERVAL and VIDIOC_SUBDEV_S_FRAME_INTERVAL can be used to enumerate and configure a subdev's frame rate from userspace. Two new video::g/s_frame_interval subdev operations are introduced to support those ioctls. The existing video::g/s_parm operations are deprecated and shouldn't be used anymore. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- Documentation/DocBook/media-entities.tmpl |6 + Documentation/DocBook/v4l/v4l2.xml |2 + .../v4l/vidioc-subdev-enum-frame-interval.xml | 147 .../DocBook/v4l/vidioc-subdev-g-frame-interval.xml | 135 ++ drivers/media/video/v4l2-subdev.c | 16 ++ include/linux/v4l2-subdev.h| 36 + include/media/v4l2-subdev.h|7 + 7 files changed, 349 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 160bca6..71cdc75 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -89,7 +89,9 @@ !ENTITY VIDIOC-SUBDEV-ENUM-FRAME-SIZE link linkend='vidioc-subdev-enum-frame-size'constantVIDIOC_SUBDEV_ENUM_FRAME_SIZE/constant/link !ENTITY VIDIOC-SUBDEV-ENUM-MBUS-CODE link linkend='vidioc-subdev-enum-mbus-code'constantVIDIOC_SUBDEV_ENUM_MBUS_CODE/constant/link !ENTITY VIDIOC-SUBDEV-G-FMT link linkend='vidioc-subdev-g-fmt'constantVIDIOC_SUBDEV_G_FMT/constant/link +!ENTITY VIDIOC-SUBDEV-G-FRAME-INTERVAL link linkend='vidioc-subdev-g-frame-interval'constantVIDIOC_SUBDEV_G_FRAME_INTERVAL/constant/link !ENTITY VIDIOC-SUBDEV-S-FMT link linkend='vidioc-subdev-g-fmt'constantVIDIOC_SUBDEV_S_FMT/constant/link +!ENTITY VIDIOC-SUBDEV-S-FRAME-INTERVAL link linkend='vidioc-subdev-g-frame-interval'constantVIDIOC_SUBDEV_S_FRAME_INTERVAL/constant/link !ENTITY VIDIOC-TRY-ENCODER-CMD link linkend='vidioc-encoder-cmd'constantVIDIOC_TRY_ENCODER_CMD/constant/link !ENTITY VIDIOC-TRY-EXT-CTRLS link linkend='vidioc-g-ext-ctrls'constantVIDIOC_TRY_EXT_CTRLS/constant/link !ENTITY VIDIOC-TRY-FMT link linkend='vidioc-g-fmt'constantVIDIOC_TRY_FMT/constant/link @@ -190,6 +192,8 @@ !ENTITY v4l2-sliced-vbi-cap structnbsp;link linkend='v4l2-sliced-vbi-cap'v4l2_sliced_vbi_cap/link !ENTITY v4l2-sliced-vbi-data structnbsp;link linkend='v4l2-sliced-vbi-data'v4l2_sliced_vbi_data/link !ENTITY v4l2-sliced-vbi-format structnbsp;link linkend='v4l2-sliced-vbi-format'v4l2_sliced_vbi_format/link +!ENTITY v4l2-subdev-frame-interval structnbsp;link linkend='v4l2-subdev-frame-interval'v4l2_subdev_frame_interval/link +!ENTITY v4l2-subdev-frame-interval-enum structnbsp;link linkend='v4l2-subdev-frame-interval-enum'v4l2_subdev_frame_interval_enum/link !ENTITY v4l2-subdev-frame-size-enum structnbsp;link linkend='v4l2-subdev-frame-size-enum'v4l2_subdev_frame_size_enum/link !ENTITY v4l2-subdev-format structnbsp;link linkend='v4l2-subdev-format'v4l2_subdev_format/link !ENTITY v4l2-subdev-mbus-code-enum structnbsp;link linkend='v4l2-subdev-mbus-code-enum'v4l2_subdev_mbus_code_enum/link @@ -322,10 +326,12 @@ !ENTITY sub-reqbufs SYSTEM v4l/vidioc-reqbufs.xml !ENTITY sub-s-hw-freq-seek SYSTEM v4l/vidioc-s-hw-freq-seek.xml !ENTITY sub-streamon SYSTEM v4l/vidioc-streamon.xml +!ENTITY sub-subdev-enum-frame-interval SYSTEM v4l/vidioc-subdev-enum-frame-interval.xml !ENTITY sub-subdev-enum-frame-size SYSTEM v4l/vidioc-subdev-enum-frame-size.xml !ENTITY sub-subdev-enum-mbus-code SYSTEM v4l/vidioc-subdev-enum-mbus-code.xml !ENTITY sub-subdev-formats SYSTEM v4l/subdev-formats.xml !ENTITY sub-subdev-g-fmt SYSTEM v4l/vidioc-subdev-g-fmt.xml +!ENTITY sub-subdev-g-frame-interval SYSTEM v4l/vidioc-subdev-g-frame-interval.xml !ENTITY sub-capture-c SYSTEM v4l/capture.c.xml !ENTITY sub-keytable-c SYSTEM v4l/keytable.c.xml !ENTITY sub-v4l2grab-c SYSTEM v4l/v4l2grab.c.xml diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 3a59b82..7806562 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -470,9 +470,11 @@ and discussions on the V4L mailing list./revremark sub-reqbufs; sub-s-hw-freq-seek; sub-streamon; +sub-subdev-enum-frame-interval; sub-subdev-enum-frame-size; sub-subdev-enum-mbus-code; sub-subdev-g-fmt; +sub-subdev-g-frame-interval; sub-subscribe-event; !-- End of ioctls. -- sub-mmap; diff --git
[cron job] v4l-dvb daily build 2.6.26 and up: 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:Sun Sep 26 19:00:10 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15164:1da5fed5c8b2 git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: dace3857de7a16b83ae7d4e13c94de8e4b267d2a gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.36-rc2-armv5: ERRORS linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35.3-armv5-davinci: WARNINGS linux-2.6.36-rc2-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35.3-armv5-ixp: WARNINGS linux-2.6.36-rc2-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35.3-armv5-omap2: WARNINGS linux-2.6.36-rc2-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-rc2-i686: ERRORS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.36-rc2-m32r: ERRORS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.36-rc2-mips: ERRORS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.36-rc2-powerpc64: ERRORS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-rc2-x86_64: ERRORS linux-git-Module.symvers: ERRORS linux-git-armv5: ERRORS linux-git-armv5-davinci: ERRORS linux-git-armv5-ixp: ERRORS linux-git-armv5-omap2: ERRORS linux-git-i686: ERRORS linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: ERRORS linux-git-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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: [GIT PATCHES FOR 2.6.37] Remove v4l2-i2c-drv.h and most of i2c-id.h
On Sat, Sep 25, 2010 at 03:09:04AM -0300, Mauro Carvalho Chehab wrote:
Em 23-09-2010 03:14, Hans Verkuil escreveu:
On Thursday, September 23, 2010 06:18:37 Mauro Carvalho Chehab wrote:
Em 15-09-2010 17:00, Hans Verkuil escreveu:
Mauro, Jean, Janne,
After applying this patch series I get the following if I grep for
I2C_HW_ in the kernel sources:
skip some false positives in drivers/gpu
drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
drivers/staging/lirc/lirc_zilog.c: if (ir-c_rx.adapter-id
== I2C_HW_B_HDPVR) {
drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
drivers/staging/lirc/lirc_zilog.c: if (ir-c_rx.adapter-id ==
I2C_HW_B_HDPVR)
Those are with Janne ;)
Since I2C_HW_B_HDPVR is not actually set anywhere and because it's staging,
I'd
propose that we just ignore this. It's under an #ifdef, so removing
i2c-id.h will
not affect this code.
drivers/video/riva/rivafb-i2c.c:chan-adapter.id=
I2C_HW_B_RIVA;
No idea about this one.
This can be removed.
drivers/media/video/ir-kbd-i2c.c: if (ir-c-adapter-id ==
I2C_HW_SAA7134 ir-c-addr == 0x30)
drivers/media/video/saa7134/saa7134-i2c.c: .id=
I2C_HW_SAA7134,
Those are easy: just add the polling interval into the platform_data. If
zero,
uses the default value. I'll write a patch for it.
Nice!
drivers/media/video/ir-kbd-i2c.c: if (adap-id ==
I2C_HW_B_CX2388x) {
This is not hard to solve. I' ll write a patch for it.
Nice!
drivers/staging/lirc/lirc_i2c.c:if (adap-id ==
I2C_HW_B_CX2388x)
drivers/staging/lirc/lirc_i2c.c:if (adap-id ==
I2C_HW_B_CX2388x) {
drivers/media/video/cx88/cx88-i2c.c:core-i2c_adap.id =
I2C_HW_B_CX2388x;
drivers/media/video/cx88/cx88-vp3054-i2c.c: vp3054_i2c-adap.id =
I2C_HW_B_CX2388x;
We need to solve lirc_i2c.c issues before being able to remove those. As
lirc_i2c has
the same implementation as ir-kbd-i2c, it is probably easier to just get
rid of it,
and then remove those two references. Jarod is working on it.
While touching it, I'll move PV951 to bttv driver, and move all IR
initialization code to
bttv-input and cx88-input on those two drivers. This will make life easier
when porting
the code to rc-core, as everything that needs to be changed will be at the
same file.
The above were already merged.
So after my pending tvaudio/tda8425 patch goes in and your patches, then
the only
remaining user of I2C_HW_B_ is lirc_i2c.c, right? Jean will like that :-)
Patch applied. The remaining places are:
drivers/media/video/cx88/cx88-i2c.c: core-i2c_adap.id =
I2C_HW_B_CX2388x;
drivers/media/video/cx88/cx88-vp3054-i2c.c: vp3054_i2c-adap.id =
I2C_HW_B_CX2388x;
drivers/staging/lirc/lirc_i2c.c: if (adap-id == I2C_HW_B_CX2388x)
drivers/staging/lirc/lirc_i2c.c: if (adap-id == I2C_HW_B_CX2388x) {
drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
drivers/staging/lirc/lirc_zilog.c:if (ir-c_rx.adapter-id ==
I2C_HW_B_HDPVR) {
drivers/staging/lirc/lirc_zilog.c:#ifdef I2C_HW_B_HDPVR
drivers/staging/lirc/lirc_zilog.c:if (ir-c_rx.adapter-id ==
I2C_HW_B_HDPVR)
drivers/video/riva/rivafb-i2c.c: chan-adapter.id=
I2C_HW_B_RIVA;
I'll try to review lirc_i2c. Maybe we can just remove it entirely, and then
remove the entries
on cx88 driver.
With lirc_i2c, I think the only hardware we *really* care about is the
Hauppague PVR-150 (variants w/o the zilog chip that includes tx
abilities), PVR-250 and PVR-350. Given that ir-kbd-i2c supports all of
those cards right now, I'm entirely in favor of lirc_i2c just going away.
--
Jarod Wilson
ja...@redhat.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
[RFC PATCH] media: consolidation of -I flags
I have been doing cleanup of makefiles, namely replacing the older style compilation flag variables with the newer style. While doing this, I noticed that the majority of drivers in the media subsystem seem to rely on a few core header files: -Idrivers/media/video -Idrivers/media/common/tuners -Idrivers/media/dvb/dvb-core -Idrivers/media/dvb/frontends This patch removes them from the individual makefiles and puts them in the main makefile under media. Now I realize that not all of the drivers depend on these includes, but most do, and almost everything under video is already being built with these as it is. I can think of a few reasons why this might not be considered a _great_ idea; nevertheless, I still would like to see what everyone else thinks. As an alternative, there could be a split division that does not include the entire media subsystem. Instead, the main makefiles under dvb and video could be modified to handle the needed include flags. dvb/Makefile: subdir-ccflags-y += -Idrivers/media/common/tuners subdir-ccflags-y += -Idrivers/media/dvb/dvb-core subdir-ccflags-y += -Idrivers/media/dvb/frontends ... video/Makefile: subdir-ccflags-y := -Idrivers/media/video subdir-ccflags-y += -Idrivers/media/common/tuners subdir-ccflags-y += -Idrivers/media/dvb/dvb-core subdir-ccflags-y += -Idrivers/media/dvb/frontends ... If neither idea is considered beneficial, I will go ahead and replace the older variables with the newer ones as is. Signed-off-by: matt mooney m...@muteddisk.com --- drivers/media/Makefile |5 + drivers/media/common/tuners/Makefile|3 --- drivers/media/dvb/b2c2/Makefile |3 --- drivers/media/dvb/bt8xx/Makefile|3 --- drivers/media/dvb/dm1105/Makefile |2 -- drivers/media/dvb/dvb-usb/Makefile |5 - drivers/media/dvb/firewire/Makefile |1 - drivers/media/dvb/frontends/Makefile|3 --- drivers/media/dvb/mantis/Makefile |2 -- drivers/media/dvb/ngene/Makefile|4 drivers/media/dvb/pluto2/Makefile |2 -- drivers/media/dvb/pt1/Makefile |2 -- drivers/media/dvb/siano/Makefile|2 -- drivers/media/dvb/ttpci/Makefile|3 --- drivers/media/dvb/ttusb-budget/Makefile |2 -- drivers/media/dvb/ttusb-dec/Makefile|2 -- drivers/media/video/Makefile|4 drivers/media/video/au0828/Makefile |4 drivers/media/video/bt8xx/Makefile |4 drivers/media/video/cx18/Makefile |4 drivers/media/video/cx231xx/Makefile|6 -- drivers/media/video/cx23885/Makefile|5 - drivers/media/video/cx25840/Makefile|2 -- drivers/media/video/cx88/Makefile |5 - drivers/media/video/em28xx/Makefile |6 -- drivers/media/video/hdpvr/Makefile |2 -- drivers/media/video/ivtv/Makefile |6 -- drivers/media/video/pvrusb2/Makefile|5 - drivers/media/video/saa7134/Makefile|5 - drivers/media/video/saa7164/Makefile|5 - drivers/media/video/tlg2300/Makefile|6 -- drivers/media/video/usbvision/Makefile |3 --- 32 files changed, 5 insertions(+), 111 deletions(-) diff --git a/drivers/media/Makefile b/drivers/media/Makefile index 499b081..f271ea9 100644 --- a/drivers/media/Makefile +++ b/drivers/media/Makefile @@ -2,6 +2,11 @@ # Makefile for the kernel multimedia device drivers. # +subdir-ccflags-y := -Idrivers/media/video +subdir-ccflags-y += -Idrivers/media/common/tuners +subdir-ccflags-y += -Idrivers/media/dvb/dvb-core +subdir-ccflags-y += -Idrivers/media/dvb/frontends + obj-y += common/ IR/ video/ obj-$(CONFIG_VIDEO_DEV) += radio/ diff --git a/drivers/media/common/tuners/Makefile b/drivers/media/common/tuners/Makefile index a543852..f6b1358 100644 --- a/drivers/media/common/tuners/Makefile +++ b/drivers/media/common/tuners/Makefile @@ -24,6 +24,3 @@ obj-$(CONFIG_MEDIA_TUNER_MXL5005S) += mxl5005s.o obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o - -EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core -EXTRA_CFLAGS += -Idrivers/media/dvb/frontends diff --git a/drivers/media/dvb/b2c2/Makefile b/drivers/media/dvb/b2c2/Makefile index b97cf72..bd2920e 100644 --- a/drivers/media/dvb/b2c2/Makefile +++ b/drivers/media/dvb/b2c2/Makefile @@ -11,6 +11,3 @@ obj-$(CONFIG_DVB_B2C2_FLEXCOP_PCI) += b2c2-flexcop-pci.o b2c2-flexcop-usb-objs = flexcop-usb.o obj-$(CONFIG_DVB_B2C2_FLEXCOP_USB) += b2c2-flexcop-usb.o - -EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core/ -Idrivers/media/dvb/frontends/ -EXTRA_CFLAGS += -Idrivers/media/common/tuners/ diff --git a/drivers/media/dvb/bt8xx/Makefile
Re: Webcam Driver Bug while using two Multilaser Cameras simultaneously
Mauro, first of all I would like to thank you. By using the commands that you told me, I was able to find the problem. Now I need to find a solution. Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 005: ID 04fc:2001 Sunplus Technology Co., Ltd Bus 003 Device 004: ID 04fc:2001 Sunplus Technology Co., Ltd Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 04f2:b015 Chicony Electronics Co., Ltd VGA 24fps UVC Webcam Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub As I showed above, I have 4 USB buses here (two usb 2.0 and two usb 1.1). However, all three external USB ports from my notebook seem to use the same USB bus (Bus 003) and the HP Webcam the Bus 002. When I turn one of the Multilaser cameras on, in one port, the Bus 003 stream uses 80% of the limit. When I turn the another camera on, in a different port, it doesn't work because it uses the same USB bus. Is there a way to change the USB bus from any of my external usb ports? Att, Daniel Bastos Moraes Graduando em Ciência da Computação - Universidade Tiradentes +55 79 88455531 On Fri, Sep 24, 2010 at 10:35 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 23-09-2010 23:19, Daniel Moraes escreveu: Hi Mauro, thanks a lot for your help. I would only take a few more questions. 1. A computer can have more than one USB Bus? As far as I know the USB Bus is unique. Yes, it can have as many bus as designed by the manufacturer. You can also add other buses by buying USB adapter cards. 2. Whereas HP webcam uses the same USB Bus but has a more compressed stream, is there a way to compress or reduce the stream of a webcam that uses a generic driver like the HP Webcam does with your drive? It will depend on the chipset used by the cameras, the screen resolution, and the number of frames per sec. 3. Is there a way to check the amount of bandwich in an USB Bus? Yes. you can watch /proc/bus/usb/devices. It will provide not only the information about each connected device on your usb bus, but also the speed used. For example, a quick test here: $ lsusb Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 003: ID 2040:4200 Hauppauge Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub This machine has 2 USB 2.0 buses (bus 7 and bus 8), with an WinTV USB2 device connected at bus 7, reading a stream at 640x480x30fps: cat /proc/bus/usb/devices showed (I removed the info for the USB 1.1 buses): T: Bus=08 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 2.06 S: Manufacturer=Linux 2.6.35+ ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:00:1d.7 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc=408/800 us (51%), #Int= 0, #Iso= 5 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 2.06 S: Manufacturer=Linux 2.6.35+ ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:00:1a.7 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=07 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2040 ProdID=4200 Rev= 1.00 S: Product=WinTV USB2 S: SerialNumber=0002819348 C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=em28xx E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=128ms E: Ad=82(I) Atr=01(Isoc) MxPS= 0 Ivl=125us E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 0 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=em28xx E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=128ms E: Ad=82(I) Atr=01(Isoc) MxPS=1024 Ivl=125us E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 0 Alt= 2 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=em28xx E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=128ms E: Ad=82(I) Atr=01(Isoc) MxPS=1448 Ivl=125us E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 0 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=ff Driver=em28xx E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=128ms E: Ad=82(I) Atr=01(Isoc)
[PATCH v3] OMAP1: Add support for SoC camera interface
This patch adds a definition of the OMAP1 camera interface platform device,
and a function that allows for providing a board specific platform data.
The device will be used with the upcoming OMAP1 SoC camera interface driver.
Created and tested against linux-2.6.36-rc5 on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Tony,
I hope this now satisfies your requirements.
I resubmit only this updated patch, not the other two, Amstrad Delta specific,
which you have alredy applied. Those are still valid (work for me), only the
not yet merged include/media/omap1_camera.h header file is required for
successfull compilation of board-ams-delta.c. I hope this is not a problem.
I'll submit the driver for Guennadi to push it via the media tree soon.
v2-v3 changes:
requested or inspired by Tony Lindgren (thanks!):
- don't #include mach/camera.h into devices.c in order to allow for
successfull compilation while the camera.h still includes a not yet merged
media/omap1_camera.h,
- move the OMAP1_CAMERA_IOSIZE macro defintion from camera.h to devices.c,
- to remove any remaining mach/camera.h or media/omap1_camera.h
dependencies from devices.c, replace the struct omap1_cam_platform_data *
argument type with a void *, and provide an inline wrapper function in
camera.h that converts back from void * to struct omap1_cam_platform_data *,
suggested by Guennadi Liakhovetski (thanks!):
- try groupping headers according to their location and keeping them sorted
alphabeticaly,
- drop extern qualifier from fuction declaration,
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/devices.c | 43 ++
arch/arm/mach-omap1/include/mach/camera.h | 13 +
2 files changed, 56 insertions(+)
diff -upr linux-2.6.36-rc5.orig/arch/arm/mach-omap1/devices.c
linux-2.6.36-rc5/arch/arm/mach-omap1/devices.c
--- linux-2.6.36-rc5.orig/arch/arm/mach-omap1/devices.c 2010-09-24
15:34:27.0 +0200
+++ linux-2.6.36-rc5/arch/arm/mach-omap1/devices.c 2010-09-25
03:47:55.0 +0200
@@ -9,6 +9,7 @@
* (at your option) any later version.
*/
+#include linux/dma-mapping.h
#include linux/module.h
#include linux/kernel.h
#include linux/init.h
@@ -191,6 +192,48 @@ static inline void omap_init_spi100k(voi
}
#endif
+
+#define OMAP1_CAMERA_BASE 0xfffb6800
+#define OMAP1_CAMERA_IOSIZE0x1c
+
+static struct resource omap1_camera_resources[] = {
+ [0] = {
+ .start = OMAP1_CAMERA_BASE,
+ .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = INT_CAMERA,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device omap1_camera_device = {
+ .name = omap1-camera,
+ .id = 0, /* This is used to put cameras on this interface */
+ .dev= {
+ .dma_mask = omap1_camera_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .num_resources = ARRAY_SIZE(omap1_camera_resources),
+ .resource = omap1_camera_resources,
+};
+
+void __init omap1_camera_init(void *info)
+{
+ struct platform_device *dev = omap1_camera_device;
+ int ret;
+
+ dev-dev.platform_data = info;
+
+ ret = platform_device_register(dev);
+ if (ret)
+ dev_err(dev-dev, unable to register device: %d\n, ret);
+}
+
+
/*-*/
static inline void omap_init_sti(void) {}
diff -upr linux-2.6.36-rc5.orig/arch/arm/mach-omap1/include/mach/camera.h
linux-2.6.36-rc5/arch/arm/mach-omap1/include/mach/camera.h
--- linux-2.6.36-rc5.orig/arch/arm/mach-omap1/include/mach/camera.h
2010-09-24 15:39:07.0 +0200
+++ linux-2.6.36-rc5/arch/arm/mach-omap1/include/mach/camera.h 2010-09-25
03:19:12.0 +0200
@@ -0,0 +1,13 @@
+#ifndef __ASM_ARCH_CAMERA_H_
+#define __ASM_ARCH_CAMERA_H_
+
+#include media/omap1_camera.h
+
+void omap1_camera_init(void *);
+
+static inline void omap1_set_camera_info(struct omap1_cam_platform_data *info)
+{
+ omap1_camera_init(info);
+}
+
+#endif /* __ASM_ARCH_CAMERA_H_ */
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Webcam Driver Bug while using two Multilaser Cameras simultaneously
Em 26-09-2010 21:29, Daniel Moraes escreveu: Mauro, first of all I would like to thank you. By using the commands that you told me, I was able to find the problem. Now I need to find a solution. Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 005: ID 04fc:2001 Sunplus Technology Co., Ltd Bus 003 Device 004: ID 04fc:2001 Sunplus Technology Co., Ltd Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 04f2:b015 Chicony Electronics Co., Ltd VGA 24fps UVC Webcam Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub As I showed above, I have 4 USB buses here (two usb 2.0 and two usb 1.1). However, all three external USB ports from my notebook seem to use the same USB bus (Bus 003) and the HP Webcam the Bus 002. When I turn one of the Multilaser cameras on, in one port, the Bus 003 stream uses 80% of the limit. When I turn the another camera on, in a different port, it doesn't work because it uses the same USB bus. Is there a way to change the USB bus from any of my external usb ports? In general, you can't. They're hardwired. You'll need to buy an extra USB adapter. There are a few PCMCIA ones, like: http://www.byterunner.com/byterunner/category=PCMCIA+USB+and+Firewire+Cards http://shopping.uol.com.br/pcmcia-usb.html?nortrk=1url=/index.htmllout=47,49psid=1#rmcl There are also some models for Express Card bus. Just be sure to buy one that will work with your notebook (if you're in doubt, you may see http://en.wikipedia.org/wiki/ExpressCard). Att, Daniel Bastos Moraes Graduando em Ciência da Computação - Universidade Tiradentes +55 79 88455531 -- 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 v3 3/6] SoC Camera: add driver for OV6650 sensor
This patch provides a V4L2 SoC Camera driver for OV6650 camera sensor, found on OMAP1 SoC based Amstrad Delta videophone. Since I have no experience with camera sensors, and the sensor documentation I was able to find was not very comprehensive, I left most settings at their default (reset) values, except for: - those required for proper mediabus parameters and picture geometry and format setup, - those used by controls. Resulting picture quality may be far from perfect, but better than nothing. In order to be able to get / set the sensor frame rate from userspace, I decided to provide two not yet SoC camera supported operations, g_parm and s_parm. These can be used after applying patch 4/6 from this series, SoC Camera: add support for g_parm / s_parm operations. Created and tested against linux-2.6.36-rc5 on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- Guennadi, I decided to submit the updated version of the sensor driver first to ensure it is OK before I submit the host interface driver, which I've been able to simplify a lot now when I think I better understand how v4l2 sensors work. Moreover, the OMAP bits are already applied in part by Tony, so there is no need to resubmit the whole set. Thanks, Janusz v2 - v3 changes: requested, suggested or inspired by Guennadi Liakhovetski (thanks again!): - no reason to use msleep_interruptible(1), use a udelay(1000) or even try whether a udelay(100) suffices too (it does); ended up with usleep_range() to better satisfy checkpatch, - drop superfluous parenthesis, - coml_mask and coml_set are only set here and only used once below, so, dropping initialisation to 0 in variable definitions and use a more readable code pattern, - cropcap shouldn't depend on any dynamic (configured by S_FMT) setting, put the full sensor resolution in cropcap, - in struct ov6650 definition, select a better name for the .qcif member, like .half_scale, add comments to both .rect and .half_scale memeber declrations, - use false/true, not 0/1, in boolean asignments, - drop ov6650_reset() and ov6650_prog_dflt() calls from the s_fmt completely, move them over into the ov6650_video_probe(), - in s_crop, also ensure that rect-left and rect-top are within limits, - in s_mbus_fmt, select an input rectangle _closest_ to the currently configured one that would allow to possibly exactly configure the requested output format, then set -rect and -half_scale with new values, - in g_fmt, return -rect scaled with -half_scale other: - in unscaled mode, align all rect members by 2, - don't fail if requested rectangle is out of limits, adjust it instead, - add support for geometry only change to s_fmt, - don't overwrite s_parm requested timeperframe value with the one calculated from platform requested pixel clock limit, use it as another limit, - convert reusable code used for clock divisor calculation into a helper funtion, use it also in g_parm instead of reading the CLKRC register, - no need to copy rect members one by one, use a single assignment of the whole structure, - still a few cosmetic changes. v1 - v2 changes: requested by Guennadi Liakhovetski (thanks!): - include linux/bitops.h if using BIT() macro, - sort headers alphabetically, - don't mix tabs with spaces (preferred) when separating symbols from #define keywords, - drop unused NUM_REGS definition, - optimize SET_SAT() and SAT_MASK macros, - reuse no longer needed function argument instead of declaring a new local variable, - don't touch auto controls when changing their correspondig manual settings, and vice versa, - drop probably unsupported auto-hue control, - initialize sensor by writing registers explicitly instead of using a magic initialization array, - avoid gotos, don't use them other than in failure cases, - make pclk computation more readable, - implement g_mbus_fmt() callback, - correct a few obvious mistakes, - remove a few extra whitespaces, suggested by Ralph Corderoy (thanks!): - use one common format when hex printing register addresses and values, - optimize if(ret) vs. if(!ret) constructs usage, - replace a few if-else constructs with more compact, conditional expression based, when translating controls to register bits, - optimize ov6650_res_roundup(), - drop redundant cast of index from ov6650_enum_fmt(), - use variable identifiers rather than their types as sizeof() arguments, other: - disable band filter, auto exposure control seems working more effectively without it, - refresh against linux-2.6.36-rc3. drivers/media/video/Kconfig |6 drivers/media/video/Makefile|1 drivers/media/video/ov6650.c| 1224 include/media/v4l2-chip-ident.h |1 4 files changed, 1232 insertions(+) diff -upr linux-2.6.36-rc5.orig/drivers/media/video/Kconfig linux-2.6.36-rc5/drivers/media/video/Kconfig --- linux-2.6.36-rc5.orig/drivers/media/video/Kconfig
Re: [PATCH v2] tm6000+audio
Hi
Em 23-09-2010 13:45, Dmitri Belimov escreveu:
Hi
Em 20-09-2010 17:07, Dmitri Belimov escreveu:
Hi
I rework my last patch for audio and now audio works well. This
patch can be submited to GIT tree Quality of audio now is good for
SECAM-DK. For other standard I set some value from datasheet need
some tests.
1. Fix pcm buffer overflow
2. Rework pcm buffer fill method
3. Swap bytes in audio stream
4. Change some registers value for TM6010
5. Change pcm buffer size
--- a/drivers/staging/tm6000/tm6000-stds.c
+++ b/drivers/staging/tm6000/tm6000-stds.c
@@ -96,6 +96,7 @@ static struct tm6000_std_tv_settings tv_stds[]
= {
{TM6010_REQ07_R04_LUMA_HAGC_CONTROL,
0xdc}, {TM6010_REQ07_R0D_CHROMA_KILL_LEVEL, 0x07},
+ {TM6010_REQ08_R05_A_STANDARD_MOD,
0x21}, /* FIXME */
This didn't seem to work for PAL-M. Probably, the right value for
it is 0x22, to follow NTSC/M, since both uses the same audio
standard.
On some tests, I was able to receive some audio there, at the
proper rate, with a tm6010-based device. It died when I tried to
change the channel, so I didn't rear yet the real audio, but I
suspect it will work on my next tests.
Yet, is being hard to test, as the driver has a some spinlock logic
broken. I'm enclosing the logs.
Yes. I have some as crash from mplayer and arecord.
I was able to test only when using a monitor on the same machine.
All trials of using vnc and X11 export ended by not receiving any
audio and hanging the machine.
I suspect that we need to fix the spinlock issue, in order to
better test it.
Who can fix it?
Well, any of us ;)
I did a BKL lock fix series of patches, and hverkuil is improving
them. They'll make easier to avoid problems inside tm6000. We just
need to make sure that we'll hold/release the proper locks at
tm6000-alsa, after applying it at the mainstream.
I found that mplayer crashed when call usb_control_msg and kfree functions.
With my best regards, Dmitry.
--
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: Trouble building v4l-dvb
Em 26-09-2010 13:18, Jan Hoogenraad escreveu: On Linux 2.6.28-19-generic the problem is tackled already: DVB_FIREDTV_IEEE1394: Requires at least kernel 2.6.30 On newer linux versions (I have tried Linux 2.6.32-24-generic) the problem is NOT that the modules dma is not present, it is just that the required header files are not present in /usr/include Another location mighte have been: ls -l /usr/src/linux-headers-2.6.28-19-generic/include/config/ieee1394 This is the right place is whatever pointed on your kernel source alias, like: $ ls -la /lib/modules/2.6.35+/source lrwxrwxrwx. 1 root root 23 Set 26 21:51 /lib/modules/2.6.35+/source - /home/v4l/v4l/patchwork but that only contains: -rw-r--r-- 1 root root0 2010-09-16 18:25 dv1394.h drwxr-xr-x 3 root root 4096 2010-06-15 20:12 eth1394 -rw-r--r-- 1 root root0 2010-09-16 18:25 eth1394.h -rw-r--r-- 1 root root0 2010-09-16 18:25 ohci1394.h -rw-r--r-- 1 root root0 2010-09-16 18:25 pcilynx.h -rw-r--r-- 1 root root0 2010-09-16 18:25 rawio.h -rw-r--r-- 1 root root0 2010-09-16 18:25 sbp2.h -rw-r--r-- 1 root root0 2010-09-16 18:25 video1394.h Can you indicate where following files should be located ? dma.h csr1212.h highlevel.h All of them are at the same place: /lib/modules/2.6.35+/source/drivers/ieee1394/dma.h /lib/modules/2.6.35+/source/drivers/ieee1394/csr1212.h /lib/modules/2.6.35+/source/drivers/ieee1394/highlevel.h In that case checking if the dma.h file is present might be the best way forward. I'll also file an ubuntu bug once I know what is missing where. I could not find an entry in launchpad on this issue yet. This is probably the best thing. A check for dma.h may also work. If you want, do a patch for it and submit to Douglas. 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
