Re: [PATCH v1 16/19] v4l: Add encoding camera controls.
On 09/09/2013 05:48 AM, Pawel Osciak wrote: Hi Hans, Thanks for the comments, one question inline. On Fri, Aug 30, 2013 at 3:48 PM, Hans Verkuil hverk...@xs4all.nl wrote: On 08/30/2013 04:17 AM, Pawel Osciak wrote: Add defines for controls found in UVC 1.5 encoding cameras. Signed-off-by: Pawel Osciak posc...@chromium.org --- drivers/media/v4l2-core/v4l2-ctrls.c | 29 + include/uapi/linux/v4l2-controls.h | 31 +++ 2 files changed, 60 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c index c3f0803..0b3a632 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -781,6 +781,35 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_AUTO_FOCUS_STATUS:return Auto Focus, Status; case V4L2_CID_AUTO_FOCUS_RANGE: return Auto Focus, Range; + case V4L2_CID_ENCODER_MIN_FRAME_INTERVAL: return Encoder, min. frame interval; + case V4L2_CID_ENCODER_RATE_CONTROL_MODE: return Encoder, rate control mode; + case V4L2_CID_ENCODER_AVERAGE_BITRATE: return Encoder, average bitrate; + case V4L2_CID_ENCODER_CPB_SIZE: return Encoder, CPB size; + case V4L2_CID_ENCODER_PEAK_BIT_RATE:return Encoder, peak bit rate; + case V4L2_CID_ENCODER_QP_PARAM_I: return Encoder, QP param for I frames; + case V4L2_CID_ENCODER_QP_PARAM_P: return Encoder, QP param for P frames; + case V4L2_CID_ENCODER_QP_PARAM_BG: return Encoder, QP param for B/G frames; A lot of these exist already. E.g. V4L2_CID_MPEG_VIDEO_MPEG4_I/P/B_FRAME_QP. Samsung added support for many of these parameters for their MFC encoder (including VP8 support) so you should use them as well. As mentioned in v4l2-controls.h the MPEG part of the control name is historical. Interpret it as 'CODEC', not MPEG. We have QP controls separately for H264, H263 and MPEG4. Why is that? Which one should I use for VP8? Shouldn't we unify them instead? I can't quite remember the details, so I've CCed Kamil since he added those controls. At least the H264 QP controls are different from the others as they have a different range. What's the range for VP8? I'm not sure why the H263/MPEG4 controls weren't unified: it might be that since the H264 range was different we decided to split it up per codec. But I seem to remember that there was another reason as well. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 16/19] v4l: Add encoding camera controls.
On Mon, Sep 9, 2013 at 4:52 PM, Hans Verkuil hverk...@xs4all.nl wrote: On 09/09/2013 05:48 AM, Pawel Osciak wrote: Hi Hans, Thanks for the comments, one question inline. On Fri, Aug 30, 2013 at 3:48 PM, Hans Verkuil hverk...@xs4all.nl wrote: On 08/30/2013 04:17 AM, Pawel Osciak wrote: Add defines for controls found in UVC 1.5 encoding cameras. Signed-off-by: Pawel Osciak posc...@chromium.org --- drivers/media/v4l2-core/v4l2-ctrls.c | 29 + include/uapi/linux/v4l2-controls.h | 31 +++ 2 files changed, 60 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c index c3f0803..0b3a632 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -781,6 +781,35 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_AUTO_FOCUS_STATUS:return Auto Focus, Status; case V4L2_CID_AUTO_FOCUS_RANGE: return Auto Focus, Range; + case V4L2_CID_ENCODER_MIN_FRAME_INTERVAL: return Encoder, min. frame interval; + case V4L2_CID_ENCODER_RATE_CONTROL_MODE: return Encoder, rate control mode; + case V4L2_CID_ENCODER_AVERAGE_BITRATE: return Encoder, average bitrate; + case V4L2_CID_ENCODER_CPB_SIZE: return Encoder, CPB size; + case V4L2_CID_ENCODER_PEAK_BIT_RATE:return Encoder, peak bit rate; + case V4L2_CID_ENCODER_QP_PARAM_I: return Encoder, QP param for I frames; + case V4L2_CID_ENCODER_QP_PARAM_P: return Encoder, QP param for P frames; + case V4L2_CID_ENCODER_QP_PARAM_BG: return Encoder, QP param for B/G frames; A lot of these exist already. E.g. V4L2_CID_MPEG_VIDEO_MPEG4_I/P/B_FRAME_QP. Samsung added support for many of these parameters for their MFC encoder (including VP8 support) so you should use them as well. As mentioned in v4l2-controls.h the MPEG part of the control name is historical. Interpret it as 'CODEC', not MPEG. We have QP controls separately for H264, H263 and MPEG4. Why is that? Which one should I use for VP8? Shouldn't we unify them instead? I can't quite remember the details, so I've CCed Kamil since he added those controls. At least the H264 QP controls are different from the others as they have a different range. What's the range for VP8? Yes, it differs, 0-127. But I feel this is pretty unfortunate, is it a good idea to multiply controls to have one per format when they have different ranges depending on the selected format in general? Perhaps a custom handler would be better? I'm not sure why the H263/MPEG4 controls weren't unified: it might be that since the H264 range was different we decided to split it up per codec. But I seem to remember that there was another reason as well. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
iMon driver with 3.11 no response
Hey Jarod, I've been using my iMon that came with my silverstone tech case for years. This was all using the old methods via lirc etc. With my new install I decided to move to devinput and use your brand new and shiny driver. However I get little to no response from either the IR part, the knob or the VFD (I just echo Hello /dev/lcd0). The only thing I do know works, is powerup (since that's all handled on the PCB itself, that's no surprise, but does show the board seems to be still in working order). The driver (when loading rc-imon-pad first) loads fine, but evtest doesn't respond to anything. I tried with lirc initially and devinput but also that gave no response. The debug output from imon when loading it with debug=1 as follows: [ 568.738241] input: iMON Panel, Knob and Mouse(15c2:ffdc) as /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.0/input/input19 [ 568.746030] imon 5-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR [ 568.746033] (id 0x2e) [ 568.746036] Registered IR keymap rc-imon-pad [ 568.746140] input: iMON Remote (15c2:ffdc) as /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.0/rc/rc4/input20 [ 568.746194] rc4: iMON Remote (15c2:ffdc) as /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.0/rc/rc4 [ 568.754091] imon 5-2:1.0: iMON device (15c2:ffdc, intf0) on usb5:2 initialized [ 568.754116] usbcore: registered new interface driver imon [ 568.755501] imon 5-2:1.0: Looks like you're trying to use an IR protocol this device does not support [ 568.755506] imon 5-2:1.0: Unsupported IR protocol specified, overriding to iMON IR protocol If you say that I'd need to double check if the original stuff still even works, I'll jerry rig some stuff and make sure that I can test it, but since I assume it works just fine, is there some deeper debug level that shows even more output? Is there anything else that I can do to test it really even works at all? Is evtest able to test the created input? It can't be an IR thing, since the knob doesn't produce output either, and lsusb shows up fine so communication seems to work to some length? THat last warning seems odd though? Oliver -- 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: Updated fi-HTV scan file
On 07-09-13 15:36, Sam Stenvall wrote: Hi, Hello, Here's an updated fi-HTV scan file according to the official specification available at http://dvb.welho.fi/cable.php. Patch merged manually and pushed, your diff failed to apply, did you use git diff? Oliver diff -r 3ee111da5b3a util/scan/dvb-c/fi-HTV --- a/util/scan/dvb-c/fi-HTVMon May 13 15:49:02 2013 +0530 +++ b/util/scan/dvb-c/fi-HTVSat Sep 07 16:32:53 2013 +0300 @@ -1,4 +1,38 @@ # HTV # freq sr fec mod -C 28300 590 NONE QAM128 +C 27400 690 NONE QAM128 +C 28200 690 NONE QAM128 +C 16200 690 NONE QAM64 +C 17000 690 NONE QAM128 +C 29000 690 NONE QAM128 +C 14600 690 NONE QAM128 C 15400 690 NONE QAM128 +C 13800 690 NONE QAM128 +C 26600 690 NONE QAM128 +C 36200 690 NONE QAM128 +C 29800 690 NONE QAM128 +C 35400 690 NONE QAM128 +C 37000 690 NONE QAM128 +C 37800 690 NONE QAM128 +C 39400 690 NONE QAM128 +C 38600 690 NONE QAM128 +C 25800 690 NONE QAM128 +C 25000 690 NONE QAM128 +C 31400 690 NONE QAM128 +C 30600 690 NONE QAM64 +C 32200 690 NONE QAM128 +C 33000 690 NONE QAM256 +C 33800 690 NONE QAM256 +C 34600 690 NONE QAM128 +C 23400 690 NONE QAM256 +C 21000 690 NONE QAM256 +C 21800 690 NONE QAM256 +C 22600 690 NONE QAM256 +C 17800 690 NONE QAM256 +C 18600 690 NONE QAM256 +C 19400 690 NONE QAM256 +C 20200 690 NONE QAM256 +C 51400 690 NONE QAM256 +C 52200 690 NONE QAM256 +C 53000 690 NONE QAM256 +C 55400 690 NONE QAM256 Regards, Sam Stenvall -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1 16/19] v4l: Add encoding camera controls.
Hi, From: Pawel Osciak [mailto:posc...@chromium.org] Sent: Monday, September 09, 2013 9:59 AM On Mon, Sep 9, 2013 at 4:52 PM, Hans Verkuil hverk...@xs4all.nl wrote: On 09/09/2013 05:48 AM, Pawel Osciak wrote: Hi Hans, Thanks for the comments, one question inline. On Fri, Aug 30, 2013 at 3:48 PM, Hans Verkuil hverk...@xs4all.nl wrote: On 08/30/2013 04:17 AM, Pawel Osciak wrote: Add defines for controls found in UVC 1.5 encoding cameras. Signed-off-by: Pawel Osciak posc...@chromium.org --- drivers/media/v4l2-core/v4l2-ctrls.c | 29 + include/uapi/linux/v4l2-controls.h | 31 +++ 2 files changed, 60 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c index c3f0803..0b3a632 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -781,6 +781,35 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_AUTO_FOCUS_STATUS:return Auto Focus, Status; case V4L2_CID_AUTO_FOCUS_RANGE: return Auto Focus, Range; + case V4L2_CID_ENCODER_MIN_FRAME_INTERVAL: return Encoder, min. frame interval; + case V4L2_CID_ENCODER_RATE_CONTROL_MODE: return Encoder, rate control mode; + case V4L2_CID_ENCODER_AVERAGE_BITRATE: return Encoder, average bitrate; + case V4L2_CID_ENCODER_CPB_SIZE: return Encoder, CPB size; + case V4L2_CID_ENCODER_PEAK_BIT_RATE:return Encoder, peak bit rate; + case V4L2_CID_ENCODER_QP_PARAM_I: return Encoder, QP param for I frames; + case V4L2_CID_ENCODER_QP_PARAM_P: return Encoder, QP param for P frames; + case V4L2_CID_ENCODER_QP_PARAM_BG: return Encoder, QP param for B/G frames; A lot of these exist already. E.g. V4L2_CID_MPEG_VIDEO_MPEG4_I/P/B_FRAME_QP. Samsung added support for many of these parameters for their MFC encoder (including VP8 support) so you should use them as well. As mentioned in v4l2-controls.h the MPEG part of the control name is historical. Interpret it as 'CODEC', not MPEG. We have QP controls separately for H264, H263 and MPEG4. Why is that? Which one should I use for VP8? Shouldn't we unify them instead? I can't quite remember the details, so I've CCed Kamil since he added those controls. At least the H264 QP controls are different from the others as they have a different range. What's the range for VP8? Yes, it differs, 0-127. But I feel this is pretty unfortunate, is it a good idea to multiply controls to have one per format when they have different ranges depending on the selected format in general? Perhaps a custom handler would be better? I'm not sure why the H263/MPEG4 controls weren't unified: it might be that since the H264 range was different we decided to split it up per codec. But I seem to remember that there was another reason as well. We had a discussion about this on linux-media mailing list. It can be found here: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/326 06 In short, it is a mix of two reasons: one - the valid range is different for different formats and second - implementing controls which have different min/max values depending on format was not easy. On the one hand I am thinking that now, when we have more codecs, it would be better to have a single control, on the other hand what about backward compatibility? Is there a graceful way to merge H263 and H264 QP controls? Best wishes, Kamil -- 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] V4L: Drop meaningless video_is_registered() call in v4l2_open()
On 09/06/2013 12:33 AM, Sylwester Nawrocki wrote: Hi Hans, Sorry for putting this on a back burner for a while. On 08/07/2013 07:49 PM, Hans Verkuil wrote: On 08/07/2013 06:49 PM, Sylwester Nawrocki wrote: Hi Hans, On 08/02/2013 03:00 PM, Hans Verkuil wrote: Hi Sylwester, The patch is good, but I have some issues with the commit message itself. Thanks a lot for the detailed explanation, I just wrote this a bit longish changelog to possibly get some feedback and to better understand what is exactly going on. Currently the v4l2-core looks like a racing disaster to me. On 08/02/2013 02:27 PM, Sylwester Nawrocki wrote: As it currently stands this code doesn't protect against any races between video device open() and its unregistration. Races could be avoided by doing the video_is_registered() check protected by the core mutex, while the video device unregistration is also done with this mutex held. The video_unregister_device() is called completely asynchronously, particularly in the case of usb drivers. So it was never the goal of the video_is_registered() to be fool proof, since that isn't possible, nor is that necessary. The goal was that the v4l2 core would use it for the various file operations and ioctls as a quick check whether the device was unregistered and to return the correct error. This prevents drivers from having to do the same thing. OK, I think I just myself used this video_is_registered() flag for some more stuff, by surrounding it with mutex_lock/mutex_unlock and putting more stuff in between, like media_entity_cleanup(). You can't do that, because there are most likely still filehandles open or even ioctls being executed. Cleanup happens in the release function(s) when the kref goes to 0. Yeah, a bit late, but I'm finally well aware of that. And this probably led me astray for a while, thinking that video_is_registered() was intended to be used synchronously. For example see fimc_lite_subdev_unregistered() in drivers/media/platform/ exynos4-is/fimc-lite.c. But as you said video_is_registered() is fully asynchronous. Actually I'm trying to fix a nasty race between deferred driver probing and video device open(). The problem is that video open() callback can be called after driver remove() callback was invoked. How is that possible? The video_device_register must be the last thing in the probe function. If it succeeds, then the probe must succeed as well. Note that I now realize that this might fail in the case of multiple device nodes being registered. We never had problems with that in the past, but in theory you can the race condition you mention in that scenario. The correct approach here would probably be to always return 0 in probe() if only some of the video_device_register calls fail. Anyway, assuming that only one device node is created, then I can't see how you can get a race condition here. Any open() call will increase the module's refcount, making it impossible to unload. The main issue is that in the exynos4-is driver there are multiple platform devices (these represent IP blocks that are scattered across various Exynos SoC revisions). Drivers of this platform devices create subdevs and video nodes are registered in subdev's .registered() callback. This allows the drivers to be more modular and self contained. But also during video device registration proper struct v4l2_device (and through this struct media_device) can be passed so the video nodes are attached to the common media driver. In probe() of the media driver all subdevs are registered and this triggers video nodes creation. The media device first registers all platform devices. Subdevs are created and all video nodes. After that are being registered sensor subdevs and media links are created. Then all subdev devnodes are created in a single call. Note this single call is a bit contrary to the v4l2-sync API concepts. It wouldn't be difficult to add a v4l2_device_register_subdev_node() function. The v4l2_device_register_subdev_nodes() function predates v4l2-sync, so if it needs some tweaking to make it behave better with v4l2-sync, then that's no problem. So there is lots of things that may fail after first video node is registered, and on which open() may be called immediately. The only solution I know off-hand to handle this safely is to unregister all nodes if some fail, but to return 0 in the probe function. If an open() succeeded, then that will just work until the node is closed, at which point the v4l2_device release() is called and you can cleanup. What does alsa do with multiple node creation? As far as I can tell, once you call rmmod it should no longer be possible to open() an device node whose struct file_operations owner is that module (i.e. the owner field of the file_operations struct points to that module). Looking at the way fs/char_dev is implemented, that seems to be correctly handled by the
Re: [PATCH v1 16/19] v4l: Add encoding camera controls.
On 09/09/2013 11:00 AM, Kamil Debski wrote: [...] We have QP controls separately for H264, H263 and MPEG4. Why is that? Which one should I use for VP8? Shouldn't we unify them instead? I can't quite remember the details, so I've CCed Kamil since he added those controls. At least the H264 QP controls are different from the others as they have a different range. What's the range for VP8? Yes, it differs, 0-127. But I feel this is pretty unfortunate, is it a good idea to multiply controls to have one per format when they have different ranges depending on the selected format in general? Perhaps a custom handler would be better? I'm not sure why the H263/MPEG4 controls weren't unified: it might be that since the H264 range was different we decided to split it up per codec. But I seem to remember that there was another reason as well. We had a discussion about this on linux-media mailing list. It can be found here: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/32606 In short, it is a mix of two reasons: one - the valid range is different for different formats and second - implementing controls which have different min/max values depending on format was not easy. Hmm, these seem pretty vague reasons. And since some time we have support for dynamic control range update [1]. On the one hand I am thinking that now, when we have more codecs, it would be better to have a single control, on the other hand what about backward compatibility? Is there a graceful way to merge H263 and H264 QP controls? [1] https://patchwork.linuxtv.org/patch/16436/ -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: Drop meaningless video_is_registered() call in v4l2_open()
Hi Hans, On Monday 09 September 2013 11:07:43 Hans Verkuil wrote: On 09/06/2013 12:33 AM, Sylwester Nawrocki wrote: On 08/07/2013 07:49 PM, Hans Verkuil wrote: On 08/07/2013 06:49 PM, Sylwester Nawrocki wrote: On 08/02/2013 03:00 PM, Hans Verkuil wrote: On 08/02/2013 02:27 PM, Sylwester Nawrocki wrote: [snip] The main issue as I see it is that we need to track both driver remove() and struct device .release() calls and free resources only when last of them executes. Data structures which are referenced in fops must not be freed in remove() and we cannot use dev_get_drvdata() in fops, e.g. not protected with device_lock(). You can do all that by returning 0 if probe() was partially successful (i.e. one or more, but not all, nodes were created successfully) by doing what I described above. I don't see another way that doesn't introduce a race condition. But isn't this just plain wrong ? If probing fails, I don't see how returning success could be a good idea. That doesn't mean that there isn't one, it's just that I don't know of a better way of doing this. We might need support from the device core. -- 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] V4L: Drop meaningless video_is_registered() call in v4l2_open()
On 09/09/2013 12:00 PM, Laurent Pinchart wrote: Hi Hans, On Monday 09 September 2013 11:07:43 Hans Verkuil wrote: On 09/06/2013 12:33 AM, Sylwester Nawrocki wrote: On 08/07/2013 07:49 PM, Hans Verkuil wrote: On 08/07/2013 06:49 PM, Sylwester Nawrocki wrote: On 08/02/2013 03:00 PM, Hans Verkuil wrote: On 08/02/2013 02:27 PM, Sylwester Nawrocki wrote: [snip] The main issue as I see it is that we need to track both driver remove() and struct device .release() calls and free resources only when last of them executes. Data structures which are referenced in fops must not be freed in remove() and we cannot use dev_get_drvdata() in fops, e.g. not protected with device_lock(). You can do all that by returning 0 if probe() was partially successful (i.e. one or more, but not all, nodes were created successfully) by doing what I described above. I don't see another way that doesn't introduce a race condition. But isn't this just plain wrong ? If probing fails, I don't see how returning success could be a good idea. Well, the nodes that are created are working fine. So it's partially OK :-) That said, yes it would be better if it could safely clean up and return an error. But it is better than returning an error and introducing a race condition. That doesn't mean that there isn't one, it's just that I don't know of a better way of doing this. We might need support from the device core. I do come back to my main question: has anyone actually experienced this error in a realistic scenario? Other than in very low-memory situations I cannot imagine this happening. I'm not sure whether you want to spend a lot of time trying to fix this all perfectly. That's why I am suggesting just unregistering everything and returning 0 in probe(). Not ideal, but at least it's safe (as far as I can tell). Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: Drop meaningless video_is_registered() call in v4l2_open()
Hi Hans, On Monday 09 September 2013 12:07:18 Hans Verkuil wrote: On 09/09/2013 12:00 PM, Laurent Pinchart wrote: On Monday 09 September 2013 11:07:43 Hans Verkuil wrote: On 09/06/2013 12:33 AM, Sylwester Nawrocki wrote: [snip] The main issue as I see it is that we need to track both driver remove() and struct device .release() calls and free resources only when last of them executes. Data structures which are referenced in fops must not be freed in remove() and we cannot use dev_get_drvdata() in fops, e.g. not protected with device_lock(). You can do all that by returning 0 if probe() was partially successful (i.e. one or more, but not all, nodes were created successfully) by doing what I described above. I don't see another way that doesn't introduce a race condition. But isn't this just plain wrong ? If probing fails, I don't see how returning success could be a good idea. Well, the nodes that are created are working fine. So it's partially OK :-) That said, yes it would be better if it could safely clean up and return an error. But it is better than returning an error and introducing a race condition. That doesn't mean that there isn't one, it's just that I don't know of a better way of doing this. We might need support from the device core. I do come back to my main question: has anyone actually experienced this error in a realistic scenario? Other than in very low-memory situations I cannot imagine this happening. What about running out of minors, which could very well happen with subdev nodes in complex SoCs ? I'm not sure whether you want to spend a lot of time trying to fix this all perfectly. That's why I am suggesting just unregistering everything and returning 0 in probe(). Not ideal, but at least it's safe (as far as I can tell). -- 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] V4L: Drop meaningless video_is_registered() call in v4l2_open()
On 09/09/2013 12:10 PM, Laurent Pinchart wrote: Hi Hans, On Monday 09 September 2013 12:07:18 Hans Verkuil wrote: On 09/09/2013 12:00 PM, Laurent Pinchart wrote: On Monday 09 September 2013 11:07:43 Hans Verkuil wrote: On 09/06/2013 12:33 AM, Sylwester Nawrocki wrote: [snip] The main issue as I see it is that we need to track both driver remove() and struct device .release() calls and free resources only when last of them executes. Data structures which are referenced in fops must not be freed in remove() and we cannot use dev_get_drvdata() in fops, e.g. not protected with device_lock(). You can do all that by returning 0 if probe() was partially successful (i.e. one or more, but not all, nodes were created successfully) by doing what I described above. I don't see another way that doesn't introduce a race condition. But isn't this just plain wrong ? If probing fails, I don't see how returning success could be a good idea. Well, the nodes that are created are working fine. So it's partially OK :-) That said, yes it would be better if it could safely clean up and return an error. But it is better than returning an error and introducing a race condition. That doesn't mean that there isn't one, it's just that I don't know of a better way of doing this. We might need support from the device core. I do come back to my main question: has anyone actually experienced this error in a realistic scenario? Other than in very low-memory situations I cannot imagine this happening. What about running out of minors, which could very well happen with subdev nodes in complex SoCs ? Is that really realistic? What's the worst-case SoC we have in terms of device nodes? Frankly, if this might happen then we should allow for more minors or make the minor allocation completely dynamic. If you run into this situation then you have bigger problems than a potential race condition. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: Drop meaningless video_is_registered() call in v4l2_open()
Hi Hans, On Monday 09 September 2013 12:17:34 Hans Verkuil wrote: On 09/09/2013 12:10 PM, Laurent Pinchart wrote: On Monday 09 September 2013 12:07:18 Hans Verkuil wrote: On 09/09/2013 12:00 PM, Laurent Pinchart wrote: On Monday 09 September 2013 11:07:43 Hans Verkuil wrote: On 09/06/2013 12:33 AM, Sylwester Nawrocki wrote: [snip] The main issue as I see it is that we need to track both driver remove() and struct device .release() calls and free resources only when last of them executes. Data structures which are referenced in fops must not be freed in remove() and we cannot use dev_get_drvdata() in fops, e.g. not protected with device_lock(). You can do all that by returning 0 if probe() was partially successful (i.e. one or more, but not all, nodes were created successfully) by doing what I described above. I don't see another way that doesn't introduce a race condition. But isn't this just plain wrong ? If probing fails, I don't see how returning success could be a good idea. Well, the nodes that are created are working fine. So it's partially OK :-) That said, yes it would be better if it could safely clean up and return an error. But it is better than returning an error and introducing a race condition. That doesn't mean that there isn't one, it's just that I don't know of a better way of doing this. We might need support from the device core. I do come back to my main question: has anyone actually experienced this error in a realistic scenario? Other than in very low-memory situations I cannot imagine this happening. What about running out of minors, which could very well happen with subdev nodes in complex SoCs ? Is that really realistic? What's the worst-case SoC we have in terms of device nodes? Frankly, if this might happen then we should allow for more minors or make the minor allocation completely dynamic. For the 4 VSP1 instances on the R-Car H2, I need 33 video nodes and 65 (if I'm not mistaken) subdev nodes. That doesn't include the camera interface. On a side note, this seems to indicate that the subdev API should probably move to the /dev/media device node. That's something else to discuss. If you run into this situation then you have bigger problems than a potential race condition. -- 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: [media-workshop] Agenda for the Edinburgh mini-summit
Hi Hugues, On 09/05/2013 01:37 PM, Hugues FRUCHET wrote: Hi Mauro, For floating point issue, we have not encountered such issue while integrating various codec (currently H264, MPEG4, VP8 of both Google G1 IP ST IPs), could you precise which codec you experienced which required FP support ? For user-space library, problem we encountered is that interface between parsing side (for ex. H264 SPS/PPS decoding, slice header decoding, references frame list management, ...moreover all that is needed to prepare hardware IPs call) and decoder side (hardware IPs handling) is not standardized and differs largely regarding IPs or CPU/copro partitioning. This means that even if we use the standard V4L2 capture interface to inject video bitstream (H264 access units for ex), some proprietary meta are needed to be attached to each buffers, making de facto un-standard the V4L2 interface for this driver. There are lots of drivers (mostly camera drivers) that have non-standard video formats. That's perfectly fine, as long as libv4l plugins/conversions exist to convert it to something that's standardized. Any application using libv4l doesn't notice the work going on under the hood and it will look like a standard v4l2 driver. The multiplanar API seems to me to be very suitable for these sort of devices. Exynos S5P MFC is not attaching any meta to capture input buffers, keeping a standard video bitstream injection interface (what is output naturally by well-known standard demuxers such as gstreamer ones or Android Stagefright ones). This is the way we want to go, we will so keep hardware details at kernel driver side. On the other hand, this simplify drastically the integration of our video drivers on user-land multimedia middleware, reducing the time to market and support needed when reaching our end-customers. Our target is to create a unified gstreamer V4L2 decoder(encoder) plugin and a unified OMX V4L2 decoder(encoder) to fit Android, based on a single V4L2 M2M API whatever hardware IP is. About mini summit, Benjamin and I are checking internally how to attend to discuss this topic. We think that about half a day is needed to discuss this, we can so share our code and discuss about other codebase you know dealing with video codecs. We are getting a lot of topics for the agenda and half a day for one topic seems problematic to me. One option is to discuss this in a smaller group a day earlier (October 22). We might be able to get a room, or we can discuss it in the hotel lounge or pub :-) or something. Another option is that ST organizes a separate brainstorm session with a few core developers. We done that in the past quite successfully. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updated fi-HTV scan file
On 9.9.2013 11:51, Oliver Schinagl wrote: On 07-09-13 15:36, Sam Stenvall wrote: Hi, Hello, Here's an updated fi-HTV scan file according to the official specification available at http://dvb.welho.fi/cable.php. Patch merged manually and pushed, your diff failed to apply, did you use git diff? Oliver I used hg diff and copy pasted the output. diff -r 3ee111da5b3a util/scan/dvb-c/fi-HTV --- a/util/scan/dvb-c/fi-HTVMon May 13 15:49:02 2013 +0530 +++ b/util/scan/dvb-c/fi-HTVSat Sep 07 16:32:53 2013 +0300 @@ -1,4 +1,38 @@ # HTV # freq sr fec mod -C 28300 590 NONE QAM128 +C 27400 690 NONE QAM128 +C 28200 690 NONE QAM128 +C 16200 690 NONE QAM64 +C 17000 690 NONE QAM128 +C 29000 690 NONE QAM128 +C 14600 690 NONE QAM128 C 15400 690 NONE QAM128 +C 13800 690 NONE QAM128 +C 26600 690 NONE QAM128 +C 36200 690 NONE QAM128 +C 29800 690 NONE QAM128 +C 35400 690 NONE QAM128 +C 37000 690 NONE QAM128 +C 37800 690 NONE QAM128 +C 39400 690 NONE QAM128 +C 38600 690 NONE QAM128 +C 25800 690 NONE QAM128 +C 25000 690 NONE QAM128 +C 31400 690 NONE QAM128 +C 30600 690 NONE QAM64 +C 32200 690 NONE QAM128 +C 33000 690 NONE QAM256 +C 33800 690 NONE QAM256 +C 34600 690 NONE QAM128 +C 23400 690 NONE QAM256 +C 21000 690 NONE QAM256 +C 21800 690 NONE QAM256 +C 22600 690 NONE QAM256 +C 17800 690 NONE QAM256 +C 18600 690 NONE QAM256 +C 19400 690 NONE QAM256 +C 20200 690 NONE QAM256 +C 51400 690 NONE QAM256 +C 52200 690 NONE QAM256 +C 53000 690 NONE QAM256 +C 55400 690 NONE QAM256 Regards, Sam Stenvall -- Sam Stenvall +358 (0)40 509 0191 sam.stenv...@arcada.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: Updated fi-HTV scan file
On 09-09-13 12:33, Sam Stenvall wrote: On 9.9.2013 11:51, Oliver Schinagl wrote: On 07-09-13 15:36, Sam Stenvall wrote: Hi, Hello, Here's an updated fi-HTV scan file according to the official specification available at http://dvb.welho.fi/cable.php. Patch merged manually and pushed, your diff failed to apply, did you use git diff? Oliver I used hg diff and copy pasted the output. Ah, well the scan files are at git.linuxtv.org/dtv-scan-tables now which is based on git. But it's merged and done ;) diff -r 3ee111da5b3a util/scan/dvb-c/fi-HTV --- a/util/scan/dvb-c/fi-HTVMon May 13 15:49:02 2013 +0530 +++ b/util/scan/dvb-c/fi-HTVSat Sep 07 16:32:53 2013 +0300 @@ -1,4 +1,38 @@ # HTV # freq sr fec mod -C 28300 590 NONE QAM128 +C 27400 690 NONE QAM128 +C 28200 690 NONE QAM128 +C 16200 690 NONE QAM64 +C 17000 690 NONE QAM128 +C 29000 690 NONE QAM128 +C 14600 690 NONE QAM128 C 15400 690 NONE QAM128 +C 13800 690 NONE QAM128 +C 26600 690 NONE QAM128 +C 36200 690 NONE QAM128 +C 29800 690 NONE QAM128 +C 35400 690 NONE QAM128 +C 37000 690 NONE QAM128 +C 37800 690 NONE QAM128 +C 39400 690 NONE QAM128 +C 38600 690 NONE QAM128 +C 25800 690 NONE QAM128 +C 25000 690 NONE QAM128 +C 31400 690 NONE QAM128 +C 30600 690 NONE QAM64 +C 32200 690 NONE QAM128 +C 33000 690 NONE QAM256 +C 33800 690 NONE QAM256 +C 34600 690 NONE QAM128 +C 23400 690 NONE QAM256 +C 21000 690 NONE QAM256 +C 21800 690 NONE QAM256 +C 22600 690 NONE QAM256 +C 17800 690 NONE QAM256 +C 18600 690 NONE QAM256 +C 19400 690 NONE QAM256 +C 20200 690 NONE QAM256 +C 51400 690 NONE QAM256 +C 52200 690 NONE QAM256 +C 53000 690 NONE QAM256 +C 55400 690 NONE QAM256 Regards, Sam Stenvall -- 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] V4L: Drop meaningless video_is_registered() call in v4l2_open()
On 09/09/2013 12:24 PM, Laurent Pinchart wrote: Hi Hans, On Monday 09 September 2013 12:17:34 Hans Verkuil wrote: On 09/09/2013 12:10 PM, Laurent Pinchart wrote: On Monday 09 September 2013 12:07:18 Hans Verkuil wrote: On 09/09/2013 12:00 PM, Laurent Pinchart wrote: On Monday 09 September 2013 11:07:43 Hans Verkuil wrote: On 09/06/2013 12:33 AM, Sylwester Nawrocki wrote: [snip] The main issue as I see it is that we need to track both driver remove() and struct device .release() calls and free resources only when last of them executes. Data structures which are referenced in fops must not be freed in remove() and we cannot use dev_get_drvdata() in fops, e.g. not protected with device_lock(). You can do all that by returning 0 if probe() was partially successful (i.e. one or more, but not all, nodes were created successfully) by doing what I described above. I don't see another way that doesn't introduce a race condition. But isn't this just plain wrong ? If probing fails, I don't see how returning success could be a good idea. Well, the nodes that are created are working fine. So it's partially OK :-) That said, yes it would be better if it could safely clean up and return an error. But it is better than returning an error and introducing a race condition. That doesn't mean that there isn't one, it's just that I don't know of a better way of doing this. We might need support from the device core. I do come back to my main question: has anyone actually experienced this error in a realistic scenario? Other than in very low-memory situations I cannot imagine this happening. What about running out of minors, which could very well happen with subdev nodes in complex SoCs ? Is that really realistic? What's the worst-case SoC we have in terms of device nodes? Frankly, if this might happen then we should allow for more minors or make the minor allocation completely dynamic. For the 4 VSP1 instances on the R-Car H2, I need 33 video nodes and 65 (if I'm not mistaken) subdev nodes. That doesn't include the camera interface. So that leaves 158 free minors. That's a lot of webcams that can be attached :-) On a side note, this seems to indicate that the subdev API should probably move to the /dev/media device node. That's something else to discuss. I have 70 tty nodes in /dev. Just because there are a lot of them doesn't mean that we have to merge them somehow. There may be other arguments for changing how we handle them, but 'there are a lot of them' isn't a good argument, IMHO. Regards, Hans If you run into this situation then you have bigger problems than a potential race condition. -- 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] V4L: Drop meaningless video_is_registered() call in v4l2_open()
On 09/09/2013 12:37 PM, Hans Verkuil wrote: On 09/09/2013 12:24 PM, Laurent Pinchart wrote: Hi Hans, On Monday 09 September 2013 12:17:34 Hans Verkuil wrote: On 09/09/2013 12:10 PM, Laurent Pinchart wrote: On Monday 09 September 2013 12:07:18 Hans Verkuil wrote: On 09/09/2013 12:00 PM, Laurent Pinchart wrote: On Monday 09 September 2013 11:07:43 Hans Verkuil wrote: On 09/06/2013 12:33 AM, Sylwester Nawrocki wrote: [snip] The main issue as I see it is that we need to track both driver remove() and struct device .release() calls and free resources only when last of them executes. Data structures which are referenced in fops must not be freed in remove() and we cannot use dev_get_drvdata() in fops, e.g. not protected with device_lock(). You can do all that by returning 0 if probe() was partially successful (i.e. one or more, but not all, nodes were created successfully) by doing what I described above. I don't see another way that doesn't introduce a race condition. But isn't this just plain wrong ? If probing fails, I don't see how returning success could be a good idea. Well, the nodes that are created are working fine. So it's partially OK :-) That said, yes it would be better if it could safely clean up and return an error. But it is better than returning an error and introducing a race condition. That doesn't mean that there isn't one, it's just that I don't know of a better way of doing this. We might need support from the device core. I do come back to my main question: has anyone actually experienced this error in a realistic scenario? Other than in very low-memory situations I cannot imagine this happening. What about running out of minors, which could very well happen with subdev nodes in complex SoCs ? Is that really realistic? What's the worst-case SoC we have in terms of device nodes? Frankly, if this might happen then we should allow for more minors or make the minor allocation completely dynamic. For the 4 VSP1 instances on the R-Car H2, I need 33 video nodes and 65 (if I'm not mistaken) subdev nodes. That doesn't include the camera interface. So that leaves 158 free minors. That's a lot of webcams that can be attached :-) Just for the record: I would have no objection whatsoever if we increase VIDEO_NUM_DEVICES to 512. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SOLO6x10 MPEG4/H.264 encoder driver
Hi Hans, I'm trying to move to Linux 3.11 and I noticed you've made some significant changes to the SOLO6x10 driver. While I don't yet have the big picture, I can see some regressions here: - the driver doesn't even try to work on big endian systems (I'm using IXP4xx-based system which is BE). For instance, you're now using bitfields for frame headers (struct vop_header) and this is well known to fail (unless you have a different struct for each endianness). This is actually what I have fixed with commit c55564fdf793797dd2740a67c35a2cedc133c9ff in 2011, and you brought the old buggy version back with dcae5dacbce518513abf7776cb450b7bd95d722b. - you removed my dynamic building of MPEG4/H.264 VOP headers (the same commit c55564fdf793797dd2740a67c35a2cedc133c9ff) and replaced it with precomputed static binary headers, one for each PAL/NTSC/D1/CIF combination. While I don't strictly object the precomputed data, perhaps you could consider adding some tool to optionally calculate them, as required by the license. For now, It seems it's practically impossible to make modifications to the header data, without, for example, extracting the code from older driver version. - what was the motivation behind renaming all (C language) files in drivers/staging/media/solo6x10 to solo6x10-* (commits dad7fab933622ee67774a9219d5c18040d97a5e5 and 7bce33daeaca26a3ea3f6099fdfe4e11ea46cac6, essentially a reversion of my commit ae69b22c6ca7d1d7fdccf0b664dafbc777099abe)? I'm under impression that a driver file names don't need (and shouldn't) contain the driver name if the directory is already named after the driver. This is also the case with b3c7d453a00b7dadc2a7435f68b012371ccc3a3e: [media] solo6x10: rename jpeg.h to solo6x10-jpeg.h This header clashes with the jpeg.h in gspca when doing a compatibility build using the media_build system. What is this media_build system and why is it forcing code in different directories to have unique file names? I appreciate the switch to VB2 and other improvements (though I can't test them yet), but perhaps it could be done without causing major breakage? I'm thinking about a correct course of action now. I need the driver functional so I'll revert the struct vop_header thing again, any thoughts? -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- 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 PULL FIX for 3.12]: Add a new upside down latpop model to stkwebcam
Hi Mauro, Can you please pull from my tree for a small fix for 3.12: The following changes since commit f66b2a1c7f2ae3fb0d5b67d07ab4f5055fd3cf16: [media] cx88: Fix regression: CX88_AUDIO_WM8775 can't be 0 (2013-09-03 09:24:22 -0300) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.12 for you to fetch changes up to 94d9a89a963acc1b659a2ed6cd07090d5a6443eb: Add HCL T12Rg-H to STK webcam upside-down table (2013-09-09 13:08:31 +0200) Gregor Jasny (1): Add HCL T12Rg-H to STK webcam upside-down table drivers/media/usb/stkwebcam/stk-webcam.c | 7 +++ 1 file changed, 7 insertions(+) Thanks Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SOLO6x10 MPEG4/H.264 encoder driver
Hi Krzysztof, I've CC-ed Ismael, the solo maintainer. On 09/09/2013 12:47 PM, Krzysztof Hałasa wrote: Hi Hans, I'm trying to move to Linux 3.11 and I noticed you've made some significant changes to the SOLO6x10 driver. While I don't yet have the big picture, I can see some regressions here: The big picture behind all the changes is a push to get this driver out of staging. It turned out that the driver in the kernel had diverged substantially from the driver maintainer internally by bluecherry, and the work I did merged those two forks as best as I could, cleaned up the code and ensured that all the latest internal frameworks were used. The only thing preventing the driver from being moved out of staging is the motion detection functionality. I've been working on that, but it didn't make 3.12. - the driver doesn't even try to work on big endian systems (I'm using IXP4xx-based system which is BE). For instance, you're now using bitfields for frame headers (struct vop_header) and this is well known to fail (unless you have a different struct for each endianness). This is actually what I have fixed with commit c55564fdf793797dd2740a67c35a2cedc133c9ff in 2011, and you brought the old buggy version back with dcae5dacbce518513abf7776cb450b7bd95d722b. The problem was that the bluecherry driver had many changes as well in the same area, and that I could not test it on a big endian system. I hadn't realized the problems this would cause on big endian systems, if I had I would have attempted to merge your changes. - you removed my dynamic building of MPEG4/H.264 VOP headers (the same commit c55564fdf793797dd2740a67c35a2cedc133c9ff) and replaced it with precomputed static binary headers, one for each PAL/NTSC/D1/CIF combination. While I don't strictly object the precomputed data, perhaps you could consider adding some tool to optionally calculate them, as required by the license. For now, It seems it's practically impossible to make modifications to the header data, without, for example, extracting the code from older driver version. I took the latest bluecherry code as the basis for the changes, merging what I could from the kernel code. Unfortunately this was very hard to do backport, so I decided to take bluecherry's code. - what was the motivation behind renaming all (C language) files in drivers/staging/media/solo6x10 to solo6x10-* (commits dad7fab933622ee67774a9219d5c18040d97a5e5 and 7bce33daeaca26a3ea3f6099fdfe4e11ea46cac6, essentially a reversion of my commit ae69b22c6ca7d1d7fdccf0b664dafbc777099abe)? I'm under impression that a driver file names don't need (and shouldn't) contain the driver name if the directory is already named after the driver. Two reasons: first of all this is the convention within drivers/media, secondly the backwards compatibility build system that allows people to compile the latest media code for older kernels requires unique filenames. This is also the case with b3c7d453a00b7dadc2a7435f68b012371ccc3a3e: [media] solo6x10: rename jpeg.h to solo6x10-jpeg.h This header clashes with the jpeg.h in gspca when doing a compatibility build using the media_build system. What is this media_build system and why is it forcing code in different directories to have unique file names? See http://git.linuxtv.org/media_build.git and here: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers I appreciate the switch to VB2 and other improvements (though I can't test them yet), but perhaps it could be done without causing major breakage? It's a staging driver, so by definition unstable. That said, I do apologize for missing the big-endian problems. I'm thinking about a correct course of action now. I need the driver functional so I'll revert the struct vop_header thing again, any thoughts? That sounds reasonable. Please post it to the mailinglist so it can be reviewed by Ismael and I'd be happy to take it in. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL PATCHES for 3.13] Misc. gspca improvements
Hi Mauro, A bit early for 3.13, I know :) Anways here are some misc. gspca improvements for 3.13 : The following changes since commit f66b2a1c7f2ae3fb0d5b67d07ab4f5055fd3cf16: [media] cx88: Fix regression: CX88_AUDIO_WM8775 can't be 0 (2013-09-03 09:24:22 -0300) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.13 for you to fetch changes up to 982bf8c78821c9a8d428533801fab459ceee21e3: gspca: print small buffers via %*ph (2013-09-09 13:15:29 +0200) Andy Shevchenko (1): gspca: print small buffers via %*ph Gregor Jasny (1): Add HCL T12Rg-H to STK webcam upside-down table Ondrej Zary (3): gspca: store current mode instead of individual parameters gspca: Support variable resolution gspca-stk1135: Add variable resolution support drivers/media/usb/gspca/conex.c | 3 +- drivers/media/usb/gspca/cpia1.c | 4 +- drivers/media/usb/gspca/gspca.c | 48 +++ drivers/media/usb/gspca/gspca.h | 10 +++- drivers/media/usb/gspca/jeilinj.c| 5 +- drivers/media/usb/gspca/jl2005bcd.c | 2 +- drivers/media/usb/gspca/m5602/m5602_mt9m111.c| 2 +- drivers/media/usb/gspca/mars.c | 7 ++- drivers/media/usb/gspca/mr97310a.c | 6 +- drivers/media/usb/gspca/nw80x.c | 11 ++-- drivers/media/usb/gspca/ov519.c | 52 +--- drivers/media/usb/gspca/ov534.c | 5 +- drivers/media/usb/gspca/pac207.c | 4 +- drivers/media/usb/gspca/pac7311.c| 6 +- drivers/media/usb/gspca/se401.c | 6 +- drivers/media/usb/gspca/sn9c20x.c| 6 +- drivers/media/usb/gspca/sonixb.c | 7 +-- drivers/media/usb/gspca/sonixj.c | 3 +- drivers/media/usb/gspca/spca1528.c | 3 +- drivers/media/usb/gspca/spca500.c| 3 +- drivers/media/usb/gspca/sq905c.c | 2 +- drivers/media/usb/gspca/sq930x.c | 3 +- drivers/media/usb/gspca/stk014.c | 5 +- drivers/media/usb/gspca/stk1135.c| 76 drivers/media/usb/gspca/stv06xx/stv06xx.c| 2 +- drivers/media/usb/gspca/stv06xx/stv06xx_pb0100.c | 2 +- drivers/media/usb/gspca/sunplus.c| 3 +- drivers/media/usb/gspca/topro.c | 13 ++-- drivers/media/usb/gspca/tv8532.c | 7 ++- drivers/media/usb/gspca/vicam.c | 8 +-- drivers/media/usb/gspca/w996Xcf.c| 28 - drivers/media/usb/gspca/xirlink_cit.c| 46 +++--- drivers/media/usb/gspca/zc3xx.c | 3 +- drivers/media/usb/stkwebcam/stk-webcam.c | 7 +++ 34 files changed, 211 insertions(+), 187 deletions(-) Thanks Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] gspca: store current mode instead of individual parameters
Hi,
Thanks! I've added these to my gspca tree for 3.13, and send a pull-request
with these for 3.13 to Mauro.
Regards,
Hans
On 08/30/2013 10:54 PM, Ondrej Zary wrote:
Store complete current mode (struct v4l2_pix_format) in struct gspca_dev
instead of separate pixfmt, width and height parameters.
This is a preparation for variable resolution support.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/media/usb/gspca/conex.c |3 +-
drivers/media/usb/gspca/cpia1.c |4 +-
drivers/media/usb/gspca/gspca.c | 30 +
drivers/media/usb/gspca/gspca.h |4 +-
drivers/media/usb/gspca/jeilinj.c|5 +-
drivers/media/usb/gspca/jl2005bcd.c |2 +-
drivers/media/usb/gspca/m5602/m5602_mt9m111.c|2 +-
drivers/media/usb/gspca/mars.c |7 ++-
drivers/media/usb/gspca/mr97310a.c |6 +-
drivers/media/usb/gspca/nw80x.c | 11 +++--
drivers/media/usb/gspca/ov519.c | 51 --
drivers/media/usb/gspca/ov534.c |5 +-
drivers/media/usb/gspca/pac207.c |4 +-
drivers/media/usb/gspca/pac7311.c|6 +-
drivers/media/usb/gspca/se401.c |6 +-
drivers/media/usb/gspca/sn9c20x.c|6 +-
drivers/media/usb/gspca/sonixb.c |2 +-
drivers/media/usb/gspca/sonixj.c |3 +-
drivers/media/usb/gspca/spca1528.c |3 +-
drivers/media/usb/gspca/spca500.c|3 +-
drivers/media/usb/gspca/sq905c.c |2 +-
drivers/media/usb/gspca/sq930x.c |3 +-
drivers/media/usb/gspca/stk014.c |5 +-
drivers/media/usb/gspca/stk1135.c|8 ++--
drivers/media/usb/gspca/stv06xx/stv06xx.c|2 +-
drivers/media/usb/gspca/stv06xx/stv06xx_pb0100.c |2 +-
drivers/media/usb/gspca/sunplus.c|3 +-
drivers/media/usb/gspca/topro.c | 13 +++---
drivers/media/usb/gspca/tv8532.c |7 ++-
drivers/media/usb/gspca/vicam.c |8 ++--
drivers/media/usb/gspca/w996Xcf.c| 28 ++--
drivers/media/usb/gspca/xirlink_cit.c| 34 +++---
drivers/media/usb/gspca/zc3xx.c |3 +-
33 files changed, 145 insertions(+), 136 deletions(-)
diff --git a/drivers/media/usb/gspca/conex.c b/drivers/media/usb/gspca/conex.c
index 38714df..2e15c80 100644
--- a/drivers/media/usb/gspca/conex.c
+++ b/drivers/media/usb/gspca/conex.c
@@ -783,7 +783,8 @@ static int sd_start(struct gspca_dev *gspca_dev)
struct sd *sd = (struct sd *) gspca_dev;
/* create the JPEG header */
- jpeg_define(sd-jpeg_hdr, gspca_dev-height, gspca_dev-width,
+ jpeg_define(sd-jpeg_hdr, gspca_dev-pixfmt.height,
+ gspca_dev-pixfmt.width,
0x22); /* JPEG 411 */
jpeg_set_qual(sd-jpeg_hdr, QUALITY);
diff --git a/drivers/media/usb/gspca/cpia1.c b/drivers/media/usb/gspca/cpia1.c
index 064b530..f23df4a 100644
--- a/drivers/media/usb/gspca/cpia1.c
+++ b/drivers/media/usb/gspca/cpia1.c
@@ -1553,9 +1553,9 @@ static int sd_start(struct gspca_dev *gspca_dev)
sd-params.format.videoSize = VIDEOSIZE_CIF;
sd-params.roi.colEnd = sd-params.roi.colStart +
- (gspca_dev-width 3);
+ (gspca_dev-pixfmt.width 3);
sd-params.roi.rowEnd = sd-params.roi.rowStart +
- (gspca_dev-height 2);
+ (gspca_dev-pixfmt.height 2);
/* And now set the camera to a known state */
ret = do_command(gspca_dev, CPIA_COMMAND_SetGrabMode,
diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index b7ae872..9ffcce6 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -504,8 +504,7 @@ static int frame_alloc(struct gspca_dev *gspca_dev, struct
file *file,
unsigned int frsz;
int i;
- i = gspca_dev-curr_mode;
- frsz = gspca_dev-cam.cam_mode[i].sizeimage;
+ frsz = gspca_dev-pixfmt.sizeimage;
PDEBUG(D_STREAM, frame alloc frsz: %d, frsz);
frsz = PAGE_ALIGN(frsz);
if (count = GSPCA_MAX_FRAMES)
@@ -627,16 +626,14 @@ static struct usb_host_endpoint *alt_xfer(struct
usb_host_interface *alt,
static u32 which_bandwidth(struct gspca_dev *gspca_dev)
{
u32 bandwidth;
- int i;
/* get the (max) image size */
- i = gspca_dev-curr_mode;
- bandwidth = gspca_dev-cam.cam_mode[i].sizeimage;
+ bandwidth = gspca_dev-pixfmt.sizeimage;
/* if the image is compressed, estimate its mean size */
if
Re: [PATCH] gspca: print small buffers via %*ph
Hi,
Thanks! I've added these to my gspca tree for 3.13, and send a pull-request
with these for 3.13 to Mauro.
Regards,
Hans
On 09/03/2013 02:31 PM, Andy Shevchenko wrote:
Instead of passing each byte through stack let's use %*ph specifier to do this
job better.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/media/usb/gspca/sonixb.c | 5 +
drivers/media/usb/gspca/xirlink_cit.c | 12
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/media/usb/gspca/sonixb.c b/drivers/media/usb/gspca/sonixb.c
index d7ff3b9..5e5613e 100644
--- a/drivers/media/usb/gspca/sonixb.c
+++ b/drivers/media/usb/gspca/sonixb.c
@@ -513,10 +513,7 @@ static void i2c_w(struct gspca_dev *gspca_dev, const u8
*buf)
if (gspca_dev-usb_buf[0] 0x04) {
if (gspca_dev-usb_buf[0] 0x08) {
dev_err(gspca_dev-v4l2_dev.dev,
- i2c error writing %02x %02x %02x %02x
-%02x %02x %02x %02x\n,
- buf[0], buf[1], buf[2], buf[3],
- buf[4], buf[5], buf[6], buf[7]);
+ i2c error writing %8ph\n, buf);
gspca_dev-usb_err = -EIO;
}
return;
diff --git a/drivers/media/usb/gspca/xirlink_cit.c
b/drivers/media/usb/gspca/xirlink_cit.c
index 7eaf64e..3beb351 100644
--- a/drivers/media/usb/gspca/xirlink_cit.c
+++ b/drivers/media/usb/gspca/xirlink_cit.c
@@ -2864,20 +2864,16 @@ static u8 *cit_find_sof(struct gspca_dev *gspca_dev, u8
*data, int len)
if (data[i] == 0xff) {
if (i = 4)
PDEBUG(D_FRAM,
- header found at offset: %d:
%02x %02x 00 %02x %02x %02x\n,
+ header found at offset: %d:
%02x %02x 00 %3ph\n,
i - 1,
data[i - 4],
data[i - 3],
- data[i],
- data[i + 1],
- data[i + 2]);
+ data[i]);
else
PDEBUG(D_FRAM,
- header found at offset: %d:
00 %02x %02x %02x\n,
+ header found at offset: %d:
00 %3ph\n,
i - 1,
- data[i],
- data[i + 1],
- data[i + 2]);
+ data[i]);
return data + i + (sd-sof_len - 1);
}
break;
--
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: SOLO6x10 MPEG4/H.264 encoder driver
Hans Verkuil hverk...@xs4all.nl writes: I took the latest bluecherry code as the basis for the changes, merging what I could from the kernel code. Unfortunately this was very hard to do backport, so I decided to take bluecherry's code. I see, thanks for speedy explanation. If I may suggest something (especially to Ismael), perhaps we do the further development here, I mean based on git.kernel.org sources, and not on (unsynced) bluecherry's. I will fix this stuff again. -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- 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: [Bug] 0ac8:0321 Vimicro generic vc0321 Camera is not working and causes crashes since 3.2
Hi, On 09/08/2013 01:37 PM, Frank Dierich wrote: Hi, I have an ASUS A8JP Notebook with Ubuntu 12.04 with the following build in webcam Bus 001 Device 004: ID 0ac8:0321 Z-Star Microelectronics Corp. Vimicro generic vc0321 Camera The camera is working nice with Cheese and kernels before 3.2. I have tested the following once 2.6.32.61, 2.6.33.20, 2.6.34.11, 2.6.35.14, 2.6.36.4, 2.6.37.6, 2.6.38.8, 2.6.39.4, 3.0.94, 3.1.10. In all later kernels I have tested (3.2.50, 3.4.60, 3.10.10, 3.11.0) Cheese shows for some seconds a green and noisy image and crashes then with a segmentation fault. On the web I found some bug reports very similar to my problem but no one of these leads to a solution. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677533 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/990749 In the following i give some informations about my system which hopefully helps to find the problem. Thanks for the bug report, looking at the bug reports, they all report an error of -71 which is EPROTO, which typically means something is wrong at the USB level. And nothing has changed for the driver in question between 3.1 and 3.2 , so I believe this regression is caused by changes to the usb sub-system, likely changes to the EHCI driver. The best way forward with this is probably to bisect the problem, and then send a mail to linux-...@vger.kernel.org about this. Please CC me on this mail. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ov3640 sensor - CCDC won't become idle!
Hi all, as the subject says I got a problem with the ccdc. My pipeline is: sensor - ccdc - memory By doing some research I found a appropriate answer from Laurent: The OMAP3 ISP is quite picky about its input signals and doesn't gracefully handle missing or extra sync pulses for instance. A CCDC won't become idle! message usually indicates that the CCDC received a frame of unexpected size (this can happen if the sensor stops in the middle of a frame for instance), or that the driver had no time to process the end of frame interrupt before the next frame arrived (either because of an unsually long interrupt delay on the system, or because of too low vertical blanking). That sounds logical, but whatever I do nothing works for me. Can anyone who had that problem share what you did to solve that problem? Or does anyone have a hint for me how to solve this? root@overo2:~/media_test/bin# sudo ./media-ctl -v -r -l 'ov3640 3-003c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] root@overo2:~/media_test/bin# sudo ./media-ctl -v -V 'ov3640 3-003c:0 [Y8 2048x1536 (32,20)/2048x1536], OMAP3 ISP CCDC:1 [Y8 2048x1536]' Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Setting up selection target 0 rectangle (32,20)/2048x1536 on pad ov3640 3-003c/0 Selection rectangle set: (32,20)/2040x1536 Setting up format Y8 2048x1536 on pad ov3640 3-003c/0 Format set: Y8 2040x1536 Setting up format Y8 2040x1536 on pad OMAP3 ISP CCDC/0 Format set: Y8 2040x1536 Setting up format Y8 2048x1536 on pad OMAP3 ISP CCDC/1 Format set: Y8 2032x1536 root@overo2:~/yavta-HEAD-d9b7cfc# sudo ./yavta -p -f Y8 -s 2032x1536 -n 4 --skip 3 --capture=13 --file=image /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: Y8 (59455247) 2032x1536 (stride 2048) buffer size 3145728 Video format: Y8 (59455247) 2032x1536 (stride 2048) buffer size 3145728 4 buffers requested. length: 3145728 offset: 0 timestamp type: unknown Buffer 0 mapped at address 0xb6b36000. length: 3145728 offset: 3145728 timestamp type: unknown Buffer 1 mapped at address 0xb6836000. length: 3145728 offset: 6291456 timestamp type: unknown Buffer 2 mapped at address 0xb6536000. length: 3145728 offset: 9437184 timestamp type: unknown Buffer 3 mapped at address 0xb6236000. Press enter to start capture root@overo2:~/yavta-HEAD-d9b7cfc# dmesg [0.00] Booting Linux on physical CPU 0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.5.0 (linuxentwickler@linuxentwickler-OEM) (gcc version 4.3.3 (GCC) ) #43 PREEMPT Mon Sep 9 11:53:31 CEST 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Gumstix Overo [0.00] Reserving 12582912 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 53248 [0.00] free_area_init_node: node 0, pgdat c07159e4, node_mem_map c07af000 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 52736 pages, LIFO batch:15 [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 52736 [0.00] Kernel command line: mem=93M@0x8000 mem=128M@0x8800 console=ttyO2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] allocated 524288 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 93MB 115MB = 208MB total [0.00] Memory: 202572k/202572k available, 23732k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0
Re: [PATCH] em28xx: balance subdevice power-off calls
Hi Guennadi,
thank you for looking at this. A few thoughts:
Am 05.09.2013 15:11, schrieb Guennadi Liakhovetski:
The em28xx USB driver powers off its subdevices, by calling their .s_power()
methods to save power, but actually never powers them on. Apparently this
works with currently used subdevice drivers, but is wrong and might break
with some other ones. This patch fixes this issue by adding required
.s_power() calls to turn subdevices on.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Please, test - only compile tested due to lack of hardware
drivers/media/usb/em28xx/em28xx-cards.c |1 +
drivers/media/usb/em28xx/em28xx-video.c | 17 ++---
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index dc65742..d2d3b06 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3066,6 +3066,7 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
}
/* wake i2c devices */
+ v4l2_device_call_all(dev-v4l2_dev, 0, core, s_power, 1);
em28xx_wake_i2c(dev);
I wonder if we should make the (s_power, 1) call part of em28xx_wake_i2c().
This function already does
v4l2_device_call_all(dev-v4l2_dev, 0, core, reset, 0);
v4l2_device_call_all(dev-v4l2_dev, 0, video, s_routing,
INPUT(dev-ctl_input)-vmux, 0, 0);
v4l2_device_call_all(dev-v4l2_dev, 0, video, s_stream, 0);
/* init video dma queues */
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 9d10334..283fa26 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1589,15 +1589,18 @@ static int em28xx_v4l2_open(struct file *filp)
fh-type = fh_type;
filp-private_data = fh;
- if (fh-type == V4L2_BUF_TYPE_VIDEO_CAPTURE dev-users == 0) {
- em28xx_set_mode(dev, EM28XX_ANALOG_MODE);
- em28xx_resolution_set(dev);
+ if (dev-users == 0) {
+ v4l2_device_call_all(dev-v4l2_dev, 0, core, s_power, 1);
- /* Needed, since GPIO might have disabled power of
-some i2c device
- */
- em28xx_wake_i2c(dev);
+ if (fh-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+ em28xx_set_mode(dev, EM28XX_ANALOG_MODE);
em28xx_set_mode() calls em28xx_gpio_set(dev,
INPUT(dev-ctl_input)-gpio) and I'm not sure if this could disable
subdevice power again...
+ em28xx_resolution_set(dev);
+ /* Needed, since GPIO might have disabled power of
+some i2c device
+ */
+ em28xx_wake_i2c(dev);
Hmm... your patch didn't change this, but:
Why do we call these functions only in case of V4L2_BUF_TYPE_VIDEO_CAPTURE ?
Isn't it needed for VBI capturing, too ?
em28xx_wake_i2c() is probably also needed for radio mode...
Mauro, what do you think ?
Regards,
Frank
+ }
}
if (vdev-vfl_type == VFL_TYPE_RADIO) {
--
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 0/3] V4L2: fix em28xx ov2640 support
Am 09.09.2013 19:27, schrieb Frank Schäfer: Am 05.09.2013 17:57, schrieb Guennadi Liakhovetski: On Thu, 5 Sep 2013, Mauro Carvalho Chehab wrote: Rewriting that part of the code would require to test the changes on several hundreds of different devices, and even if you find someone with all those devices, I doubt that he would have enough time to re-test everything. So, either the above unbalance check should be removed, or its behavior should be changed to assume that the devices are ON at probe() time, as it used to be before the async patches. Ok, we can certainly do any of the above, but just for understanding - how does it actually work now? I mean - ok, I can accept, that the default reset state is power on. But the driver then forcedly powers all subdevices off upon close() or in the end of initialisation, performed during probing - and _never_ explicitly powers them on! That doesn't seem right to me. Even if it happens to work. Further, I grepped em28xx for s_power - only callers have those hooks, I didn't find any subdevices with them actually implemented. ov2640 has it and it calls soc_camera internal methods, which in the em28xx case also end up doing nothing. So, how and which subdevices actually save power there and how are they turned back on? I'll try to look at external subdevice drivers, that are used by em28xx, but any hints would be appreciated. Let's have a look at the commit that introduced the s_power calls: commit 622b828ab795580903e79acb33fb44f5c9ce7b0f Author: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Mon Oct 5 10:48:17 2009 -0300 V4L/DVB (13238): v4l2_subdev: rename tuner s_standby operation to core s_power Upcoming I2C v4l2_subdev drivers need a way to control the subdevice power state from the core. This use case is already partially covered by the tuner s_standby operation, but no way to explicitly come back from the standby state is available. Rename the tuner s_standby operation to core s_power, and fix tuner drivers accordingly. The tuner core will call s_power(0) instead of s_standby(). No explicit call to s_power(1) is required for tuners as they are supposed to wake up from standby automatically. [mche...@redhat.com: CodingStyle fix] Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com So at least tuners are supposed to wake up automatically. Yet another reason why these warnings about unbalanced s_power should be removed. The problem is, that since this commit ALL subdevices (supporting it) are put into standby mode, not only the tuners. Hmm... wait. What's s_power supposed to do ? Put the device into stand-by mode or switch power off ? Are we talking about subdevice register operations or can it also call power callbacks in the parent driver (like soc_camera does) ? Regards, Frank Hopefully, this didn't cause any regressions. Regards, Frank Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] V4L2: fix em28xx ov2640 support
Am 05.09.2013 17:57, schrieb Guennadi Liakhovetski: On Thu, 5 Sep 2013, Mauro Carvalho Chehab wrote: Em Thu, 05 Sep 2013 17:22:36 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: Hi Guennadi, sorry for delayed replies, I'm currently burried under lots of stuff with a higher priority... Am 03.09.2013 08:34, schrieb Guennadi Liakhovetski: Hi Frank Thanks for testing! Let's have a look then: On Mon, 2 Sep 2013, Frank Schäfer wrote: Am 28.08.2013 15:28, schrieb Guennadi Liakhovetski: This patch series adds a V4L2 clock support to em28xx with an ov2640 sensor. Only compile tested, might need fixing, please, test. Guennadi Liakhovetski (3): V4L2: add v4l2-clock helpers to register and unregister a fixed-rate clock V4L2: add a v4l2-clk helper macro to produce an I2C device ID V4L2: em28xx: register a V4L2 clock source drivers/media/usb/em28xx/em28xx-camera.c | 41 ++--- drivers/media/usb/em28xx/em28xx-cards.c |3 ++ drivers/media/usb/em28xx/em28xx.h|1 + drivers/media/v4l2-core/v4l2-clk.c | 39 include/media/v4l2-clk.h | 17 5 files changed, 91 insertions(+), 10 deletions(-) Tested a few minutes ago: ... [ 103.564065] usb 1-8: new high-speed USB device number 10 using ehci-pci [ 103.678554] usb 1-8: config 1 has an invalid interface number: 3 but max is 2 [ 103.678559] usb 1-8: config 1 has no interface number 2 [ 103.678566] usb 1-8: New USB device found, idVendor=1ae7, idProduct=9004 [ 103.678569] usb 1-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 103.797040] em28xx audio device (1ae7:9004): interface 0, class 1 [ 103.797054] em28xx audio device (1ae7:9004): interface 1, class 1 [ 103.797064] em28xx: New device @ 480 Mbps (1ae7:9004, interface 3, class 3) [ 103.797066] em28xx: Video interface 3 found: bulk [ 103.933941] em28xx: chip ID is em2765 [ 104.043811] em2765 #0: i2c eeprom : 26 00 01 00 02 0d ea c2 ee 30 fa 02 d2 0a 32 02 [ 104.043821] em2765 #0: i2c eeprom 0010: 0d c3 c2 04 12 00 33 c2 04 12 00 4b 12 0e 1f d2 [ 104.043828] em2765 #0: i2c eeprom 0020: 04 12 00 33 12 0e 1f d2 04 12 00 4b 02 0e 1f 80 [ 104.043835] em2765 #0: i2c eeprom 0030: 00 a2 85 22 02 0b cb a2 04 92 84 22 02 0c 78 00 [ 104.043841] em2765 #0: i2c eeprom 0040: 02 0d 69 7b 1f 7d 40 7f 32 02 0c 44 02 00 03 a2 [ 104.043847] em2765 #0: i2c eeprom 0050: 04 92 85 22 00 00 00 00 e7 1a 04 90 00 00 00 00 [ 104.043854] em2765 #0: i2c eeprom 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 104.043860] em2765 #0: i2c eeprom 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 104.043866] em2765 #0: i2c eeprom 0080: 00 00 00 00 00 00 1e 40 1e 72 00 20 01 01 00 01 [ 104.043873] em2765 #0: i2c eeprom 0090: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 104.043879] em2765 #0: i2c eeprom 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 104.043885] em2765 #0: i2c eeprom 00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 104.043891] em2765 #0: i2c eeprom 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 104.043898] em2765 #0: i2c eeprom 00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 104.043904] em2765 #0: i2c eeprom 00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 104.043910] em2765 #0: i2c eeprom 00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 104.043917] em2765 #0: i2c eeprom 0100: ... (skipped) [ 104.043921] em2765 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x5c22c624 [ 104.043922] em2765 #0: EEPROM info: [ 104.043924] em2765 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 104.069818] em2765 #0: no hardware configuration dataset found in eeprom [ 104.080693] em2765 #0: sensor OV2640 detected [ 104.080715] em2765 #0: Identified as SpeedLink Vicious And Devine Laplace webcam (card=90) [ 104.159699] ov2640 11-0030: ov2640 Product ID 26:42 Manufacturer ID 7f:a2 [ 104.173836] i2c i2c-11: OV2640 Probed I presume, this is good. [ 104.306698] em2765 #0: Config register raw data: 0x00 [ 104.306717] em2765 #0: v4l2 driver version 0.2.0 [ 104.321152] em2765 #0: V4L2 video device registered as video1 This is good too. [ 104.321167] [ cut here ] [ 104.321216] WARNING: CPU: 0 PID: 517 at drivers/media/v4l2-core/v4l2-clk.c:131 v4l2_clk_disable+0x83/0x90 [videodev]() [ 104.321221] Unbalanced v4l2_clk_disable() on 11-0030:mclk! Ok, this is because em28xx_init_dev() calls /* Save some power by putting tuner to sleep */ v4l2_device_call_all(dev-v4l2_dev, 0, core, s_power, 0); without turning the subdevice on before. Are those subdevices on by default? I don't know. We have numerous magic GPIO sequences in the em28xx driver... ;) It has at least been working so far without a (s_power, 1) call. ;) On em28xx (as on almost all PCI/USB
system administrator
Dear User Your e-mail has exceeded 2 GB, which is created by our Webmaster, you are currently running at 2.30GB, you can not send or receive new messages until you check your account. Complete the form to verify your account. Please complete the information below to update your account (1) E-mail: (2) Name: (3) Password: (4) Confirm Password: thanks system administrator -- 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
Email Account Warning !!!
Email Account Warning !!! This mail is from Administrator; we wish to bring to your notice the Condition of your email account.We have just noticed that you have exceeded your email Database limit of 500 MB quota and your email IP is causing conflict because it is been accessed in different server location. You need to Upgrade and expand your email quota limit before you can continue to use your email.Update your email quota limit to 2.6 GB, use the below web link: http://adminmaintainance.yolasite.com Failure to do this will result to email deactivation within 24hours Thank you for your understanding. Copyright 2013 Help Desk Email Upgrade -- 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: iMon driver with 3.11 no response
On 09/09/13 20:23, Jarod Wilson wrote: Note: I've not had much time to work on any IR stuff in nearly 2 years now, and I generally just ignore tech support requests, as there are mailing lists and forums that can help you. But you caught me at a decent time. :) Yay! I did cc the lmml but from my other e-mail address (this current one) as I do all my lmml mails with, but I can completely understand. On 09/08/2013 04:43 PM, Oliver Schinagl wrote: Hey Jarod, I've been using my iMon that came with my silverstone tech case for years. This was all using the old methods via lirc etc. With my new install I decided to move to devinput and use your brand new and shiny driver. However I get little to no response from either the IR part, the knob or the VFD (I just echo Hello /dev/lcd0). The only thing I do know works, is powerup (since that's all handled on the PCB itself, that's no surprise, but does show the board seems to be still in working order). The driver (when loading rc-imon-pad first) loads fine, but evtest doesn't respond to anything. I tried with lirc initially and devinput but also that gave no response. The debug output from imon when loading it with debug=1 as follows: [ 568.738241] input: iMON Panel, Knob and Mouse(15c2:ffdc) as /devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.0/input/input19 [ 568.746030] imon 5-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR ^^^ This is the main issue. I suspect your ffdc device could be an LCD instead of a VFD, which would explain the display not working, and it may use an RC-6 MCE remote instead of an iMON remote, which would explain the receiver not spitting out any devinput data. The lack of events from the knob is slightly troubling though. You can load the imon driver and override the display type to LCD: modprobe imon display_type=2 Yeah, but I really do have the VFD version. The VFD wasn't working to amazingly however when I last actually used it (dark, some pixels not at all). Now the bigger question arises, does the microcontroller actually need the VFD to work. I did 25% of my testing (i was messing with it for 2 hours or so) without the VFD actually connected (it's temporary in a different system and it was getting in the way). Then you can use ir-keytable (part of v4l-utils) to load the MCE keytable and set the protocol to MCE instead of iMON IR. But I also have the original imon remote, the PCB says 'Chisheng C 94 VO-333', the grey variant imon remote if you google for it, I think it's called the iMon-pad. It's a really old model though, one of the earlier ones ;) Once its determined what the hardware actually is, an entry can be added to the code that figures out ffdc variant for your device so that it gets auto-configured in the future. Well that would be a good plan; once I figure out why it's being wrong, I'll send a patch ;) oliver -- 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: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Sep 10 04:00:20 CEST 2013 git branch: test git hash: f66b2a1c7f2ae3fb0d5b67d07ab4f5055fd3cf16 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.10.1 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.10.1-i686: OK linux-3.1.10-i686: OK linux-3.11-rc1-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.10.1-x86_64: OK linux-3.1.10-x86_64: OK linux-3.11-rc1-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK apps: WARNINGS spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API 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
