Re: [RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO
Hi Laurent,
2011-02-25 오후 9:58, Laurent Pinchart 쓴 글:
> Hi,
>
> On Friday 25 February 2011 13:46:01 Kim, HeungJun wrote:
>> As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
>> type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.
>>
>> Signed-off-by: Heungjun Kim
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/media/video/uvc/uvc_ctrl.c |9 -
>> 1 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/video/uvc/uvc_ctrl.c
>> b/drivers/media/video/uvc/uvc_ctrl.c index 59f8a9a..b98b9f1 100644
>> --- a/drivers/media/video/uvc/uvc_ctrl.c
>> +++ b/drivers/media/video/uvc/uvc_ctrl.c
>> @@ -333,6 +333,11 @@ static struct uvc_menu_info exposure_auto_controls[] =
>> { { 8, "Aperture Priority Mode" },
>> };
>>
>> +static struct uvc_menu_info focus_auto_controls[] = {
>> +{ 1, "Auto Mode" },
>> +{ 0, "Manual Mode" },
>
> Now that manual focus has value 0 and auto focus value 1, the menu entries
> need to be the other way around.
I don't really get it. My understanding is that your words are structure
uvc_menu_info should be changed as fitted to focus menu type. right?
But, I thinks they don't need to be changed, and I don't find wrong,
I don't know how to fix what you telling me exactly.
So, could you explain more details? Some examples helps to me.
Sorry to bother if you are busy, but it's good for me your advice.
I'll waiting.
Thanks and Regards,
Heungjun Kim
--
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: Mulling over multi-planar formats and videobuf2 for cx18
Hi Andy,
On Sun, Feb 27, 2011 at 13:31, Andy Walls wrote:
> Hi all,
>
> So I've been looking into converting cx18 to videobuf2 for about a day.
> Overall I think I can make it work. I might not be able to take full
> advantage of some things.
>
> I've encountered these design challenges already:
>
> 1. Supporting V4L2_MPEG_STREAM_VBI_FMT_IVTV
>
> http://linuxtv.org/downloads/v4l-dvb-apis/sliced.html#id2811930
>
> is going to be a hassle, if not impossible, in a single-planar format
> without copying buffers and losing the benefit of zero-copy.
>
> 2. A new technique for detecting missed buffer notifications from the
> CX23418 is needed. The old technique I used won't work, since it relies
> on buffer allocations not being very dynamic at all.
>
> 3. When staring an MPEG capture, the cx18 and ivtv driver can
> automatically start associated metadata or data streams: MPEG Index
> and/or Sliced VBI. Unfortunately the CX23418 engine generally DMAs
> these buffers at different rates, so they are not in lock-step. To take
> adavantage of the multiplanar support in vb2 (which is nice, BTW), I can
> only use zero-copy for the primary capture stream.
>
> 4. When starting up one of the associated data or metadata streams, the
> cx18 driver will likely need to use a vb2 queue internally and not hook
> it to any particular device node in user space. I still need to
> investigate if this is possible; I think it should be.
>
>
> So I have some questions
>
> 1. Do we have any mulitplanar FourCCs defined yet?
>
Yes, we have 3 of them for, currently used in the s5p-fimc driver:
+/* two non contiguous planes - one Y, one Cr + Cb interleaved */
+#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 */
+#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 64x32 macroblocks */
+
+/* three non contiguous planes - Y, Cb, Cr */
+#define V4L2_PIX_FMT_YUV420M v4l2_fourcc('Y', 'M', '1', '2') /* 12
YUV420 planar */
+
> 2. Would an MPEG multiplanar format with these planes be acceptable?
>
> MPEG
> MPEG Index
> MPEG Private packets (holding struct v4l2_mpeg_vbi_fmt_ivtv)
>
Definitely, that's another use for multi-planar formats that Hans
envisioned a year ago, i.e. use planes for not only video data, but
other (meta-)data as well.
> 3. Is a multiplanar format for a particular FourCC envisionsed to always
> have all of its metadata planes present?
This is the next step in the multi-planar extensions: having mandatory
number of planes in each buffer and allowing optional planes to be
passed along with them when needed. The current format could indicate
the obligatory number of planes, while the buffers passed to
qbuf/dqbuf could occasionally have additional planes in them by
increasing buf->length value and adding additional pointers in the
planes array. As long as the driver or an application could identify
those additional planes, they would use them, otherwise they could
safely ignore them.
> For example, what about the above with the "MPEG Index" absent:
>
> MPEG
> MPEG Private packets (holding struct v4l2_mpeg_vbi_fmt_ivtv)
>
> or
>
> MPEG
> MPEG Index
> Sliced VBI (struct v4l2_sliced_vbi_data)
>
> or
>
> MPEG
> Sliced VBI (struct v4l2_sliced_vbi_data)
>
> Instead of having a separate FourCC for each permutaion, would it make
> sense for a plane format be added to struct v4l2_plane_pix_format?
Definitely. We need to design something that would be universal enough though.
>
> 3. I have some additional ideas for some multiplanar formats
>
> HM12
> Sliced VBI (struct v4l2_sliced_vbi_data)
>
> HM12
> Raw VBI
>
> UYVY
> Sliced VBI (struct v4l2_sliced_vbi_data)
>
> UYVY
> Raw VBI
>
> (The CX23418 can actually produce UYVY in hardware, unlike the
> CX23415/6.)
>
> These multiplanar image/data formats can certainly help applications
> keep Video and VBI synchronized.
>
> Would this sort of thing be acceptable? The same question about
> FourCC's for each permutation applies.
>
> Such multiplanar image/data formats somewhat obviate the need to use the
> seperate V4L2 device node for VBI when capturing video. [I'd throw a
> PCM audio data plane in there too, if I though I could get away with
> it. ;) ]
Those are all good ideas. It'd be great if we could do some more
brainstorming, gather requirements for different devices and come up
with an universal solution.
--
Best regards,
Pawel Osciak
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Well supported USB DVB-C device?
On 02/28/2011 02:02 AM, Malte Gell wrote: is there a DVB-C device with USB that is well supported by a recent kernel (2.6.38)? Anysee E30 C Plus is supported as far as I know. Note that new revision of Anysee E30 Combo Plus is no longer supported since they changed to new NXP silicon tuner. E30 Combo Plus and E30 C Plus are different devices. I am not sure which is status of TT CT-3650, it could be other one which is working. Antti -- http://palosaari.fi/ -- 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 v19 0/3] TI Wl1273 FM radio driver.
Hi Mauro, On Tue, Feb 15, 2011 at 05:59:52PM -0200, Mauro Carvalho Chehab wrote: > Em 15-02-2011 06:13, Matti J. Aaltonen escreveu: > > Hello. > > > > Now I've refactored the code so that the I2C I/O functions are in the > > MFD core. Also now the codec can be compiled without compiling the V4L2 > > driver. > > > > I haven't implemented the audio routing (yet), but I've added a TODO > > comment about it in the codec file. > > Matti, > > It looks ok on my eyes. As most of the changes is at the V4L part, it is > probably better to merge this patch via my tree. I'm fine with that, yes. I'll add my Acked-by once Matti has fixed the minor issues I found. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: [PATCH v19 1/3] MFD: WL1273 FM Radio: MFD driver for the FM radio.
Hi Matti
On Tue, Feb 15, 2011 at 10:13:44AM +0200, Matti J. Aaltonen wrote:
> This is the core of the WL1273 FM radio driver, it connects
> the two child modules. The two child drivers are
> drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c.
>
> The radio-wl1273 driver implements the V4L2 interface and communicates
> with the device. The ALSA codec offers digital audio, without it only
> analog audio is available.
The driver looks fine, but for Mauro to take this one you'd have to provide a
diff against the already existing wl1273-core.
I have some minor comments:
> diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
> new file mode 100644
> index 000..66e0ac9
> --- /dev/null
> +++ b/drivers/mfd/wl1273-core.c
> @@ -0,0 +1,295 @@
> +/*
> + * MFD driver for wl1273 FM radio and audio codec submodules.
> + *
> + * Copyright (C) 2010 Nokia Corporation
2011.
> +/**
> + * wl1273_fm_set_volume() - Set volume.
> + * @core:A pointer to the device struct.
> + * @volume: The new volume value.
> + */
> +static int wl1273_fm_set_volume(struct wl1273_core *core, unsigned int
> volume)
> +{
> + u16 val;
> + int r;
> +
> + if (volume > WL1273_MAX_VOLUME)
> + return -EINVAL;
> +
> + if (core->volume == volume)
> + return 0;
> +
> + val = volume;
> + r = wl1273_fm_read_reg(core, WL1273_VOLUME_SET, &val);
> + if (r)
> + return r;
> +
> + core->volume = volume;
> + return 0;
> +}
I'm confused with this one: Isn't WL1273_VOLUME_SET a command ? Also, how can
reading from it set the volume ?
> +static int wl1273_core_remove(struct i2c_client *client)
> +{
> + struct wl1273_core *core = i2c_get_clientdata(client);
> +
> + dev_dbg(&client->dev, "%s\n", __func__);
> +
> + mfd_remove_devices(&client->dev);
> + i2c_set_clientdata(client, NULL)
Not needed.
> +err:
> + i2c_set_clientdata(client, NULL);
Ditto.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.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
Well supported USB DVB-C device?
Hello, is there a DVB-C device with USB that is well supported by a recent kernel (2.6.38)? Thanx Malte -- 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: [st-ericsson] v4l2 vs omx for camera
On Saturday 26 February 2011, Edward Hervey wrote: > > > > Are there any gstreamer/linaro/etc core developers attending the ELC in San > > Francisco > > in April? I think it might be useful to get together before, during or > > after the > > conference and see if we can turn this discussion in something more > > concrete. > > > > It seems to me that there is an overall agreement of what should be done, > > but > > that we are far from anything concrete. > > > > I will be there and this was definitely a topic I intended to talk > about. > See you there. I'll also be there. Should we organize an official BOF session for this and invite more people? Arnd -- 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: MT9P031 camera
On Fri, 25 Feb 2011, Ivan Nazarenko wrote: > Dear Dr. Guennadi. > > I have similar set-up as Mr. Valentini - a Beagleboard XM + leopard imaging > mt0p031 camera. Sorry, I forgot about those additional patches, that I've sent to Juliano. I've sent them to you separately too. Thanks Guennadi > > Could you send me those patches too? > > Regards, > > Ivan > > > > > On Fri, 18 Feb 2011, Juliano Valentini wrote: > > > > > Dears, > > > > > > I'm trying to apply Guennadi's patch > > > (http://download.open-technology.de/BeagleBoard_xM-MT9P031/linux-2.6- > omap3isp-bbxm-mt9p031.gitdiff) > > > to official 2.6.37.1 Kernel version. > > > > No, this cannot work. That kernel patch requires media-controller and > > omap3isp, so, it is based on the omap3isp branch of the development tree > > by Laurent Pinchart: > > > > git://linuxtv.org/pinchartl/media.git > > > > But that tree has been rebased since then, so, I wouldn't expect that > > patch to apply cleanly, porting it to the current kernel would require a > > non-zero development effort. > > > > > I suppose that kernel version is wrong or missing previous patches > > > (see result at the end). > > > I have to make it work: MT9P031 SoC camera module on Beagleboard Xm. > > > Could somebody help me? Where/how can I get the right kernel version? > > > > I'll send you a tarball of those "old" patches off-list. > > > > 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
[GIT PATCHES FOR 2.6.39] ds3000: wrong hardware tune function implemented
The following changes since commit 9e650fdb12171a5a5839152863eaab9426984317: [media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver (2011-02-27 07:50:42 -0300) are available in the git repository at: git://linuxtv.org/liplianin/media_tree.git ds3000-new Igor M. Liplianin (1): ds3000: wrong hardware tune function implemented drivers/media/dvb/frontends/ds3000.c | 15 +-- 1 files changed, 13 insertions(+), 2 deletions(-) -- 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.39] dw2102 updates
The following changes since commit 9e650fdb12171a5a5839152863eaab9426984317: [media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver (2011-02-27 07:50:42 -0300) are available in the git repository at: git://linuxtv.org/liplianin/media_tree.git dw2102 Igor M. Liplianin (5): dw2102: X3M TV SPC1400HD added. dw2102: remove unnecessary delays for i2c transfer for some cards. dw2102: i2c transfer corrected for some cards. dw2102: i2c transfer corrected for yet another cards. dw2102: prof 1100 corrected. drivers/media/dvb/dvb-usb/dw2102.c | 47 +-- 1 files changed, 28 insertions(+), 19 deletions(-) -- 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.39] cx23885, altera-ci: remove operator return in void procedure
The following changes since commit 9e650fdb12171a5a5839152863eaab9426984317: [media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver (2011-02-27 07:50:42 -0300) are available in the git repository at: git://linuxtv.org/liplianin/media_tree.git dual_dvb_t_c_ci_rf Igor M. Liplianin (1): cx23885, altera-ci: remove operator return in void procedure drivers/media/video/cx23885/altera-ci.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) -- 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: dw2102.c: quadratic increment intended?
В сообщении от 27 февраля 2011 22:57:50 автор Malcolm Priestley написал:
> On Sun, 2011-02-27 at 20:30 +0200, Igor M. Liplianin wrote:
> > В сообщении от 27 февраля 2011 16:40:19 автор Török Edwin написал:
> > > Hi,
> >
> > Hi
> >
> > > Please see http://llvm.org/bugs/show_bug.cgi?id=9259#c5, is the code
> > > intended to do a quadratic increment there?
> > >
> > > While looking at this, I wonder if this isn't also a bug in the
> > > original
> > >
> > > code:
> > > /* read stv0299 register */
> > > request = 0xb5;
> > > value = msg[0].buf[0];/* register */
> > > for (i = 0; i < msg[1].len; i++) {
> > >
> > > value = value + i;
> > > ret = dw2102_op_rw(d->udev, 0xb5,
> > >
> > > value, buf6, 2, DW2102_READ_MSG);
> > >
> > > msg[1].buf[i] = buf6[0];
> > >
> > > }
> > >
> > > I don't know anything about the hardware this driver is written for,
> > > but is 'value' really intended to increment quadratically? That seems
> > > suspicious. One
> > >
> > > wonders if the following is what was intended:
> > > [...]
> > > for (i = 0; i < msg[1].len; i++) {
> > >
> > > ret = dw2102_op_rw(d->udev, 0xb5,
> > >
> > > value + i, buf6, 2, DW2102_READ_MSG);
> > >
> > > msg[1].buf[i] = buf6[0];
> > >
> > > }
> >
> > Accidentally, this didn't affect driver, as it reads registers by one
> > register at one time. But it should be corrected.
>
> stv0299, along with other stv02xx family members can read and write the
> entire register map from the start register.
You misundestood me. I spoke about driver features, not about stv0299 features.
Except that, you are right.
>
> However, there is a limitation, the buffer size of the I2C master
> hardware.
--
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Mulling over multi-planar formats and videobuf2 for cx18
Hi all, So I've been looking into converting cx18 to videobuf2 for about a day. Overall I think I can make it work. I might not be able to take full advantage of some things. I've encountered these design challenges already: 1. Supporting V4L2_MPEG_STREAM_VBI_FMT_IVTV http://linuxtv.org/downloads/v4l-dvb-apis/sliced.html#id2811930 is going to be a hassle, if not impossible, in a single-planar format without copying buffers and losing the benefit of zero-copy. 2. A new technique for detecting missed buffer notifications from the CX23418 is needed. The old technique I used won't work, since it relies on buffer allocations not being very dynamic at all. 3. When staring an MPEG capture, the cx18 and ivtv driver can automatically start associated metadata or data streams: MPEG Index and/or Sliced VBI. Unfortunately the CX23418 engine generally DMAs these buffers at different rates, so they are not in lock-step. To take adavantage of the multiplanar support in vb2 (which is nice, BTW), I can only use zero-copy for the primary capture stream. 4. When starting up one of the associated data or metadata streams, the cx18 driver will likely need to use a vb2 queue internally and not hook it to any particular device node in user space. I still need to investigate if this is possible; I think it should be. So I have some questions 1. Do we have any mulitplanar FourCCs defined yet? 2. Would an MPEG multiplanar format with these planes be acceptable? MPEG MPEG Index MPEG Private packets (holding struct v4l2_mpeg_vbi_fmt_ivtv) 3. Is a multiplanar format for a particular FourCC envisionsed to always have all of its metadata planes present? For example, what about the above with the "MPEG Index" absent: MPEG MPEG Private packets (holding struct v4l2_mpeg_vbi_fmt_ivtv) or MPEG MPEG Index Sliced VBI (struct v4l2_sliced_vbi_data) or MPEG Sliced VBI (struct v4l2_sliced_vbi_data) Instead of having a separate FourCC for each permutaion, would it make sense for a plane format be added to struct v4l2_plane_pix_format? 3. I have some additional ideas for some multiplanar formats HM12 Sliced VBI (struct v4l2_sliced_vbi_data) HM12 Raw VBI UYVY Sliced VBI (struct v4l2_sliced_vbi_data) UYVY Raw VBI (The CX23418 can actually produce UYVY in hardware, unlike the CX23415/6.) These multiplanar image/data formats can certainly help applications keep Video and VBI synchronized. Would this sort of thing be acceptable?The same question about FourCC's for each permutation applies. Such multiplanar image/data formats somewhat obviate the need to use the seperate V4L2 device node for VBI when capturing video. [I'd throw a PCM audio data plane in there too, if I though I could get away with it. ;) ] Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] snapshot mode, flash capabilities and control
Hi, Guennadi Liakhovetski wrote: On Fri, 25 Feb 2011, Sakari Ailus wrote: Hi Guennadi, Guennadi Liakhovetski wrote: In principle - yes, and yes, I do realise, that the couple of controls, that I've proposed only cover a very minor subset of the whole flash function palette. The purposes of my RFC were: Why would there be a different interface for controlling the flash in simple cases and more complex cases? Sorry, not sure what you mean. Do you mean different APIs when the flash is controlled directly by the sensor and by an external controller? No, of course we need one API, but you either issue those ioctl()s to the sensor (sub)device, or to the dedicated flash (sub)device. If you mean my "minor subset" above, then I was trying to say, that this is a basis, that has to be extended, but not, that we will develop a new API for more complicated cases. I think I misunderstood you originally, sorry. I should have properly read the RFC. :-) Your proposal of the flash mode is good, but what about software strobe (a little more on that below)? Also, what about making this a V4L2 control instead? The ADP1653 driver that Laurent referred to implements flash control using V4L2 controls only. A version of the driver is here: http://gitorious.org/omap3camera/mainline/commit/a41027c857dfcbc268cf8d1c7c7d0ab8b6abac92> It's not yet in mainline --- one reason for this is the lack of time to discuss a proper API for the flash. :-) ... This doesn't solve the flash/capture synchronization problem though. I don't think we need a dedicated snapshot capture mode at the V4L2 level. A way to configure the sensor to react on an external trigger provided by the flash controller is needed, and that could be a control on the flash sub-device. Well... Sensors call this a "snapshot mode." I don't care that much how we _call_ it, but I do think, that we should be able to use it. Some sensors and webcams might have that, but newer camera solutions tend to contain a raw bayer sensor and and ISP. There is no concept of snapsnot mode in these sensors. Hm, I am not sure I understand, why sensors with DSPs in them should have no notion of a snapshot mode. Do they have no strobe / trigger pins? And no built in possibility to synchronize with a flash? I was referring to ISPs such as the OMAP 3 ISP. Some hardware have a flash strobe pin while some doesn't (such as the N900). Still, even if the strobe pin is missing it should be possible to allow strobing the flash by using software strobe (usually an I2C message). I agree using a hardware strobe is much much better if it's available. Hm, don't think only the "flash subdevice" has to know about this. First, you have to switch the sensor into that mode. Second, it might be either external trigger from the flash controller, or a programmed trigger and a flash strobe from the sensor to the flash (controller). Third, well, not quite sure, but doesn't the host have to know about the snapshot mode? I do not favour adding use case type of functionality to interfaces that do not necessarily need it. Would the concept of a snapshot be parametrisable on V4L2 level? I am open to this. I don't have a good idea of whether camera hosts have to know about the snapshot mode or not. It's open for discussion. What functionality would the snapshot mode provide? Flash synchronisation? Something else? I have to admit I don't know of any hardware which would recognise a concept of "snapshot". Do you have a smart sensor which does this, for example? The only hardware support for the flash use I know of is the flash strobe signal. Flash synchronisation is indeed an issue, and how to tell that a given frame has been exposed with flash. The use of flash is just one of the parameters which would be nice to connect to frames, though. Regards, -- Sakari Ailus sakari.ai...@iki.fi -- 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: dw2102.c: quadratic increment intended?
On Sun, 2011-02-27 at 20:30 +0200, Igor M. Liplianin wrote:
> В сообщении от 27 февраля 2011 16:40:19 автор Török Edwin написал:
> > Hi,
> Hi
>
> >
> > Please see http://llvm.org/bugs/show_bug.cgi?id=9259#c5, is the code
> > intended to do a quadratic increment there?
> >
> > While looking at this, I wonder if this isn't also a bug in the original
> > code:
> >
> > /* read stv0299 register */
> > request = 0xb5;
> > value = msg[0].buf[0];/* register */
> > for (i = 0; i < msg[1].len; i++) {
> > value = value + i;
> > ret = dw2102_op_rw(d->udev, 0xb5,
> > value, buf6, 2, DW2102_READ_MSG);
> > msg[1].buf[i] = buf6[0];
> >
> > }
> >
> > I don't know anything about the hardware this driver is written for, but is
> > 'value' really intended to increment quadratically? That seems
> > suspicious. One
> > wonders if the following is what was intended:
> >
> > [...]
> > for (i = 0; i < msg[1].len; i++) {
> > ret = dw2102_op_rw(d->udev, 0xb5,
> > value + i, buf6, 2, DW2102_READ_MSG);
> > msg[1].buf[i] = buf6[0];
> >
> > }
> >
> Accidentally, this didn't affect driver, as it reads registers by one
> register at one time.
> But it should be corrected.
stv0299, along with other stv02xx family members can read and write the
entire register map from the start register.
However, there is a limitation, the buffer size of the I2C master
hardware.
--
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: [cron job] v4l-dvb daily build: ERRORS
On Sunday, February 27, 2011 19:41:50 Hans Verkuil wrote: > This message is generated daily by a cron job that builds v4l-dvb for > the kernels and architectures in the list below. > > Results of the daily build of v4l-dvb: > > date:Sun Feb 27 19:00:40 CET 2011 > git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f > git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 > host hardware:x86_64 > host os: 2.6.32.5 > > linux-git-armv5: WARNINGS > linux-git-armv5-davinci: WARNINGS > linux-git-armv5-ixp: WARNINGS > linux-git-armv5-omap2: WARNINGS > linux-git-i686: WARNINGS > linux-git-m32r: WARNINGS > linux-git-mips: WARNINGS > linux-git-powerpc64: WARNINGS > linux-git-x86_64: WARNINGS > linux-2.6.31.12-i686: ERRORS > linux-2.6.32.6-i686: ERRORS > linux-2.6.33-i686: ERRORS > linux-2.6.34-i686: ERRORS > linux-2.6.35.3-i686: ERRORS > linux-2.6.36-i686: ERRORS > linux-2.6.37-i686: ERRORS > linux-2.6.31.12-x86_64: ERRORS > linux-2.6.32.6-x86_64: ERRORS > linux-2.6.33-x86_64: ERRORS > linux-2.6.34-x86_64: ERRORS > linux-2.6.35.3-x86_64: ERRORS > linux-2.6.36-x86_64: ERRORS > linux-2.6.37-x86_64: ERRORS > spec-git: OK > sparse: ERRORS Lots of errors here, but I wait with fixing this until the media controller patches are in. I prefer to go through this only once rather than after each new patch set that breaks the build given the limited amount of time that I have. Regards, Hans > > Detailed results are available here: > > http://www.xs4all.nl/~hverkuil/logs/Sunday.log > > Full logs are available here: > > http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 > > The V4L-DVB specification from this daily build is here: > > http://www.xs4all.nl/~hverkuil/spec/media.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- Hans Verkuil - video4linux developer - sponsored by 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
CXD2820 & PCTV nanoStick T2 290e bringup
Hello everyone, I've done some work on bringup of this device in Linux, and now have a stub for the CXD2820 demod that includes the capability to pass I2C commands through to the tuner that sits behind it. The focus was on bringup, not compatibility with linux-media or Linus' coding guidelines, but hopefully it's not so horrendous that it makes you want to cry. This isn't a formal patch submission, but anyone with an interest is welcome to read more and grab the patch here: http://stevekerrison.com/290e/index.html#20110227 taking heed of the warnings and advice where necessary :) Only I2C passthrough is supported - none of the other demodulator or frontend functions work, and it doesn't detach properly. I'd like to know what the best approach would be for me to allow others to contribute to this if they so wish? Many thanks, -- Steve Kerrison MEng Hons. http://www.stevekerrison.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: omap3-isp: can't register subdev for new sensor driver mt9t001
Hello, fail or success in registering these subdevs depend on the sensor code probe() function (at least I think so). When the isp already mentions your driver name saa7113 check your saa7113 driver code and see what can fail in the probe function and add some debug output. Probably the i2c communication doesn't work, but I do not know the code. good luck, Bastian 2011/2/24 Loïc Akue : > > Hello Bastian, > > As a newbie in kernel development, I'm facing the same issue about subdev > registration. > I'm trying to capture some raw video from a SAA7113 connected to the ISP of an > omap3530. May I please have your help with this problem? > > root@cm-t35:~# modprobe iommu > [ 8409.776123] omap-iommu omap-iommu.0: isp registered > > root@cm-t35:~# modprobe omap3_isp > [ 8451.821533] omap3isp omap3isp: Revision 2.0 found > [ 8451.827056] omap-iommu omap-iommu.0: isp: version 1.1 > [ 8453.291992] isp_register_subdev_group: Unable to register subdev saa7113 > > Regards > > Loïc Akue > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ec168-9295d36ab66e compiling error
Dont use my, or anyone else, old HG trees. You should follow that http://www.linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers Antti On 02/24/2011 04:24 PM, Vinicio Nocciolini wrote: Hi all I have problem compiling the project regards Vinicio --- CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/vc032x.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/zc3xx.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-control.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-core.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hdpvr-video.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hopper_cards.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/hopper_vp3028.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-functions.o CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.o /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c: In function '__ir_input_register': /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c:452:24: warning: assignment from incompatible pointer type /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-keytable.c:453:24: warning: assignment from incompatible pointer type CC [M] /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.o /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c: In function 'ir_register_class': /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c:268:23: error: 'ir_raw_dev_type' undeclared (first use in this function) /home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.c:268:23: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [/home/vinicio/Desktop/ec168-9295d36ab66e/v4l/ir-sysfs.o] Error 1 make[2]: *** [_module_/home/vinicio/Desktop/ec168-9295d36ab66e/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.35.11-83.fc14.i686' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/vinicio/Desktop/ec168-9295d36ab66e/v4l' make: *** [all] Error 2 [vinicio@localhost ec168-9295d36ab66e]$ cat /etc/issue Fedora release 14 (Laughlin) Kernel \r on an \m (\l) -- 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 -- http://palosaari.fi/ -- 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: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Feb 27 19:00:40 CET 2011 git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dw2102.c: quadratic increment intended?
В сообщении от 27 февраля 2011 16:40:19 автор Török Edwin написал:
> Hi,
Hi
>
> Please see http://llvm.org/bugs/show_bug.cgi?id=9259#c5, is the code
> intended to do a quadratic increment there?
>
> While looking at this, I wonder if this isn't also a bug in the original
> code:
>
> /* read stv0299 register */
> request = 0xb5;
> value = msg[0].buf[0];/* register */
> for (i = 0; i < msg[1].len; i++) {
> value = value + i;
> ret = dw2102_op_rw(d->udev, 0xb5,
> value, buf6, 2, DW2102_READ_MSG);
> msg[1].buf[i] = buf6[0];
>
> }
>
> I don't know anything about the hardware this driver is written for, but is
> 'value' really intended to increment quadratically? That seems
> suspicious. One
> wonders if the following is what was intended:
>
> [...]
> for (i = 0; i < msg[1].len; i++) {
> ret = dw2102_op_rw(d->udev, 0xb5,
> value + i, buf6, 2, DW2102_READ_MSG);
> msg[1].buf[i] = buf6[0];
>
> }
>
Accidentally, this didn't affect driver, as it reads registers by one register
at one time.
But it should be corrected.
> Best regards,
> --Edwin
--
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 2/2] uvcvideo: Use videobuf2
Replace the uvcvideo buffer queue implementation by videobuf2.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/uvc/Kconfig |1 +
drivers/media/video/uvc/uvc_isight.c | 10 +-
drivers/media/video/uvc/uvc_queue.c | 494 ++
drivers/media/video/uvc/uvc_v4l2.c | 19 +--
drivers/media/video/uvc/uvc_video.c | 30 +-
drivers/usb/gadget/uvc.h |2 +-
include/linux/uvcvideo.h | 37 ++--
7 files changed, 176 insertions(+), 417 deletions(-)
diff --git a/drivers/media/video/uvc/Kconfig b/drivers/media/video/uvc/Kconfig
index 2956a76..6c197da 100644
--- a/drivers/media/video/uvc/Kconfig
+++ b/drivers/media/video/uvc/Kconfig
@@ -1,5 +1,6 @@
config USB_VIDEO_CLASS
tristate "USB Video Class (UVC)"
+ select VIDEOBUF2_VMALLOC
---help---
Support for the USB Video Class (UVC). Currently only video
input devices, such as webcams, are supported.
diff --git a/drivers/media/video/uvc/uvc_isight.c
b/drivers/media/video/uvc/uvc_isight.c
index 8217c5d..eaa5df0 100644
--- a/drivers/media/video/uvc/uvc_isight.c
+++ b/drivers/media/video/uvc/uvc_isight.c
@@ -73,7 +73,7 @@ static int isight_decode(struct uvc_video_queue *queue,
struct uvc_buffer *buf,
* Empty buffers (bytesused == 0) don't trigger end of frame detection
* as it doesn't make sense to return an empty buffer.
*/
- if (is_header && buf->buf.bytesused != 0) {
+ if (is_header && buf->bytesused != 0) {
buf->state = UVC_BUF_STATE_DONE;
return -EAGAIN;
}
@@ -82,13 +82,13 @@ static int isight_decode(struct uvc_video_queue *queue,
struct uvc_buffer *buf,
* contain no data.
*/
if (!is_header) {
- maxlen = buf->buf.length - buf->buf.bytesused;
- mem = queue->mem + buf->buf.m.offset + buf->buf.bytesused;
+ maxlen = buf->length - buf->bytesused;
+ mem = buf->mem + buf->bytesused;
nbytes = min(len, maxlen);
memcpy(mem, data, nbytes);
- buf->buf.bytesused += nbytes;
+ buf->bytesused += nbytes;
- if (len > maxlen || buf->buf.bytesused == buf->buf.length) {
+ if (len > maxlen || buf->bytesused == buf->length) {
uvc_trace(UVC_TRACE_FRAME, "Frame complete "
"(overflow).\n");
buf->state = UVC_BUF_STATE_DONE;
diff --git a/drivers/media/video/uvc/uvc_queue.c
b/drivers/media/video/uvc/uvc_queue.c
index 36f3c58..cb73b08 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
/*
@@ -68,7 +69,7 @@
*
*When the device is disconnected, the kernel calls the completion handler
*with an appropriate status code. The handler marks all buffers in the
- *irq queue as being erroneous (UVC_BUF_STATE_ERROR) and wakes them up so
+ *irq queue as being erroneous (UVC_BUF_STATE_ERROR) and completes them so
*that any process waiting on a buffer gets woken up.
*
*Waking up up the first buffer on the irq list is not enough, as the
@@ -77,414 +78,192 @@
*
*/
-void uvc_queue_init(struct uvc_video_queue *queue, enum v4l2_buf_type type,
- int drop_corrupted)
-{
- mutex_init(&queue->mutex);
- spin_lock_init(&queue->irqlock);
- INIT_LIST_HEAD(&queue->mainqueue);
- INIT_LIST_HEAD(&queue->irqqueue);
- queue->flags = drop_corrupted ? UVC_QUEUE_DROP_CORRUPTED : 0;
- queue->type = type;
-}
-
-/*
- * Free the video buffers.
- *
- * This function must be called with the queue lock held.
+/*
-
+ * videobuf2 queue operations
*/
-static int __uvc_free_buffers(struct uvc_video_queue *queue)
+
+static int uvc_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
+ unsigned int *nplanes, unsigned long sizes[],
+ void *alloc_ctxs[])
{
- unsigned int i;
+ struct uvc_video_queue *queue = vb2_get_drv_priv(vq);
+ struct uvc_streaming *stream =
+ container_of(queue, struct uvc_streaming, queue);
- for (i = 0; i < queue->count; ++i) {
- if (queue->buffer[i].vma_use_count != 0)
- return -EBUSY;
- }
+ if (*nbuffers > UVC_MAX_VIDEO_BUFFERS)
+ *nbuffers = UVC_MAX_VIDEO_BUFFERS;
- if (queue->count) {
- vfree(queue->mem);
- queue->count = 0;
- }
+ *nplanes = 1;
+
+ sizes[0] = stream->ctrl.dwMaxVideoFrameSize;
return 0;
}
-int uvc_free_buffers(struct uvc_video_queue *queue)
+static int uvc_buffer_prepare(s
[RFC/PATCH 1/2] v4l: videobuf2: Handle buf_queue errors
videobuf2 expects drivers to check buffer in the buf_prepare operation
and to return success only if the buffer can queued without any issue.
For hot-pluggable devices, disconnection events need to be handled at
buf_queue time. Checking the disconnected flag and adding the buffer to
the driver queue need to be performed without releasing the driver
spinlock, otherwise race conditions can occur in which the driver could
still allow a buffer to be queued after the disconnected flag has been
set, resulting in a hang during the next DQBUF operation.
This problem can be solved either in the videobuf2 core or in the device
drivers. To avoid adding a spinlock to videobuf2, make buf_queue return
an int and handle buf_queue failures in videobuf2. Drivers must not
return an error in buf_queue if the condition leading to the error can
be caught in buf_prepare.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/videobuf2-core.c | 32 ++--
include/media/videobuf2-core.h |2 +-
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index cc7ab0a..1d81536 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -798,13 +798,22 @@ static int __qbuf_mmap(struct vb2_buffer *vb, struct
v4l2_buffer *b)
/**
* __enqueue_in_driver() - enqueue a vb2_buffer in driver for processing
*/
-static void __enqueue_in_driver(struct vb2_buffer *vb)
+static int __enqueue_in_driver(struct vb2_buffer *vb)
{
struct vb2_queue *q = vb->vb2_queue;
+ int ret;
vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(&q->queued_count);
- q->ops->buf_queue(vb);
+ ret = q->ops->buf_queue(vb);
+ if (ret == 0)
+ return 0;
+
+ vb->state = VB2_BUF_STATE_ERROR;
+ atomic_dec(&q->queued_count);
+ wake_up_all(&q->done_wq);
+
+ return ret;
}
/**
@@ -890,8 +899,13 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
* If already streaming, give the buffer to driver for processing.
* If not, the buffer will be given to driver on next streamon.
*/
- if (q->streaming)
- __enqueue_in_driver(vb);
+ if (q->streaming) {
+ ret = __enqueue_in_driver(vb);
+ if (ret < 0) {
+ dprintk(1, "qbuf: buffer queue failed\n");
+ return ret;
+ }
+ }
dprintk(1, "qbuf of buffer %d succeeded\n", vb->v4l2_buf.index);
return 0;
@@ -1101,6 +1115,7 @@ EXPORT_SYMBOL_GPL(vb2_dqbuf);
int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type type)
{
struct vb2_buffer *vb;
+ int ret;
if (q->fileio) {
dprintk(1, "streamon: file io in progress\n");
@@ -1139,8 +1154,13 @@ int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type
type)
* If any buffers were queued before streamon,
* we can now pass them to driver for processing.
*/
- list_for_each_entry(vb, &q->queued_list, queued_entry)
- __enqueue_in_driver(vb);
+ list_for_each_entry(vb, &q->queued_list, queued_entry) {
+ ret = __enqueue_in_driver(vb);
+ if (ret < 0) {
+ dprintk(1, "streamon: buffer queue failed\n");
+ return ret;
+ }
+ }
dprintk(3, "Streamon successful\n");
return 0;
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 597efe6..3a92f75 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -225,7 +225,7 @@ struct vb2_ops {
int (*start_streaming)(struct vb2_queue *q);
int (*stop_streaming)(struct vb2_queue *q);
- void (*buf_queue)(struct vb2_buffer *vb);
+ int (*buf_queue)(struct vb2_buffer *vb);
};
/**
--
1.7.3.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
[RFC/PATCH 0/2] Convert uvcvideo to videobuf2
Hi everybody, Those two RFC patches convert the uvcvideo driver to videobuf2. The transition was pretty smooth, except for an issue with videobuf2 and hot-pluggable devices. When a hot-pluggable device is disconnected, all pending video buffers must be marked as erroneous and waiters must be woken up. Drivers (and/or videobuf2) must then not allow new buffers to be queued, otherwise applications would wait forever on VIDIOC_DQBUF (side note: maybe it's time for V4L2 to explictly state what should happen in that case, and what error codes must be returned). This isn't a big issue in itself, except that handling the disconnection event in QBUF introduces a race condition. Fixing it can only be done with the help of a spinlock which must be held across the disconnection check and the list_add_tail call in buf_queue. Unfortunately, buf_queue returns void, which prevents checking for the disconnection event there. There are multiple ways to solve this problem. the one I've implemented in this RFC modifies buf_queue to return an error code, and lets drivers implement buffers queue cancellation on disconnect. As this could be a tricky problem, a better solution might be to move disconnection handling inside videobuf2. The downside is that a new spinlock will be needed in videobuf2. Yet another solution would be to let QBUF succeed, but marking the buffer as erroneous and waking up userspace immediately. I don't like this though, as the error flag on buffers is meant to indicate transcient errors, and device disconnection is more on the fatal error side :-) Laurent Pinchart (2): v4l: videobuf2: Handle buf_queue errors uvcvideo: Use videobuf2 drivers/media/video/uvc/Kconfig |1 + drivers/media/video/uvc/uvc_isight.c | 10 +- drivers/media/video/uvc/uvc_queue.c | 494 ++ drivers/media/video/uvc/uvc_v4l2.c | 19 +-- drivers/media/video/uvc/uvc_video.c | 30 +- drivers/media/video/videobuf2-core.c | 32 ++- drivers/usb/gadget/uvc.h |2 +- include/linux/uvcvideo.h | 37 ++-- include/media/videobuf2-core.h |2 +- 9 files changed, 203 insertions(+), 424 deletions(-) -- 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] media/radio/wl1273: fix build errors
From: Randy Dunlap RADIO_WL1273 needs to make sure that the mfd core is built to avoid build errors: ERROR: "mfd_add_devices" [drivers/mfd/wl1273-core.ko] undefined! ERROR: "mfd_remove_devices" [drivers/mfd/wl1273-core.ko] undefined! Signed-off-by: Randy Dunlap Cc: Matti Aaltonen --- (also needed in mainline) drivers/media/radio/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20110223.orig/drivers/media/radio/Kconfig +++ linux-next-20110223/drivers/media/radio/Kconfig @@ -441,6 +441,7 @@ config RADIO_TIMBERDALE config RADIO_WL1273 tristate "Texas Instruments WL1273 I2C FM Radio" depends on I2C && VIDEO_V4L2 + select MFD_CORE select MFD_WL1273_CORE select FW_LOADER ---help--- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l: videobuf2: Typo fix
vb2_get_plane_payload() gets the bytesused field for a plane, it doesn't set it. Signed-off-by: Laurent Pinchart --- include/media/videobuf2-core.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index 0d71fc5..597efe6 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -351,7 +351,7 @@ static inline void vb2_set_plane_payload(struct vb2_buffer *vb, } /** - * vb2_get_plane_payload() - set bytesused for the plane plane_no + * vb2_get_plane_payload() - get bytesused for the plane plane_no * @vb:buffer for which plane payload should be set * @plane_no: plane number for which payload should be set * @size: payload in bytes -- 1.7.3.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
[GIT PATCHES FOR 2.6.39] Make the UVC API public (and bug fixes)
Hi Mauro,
These patches move the uvcvideo.h header file from drivers/media/video/uvc
to include/linux, making the UVC API public.
Martin Rubli has committed support for the public API to libwebcam, so
userspace support is up to date.
The following changes since commit 9e650fdb12171a5a5839152863eaab9426984317:
[media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver
(2011-02-27 07:50:42 -0300)
are available in the git repository at:
git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next
Laurent Pinchart (6):
uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*
uvcvideo: Include linux/types.h in uvcvideo.h
uvcvideo: Move uvcvideo.h to include/linux
uvcvideo: Fix descriptor parsing for video output devices
v4l: videobuf2: Typo fix
Martin Rubli (2):
uvcvideo: Add UVCIOC_CTRL_QUERY ioctl
uvcvideo: Add driver documentation
Stephan Lachowsky (1):
uvcvideo: Fix uvc_fixup_video_ctrl() format search
Documentation/feature-removal-schedule.txt | 23 ++
Documentation/ioctl/ioctl-number.txt |2 +-
Documentation/video4linux/uvcvideo.txt | 239 ++
drivers/media/video/uvc/uvc_ctrl.c | 334
drivers/media/video/uvc/uvc_driver.c | 11 +-
drivers/media/video/uvc/uvc_isight.c |3 +-
drivers/media/video/uvc/uvc_queue.c|3 +-
drivers/media/video/uvc/uvc_status.c |3 +-
drivers/media/video/uvc/uvc_v4l2.c | 45 +++-
drivers/media/video/uvc/uvc_video.c| 17 +-
include/linux/Kbuild |1 +
.../media/video/uvc => include/linux}/uvcvideo.h | 43 ++-
include/media/videobuf2-core.h |2 +-
13 files changed, 550 insertions(+), 176 deletions(-)
create mode 100644 Documentation/video4linux/uvcvideo.txt
rename {drivers/media/video/uvc => include/linux}/uvcvideo.h (95%)
--
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: Fwd: v4l2 lost frame when use with epoll (uvc bug)
Hi, On Monday 14 February 2011 01:25:49 xinglp wrote: > On 2011/2/13 Hans Verkuil wrote: > On Sunday, February 13, 2011 13:33:27 xinglp wrote: > > 2011/2/13 Hans Verkuil : > > > On Sunday, February 13, 2011 09:18:41 xinglp wrote: > > >> It seems like that epoll_wait() do not return as soon as possible when > > >> one frame be captured, it only returns when 4(set by > > >> ioctl(..VIDIOC_REQBUFS..).) frames be captured. > > >> And v4l2_buffer::sequence indecates one lost per 4 frames. > > > > > > What hardware/driver are you using? > > > > I' using uvcvideo. I've tried two cheap usbcam at two PC. > > > > lsusb > > Bus 002 Device 002: ID 1871:01f0 Aveo Technology Corp. > > > > lsmod > > Module Size Used by > > uvcvideo 54924 - > > videodev 65184 - > > > > DG45ID mainboard and a hp2530p notebook. > > A quick follow-up: I could reproduce this with uvc. It works fine with vivi > and gspca, so this seems to be a uvc bug. > > Please post this bug report to the linux-media mailinglist with a CC to > Laurent Pinchart who is the uvc > maintainer. I'm not sure if the problem lies in uvcvideo or in the epoll implementation, but I'm working on using videobuf2 in uvcvideo, and that will fix the issue. > > >> The source in attachment can reproducte it, run it with option --epoll > > >> to make it use epoll. > > >> > > >> The attachment is a modified version of the follow URL. > > >> http://v4l2spec.bytesex.org/v4l2spec/capture.c > > > > > > I can't reproduce this with the vivi driver. It's much more likely to > > > be a driver issue. > > > > On my machine, vivi even not work with epoll(). only capture one frame > > and stop.(epoll_wait() never return again.) > > > > > BTW, it's much better to mail the linux-media mailinglist. Also note > > > that Bill is no longer involved in V4L. > > > > I can't subscribe any kernel maillist successfully. -- 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: [patch v2] [media] stv090x: handle allocation failures
On Tuesday 15 February 2011 11:10:08 Dan Carpenter wrote: > kmalloc() can fail so check whether state->internal is NULL. > append_internal() can return NULL on allocation failures so check that. > Also if we hit the error condition later in the function then there is > a memory leak and we need to call remove_dev() to fix it. > > Also Oliver Endriss pointed out an additional leak that I missed in the > first version of this patch. > > Signed-off-by: Dan Carpenter > --- > v2: Fix the leak Oliver noticed. > > diff --git a/drivers/media/dvb/frontends/stv090x.c > b/drivers/media/dvb/frontends/stv090x.c > ... Acked-by: Oliver Endriss CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: Genuis Emessenger 310 webcam slow work with pac7302 in 2.6.37.1 kernel
В Сбт, 26/02/2011 в 17:11 +0600, housegregory299 пишет: > Hello! My name is Galym, I'm from Kazakhstan. Sorry for my bad English. > My Genuis E-messenger 310 webcam slow work with pac7302 in 2.6.37.1 > kernel. > I lowered the Exposure value ((to reduce freezes) since my webcam is > running slow, (ie, slow picture) but the picture freezes completely. I > had to return the value. (In the previous kernel 2.6.32 everything was > OK, because there used pac7311). > > My device ID: > Bus 005 Device 002: ID 093a:2624 Pixart Imaging, Inc. Webcam > > My system: Debian Squeeze Stable 64-bit with 2.6.37.1 kernel (kernel > installed from Sid Repository) > > I hope for your help. -- 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: Genuis Emessenger 310 webcam slow work with pac7302 in 2.6.37.1 kernel
В Вск, 27/02/2011 в 18:37 +0600, housegregory299 пишет:
> > As I understand the webcam was not working properly even using 2.6.32
> > kernel.
>
> Yes, this is so. But in near installed Windows 7 webcam also work slow
> and picture quality is worse than on Debian with 2.6.37. I think my
> webcam very limited functionality. I have to keep both the kernels on my
> system - 2.6.32 and 2.6.37 and switch between them on the need.
>
> > Are you using v4l2ucp for setting exposure value? This command is
> > available
> > from the v4l2ucp Debian package. Are the other controls working
> > properly?
>
> I use v4l2ucp from command line to saving and loading webcam's
> customised parameters, (v4l2ucp -s .webcam and v4l2ucp -l .webcam)
> but with other keys are not used. All parameters in Guvcview work fine
> and properly, except Exposure.
>
> > Some more hints for the trying the "test images": make sure that
> > v4l-utils
> > Debian package is installed ("apt-get install v4l-utils" as root).
> > Then
> > you can use the command "v4l2-dbg --set-register=0x72 x" where "x" is
> > any
> > number between 0 and 15. This command has to be executed as root. To
> > return
> > to the normal operation just use the zero value for x. I'm not sure
> > that
> > these test patterns will work for your webcam model also, but it would
> > be
> > interesting to try.
>
> command "v4l2-dbg --set-register=0x72 10 not help to me: With value 0
> output are similar:
>
> root@debian:/home/t800# v4l2-dbg --set-register=0x72 10
> Failed to set register 0x0072 value 0xa: Invalid argument
>
> But i try setup my webcam with v4l-utils.
>
> > The main problem is that the manufacturer of the chip which is
> > included
> > in your webcam neither released programming documentation nor
> > implemented
> > a standard protocol like USB Video Class. Without documentation open
> > source
> > projects can only use trial and error
> > ( http://en.wikipedia.org/wiki/Trial_and_error ).
>
> I understand, OK. So.. Which webcam is better suited for Linux systems -
> UVC standard ? This is open? or closed? Sorry, if this question is wrong
> - i don't know which webcam select for my Linux-system.
>
> > I would strongly recommend to add the mailing list
> > "linux-media@vger.kernel.org"
> > in CC field, so more people can see this conversation.
>
> OK. I do 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: Genuis Emessenger 310 webcam slow work with pac7302 in 2.6.37.1 kernel
В Вск, 27/02/2011 в 05:26 +0600, housegregory299 пишет: > Hello! Thanks for answer to me. > Outputs from these commands: > > root@debian:/home/t800# cat /proc/version > Linux version 2.6.37-1-amd64 (Debian 2.6.37-1) (b...@decadent.org.uk) > (gcc version 4.4.5 (Debian 4.4.5-10) ) #1 SMP Tue Feb 15 17:43:38 UTC > 2011 > > dpkg -l libv4l-0 : > ii libv4l-0 0.8.0-1Collection of video4linux support > libraries > > root@debian:/home/t800# dpkg -l |grep linux-image > ii linux-image-2.6-amd64 2.6.32+29 > Linux 2.6 for 64-bit PCs (meta-package) > ii linux-image-2.6.32-5-amd642.6.32-30 > Linux 2.6.32 for 64-bit PCs > ii linux-image-2.6.37-1-amd642.6.37-1 > Linux 2.6.37 for 64-bit PCs > > dmesg output: No Errors > [5.497771] gspca: v2.10.0 registered > [5.575635] gspca: probing 093a:2624 > [5.579935] input: pac7302 > as /devices/pci:00/:00:1d.3/usb5/5-2/input/input6 > [5.580056] gspca: video0 created > [5.580084] usbcore: registered new interface driver pac7302 > [5.658209] usbcore: registered new interface driver snd-usb-audio > > Frame rate not depend on the content of image, but in 2.6.32 kernel is > depend on Exposure, i set up the webcam through the program guvcview, > (in 2.6.32) and lowered Exposure value to 0% and freezes disappeared, > and will be OK. But the colors were a bit distorted and blurred. > In the 2.6.37.1 (Installed from Sid Repository) colors are better on > image, but I can not lower the value Exposure to reduce freezes, but > increase this value is impossible without freezes or slow frame rate. > > Therefore, I usually lower them parameter to configure. Earlier this > helps. But not with the new kernel. I also tried ubuntu 10.10 with > 2.6.35.xx stock kernel and freezes there be similar. > Webcam's image normally visible in Cheese, skype and Kopete. > Thank you for tips, > I'll definitely try them. It is a pity that it happened, in the new > kernel has many improvements to my PC > > My PC's quick specs: > Gigabyte G31M-ES2L Motherboard > CPU: Intel Dualcore 2.93 GHz > 4 GB Ram > Realtek HD alc883 audio integrated > GPU: ATI Radeon HD 4650 (1024 mb) GDDR2 PC-e x16 by Gigabyte > > In Debian/Ubuntu distros all devices work fine - without any problem > except webcam. > > Translating partially done by Google Translator and > > I'll understand a little English =) > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] TI WL 128x FM V4L2 driver
Em 25-01-2011 03:48, halli manjunatha escreveu: > Hi Mauro, > > Please pull the WL128x FM V4L2 driver from > http://dev.omapzoom.org/pub/scm/manju/L24x-btfm.git fm_v4l2_upstream > > This is TI WL128x FM V4L2 driver and it introduces ‘wl128x’ folder > under the ‘drivers/media/radio’. This driver enables support for FM RX > and TX for Texas Instrument's WL128x (also compatible with WL127x) > WiLink chip sets. The V4L2 FM driver can work in either Rx or Tx mode, > and V4L2 interfaces are provided for both. > > Texas Instrument's WL128x chip set packs BT, FM, GPS and WLAN in a > single die with BT, FM and GPS being interfaced over a single UART. > This driver works on top of the shared transport line discipline > driver. This driver can also be made use for the WL127x version of the > chip which packs BT, FM and WLAN only. > > This driver has been reviewed by various folks within TI and also in > Linux media community. The driver has been tested extensively on TI > platforms and we believe that it is ready for merge into mainline. Applied, thanks. >From what I understood from your comments, this driver will also cover wl127x chips. As such, it would be better to double check if all functionalities present at drivers/media/radio/radio-wl1273.c (assuming that wl1273 is covered) are also on the new driver, and, if not, merge the remaining ones and deprecate the wl1273-specific driver. Cheers, Mauro > > The following changes since commit db309d3d54c2f721dd1176ce86c63b0381c0a258: > Mauro Carvalho Chehab (1): > [media] add support for Encore FM3 > > are available in the git repository at: > > http://dev.omapzoom.org/pub/scm/manju/L24x-btfm.git fm_v4l2_upstream > > Manjunatha Halli (7): > drivers:media:radio: wl128x: FM Driver common header file > drivers:media:radio: wl128x: FM Driver V4L2 sources > drivers:media:radio: wl128x: FM Driver Common sources > drivers:media:radio: wl128x: FM driver RX sources > drivers:media:radio: wl128x: FM driver TX sources > drivers:media:radio: wl128x: Kconfig & Makefile for wl128x driver > drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver > > drivers/media/radio/Kconfig |3 + > drivers/media/radio/Makefile |1 + > drivers/media/radio/wl128x/Kconfig| 17 + > drivers/media/radio/wl128x/Makefile |6 + > drivers/media/radio/wl128x/fmdrv.h| 244 + > drivers/media/radio/wl128x/fmdrv_common.c | 1677 > + > drivers/media/radio/wl128x/fmdrv_common.h | 402 +++ > drivers/media/radio/wl128x/fmdrv_rx.c | 847 +++ > drivers/media/radio/wl128x/fmdrv_rx.h | 59 + > drivers/media/radio/wl128x/fmdrv_tx.c | 425 > drivers/media/radio/wl128x/fmdrv_tx.h | 37 + > drivers/media/radio/wl128x/fmdrv_v4l2.c | 580 ++ > drivers/media/radio/wl128x/fmdrv_v4l2.h | 33 + > 13 files changed, 4331 insertions(+), 0 deletions(-) > create mode 100644 drivers/media/radio/wl128x/Kconfig > create mode 100644 drivers/media/radio/wl128x/Makefile > create mode 100644 drivers/media/radio/wl128x/fmdrv.h > create mode 100644 drivers/media/radio/wl128x/fmdrv_common.c > create mode 100644 drivers/media/radio/wl128x/fmdrv_common.h > create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.c > create mode 100644 drivers/media/radio/wl128x/fmdrv_rx.h > create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.c > create mode 100644 drivers/media/radio/wl128x/fmdrv_tx.h > create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.c > create mode 100644 drivers/media/radio/wl128x/fmdrv_v4l2.h > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
