Re: [linux-dvb] ca_zap source available?
On 24.06.2010 05:53, YD wrote: Hello, Is it avaiable to have the ca_zap source code? I read the ci.txt and it said we could test the ci function with ca_zap. But I could not find out yet. Also please recommend good reference about the DVB-CI implementation. Thanks, ___ linux-dvb users mailing list For V4L/DVB development, please use insteadlinux-me...@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Hello It is part of dvb-apps. hg clone http://linuxtv.org/hg/dvb-apps -- 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]video:gspca.c Fix warning: case value '7' not in enumerated type 'enum v4l2_memory'
On Wed, 7 Jul 2010 21:46:18 -0700
Justin P. Mattock justinmatt...@gmail.com wrote:
This fixes a warning I'm seeing when building:
CC [M] drivers/media/video/gspca/gspca.o
drivers/media/video/gspca/gspca.c: In function 'vidioc_reqbufs':
drivers/media/video/gspca/gspca.c:1508:2: warning: case value '7' not
in enumerated type 'enum v4l2_memory'
Hi Justin,
I don't agree with your patch: the value GSPCA_MEMORY_READ must not be
seen by user applications.
The warning may be simply fixed by (change the line numbers):
--- gspca.c~2010-07-08 08:15:14.0 +0200
+++ gspca.c 2010-07-08 08:28:52.0 +0200
@@ -1467,7 +1467,8 @@ static int vidioc_reqbufs(struct file *f
struct gspca_dev *gspca_dev = priv;
int i, ret = 0, streaming;
- switch (rb-memory) {
+ i = rb-memory; /* (avoid compilation warning) */
+ switch (i) {
case GSPCA_MEMORY_READ: /* (internal call) */
case V4L2_MEMORY_MMAP:
case V4L2_MEMORY_USERPTR:
Cheers.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]video:gspca.c Fix warning: case value '7' not in enumerated type 'enum v4l2_memory'
On 07/07/2010 11:40 PM, Jean-Francois Moine wrote:
On Wed, 7 Jul 2010 21:46:18 -0700
Justin P. Mattockjustinmatt...@gmail.com wrote:
This fixes a warning I'm seeing when building:
CC [M] drivers/media/video/gspca/gspca.o
drivers/media/video/gspca/gspca.c: In function 'vidioc_reqbufs':
drivers/media/video/gspca/gspca.c:1508:2: warning: case value '7' not
in enumerated type 'enum v4l2_memory'
Hi Justin,
I don't agree with your patch: the value GSPCA_MEMORY_READ must not be
seen by user applications.
The warning may be simply fixed by (change the line numbers):
--- gspca.c~2010-07-08 08:15:14.0 +0200
+++ gspca.c 2010-07-08 08:28:52.0 +0200
@@ -1467,7 +1467,8 @@ static int vidioc_reqbufs(struct file *f
struct gspca_dev *gspca_dev = priv;
int i, ret = 0, streaming;
- switch (rb-memory) {
+ i = rb-memory; /* (avoid compilation warning) */
+ switch (i) {
case GSPCA_MEMORY_READ: /* (internal call) */
case V4L2_MEMORY_MMAP:
case V4L2_MEMORY_USERPTR:
Cheers.
o.k. buddy.. make sense with the userspace etc..
Anyways looks good, builds without a warning..
Tested-By: Justin P. Mattock justinmatt...@gmail.com
cheers as well,
Justin P. Mattock
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 2/6] v4l: subdev: Add device node support
Hi,
v4l2_device *v4l2_dev,
if (err err != -ENOIOCTLCMD) {
v4l2_device_unregister_subdev(sd);
sd = NULL;
+ } else {
+ sd-initialized = 1;
}
Wouldn't checkpatch.pl script complain about { } on the else part since
there is only one statement?
}
CodingStyle is 100% clear on this:
Do not unnecessarily use braces where a single statement will do.
if (condition)
action();
This does not apply if one branch of a conditional statement is a single
statement. Use braces in both branches.
if (condition) {
do_this();
do_that();
} else {
otherwise();
}
Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland RD Center
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.35] mem2mem_testdev bugfix
The following changes since commit ed8c030bde28fc675aae7687a535436579298f06: stv090x: Fix merge conflict caused by changeset f2b3c6d2 (2010-06-01 18:13:26 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung v4l/fixes_for_v2.6.35 Pawel Osciak (1): v4l: mem2mem_testdev: fix g_fmt NULL pointer dereference drivers/media/video/mem2mem_testdev.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) This fixes a NULL-pointer dereference bug reported by Németh Márton. Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v3] Multi-plane buffer support for V4L2 API
Ok, I think I have all the information I need for a v4, which will become quite a major redesign. I will repeat in this post what we discussed on IRC about for everybody. Hans Verkuil mailto:hverk...@xs4all.nl wrote: On Monday 05 July 2010 14:36:38 Pawel Osciak wrote: We will also need to add a new flag to struct v4l2_fmtdesc: V4L2_FMT_FLAG_MPLANE. When enumerating the formats userspace needs to determine whether it is a multiplane format or not. Wouldn't fourcc found in that struct be enough? Since we agreed that we'd like separate fourcc codes for multiplane formats... Drivers and userspace would have to be aware of them anyway. Or am I missing something? How to interpret the data in the planes should indeed be determined by the fourcc. But for libraries like libv4l it would be very useful if they get enough information from V4L to allocate and configure the plane memory. That way the capture code can be generic and the planes can be fed to the conversion code that can convert it to more common formats. In order to write generic capture/output code you need to know whether multiplanar is required and also the number of planes. With this flag you know that you have to use V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE. And through G_FMT with that stream type you can get hold of the number of planes. It might also be a good idea to take one of the reserved fields and let that return the number of planes associated with this format. What do you think? This is not needed, since you get that already through G_FMT. Interesting idea. Although, since an application would still need to be able to recognize new fourccs, how this could be used? To write generic capture/output code. That's actually how all existing apps work: the capture code is generic, then the interpretation of the data is based on the fourcc. As we discussed on IRC, there is no need for that flag after all, as applications will be able to use v4l2_buf_type while calling ENUM_FMT anyway. This actually leads me to a related topic: V4L2_BUF_TYPE_VIDEO_CAPTURE is effectively a subset of V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE. Would it be difficult to support V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE as well for simple single plane formats? It would simplify apps if they can always use MPLANE for capturing. I don't see any problems with that, should be doable out-of-the-box. Regarding the main multi-plane proposal: as we discussed on IRC that should perhaps be combined with pre-registration. I've been thinking that maybe it'd be better to agree on a general shape of this, how to incorporate multiplanes into the API in general, etc., while leaving enough reserved fields for pre-registration extensions (and other things). The interest in this topic seems to have diminished somehow, or rather people just don't have time for this right now. Moreover, realistically speaking, memory pools are something that will not happen in the foreseeable future I'm afraid. We are afraid that with that, multiplanes would get put off for a long time, or even indefinitely. And this is a huge showstopper for us, we are simply unable to post our multimedia drivers without it. I've come to the conclusion that the multiplanar API is needed regardless of any preregistration API. So there is no need to wait for that IMHO. Thanks, this is my opinion as well. Incremental changes are better than huge all-in-ones. What about mixed mmap and userptr planes? I see it like this: if you negotiated n-plane buffers, queuing more than n planes makes all those additional buffers userptr, whatever main memory type has been agreed on. Do you think it would be sufficient? Very good idea. But there needs to be a way to tell the application what the minimum number of planes is, and how many extra userptr 'planes' there can be. And what the size of those extra planes is. Theoretically you can have: - X planes with video data whose size is #lines * bytesperline, using the main memory type. - Y 'planes' with non-video data with some maximum size, but still containing required information so also using the main memory type. - Z optional 'planes' with non-video data with some maximum size which assume userptr as the memory type. All three X, Y and Z values need to be available to the application. The question is if 'Y' can ever be non-zero. I can't think of an example right now, but I learned the hard way that you should never make assumptions. All this info can be part of struct v4l2_pix_format_mplane, I think. You are right, it's safer to assume Y can be nonzero. But I don't think it's a problem though. If we want to use the main memory type for Y planes, it has to be preallocated anyway. The format becomes an X+Y-plane format, and we simply set bytesused on a Y plane to 0 if it is unused. But, as you noticed, we need a way to inform the application about the size of Y planes. So we will add a sizeimage field to each v4l2_plane_format struct. Best
Undeliverable Mail
No message body: investor.relati...@kepland.com Original message follows. -- 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: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Wed, 7 Jul 2010 17:32:43 -0400 Kyle Baker kyleaba...@gmail.com wrote: I've edited the gspca.c file with your suggestion to begin testing, but I'm unable to get the new drivers to compile with and Error 2. Strange! Well, I put the change my test version. May you get this one from my web page and test it? Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/6] v4l: subdev: Add device node support
Hi Hans, On Wednesday 07 July 2010 15:04:17 Hans Verkuil wrote: On Wednesday 07 July 2010 14:30:45 Hans Verkuil wrote: [snip] Some (most ?) I2C sensors need to be accessed during probe. This involves powering the sensor up, which is handled by a board code function called through a platform data function pointer. On the OMAP3 ISP the sensor clock can be generated by the ISP. This means that board code needs to call an ISP (exported) function to turn the clock on. To do so we currently retrieve a pointer to the ISP device through the subdev's parent v4l2_device, embedded in the ISP device structure. This requires the subdev to be registered, otherwise its parent will be NULL. For that reason we're still using the core::s_config operation. This is obviously not an ideal situation, and I'm open to suggestions on how to solve it without core::s_config. One possibility would be to use a global ISP device pointer in the board code, as there's only one ISP device in the system. It feels a bit hackish though. Or make the v4l2_device pointer part of the platform data? That way the subdev driver has access to the v4l2_device pointer in a fairly clean manner. As we've discussed on IRC, the platform data should really store hardware properties, not software/driver information. Beside, storing the v4l2_device pointer in the platform data would be quite difficult, as v4l2_device_register_subdev only sees a void * pointer for platform_data. It has no knowledge of the device-specific structure. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/6] v4l: subdev: Add device node support
Hi Mauro,
On Wednesday 07 July 2010 22:53:40 Mauro Carvalho Chehab wrote:
Em 07-07-2010 16:44, Laurent Pinchart escreveu:
On Wednesday 07 July 2010 16:58:01 Mauro Carvalho Chehab wrote:
Em 07-07-2010 08:53, Laurent Pinchart escreveu:
Create a device node named subdevX for every registered subdev.
As the device node is registered before the subdev core::s_config
function is called, return -EGAIN on open until initialization
completes.
[snip]
+static int subdev_open(struct file *file)
+{
+ struct video_device *vdev = video_devdata(file);
+ struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
+
+ if (!sd-initialized)
+ return -EAGAIN;
Those internal interfaces should not be used on normal
devices/applications, as none of the existing drivers are tested or
supposed to properly work if an external program is touching on its
internal interfaces. So, please add:
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
As Hans pointed out, subdev device nodes should only be created if the
subdev request it explicitly. I'll fix the patch accordingly. Existing
subdevs will not have a device node by default anymore, so the
CAP_SYS_ADMIN capability won't be required (new subdevs that explicitly
ask for a device node are supposed to handle the calls properly,
otherwise it's a bit pointless :-)).
It should be not requested by the subdev, but by the bridge driver (or
maybe by both).
On several drivers, the bridge is connected to more than one subdev, and
some changes need to go to both subdevs, in order to work. As the glue
logic is at the bridge driver, creating subdev interfaces will not make
sense on those devices.
Agreed. I've added a flag that subdev drivers can set to request creation of a
device node explicitly, and an argument to to v4l2_i2c_new_subdev_board and
v4l2_spi_new_subdev to overwrite the flag. A device node will only be created
if the flag is set by the subdev (meaning I can support device nodes) and
the flag is not forced to 0 by the bridge driver (meaning I allow userspace
to access the subdev directly).
[snip]
+static long subdev_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ return video_usercopy(file, cmd, arg, subdev_do_ioctl);
This is a legacy call. Please, don't use it.
What should I use instead then ? I need the functionality of
video_usercopy. I could copy it to v4l2-subdev.c verbatim. As
video_ioctl2 shares lots of code with video_usercopy I think
video_usercopy should stay, and video_ioctl2 should use it.
The bad thing of video_usercopy() is that it has a compat code, to fix
broken definitions of some iotls (see video_fix_command()), and that a few
drivers still use it, instead of video_ioctl2.
video_ioctl2 has the same compat code.
For sure, we don't need the compat code for subdev interface. Also, as
time goes by, we'll eventually have different needs at the subdev interface,
as some types of ioctl's may be specific to subdevs and may require
different copy logic.
We can change the logic then :-)
IMO, the better is to use the same logic inside the subdev stuff, of course
removing that old ioctl fix logic:
#ifdef __OLD_VIDIOC_
cmd = video_fix_command(cmd);
#endif
And replacing the call to:
err = func(file, cmd, parg);
By the proper subdev handling.
What about renaming video_usercopy to __video_usercopy, adding an argument to
enable/disable the compat code, create a new video_usercopy that calls
__video_usercopy with compat code enabled, have video_ioctl2 call
__video_usercopy with compat code enabled, and having subdev_ioctl call
__video_usercopy with compat code disabled ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] V4L2: fix sh_vou.c compile breakage: #include slab.h
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- There have been a bunch of these slab.h patches floating around, I thought, there also was one for sh_vou, but I cannot find it atm. So, if an equivalent patch has been submitted earlier, sorry to the original author and ignore this one. Otherwise, I'll add it to the 2.6.36 queue. drivers/media/video/sh_vou.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/sh_vou.c b/drivers/media/video/sh_vou.c index f5b892a..5f73a01 100644 --- a/drivers/media/video/sh_vou.c +++ b/drivers/media/video/sh_vou.c @@ -18,6 +18,7 @@ #include linux/kernel.h #include linux/platform_device.h #include linux/pm_runtime.h +#include linux/slab.h #include linux/version.h #include linux/videodev2.h -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/6] v4l: subdev: Add device node support
Hi Hans, On Wednesday 07 July 2010 15:04:17 Hans Verkuil wrote: On Wednesday 07 July 2010 14:30:45 Hans Verkuil wrote: [snip] Some (most ?) I2C sensors need to be accessed during probe. This involves powering the sensor up, which is handled by a board code function called through a platform data function pointer. On the OMAP3 ISP the sensor clock can be generated by the ISP. This means that board code needs to call an ISP (exported) function to turn the clock on. To do so we currently retrieve a pointer to the ISP device through the subdev's parent v4l2_device, embedded in the ISP device structure. This requires the subdev to be registered, otherwise its parent will be NULL. For that reason we're still using the core::s_config operation. This is obviously not an ideal situation, and I'm open to suggestions on how to solve it without core::s_config. One possibility would be to use a global ISP device pointer in the board code, as there's only one ISP device in the system. It feels a bit hackish though. Or make the v4l2_device pointer part of the platform data? That way the subdev driver has access to the v4l2_device pointer in a fairly clean manner. As we've discussed on IRC, the platform data should really store hardware properties, not software/driver information. Beside, storing the v4l2_device pointer in the platform data would be quite difficult, as v4l2_device_register_subdev only sees a void * pointer for platform_data. It has no knowledge of the device-specific structure. I think my main problem is the use of s_config. This op was designed to pass irq and platform data to i2c drivers in pre-2.6.26 kernels. Looking at the current tree I see that the only driver using it is mt9v011.c. I think s_config should be removed and mt9v011.c/em28xx-cards.c be changed to use the platform_data directly. Currently s_config is used there to set the sensor xtal, which seems very much hardware specific to me. Instead of s_config I would probably add a 'registered' op that is called automatically by v4l2_device_register_subdev once the subdev has been registered successfully. Subdev drivers can then execute code that can only be run when registered. Later we might add an 'unregistered' op as well should we need it. This seems much more reasonable to me. Comments? Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/6] v4l: subdev: Add device node support
Em 08-07-2010 09:08, Laurent Pinchart escreveu:
Hi Mauro,
On Wednesday 07 July 2010 22:53:40 Mauro Carvalho Chehab wrote:
Em 07-07-2010 16:44, Laurent Pinchart escreveu:
On Wednesday 07 July 2010 16:58:01 Mauro Carvalho Chehab wrote:
Em 07-07-2010 08:53, Laurent Pinchart escreveu:
Create a device node named subdevX for every registered subdev.
As the device node is registered before the subdev core::s_config
function is called, return -EGAIN on open until initialization
completes.
[snip]
+static int subdev_open(struct file *file)
+{
+ struct video_device *vdev = video_devdata(file);
+ struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
+
+ if (!sd-initialized)
+ return -EAGAIN;
Those internal interfaces should not be used on normal
devices/applications, as none of the existing drivers are tested or
supposed to properly work if an external program is touching on its
internal interfaces. So, please add:
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
As Hans pointed out, subdev device nodes should only be created if the
subdev request it explicitly. I'll fix the patch accordingly. Existing
subdevs will not have a device node by default anymore, so the
CAP_SYS_ADMIN capability won't be required (new subdevs that explicitly
ask for a device node are supposed to handle the calls properly,
otherwise it's a bit pointless :-)).
It should be not requested by the subdev, but by the bridge driver (or
maybe by both).
On several drivers, the bridge is connected to more than one subdev, and
some changes need to go to both subdevs, in order to work. As the glue
logic is at the bridge driver, creating subdev interfaces will not make
sense on those devices.
Agreed. I've added a flag that subdev drivers can set to request creation of
a
device node explicitly, and an argument to to v4l2_i2c_new_subdev_board and
v4l2_spi_new_subdev to overwrite the flag. A device node will only be created
if the flag is set by the subdev (meaning I can support device nodes) and
the flag is not forced to 0 by the bridge driver (meaning I allow userspace
to access the subdev directly).
OK.
[snip]
+static long subdev_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ return video_usercopy(file, cmd, arg, subdev_do_ioctl);
This is a legacy call. Please, don't use it.
What should I use instead then ? I need the functionality of
video_usercopy. I could copy it to v4l2-subdev.c verbatim. As
video_ioctl2 shares lots of code with video_usercopy I think
video_usercopy should stay, and video_ioctl2 should use it.
The bad thing of video_usercopy() is that it has a compat code, to fix
broken definitions of some iotls (see video_fix_command()), and that a few
drivers still use it, instead of video_ioctl2.
video_ioctl2 has the same compat code.
Yes, in order to avoid breaking binary compatibility with files compiled against
the old videodev2.h header that used to declare some ioctls as:
#define VIDIOC_OVERLAY _IOWR('V', 14, int)
#define VIDIOC_S_PARM_IOW('V', 22, struct v4l2_streamparm)
#define VIDIOC_S_CTRL_IOW('V', 28, struct v4l2_control)
#define VIDIOC_G_AUDIO _IOWR('V', 33, struct v4l2_audio)
#define VIDIOC_G_AUDOUT _IOWR('V', 49, struct v4l2_audioout)
#define VIDIOC_CROPCAP _IOR('V', 58, struct v4l2_cropcap)
instead of:
#define VIDIOC_OVERLAY _IOW('V', 14, int)
#define VIDIOC_S_PARM _IOWR('V', 22, struct v4l2_streamparm)
#define VIDIOC_S_CTRL _IOWR('V', 28, struct v4l2_control)
#define VIDIOC_G_AUDIO _IOR('V', 33, struct v4l2_audio)
#define VIDIOC_G_AUDOUT _IOR('V', 49, struct v4l2_audioout)
#define VIDIOC_CROPCAP _IOWR('V', 58, struct v4l2_cropcap)
(basically, the old ioctl's were using the wrong _IO macros, preventing a
generic
copy_from_user/copy_to_user code to work)
This doesn't make sense for subdev, as old binary-only applications will never
use the legacy ioctl definitions.
Probably, we can mark this legacy support for removal at
Documentation/feature-removal-schedule.txt, and remove
it on a latter version of the kernel. It seems that the old ioctl definitions
are
before 2005 (before 2.6.12):
^1da177e (Linus Torvalds2005-04-16 15:20:36 -0700 1461) #define
VIDIOC_OVERLAY_OLD _IOWR ('V', 14, int)
^1da177e (Linus Torvalds2005-04-16 15:20:36 -0700 1462) #define
VIDIOC_S_PARM_OLD _IOW ('V', 22, struct v4l2_streamparm)
^1da177e (Linus Torvalds2005-04-16 15:20:36 -0700 1463) #define
VIDIOC_S_CTRL_OLD _IOW ('V', 28, struct v4l2_control)
^1da177e (Linus Torvalds2005-04-16 15:20:36 -0700 1464) #define
VIDIOC_G_AUDIO_OLD _IOWR ('V', 33, struct v4l2_audio)
^1da177e (Linus Torvalds2005-04-16 15:20:36 -0700 1465) #define
VIDIOC_G_AUDOUT_OLD _IOWR ('V', 49, struct v4l2_audioout)
^1da177e (Linus Torvalds2005-04-16 15:20:36 -0700
metodika pohudeniya
http://dx9.gu.ma/ -- 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] IR/mceusb: more streamlining of device init
Spent a while last night getting device initialization packet captures
under Windows for all generations of devices. There are a few places
where we were doing things differently, and few things we were doing
that we don't need to do, particularly on gen3 hardware, and I *think*
one of those things is what was locking up my pinnacle hw from time to
time -- at least, its been perfectly well behaved every time its been
plugged in since making this change.
First up, we're adding a bit more to the gen1 init routine here. Its
not absolutely necessary, the hardware works the same both with and
without it, but I'd like to be consistent w/Windows here.
Second, DEVICE_RESET is never called when initializing either of my
gen3 devices, its only called for gen1 and gen2. The bits in the gen3
init after removing that, are safe (and interesting) to run on all
hardware, so there's no more gen3-specific init done, there's instead
a generic mceusb_get_parameters() that is run for all hardware.
Third, the gen3 flag isn't needed. We only care if hardware is gen3
during probe, so I've dropped that from the device flags struct.
Successfully tested on all three generations of mceusb hardware.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/mceusb.c | 34 ++
1 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index e368b82..78bf7f7 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -254,8 +254,7 @@ struct mceusb_dev {
u32 connected:1;
u32 tx_mask_inverted:1;
u32 microsoft_gen1:1;
- u32 gen3:1;
- u32 reserved:28;
+ u32 reserved:29;
} flags;
/* transmit support */
@@ -292,6 +291,7 @@ struct mceusb_dev {
static char DEVICE_RESET[] = {0x00, 0xff, 0xaa};
static char GET_REVISION[] = {0xff, 0x0b};
static char GET_UNKNOWN[] = {0xff, 0x18};
+static char GET_UNKNOWN2[] = {0x9f, 0x05};
static char GET_CARRIER_FREQ[] = {0x9f, 0x07};
static char GET_RX_TIMEOUT[] = {0x9f, 0x0d};
static char GET_TX_BITMASK[] = {0x9f, 0x13};
@@ -766,6 +766,7 @@ static void mceusb_dev_recv(struct urb *urb, struct pt_regs
*regs)
static void mceusb_gen1_init(struct mceusb_dev *ir)
{
int ret;
+ int maxp = ir-len_in;
struct device *dev = ir-dev;
char *data;
@@ -805,6 +806,14 @@ static void mceusb_gen1_init(struct mceusb_dev *ir)
0x, 0x0100, NULL, 0, HZ * 3);
dev_dbg(dev, %s - retC = %d\n, __func__, ret);
+ /* device reset */
+ mce_async_out(ir, DEVICE_RESET, sizeof(DEVICE_RESET));
+ mce_sync_in(ir, NULL, maxp);
+
+ /* get hw/sw revision? */
+ mce_async_out(ir, GET_REVISION, sizeof(GET_REVISION));
+ mce_sync_in(ir, NULL, maxp);
+
kfree(data);
};
@@ -820,19 +829,17 @@ static void mceusb_gen2_init(struct mceusb_dev *ir)
mce_async_out(ir, GET_REVISION, sizeof(GET_REVISION));
mce_sync_in(ir, NULL, maxp);
- /* unknown what this actually returns... */
+ /* unknown what the next two actually return... */
mce_async_out(ir, GET_UNKNOWN, sizeof(GET_UNKNOWN));
mce_sync_in(ir, NULL, maxp);
+ mce_async_out(ir, GET_UNKNOWN2, sizeof(GET_UNKNOWN2));
+ mce_sync_in(ir, NULL, maxp);
}
-static void mceusb_gen3_init(struct mceusb_dev *ir)
+static void mceusb_get_parameters(struct mceusb_dev *ir)
{
int maxp = ir-len_in;
- /* device reset */
- mce_async_out(ir, DEVICE_RESET, sizeof(DEVICE_RESET));
- mce_sync_in(ir, NULL, maxp);
-
/* get the carrier and frequency */
mce_async_out(ir, GET_CARRIER_FREQ, sizeof(GET_CARRIER_FREQ));
mce_sync_in(ir, NULL, maxp);
@@ -999,7 +1006,6 @@ static int __devinit mceusb_dev_probe(struct usb_interface
*intf,
ir-usbdev = dev;
ir-dev = intf-dev;
ir-len_in = maxp;
- ir-flags.gen3 = is_gen3;
ir-flags.microsoft_gen1 = is_microsoft_gen1;
ir-flags.tx_mask_inverted = tx_mask_inverted;
@@ -1032,16 +1038,12 @@ static int __devinit mceusb_dev_probe(struct
usb_interface *intf,
ir-urb_in-transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
/* initialize device */
- if (ir-flags.gen3)
- mceusb_gen3_init(ir);
-
- else if (ir-flags.microsoft_gen1)
+ if (ir-flags.microsoft_gen1)
mceusb_gen1_init(ir);
-
- else
+ else if (!is_gen3)
mceusb_gen2_init(ir);
- mce_sync_in(ir, NULL, maxp);
+ mceusb_get_parameters(ir);
mceusb_set_tx_mask(ir, MCE_DEFAULT_TX_MASK);
--
1.7.1
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Mantis DMA transfer cleanup, fixes data corruption and a race, improves performance. (signed-off this time)
Hi
This is a resend of the exactly same patch
than I sent 2010-06-20, to sign off it.
Signed-off-by: Marko M Ristola marko.rist...@kolumbus.fi
Regards,
Marko Ristola
-
Here is another version of the DMA transfer fix.
Please try it. Comments?
The current DMA code with drivers/media/dvb/mantis/mantis_dma.c has user
visible problems:
- about 1500 interrupts per second. One CPU can't copy h.264 data over
the network for me (vdr, streamdev).
- 64K garbage at start of the data stream, part of which goes into User
land application.
The garbage data is partly from the same stream (given twice), and
partly from previous tuned frequency (buffer
uninitialized at DMA start).
- Race condition: Memory copying from DMA buffer is done at the same
time as there is DMA transfer going on to the same bytes.
Can this race cause harware problems?
Current DMA code is not clear:
Current DMA RISC coding creates one DMA transfer per 2048 bytes.
Risc command generating code has mantis-line_count=32.
mantis-last_block and mantis-finished_block iterates over [0 to 16].
These counters are confusing. It takes lots of time to look and debug to
understand
what is happening there even for me :(
Basic example how the 64K garbage generation happens:
At mantis_dma_start, mantis-last_block = mantis-finished_block = 0
1st DMA transfer (2048 bytes) generates interrupt, sets
mantis-finished_block=15.
Tasklet will call mantis_dma_xfer(), which iterates from
mantis-last_block = 0 to mantis-finished_block = 14. Set last_block=15.
2nd DMA transfer of 2048 bytes goes quietly (no interrupt generated),
race with the tasklet above here.
3rd DMA transfer sets mantis-finished_block = 0, mantis_dma_xfer()
copies mantis-finished_block = 15. Set last_block=0.
After this copying continues from block 0, so the content is valid,
although block 0 was already partly copied.
Because the current looping implementation is too hard to understand,
I decided to rewrite it and not give you any small patch that fixes the
issue but nobody else understands it.
This doesn't have the alignment stuff at all that I mentioned in earlier
emails last week.
Basic idea:
Keep DMA buffer of size 64k, but generate interrupts four times, thus
one interrupt per 16k.
Rename mantis-finished_block to be mantis-busy_block, because that
keeps mantis_dma_xfer() simple:
while(mantis-last_block != mantis-busy_block) { do copy, last_block =
(last_block + 1) mod 4.
last_block is thus incremented until last_block == busy_block, which
can't be copied yet.
DMA RISC code generation: outer loop iterates over blocks from 0 to 4.
Inner loop iterates over DMA transfer units from 0 to
MANTIS_DMA_TR_UNITS, each DMA transfer is 2048 bytes.
The interrupt is generated at block[0], DMA unit 0: the block 0 is now
busy :)
mantis-line_bytes, mantis-line_count and mantis-risc_pos
were used only for DMA risc code generation.
Removed them from the structure.
Benefits of this code:
- Removes the 64k garbage issue.
- Remove race condition with concurrent DMA transfer and memory copy.
- Lessen interrupts to about 350 per second (seen by powertop) by
moving 16k bytes per interrupt, instead of 4k per interrupt.
The number of interrupts gets much smaller, and it becomes possible
with single core AMD cpu to
deliver h.264 data over the network from vdr via streamdev.
- Mantis DMA code is more understandable for reviewers and others.
My patch is GPLv2.
The patch is made against GIT linuxtv/master, applies cleanly to
Mercurial v4l-dvb too.
Best regards,
Marko Ristola
diff --git a/drivers/media/dvb/mantis/hopper_cards.c
b/drivers/media/dvb/mantis/hopper_cards.c
index 09e9fc7..3b7e376 100644
--- a/drivers/media/dvb/mantis/hopper_cards.c
+++ b/drivers/media/dvb/mantis/hopper_cards.c
@@ -126,7 +126,7 @@ static irqreturn_t hopper_irq_handler(int irq, void
*dev_id)
}
if (stat MANTIS_INT_RISCI) {
dprintk(MANTIS_DEBUG, 0, %s, label[8]);
-mantis-finished_block = (stat MANTIS_INT_RISCSTAT) 28;
+mantis-busy_block = (stat MANTIS_INT_RISCSTAT) 28;
tasklet_schedule(mantis-tasklet);
}
if (stat MANTIS_INT_I2CDONE) {
diff --git a/drivers/media/dvb/mantis/mantis_cards.c
b/drivers/media/dvb/mantis/mantis_cards.c
index cf4b39f..8f048d5 100644
--- a/drivers/media/dvb/mantis/mantis_cards.c
+++ b/drivers/media/dvb/mantis/mantis_cards.c
@@ -134,7 +134,7 @@ static irqreturn_t mantis_irq_handler(int irq, void
*dev_id)
}
if (stat MANTIS_INT_RISCI) {
dprintk(MANTIS_DEBUG, 0, %s, label[8]);
-mantis-finished_block = (stat MANTIS_INT_RISCSTAT) 28;
+mantis-busy_block = (stat MANTIS_INT_RISCSTAT) 28;
tasklet_schedule(mantis-tasklet);
}
if (stat MANTIS_INT_I2CDONE) {
diff --git a/drivers/media/dvb/mantis/mantis_common.h
b/drivers/media/dvb/mantis/mantis_common.h
index d0b645a..23b23b7 100644
--- a/drivers/media/dvb/mantis/mantis_common.h
+++
Re: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
KWORLD DVD Maker USB 2.0 (VS-USB2800) Minor correction, for people who might be searching on the exact model number: KWORLD DVD Maker USB 2.0 (VS-USB2800D) It seemed likely to be supported by the em28xx driver, and I'm pleased to report that, in fact, it is! Yup, it's supported. Ok, I just wanted to submit a detailed report because I didn't see my exact hardware in any of (what I suppose are) the official lists: http://www.mjmwired.net/kernel/Documentation/video4linux/CARDLIST.em28xx http://www.linuxtv.org/wiki/index.php/Em28xx_devices#Validated_boards It's also kinda nice to see that my previous email is already in the top ten google results for *linux kworld dvd maker*. No firmware is involved at all for this device. The Merlin ROM you are seeing is for other devices that use the same underlying driver. Ah, that makes sense. If your device actually has a physical button on it then yes it will work. The driver will generate a KEY_CAMERA input event via inputdev (similar to a keyboard event). Read up on inputdev to see how to write a userland application which can see it. Thanks for those pointers. Now, regarding the difference in image quality between the Linux and Windows drivers, I took some snapshots. Linux is first, then Windows: http://www3.picturepush.com/photo/a/3762966/img/3762966.png http://www4.picturepush.com/photo/a/3762977/img/3762977.png I would have thought that the digitized video coming from the card would be essentially the same in both cases, but the vertical stripes and the difference in width don't seem to be merely a matter of postprocessing. Does the driver have a greater level of control than I suspected over the digitization process in the card? (The difference in sharpness, on the other hand, I would guess to be postprocessing.) So I'm mainly wondering whether the vertical stripes can be eliminated by controlling the card differently, or if we have no control over that and have to deal with it by postprocessing. Ivan -- 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On Thu, Jul 8, 2010 at 1:44 PM, Ivan ivan.q.pub...@gmail.com wrote: Now, regarding the difference in image quality between the Linux and Windows drivers, I took some snapshots. Linux is first, then Windows: http://www3.picturepush.com/photo/a/3762966/img/3762966.png http://www4.picturepush.com/photo/a/3762977/img/3762977.png I would have thought that the digitized video coming from the card would be essentially the same in both cases, but the vertical stripes and the difference in width don't seem to be merely a matter of postprocessing. Does the driver have a greater level of control than I suspected over the digitization process in the card? (The difference in sharpness, on the other hand, I would guess to be postprocessing.) So I'm mainly wondering whether the vertical stripes can be eliminated by controlling the card differently, or if we have no control over that and have to deal with it by postprocessing. The vertical stripes were a problem with the anti-alias filter configuration, which I fixed a few months ago (and probably just hasn't made it into your distribution). Just install the current v4l-dvb code and it should go away: http://linuxtv.org/repo 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
[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:Thu Jul 8 19:00:26 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 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-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 15826] New: WARNING: at fs/proc/generic.c:317 __xlate_proc_name+0xbd/0xe0()
Still present in kernel-2.6.34.1. The dvb card itself has been installed to another computer, different os (archlinux instead of gentoo), warning is still there. [dmesg]... b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully flexcop-pci: will use the HW PID filter. flexcop-pci: card revision 2 b2c2_flexcop_pci :00:0b.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ cut here ] WARNING: at fs/proc/generic.c:317 __xlate_proc_name+0xb3/0xc0() Hardware name: System Name name 'Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver' Modules linked in: b2c2_flexcop_pci(+) i2c_viapro snd(+) soundcore b2c2_flexcop dvb_core cx24123 cx24113 via_ircc uhci_hcd s5h1420 button thermal processor irda crc_ccitt ehci_hcd usbcore via_agp firewire_ohci firewire_core crc_itu_t shpchp pci_hotplug evdev psmouse via_rhine mii emu10k1_gp gameport sg serio_raw pcspkr rtc_cmos rtc_core rtc_lib ext4 mbcache jbd2 crc16 sr_mod cdrom sd_mod pata_via ata_generic pata_acpi floppy libata scsi_mod radeon ttm drm_kms_helper drm agpgart i2c_algo_bit i2c_core Pid: 1187, comm: modprobe Not tainted 2.6.34-ARCH #1 Call Trace: [c104317d] warn_slowpath_common+0x6d/0xa0 [c113b553] ? __xlate_proc_name+0xb3/0xc0 [c113b553] ? __xlate_proc_name+0xb3/0xc0 [c10431f6] warn_slowpath_fmt+0x26/0x30 [c113b553] __xlate_proc_name+0xb3/0xc0 [c113b5b9] __proc_create+0x59/0x100 [c113bed3] proc_mkdir_mode+0x23/0x50 [c113bf0f] proc_mkdir+0xf/0x20 [c10986ab] register_handler_proc+0xeb/0x110 [c1096a3f] __setup_irq+0x19f/0x2f0 [c10e950c] ? kmem_cache_alloc_notrace+0x7c/0xb0 [f8ce7140] ? flexcop_pci_isr+0x0/0x140 [b2c2_flexcop_pci] [c1096c6e] request_threaded_irq+0xde/0x1c0 [c1027516] ? ioremap_nocache+0x16/0x20 [f8ce73e0] flexcop_pci_probe+0x160/0x2b0 [b2c2_flexcop_pci] [c119ad56] pci_device_probe+0x56/0x80 [c1215a27] driver_probe_device+0x77/0x180 [c1215ba9] __driver_attach+0x79/0x80 [c1214c83] bus_for_each_dev+0x43/0x70 [c1215779] driver_attach+0x19/0x20 [c1215b30] ? __driver_attach+0x0/0x80 [c121533d] bus_add_driver+0xbd/0x2d0 [c119aca0] ? pci_device_remove+0x0/0x40 [c1215da5] driver_register+0x65/0x110 [c119af80] __pci_register_driver+0x40/0xb0 [f8cf4017] flexcop_pci_module_init+0x17/0x19 [b2c2_flexcop_pci] [c100120d] do_one_initcall+0x2d/0x190 [f8cf4000] ? flexcop_pci_module_init+0x0/0x19 [b2c2_flexcop_pci] [c1078fed] sys_init_module+0xad/0x210 [c10d8ec9] ? sys_mmap_pgoff+0x89/0x110 [c100379f] sysenter_do_call+0x12/0x28 ---[ end trace d65de7b15fba8e1f ]--- DVB: registering new adapter (FlexCop Digital TV device) b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58 CX24123: cx24123_i2c_readreg: reg=0x0 (error=-121) CX24123: wrong demod revision: 87 usb 2-2: new low speed USB device using uhci_hcd and address 3 b2c2-flexcop: found 'ST STV0299 DVB-S' . DVB: registering adapter 0 frontend 0 (ST STV0299 DVB-S)... b2c2-flexcop: initialization of 'Sky2PC/SkyStar 2 DVB-S rev 2.6' at the 'PCI' bus controlled by a 'FlexCopIIb' complete ... [dmesg] Am Dienstag, 27. April 2010 schrieb Andrew Morton: (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Wed, 21 Apr 2010 12:21:18 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=15826 Summary: WARNING: at fs/proc/generic.c:317 __xlate_proc_name+0xbd/0xe0() Product: v4l-dvb Version: unspecified Kernel Version: 2.6.34-rc5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: dvb-core AssignedTo: v4l-dvb_dvb-c...@kernel-bugs.osdl.org ReportedBy: bugzilla.kernel@boris64.net Regression: No Created an attachment (id=26077) -- (https://bugzilla.kernel.org/attachment.cgi?id=26077) full dmesg I keep getting this warning on boot. It seems to happen when the dvb driver for my technisat skystar2 card is loaded (correct me if i'm wrong). If you need more infos or debug stuff inside my kernel config, please tell me what i need to include. Thank you in advance. ... [0.739420] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully [0.739435] flexcop-pci: will use the HW PID filter. [0.739438] flexcop-pci: card revision 2 [0.739442] b2c2_flexcop_pci :04:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [0.739459] [ cut here ] [0.739463] WARNING: at fs/proc/generic.c:317 __xlate_proc_name+0xbd/0xe0() Alexey, this sucks. A developer goes to the warning site: static int __xlate_proc_name(const char *name, struct proc_dir_entry
Re: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On 07/08/2010 01:52 PM, Devin Heitmueller wrote: The vertical stripes were a problem with the anti-alias filter configuration, which I fixed a few months ago (and probably just hasn't made it into your distribution). Just install the current v4l-dvb code and it should go away: http://linuxtv.org/repo Yep, that gets rid of the vertical stripes but adds in a lovely horizontal shift: http://www3.picturepush.com/photo/a/3763906/img/3763906.png Also, vertical lines look slightly more ragged than they did before, to my eye at least. I'm also encountering this old compilation problem: http://www.mail-archive.com/linux-media@vger.kernel.org/msg06865.html I worked around it by disabling firedtv in v4l/.config. (I'm running 2.6.32-23-generic on Ubuntu Lucid.) Ivan -- 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On Thu, Jul 8, 2010 at 3:52 PM, Ivan ivan.q.pub...@gmail.com wrote: On 07/08/2010 01:52 PM, Devin Heitmueller wrote: The vertical stripes were a problem with the anti-alias filter configuration, which I fixed a few months ago (and probably just hasn't made it into your distribution). Just install the current v4l-dvb code and it should go away: http://linuxtv.org/repo Yep, that gets rid of the vertical stripes but adds in a lovely horizontal shift: http://www3.picturepush.com/photo/a/3763906/img/3763906.png Also, vertical lines look slightly more ragged than they did before, to my eye at least. I'm also encountering this old compilation problem: http://www.mail-archive.com/linux-media@vger.kernel.org/msg06865.html I worked around it by disabling firedtv in v4l/.config. (I'm running 2.6.32-23-generic on Ubuntu Lucid.) Ivan The jagged vertical lines is probably this issue, which was fixed in git but the fix hasn't hit the hg repository yet: http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=9db74cf24c038292d353d746cec11f6da368ef4c The horizontal shift issue is interesting. Does that happen every time? And did you unplug/replug the device? Try to reboot? Regarding the compilation issue, yeah it's annoying. Perhaps someday the Ubuntu people will fix their kernel packaging process. 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On 07/08/2010 04:02 PM, Devin Heitmueller wrote: On Thu, Jul 8, 2010 at 3:52 PM, Ivanivan.q.pub...@gmail.com wrote: Yep, that gets rid of the vertical stripes but adds in a lovely horizontal shift: http://www3.picturepush.com/photo/a/3763906/img/3763906.png The horizontal shift issue is interesting. Does that happen every time? And did you unplug/replug the device? Try to reboot? Reboot? What is this, Windoze? :^D But yeah, it's consistent across unplugs/replugs/reboots. Ivan -- 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On 07/08/2010 04:35 PM, Ivan wrote: On 07/08/2010 04:02 PM, Devin Heitmueller wrote: On Thu, Jul 8, 2010 at 3:52 PM, Ivanivan.q.pub...@gmail.com wrote: Yep, that gets rid of the vertical stripes but adds in a lovely horizontal shift: http://www3.picturepush.com/photo/a/3763906/img/3763906.png The horizontal shift issue is interesting. Does that happen every time? And did you unplug/replug the device? Try to reboot? Reboot? What is this, Windoze? :^D But yeah, it's consistent across unplugs/replugs/reboots. Ok, the horizontal shift disappears if I switch to 720x480 instead of 640x480. Does the card always output 720x480 (in NTSC mode anyway), then, and any scaling is done by V4L? I also have a question about dropped frames. After running mplayer or mencoder, I see a line like: v4l2: 1199 frames successfully processed, -3 frames dropped. I can only guess that the negative number means that V4L received frames at a slightly faster rate than the expected 3/1001 fps. In my case, it would seem that my SNES is producing something more like 30.05 fps, and so V4L reports a negative dropped frame every 12.5 seconds or so. It would also seem that V4L doesn't actually discard any frames, but still passes them on to mplayer/mencoder, because mencoder shows an encoding fps of 30.04 (and it will skip a frame every 12.5 seconds or so unless you pass it -noskip). Am I right about all this? Ivan -- 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On Thu, Jul 8, 2010 at 5:33 PM, Ivan ivan.q.pub...@gmail.com wrote: Ok, the horizontal shift disappears if I switch to 720x480 instead of 640x480. Does the card always output 720x480 (in NTSC mode anyway), then, and any scaling is done by V4L? That card does have an onboard scaler, although it's not clear to me why it isn't working. Exactly what command line did you use? I also have a question about dropped frames. After running mplayer or mencoder, I see a line like: v4l2: 1199 frames successfully processed, -3 frames dropped. I can only guess that the negative number means that V4L received frames at a slightly faster rate than the expected 3/1001 fps. In my case, it would seem that my SNES is producing something more like 30.05 fps, and so V4L reports a negative dropped frame every 12.5 seconds or so. Yeah, I don't know. You would have to ask the mplayer/mencoder people. It would also seem that V4L doesn't actually discard any frames, but still passes them on to mplayer/mencoder, because mencoder shows an encoding fps of 30.04 (and it will skip a frame every 12.5 seconds or so unless you pass it -noskip). Am I right about all this? Again, this would be an mplayer/mencoder thing. 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: Status of the patches under review at LMML (60 patches)
Hi Mauro, == Waiting for Tobias Lorenz tobias.lor...@gmx.net review == Feb, 3 2010: radio-si470x-common: -EINVAL overwritten in si470x_vidioc_s_tuner()http://patchwork.kernel.org/patch/76786 This patch was superseded by the following patch: http://linuxtv.org/hg/~tlorenz/v4l-dvb/raw-rev/72a2f38d5956 Please use this instead. Bye, Toby -- 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On 07/08/2010 05:49 PM, Devin Heitmueller wrote: That card does have an onboard scaler, although it's not clear to me why it isn't working. Exactly what command line did you use? At first, I was always using mplayer tv:// -tv device=/dev/video1:input=1:norm=NTSC which defaults to a resolution of 640x480. This output looked correct (except for vertical stripes) in kernel 2.6.32-23-generic, but was horizontally shifted after I updated to the current mercurial sources. Then I noticed that mplayer tv:// -tv device=/dev/video1:input=1:norm=NTSC:width=720 gives a correct picture with current hg source. v4l2: 1199 frames successfully processed, -3 frames dropped. ... Yeah, I don't know. You would have to ask the mplayer/mencoder people. Ah, so those statistics are generated by mplayer, then, not by v4l. It would also seem that V4L doesn't actually discard any frames... ...blah blah blah about mencoder... Again, this would be an mplayer/mencoder thing. I guess I'm just trying to confirm that v4l doesn't try to enforce a strict NTSC framerate, but just passes all frames on even if they appear at a slightly different framerate. Ivan -- 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] Terratec Cinergy 250 PCI support
Hi Jean-Michel,
Am Sonntag, den 04.07.2010, 19:03 +0200 schrieb Jean-Michel Grimaldi:
Thanks Hermann,
Yes my card is 153b:1160 in dmesg. After testing, the right audio is
actually LINE2 rather than LINE1 (it did not make any difference for
me since I did not use the audio on this card). Hence the following
patch does the job for my card:
sorry for the delay.
Ah, indeed the same PCI subsystem on yours.
Looks like the documentation of the card variants needs improvement.
On the low profile one at the bttv-gallery the chips for digital TV are
not soldered, it has the huge brown 7.5MHz radio IF filter, the yellow
input connector seems to be for radio RF antenna input.
Especially to be noted, it has a KS008 for i2c IR.
But that fuzzy picture on the package there shows the same card as on
your second link. It has extra connectors for audio in and out. (blue
and green)
Like on your card on your first link, 250 PCI Ver.1.0, the KS008 is
missing, the digital TV chips are present, the huge radio IF ceramic
filter is gone and likely replaced by some SMD part, since analog radio
support is still announced, but you don't have the blue and green audio
connectors.
Thanks for testing also the audio input.
Your result is conform to the .inf file in the bttv-gallery.
Is external audio-in over a break out cable together with S-Video?
Is the yellow input for the radio RF antenna or Composite?
The vmux 3 is typically used for an extra Composite input whereas vmux 0
is in most cases Composite over the S-Video connector.
Please post also all dmesg related to the card for the record and in
case we should need it in the future.
BTW, the recent Cinergy HT PCI is cx88x based and comes with a Composite
to S-Video adapter.
http://www.terratec.net/de/produkte/bilder/produkt_bilder_de_4387.html
But for the connectivity they show the HT PCI with saa7131e ...
and point to the yellow input from VCR/DVD/etc.
--- saa7134-cards.old.c2010-07-04 18:50:13.0 +0200
+++ saa7134-cards.new.c2010-07-04 18:17:54.0 +0200
@@ -2832,6 +2832,10 @@
.amux = TV,
.tv = 1,
},{
+.name = name_comp1,
+.vmux = 3,
+.amux = LINE2,
+},{
.name = name_svideo, /* NOT tested */
.vmux = 8,
.amux = LINE1,
I did not touch the existing sections in case another variation of the
card worked with them.
Is this patch ok now?
Regards,
Jean-Michel
Yes, looks at least much better.
We can change the amux of svideo to LINE2 too.
In the attached version of your patch against mercurial v4l-dvb I do
this and sign off for it.
Please reply with your SOB for adding and testing the Composite input
and put it above my reviewed by and the patch should be ready for
lift-off now.
Thanks for working on it,
Hermann
patch is attached
saa7134: add the Composite input on Cinergy 250 PCI and fix related amux
This was untested until now and the changes are also conform to the
.inf file of the Philips driver. We change the amux for S-Video
accordingly too. There are slightly different variants of the card
not yet fully investigated.
Priority: normal
Reviewed-by: hermann pitton hermann-pit...@arcor.de
Signed-off-by: hermann pitton hermann-pit...@arcor.de
2010/7/2 hermann pitton hermann-pit...@arcor.de
Hi Jean-Michel,
Am Mittwoch, den 30.06.2010, 00:02 +0200 schrieb Jean-Michel
Grimaldi:
Hi Hermann,
Thanks for your answer. Do you mean I should add an entry
with .name =
name_comp1, .vmux = 3, .amux = LINE1 ?
Should I remove the svideo entry, given that the card (which
can be
seen at [1]) only has a (proprietary) composite jack?
However there
seems to exist another card with the same name Terratec
Cinergy 250
PCI but different connectors : [2]
What do you think? Should I just add a composite entry and
leave the
svideo as it is?
Jean-Michel
[1] http://www.arminformatique.fr/images/TerraTec%20Cinergy%
20250%
20PCI.jpg
[2] http://www.notebookland.hu/shop
+TERRATEC-CINERGY-250-PCI-TERRATEC-TV-tuner_29849_49
there is also a low profile PCI card.
http://www.terratec.net/de/produkte/bilder/img/2195346_5f78fcd0d7.png
http://www.terratec.net/de/produkte/bilder/produkt_bilder_de_4387.html
Without any such device in my possession and without
sufficient testing
and reports, hard to tell.
Do you have the known subsystem 153b:1160 ?
For that one from http://www.bttv-gallery.de
chips: saa7131e, KS008, 8275ac1
pcb: TV-7131 Ver:B
:00:0b.0 Multimedia controller:
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Thu, Jul 8, 2010 at 6:14 AM, Jean-Francois Moine moin...@free.fr wrote: Strange! Well, I put the change my test version. May you get this one from my web page and test it? Okay, now I've exhausted the quick fixes that you've suggested and have come to a new conclusion. Without modifying the value in gspca_dev-nbalt the drivers will report bandwidth not wide enough - trying again. Modifying this value to subtract between 1 and 8 seems to eliminate this bandwidth error. However, the results ultimately stay the same as before where there is video and no audio for decreasing gspca_dev-nbalt from 0-5. Video input stops working after decreasing by 6-8 while still breaking the audio input, except for decreasing by 8 where the video breaks and audio remains...due to a no transfer endpoint found message. My conclusion, reducing gspca_dev-nbalt by values 1-5 apparently fix the bandwidth issue and don't alter the video input. However, they also do not correct the issue where the microphone breaks and becomes disabled. Below is a log that I kept of each test, compiling the changes, rebooting, testing and recording, then repeating for each decrement. - gspca_dev-nbalt -= 0; /* or same as no change */ Initial startup (audio works) $ dmesg | grep gspca [ 21.268018] gspca: main v2.9.0 registered [ 21.268850] gspca-2.9.50: probing 045e:00f7 [ 21.285392] gspca-2.9.50: video0 created [ 21.285395] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 21.285413] gspca-2.9.50: 045e:00f7 bad interface 1 [ 21.285419] gspca-2.9.50: 045e:00f7 bad interface 2 Started Cheese (video works, no audio) $ dmesg | grep gspca [ 21.268018] gspca: main v2.9.0 registered [ 21.268850] gspca-2.9.50: probing 045e:00f7 [ 21.285392] gspca-2.9.50: video0 created [ 21.285395] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 21.285413] gspca-2.9.50: 045e:00f7 bad interface 1 [ 21.285419] gspca-2.9.50: 045e:00f7 bad interface 2 [ 158.861671] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 160.405694] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 160.405698] gspca-2.9.50: bandwidth not wide enough - trying again [ 160.434684] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 175.635876] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 gspca_dev-nbalt -= 1; Initial startup (audio works) $ dmesg | grep gspca [ 21.905722] gspca: main v2.9.0 registered [ 21.915236] gspca-2.9.50: probing 045e:00f7 [ 21.931505] gspca-2.9.50: video0 created [ 21.931508] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 21.931528] gspca-2.9.50: 045e:00f7 bad interface 1 [ 21.931536] gspca-2.9.50: 045e:00f7 bad interface 2 Started Cheese (video works, no audio) $ dmesg | grep gspca [ 21.905722] gspca: main v2.9.0 registered [ 21.915236] gspca-2.9.50: probing 045e:00f7 [ 21.931505] gspca-2.9.50: video0 created [ 21.931508] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 21.931528] gspca-2.9.50: 045e:00f7 bad interface 1 [ 21.931536] gspca-2.9.50: 045e:00f7 bad interface 2 [ 188.170963] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 188.170963] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 gspca_dev-nbalt -= 2; Initial startup (audio works) $ dmesg | grep gspca [ 22.463556] gspca: main v2.9.0 registered [ 22.466506] gspca-2.9.50: probing 045e:00f7 [ 22.483436] gspca-2.9.50: video0 created [ 22.483438] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 22.483458] gspca-2.9.50: 045e:00f7 bad interface 1 [ 22.483465] gspca-2.9.50: 045e:00f7 bad interface 2 Started Cheese (video works, no audio) $ dmesg | grep gspca [ 22.463556] gspca: main v2.9.0 registered [ 22.466506] gspca-2.9.50: probing 045e:00f7 [ 22.483436] gspca-2.9.50: video0 created [ 22.483438] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 22.483458] gspca-2.9.50: 045e:00f7 bad interface 1 [
Leadtek WinFast PxDVR3200 H scan issues
Greetings, I've aquired myself a /Leadtek WinFast PxDVR3200 H/ and am trying to get it working under Ubuntu 10.04. It's now installed and showing up in the system. I've extracted the firmware and installed it as per http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the_Firmware lspci -vv 02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 03) Subsystem: LeadTek Research Inc. Device 6f39 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at fac0 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 2us, L1 4us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Vital Product Data ? Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: Data: Capabilities: [100] Advanced Error Reporting ? Capabilities: [200] Virtual Channel ? Kernel driver in use: cx23885 Kernel modules: cx23885 However, when I try to scan for channels I get the following errors showing up in messages. scan /usr/share/dvb/dvb-t/au-Brisbane scanning /usr/share/dvb/dvb-t/au-Brisbane using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 22650 1 3 9 3 1 1 0 initial transponder 17750 1 3 9 3 1 1 0 initial transponder 191625000 1 3 9 3 1 1 0 initial transponder 21950 1 3 9 3 1 1 0 initial transponder 585625000 1 2 9 3 1 2 0 tune to: 22650:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE WARNING: tuning failed!!! etc dmesg has the following errors repeated [ 61.354294] cx23885 :02:00.0: firmware: requesting xc3028-v27.fw [ 61.379255] xc2028 2-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [ 61.52] xc2028 2-0061: Loading firmware for type=BASE F8MHZ (3), id . [ 62.065878] xc2028 2-0061: i2c output error: rc = -5 (should be 64) [ 62.065886] xc2028 2-0061: -5 returned from send [ 62.065894] xc2028 2-0061: Error -22 while loading base firmware Any assistance in helping out with getting this to work would be appreciated. Regards, Dave. -- 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
