failing videobuf_iolock() in multiple drivers - wrong error processing?
Looking at .buf_prepare() videobuf_queue_ops methods I cannot understand, why if videobuf_iolock() fails they all call some internal buffer freeing function, that, among others, also calls some nideobuf-specific free function... Is this really needed, if yes - why? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Install Sasc-NG in FC12
Hi, I'm trying to install Sasc-NG in my fedora 12. But no luck. It is showing Kernel error. Does anybody installed Sasc-NG in fedora 12 or in latest kernel? Regards, Aslam -- 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: [ANNOUNCE] git tree repositories libv4l
Hi, On 02/24/2010 07:05 AM, Brandon Philips wrote: On 16:51 Tue 23 Feb 2010, Hans de Goede wrote: On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote: Hans de Goede wrote: Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? I added it. In thesis, it is open for commit to you, me, hverkuil and dougsland. I see good, thanks! Can someone (Douglas ?) with better hg / git powers then me please somehow import all the libv4l changes from: http://linuxtv.org/hg/~hgoede/libv4l Once that is done I'll retire my own tree, and move all my userspace work to the git tree. For starters I plan to create / modify Makefiles so that everything will build out of the box, and has proper make install targets which can be used by distro's So: -proper honoring of CFLAGS -work with standard (and possibly somewhat older kernel headers) -honor DESTDIR, PREFIX and LIBDIR when doing make install Do you still want me to convert to autoconf? I was still planning on doing that. We discussed it a month ago when this conversation started. http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15009 I know that was mentioned then, but re-thinking this, as this will all be Linux specific, I don't really see a need for autotools atm, and as I personally find autotools a bit overcomplicated. I would like to try just using plain Makefiles for now. If it turns out this does not work we can always switch to autotools later. Thanks for the offer though! Regards, Hans -- 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: [ANNOUNCE] git tree repositories libv4l
Hi,
On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
Hans de Goede wrote:
Hi,
On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
Hans de Goede wrote:
Ok, so this will give me a local tree, how do I get this onto
linuxtv.org ?
I added it. In thesis, it is open for commit to you, me, hverkuil and
dougsland.
I see good, thanks! Can someone (Douglas ?) with better hg / git powers
then me please
somehow import all the libv4l changes from:
http://linuxtv.org/hg/~hgoede/libv4l
Ok, I added there. The procedure were simple: I ran Brandon script again,
but after pulling from your tree. Then, I used git format-patch to generate
a quilt series, and used git quiltimport on the correct -git tree.
Thanks!
Once that is done I'll retire my own tree, and move all my userspace
work to
the git tree.
For starters I plan to create / modify Makefiles so that everything will
build
out of the box, and has proper make install targets which can be used by
distro's
So:
-proper honoring of CFLAGS
-work with standard (and possibly somewhat older kernel headers)
-honor DESTDIR, PREFIX and LIBDIR when doing make install
The better here is to have the latest kernel headers copied on the tree.
This way, it is possible to compile libv4l2 with an older kernel version and
later upgrade the kernel, if needed, or to use a fast machine to compile
it, and then use it on another machine.
If possible I would like to avoid this, afaik no other userspace utility
packages
are doing this.
Where necessary libv4l currently has code snippets like:
#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
#endif
So libv4l (in its current state) will already compile fine with older kernel
headers. I expect that the other utilities will not need a lot of
recent kernel ABI. So for now I would like to try and extend the above approach
to the other utilities.
The reason for this is that I want to avoid carrying a copy of a dir from some
other tree, with all getting stale and needing sync all the time issues that
come with that, not to mention chicken and egg problems in the case of
new formats which simultaneously need to be added to both libv4l and the
kernel.
For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l, before it
hits any official v4l-dvb kernel tree, with the:
#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
#endif
Approach this works fine, if I were to carry an include tree copy, that would
now need to become a patched include tree copy, and with the next sync I then
need to ensure that any needed patches are either already in the sync source,
or applied again.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V1 09/10] VPFE Capture: Add support for USERPTR mode of operation
On Wed, Feb 24, 2010 at 12:37 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:
-Original Message-
From: Muralidharan Karicheri [mailto:mkarich...@gmail.com]
Sent: Wednesday, February 24, 2010 4:53 AM
To: Hiremath, Vaibhav
Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org;
hverk...@xs4all.nl; Karicheri, Muralidharan
Subject: Re: [PATCH-V1 09/10] VPFE Capture: Add support for USERPTR mode of
operation
Vaibhav,
There are changes to vpfe capture on Arago tree on top of this. For
example, vpfe_uservirt_to_phys() is removed and is replaced with
videobuf_iolock(). So please get the latest changes to upstream.
[Hiremath, Vaibhav] No, the Arago version doesn't support USERPTR mode at all,
Probably you are referring to the wrong tree. This code has gone
through test cycles and I prefer re-using the code as much as
possible. Check out below...
http://arago-project.org/git/people/sneha/linux-davinci-staging.git
My linux-davinci-video.git tree just track the upstream...
Murali
1386 if (V4L2_MEMORY_USERPTR == req_buf-memory) {
1386 /* we don't support user ptr IO */
1387 v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_reqbufs:
1388 USERPTR IO not supported\n);
1389 return -EINVAL;
1390 }
And also, I have received important comment from Mauro, which expects some
code tobe moved to generic VideoBuf layer. I will be submitting patch for the
same separately.
Thanks,
Vaibhav
Murali
On Tue, Feb 23, 2010 at 3:34 AM, hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/ti-media/vpfe_capture.c | 94
++
1 files changed, 79 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/ti-media/vpfe_capture.c
b/drivers/media/video/ti-media/vpfe_capture.c
index cece265..7d4ab44 100644
--- a/drivers/media/video/ti-media/vpfe_capture.c
+++ b/drivers/media/video/ti-media/vpfe_capture.c
@@ -538,7 +538,24 @@ static void vpfe_schedule_next_buffer(struct
vpfe_device *vpfe_dev)
struct videobuf_buffer, queue);
list_del(vpfe_dev-next_frm-queue);
vpfe_dev-next_frm-state = VIDEOBUF_ACTIVE;
- addr = videobuf_to_dma_contig(vpfe_dev-next_frm);
+ if (V4L2_MEMORY_USERPTR == vpfe_dev-memory)
+ addr = vpfe_dev-cur_frm-boff;
+ else
+ addr = videobuf_to_dma_contig(vpfe_dev-next_frm);
+
+ ccdc_dev-hw_ops.setfbaddr(addr);
+}
+
+static void vpfe_schedule_bottom_field(struct vpfe_device *vpfe_dev)
+{
+ unsigned long addr;
+
+ if (V4L2_MEMORY_USERPTR == vpfe_dev-memory)
+ addr = vpfe_dev-cur_frm-boff;
+ else
+ addr = videobuf_to_dma_contig(vpfe_dev-cur_frm);
+
+ addr += vpfe_dev-field_off;
ccdc_dev-hw_ops.setfbaddr(addr);
}
@@ -559,7 +576,6 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
{
struct vpfe_device *vpfe_dev = dev_id;
enum v4l2_field field;
- unsigned long addr;
int fid;
v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, \nStarting
vpfe_isr...\n);
@@ -604,10 +620,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
* the CCDC memory address
*/
if (field == V4L2_FIELD_SEQ_TB) {
- addr =
- videobuf_to_dma_contig(vpfe_dev-
cur_frm);
- addr += vpfe_dev-field_off;
- ccdc_dev-hw_ops.setfbaddr(addr);
+ vpfe_schedule_bottom_field(vpfe_dev);
}
goto clear_intr;
}
@@ -1234,7 +1247,10 @@ static int vpfe_videobuf_setup(struct
videobuf_queue *vq,
struct vpfe_device *vpfe_dev = fh-vpfe_dev;
v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_buffer_setup\n);
- *size = config_params.device_bufsize;
+ *size = vpfe_dev-fmt.fmt.pix.sizeimage;
+ if (vpfe_dev-memory == V4L2_MEMORY_MMAP
+ vpfe_dev-fmt.fmt.pix.sizeimage
config_params.device_bufsize)
+ *size = config_params.device_bufsize;
if (*count config_params.min_numbuffers)
*count = config_params.min_numbuffers;
@@ -1243,6 +1259,46 @@ static int vpfe_videobuf_setup(struct
videobuf_queue *vq,
return 0;
}
+/*
+ * vpfe_uservirt_to_phys: This function is used to convert user
+ * space virtual address to physical address.
+ */
+static u32 vpfe_uservirt_to_phys(struct vpfe_device *vpfe_dev, u32 virtp)
+{
+ struct mm_struct *mm = current-mm;
+ unsigned long physp = 0;
+
Re: Status of the patches under review (29 patches)
Hi Jean, Jean Delvare wrote: I have 3 patches pending which aren't in your list. I can see them in patchwork: http://patchwork.kernel.org/patch/79755/ http://patchwork.kernel.org/patch/79754/ http://patchwork.kernel.org/patch/77349/ The former two are in Accepted state, and actually I received an e-mail telling me they had been accepted, however I can't see them in the hg repository. So where are they? They are already on the git tree: commit 2887117b31b77ebe5fb42f95ea8d77a3716b405b Author: Jean Delvare kh...@linux-fr.org Date: Tue Feb 16 14:22:37 2010 -0300 V4L/DVB: bttv: Let the user disable IR support Add a new module parameter disable_ir to disable IR support. Several other drivers do that already, and this can be very handy for debugging purposes. Signed-off-by: Jean Delvare kh...@linux-fr.org Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com commit e151340a2a9e7147eb48114af0381122130266b0 Author: Jean Delvare kh...@linux-fr.org Date: Fri Feb 19 00:18:41 2010 -0300 V4L/DVB: bttv: Move I2C IR initialization Move I2C IR initialization from just after I2C bus setup to right before non-I2C IR initialization. This avoids the case where an I2C IR device is blocking audio support (at least the PV951 suffers from this). It is also more logical to group IR support together, regardless of the connectivity. This fixes bug #15184: http://bugzilla.kernel.org/show_bug.cgi?id=15184 Signed-off-by: Jean Delvare kh...@linux-fr.org CC: sta...@kernel.org Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com As patches in -hg are manually backported, maybe Douglas haven't backported it yet or he simply missed. Douglas, could you please check this? The latter is in Not Applicable state, and I have no idea what it means. The patch is really simple and I see no formatting issue. Should I just resend it? This means that this patch is not applicable on -git. There's no versions.txt upstream. All patches that don't have upstream code are marked as such on patchwork. I generally ping Douglas on such cases, for him to double check on -hg. Anyway, the better is to c/c to Douglas on all patches that are meant only to the building system. Douglas, could you please check if you've applied this patch? -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] soft demux device
On Wed, 2010-02-24 at 03:57 -0800, ozgur cagdas wrote: Hi, Thanks very much for the previous information. To give it a go just as it is, I've loaded dvb_dummy_fe module manually and many other modules including dvb_core as well, but no hope, don't have /dev/dvb folder yet. As I've mentioned earlier, I do not have a hardware at the moment, so I should trigger loading of proper modules manually. In my scenario, which modules should I load? Any simple set of modules that'd create necessary /dev/dvb/ and subsequent would do for me. If it matters, I am using 2.6.31 kernel and ubuntu 9.10 distribution. See my dvb_dummy_adapter patch I just posted to the list. Regards, Andy Cheers, Ozgur. ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review (29 patches)
On Wed, 2010-02-24 at 02:40 -0300, Mauro Carvalho Chehab wrote: Hi, I suspect that Linus should be releasing the 2.6.33 kernel any time soon, so the next merge window is about to open. I've handled already everything on my pending queues. However, I missed some emails due to a crash on my exim filter. Also, patchwork.kernel.org missed some emails due to some trouble there. So, maybe there are still some unnoticed pending stuff. I had emailed some cx18 component video patches to the list. They are not critical for 2.6.34 but you can find them as the two most recent patches here: http://linuxtv.org/hg/~awalls/cx18-pvr2100-component/ Regards, Andy If you still have any pending work for 2.6.34 that aren't merged nor are under review, please submit it ASAP, as patches received after the release of 2.6.33 will likely be postponed to 2.6.35. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hans de Goede wrote: Hi, On 02/24/2010 07:05 AM, Brandon Philips wrote: On 16:51 Tue 23 Feb 2010, Hans de Goede wrote: On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote: Hans de Goede wrote: Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? I added it. In thesis, it is open for commit to you, me, hverkuil and dougsland. I see good, thanks! Can someone (Douglas ?) with better hg / git powers then me please somehow import all the libv4l changes from: http://linuxtv.org/hg/~hgoede/libv4l Once that is done I'll retire my own tree, and move all my userspace work to the git tree. For starters I plan to create / modify Makefiles so that everything will build out of the box, and has proper make install targets which can be used by distro's So: -proper honoring of CFLAGS -work with standard (and possibly somewhat older kernel headers) -honor DESTDIR, PREFIX and LIBDIR when doing make install Do you still want me to convert to autoconf? I was still planning on doing that. We discussed it a month ago when this conversation started. http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15009 I know that was mentioned then, but re-thinking this, as this will all be Linux specific, I don't really see a need for autotools atm, and as I personally find autotools a bit overcomplicated. I would like to try just using plain Makefiles for now. If it turns out this does not work we can always switch to autotools later. I suspect it won't work fine. There are some library dependencies at utils/contrib, like libsysfs and libqt stuff. The build system should or refuse to compile or disable some of those tools if the dependencies are missing. Of course you may create a non-autotools configure script that checks for those libraries. They aren't many, so this approach works, but it will likely require more time than using autotools. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
Hi,
On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
Hans de Goede wrote:
Hi,
On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
Hans de Goede wrote:
Ok, so this will give me a local tree, how do I get this onto
linuxtv.org ?
I added it. In thesis, it is open for commit to you, me, hverkuil and
dougsland.
I see good, thanks! Can someone (Douglas ?) with better hg / git powers
then me please
somehow import all the libv4l changes from:
http://linuxtv.org/hg/~hgoede/libv4l
Ok, I added there. The procedure were simple: I ran Brandon script
again,
but after pulling from your tree. Then, I used git format-patch to
generate
a quilt series, and used git quiltimport on the correct -git tree.
Thanks!
Once that is done I'll retire my own tree, and move all my userspace
work to
the git tree.
For starters I plan to create / modify Makefiles so that everything
will
build
out of the box, and has proper make install targets which can be used
by
distro's
So:
-proper honoring of CFLAGS
-work with standard (and possibly somewhat older kernel headers)
-honor DESTDIR, PREFIX and LIBDIR when doing make install
The better here is to have the latest kernel headers copied on the tree.
This way, it is possible to compile libv4l2 with an older kernel version
and
later upgrade the kernel, if needed, or to use a fast machine to compile
it, and then use it on another machine.
If possible I would like to avoid this, afaik no other userspace utility
packages
are doing this.
Where necessary libv4l currently has code snippets like:
#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line
*/
#endif
So libv4l (in its current state) will already compile fine with older
kernel
headers. I expect that the other utilities will not need a lot of
recent kernel ABI. So for now I would like to try and extend the above
approach
to the other utilities.
Note that the v4l2-ctl and v4l2-dbg utilities often *do* track the latest
kernel. In particular v4l2-ctl is often used to control/test new features.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: [ANNOUNCE] git tree repositories libv4l
Hans de Goede wrote:
Hi,
On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
Hans de Goede wrote:
Hi,
On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
Hans de Goede wrote:
Ok, so this will give me a local tree, how do I get this onto
linuxtv.org ?
I added it. In thesis, it is open for commit to you, me, hverkuil and
dougsland.
I see good, thanks! Can someone (Douglas ?) with better hg / git powers
then me please
somehow import all the libv4l changes from:
http://linuxtv.org/hg/~hgoede/libv4l
Ok, I added there. The procedure were simple: I ran Brandon script again,
but after pulling from your tree. Then, I used git format-patch to
generate
a quilt series, and used git quiltimport on the correct -git tree.
Thanks!
Once that is done I'll retire my own tree, and move all my userspace
work to
the git tree.
For starters I plan to create / modify Makefiles so that everything will
build
out of the box, and has proper make install targets which can be used by
distro's
So:
-proper honoring of CFLAGS
-work with standard (and possibly somewhat older kernel headers)
-honor DESTDIR, PREFIX and LIBDIR when doing make install
The better here is to have the latest kernel headers copied on the tree.
This way, it is possible to compile libv4l2 with an older kernel
version and
later upgrade the kernel, if needed, or to use a fast machine to compile
it, and then use it on another machine.
If possible I would like to avoid this, afaik no other userspace utility
packages
are doing this.
Where necessary libv4l currently has code snippets like:
#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per
line */
#endif
So libv4l (in its current state) will already compile fine with older
kernel
headers. I expect that the other utilities will not need a lot of
recent kernel ABI. So for now I would like to try and extend the above
approach
to the other utilities.
I think build will fail. I remember I had some such troubles when compiling
it against RHEL5, before we did the merge with the in-tree videodev2.h.
It should be reminded that, when people upgrade their kernels by hand,
they generally don't run make headers_install. So, the kernel headers
on /usr/include/linux are the ones found on the original distro kernel,
and not the ones that are needed by the user.
The reason for this is that I want to avoid carrying a copy of a dir
from some
other tree, with all getting stale and needing sync all the time issues
that
come with that,
The sync problem will keep existing, since some of the tools from
this tree are used as examples on media-specs.
not to mention chicken and egg problems in the case of
new formats which simultaneously need to be added to both libv4l and
the kernel.
For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l,
before it
hits any official v4l-dvb kernel tree, with the:
#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per
line */
#endif
Approach this works fine, if I were to carry an include tree copy, that
would
now need to become a patched include tree copy, and with the next sync I
then
need to ensure that any needed patches are either already in the sync
source,
or applied again.
True, but the additional work for those occasional changes are minimum, and
may save some time when handling complains about why the tree don't build
on his machine.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories libv4l
On 13:55 Wed 24 Feb 2010, Hans de Goede wrote:
On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
Hans de Goede wrote:
The better here is to have the latest kernel headers copied on the tree.
This way, it is possible to compile libv4l2 with an older kernel version and
later upgrade the kernel, if needed, or to use a fast machine to compile
it, and then use it on another machine.
If possible I would like to avoid this, afaik no other userspace
utility packages are doing this.
Off the top of my head I know ethtool does this. It greatly simplifies
the work of maintaing the package:
http://git.kernel.org/?p=network/ethtool/ethtool.git;a=blob;f=ethtool-copy.h;h=09dd5480ff3488214ab67ad04459541314291f79;hb=HEAD
Where necessary libv4l currently has code snippets like:
#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
#endif
I don't think this is less work than copying the header file from the
Kernel. Test building under all versions of the Kernel headers that
exist to make sure something isn't missed isn't possible. It really is
easier just to sync the header file up.
The reason for this is that I want to avoid carrying a copy of a dir
from some other tree, with all getting stale and needing sync all
the time issues that come with that, not to mention chicken and egg
problems in the case of new formats which simultaneously need to be
added to both libv4l and the kernel.
Worst case is that if it is stale then it won't build since it depends
on fancy new feature XYZ. But, at least it won't build on all systems
instead of randomly breaking based on installed kernel headers
version.
For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l, before it
hits any official v4l-dvb kernel tree, with the:
Please don't add features to releases before they are merged with
Linus. It would suck to ship a copy of libv4l that has a different
idea of structs or constants then the upstream Kernel.
Approach this works fine, if I were to carry an include tree copy, that would
now need to become a patched include tree copy, and with the next sync I then
need to ensure that any needed patches are either already in the sync source,
or applied again.
Or just fix it upstream with #ifdef __KERNEL__ tags once and for all,
right?
Cheers,
Brandon
--
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: Requested feedback on V4L2 driver design
Hans, Some follow-up from the syslink team about the driver code in the git tree. The only code to be referred on omapzoom that will actually be in the kernel is the Notify module. All the other code in multicore_ipc will actually move to user-side. The Notify module gives additional functionality over the basic mailbox driver to abstract the single physical event into multiple logical events. This enables multiple clients (one of which is the DSS driver) to use the single physical interrupt for multiple different purposes in a fully modular manner. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, February 09, 2010 1:52 AM To: Mauro Carvalho Chehab; laurent.pinch...@ideasonboard.com Cc: Maupin, Chase; sakari.ai...@maxwell.research.nokia.com; vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver design (May contain non-TIers); linux-media@vger.kernel.org Subject: Re: Requested feedback on V4L2 driver design On Monday 08 February 2010 21:23:00 Mauro Carvalho Chehab wrote: Maupin, Chase wrote: All, Texas Instruments (TI) is working on the design for the V4L2 capture and display drivers for our next generation system-on-chip (SoC) processor and would like to solicit your feedback. Our new SoCs have been improved to allow for higher video resolutions and greater frame rates. To this end the display hardware has been moved to a separate processing block called the video processing subsystem (VPSS). The VPSS will be running a firmware image that controls the capture/display hardware and services requests from one or more host processors. Moving to a remote processor for the processing of video input and output data requires that commands to control the hardware be passed to this processing block using some form of inter-processor communication (IPC). TI would like to solicit your feedback on proposal for the V4L2 driver design to get a feel for whether or not this design would be accepted into the Linux kernel. To this end we have put together an overview of the design and usage on our wiki at http://wiki.davincidsp.com/index.php/Video_Processing_Subsystem_Driver_Des ign. We would greatly appreciate feedback from community members on the acceptability of our driver design. If you have additional questions or need more information please feel free to contact us (we have setup a mailing list at vpss_driver_des...@list.ti.com) so we can answer them. Hi Chase, I'm not sure if I got all the details on your proposal, so let me try to give my understanding. First of all, for normal usage (e.g. capturing a stream or sending an stream to an output device), the driver should work with only the standard V4L2 API. I'm assuming that the driver will provide this capability. I understand that, being a SoC hardware, there are much more that can be done than just doing the normal stream capture/output, already supported by V4L2 API. For such advanced usages, we're open to a proposal to enhance the existing API to support the needs. There are some important aspects that need to be considered when designing any Linux userspace API's: The full functionality of this device can be handled by the proposals made during last year's LPC and that are currently being implemented/prototyped for omap3. That's no coincidence, by the way :-) 1) kernel-userspace API's are forever. So, they need to be designed in a way that new technology changes won't break the old API; 2) API's are meant to be generic. So, they needed to be designed in a way that, if another hardware with similar features require an API, the planned one should fit; 3) The API's should be, as much as possible, independent of the hardware architecture. You'll see that even low-level architecture dependent stuff, like bus drivers are designed in a way that they are not bound to a particular hardware, but instead provide the same common methods to interact with the hardware to other device drivers. That's said, it would be interesting if you could give us a more deep detail on what kind of functionalities and how do you think you'll be implementing them. For me the core issue will be the communication between the main ARM and the ARM controlling the VPSS. Looking at the syslink part of the git tree it all looks way overengineered to me. In particular the multicore_ipc directory. Is all that code involved in setting up the communication path between the main and VPSS ARM? Is there some more detailed document describing how the syslink code works? What I would expect to see is standard mailbox functionality that is used in other places
Re: Requested feedback on V4L2 driver design
On Wednesday 24 February 2010 15:34:19 Maupin, Chase wrote: Hans, Some follow-up from the syslink team about the driver code in the git tree. The only code to be referred on omapzoom that will actually be in the kernel is the Notify module. All the other code in multicore_ipc will actually move to user-side. The Notify module gives additional functionality over the basic mailbox driver to abstract the single physical event into multiple logical events. This enables multiple clients (one of which is the DSS driver) to use the single physical interrupt for multiple different purposes in a fully modular manner. Hi Chase, That is good news. Will it also switch to the standard linux mailbox code? I saw a patch on the omap mailinglist recently that replaced the DSPBRIDGE mailbox code with the kernel mailbox code. I'm not sure whether this is applicable to the Notify code as well, but if it is, then that seems a sensible move. Regards, Hans Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, February 09, 2010 1:52 AM To: Mauro Carvalho Chehab; laurent.pinch...@ideasonboard.com Cc: Maupin, Chase; sakari.ai...@maxwell.research.nokia.com; vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver design (May contain non-TIers); linux-media@vger.kernel.org Subject: Re: Requested feedback on V4L2 driver design On Monday 08 February 2010 21:23:00 Mauro Carvalho Chehab wrote: Maupin, Chase wrote: All, Texas Instruments (TI) is working on the design for the V4L2 capture and display drivers for our next generation system-on-chip (SoC) processor and would like to solicit your feedback. Our new SoCs have been improved to allow for higher video resolutions and greater frame rates. To this end the display hardware has been moved to a separate processing block called the video processing subsystem (VPSS). The VPSS will be running a firmware image that controls the capture/display hardware and services requests from one or more host processors. Moving to a remote processor for the processing of video input and output data requires that commands to control the hardware be passed to this processing block using some form of inter-processor communication (IPC). TI would like to solicit your feedback on proposal for the V4L2 driver design to get a feel for whether or not this design would be accepted into the Linux kernel. To this end we have put together an overview of the design and usage on our wiki at http://wiki.davincidsp.com/index.php/Video_Processing_Subsystem_Driver_Des ign. We would greatly appreciate feedback from community members on the acceptability of our driver design. If you have additional questions or need more information please feel free to contact us (we have setup a mailing list at vpss_driver_des...@list.ti.com) so we can answer them. Hi Chase, I'm not sure if I got all the details on your proposal, so let me try to give my understanding. First of all, for normal usage (e.g. capturing a stream or sending an stream to an output device), the driver should work with only the standard V4L2 API. I'm assuming that the driver will provide this capability. I understand that, being a SoC hardware, there are much more that can be done than just doing the normal stream capture/output, already supported by V4L2 API. For such advanced usages, we're open to a proposal to enhance the existing API to support the needs. There are some important aspects that need to be considered when designing any Linux userspace API's: The full functionality of this device can be handled by the proposals made during last year's LPC and that are currently being implemented/prototyped for omap3. That's no coincidence, by the way :-) 1) kernel-userspace API's are forever. So, they need to be designed in a way that new technology changes won't break the old API; 2) API's are meant to be generic. So, they needed to be designed in a way that, if another hardware with similar features require an API, the planned one should fit; 3) The API's should be, as much as possible, independent of the hardware architecture. You'll see that even low-level architecture dependent stuff, like bus drivers are designed in a way that they are not bound to a particular hardware, but instead provide the same common methods to interact with the hardware to other device drivers. That's said, it would be interesting if you could give us a more deep detail on what kind of functionalities and how do you think you'll be implementing
Re: [ANNOUNCE] git tree repositories libv4l
Hi all, On Wed, 24 Feb 2010, Mauro Carvalho Chehab wrote: I know that was mentioned then, but re-thinking this, as this will all be Linux specific, I don't really see a need for autotools atm, and as I personally find autotools a bit overcomplicated. I would like to try just using plain Makefiles for now. If it turns out this does not work we can always switch to autotools later. I suspect it won't work fine. There are some library dependencies at utils/contrib, like libsysfs and libqt stuff. The build system should or refuse to compile or disable some of those tools if the dependencies are missing. Have a look at cmake: cmake.org . It is extremely powerful in terms of external-library--detection, it can do QT natively and all other things around library generation and dependencies. Cmake has become my favorite build-tool for user-space development. Just my 2cts. -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] cx23885 / HVR 1200 - A/V Inputs?
On Wed, Feb 24, 2010 at 10:24 AM, Jean-Michel Bruenn jean.bru...@ip-minds.de wrote: Hello, i wanted to ask whether theres some progress or status on the cx23885 driver. DVB-T is working fine, however - i'm currently interested into the A/V Inputs. Maybe there's some alpha/beta thing to test? http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1200 Talking about this card and would like to use the A/V Inputs. Hi Jean, No, there hasn't really been any progress in this area. I've started doing some work on the 23885 tree for the HVR-1800, all of which is work applicable for the 1200/1250. But frankly those cards are a relatively low priority on my todo list and I'm only working on it in the background. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] cx23885 / HVR 1200 - A/V Inputs?
Hello Devin, thanks for your answer. Might i be able to help a bit? Whats missing? Cheers, Jean Devin Heitmueller wrote: On Wed, Feb 24, 2010 at 10:24 AM, Jean-Michel Bruenn jean.bru...@ip-minds.de wrote: Hello, i wanted to ask whether theres some progress or status on the cx23885 driver. DVB-T is working fine, however - i'm currently interested into the A/V Inputs. Maybe there's some alpha/beta thing to test? http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1200 Talking about this card and would like to use the A/V Inputs. Hi Jean, No, there hasn't really been any progress in this area. I've started doing some work on the 23885 tree for the HVR-1800, all of which is work applicable for the 1200/1250. But frankly those cards are a relatively low priority on my todo list and I'm only working on it in the background. Cheers, Devin -- 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] cx23885 / HVR 1200 - A/V Inputs?
On Wed, Feb 24, 2010 at 10:34 AM, Jean-Michel Bruenn jean.bru...@ip-minds.de wrote: Hello Devin, thanks for your answer. Might i be able to help a bit? Whats missing? Cheers, Jean Hi Jean, At this point, what really needs to happen is a developer who is familiar with the internals of the cx23885 (and has the datasheets) needs to sit down and spend a few days debugging the driver. I've been too swamped with commercial projects to spend any real time on it (although that's the sort of problem that would get solved faster if some commercial party threw some money at the problem). Since I'm only really working on it in my free time, it's the sort of situation where it'll start working when I finally get around to it. For what it's worth, most of the work I'm doing for the HVR-1800 is common to the 1200/1250 as well in terms of the bugs I'm fixing would be common to both. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] soft demux device
Hi, I have just compiled v4l-dvb successfully. My aim is to develop some experimental dvb applications on top of this dvb kernel api. Initially, I do not want to use any hardware and would like to play with the recorded ts files I have. So, is there any software demux device available within this package or somewhere else? If so, how can I load this device and make it work on a given ts file circularly? On the other hand, I have no /dev/dvb node at the moment, so should I do anything for this or would loading the driver create it automatically? Thanks in advance. Cheers, Ozgur. maybe this is a good starting point for you: I wrote a Linux kernel module which provides one or more virtual DVB adapters. When loaded, it creates a char device of the form /dev/dvbloopnum for every virtual DVB adapter. All Transport Stream packets written to a char device will be delivered on the corresponding virtual DVB adapter. You can get the sources at http://cpn.dyndns.org/projects/dvbloop.shtml Maybe somebody finds it useful. Cheers, Christian. -- Christian Praehauser the link seems to be outdated, but the following is still working https://svn.baycom.de/repos/dvbloop/. A S2API patch is out as well: http://www.vdrportal.de/board/attachment.php?attachmentid=24024 I've no idea if this is working well or not, I'm not using it myself. YMWV Roland -- 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] soft demux device
Lovely! It worked straight away, at least happily created the nodes :) I'm hoping to give an update after I manage to find sometime to play with it. On the other hand, as a small note, I've applied your patch ( http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/16540 ) on top of the latest hg clone but linux/drivers/media/dvb/Makefile patch failed. It's a very simple patch to apply manually though. Cheers, Ozgur. - Original Message From: Andy Walls awa...@radix.net To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Wed, February 24, 2010 1:22:32 PM Subject: Re: [linux-dvb] soft demux device On Wed, 2010-02-24 at 03:57 -0800, ozgur cagdas wrote: Hi, Thanks very much for the previous information. To give it a go just as it is, I've loaded dvb_dummy_fe module manually and many other modules including dvb_core as well, but no hope, don't have /dev/dvb folder yet. As I've mentioned earlier, I do not have a hardware at the moment, so I should trigger loading of proper modules manually. In my scenario, which modules should I load? Any simple set of modules that'd create necessary /dev/dvb/ and subsequent would do for me. If it matters, I am using 2.6.31 kernel and ubuntu 9.10 distribution. See my dvb_dummy_adapter patch I just posted to the list. Regards, Andy Cheers, Ozgur. ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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] cx88: increase BUFFER_TIMEOUT to 2 seconds
# HG changeset patch
# User Marton Balint c...@fazekas.hu
# Date 1267027831 -3600
# Node ID 5013801372b14e3d143955c04108d450323eb2de
# Parent 2e0444bf93a4a93e5e9363d43e6f6e9d451fa9bc
cx88: increase BUFFER_TIMEOUT to 2 seconds
From: Marton Balint c...@fazekas.hu
When temporarily there is no video signal, sometimes it takes more than 0.5
secs for the cx88 chip to generate a single frame. If a dma timeout occurs
during recording, it confuses the recording application (at least mencoder) and
the recording stops. Since there is already an ifdefed-out 2 second buffer
timeout in the code, re-enabling that seemed the most simple solution.
Priority: normal
Signed-off-by: Marton Balint c...@fazekas.hu
diff -r 2e0444bf93a4 -r 5013801372b1 linux/drivers/media/video/cx88/cx88.h
--- a/linux/drivers/media/video/cx88/cx88.h Mon Feb 22 10:58:43 2010 -0300
+++ b/linux/drivers/media/video/cx88/cx88.h Wed Feb 24 17:10:31 2010 +0100
@@ -290,10 +290,7 @@
#define RESOURCE_VIDEO 2
#define RESOURCE_VBI 4
-#define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */
-#if 0
#define BUFFER_TIMEOUT msecs_to_jiffies(2000)
-#endif
/* buffer for one video frame */
struct cx88_buffer {
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 6/6] V4L: Events: Add documentation
Randy Dunlap wrote: On 02/22/10 15:01, Sakari Ailus wrote: Add documentation on how to use V4L2 events, both for V4L2 drivers and for V4L2 applications. Thanks for the comments, Randy! I'll put the fixes to the next version. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Feb 24 19:01:07 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14233:2e0444bf93a4 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-rc5-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-rc5-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.17-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-rc5-x86_64: OK spec: OK sparse (v4l-dvb-git): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: OK linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: OK linux-2.6.19.7-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Elgato EyeTV DTT deluxe v2 - i2c enumeration failed
Hi, I recently purchased the Elgato EyeTV DTT deluxe v2 stick. I am running Ubuntu 8.10 with Linux 2.6.28-15-generic. I installed v4l-dvb from mercurial with a slight change of linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h to account for the USB ID of the device (#define USB_PID_ELGATO_EYETV_DTT_Dlx 0x002c). After insertion the stick is recognized, however no frontend is activated since the i2c enumeration failed. This might be related to a missing udev rule. Any support is appreciated. This is the corresponding part from dmesg kernel: [24106.302688] usb 2-1: new high speed USB device using ehci_hcd and address 45 kernel: [24106.459222] usb 2-1: configuration #1 chosen from 1 choice kernel: [24106.459730] dvb-usb: found a 'Elgato EyeTV Dtt Dlx PD378S' in cold state, will try to load a firmware kernel: [24106.459738] usb 2-1: firmware: requesting dvb-usb-dib0700-1.20.fw kernel: [24106.523808] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' kernel: [24106.733953] dib0700: firmware started successfully. kernel: [24107.244517] dvb-usb: found a 'Elgato EyeTV Dtt Dlx PD378S' in warm state. kernel: [24107.244631] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. kernel: [24107.244862] DVB: registering new adapter (Elgato EyeTV Dtt Dlx PD378S) kernel: [24107.327206] dib0700: stk7070p_frontend_attach: dib7000p_i2c_enumeration failed. Cannot continue kernel: [24107.327211] kernel: [24107.327216] dvb-usb: no frontend was attached by 'Elgato EyeTV Dtt Dlx PD378S' kernel: [24107.327223] dvb-usb: Elgato EyeTV Dtt Dlx PD378S successfully initialized and connected. kernel: [24107.327703] dib0700: ir protocol setup failed kernel: [24130.411288] dvb-usb: Elgato EyeTV Dtt Dlx PD378S successfully deinitialized and disconnected. -- 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
[PULL] soc-camera: more patches for 2.6.34
Hi Mauro Here go the patches, that were missing in my last previous requests. And I still hope that also this time I've done everything right. My local soc-camera development branch was previously based off an earlier snapshot of your v4l development git tree. Now I have rebased that branch onto your current HEAD, applied the new patches, and pushed to linuxtv.org... It seems to have worked, but please, double-check whether it really has done everything right. If not - please, let me know. If everything is ok, I'll finally dlete my fixes tree from linuxtv.org. The following changes since commit 0f857c8e41b32c27a5bb623cabad34f36afcb596: Guennadi Liakhovetski (1): sh_mobile_ceu_camera: pass .set_parm and .get_parm down to subdevices are available in the git repository at: ssh://linuxtv.org/git/gliakhovetski/soc-camera.git devel Guennadi Liakhovetski (1): soc-camera: add runtime pm support for subdevices Márton Németh (1): The first two parameters of soc_camera_limit_side() are usually pointers to struct v4l2_rect elements. They are signed, so adjust the prototype accordingly. Valentin Longchamp (1): mt9t031: use runtime pm support to restore ADDRESS_MODE registers drivers/media/video/mt9t031.c | 66 ++-- drivers/media/video/mt9v022.c |2 +- drivers/media/video/mx3_camera.c |4 +- drivers/media/video/rj54n1cb0c.c | 18 drivers/media/video/sh_mobile_ceu_camera.c |8 ++-- drivers/media/video/soc_camera.c | 18 +++- include/media/soc_camera.h | 12 - 7 files changed, 105 insertions(+), 23 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: Elgato EyeTV DTT deluxe v2 - i2c enumeration failed
On Wednesday 24 February 2010 21:23:45 Bringfried Stecklum wrote: Hi, I recently purchased the Elgato EyeTV DTT deluxe v2 stick. I am running Ubuntu 8.10 with Linux 2.6.28-15-generic. I installed v4l-dvb from mercurial with a slight change of linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h to account for the USB ID of the device (#define USB_PID_ELGATO_EYETV_DTT_Dlx 0x002c). After insertion the stick is recognized, however no frontend is activated since the i2c enumeration failed. This might be related to a missing udev rule. Most likely Elgato has changed the USB ID of their product, because it is not the same product. In general (I'd say 50% of the cases) changing the USB ID is not the right solution to get the hardware work. If you can, open the stick to see on which hardware the device is based on, or search the internet to find out. If you're lucky another minor quirk in this or another driver is sufficient to make it work. -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: af901x: NXP TDA18218
This is a forward of the original email from Nikola Pajkovsky. Just
for the records, so it is on the list.
This solves the problem of the tuner id:179 not supported error, when
loading the AF9015 driver.
Thank you, Nikola!
Regards,
Bert Massop
-- Forwarded message --
From: Nikola Pajkovsky npajk...@redhat.com
Date: Wed, Feb 24, 2010 at 11:54
Subject: Re: af901x: NXP TDA18218
To: Antti Palosaari cr...@iki.fi
Cc: jan.sund...@aland.net, bert.mas...@gmail.com,
mkru...@kernellabs.com, dheitmuel...@kernellabs.com
Hello,
here is my solution, I can watch Vancouver right now :). I don't
look at the patch if there is some mistake(no time watch Vancouver),
but I will when I will have some free time.
Attached patch apply against this souce (hg clone
http://linuxtv.org/hg/~anttip/af9015/).
Firmware:
wget http://jusst.de/manu/fw/AFA/dvb-usb-af9015.fw_a-link
sudo mv dvb-usb-af9015.fw_a-link /lib/firmware/dvb-usb-af9015.fw
Have a nice day ;)
On 23.2.2010 14:02, Antti Palosaari wrote:
Hello,
I just got info from one user about this driver, looks like Terratec have
driver.
http://forum.ubuntuusers.de/topic/probleme-beim-installieren-terratec-cinergy-t/3/?highlight=terratec+cinergy+t+stick
Antti
Nikola Pajkovsky wrote:
Hello,
is any chance that will be support for TDA182118?
Regards,
--
Nikola
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Kconfig
--- a/linux/drivers/media/common/tuners/Kconfig Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Kconfig Wed Feb 24 11:47:14 2010 +0100
@@ -179,4 +179,11 @@
help
A driver for the silicon tuner MAX2165 from Maxim.
+config MEDIA_TUNER_TDA18218
+ tristate NXP TDA18218 silicon tuner
+ depends on VIDEO_MEDIA I2C
+ default m if MEDIA_TUNER_CUSTOMISE
+ help
+ A driver for the silicon tuner TDA18218 from NXP.
+
endif # MEDIA_TUNER_CUSTOMISE
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Makefile
--- a/linux/drivers/media/common/tuners/Makefile Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Makefile Wed Feb 24 11:47:14 2010 +0100
@@ -24,6 +24,7 @@
obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o
obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o
obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
+obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff -r 0f41fd7df85d linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c Wed Feb 24 11:47:14 2010 +0100
@@ -20,11 +20,7 @@
*Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
*/
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 25)
-#include linux/hash.h
-
-#endif
#include af9015.h
#include af9013.h
#include mt2060.h
@@ -32,6 +28,7 @@
#include tda18271.h
#include mxl5005s.h
#include mc44s803.h
+#include tda18218.h
static int dvb_usb_af9015_debug;
module_param_named(debug, dvb_usb_af9015_debug, int, 0644);
@@ -273,7 +270,8 @@
while (i num) {
if (msg[i].addr == af9015_af9013_config[0].demod_address ||
- msg[i].addr == af9015_af9013_config[1].demod_address) {
+ msg[i].addr == af9015_af9013_config[1].demod_address ||
+ msg[i].addr == 0x3a) {
addr = msg[i].buf[0] 8;
addr += msg[i].buf[1];
mbox = msg[i].buf[2];
@@ -286,7 +284,8 @@
if (num i + 1 (msg[i+1].flags I2C_M_RD)) {
if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+ msg[i].addr == 0x3a)
req.cmd = READ_MEMORY;
else
req.cmd = READ_I2C;
@@ -301,7 +300,8 @@
} else if (msg[i].flags I2C_M_RD) {
ret = -EINVAL;
if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+ msg[i].addr == 0x3a)
goto error;
else
req.cmd = READ_I2C;
@@ -315,7 +315,8 @@
i += 1;
} else {
if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+ msg[i].addr == 0x3a)
req.cmd = WRITE_MEMORY;
else
req.cmd = WRITE_I2C;
@@ -560,24 +561,11 @@
return ret;
}
-#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 25)
+/* dump eeprom */
static int af9015_eeprom_dump(struct dvb_usb_device *d)
-#else
-/* hash (and dump) eeprom */
-static int af9015_eeprom_hash(struct usb_device *udev)
-#endif
{
-#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 25)
u8 reg, val;
-#else
- static const unsigned int eeprom_size = 256;
- unsigned int reg;
- int ret;
- u8 val, *eeprom;
- struct req_t req = {READ_I2C, AF9015_I2C_EEPROM, 0, 0, 1, 1, val};
-#endif
-#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 25)
for (reg = 0; ; reg++) {
if (reg % 16 == 0) {
if (reg)
@@ -590,43 +578,9 @@
deb_info(KERN_CONT --);
if (reg == 0xff)
break;
-#else
- eeprom = kmalloc(eeprom_size, GFP_KERNEL);
- if (eeprom == NULL)
Re: af9015: tuner id:179 not supported, please report!
This is a forward of the original email from Nikola Pajkovsky. Just
for the records, so it is on the list.
This solves the problem of the tuner id:179 not supported error, when
loading the AF9015 driver.
Thank you, Nikola!
Regards,
Bert Massop
-- Forwarded message --
From: Nikola Pajkovsky npajk...@redhat.com
Date: Wed, Feb 24, 2010 at 11:54
Subject: Re: af901x: NXP TDA18218
To: Antti Palosaari cr...@iki.fi
Cc: jan.sund...@aland.net, bert.mas...@gmail.com,
mkru...@kernellabs.com, dheitmuel...@kernellabs.com
Hello,
here is my solution, I can watch Vancouver right now :). I don't
look at the patch if there is some mistake(no time watch Vancouver),
but I will when I will have some free time.
Attached patch apply against this souce (hg clone
http://linuxtv.org/hg/~anttip/af9015/).
Firmware:
wget http://jusst.de/manu/fw/AFA/dvb-usb-af9015.fw_a-link
sudo mv dvb-usb-af9015.fw_a-link /lib/firmware/dvb-usb-af9015.fw
Have a nice day ;)
On 23.2.2010 14:02, Antti Palosaari wrote:
Hello,
I just got info from one user about this driver, looks like Terratec have
driver.
http://forum.ubuntuusers.de/topic/probleme-beim-installieren-terratec-cinergy-t/3/?highlight=terratec+cinergy+t+stick
Antti
Nikola Pajkovsky wrote:
Hello,
is any chance that will be support for TDA182118?
Regards,
--
Nikola
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Kconfig
--- a/linux/drivers/media/common/tuners/Kconfig Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Kconfig Wed Feb 24 11:47:14 2010 +0100
@@ -179,4 +179,11 @@
help
A driver for the silicon tuner MAX2165 from Maxim.
+config MEDIA_TUNER_TDA18218
+ tristate NXP TDA18218 silicon tuner
+ depends on VIDEO_MEDIA I2C
+ default m if MEDIA_TUNER_CUSTOMISE
+ help
+ A driver for the silicon tuner TDA18218 from NXP.
+
endif # MEDIA_TUNER_CUSTOMISE
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Makefile
--- a/linux/drivers/media/common/tuners/Makefile Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Makefile Wed Feb 24 11:47:14 2010 +0100
@@ -24,6 +24,7 @@
obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o
obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o
obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
+obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff -r 0f41fd7df85d linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c Wed Feb 24 11:47:14 2010 +0100
@@ -20,11 +20,7 @@
*Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
*/
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 25)
-#include linux/hash.h
-
-#endif
#include af9015.h
#include af9013.h
#include mt2060.h
@@ -32,6 +28,7 @@
#include tda18271.h
#include mxl5005s.h
#include mc44s803.h
+#include tda18218.h
static int dvb_usb_af9015_debug;
module_param_named(debug, dvb_usb_af9015_debug, int, 0644);
@@ -273,7 +270,8 @@
while (i num) {
if (msg[i].addr == af9015_af9013_config[0].demod_address ||
- msg[i].addr == af9015_af9013_config[1].demod_address) {
+ msg[i].addr == af9015_af9013_config[1].demod_address ||
+ msg[i].addr == 0x3a) {
addr = msg[i].buf[0] 8;
addr += msg[i].buf[1];
mbox = msg[i].buf[2];
@@ -286,7 +284,8 @@
if (num i + 1 (msg[i+1].flags I2C_M_RD)) {
if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+ msg[i].addr == 0x3a)
req.cmd = READ_MEMORY;
else
req.cmd = READ_I2C;
@@ -301,7 +300,8 @@
} else if (msg[i].flags I2C_M_RD) {
ret = -EINVAL;
if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+ msg[i].addr == 0x3a)
goto error;
else
req.cmd = READ_I2C;
@@ -315,7 +315,8 @@
i += 1;
} else {
if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+ msg[i].addr == 0x3a)
req.cmd = WRITE_MEMORY;
else
req.cmd = WRITE_I2C;
@@ -560,24 +561,11 @@
return ret;
}
-#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 25)
+/* dump eeprom */
static int af9015_eeprom_dump(struct dvb_usb_device *d)
-#else
-/* hash (and dump) eeprom */
-static int af9015_eeprom_hash(struct usb_device *udev)
-#endif
{
-#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 25)
u8 reg, val;
-#else
- static const unsigned int eeprom_size = 256;
- unsigned int reg;
- int ret;
- u8 val, *eeprom;
- struct req_t req = {READ_I2C, AF9015_I2C_EEPROM, 0, 0, 1, 1, val};
-#endif
-#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 25)
for (reg = 0; ; reg++) {
if (reg % 16 == 0) {
if (reg)
@@ -590,43 +578,9 @@
deb_info(KERN_CONT --);
if (reg == 0xff)
break;
-#else
- eeprom = kmalloc(eeprom_size, GFP_KERNEL);
- if (eeprom == NULL)
[PATCH v8 0/6] V4L2 file handles and event interface
Hi, Here's the tenth version of the V4L2 file handle and event interface patchset. The patchset has been tested with the OMAP 3 ISP driver. Patches for OMAP 3 ISP are not part of this patchset but are available in Gitorious (branch is called event): git://gitorious.org/omap3camera/mainline.git event The patchset I'm posting now is against the v4l-dvb tree instead of linux-omap. The omap3camera tree thus has a slightly different version of these patches (just Makefiles) due to different baselines. Some more comments from Hans and Randy. There are only improvements in documentation this time. Comments are welcome as always. Cheers, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 5/6] V4L: Events: Support event handling in do_ioctl
Add support for event handling to do_ioctl.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-fh.c| 11 +++-
drivers/media/video/v4l2-ioctl.c | 50 ++
include/media/v4l2-ioctl.h |7 +
3 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
index aab2fb6..1423c44 100644
--- a/drivers/media/video/v4l2-fh.c
+++ b/drivers/media/video/v4l2-fh.c
@@ -34,7 +34,16 @@ int v4l2_fh_init(struct v4l2_fh *fh, struct video_device
*vdev)
INIT_LIST_HEAD(fh-list);
set_bit(V4L2_FL_USES_V4L2_FH, fh-vdev-flags);
- return v4l2_event_init(fh);
+ /*
+* fh-events only needs to be initialized if the driver
+* supports the VIDIOC_SUBSCRIBE_EVENT ioctl.
+*/
+ if (vdev-ioctl_ops vdev-ioctl_ops-vidioc_subscribe_event)
+ return v4l2_event_init(fh);
+ else
+ fh-events = NULL;
+
+ return 0;
}
EXPORT_SYMBOL_GPL(v4l2_fh_init);
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 34c7d6e..4ba22da 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -25,6 +25,8 @@
#endif
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
+#include media/v4l2-fh.h
+#include media/v4l2-event.h
#include media/v4l2-chip-ident.h
#define dbgarg(cmd, fmt, arg...) \
@@ -1944,7 +1946,55 @@ static long __video_do_ioctl(struct file *file,
}
break;
}
+ case VIDIOC_DQEVENT:
+ {
+ struct v4l2_event *ev = arg;
+
+ if (!ops-vidioc_subscribe_event)
+ break;
+
+ ret = v4l2_event_dequeue(fh, ev, file-f_flags O_NONBLOCK);
+ if (ret 0) {
+ dbgarg(cmd, no pending events?);
+ break;
+ }
+ dbgarg(cmd,
+ pending=%d, type=0x%8.8x, sequence=%d,
+ timestamp=%lu.%9.9lu ,
+ ev-pending, ev-type, ev-sequence,
+ ev-timestamp.tv_sec, ev-timestamp.tv_nsec);
+ break;
+ }
+ case VIDIOC_SUBSCRIBE_EVENT:
+ {
+ struct v4l2_event_subscription *sub = arg;
+ if (!ops-vidioc_subscribe_event)
+ break;
+
+ ret = ops-vidioc_subscribe_event(fh, sub);
+ if (ret 0) {
+ dbgarg(cmd, failed, ret=%ld, ret);
+ break;
+ }
+ dbgarg(cmd, type=0x%8.8x, sub-type);
+ break;
+ }
+ case VIDIOC_UNSUBSCRIBE_EVENT:
+ {
+ struct v4l2_event_subscription *sub = arg;
+
+ if (!ops-vidioc_unsubscribe_event)
+ break;
+
+ ret = ops-vidioc_unsubscribe_event(fh, sub);
+ if (ret 0) {
+ dbgarg(cmd, failed, ret=%ld, ret);
+ break;
+ }
+ dbgarg(cmd, type=0x%8.8x, sub-type);
+ break;
+ }
default:
{
if (!ops-vidioc_default)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index e8ba0f2..06daa6e 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -21,6 +21,8 @@
#include linux/videodev2.h
#endif
+struct v4l2_fh;
+
struct v4l2_ioctl_ops {
/* ioctl callbacks */
@@ -254,6 +256,11 @@ struct v4l2_ioctl_ops {
int (*vidioc_g_dv_timings) (struct file *file, void *fh,
struct v4l2_dv_timings *timings);
+ int (*vidioc_subscribe_event) (struct v4l2_fh *fh,
+ struct v4l2_event_subscription *sub);
+ int (*vidioc_unsubscribe_event)(struct v4l2_fh *fh,
+ struct v4l2_event_subscription *sub);
+
/* For other private ioctls */
long (*vidioc_default) (struct file *file, void *fh,
int cmd, void *arg);
--
1.5.6.5
--
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 v8 3/6] V4L: Events: Add new ioctls for events
This patch adds a set of new ioctls to the V4L2 API. The ioctls conform to
V4L2 Events RFC version 2.3:
URL:http://www.spinics.net/lists/linux-media/msg12033.html
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/v4l2-compat-ioctl32.c |3 +++
drivers/media/video/v4l2-ioctl.c |3 +++
include/linux/videodev2.h | 26 ++
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index f77f84b..9004a5f 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -1086,6 +1086,9 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_QUERY_DV_PRESET:
case VIDIOC_S_DV_TIMINGS:
case VIDIOC_G_DV_TIMINGS:
+ case VIDIOC_DQEVENT:
+ case VIDIOC_SUBSCRIBE_EVENT:
+ case VIDIOC_UNSUBSCRIBE_EVENT:
ret = do_video_ioctl(file, cmd, arg);
break;
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 4b11257..34c7d6e 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -290,6 +290,9 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_QUERY_DV_PRESET)] = VIDIOC_QUERY_DV_PRESET,
[_IOC_NR(VIDIOC_S_DV_TIMINGS)] = VIDIOC_S_DV_TIMINGS,
[_IOC_NR(VIDIOC_G_DV_TIMINGS)] = VIDIOC_G_DV_TIMINGS,
+ [_IOC_NR(VIDIOC_DQEVENT)] = VIDIOC_DQEVENT,
+ [_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)] = VIDIOC_SUBSCRIBE_EVENT,
+ [_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] = VIDIOC_UNSUBSCRIBE_EVENT,
};
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3c26560..d3b1446 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1622,6 +1622,29 @@ struct v4l2_streamparm {
};
/*
+ * E V E N T S
+ */
+
+struct v4l2_event {
+ __u32 type;
+ union {
+ __u8data[64];
+ } u;
+ __u32 pending;
+ __u32 sequence;
+ struct timespec timestamp;
+ __u32 reserved[9];
+};
+
+struct v4l2_event_subscription {
+ __u32 type;
+ __u32 reserved[7];
+};
+
+#define V4L2_EVENT_ALL 0
+#define V4L2_EVENT_PRIVATE_START 0x0800
+
+/*
* A D V A N C E D D E B U G G I N G
*
* NOTE: EXPERIMENTAL API, NEVER RELY ON THIS IN APPLICATIONS!
@@ -1743,6 +1766,9 @@ struct v4l2_dbg_chip_ident {
#defineVIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct v4l2_dv_preset)
#defineVIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct v4l2_dv_timings)
#defineVIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct v4l2_dv_timings)
+#defineVIDIOC_DQEVENT _IOR('V', 89, struct v4l2_event)
+#defineVIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription)
+#defineVIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct
v4l2_event_subscription)
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
--
1.5.6.5
--
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 v8 2/6] V4L: File handles: Add documentation
Add documentation on using V4L2 file handles (v4l2_fh) in V4L2 drivers. Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- Documentation/video4linux/v4l2-framework.txt | 37 ++ 1 files changed, 37 insertions(+), 0 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 74d677c..bfaf0c5 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -695,3 +695,40 @@ The better way to understand it is to take a look at vivi driver. One of the main reasons for vivi is to be a videobuf usage example. the vivi_thread_tick() does the task that the IRQ callback would do on PCI drivers (or the irq callback on USB). + +struct v4l2_fh +-- + +struct v4l2_fh provides a way to easily keep file handle specific data +that is used by the V4L2 framework. + +struct v4l2_fh is allocated as a part of the driver's own file handle +structure and is set to file-private_data in the driver's open +function by the driver. Drivers can extract their own file handle +structure by using the container_of macro. + +Useful functions: + +- v4l2_fh_init() + + Initialise the file handle. This *MUST* be performed in the driver's + v4l2_file_operations-open() handler. + +- v4l2_fh_add() + + Add a v4l2_fh to video_device file handle list. May be called after + initialising the file handle. + +- v4l2_fh_del() + + Unassociate the file handle from video_device(). The file handle + exit function may now be called. + +- v4l2_fh_exit() + + Uninitialise the file handle. After uninitialisation the v4l2_fh + memory can be freed. + +The users of v4l2_fh know whether a driver uses v4l2_fh as its +file-private_data pointer by testing the V4L2_FL_USES_V4L2_FH bit in +video_device-flags. -- 1.5.6.5 -- 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 v8 4/6] V4L: Events: Add backend
Add event handling backend to V4L2. The backend handles event subscription
and delivery to file handles. Event subscriptions are based on file handle.
Events may be delivered to all subscribed file handles on a device
independent of where they originate from.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/Makefile |3 +-
drivers/media/video/v4l2-event.c | 289 ++
drivers/media/video/v4l2-fh.c|6 +-
include/media/v4l2-event.h | 67 +
include/media/v4l2-fh.h |2 +
5 files changed, 365 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/video/v4l2-event.c
create mode 100644 include/media/v4l2-event.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 14bf69a..b84abfe 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,8 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o
omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o
-videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
+videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
+ v4l2-event.o
# V4L2 core modules
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
new file mode 100644
index 000..aea4332
--- /dev/null
+++ b/drivers/media/video/v4l2-event.c
@@ -0,0 +1,289 @@
+/*
+ * v4l2-event.c
+ *
+ * V4L2 events.
+ *
+ * Copyright (C) 2009--2010 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include media/v4l2-dev.h
+#include media/v4l2-fh.h
+#include media/v4l2-event.h
+
+#include linux/sched.h
+
+int v4l2_event_init(struct v4l2_fh *fh)
+{
+ fh-events = kzalloc(sizeof(*fh-events), GFP_KERNEL);
+ if (fh-events == NULL)
+ return -ENOMEM;
+
+ init_waitqueue_head(fh-events-wait);
+
+ INIT_LIST_HEAD(fh-events-free);
+ INIT_LIST_HEAD(fh-events-available);
+ INIT_LIST_HEAD(fh-events-subscribed);
+
+ fh-events-sequence = -1;
+
+ return 0;
+}
+
+int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
+{
+ struct v4l2_events *events = fh-events;
+ unsigned long flags;
+
+ if (!events) {
+ WARN_ON(1);
+ return -ENOMEM;
+ }
+
+ while (events-nallocated n) {
+ struct v4l2_kevent *kev;
+
+ kev = kzalloc(sizeof(*kev), GFP_KERNEL);
+ if (kev == NULL)
+ return -ENOMEM;
+
+ spin_lock_irqsave(fh-vdev-fh_lock, flags);
+ list_add_tail(kev-list, events-free);
+ events-nallocated++;
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_alloc);
+
+#define list_kfree(list, type, member) \
+ while (!list_empty(list)) { \
+ type *hi; \
+ hi = list_first_entry(list, type, member); \
+ list_del(hi-member); \
+ kfree(hi); \
+ }
+
+void v4l2_event_free(struct v4l2_fh *fh)
+{
+ struct v4l2_events *events = fh-events;
+
+ if (!events)
+ return;
+
+ list_kfree(events-free, struct v4l2_kevent, list);
+ list_kfree(events-available, struct v4l2_kevent, list);
+ list_kfree(events-subscribed, struct v4l2_subscribed_event, list);
+
+ kfree(events);
+ fh-events = NULL;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_free);
+
+static int __v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event)
+{
+ struct v4l2_events *events = fh-events;
+ struct v4l2_kevent *kev;
+ unsigned long flags;
+
+ spin_lock_irqsave(fh-vdev-fh_lock, flags);
+
+ if (list_empty(events-available)) {
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+ return -ENOENT;
+ }
+
+ WARN_ON(events-navailable == 0);
+
+ kev = list_first_entry(events-available, struct v4l2_kevent, list);
+ list_move(kev-list, events-free);
+ events-navailable--;
+
+
[PATCH v8 1/6] V4L: File handles
This patch adds a list of v4l2_fh structures to every video_device.
It allows using file handle related information in V4L2. The event interface
is one example of such use.
Video device drivers should use the v4l2_fh pointer as their
file-private_data.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/Makefile |2 +-
drivers/media/video/v4l2-dev.c |4 ++
drivers/media/video/v4l2-fh.c | 66
include/media/v4l2-dev.h |5 +++
include/media/v4l2-fh.h| 42 +
5 files changed, 118 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/video/v4l2-fh.c
create mode 100644 include/media/v4l2-fh.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 5163289..14bf69a 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,7 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o
omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o
-videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o
+videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
# V4L2 core modules
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 7090699..65a7b30 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -421,6 +421,10 @@ static int __video_register_device(struct video_device
*vdev, int type, int nr,
if (!vdev-release)
return -EINVAL;
+ /* v4l2_fh support */
+ spin_lock_init(vdev-fh_lock);
+ INIT_LIST_HEAD(vdev-fh_list);
+
/* Part 1: check device type */
switch (type) {
case VFL_TYPE_GRABBER:
diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
new file mode 100644
index 000..93ea0af
--- /dev/null
+++ b/drivers/media/video/v4l2-fh.c
@@ -0,0 +1,66 @@
+/*
+ * v4l2-fh.c
+ *
+ * V4L2 file handles.
+ *
+ * Copyright (C) 2009--2010 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/bitops.h
+#include media/v4l2-dev.h
+#include media/v4l2-fh.h
+
+int v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
+{
+ fh-vdev = vdev;
+ INIT_LIST_HEAD(fh-list);
+ set_bit(V4L2_FL_USES_V4L2_FH, fh-vdev-flags);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_init);
+
+void v4l2_fh_add(struct v4l2_fh *fh)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(fh-vdev-fh_lock, flags);
+ list_add(fh-list, fh-vdev-fh_list);
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_add);
+
+void v4l2_fh_del(struct v4l2_fh *fh)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(fh-vdev-fh_lock, flags);
+ list_del_init(fh-list);
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_del);
+
+void v4l2_fh_exit(struct v4l2_fh *fh)
+{
+ if (fh-vdev == NULL)
+ return;
+
+ fh-vdev = NULL;
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_exit);
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 2dee938..bebe44b 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -32,6 +32,7 @@ struct v4l2_device;
Drivers can clear this flag if they want to block all future
device access. It is cleared by video_unregister_device. */
#define V4L2_FL_REGISTERED (0)
+#define V4L2_FL_USES_V4L2_FH (1)
struct v4l2_file_operations {
struct module *owner;
@@ -77,6 +78,10 @@ struct video_device
/* attribute to differentiate multiple indices on one physical device */
int index;
+ /* V4L2 file handles */
+ spinlock_t fh_lock; /* Lock for all v4l2_fhs */
+ struct list_headfh_list; /* List of struct v4l2_fh */
+
int debug; /* Activates debug level*/
/* Video standard vars */
diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h
new file mode 100644
index 000..410e86c
--- /dev/null
+++ b/include/media/v4l2-fh.h
@@ -0,0 +1,42 @@
+/*
+ * v4l2-fh.h
+ *
+ * V4L2 file handle.
+ *
+ * Copyright (C) 2009--2010 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ *
+ * This
[PATCH v8 6/6] V4L: Events: Add documentation
Add documentation on how to use V4L2 events, both for V4L2 drivers and for V4L2 applications. Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- Documentation/DocBook/media-entities.tmpl |9 ++ Documentation/DocBook/v4l/dev-event.xml| 31 + Documentation/DocBook/v4l/v4l2.xml |3 + Documentation/DocBook/v4l/vidioc-dqevent.xml | 124 .../DocBook/v4l/vidioc-subscribe-event.xml | 104 Documentation/video4linux/v4l2-framework.txt | 60 ++ 6 files changed, 331 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/dev-event.xml create mode 100644 Documentation/DocBook/v4l/vidioc-dqevent.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subscribe-event.xml diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index c725cb8..770be3c 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -17,6 +17,7 @@ !ENTITY VIDIOC-DBG-G-REGISTER link linkend='vidioc-dbg-g-register'constantVIDIOC_DBG_G_REGISTER/constant/link !ENTITY VIDIOC-DBG-S-REGISTER link linkend='vidioc-dbg-g-register'constantVIDIOC_DBG_S_REGISTER/constant/link !ENTITY VIDIOC-DQBUF link linkend='vidioc-qbuf'constantVIDIOC_DQBUF/constant/link +!ENTITY VIDIOC-DQEVENT link linkend='vidioc-dqevent'constantVIDIOC_DQEVENT/constant/link !ENTITY VIDIOC-ENCODER-CMD link linkend='vidioc-encoder-cmd'constantVIDIOC_ENCODER_CMD/constant/link !ENTITY VIDIOC-ENUMAUDIO link linkend='vidioc-enumaudio'constantVIDIOC_ENUMAUDIO/constant/link !ENTITY VIDIOC-ENUMAUDOUT link linkend='vidioc-enumaudioout'constantVIDIOC_ENUMAUDOUT/constant/link @@ -60,6 +61,7 @@ !ENTITY VIDIOC-REQBUFS link linkend='vidioc-reqbufs'constantVIDIOC_REQBUFS/constant/link !ENTITY VIDIOC-STREAMOFF link linkend='vidioc-streamon'constantVIDIOC_STREAMOFF/constant/link !ENTITY VIDIOC-STREAMON link linkend='vidioc-streamon'constantVIDIOC_STREAMON/constant/link +!ENTITY VIDIOC-SUBSCRIBE-EVENT link linkend='vidioc-subscribe-event'constantVIDIOC_SUBSCRIBE_EVENT/constant/link !ENTITY VIDIOC-S-AUDIO link linkend='vidioc-g-audio'constantVIDIOC_S_AUDIO/constant/link !ENTITY VIDIOC-S-AUDOUT link linkend='vidioc-g-audioout'constantVIDIOC_S_AUDOUT/constant/link !ENTITY VIDIOC-S-CROP link linkend='vidioc-g-crop'constantVIDIOC_S_CROP/constant/link @@ -141,6 +143,8 @@ !ENTITY v4l2-enc-idx structnbsp;link linkend='v4l2-enc-idx'v4l2_enc_idx/link !ENTITY v4l2-enc-idx-entry structnbsp;link linkend='v4l2-enc-idx-entry'v4l2_enc_idx_entry/link !ENTITY v4l2-encoder-cmd structnbsp;link linkend='v4l2-encoder-cmd'v4l2_encoder_cmd/link +!ENTITY v4l2-event structnbsp;link linkend='v4l2-event'v4l2_event/link +!ENTITY v4l2-event-subscription structnbsp;link linkend='v4l2-event-subscription'v4l2_event_subscription/link !ENTITY v4l2-ext-control structnbsp;link linkend='v4l2-ext-control'v4l2_ext_control/link !ENTITY v4l2-ext-controls structnbsp;link linkend='v4l2-ext-controls'v4l2_ext_controls/link !ENTITY v4l2-fmtdesc structnbsp;link linkend='v4l2-fmtdesc'v4l2_fmtdesc/link @@ -200,6 +204,7 @@ !ENTITY sub-controls SYSTEM v4l/controls.xml !ENTITY sub-dev-capture SYSTEM v4l/dev-capture.xml !ENTITY sub-dev-codec SYSTEM v4l/dev-codec.xml +!ENTITY sub-dev-event SYSTEM v4l/dev-event.xml !ENTITY sub-dev-effect SYSTEM v4l/dev-effect.xml !ENTITY sub-dev-osd SYSTEM v4l/dev-osd.xml !ENTITY sub-dev-output SYSTEM v4l/dev-output.xml @@ -292,6 +297,8 @@ !ENTITY sub-v4l2grab-c SYSTEM v4l/v4l2grab.c.xml !ENTITY sub-videodev2-h SYSTEM v4l/videodev2.h.xml !ENTITY sub-v4l2 SYSTEM v4l/v4l2.xml +!ENTITY sub-dqevent SYSTEM v4l/vidioc-dqevent.xml +!ENTITY sub-subscribe-event SYSTEM v4l/vidioc-subscribe-event.xml !ENTITY sub-intro SYSTEM dvb/intro.xml !ENTITY sub-frontend SYSTEM dvb/frontend.xml !ENTITY sub-dvbproperty SYSTEM dvb/dvbproperty.xml @@ -381,3 +388,5 @@ !ENTITY reqbufs SYSTEM v4l/vidioc-reqbufs.xml !ENTITY s-hw-freq-seek SYSTEM v4l/vidioc-s-hw-freq-seek.xml !ENTITY streamon SYSTEM v4l/vidioc-streamon.xml +!ENTITY dqevent SYSTEM v4l/vidioc-dqevent.xml +!ENTITY subscribe_event SYSTEM v4l/vidioc-subscribe-event.xml diff --git a/Documentation/DocBook/v4l/dev-event.xml b/Documentation/DocBook/v4l/dev-event.xml new file mode 100644 index 000..be5a98f --- /dev/null +++ b/Documentation/DocBook/v4l/dev-event.xml @@ -0,0 +1,31 @@ + titleEvent Interface/title + + paraThe V4L2 event interface provides means for user to get + immediately notified on certain conditions taking place on a device. + This might include start of frame or loss of signal events, for + example. + /para + + paraTo receive events, the events the user is interested in first must + be subscribed using the VIDIOC-SUBSCRIBE-EVENT; ioctl. Once an event is + subscribed, the events of subscribed types are dequeueable using the + VIDIOC-DQEVENT; ioctl. Events may be
Development of TM6000
Hi Mauro, From what I have gather so far, it seem that you are the only person who might still be keen in the continue development of TM6000 driver. Apparently, I saw that you are also pretty much occupied with other works at hand. I have recently bought a USB stick(MSI Vox II) that have the TM5600/XC2028 chipset. Using the latest source from http://linuxtv.org/hg/v4l-dvb and activating the TM6000 under staging, I was able to detect the tuner stick. Firmware was extracted using the tridvid.sys from the windows driver CD. Unfortunately, this is the furthest that I can go. Both tvtime and mplayer were able to load but the notebook just freeze some time. Do you have any pointer on how I can get it to work? Playing tv://. TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski olschew...@zpr.uni-koeln.de comment: first try, more to come ;-) Selected device: Trident TVMaster TM5600/6000 Tuner cap: Tuner rxs: MONO Capabilites: video capture tuner read/write streaming supported norms: 0 = NTSC-M; 1 = NTSC-M-JP; 2 = PAL; 3 = PAL-BG; 4 = PAL-H; 5 = PAL-I; 6 = PAL-DK; 7 = PAL-M; 8 = PAL-N; 9 = PAL-Nc; 10 = PAL-60; 11 = SECAM; 12 = SECAM-B; 13 = SECAM-G; 14 = SECAM-H; 15 = SECAM-DK; 16 = SECAM-L; 17 = SECAM-Lc; inputs: 0 = Television; 1 = Composite; 2 = S-Video; Current input: 0 Current format: YUYV v4l2: current audio mode is : MONO v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument On a side note, I am starting to look through documentation on developing v4l driver so that I can work on the existing TM6000 driver. Unfortunately, while I am verse in programming(userspace only), C and Assembly is only something I am familiar with many years back during school days. So its going to take a while for me to catch up. I guess working on the driver on my own might be the only possibility if you cannot afford the time to work on it. -- 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: [ANNOUNCE] git tree repositories libv4l
Hello all, On 02/23/2010 10:51 AM, Hans de Goede wrote: Hi, On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote: Hans de Goede wrote: Ok, so this will give me a local tree, how do I get this onto linuxtv.org ? I added it. In thesis, it is open for commit to you, me, hverkuil and dougsland. I see good, thanks! Can someone (Douglas ?) with better hg / git powers then me please somehow import all the libv4l changes from: http://linuxtv.org/hg/~hgoede/libv4l Done! Cheers Douglas -- 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: Requested feedback on V4L2 driver design
Chase, Laurent, Sorry for the extreme delay in my response ... From the code available currently on omapzoom, our plans are to eventually have only the Notify module in kernel-space. All the other code in multicore_ipc will actually move to user-side. The Notify module gives additional functionality over the basic mailbox driver to abstract the single physical event into multiple logical events. This enables multiple clients (one of which is the DSS driver) to use the single physical interrupt for multiple different purposes in a fully modular manner. We will ensure that the kernel-side Notify module is fully integrated into the kernel in the proper way and still meets our functionality requirements, taking feedback from the community into account. We are also making several changes in the APIs for all modules to make them much easier to use. A lot of the complexity as seen by the user will vanish underneath. This is still under progress, so it's not out on omapzoom yet, but will definitely be done. As soon as this is done, we will work on moving most of the modules (except Notify) fully from kernel-user space. Once our kernel-user work has at least gone far enough ahead to allow us to make a design proposal, we will push it out for review to get your valuable feedback. I have also looped in the TI engineers who have worked on and pushed out the omapzoom SysLink code. Regards, Mugdha -Original Message- From: Maupin, Chase Sent: Friday, February 12, 2010 10:17 PM To: Laurent Pinchart Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver design (May contain non-TIers); linux-media@vger.kernel.org; Kamoolkar, Mugdha Subject: RE: Requested feedback on V4L2 driver design Laurent, First let me thank you for taking time to review this. I have made comments below to address your concerns. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Thursday, February 11, 2010 7:23 PM To: Maupin, Chase Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver design (May contain non-TIers); linux- me...@vger.kernel.org Subject: Re: Requested feedback on V4L2 driver design Hi Chase, On Monday 08 February 2010 16:08:37 Maupin, Chase wrote: All, Texas Instruments (TI) is working on the design for the V4L2 capture and display drivers for our next generation system-on-chip (SoC) processor and would like to solicit your feedback. Thank you very much for requesting feedback on the system design. I personally appreciate this, and I'm pretty sure that the feeling is shared by most of the Linux kernel developers. If you have additional questions or need more information please feel free to contact us (we have setup a mailing list at vpss_driver_des...@list.ti.com) so we can answer them. I'll answer here as the instructions provided in the wiki to subscribe to the vpss_driver_design mailing list are incorrect (http://list.ti.com/ isn't accessible, the name has no A record associated to it). I've CC'ed the list in case subscription wouldn't be required to post. The page for subscribing to the list requires a my.TI login which you can setup at https://myportal.ti.com/portal/dt?provider=TIPassLoginSingleContainerlt=mytij5=2j3=1goto=https%3A%2F%2Fmy.ti.com%3A443%2Fcgi-bin%2Fhome.pl%3FDCMP%3DTIHeaderTracking%26HQS%3DOther%2BOT%2Bhdr_my_ti. However, your reply to the list should be fine without subscribing. 1. Multi-core design OMAP3 was already a dual-core system, OMAP4 (I assume all this is about the OMAP4 processors family) seems to push the concept one step further. With its heterogeneous multi-core design (ARM master CPU and slave DSPs), the OMAP architecture delivers high performances at the cost of higher development time and effort as users need to write software for completely different cores, usually using different toolchains. This is in my opinion a good (or at least acceptable) trade-off between CPU power, development time and power consumption (DSPs being more efficient at signal processing at the cost of a higher development complexity). I'm a bit puzzled, however, by how the VPSS MCU will help improving the situation compared to the OMAP3 design. The VPSS MCU will provide an API that will expose a fixed subset of the hardware capabilities. This is only a guess, but I suppose the firmware will be fairly generic, and that TI will provide customized versions to big customers tailored for their needs and use cases. The official kernel drivers
Re: Chroma gain configuration
On Tue, Feb 23, 2010 at 2:53 AM, Hans Verkuil hverk...@xs4all.nl wrote: Control enumeration is actually working fine. The queryctrl does properly return all of the controls, including my new private control. OK. So the problem is that v4l2-ctl uses G/S_EXT_CTRLS for non-user controls, right? Why not change v4l2-ctl: let it first try the EXT version but if that fails with EINVAL then try the old control API. For what it's worth, I actually bisected the v4l2-ctl.cpp, and found out the breakage got introduced in rev 12546: == v4l2-ctl: add support for string controls From: Hans Verkuil hverk...@xs4all.nl Add support for string controls to v4l2-ctl. Also refactor the code to generalize the handling of control classes. Priority: normal == And this change breaks the v4l2-ctl application not just with my driver but with *any* of the drivers which have private controls implemented in g_ctrl or s_ctrl (including bttv, saa7134, and pwc) The root of the issue is that private controls are not considered user controls. Hence when getting or setting the control, the v4l2-ctl app will always insist on attempting to use the g_ext_ctrls/s_ext_ctrls ioctl calls, even though the underlying driver doesn't have them implemented as extended controls. The enumeration of all of control values (using the -l argument) does include the private controls properly because the logic is written such that it always uses g_ctrl for all cases where the control ID = V4L2_CID_PRIVATE_BASE. I guess I'll see whether I can rework the logic a bit such that the set/get routines work in a comparable manner to the routine to enumerate all the controls. I would prefer to avoid making the g_ext_ctrls ioctl() call and then retrying it as g_ctrl if it fails, since that will cause errors to be printed to the screen (due to the abstraction of doioctl() function) and is generally a bad practice. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Linux testers wanted for Genius iSlim 310
Hi,
based on the information from installing the Windows driver the
Genius iSlim 310 is a potential candidate that the gspca_pac7302 driver under
Linux may handle, see
http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302#Identification .
If you have access to Genius iSlim 310 and would like to give a try please
apply the patch in this email, compile and install the patched kernel,
check dmesg for messages and try whether the webcam is working for
example with cheese.
Regards,
Márton Németh
---
From: Márton Németh nm...@freemail.hu
On the schematics in PixArt PAC7301/PAC7302 datasheet
(http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf)
pages 19, 20, 21 and 22 there is a note titled PID IO_TRAP which describes
the possible product ID range 0x2620..0x262f. In this range there are some
known webcams, however, there are some PIDs with unknown or future devices.
Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is
probable that this driver will work correctly independent of the used PID.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r dfa82cf98a85 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sat Jan 30 20:03:02 2010 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 31 11:08:21 2010 +0100
@@ -96,6 +96,7 @@
u8 flags;
#define FL_HFLIP 0x01 /* mirrored by default */
#define FL_VFLIP 0x02 /* vertical flipped by default */
+#define FL_EXPERIMENTAL 0x80 /* USB IDs based on heuristic without any known
product */
u8 sof_read;
u8 autogain_ignore_frames;
@@ -1220,17 +1221,33 @@
};
/* -- module initialisation -- */
+/* Note on FL_EXPERIMENTAL:
+ * On the schematics in PixArt PAC7301/PAC7302 datasheet
+ *
(http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf)
+ * pages 19, 20, 21 and 22 there is a note titled PID IO_TRAP which describes
+ * the possible product ID range 0x2620..0x262f. In this range there are some
+ * known webcams, however, there are some PIDs with unknown or future devices.
+ * Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is
+ * probable that this driver will work correctly independent of the used PID.
+ */
static const struct usb_device_id device_table[] __devinitconst = {
{USB_DEVICE(0x06f8, 0x3009)},
{USB_DEVICE(0x093a, 0x2620)},
{USB_DEVICE(0x093a, 0x2621)},
{USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP},
+ {USB_DEVICE(0x093a, 0x2623), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP},
+ {USB_DEVICE(0x093a, 0x2625), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2626)},
+ {USB_DEVICE(0x093a, 0x2627), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2628)},
{USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP},
{USB_DEVICE(0x093a, 0x262a)},
+ {USB_DEVICE(0x093a, 0x262b), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x262c)},
+ {USB_DEVICE(0x093a, 0x262d), .driver_info = FL_EXPERIMENTAL },
+ {USB_DEVICE(0x093a, 0x262e), .driver_info = FL_EXPERIMENTAL },
+ {USB_DEVICE(0x093a, 0x262f), .driver_info = FL_EXPERIMENTAL },
{}
};
MODULE_DEVICE_TABLE(usb, device_table);
@@ -1239,6 +1256,17 @@
static int __devinit sd_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
+ if ((u8)id-driver_info FL_EXPERIMENTAL) {
+ PDEBUG(D_ERR | D_PROBE, WARNING: USB device ID %04x:%04x is
+ not known, but based on some heuristics this driver
+ tries to handle it.,
+ id-idVendor, id-idProduct);
+ PDEBUG(D_ERR | D_PROBE, WARNING: Plase send an email to
+ linux-media@vger.kernel.org with 'lsusb -v' output,
+ the vendor and name of the product and whether the
+ device is working or not.);
+ }
+
return gspca_dev_probe(intf, id, sd_desc, sizeof(struct sd),
THIS_MODULE);
}
--
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
