Re: Media Controller (v4l2 core) MT9V032 Device Driver
(Re-sent as mailing list rejected the original HTML email.) Hi Laurent, On Friday 02 December 2011 05:14:36 James wrote: On Thu, Dec 1, 2011 at 7:10 AM, Laurent Pinchart wrote: On Tuesday 29 November 2011 03:07:28 James wrote: On Mon, Nov 28, 2011 at 7:15 PM, Laurent Pinchart wrote: Regarding why mplayer fails, I'm not too sure. Your pipeline is configured for YUYV, have you tried replacing outfmt=uyvy with outfmt=yuyv on the mplayer command line ? AFAIK mplayer only has outfmt=uyvy and even with the pipeline configured to UYVY, the result is the same; 0 frame processed. Any suggestion is most welcome to me. (^^) I wrote a patch that fixes the 2 warnings you get. It might help with mplayer, could you please try it ? http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-next How can I merge the patches in your branch omap3isp-omap3isp-next to Steve's tree locally? 1) I've cloned Steve's repo locally. 2) use git remote add pinchart git://linuxtv.org/pinchartl/media.git to the tree. 3) checked out the omap3isp-omap3isp-next branch 4) make a new branch that tracks Steve's omap-3.0-pm. git checkout -b myomap-3.0-pm -t origin/omap-3.0-pm 5) Merge your omap3isp-omap3isp-next branch. git pull . omap3isp-omap3isp-next after this command, I saw lots of files being removed and several merge conflicts. I tried git mergetool to call up kdiff3 to manually resolve but some are way out of ability/level of understanding since I don't know which holds the latest patches integrated into the respective files. The confusing parts is when your branch deleted lots of files. even drivers/net/smsc911x.c which is the driver for the ethernet chip!?! (^^) very confusing.. hahahaha That's because the two branches include lots of different changes. My branch is based on Mauro's official branch for patches targeted at the next kernel version, which is in turn based on mainline (between v3.1 and v3.2-rc1) and includes many patches for drivers/media/*. Steve's branch is also based on mainline, but on v3.0 instead of v3.1, and includes other patches. Thanks for clarifying the starting point of your tree. Which branch at Mauro's tree is your omap3isp-omap3isp-next sitting on? If you merge my branch onto Steve's tree, you will get the whole v3.1, which likely conflicts. Doing it the other way around isn't much better. The easiest way to use the OMAP3 ISP patches on top of Steve's tree is likely to hand-pick them. You can get a list of patches with git log, and use git cherry-pick to pick them manually. With this layout, my understanding is that the 'proper' path for Steve's branch to get updated with all media patches is only when the mainline merged Mauro's branch and Steve pull them into his or rebase against it. Right? I saw Steve's repo staging a new omap-v3.2. http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=shortlog;h=refs/heads/omap-3.2 Wonder till what stage has Mauro's branch been merged into mainline. Is there a way to determine a common baseline/point between both trees so that I can hand-pick them into Steve's v3.2? My understanding of git workflow is still at 'infant' stage. (^^) and the difficulty is learning how to 'pull, merge resolves conflicts' from different trees/branches. (^^) Since I'm using Overo, I relies mainly on Steve's repo but I do know that TI has a linux-omap tree at git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git which is fairly updated tracks the mainline closely. Pardon my silly questions. Regards, James. -- 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
Omap3 ISP + Gstreamer v4l2src
Hi Laurent, Firstly, please accept my apologies, for what is very probably a naive question. I'm new to V4L2 and am just getting to grips with how things work. I'm using a tvp5151 in bt656 mode with the Omap3 ISP, as described in this thread (Your YUV support tree + some patches for bt656, based on 2.6.39): http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/39539 I am able to capture some frames using yavta, using the media-ctl configuration as follows: media-ctl -v -r -l 'tvp5150 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005d:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x625]' This yields this: Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Media controller API version 0.0.0 Media device information driver omap3isp model TI OMAP3 ISP serial bus info hw revision 0x0 driver version 0.0.0 Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Sink [SGRBG10 4096x4096] - OMAP3 ISP CCP2 input:0 [] pad1: Source [SGRBG10 4096x4096] - OMAP3 ISP CCDC:0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Source - OMAP3 ISP CCP2:0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Sink [SGRBG10 4096x4096] pad1: Source [SGRBG10 4096x4096] - OMAP3 ISP CSI2a output:0 [] - OMAP3 ISP CCDC:0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Sink - OMAP3 ISP CSI2a:1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Sink [UYVY2X8 720x625] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 3-005d:0 [ENABLED] pad1: Source [UYVY2X8 720x625] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] pad2: Source [UYVY2X8 720x624] - OMAP3 ISP preview:0 [] - OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE] - OMAP3 ISP AF:0 [ENABLED,IMMUTABLE] - OMAP3 ISP histogram:0 [ENABLED,IMMUTABLE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Sink - OMAP3 ISP CCDC:1 [ENABLED] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Sink [SGRBG10 4096x4096 (8,4)/4082x4088] - OMAP3 ISP CCDC:2 [] - OMAP3 ISP preview input:0 [] pad1: Source [YUYV 4082x4088] - OMAP3 ISP preview output:0 [] - OMAP3 ISP resizer:0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Source - OMAP3 ISP preview:0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Sink - OMAP3 ISP preview:1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Sink [YUYV 4095x4095 (0,6)/4094x4082] - OMAP3 ISP CCDC:1 [] - OMAP3 ISP preview:1 [] - OMAP3 ISP resizer input:0 [] pad1: Source [YUYV 3312x4095] - OMAP3 ISP resizer output:0 [] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Source - OMAP3 ISP resizer:0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Sink - OMAP3 ISP resizer:1 [] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev7 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 16: tvp5150 3-005d (1 pad, 1 link) type V4L2 subdev subtype
Re: [PATCH 1/2] [media] V4L: atmel-isi: add code to enable/disable ISI_MCK clock
On Wed, Nov 30, 2011 at 06:06:43PM +0800, Josh Wu wrote:
+ /* Get ISI_MCK, provided by programmable clock or external clock */
+ isi-mck = clk_get(dev, isi_mck);
+ if (IS_ERR_OR_NULL(isi-mck)) {
This should be IS_ERR()
+ dev_err(dev, Failed to get isi_mck\n);
+ ret = isi-mck ? PTR_ERR(isi-mck) : -EINVAL;
ret = PTR_ERR(isi-mck);
--
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 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again
On 05-12-2011 21:47, Devin Heitmueller wrote:
On Mon, Dec 5, 2011 at 6:32 PM, Eddi De Pierie...@depieri.net wrote:
Sorry, I think I applied follow patch on my tree while I developed
the driver trying to fix tuner initialization.
http://patchwork.linuxtv.org/patch/6617/
I forgot to remove from my tree after I see that don't solve anything.
Ok, great. At least that explains why it's there (since I couldn't
figure out how on Earth the patch made sense otherwise).
Eddi, could you please submit a patch removing the offending code?
Ok, As Eddi agreed with this change, I'm adding the enclosed patch to
the development tree, removing the bad code.
I'll do a quick test before pushing it upstream.
Regards,
Mauro
-
[media] xc5000: Remove the global mutex lock at xc5000 firmware init
As reported by Devin Heitmueller dheitmuel...@kernellabs.com:
It seems like a change such as this could significantly change the
timing of tuner initialization if you have multiple xc5000 based
products that might have a slow i2c bus. Was that intentional?
After discussed with Eddi de Pierri e...@depieri.net, it was pointed that
the change was not intentional, and it was just a trial while developing
the patches that add support for HVR-930C.
So, remove this hack.
Reported-by: Devin Heitmueller dheitmuel...@kernellabs.com
Acked by: Eddi de Pierri e...@depieri.net
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index 048f489..ecd1f95 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -1004,8 +1004,6 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend
*fe)
struct xc5000_priv *priv = fe-tuner_priv;
int ret = 0;
- mutex_lock(xc5000_list_mutex);
-
if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
ret = xc5000_fwupload(fe);
if (ret != XC_RESULT_SUCCESS)
@@ -1025,8 +1023,6 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend
*fe)
/* Default to CABLE mode */
ret |= xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE);
- mutex_unlock(xc5000_list_mutex);
-
return ret;
}
Thanks,
Devin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wednesday 07 December 2011, Semwal, Sumit wrote: Do you have a use case for making the interface compile-time disabled? I had assumed that any code using it would make no sense if it's not available so you don't actually need this. Ok. Though if we keep the interface compile-time disabled, the users can actually check and fail or fall-back gracefully when the API is not available; If I remove it, anyways the users would need to do the same compile time check whether API is available or not, right? If you have to do a compile-time check for the config symbol, it's better to do it the way you did here than in the caller. My guess was that no caller would actually require this, because when you write a part of a subsystem to interact with the dma-buf infrastructure, you would always disable compilation of an extire file that deals with everything related to struct dma_buf, not just stub out the calls. 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: [PATCH 1/2] [media] V4L: atmel-isi: add code to enable/disableISI_MCK clock
Hi, Russell King
On Wed, Dec 07, 2011 at 4:50 PM, Russell King wrote:
On Wed, Nov 30, 2011 at 06:06:43PM +0800, Josh Wu wrote:
+/* Get ISI_MCK, provided by programmable clock or external clock
*/
+isi-mck = clk_get(dev, isi_mck);
+if (IS_ERR_OR_NULL(isi-mck)) {
This should be IS_ERR()
So it means the clk_get() will never return NULL even when clk structure
is NULL in clk lookup entry. Right?
+dev_err(dev, Failed to get isi_mck\n);
+ret = isi-mck ? PTR_ERR(isi-mck) : -EINVAL;
ret = PTR_ERR(isi-mck);
Best Regards,
Josh Wu
--
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 Controller (v4l2 core) MT9V032 Device Driver
Hi James, On Wednesday 07 December 2011 09:00:18 James wrote: On Friday 02 December 2011 05:14:36 James wrote: On Thu, Dec 1, 2011 at 7:10 AM, Laurent Pinchart wrote: On Tuesday 29 November 2011 03:07:28 James wrote: On Mon, Nov 28, 2011 at 7:15 PM, Laurent Pinchart wrote: Regarding why mplayer fails, I'm not too sure. Your pipeline is configured for YUYV, have you tried replacing outfmt=uyvy with outfmt=yuyv on the mplayer command line ? AFAIK mplayer only has outfmt=uyvy and even with the pipeline configured to UYVY, the result is the same; 0 frame processed. Any suggestion is most welcome to me. (^^) I wrote a patch that fixes the 2 warnings you get. It might help with mplayer, could you please try it ? http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3i sp- omap3isp-next How can I merge the patches in your branch omap3isp-omap3isp-next to Steve's tree locally? 1) I've cloned Steve's repo locally. 2) use git remote add pinchart git://linuxtv.org/pinchartl/media.git to the tree. 3) checked out the omap3isp-omap3isp-next branch 4) make a new branch that tracks Steve's omap-3.0-pm. git checkout -b myomap-3.0-pm -t origin/omap-3.0-pm 5) Merge your omap3isp-omap3isp-next branch. git pull . omap3isp-omap3isp-next after this command, I saw lots of files being removed and several merge conflicts. I tried git mergetool to call up kdiff3 to manually resolve but some are way out of ability/level of understanding since I don't know which holds the latest patches integrated into the respective files. The confusing parts is when your branch deleted lots of files. even drivers/net/smsc911x.c which is the driver for the ethernet chip!?! (^^) very confusing.. hahahaha That's because the two branches include lots of different changes. My branch is based on Mauro's official branch for patches targeted at the next kernel version, which is in turn based on mainline (between v3.1 and v3.2-rc1) and includes many patches for drivers/media/*. Steve's branch is also based on mainline, but on v3.0 instead of v3.1, and includes other patches. Thanks for clarifying the starting point of your tree. Which branch at Mauro's tree is your omap3isp-omap3isp-next sitting on? My -next branches are based on the latest staging/for_v3.* branch. I rebase them from time to time, so they might lag slightly. If you merge my branch onto Steve's tree, you will get the whole v3.1, which likely conflicts. Doing it the other way around isn't much better. The easiest way to use the OMAP3 ISP patches on top of Steve's tree is likely to hand-pick them. You can get a list of patches with git log, and use git cherry-pick to pick them manually. With this layout, my understanding is that the 'proper' path for Steve's branch to get updated with all media patches is only when the mainline merged Mauro's branch and Steve pull them into his or rebase against it. Right? Then you will get all patches automatically, but you will have to wait some time for them (v3.3 will be released in roughly 2 months). If you want to test the patches sooner, you can either merge Steve's branch onto omap3isp- omap3isp-next (but you might have to fix some conflicts manually), or use one of the two branches and cherry-pick the patches you want from the other branch. That's more work, but you'll get the result now. I saw Steve's repo staging a new omap-v3.2. http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=shortlog;h =refs/heads/omap-3.2 Wonder till what stage has Mauro's branch been merged into mainline. A staging/for_v3.* branch is merged into mainline in the v3.*-rc1 version. staging/for_v3.3 is thus waiting for the v3.3 merge window to open. Is there a way to determine a common baseline/point between both trees so that I can hand-pick them into Steve's v3.2? git-merge-base. My understanding of git workflow is still at 'infant' stage. (^^) and the difficulty is learning how to 'pull, merge resolves conflicts' from different trees/branches. (^^) I understand your pain. I've been there, and the learning curve was steep. But don't despair, once you understand the tool, it's extremely powerful. For this particular case you have another option. You can use Steve's tree and compile the V4L-DVB subsystem from my tree on top of that. Get a clone of media_build.git from git.linuxtv.org, and look for instructions in the linuxtv.org wiki. In a nutshell, media_build is a set of scripts and patches that let you compile the V4L-DVB subsystem from one git tree to run on another git tree. There can be compile errors from time to time when using bleeding edge kernels for either of the trees, but media_build then gets updated pretty fast. Since I'm using Overo, I relies mainly on Steve's repo but I do know
Re: [RFC/PATCH 0/5] v4l: New camera controls
Hi Laurent, On 12/06/2011 01:34 PM, Laurent Pinchart wrote: On Sunday 04 December 2011 16:16:11 Sylwester Nawrocki wrote: Hi All, I put some effort in preparing a documentation for a couple of new controls in the camera control class. It's a preeliminary work, it's mainly just documentation. There is yet no patches for any driver using these controls. I just wanted to get some possible feedback on them, if this sort of stuff is welcome and what might need to be done differently. Thanks for the patches. Regarding patches 3/5, 4/5 and 5/5, we should perhaps try to brainstorm this a bit. There's more to exposure setting than just those controls, maybe it's time to think about a proper exposure API. We could start by gathering requirements on the list, and maybe have an IRC meeting if needed. Certainly the existing support for exposure setting in V4L2 is not sufficient even for mobile camera control. I'll try to prepare a list of requirements. It would be great to have a brainstorming session with more people experienced in this field. Regards, -- Sylwester Nawrocki Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Omap3 ISP + Gstreamer v4l2src
Hi Adam, On Wednesday 07 December 2011 09:02:42 Adam Pledger wrote: Hi Laurent, Firstly, please accept my apologies, for what is very probably a naive question. I'm new to V4L2 and am just getting to grips with how things work. No worries. I'm using a tvp5151 in bt656 mode with the Omap3 ISP, Please note that BT.656 support is still experimental, so issues are not unexpected. as described in this thread (Your YUV support tree + some patches for bt656, based on 2.6.39): http://comments.gmane.org/gmane.linux.drivers.video-input- infrastructure/39539 I am able to capture some frames using yavta, using the media-ctl configuration as follows: media-ctl -v -r -l 'tvp5150 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005d:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x625]' This yields this: [snip] Looks good. The following works nicely: yavta -f UYVY -s 720x625 -n 4 --capture=4 -F /dev/video2 The problem comes when I try to use gstreamer to capture from /dev/video2, using the following: gst-launch v4l2src device=/dev/video2 ! 'video/x-raw-yuv,width=720,height=625' ! filesink location=sample.yuv This fails with: ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed getting controls attributes on device '/dev/video2'. Additional debug info: v4l2_calls.c(267): gst_v4l2_fill_lists (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed querying control 9963776 on device '/dev/video2'. (25 - Inappropriate ioctl for device) My question is, should this just work? It was my understanding that once the pipeline was configured with media-ctl then the CCDC output pad should behave like a standard V4L2 device node. That's more or less correct. There have been a passionate debate regarding what a standard V4L2 device node is. Not all V4L2 ioctls are mandatory, and no driver implements them all. The OMAP3 ISP driver implements a very small subset of the V4L2 API, and it wasn't clear whether that still qualified as V4L2. After discussions we decided that the V4L2 specification will document profiles, with a set of required ioctls for each of them. The OMAP3 ISP implements the future video streaming profile. I'm not sure what ioctls v4l2src consider as mandatory. The above error related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't implemented by the OMAP3 ISP driver and will likely never be. I don't think that should be considered as mandatory. I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't implemented in the OMAP3 ISP driver. That might change in the future, but I'm not sure yet whether it will. In any case, you might have to modify v4l2src and/or the OMAP3 ISP driver for now. Some patches have been posted a while ago to this mailing list. I realise that this might be something borked with my build dependencies (although I'm pretty certain that v4l2src is being built against the latest libv42) or gstreamer. Before I start digging through the code to work out what is going on with the ioctl handling, I thought I would check to see whether this should work, or whether I am doing something fundamentally silly. -- 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: uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2).
On 11/30/2011 04:51 AM, Laurent Pinchart wrote: Hi Alex, On Monday 28 November 2011 22:53:19 Alex wrote: On 11/28/2011 10:20 PM, Laurent Pinchart wrote: On Monday 28 November 2011 20:14:25 Alex wrote: On 11/28/2011 10:08 PM, Laurent Pinchart wrote: On Monday 28 November 2011 19:04:22 Alex wrote: Fortunately my laptop is alive now so I'm sending you lsusb output. Thanks. Would you mind re-running lsusb -v -d '04f2:b221' as root ? What laptop brand/model is the camera embedded in ? About reverting commit - will try bit later. I've received reports that reverting the commit helps. A proper patch has also been posted to the linux-usb mailing list (EHCI : Fix a regression in the ISO scheduler). It would be nice if you could check whether that fixes your first issue as well. That is lsusb output you asked. Laptop is Thinkpad T420s. Camera works OK with 3.1.x kernel BTW. Thank you. Could you send this fix patch to me please? http://www.spinics.net/lists/linux-usb/msg54992.html It was the first hit on Google... Laurent, Seems this patch didn't help I recompiled kernel and still get same error: [ 101.100914] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). [ 103.900163] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). [ 103.909735] uvcvideo: Failed to submit URB 0 (-28). [ 107.896939] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). I'm surprised. The patch has been included in 3.1.4, could you please try it ? Laurent, It works ok with 3.1.4 as with all other 3.1.x version. But doesn't work with 3.2-rc4 and previous Thanks, Alex -- 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 v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wed, Dec 7, 2011 at 3:41 PM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 07 December 2011, Semwal, Sumit wrote: Do you have a use case for making the interface compile-time disabled? I had assumed that any code using it would make no sense if it's not available so you don't actually need this. Ok. Though if we keep the interface compile-time disabled, the users can actually check and fail or fall-back gracefully when the API is not available; If I remove it, anyways the users would need to do the same compile time check whether API is available or not, right? If you have to do a compile-time check for the config symbol, it's better to do it the way you did here than in the caller. My guess was that no caller would actually require this, because when you write a part of a subsystem to interact with the dma-buf infrastructure, you would always disable compilation of an extire file that deals with everything related to struct dma_buf, not just stub out the calls. Right; that would be ideal, but we may not be able to ask each user to do so - especially when the sharing part might be interspersed in existing buffer handling code. So for now, I would like to keep it as it-is. Arnd BR, ~Sumit. -- -- 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: uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2).
Hi Alex, On Wednesday 07 December 2011 11:48:36 Alex wrote: On 11/30/2011 04:51 AM, Laurent Pinchart wrote: On Monday 28 November 2011 22:53:19 Alex wrote: On 11/28/2011 10:20 PM, Laurent Pinchart wrote: On Monday 28 November 2011 20:14:25 Alex wrote: On 11/28/2011 10:08 PM, Laurent Pinchart wrote: On Monday 28 November 2011 19:04:22 Alex wrote: Fortunately my laptop is alive now so I'm sending you lsusb output. Thanks. Would you mind re-running lsusb -v -d '04f2:b221' as root ? What laptop brand/model is the camera embedded in ? About reverting commit - will try bit later. I've received reports that reverting the commit helps. A proper patch has also been posted to the linux-usb mailing list (EHCI : Fix a regression in the ISO scheduler). It would be nice if you could check whether that fixes your first issue as well. That is lsusb output you asked. Laptop is Thinkpad T420s. Camera works OK with 3.1.x kernel BTW. Thank you. Could you send this fix patch to me please? http://www.spinics.net/lists/linux-usb/msg54992.html It was the first hit on Google... Laurent, Seems this patch didn't help I recompiled kernel and still get same error: [ 101.100914] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). [ 103.900163] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). [ 103.909735] uvcvideo: Failed to submit URB 0 (-28). [ 107.896939] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). I'm surprised. The patch has been included in 3.1.4, could you please try it ? Laurent, It works ok with 3.1.4 as with all other 3.1.x version. But doesn't work with 3.2-rc4 and previous The fix for the Failed to submit URB error is in Linus' tree, and will be in v3.2-rc5. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 3/5] v4l: Add V4L2_CID_METERING_MODE camera control
On 12/06/2011 05:27 PM, Sylwester Nawrocki wrote:
+
entryconstantV4L2_METERING_MODE_CENTER_WEIGHTED/constantnbsp;/entr
y + entryAverage the light information coming from the
entire scene
+giving priority to the center of the metered area./entry
+ /row
+ row
+
entryconstantV4L2_METERING_MODE_SPOT/constantnbsp;/entry
+ entryMeasure only very small area at the cent-re of the
scene./entry +/row
+ /tbody
For the last two cases, would it also make sense to specify the center of
the
weighted area and the spot location ?
Yes, that's quite basic requirement as well.. A means to determine the
location would be also needed for some auto focus algorithms.
Additionally for V4L2_METERING_MODE_CENTER_WEIGHTED it's also needed to
specify the size of the area (width/height).
What do you think about defining new control for passing pixel position,
i.e. modifying struct v4l2_ext_control to something like:
struct v4l2_ext_control {
__u32 id;
__u32 size;
__u32 reserved2[1];
union {
__s32 value;
__s64 value64;
struct v4l2_point position;
char *string;
};
} __attribute__ ((packed));
where:
struct v4l2_point {
__s32 x;
__s32 y;
};
Hmm, that won't work since there is no way to handle the min/max/step for
more than one value. Probably the selection API could be used for specifying
the metering rectangle, or just separate controls for x, y, width, height.
Since we need to specify only locations for some controls and a rectangle for
others, probably separate controls would be more suitable.
--
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: Omap3 ISP + Gstreamer v4l2src
Hi Adam, On 12/07/2011 11:34 AM, Laurent Pinchart wrote: Hi Adam, On Wednesday 07 December 2011 09:02:42 Adam Pledger wrote: Hi Laurent, Firstly, please accept my apologies, for what is very probably a naive question. I'm new to V4L2 and am just getting to grips with how things work. No worries. I'm using a tvp5151 in bt656 mode with the Omap3 ISP, Please note that BT.656 support is still experimental, so issues are not unexpected. as described in this thread (Your YUV support tree + some patches for bt656, based on 2.6.39): http://comments.gmane.org/gmane.linux.drivers.video-input- infrastructure/39539 I am able to capture some frames using yavta, using the media-ctl configuration as follows: media-ctl -v -r -l 'tvp5150 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005d:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x625]' This yields this: [snip] Looks good. The following works nicely: yavta -f UYVY -s 720x625 -n 4 --capture=4 -F /dev/video2 The problem comes when I try to use gstreamer to capture from /dev/video2, using the following: gst-launch v4l2src device=/dev/video2 ! 'video/x-raw-yuv,width=720,height=625' ! filesink location=sample.yuv This fails with: ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed getting controls attributes on device '/dev/video2'. Additional debug info: v4l2_calls.c(267): gst_v4l2_fill_lists (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed querying control 9963776 on device '/dev/video2'. (25 - Inappropriate ioctl for device) My question is, should this just work? It was my understanding that once the pipeline was configured with media-ctl then the CCDC output pad should behave like a standard V4L2 device node. That's more or less correct. There have been a passionate debate regarding what a standard V4L2 device node is. Not all V4L2 ioctls are mandatory, and no driver implements them all. The OMAP3 ISP driver implements a very small subset of the V4L2 API, and it wasn't clear whether that still qualified as V4L2. After discussions we decided that the V4L2 specification will document profiles, with a set of required ioctls for each of them. The OMAP3 ISP implements the future video streaming profile. I'm not sure what ioctls v4l2src consider as mandatory. The above error related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't implemented by the OMAP3 ISP driver and will likely never be. I don't think that should be considered as mandatory. I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't implemented in the OMAP3 ISP driver. That might change in the future, but I'm not sure yet whether it will. In any case, you might have to modify v4l2src and/or the OMAP3 ISP driver for now. Some patches have been posted a while ago to this mailing list. Here was my submission for ENUM_FMT support: http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html I submitted this in order to be able to use the omap3-isp with GStreamer. I missed the discussion about V4L2 profiles, but when I submitted that patch we discussed whether ENUM_FMT was mandatory. After I pointed out that the V4L2 spec states plainly that it _is_ mandatory, I thought Laurent basically agreed that it was reasonable. Laurent, what do you think about adding ENUM_FMT support now? I realise that this might be something borked with my build dependencies (although I'm pretty certain that v4l2src is being built against the latest libv42) or gstreamer. Before I start digging through the code to work out what is going on with the ioctl handling, I thought I would check to see whether this should work, or whether I am doing something fundamentally silly. -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier -- 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] Resolution change support in video codecs in v4l2
From: Sakari Ailus [mailto:sakari.ai...@iki.fi] Sent: 06 December 2011 23:42 [...] That's a good point. It's more related to changes in stream properties --- the frame rate of the stream could change, too. That might be when you could like to have more buffers in the queue. I don't think this is critical either. This could also depend on the properties of the codec. Again, I'd wish a comment from someone who knows codecs well. Some codecs need to be able to access buffers which have already been decoded to decode more buffers. Key frames, simply. Ok, but let's not add unneeded things at the API if you're not sure. If we have such need for a given hardware, then add it. Otherwise, keep it simple. This is not so much dependent on hardware but on the standards which the cdoecs implement. Could you please elaborate it? On what scenario this is needed? This is a property of the stream, not a property of the decoder. To reconstruct each frame, a part of the stream is required and already decoded frames may be used to accelerate the decoding. What those parts are. depends on the codec, not a particular implementation. They are not used to accelerate decoding. They are used to predict what should be displayed. If that frame is missing or modified it will cause corruption in consecutive frames. I want to make it clear - they are necessary, not optional to accelerate decoding speed. Anyone with more knowledge of codecs than myself might be able to give a concrete example. Sebastian? -- Kamil Debski Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[dvb] Problem registering demux0 device
Hi, I'm implementing new adapter for DVB, I built a module to register the adapter and demux/net devices. From the kernel log I see all actions are performed fine and dvb_register_device (called by dvb_dmxdev_init) is called successfully for net0/demux0/dvr0, however, demux0/dvr0 devices do not show up, ls /sys/class/dvb shows only dvb0.net0 (and nothing appears under /dev/dvb/ anyhow). What could cause not having demux0/dvr0 registered? Note that net0 shows up fine. Appreciate your help. Thanks Hamad -- 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 v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wednesday 07 December 2011, Semwal, Sumit wrote: Right; that would be ideal, but we may not be able to ask each user to do so - especially when the sharing part might be interspersed in existing buffer handling code. So for now, I would like to keep it as it-is. Ok, fair enough. It certainly doesn't hurt. 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: Omap3 ISP + Gstreamer v4l2src
Hi Laurent, Michael, snip Please note that BT.656 support is still experimental, so issues are not unexpected. Yes, I was aware that this is not yet fully baked. snip My question is, should this just work? It was my understanding that once the pipeline was configured with media-ctl then the CCDC output pad should behave like a standard V4L2 device node. That's more or less correct. There have been a passionate debate regarding what a standard V4L2 device node is. Not all V4L2 ioctls are mandatory, and no driver implements them all. The OMAP3 ISP driver implements a very small subset of the V4L2 API, and it wasn't clear whether that still qualified as V4L2. After discussions we decided that the V4L2 specification will document profiles, with a set of required ioctls for each of them. The OMAP3 ISP implements the future video streaming profile. I'm not sure what ioctls v4l2src consider as mandatory. The above error related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't implemented by the OMAP3 ISP driver and will likely never be. I don't think that should be considered as mandatory. I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't implemented in the OMAP3 ISP driver. That might change in the future, but I'm not sure yet whether it will. In any case, you might have to modify v4l2src and/or the OMAP3 ISP driver for now. Some patches have been posted a while ago to this mailing list. Here was my submission for ENUM_FMT support: http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html I submitted this in order to be able to use the omap3-isp with GStreamer. I missed the discussion about V4L2 profiles, but when I submitted that patch we discussed whether ENUM_FMT was mandatory. After I pointed out that the V4L2 spec states plainly that it _is_ mandatory, I thought Laurent basically agreed that it was reasonable. Laurent, what do you think about adding ENUM_FMT support now? Thank you both for clarifying the current situation regarding omap3isp / MCF (and Michael for the previous patch, which I will take a look at). This addresses quite a few questions that I have been mulling over in the last few days. snip Best Regards Adam -- 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] Resolution change support in video codecs in v4l2
From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Sent: 06 December 2011 17:40 On 06-12-2011 14:11, Kamil Debski wrote: From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Sent: 06 December 2011 16:40 On 06-12-2011 13:19, Kamil Debski wrote: From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Sent: 06 December 2011 15:42 On 06-12-2011 12:28, 'Sakari Ailus' wrote: Hi all, On Tue, Dec 06, 2011 at 01:00:59PM +0100, Laurent Pinchart wrote: ... 2) new requirement is for a bigger buffer. DMA transfers need to be stopped before actually writing inside the buffer (otherwise, memory will be corrupted). In this case, all queued buffers should be marked with an error flag. So, both V4L2_BUF_FLAG_FORMATCHANGED and V4L2_BUF_FLAG_ERROR should raise. The new format should be available via G_FMT. I'd like to reword this as follows: 1. In all cases, the application needs to be informed that the format has changed. V4L2_BUF_FLAG_FORMATCHANGED (or a similar flag) is all we need. G_FMT will report the new format. 2. In all cases, the application must have the option of reallocating buffers if it wishes. In order to support this, the driver needs to wait until the application acknowledged the format change before it starts decoding the stream. Otherwise, if the codec started decoding the new stream to the existing buffers by itself, applications wouldn't have the option of freeing the existing buffers and allocating smaller ones. STREAMOFF/STREAMON is one way of acknowledging the format change. I'm not opposed to other ways of doing that, but I think we need an acknowledgment API to tell the driver to proceed. Forcing STRAEMOFF/STRAEMON has two major advantages: 1) The application will have an ability to free and reallocate buffers if it wishes so, and 2) It will get explicit information on the changed format. Alternative would require an additional API to query the format of buffers in cases the information isn't implicitly available. As already said, a simple flag may give this meaning. Alternatively (or complementary, an event may be generated, containing the new format). If we do not require STRAEMOFF/STREAMON, the stream would have to be paused until the application chooses to continue it after dealing with its buffers and formats. No. STREAMOFF is always used to stop the stream. We can't make it mean otherwise. So, after calling it, application should assume that frames will be lost, while the DMA engine doesn't start again. Do you mean all buffers or just those that are queued in hardware? Of course the ones queued. What has been processed stays processed, it should not matter to the buffers that have been processed. Sure. The compressed buffer that is queued in the driver and that caused the resolution change is on the OUTPUT queue. Not necessarily. If the buffer is smaller than the size needed for the resolution change, what is there is trash, as it could be a partially filled buffer or an empty buffer, depending if the driver detected about the format change after or before start filling it. I see the problem. If a bigger buffer is needed it's clear. A buffer with no sane data is returned and *_FORMAT_CHANGED | *_ERROR flags are set. If the resolution is changed but it fits the current conditions (size + number of buffers) then what should be the contents of the returned buffer? The one returned on G_FMT or at an specific event. Userspace application can change it later with S_FMT, if needed. I think that still it should contain no useful data, just *_FORMAT_CHANGED | *_ERROR flags set. Then the application could decide whether it keeps the current size/alignment/... or should it allocate new buffers. Then ACK the driver. This will cause frame losses on Capture devices. It probably doesn't make sense to define resolution change support like this for output devices. Eventually, we may have an extra flag: *_PAUSE. If *_PAUSE is detected, a VIDEO_DECODER_CMD is needed to continue. So, on M2M devices, the 3 flags are raised and the buffer is not filled. This would cover Sakari's case. For our (Samsung) hw this is not a problem, we could always use the existing buffers if it is possible (size). But Sakari had reported that he might need to adjust some alignment property. Also, having memory constraints, the application might choose to allocate smaller buffers. STREMOFF is only done on the CAPTURE queue, so it stays queued and information is retained. From CAPTURE all processed buffers have already been dequeued, so yes the content of the buffers queued in hw is lost. But this is ok, because after the resolution change the previous frames are not used in prediction. No. According with the spec: The VIDIOC_STREAMON
Re: [dvb] Problem registering demux0 device
On 07-12-2011 09:30, Hamad Kadmany wrote: Hi, I'm implementing new adapter for DVB, I built a module to register the adapter and demux/net devices. From the kernel log I see all actions are performed fine and dvb_register_device (called by dvb_dmxdev_init) is called successfully for net0/demux0/dvr0, however, demux0/dvr0 devices do not show up, ls /sys/class/dvb shows only dvb0.net0 (and nothing appears under /dev/dvb/ anyhow). What could cause not having demux0/dvr0 registered? Note that net0 shows up fine. It is hard to tell the exact problem without looking into the driver. Are you handling the error codes returned by the register functions? You can follow what's happening inside your driver by enabling tracepoints. Here is one of the scripts I used when I need to know what functions are called: #!/bin/bash cd /sys/kernel/debug/tracing echo disabling trace echo 0 tracing_enabled echo getting funcs FUNC=`cat /sys/kernel/debug/tracing/available_filter_functions|grep -i drx` echo setting functions echo $FUNCset_ftrace_filter echo set trace type echo function_graph current_tracer echo enabling trace echo 1 tracing_enabled (the above enables tracing only for functions with drx in the name - you'll need to tailor it for your specific needs) Of course, after finishing the device creation, you should disable the trace and get its results with: #!/bin/bash cd /sys/kernel/debug/tracing echo 0 tracing_enabled less trace I suggest you to compare the trace for a device that is known to create all dvb nodes with your driver. This may give you a good hint about what is missing on your driver. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge HVR-930C problems
On 05-12-2011 21:37, Eddi De Pieri wrote: try using scan from dvb-apps and not w_scan. Actually It seems to me w_scan isn't compatible with this driver due some missing lock. It works for me. The only parameter that it is mandatory is -f c, in order to use the DVB-C frontend, instead of DVB-T. I've passed a few other parameters to speedup it (otherwise, it would take hours, as it tries first QAM_64, on all possible symbol rates, and then QAM_256). Anyway: $ w_scan -f c -S 13 -Q 1 w_scan version 20111011 (compiled for DVB API 5.3) guessing country 'BR', use -c country to override using settings for BRAZIL DVB cable DVB-C BR frontend_type DVB-C, channellist 10 output format vdr-1.6 output charset 'UTF-8', use -C charset to override Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - DVB-C DRXK DVB-C: good :-) /dev/dvb/adapter0/frontend1 - DVB-T DRXK DVB-T: specified was DVB-C - SEARCH NEXT ONE. Using DVB-C frontend (adapter /dev/dvb/adapter0/frontend0) -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 5.4 frontend 'DRXK DVB-C' supports INVERSION_AUTO QAM_AUTO not supported, trying QAM_256. FEC_AUTO FREQ (47.00MHz ... 862.00MHz) SRATE (0.870MBd ... 11.700MBd) -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ searching QAM256... 57000: sr5217 (time: 00:01) 63000: sr5217 (time: 00:03) 69000: sr5217 (time: 00:06) 79000: sr5217 (time: 00:08) 85000: sr5217 (time: 00:11) 177000: sr5217 (time: 00:13) 183000: sr5217 (time: 00:16) 189000: sr5217 (time: 00:18) 195000: sr5217 (time: 00:21) 201000: sr5217 (time: 00:23) 207000: sr5217 (time: 00:26) 213000: sr5217 (time: 00:28) 123000: sr5217 (time: 00:31) 129000: sr5217 (time: 00:34) 135000: sr5217 (time: 00:36) 141000: sr5217 (time: 00:39) 147000: sr5217 (time: 00:41) 153000: sr5217 (time: 00:44) 159000: sr5217 (time: 00:46) 165000: sr5217 (time: 00:49) 171000: sr5217 (time: 00:51) 219000: sr5217 (time: 00:54) 225000: sr5217 (time: 00:56) 231000: sr5217 (time: 00:59) 237000: sr5217 (time: 01:01) 243000: sr5217 (time: 01:04) 249000: sr5217 (time: 01:07) 255000: sr5217 (time: 01:09) 261000: sr5217 (time: 01:12) 267000: sr5217 (time: 01:14) 273000: sr5217 (time: 01:17) 279000: sr5217 (time: 01:19) 285000: sr5217 (time: 01:22) 291000: sr5217 (time: 01:24) 297000: sr5217 (time: 01:27) 303000: sr5217 (time: 01:29) 309000: sr5217 (time: 01:32) 315000: sr5217 (time: 01:34) 321000: sr5217 (time: 01:37) 327000: sr5217 (time: 01:40) 333000: sr5217 (time: 01:42) 339000: sr5217 (time: 01:45) 345000: sr5217 (time: 01:47) 351000: sr5217 (time: 01:50) 357000: sr5217 (time: 01:52) 363000: sr5217 (time: 01:55) 369000: sr5217 (time: 01:57) 375000: sr5217 (time: 02:00) 381000: sr5217 (time: 02:02) 387000: sr5217 (time: 02:05) 393000: sr5217 (time: 02:08) 399000: sr5217 (time: 02:10) 405000: sr5217 (time: 02:13) 411000: sr5217 (time: 02:15) 417000: sr5217 (time: 02:18) 423000: sr5217 (time: 02:20) 429000: sr5217 (time: 02:23) 435000: sr5217 (time: 02:25) 441000: sr5217 (time: 02:28) 447000: sr5217 (time: 02:30) 453000: sr5217 (time: 02:33) 459000: sr5217 (time: 02:35) 465000: sr5217 (time: 02:38) 471000: sr5217 (time: 02:41) 477000: sr5217 (time: 02:43) 483000: sr5217 (time: 02:46) 489000: sr5217 (time: 02:48) 495000: sr5217 (time: 02:51) 501000: sr5217 (time: 02:53) 507000: sr5217 (time: 02:56) 513000: sr5217 (time: 02:58) 519000: sr5217 (time: 03:01) 525000: sr5217 (time: 03:03) 531000: sr5217 (time: 03:06) 537000: sr5217 (time: 03:08) 543000: sr5217 (time: 03:11) 549000: sr5217 (time: 03:14) 555000: sr5217 (time: 03:16) 561000: sr5217 (time: 03:19) 567000: sr5217 (time: 03:21) 573000: sr5217 (time: 03:24) (time: 03:25) signal ok: QAM_256 f = 573000 kHz S5217C999 new transponder: (QAM_256 f = 591000 kHz S5217C34) new transponder: (QAM_256 f = 597000 kHz S5217C34) new transponder: (QAM_256 f = 603000 kHz S5217C34) new transponder: (QAM_256 f = 609000 kHz S5217C34) new transponder: (QAM_256 f = 615000 kHz S5217C34) new transponder: (QAM_256 f = 621000 kHz S5217C34) new transponder: (QAM_256 f = 627000 kHz S5217C34) new transponder: (QAM_256 f = 633000 kHz S5217C34) new transponder: (QAM_256 f = 639000 kHz S5217C34) new transponder: (QAM_256 f = 681000 kHz S5217C34) new transponder: (QAM_256 f = 651000 kHz S5217C34) new transponder: (QAM_256 f = 693000 kHz S5217C34) new transponder: (QAM_256 f = 699000 kHz S5217C34) new transponder: (QAM_256 f = 687000 kHz S5217C34) new transponder: (QAM_256 f = 657000 kHz S5217C34) new transponder: (QAM_256 f = 663000 kHz S5217C34) new transponder: (QAM_256 f = 669000 kHz S5217C34) new transponder: (QAM_256 f = 705000 kHz S5217C34) new
Re: Hauppauge HVR-930C problems
On 02-12-2011 17:41, Fredrik Lingvall wrote: Hi , I noticed that HVR 930C support was added 21-11-2011. I have build the new driver and installed the firmware but I'm struggling to get it working. 4) DVB scanning # w_scan -c NO -f c ... 602000: sr6900 (time: 10:32) (time: 10:33) signal ok: QAM_256 f = 602000 kHz S6900C999 This means that it detected a QAM_256 carrier, at 602000 kHz, with 6.900 Kbauds symbol rate. start_filter:1415: ERROR: ioctl DMX_SET_FILTER failed: 28 No space left on device -ENOSPC error is generally associated with the lack of USB bandwidth support. This means that the USB bus doesn't have enough free slots for the traffic required in order to support your stream. It generally means that your device is connected into a USB 1.1 hub or port. There are some new USB interfaces that are known to have troubles with the Linux USB 2.0 implementation, as they internally use some USB hubs. It could be your case, as the driver detects it on an USB 2.0 port: [90072.073832] em28xx: New device WinTV HVR-930C @ 480 Mbps (2040:1605, interface 0, class 0) Please do a: # mount usbfs /proc/bus/usb -t usbfs $ cat /proc/bus/usb/devices It should see you something like: T: Bus=08 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 29/900 us ( 3%), #Int= 2, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1d.2 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=08 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 D: Ver= 1.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=2101 ProdID=020f Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=10ms T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1d.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1d.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1a.2 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1a.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1a.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:00:1d.7 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS=
Re: [PATCH 0/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
On 06-12-2011 12:33, Gianluca Gennari wrote: Hi All, I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components: - Empiatech em2880 USB bridge; - Zarlink zl10353 demodulator; - Xceive XC3028 tuner; For this device, the ZARLINK456 define is set to true so it is using the firmwares with type D2633 for the XC3028 tuner. I found out that: 1) the DTV7 firmware works fine in VHF band (bw=7MHz); 2) the DTV8 firmware works fine in UHF band (bw=8MHz); 3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not work at all in VHF band (bw=7MHz); In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and immediately lost. So the proposed patch forces a reload of the DTV7 firmware every time a 7MHz channel is requested. The only drawback is that channel change from VHF to UHF or viceversa is slightly slower. Devices using the D2620 firmwares are unaffected. Hi Gianluca, The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we do, we end by having troubles, as the issue is Country-dependent. For example, Australia requires a different firmware than Germany, due to the differences on the VHF/UHF bands. I prefer if you could work into a patch that would add some modprobe parameter to disable the current autodetection way, allowing to override the firmware used for VHF and UHF. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.3] uvcvideo: move to vb2, support UVC timestamps, and various fixes
Hi Mauro, The following changes since commit 2a887d27708a4f9f3b5ad8258f9e19a150b58f03: [media] tm6000: fix OOPS at tm6000_ir_int_stop() and tm6000_ir_int_start() (2011-11-30 16:49:45 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next Alexey Fisher (2): uvcvideo: Add debugfs support uvcvideo: Extract video stream statistics Haogang Chen (1): uvcvideo: Fix integer overflow in uvc_ioctl_ctrl_map() Laurent Pinchart (10): uvcvideo: Move fields from uvc_buffer::buf to uvc_buffer uvcvideo: Use videobuf2-vmalloc uvcvideo: Handle uvc_init_video() failure in uvc_video_enable() uvcvideo: Remove duplicate definitions of UVC_STREAM_* macros uvcvideo: Add support for LogiLink Wireless Webcam uvcvideo: Make uvc_commit_video() static uvcvideo: Don't skip erroneous payloads uvcvideo: Ignore GET_RES error for XU controls uvcvideo: Extract timestamp-related statistics uvcvideo: Add UVC timestamps support drivers/media/video/uvc/Kconfig |1 + drivers/media/video/uvc/Makefile |2 +- drivers/media/video/uvc/uvc_ctrl.c| 17 +- drivers/media/video/uvc/uvc_debugfs.c | 135 +++ drivers/media/video/uvc/uvc_driver.c | 30 ++- drivers/media/video/uvc/uvc_isight.c | 10 +- drivers/media/video/uvc/uvc_queue.c | 564 -- drivers/media/video/uvc/uvc_v4l2.c| 29 +- drivers/media/video/uvc/uvc_video.c | 625 ++-- drivers/media/video/uvc/uvcvideo.h| 128 ++-- 10 files changed, 1039 insertions(+), 502 deletions(-) create mode 100644 drivers/media/video/uvc/uvc_debugfs.c -- 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 2/2] [media] tm6000: Fix bad indentation.
On 06-12-2011 19:03, Antti Palosaari wrote: On 12/06/2011 10:58 PM, Mauro Carvalho Chehab wrote: On 06-12-2011 12:13, Thierry Reding wrote: * Antti Palosaari wrote: That question is related to that kind of indentation generally, not only that patch. On 12/06/2011 03:39 PM, Thierry Reding wrote: Function parameters on subsequent lines should never be aligned with the function name but rather be indented. [...] usb_set_interface(dev-udev, - dev-isoc_in.bInterfaceNumber, - 0); + dev-isoc_in.bInterfaceNumber, 0); Which kind of indentation should be used when function params are slitted to multiple lines? Documentation/CodingStyle currently says: Statements longer than 80 columns will be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long argument list. However, never break user-visible strings such as printk messages, because that breaks the ability to grep for them. So, it should be: substantially to the right whatever this means. I don't think this is documented anywhere and there are no hard rules with regard to this. I guess anything is fine as long as it is indented at all. In that case two tabs are used (related to function indentation). example: ret= function(param1, param2); I usually use that because it is my text editor's default. Other generally used is only one tab (related to function indentation). example: ret= function(param1, param2); I think that's okay as well. One tab can hardly be interpreted as substantially to the right. And last generally used is multiple tabs + spaces until same location where first param is meet (related to function indentation). I see that bad since use of tabs, with only spaces I see it fine. And this many times leads situation param level are actually different whilst originally idea was to put those same level. example: ret= function(param1, param2); In practice, this is the most commonly used way, from what I noticed, not only at drivers/media. A good place to look for commonly used CodingStyle are the most used headers at include/linux. As far as I noticed, they all use this style. Yes, but it is not correct according to CodingStyle if you use spaces even when mixing with tabs. Correct seems to be intend it adding only tabs, as many as possible, still not to exceed 80 char line len limit. This is not indentation, it is long line breaking. There's nothing there saying that white spaces are not allowed on line breaks, nor checkpatch complains about it. So, it seems to be the better way for doing it, although CodingStyle doesn't enforce it. Whether this works or not always depends on the tab-width. I think most variations are okay here. Some people like to align them, other people don't. Tab width is always 8, according with the CodingStyle: Tabs are 8 characters, and thus indentations are also 8 characters. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [dvb] Problem registering demux0 device
On 07-12-2011 13:50, Mauro Carvalho Chehab wrote:
It is hard to tell the exact problem without looking into the driver. Are you
handling the error codes returned by the register functions?
You can follow what's happening inside your driver by enabling tracepoints.
Here is one of the scripts I used when I need to know what functions are
called:
#!/bin/bash
cd /sys/kernel/debug/tracing
echo disabling trace
echo 0 tracing_enabled
echo getting funcs
FUNC=`cat /sys/kernel/debug/tracing/available_filter_functions|grep -i
drx`
echo setting functions
echo $FUNCset_ftrace_filter
echo set trace type
echo function_graph current_tracer
echo enabling trace
echo 1 tracing_enabled
(the above enables tracing only for functions with drx in the name - you'll
need to tailor it for your specific needs)
Of course, after finishing the device creation, you should disable the trace
and
get its results with:
#!/bin/bash
cd /sys/kernel/debug/tracing
echo 0 tracing_enabled
less trace
I suggest you to compare the trace for a device that is known to create all
dvb
nodes with your driver. This may give you a good hint about what is missing on
your driver.
Regards,
Mauro
I'm checking return error codes, no problems there, I also added traces within
the register functions and they all run fine. Here's my code that registers the
demux device (note that the net device works fine):
static struct dvb_demux demux;
static struct dmxdev dmxdev;
static struct dvb_net net;
static struct dmx_frontend fe_hw;
static struct dmx_frontend fe_mem;
static int test_start_feed(struct dvb_demux_feed *feed)
{
printk(KERN_INFO %s executed\n, __FUNCTION__);
return 0;
}
static int test_stop_feed(struct dvb_demux_feed *feed)
{
printk(KERN_INFO %s executed\n, __FUNCTION__);
return 0;
}
static int test_write_to_decoder(struct dvb_demux_feed *feed, const u8 *buf,
size_t len)
{
printk(KERN_INFO %s executed\n, __FUNCTION__);
return 0;
}
// initialization specific demux device
void test_demux_device_init(struct dvb_adapter* adapter)
{
int result;
printk(KERN_INFO %s executed\n, __FUNCTION__);
memset(demux, 0, sizeof(struct dvb_demux));
demux.dmx.capabilities = DMX_TS_FILTERING |
DMX_PES_FILTERING |
DMX_SECTION_FILTERING |
DMX_MEMORY_BASED_FILTERING |
DMX_CRC_CHECKING |
DMX_TS_DESCRAMBLING;
demux.priv = NULL;
demux.filternum = 31;
demux.feednum = 31;
demux.start_feed = test_start_feed;
demux.stop_feed = test_stop_feed;
demux.write_to_decoder = test_write_to_decoder;
printk(KERN_INFO %s call dvb_dmx_init\n, __FUNCTION__);
if ((result = dvb_dmx_init(demux)) 0)
{
printk(KERN_ERR %s: dvb_dmx_init failed\n, __FUNCTION__);
goto init_failed;
}
dmxdev.filternum = 31;
dmxdev.demux = demux.dmx;
dmxdev.capabilities = 0;
printk(KERN_INFO %s call dvb_dmxdev_init\n, __FUNCTION__);
if ((result = dvb_dmxdev_init(dmxdev, adapter)) 0)
{
printk(KERN_ERR %s: dvb_dmxdev_init failed (errno=%d)\n,
__FUNCTION__, result);
goto init_failed_dmx_release;
}
fe_hw.source = DMX_FRONTEND_0;
printk(KERN_INFO %s call add_frontend\n, __FUNCTION__);
if ((result = demux.dmx.add_frontend(demux.dmx, fe_hw)) 0)
{
printk(KERN_ERR %s: add_frontend (hw) failed (errno=%d)\n,
__FUNCTION__, result);
goto init_failed_dmxdev_release;
}
fe_mem.source = DMX_MEMORY_FE;
if ((result = demux.dmx.add_frontend(demux.dmx, fe_mem)) 0)
{
printk(KERN_ERR %s: add_frontend (mem) failed (errno=%d)\n,
__FUNCTION__, result);
goto init_failed_remove_hw_frontend;
}
if ((result = demux.dmx.connect_frontend(demux.dmx, fe_hw)) 0)
{
printk(KERN_ERR %s: connect_frontend failed (errno=%d)\n,
__FUNCTION__, result);
goto init_failed_remove_mem_frontend;
}
if ((result = dvb_net_init(adapter, net, demux.dmx)) 0)
{
printk(KERN_ERR %s: dvb_net_init failed (errno=%d)\n,
__FUNCTION__, result);
goto init_failed_disconnect_frontend;
}
init_failed_disconnect_frontend:
demux.dmx.disconnect_frontend(demux.dmx);
init_failed_remove_mem_frontend:
demux.dmx.remove_frontend(demux.dmx, fe_mem);
init_failed_remove_hw_frontend:
demux.dmx.remove_frontend(demux.dmx,
[PATCH] as3645a: Handle power on errors when registering the device
Return an error in the registered handler if the device can't be powered on. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/as3645a.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) Hi everybody, This patch applies on top of the as3645a driver that I'm going to submit for v3.3. In order to make review easier I'm sending it separately, I will then squash it into the driver for submission. diff --git a/drivers/media/video/as3645a.c b/drivers/media/video/as3645a.c index d583a9c..f7c3178 100644 --- a/drivers/media/video/as3645a.c +++ b/drivers/media/video/as3645a.c @@ -557,7 +557,9 @@ static int as3645a_registered(struct v4l2_subdev *sd) /* Power up the flash driver and read manufacturer ID, model ID, RFU * and version. */ - as3645a_set_power(flash-subdev, 1); + rval = as3645a_set_power(flash-subdev, 1); + if (rval 0) + return rval; rval = as3645a_read(flash, AS_DESIGN_INFO_REG); if (rval 0) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
Hi Daniel, Rob,
On Tue, Dec 6, 2011 at 3:41 AM, Rob Clark r...@ti.com wrote:
On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann a...@arndb.de wrote:
In the patch 2, you have a section about migration that mentions that
it is possible to export a buffer that can be migrated after it
is already mapped into one user driver. How does that work when
the physical addresses are mapped into a consumer device already?
I think you can do physical migration if you are attached, but
probably not if you are mapped.
Yeah, that's very much how I see this, and also why map/unmap (at least
for simple users like v4l) should only bracket actual usage. GPU memory
managers need to be able to move around buffers while no one is using
them.
[snip]
+ /* allow allocator to take care of cache ops */
+ void (*sync_sg_for_cpu) (struct dma_buf *, struct device *);
+ void (*sync_sg_for_device)(struct dma_buf *, struct device *);
I don't see how this works with multiple consumers: For the streaming
DMA mapping, there must be exactly one owner, either the device or
the CPU. Obviously, this rule needs to be extended when you get to
multiple devices and multiple device drivers, plus possibly user
mappings. Simply assigning the buffer to the device from one
driver does not block other drivers from touching the buffer, and
assigning it to the cpu does not stop other hardware that the
code calling sync_sg_for_cpu is not aware of.
The only way to solve this that I can think of right now is to
mandate that the mappings are all coherent (i.e. noncachable
on noncoherent architectures like ARM). If you do that, you no
longer need the sync_sg_for_* calls.
My original thinking was that you either need DMABUF_CPU_{PREP,FINI}
ioctls and corresponding dmabuf ops, which userspace is required to
call before / after CPU access. Or just remove mmap() and do the
mmap() via allocating device and use that device's equivalent
DRM_XYZ_GEM_CPU_{PREP,FINI} or DRM_XYZ_GEM_SET_DOMAIN ioctls. That
would give you a way to (a) synchronize with gpu/asynchronous
pipeline, (b) synchronize w/ multiple hw devices vs cpu accessing
buffer (ie. wait all devices have dma_buf_unmap_attachment'd). And
that gives you a convenient place to do cache operations on
noncoherent architecture.
I sort of preferred having the DMABUF shim because that lets you pass
a buffer around userspace without the receiving code knowing about a
device specific API. But the problem I eventually came around to: if
your GL stack (or some other userspace component) is batching up
commands before submission to kernel, the buffers you need to wait for
completion might not even be submitted yet. So from kernel
perspective they are ready for cpu access. Even though in fact they
are not in a consistent state from rendering perspective. I don't
really know a sane way to deal with that. Maybe the approach instead
should be a userspace level API (in libkms/libdrm?) to provide
abstraction for userspace access to buffers rather than dealing with
this at the kernel level.
Well, there's a reason GL has an explicit flush and extensions for sync
objects. It's to support such scenarios where the driver batches up gpu
commands before actually submitting them.
Hmm.. what about other non-GL APIs.. maybe vaapi/vdpau or similar?
(Or something that I haven't thought of.)
Also, recent gpus have all (or
shortly will grow) multiple execution pipelines, so it's also important
that you sync up with the right command stream. Syncing up with all of
them is generally frowned upon for obvious reasons ;-)
Well, I guess I am happy enough with something that is at least
functional. Usespace access would (I think) mainly be weird edge case
type stuff. But...
snip
On the topic of a coherency model for dmabuf, I think we need to look at
dma_buf_attachment_map/unmap (and also the mmap variants cpu_start and
cpu_finish or whatever they might get called) as barriers:
So after a dma_buf_map, all previsously completed dma operations (i.e.
unmap already called) and any cpu writes (i.e. cpu_finish called) will be
coherent. Similar rule holds for cpu access through the userspace mmap,
only writes completed before the cpu_start will show up.
Similar, writes done by the device are only guaranteed to show up after
the _unmap. Dito for cpu writes and cpu_finish.
In short we always need two function calls to denote the start/end of the
critical section.
Yup, this was exactly my assumption. But I guess it is better to spell it
out.
Thanks for the excellent discussion - it indeed is very good learning
for the relatively-inexperienced me :)
So, for the purpose of dma-buf framework, could I summarize the
following and rework accordingly?:
1. remove mmap() dma_buf_op [and mmap fop], and
Re: Hauppauge HVR-930C problems
On 12/07/11 13:56, Mauro Carvalho Chehab wrote: On 02-12-2011 17:41, Fredrik Lingvall wrote: Hi , I noticed that HVR 930C support was added 21-11-2011. I have build the new driver and installed the firmware but I'm struggling to get it working. 4) DVB scanning # w_scan -c NO -f c ... 602000: sr6900 (time: 10:32) (time: 10:33) signal ok: QAM_256 f = 602000 kHz S6900C999 This means that it detected a QAM_256 carrier, at 602000 kHz, with 6.900 Kbauds symbol rate. start_filter:1415: ERROR: ioctl DMX_SET_FILTER failed: 28 No space left on device -ENOSPC error is generally associated with the lack of USB bandwidth support. This means that the USB bus doesn't have enough free slots for the traffic required in order to support your stream. It generally means that your device is connected into a USB 1.1 hub or port. There are some new USB interfaces that are known to have troubles with the Linux USB 2.0 implementation, as they internally use some USB hubs. It could be your case, as the driver detects it on an USB 2.0 port: [90072.073832] em28xx: New device WinTV HVR-930C @ 480 Mbps (2040:1605, interface 0, class 0) Please do a: # mount usbfs /proc/bus/usb -t usbfs $ cat /proc/bus/usb/devices It should see you something like: T: Bus=08 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 29/900 us ( 3%), #Int= 2, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1d.2 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=08 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 D: Ver= 1.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=2101 ProdID=020f Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=10ms T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1d.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1d.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1a.2 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1a.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1a.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:00:1d.7 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00
Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module
Hi, On Wed, Dec 7, 2011 at 6:01 AM, Sylwester Nawrocki snj...@gmail.com wrote: On 12/06/2011 03:07 PM, Ming Lei wrote: Hi, Thanks for your review. On Tue, Dec 6, 2011 at 5:55 AM, Sylwester Nawrocki snj...@gmail.com wrote: Hi Ming, (I've pruned the Cc list, leaving just the mailing lists) On 12/02/2011 04:02 PM, Ming Lei wrote: This patch introduces one driver for face detection purpose. The driver is responsible for all v4l2 stuff, buffer management and other general things, and doesn't touch face detection hardware directly. Several interfaces are exported to low level drivers (such as the coming omap4 FD driver)which will communicate with face detection hw module. So the driver will make driving face detection hw modules more easy. I would hold on for a moment on implementing generic face detection module which is based on the V4L2 video device interface. We need to first define an API that would be also usable at sub-device interface level (http://linuxtv.org/downloads/v4l-dvb-apis/subdev.html). If we can define a good/stable enough APIs between kernel and user space, I think the patches can be merged first. For internal kernel APIs, we should allow it to evolve as new hardware comes or new features are to be introduced. I also don't see a problem in discussing it a bit more;) OK, fair enough, let's discuss it, :-) I understand the API you mentioned here should belong to kernel internal API, correct me if it is wrong. Yes, I meant the in kernel design, i.e. generic face detection kernel module and an OMAP4 FDIF driver. It makes lots of sense to separate common code in this way, maybe even when there would be only OMAP devices using it. Yes, that is the motivation of the generic FD module. I think we can focus on two use cases for the generic FD now: - one is to detect faces from user space image data - another one is to detect faces in image data generated from HW(SoC internal bus, resize hardware) For OMAP4 hardware, input data is always from physically continuous memory directly, so it is very easy to support the two cases. For the use case 2, if buffer copy is to be avoided, we can use the coming shared dma-buf[1] to pass the image buffer produced by other HW to FD hw directly. For other FD hardware, if it supports to detect faces in image data from physically continuous memory, I think the patch is OK to support it. If the FD hw doesn't support to detect faces from physically continuous memory, I have some questions: how does user space app to parse the FD result if application can't get the input image data? If user space can get image data, how does it connect the image data with FD result? and what standard v4l2 ways(v4l2_buffer?) can the app use to describe the image data? I'm sure now the Samsung devices won't fit in video output node based driver design. They read image data in different ways and also the FD result format is totally different. I think user space will need the FD result, so it is very important to define API to describe the FD result format to user space. And the input about your FD HW result format is certainly helpful to define the API. AFAICS OMAP4 FDIF processes only data stored in memory, thus it seems reasonable to use the videodev interface for passing data to the kernel from user space. But there might be face detection devices that accept data from other H/W modules, e.g. transferred through SoC internal data buses between image processing pipeline blocks. Thus any new interfaces need to be designed with such devices in mind. Also the face detection hardware block might now have an input DMA engine in it, the data could be fed from memory through some other subsystem (e.g. resize/colour converter). Then the driver for that subsystem would implement a video node. I think the direct input image or frame data to FD should be from memory no matter the actual data is from external H/W modules or input DMA because FD will take lot of time to detect faces in one image or frame and FD can't have so much memory to cache several images or frames data. Sorry, I cannot provide much details at the moment, but there exists hardware that reads data from internal SoC buses and even if it uses some sort of cache memory it doesn't necessarily have to be available for the user. Without some hardware background, it is not easy to give a generic FD module design. Still the FD result is associated with an image frame for such H/W, but not necessarily with a memory buffer queued by a user application. For user space application, it doesn't make sense to handle FD results only without image data. Even though there are other ways of input image data to FD, user space still need to know the image data, so it makes sense to associate FD result with a memory buffer. How long it approximately takes to process single image for OMAP4 FDIF ? See the link[2], and my test result is basically consistent with the
Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wednesday 07 December 2011, Semwal, Sumit wrote: Thanks for the excellent discussion - it indeed is very good learning for the relatively-inexperienced me :) So, for the purpose of dma-buf framework, could I summarize the following and rework accordingly?: 1. remove mmap() dma_buf_op [and mmap fop], and introduce cpu_start(), cpu_finish() ops to bracket cpu accesses to the buffer. Also add DMABUF_CPU_START / DMABUF_CPU_FINI IOCTLs? I think we'd be better off for now without the extra ioctls and just document that a shared buffer must not be exported to user space using mmap at all, to avoid those problems. Serialization between GPU and CPU is on a higher level than the dma_buf framework IMHO. 2. remove sg_sync* ops for now (and we'll see if we need to add them later if needed) Just removing the sg_sync_* operations is not enough. We have to make the decision whether we want to allow a) only coherent mappings of the buffer into kernel memory (requiring an extension to the dma_map_ops on ARM to not flush caches at map/unmap time) b) not allowing any in-kernel mappings (same requirement on ARM, also limits the usefulness of the dma_buf if we cannot access it from the kernel or from user space) c) only allowing streaming mappings, even if those are non-coherent (requiring strict serialization between CPU (in-kernel) and dma users of the buffer) This issue has to be solved or we get random data corruption. 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: [GIT PATCHES FOR 3.3] v4l: introduce selection API
On 14-11-2011 14:08, Tomasz Stanislawski wrote:
Hi Mauro,
This is the second 'pull-requested' version of the selection API. The patch-set
introduces new ioctls to V4L2 API for the configuration of the selection
rectangles like crop and compose areas.
Tomasz,
A way better than the previous pull request. The only missing issue is related
to the scaling. As I told you on IRC, the scale for it should be decided
in advance, as a latter change would break binaries compiled with old Kernel
versions.
So, we need to decide if the scale for cropping will be pixels or sub-pixels,
or to add some flag that would allow userspace to decide between them.
PS.: As I've reviewed already the other patches, please add a new patch with the
incremental change for scaling, as this saves my time to review the patches that
are already ok.
Thanks,
Mauro
Changelog:
- changed naming of constraints flags to form V4L2_SEL_FLAG_*
- changed naming of selection target to form V4L2_SEL_TGT_*
- size of PNG files in the documentation is greatly reduced
- fixes to handling of output queues for old cropping emulation
- VIDIOC_{S/G}_SELECTION for s5p-mixer accepts single- and multiplane buffers
as VIDIOC_{S/G}_CROP did
Best regards,
Tomasz Stanislawski
The following changes since commit e9eb0dadba932940f721f9d27544a7818b2fa1c5:
[media] V4L menu: add submenu for platform devices (2011-11-08 12:09:52 -0200)
are available in the git repository at:
git://git.infradead.org/users/kmpark/linux-samsung v4l-selection
Tomasz Stanislawski (5):
v4l: add support for selection api
doc: v4l: add binary images for selection API
doc: v4l: add documentation for selection API
v4l: emulate old crop API using extended crop/compose API
v4l: s5p-tv: mixer: add support for selection API
Documentation/DocBook/media/constraints.png.b64 | 59
Documentation/DocBook/media/selection.png.b64 | 206
Documentation/DocBook/media/v4l/common.xml | 2 +
Documentation/DocBook/media/v4l/compat.xml | 9 +
Documentation/DocBook/media/v4l/selection-api.xml | 327 +++
Documentation/DocBook/media/v4l/v4l2.xml | 1 +
.../DocBook/media/v4l/vidioc-g-selection.xml | 304 +
drivers/media/video/s5p-tv/mixer.h | 14 +-
drivers/media/video/s5p-tv/mixer_grp_layer.c | 157 +++--
drivers/media/video/s5p-tv/mixer_video.c | 342 +---
drivers/media/video/s5p-tv/mixer_vp_layer.c | 108 ---
drivers/media/video/v4l2-compat-ioctl32.c | 2 +
drivers/media/video/v4l2-ioctl.c | 116 +++-
include/linux/videodev2.h | 46 +++
include/media/v4l2-ioctl.h | 4 +
15 files changed, 1495 insertions(+), 202 deletions(-)
create mode 100644 Documentation/DocBook/media/constraints.png.b64
create mode 100644 Documentation/DocBook/media/selection.png.b64
create mode 100644 Documentation/DocBook/media/v4l/selection-api.xml
create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-selection.xml
--
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: [PATCH] omap3isp: video: Don't WARN() on unknown pixel formats
Hi Sakari,
On Thursday 01 December 2011 15:34:51 Sakari Ailus wrote:
On Thu, Dec 01, 2011 at 12:26:07AM +0100, Laurent Pinchart wrote:
On Wednesday 30 November 2011 09:35:38 Sakari Ailus wrote:
Laurent Pinchart wrote:
On Monday 28 November 2011 17:01:12 Sakari Ailus wrote:
On Mon, Nov 28, 2011 at 12:37:34PM +0100, Laurent Pinchart wrote:
When mapping from a V4L2 pixel format to a media bus format in the
VIDIOC_TRY_FMT and VIDIOC_S_FMT handlers, the requested format may
be unsupported by the driver. Return a hardcoded format instead of
WARN()ing in that case.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/ispvideo.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index d100072..ffe7ce9
100644 --- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -210,14 +210,14 @@ static void isp_video_pix_to_mbus(const
struct v4l2_pix_format *pix,
mbus-width = pix-width;
mbus-height = pix-height;
- for (i = 0; i ARRAY_SIZE(formats); ++i) {
+ /* Skip the last format in the loop so that it will be selected
if no
+ * match is found.
+ */
+ for (i = 0; i ARRAY_SIZE(formats) - 1; ++i) {
if (formats[i].pixelformat == pix-pixelformat)
break;
}
- if (WARN_ON(i == ARRAY_SIZE(formats)))
- return;
-
mbus-code = formats[i].code;
mbus-colorspace = pix-colorspace;
mbus-field = pix-field;
In case of setting or trying an invalid format, instead of selecting
a default format, shouldn't we leave the format unchanced --- the
current setting is valid after all.
TRY/SET operations must succeed. The format we select when an invalid
format is requested isn't specified. We could keep the current
format, but wouldn't that be more confusing for applications ? The
format they would get in response to a TRY/SET operation would then
potentially depend on the previous SET operations.
I don't think a change to something that has nothing to do what was
requested is better than not changing it. The application has requested
a particular format; changing it to something else isn't useful for the
application. And if the application would try more than invalid format
in a row, they both would yield to the same default format.
I would personally not change it.
I can agree with you for S_FMT, but I have more doubts about TRY_FMT.
Making TRY_FMT return the current format if the requested format is not
supported seems confusing to me. And if we make TRY_FMT return a fixed
format in that case, why not making S_FMT do the same ? :-)
I'd rather have it the other way around. :-)
TRY_FMT means can I use this format?. If the format isn't supported, the
driver answers no, you should use this other format instead. I think that
making that other format depend on the current format would be confusing.
For S_FMT I could agree with you. When asked please use this format, the
driver can answer I can't, so I'm going to use this other one instead. That
other format could be the current one. However, it might be confusing (and
more difficult to implement) to return different formats in TRY_FMT and
S_FMTfor the same input. That's why I'm inclined to make S_FMT report the same
format as TRY_FMT.
This being said, the TRY_FMT/S_FMT behaviour of the OMAP3 ISP driver is
currently a bit broken, and ENUMFMT isn't implemented. Fixing this properly
requires getting rid of our current multiple video queues per video node hack
and using CREATE_BUFS instead. I'll see if I can find time to fix that. I
would still like to integrate this patch (or something close) in the meantime
to remove the WARN_ON.
Hans; what do you think? (Cc Hans.)
What I can find in the spec is this:
When the application calls the VIDIOC_S_FMT ioctl with a pointer to a
v4l2_format structure the driver checks and adjusts the parameters
against hardware abilities.
I wonder how other drivers behave.
uvcvideo returns -EINVAL, which I think should be fixed.
The sensor drivers I wrote return a fixed format (this isn't strictly
S_FMT/TRY_FMT, but I think it's related).
For the mbus format it's a little bit different: if the format is something
else than what the user asked for, chances are high there's no use for it.
Cheers,
--
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 v2] omap3isp: Prevent pipelines that contain a crashed entity from starting
The OMAP3 ISP preview engine will violate the L4 bus protocol if we try
to write some of its internal registers after it failed to stop
properly. This generates an external abort on non-linefetch fault,
triggering a fatal kernel oops.
We can't always prevent preview engine stop failures (they can for
instance be caused by a sensor crash), but we can improve the system
reliability by refusing to start streaming on a pipeline that contains
the preview engine if it failed to stop. The driver will then eventually
reset the ISP (when all applications will have closed their file handles
related to OMAP3 ISP device nodes), making the ISP usable again.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/omap3isp/isp.c | 26 --
drivers/media/video/omap3isp/isp.h |3 ++-
2 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index b818cac..172e811 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -741,6 +741,16 @@ static int isp_pipeline_enable(struct isp_pipeline *pipe,
unsigned long flags;
int ret;
+ /* If the preview engine crashed it might not respond to read/write
+* operations on the L4 bus. This would result in a bus fault and a
+* kernel oops. Refuse to start streaming in that case. This check must
+* be performed before the loop below to avoid starting entities if the
+* pipeline won't start anyway (those entities would then likely fail to
+* stop, making the problem worse).
+*/
+ if (isp-crashed (1 isp-isp_prev.subdev.entity.id))
+ return -EIO;
+
spin_lock_irqsave(pipe-lock, flags);
pipe-state = ~(ISP_PIPELINE_IDLE_INPUT | ISP_PIPELINE_IDLE_OUTPUT);
spin_unlock_irqrestore(pipe-lock, flags);
@@ -881,13 +891,15 @@ static int isp_pipeline_disable(struct isp_pipeline *pipe)
if (ret) {
dev_info(isp-dev, Unable to stop %s\n, subdev-name);
+ /* If the entity failed to stopped, assume it has
+* crashed. Mark it as such, the ISP will be reset when
+* applications will release it.
+*/
+ isp-crashed |= 1 subdev-entity.id;
failure = -ETIMEDOUT;
}
}
- if (failure 0)
- isp-needs_reset = true;
-
return failure;
}
@@ -1071,6 +1083,7 @@ static int isp_reset(struct isp_device *isp)
udelay(1);
}
+ isp-crashed = 0;
return 0;
}
@@ -1500,10 +1513,11 @@ void omap3isp_put(struct isp_device *isp)
if (--isp-ref_count == 0) {
isp_disable_interrupts(isp);
isp_save_ctx(isp);
- if (isp-needs_reset) {
+ /* Reset the ISP if an entity has failed to stop. This is the
+* only way to recover from such conditions.
+*/
+ if (isp-crashed)
isp_reset(isp);
- isp-needs_reset = false;
- }
isp_disable_clocks(isp);
}
mutex_unlock(isp-isp_mutex);
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 705946e..6c3037a 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -145,6 +145,7 @@ struct isp_platform_callback {
* @raw_dmamask: Raw DMA mask
* @stat_lock: Spinlock for handling statistics
* @isp_mutex: Mutex for serializing requests to ISP.
+ * @crashed: Bitmask of crashed entities (indexed by entity ID)
* @has_context: Context has been saved at least once and can be restored.
* @ref_count: Reference count for handling multiple ISP requests.
* @cam_ick: Pointer to camera interface clock structure.
@@ -184,7 +185,7 @@ struct isp_device {
/* ISP Obj */
spinlock_t stat_lock; /* common lock for statistic drivers */
struct mutex isp_mutex; /* For handling ref_count field */
- bool needs_reset;
+ u32 crashed;
int has_context;
int ref_count;
unsigned int autoidle;
--
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] omap3isp: Mark next captured frame as faulty when an SBL overflow occurs
Instead of trying to propagate errors down the pipeline manually (and
failing to do so properly in all cases), flag SBL errors in the pipeline
to which the entity that triggered the error belongs, and use pipeline
error flags to mark buffers as faulty when completing them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/isp.c| 53 -
drivers/media/video/omap3isp/ispccdc.c|7 ++--
drivers/media/video/omap3isp/ispccdc.h|2 -
drivers/media/video/omap3isp/ispccp2.c| 20 ---
drivers/media/video/omap3isp/ispccp2.h|3 +-
drivers/media/video/omap3isp/ispcsi2.c| 18 --
drivers/media/video/omap3isp/ispcsi2.h|2 +-
drivers/media/video/omap3isp/isppreview.c |9 +
drivers/media/video/omap3isp/isppreview.h |2 -
drivers/media/video/omap3isp/ispresizer.c |7 +---
drivers/media/video/omap3isp/ispresizer.h |1 -
drivers/media/video/omap3isp/ispvideo.c | 13 +--
drivers/media/video/omap3isp/ispvideo.h |8 +++-
13 files changed, 68 insertions(+), 77 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 172e811..09874a7 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -410,6 +410,7 @@ static inline void isp_isr_dbg(struct isp_device *isp, u32
irqstatus)
static void isp_isr_sbl(struct isp_device *isp)
{
struct device *dev = isp-dev;
+ struct isp_pipeline *pipe;
u32 sbl_pcr;
/*
@@ -423,27 +424,38 @@ static void isp_isr_sbl(struct isp_device *isp)
if (sbl_pcr)
dev_dbg(dev, SBL overflow (PCR = 0x%08x)\n, sbl_pcr);
- if (sbl_pcr (ISPSBL_PCR_CCDC_WBL_OVF | ISPSBL_PCR_CSIA_WBL_OVF
-| ISPSBL_PCR_CSIB_WBL_OVF)) {
- isp-isp_ccdc.error = 1;
- if (isp-isp_ccdc.output CCDC_OUTPUT_PREVIEW)
- isp-isp_prev.error = 1;
- if (isp-isp_ccdc.output CCDC_OUTPUT_RESIZER)
- isp-isp_res.error = 1;
+ if (sbl_pcr ISPSBL_PCR_CSIB_WBL_OVF) {
+ pipe = to_isp_pipeline(isp-isp_ccp2.subdev.entity);
+ if (pipe != NULL)
+ pipe-error = true;
+ }
+
+ if (sbl_pcr (ISPSBL_PCR_CSIA_WBL_OVF)) {
+ pipe = to_isp_pipeline(isp-isp_csi2a.subdev.entity);
+ if (pipe != NULL)
+ pipe-error = true;
+ }
+
+ if (sbl_pcr ISPSBL_PCR_CCDC_WBL_OVF) {
+ pipe = to_isp_pipeline(isp-isp_ccdc.subdev.entity);
+ if (pipe != NULL)
+ pipe-error = true;
}
if (sbl_pcr ISPSBL_PCR_PRV_WBL_OVF) {
- isp-isp_prev.error = 1;
- if (isp-isp_res.input == RESIZER_INPUT_VP
- !(isp-isp_ccdc.output CCDC_OUTPUT_RESIZER))
- isp-isp_res.error = 1;
+ pipe = to_isp_pipeline(isp-isp_prev.subdev.entity);
+ if (pipe != NULL)
+ pipe-error = true;
}
if (sbl_pcr (ISPSBL_PCR_RSZ1_WBL_OVF
| ISPSBL_PCR_RSZ2_WBL_OVF
| ISPSBL_PCR_RSZ3_WBL_OVF
- | ISPSBL_PCR_RSZ4_WBL_OVF))
- isp-isp_res.error = 1;
+ | ISPSBL_PCR_RSZ4_WBL_OVF)) {
+ pipe = to_isp_pipeline(isp-isp_res.subdev.entity);
+ if (pipe != NULL)
+ pipe-error = true;
+ }
if (sbl_pcr ISPSBL_PCR_H3A_AF_WBL_OVF)
omap3isp_stat_sbl_overflow(isp-isp_af);
@@ -471,24 +483,17 @@ static irqreturn_t isp_isr(int irq, void *_isp)
IRQ0STATUS_HS_VS_IRQ;
struct isp_device *isp = _isp;
u32 irqstatus;
- int ret;
irqstatus = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
isp_reg_writel(isp, irqstatus, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
isp_isr_sbl(isp);
- if (irqstatus IRQ0STATUS_CSIA_IRQ) {
- ret = omap3isp_csi2_isr(isp-isp_csi2a);
- if (ret)
- isp-isp_ccdc.error = 1;
- }
+ if (irqstatus IRQ0STATUS_CSIA_IRQ)
+ omap3isp_csi2_isr(isp-isp_csi2a);
- if (irqstatus IRQ0STATUS_CSIB_IRQ) {
- ret = omap3isp_ccp2_isr(isp-isp_ccp2);
- if (ret)
- isp-isp_ccdc.error = 1;
- }
+ if (irqstatus IRQ0STATUS_CSIB_IRQ)
+ omap3isp_ccp2_isr(isp-isp_ccp2);
if (irqstatus IRQ0STATUS_CCDC_VD0_IRQ) {
if (isp-isp_ccdc.output CCDC_OUTPUT_PREVIEW)
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index a319281..18e96bd 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++
Re: [PATCH 0/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto: On 06-12-2011 12:33, Gianluca Gennari wrote: Hi All, I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components: - Empiatech em2880 USB bridge; - Zarlink zl10353 demodulator; - Xceive XC3028 tuner; For this device, the ZARLINK456 define is set to true so it is using the firmwares with type D2633 for the XC3028 tuner. I found out that: 1) the DTV7 firmware works fine in VHF band (bw=7MHz); 2) the DTV8 firmware works fine in UHF band (bw=8MHz); 3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not work at all in VHF band (bw=7MHz); In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and immediately lost. So the proposed patch forces a reload of the DTV7 firmware every time a 7MHz channel is requested. The only drawback is that channel change from VHF to UHF or viceversa is slightly slower. Devices using the D2620 firmwares are unaffected. Hi Gianluca, The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we do, we end by having troubles, as the issue is Country-dependent. For example, Australia requires a different firmware than Germany, due to the differences on the VHF/UHF bands. I prefer if you could work into a patch that would add some modprobe parameter to disable the current autodetection way, allowing to override the firmware used for VHF and UHF. Thanks, Mauro Hi Mauro, thanks for the feedback. Unfortunately I do not have any info on which kind of firmware is needed on other parts of the world. All I know is what is happening here in Italy, and what I can understand reading the code. I suppose my findings can be extended to the rest of Europe, and maybe Africa and Middle-East. Can you provide a reference about problems in other continents like Australia? Do you think a simple module parameters that allows to enable/disable the usage of the DTV78 firmware would do the trick? Eventually, do you agree that the default solution should be to DISABLE DTV78 firmware, since this seems to be the more robust solution, and let the user enable it through the kernel parameter if it is working in his country? Or do you prefer the other way around, so by default DTV78 firmware is enabled, and users with problems can disable it through the kernel module parameter? Best regards, Gianluca -- 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: DVB-T Muxes Germany / Berlin outdated, please update...
Your version of dvb-apps is older than three months (your output doesn't contradict [1]), tuning parameters haven't changed since then. Christoph [1] http://linuxtv.org/hg/dvb-apps/rev/7c4cee8c5709 2011/12/1 Barts Builder pe-buil...@gmx.de: Problem: The Muxes from 'Network by Location' of tvheadend are outdated for Germany / Berlin. tvheadend bugtracker answer: Please report outdated mux information the the linux-media mailing list. Tvheadend is taking the list from the dvb-apps initial tuning files as the basis for the list of dvb networks. Freqency:QAM:MHz:k-mode:MuxID 506000:16:8:8:773 522000:16:8:8:258 57:16:8:8:514 618000:64:?:?:775 658000:16:8:8:769 706000:64:8:8:772 754000:16:8:8:774 w_scan version 20101001 (compiled for DVB API 5.2) scan result 37 services (Ubuntu 11.04) Germany / Berlin - Das Erste;ARD:522000:I999B8C23D0M16T8G8Y0:T:27500:1401:1402=deu,1403=mis:1404:0:14:8468:258:0 rbb Berlin;ARD:522000:I999B8C23D0M16T8G8Y0:T:27500:1201:1202=ger:1204:0:12:8468:258:0 rbb Brandenburg;ARD:522000:I999B8C23D0M16T8G8Y0:T:27500:1201:1202=ger:1504:0:11:8468:258:0 Phoenix;ARD:522000:I999B8C23D0M16T8G8Y0:T:27500:1301:1302=ger:1304:0:13:8468:258:0 EinsExtra;ARD:522000:I999B8C23D0M16T8G8Y0:T:27500:1501:1502=ger:1404:0:15:8468:258:0 SAT.1;ProSiebenSat.1:658000:I999B8C23D0M16T8G8Y0:T:27500:385:386=deu:391:0:16408:8468:769:0 ProSieben;ProSiebenSat.1:658000:I999B8C23D0M16T8G8Y0:T:27500:305:306=deu:311:0:16403:8468:769:0 kabel eins;ProSiebenSat.1:658000:I999B8C23D0M16T8G8Y0:T:27500:161:162=deu:167:0:16394:8468:769:0 N24;ProSiebenSat.1:658000:I999B8C23D0M16T8G8Y0:T:27500:225:226=deu:231:0:16398:8468:769:0 WDR Köln;ARD:706000:I999B8C23D0M16T8G8Y0:T:27500:4193:4194=deu:4199:0:262:8468:772:0 Südwest BW/RP;ARD:706000:I999B8C23D0M16T8G8Y0:T:27500:3601:3602=deu:3607:0:225:8468:772:0 HSE24;MEDIA BROADCAST:706000:I999B8C23D0M16T8G8Y0:T:27500:49:50=deu:55:0:16387:8468:772:0 TELE 5;MEDIA BROADCAST:706000:I999B8C23D0M16T8G8Y0:T:27500:465:466=deu:471:0:16413:8468:772:0 Eurosport;Media Broadcast:754000:I999B8C23D0M16T8G8Y0:T:27500:577:578=ger:583:0:16420:8468:774:0 TV.Berlin;Media Broadcast:754000:I999B8C23D0M16T8G8Y0:T:27500:3121:3122=ger:3127:0:16579:8468:774:0 imusic TV;Media Broadcast:754000:I999B8C23D0M16T8G8Y0:T:27500:129:130=deu:0:0:16392:8468:774:0 sixx;ProSiebenSat.1:754000:I999B8C23D0M16T8G8Y0:T:27500:273:274=deu:279:0:16401:8468:774:0 Bayerisches FS;ARD:618000:I999B8C23D0M64T8G8Y0:T:27500:545:546=deu:551:0:34:8468:775:0 n-tv;RTL World:618000:I999B8C23D0M64T8G8Y0:T:27500:257:258=ger:263:0:16400:8468:775:0 QVC;MEDIA BROADCAST:618000:I999B8C23D0M64T8G8Y0:T:27500:321:322=ger:327:0:16404:8468:775:0 Channel 21/Euronews;MEDIA BROADCAST:618000:I999B8C23D0M64T8G8Y0:T:27500:593:594=deu,595=eng,596=fra:599:0:16421:8468:775:0 Bibel TV;MEDIA BROADCAST:618000:I999B8C23D0M64T8G8Y0:T:27500:673:674=ger:679:0:16426:8468:775:0 DAS VIERTE;BetaDigital:618000:I999B8C23D0M64T8G8Y0:T:27500:737:738=deu:743:0:16430:8468:775:0 sunshine live;BetaDigital:618000:I999B8C23D0M64T8G8Y0:T:27500:0:274=deu:0:0:24593:8468:775:0 ERF Radio;BetaDigital:618000:I999B8C23D0M64T8G8Y0:T:27500:0:290=deu:0:0:24594:8468:775:0 Radio Horeb;Eurociel:618000:I999B8C23D0M64T8G8Y0:T:27500:0:306=ger:0:0:24595:8468:775:0 the wave - relaxing radio;MEDIA BROADCAST:618000:I999B8C23D0M64T8G8Y0:T:27500:0:610=DEU:0:0:24614:8468:775:0 104.6 RTL;MEDIA BROADCAST:618000:I999B8C23D0M64T8G8Y0:T:27500:0:2082=DEU:0:0:26498:8468:775:0 Radio Paloma;MEDIA BROADCAST:618000:I999B8C23D0M64T8G8Y0:T:27500:0:2162=DEU:0:0:26503:8468:775:0 Spreeradio;MEDIA BROADCAST:618000:I999B8C23D0M64T8G8Y0:T:27500:0:2210=DEU:0:0:26506:8468:775:0 NDR FERNSEHEN;ARD:682000:I999B8C23D0M16T8G8Y0:T:27500:4881:4882=ger:4884:0:129:8468:257:0 MDR Sachsen;ARD:682000:I999B8C23D0M16T8G8Y0:T:27500:4897:4898=ger:4900:0:97:8468:257:0 arte;ARD:682000:I999B8C23D0M16T8G8Y0:T:27500:4913:4914=deu,4915=fra:4916:0:2:8468:257:0 ZDF;ZDFmobil:57:I999B8C23D0M16T8G4Y0:T:27500:545:546=deu,547=mis:551:0:514:8468:514:0 3sat;ZDFmobil:57:I999B8C23D0M16T8G4Y0:T:27500:561:562=deu,563=mis:567:0:515:8468:514:0 neo/KI.KA;ZDFmobil:57:I999B8C23D0M16T8G4Y0:T:27500:593:594=deu:599:0:517:8468:514:0 ZDFinfo;ZDFmobil:57:I999B8C23D0M16T8G4Y0:T:27500:577:578=deu:551:0:516:8468:514:0 -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote: On 06.12.2011 15:19, Mark Brown wrote: Your assertatation that applications should ignore the underlying transport (which seems to be a big part of what you're saying) isn't entirely in line with reality. Did you notice that we're talking about a very particular application? *sigh* VoIP really is totally off-topic. The B in DVB stands for broadcast. There's only one direction in which MPEG payload is to be sent (using RTP for example). You can't just re-encode the data on the fly without loss of information. This is pretty much exactly the case for VoIP some of the time (though obviously bidirectional use cases are rather common there's things like conferencing). I would really expect similar considerations to apply for video content as they certainly do in videoconferencing VoIP applications - if the application knows about the network it can tailor what it's doing to that network. For example, if it is using a network with a guaranteed bandwidth it can assume that bandwidth. If it knows something about the structure of the network it may be able to arrange to work around choke points. Depending on the situation even something lossy may be the answer - if it's the difference between working at all and not working then the cost may be worth 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: Hauppauge HVR-930C problems
On 07-12-2011 11:31, Fredrik Lingvall wrote: On 12/07/11 13:56, Mauro Carvalho Chehab wrote: On 02-12-2011 17:41, Fredrik Lingvall wrote: Hi , I noticed that HVR 930C support was added 21-11-2011. I have build the new driver and installed the firmware but I'm struggling to get it working. 4) DVB scanning # w_scan -c NO -f c ... 602000: sr6900 (time: 10:32) (time: 10:33) signal ok: QAM_256 f = 602000 kHz S6900C999 This means that it detected a QAM_256 carrier, at 602000 kHz, with 6.900 Kbauds symbol rate. start_filter:1415: ERROR: ioctl DMX_SET_FILTER failed: 28 No space left on device -ENOSPC error is generally associated with the lack of USB bandwidth support. This means that the USB bus doesn't have enough free slots for the traffic required in order to support your stream. It generally means that your device is connected into a USB 1.1 hub or port. There are some new USB interfaces that are known to have troubles with the Linux USB 2.0 implementation, as they internally use some USB hubs. It could be your case, as the driver detects it on an USB 2.0 port: [90072.073832] em28xx: New device WinTV HVR-930C @ 480 Mbps (2040:1605, interface 0, class 0) Please do a: # mount usbfs /proc/bus/usb -t usbfs $ cat /proc/bus/usb/devices It should see you something like: T: Bus=08 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 29/900 us ( 3%), #Int= 2, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1d.2 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=08 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 D: Ver= 1.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=2101 ProdID=020f Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=10ms T: Bus=07 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1d.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1d.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1a.2 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1a.1 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0001 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=:00:1a.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 3.01 S: Manufacturer=Linux 3.1.1-2.fc16.x86_64 ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=:00:1d.7 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00
Re: [PATCH] Update dvb-t scan frequencies for uk-Oxford, following digital switchover
Updated, thanks. Christoph 2011/11/20 Nick Burch v...@gagravarr.org: Hi All The scan channels file in dvb-apps/util/scan/dvb-t/uk-Oxford needs to be updated with the new frequencies for Oxford, UK, following the digital switchover here that happend a short time ago. Based on some public information, w_scan and some trial+error, I believe the patch below will update the file to the new frequencies Cheers Nick --- a/util/scan/dvb-t/uk-Oxford Fri Oct 07 01:26:04 2011 +0530 +++ b/util/scan/dvb-t/uk-Oxford Sun Nov 20 17:44:17 2011 + @@ -1,10 +1,26 @@ # UK, Oxford -# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html -# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html -# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 57800 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 85000 8MHz 2/3 NONE QAM64 2k 1/32 NONE +# +# Post-Switchover, found from a mixture of w_scan, trial+error +# and http://www.ukfree.tv/txdetail.php?a=SP567105 + +# Local Channels, C51, details still TBA T 713833000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 721833000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 69000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 53800 8MHz 3/4 NONE QAM16 2k 1/32 NONE + +# PSB1 BBC-A, C53+. Apparently 730.2 but actually looks to be 730.167 +T 730167000 8MHz 2/3 NONE QAM64 8k 1/32 NONE + +# ArqB (COM6), C55, 746.0 +T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE + +# PSB3 BBC-B, C57, 256QAM DVB-T2, TBA +# May well be wrong, needs a DVB-T2 tuner to be sure! +T 76200 8MHz 2/3 NONE QAM256 8k 1/32 NONE + +# ArqA (COM5), C59-, Apparently 777.8 but actually looks to be 777.833 +T 777833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE + +# PSB2, D3+4, C60-, Apparently 785.0 but actually looks to be 785.833 +T 785833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE + +# SDN (COM4), C62, 802.0 +T 80200 8MHz 2/3 NONE QAM64 8k 1/32 NONE -- 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: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 07.12.2011 14:49, Mark Brown wrote: On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote: On 06.12.2011 15:19, Mark Brown wrote: Your assertatation that applications should ignore the underlying transport (which seems to be a big part of what you're saying) isn't entirely in line with reality. Did you notice that we're talking about a very particular application? *sigh* VoIP really is totally off-topic. The B in DVB stands for broadcast. There's only one direction in which MPEG payload is to be sent (using RTP for example). You can't just re-encode the data on the fly without loss of information. This is pretty much exactly the case for VoIP some of the time (though obviously bidirectional use cases are rather common there's things like conferencing). I would really expect similar considerations to apply for video content as they certainly do in videoconferencing VoIP applications - if the application knows about the network it can tailor what it's doing to that network. For example, if it is using a network with a guaranteed bandwidth it can assume that bandwidth. If it knows something about the structure of the network it may be able to arrange to work around choke points. Depending on the situation even something lossy may be the answer - if it's the difference between working at all and not working then the cost may be worth it. Once and for all: We have *not* discussed a generic video streaming application. It's only, I repeat, only about accessing a remote DVB API tuner *as if it was local*. No data received from a satellite, cable or terrestrial DVB network shall be modified by this application! Virtually *every* user of it will use it in a LAN. It can't be so hard to understand. -- 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/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
On 07-12-2011 11:47, Gianluca Gennari wrote: Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto: On 06-12-2011 12:33, Gianluca Gennari wrote: Hi All, I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components: - Empiatech em2880 USB bridge; - Zarlink zl10353 demodulator; - Xceive XC3028 tuner; For this device, the ZARLINK456 define is set to true so it is using the firmwares with type D2633 for the XC3028 tuner. I found out that: 1) the DTV7 firmware works fine in VHF band (bw=7MHz); 2) the DTV8 firmware works fine in UHF band (bw=8MHz); 3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not work at all in VHF band (bw=7MHz); In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and immediately lost. So the proposed patch forces a reload of the DTV7 firmware every time a 7MHz channel is requested. The only drawback is that channel change from VHF to UHF or viceversa is slightly slower. Devices using the D2620 firmwares are unaffected. Hi Gianluca, The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we do, we end by having troubles, as the issue is Country-dependent. For example, Australia requires a different firmware than Germany, due to the differences on the VHF/UHF bands. I prefer if you could work into a patch that would add some modprobe parameter to disable the current autodetection way, allowing to override the firmware used for VHF and UHF. Thanks, Mauro Hi Mauro, thanks for the feedback. Unfortunately I do not have any info on which kind of firmware is needed on other parts of the world. All I know is what is happening here in Italy, and what I can understand reading the code. I suppose my findings can be extended to the rest of Europe, and maybe Africa and Middle-East. Even in Europe, there are some differences. Can you provide a reference about problems in other continents like Australia? All I know is from the constant reports at the ML from users. We used to have a developer in Australia, but he moved away, and it seems that he lost interest on DVB development, as we were unable to contact him ever since. Do you think a simple module parameters that allows to enable/disable the usage of the DTV78 firmware would do the trick? Perhaps one or two module parameters to allow forcing a certain firmware for VHF and UHF. Eventually, do you agree that the default solution should be to DISABLE DTV78 firmware, since this seems to be the more robust solution, and let the user enable it through the kernel parameter if it is working in his country? Or do you prefer the other way around, so by default DTV78 firmware is enabled, and users with problems can disable it through the kernel module parameter? AFAIK, DTV78 should be used in Spain and in Germany. Changing the current default doesn't look a good idea, as it will cause regressions, if the new way is not backward-compatible. Best regards, Gianluca -- 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: Hauppauge HVR-930C problems
On 12/07/11 14:55, Mauro Carvalho Chehab wrote: snip Bus 2 doesn't seem to do anything [Alloc= 0/800 us ( 0%)] while I'm scanning!? Scanning envolves 2 different things: 1) tuning and locking into a channel; 2) streaming and filtering, in order to seek for program tables inside the MPEG-TS. Step 1 uses USB control messages. Only at step 2, the device will use the USB ISOC packets. The USB core will see if is there enough bandwidth to reserve for ISOC transfers on that time (based on other traffic data), and submit the URB's (or return -ENOSPC otherwise). BTW: I'm running Gentoo x86_64 (amd64) on a Dell M2400 laptop with an SSD disk. Other hardware connected is a 200 GB disk using the eSata slot, a 1TB WD disk connected using another USB slot, a RME Multiface II soundcard using the expresscard slot. The external USB disk may be interfering, if it is also at bus 2. Also, some laptops use USB for some internal components like wireless. Please remove all other USB devices, disable wireless (if your device is USB) and try again. Regards, Mauro No there's nothing else at Bus 2 (I did a umount on the WD usb disk, cannot unplug devices since I'm logged in remotely right now), and Wireless is a pci device: lin-tv ~ # lspci 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) 00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07) 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03) 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) 00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03) 00:1f.2 RAID bus controller: Intel Corporation Mobile 82801 SATA RAID Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation Device 06fb (rev a1) 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04) 03:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21) 03:01.2 SD Host controller: Ricoh Co Ltd R5C843 MMC Host Controller (rev 11) 0c:00.0 Network controller: Intel Corporation PRO/Wireless 5300 AGN [Shiloh] Network Connection 0e:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP (rev 3c) lin-tv ~ # lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 413c:2513 Dell Computer Corp. internal USB Hub of E-Port Replicator Bus 001 Device 005: ID 0c45:63f8 Microdia Sonix Integrated Webcam Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 005 Device 002: ID 0a5c:5800 Broadcom Corp. BCM5880 Secure Applications Processor Bus 006 Device 002: ID 0451:2036 Texas Instruments, Inc. TUSB2036 Hub Bus 003 Device 003: ID 413c:8157 Dell Computer Corp. Integrated Keyboard Bus 003 Device 004: ID 413c:8158 Dell Computer Corp. Integrated Touchpad / Trackstick Bus 006 Device 004: ID 046d:c704 Logitech, Inc. diNovo Wireless Desktop Bus 003 Device 005: ID 413c:8156 Dell Computer Corp. Wireless 370 Bluetooth Mini-card Bus 002 Device 008: ID 2040:1605 Hauppauge Devices at Bus 2: lin-tv ~ # lsusb | grep Bus 002 Bus 002 Device 001: ID 1d6b:0002
Re: Initial tuning file for DVB-C network of Delta in the netherlands
Added, thanks. Christoph 2011/10/30 Hein Rigolo rig...@gmail.com: Here is an initial tuning file for the DVB-C network of Delta in the netherlands: # Initial Tuning file for nl-DELTA # This file only lists the main # frequency. You still need to do # a network scan to find other # transponders. # # C 40200 6875000 NONE QAM64 # Main Frequency Could this be added to dvb-apps list of initial tuning files? Hein -- 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: Hauppauge HVR-930C problems
On 07-12-2011 12:25, Fredrik Lingvall wrote: On 12/07/11 14:55, Mauro Carvalho Chehab wrote: snip Bus 2 doesn't seem to do anything [Alloc= 0/800 us ( 0%)] while I'm scanning!? Scanning envolves 2 different things: 1) tuning and locking into a channel; 2) streaming and filtering, in order to seek for program tables inside the MPEG-TS. Step 1 uses USB control messages. Only at step 2, the device will use the USB ISOC packets. The USB core will see if is there enough bandwidth to reserve for ISOC transfers on that time (based on other traffic data), and submit the URB's (or return -ENOSPC otherwise). BTW: I'm running Gentoo x86_64 (amd64) on a Dell M2400 laptop with an SSD disk. Other hardware connected is a 200 GB disk using the eSata slot, a 1TB WD disk connected using another USB slot, a RME Multiface II soundcard using the expresscard slot. The external USB disk may be interfering, if it is also at bus 2. Also, some laptops use USB for some internal components like wireless. Please remove all other USB devices, disable wireless (if your device is USB) and try again. Regards, Mauro No there's nothing else at Bus 2 (I did a umount on the WD usb disk, cannot unplug devices since I'm logged in remotely right now), and Wireless is a pci device: lin-tv ~ # lspci 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) 00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07) 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03) 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) 00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03) 00:1f.2 RAID bus controller: Intel Corporation Mobile 82801 SATA RAID Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation Device 06fb (rev a1) 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04) 03:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21) 03:01.2 SD Host controller: Ricoh Co Ltd R5C843 MMC Host Controller (rev 11) 0c:00.0 Network controller: Intel Corporation PRO/Wireless 5300 AGN [Shiloh] Network Connection 0e:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP (rev 3c) lin-tv ~ # lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 413c:2513 Dell Computer Corp. internal USB Hub of E-Port Replicator Bus 001 Device 005: ID 0c45:63f8 Microdia Sonix Integrated Webcam Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 005 Device 002: ID 0a5c:5800 Broadcom Corp. BCM5880 Secure Applications Processor Bus 006 Device 002: ID 0451:2036 Texas Instruments, Inc. TUSB2036 Hub Bus 003 Device 003: ID 413c:8157 Dell Computer Corp. Integrated Keyboard Bus 003 Device 004: ID 413c:8158 Dell Computer Corp. Integrated Touchpad / Trackstick Bus 006 Device 004: ID 046d:c704 Logitech, Inc. diNovo Wireless Desktop Bus 003 Device 005: ID 413c:8156 Dell Computer Corp. Wireless 370 Bluetooth Mini-card Bus 002 Device 008: ID 2040:1605 Hauppauge Devices at Bus 2: lin-tv ~ # lsusb | grep Bus 002 Bus 002 Device
Re: [PATCH 0/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
On 07-12-2011 12:53, Gianluca Gennari wrote:
Il 07/12/2011 15:20, Mauro Carvalho Chehab ha scritto:
On 07-12-2011 11:47, Gianluca Gennari wrote:
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
On 06-12-2011 12:33, Gianluca Gennari wrote:
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042).
This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;
For this device, the ZARLINK456 define is set to true so it is using
the
firmwares with type D2633 for the XC3028 tuner.
I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not
work at all in VHF band (bw=7MHz);
In fact, when the DTV78 firmware is loaded and I try to tune a VHF
channel, the frequency lock is ciclically acquired for a second and
immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every time a
7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or
viceversa is
slightly slower.
Devices using the D2620 firmwares are unaffected.
Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we
do,
we end by having troubles, as the issue is Country-dependent. For
example,
Australia requires a different firmware than Germany, due to the
differences
on the VHF/UHF bands.
I prefer if you could work into a patch that would add some modprobe
parameter
to disable the current autodetection way, allowing to override the
firmware
used for VHF and UHF.
Thanks,
Mauro
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on which
kind of firmware is needed on other parts of the world. All I know is
what is happening here in Italy, and what I can understand reading the
code. I suppose my findings can be extended to the rest of Europe, and
maybe Africa and Middle-East.
Even in Europe, there are some differences.
OK, so the validity of my findings are restricted to Italy.
Can you provide a reference about problems in other continents like
Australia?
All I know is from the constant reports at the ML from users. We used to
have a developer in Australia, but he moved away, and it seems that he lost
interest on DVB development, as we were unable to contact him ever since.
Do you think a simple module parameters that allows to enable/disable
the usage of the DTV78 firmware would do the trick?
Perhaps one or two module parameters to allow forcing a certain firmware
for
VHF and UHF.
Seems reasonable.
Eventually, do you agree that the default solution should be to DISABLE
DTV78 firmware, since this seems to be the more robust solution, and let
the user enable it through the kernel parameter if it is working in his
country? Or do you prefer the other way around, so by default DTV78
firmware is enabled, and users with problems can disable it through the
kernel module parameter?
AFAIK, DTV78 should be used in Spain and in Germany. Changing the current
default doesn't look a good idea, as it will cause regressions, if the new
way is not backward-compatible.
With the proposed patch DTV78 will be used in UHF band, while DTV7 in
VHF band. Will this make any difference in Spain or Germany?
Not sure. I don't live there ;)
What about a kernel parameter to specify the country?
Something like:
country={0-4}
DEFAULT=0,ITALY=1,GERMANY=2,SPAIN=3,AUSTRALIA=4
Then we could specify a well-defined behavior for each country, hiding
the firmware-related problems to the user (which will have problems
understanding parameters like force-DTV7-firmware-in-VHF-band).
All I need to know is what is the best behavior for each country.
That's the hardest part ;) We would need someone on each possible Country,
in order to test. Also, a per-country setup like that sucks. Ideally, the
driver should use the bandwidh and the other information at the standard DVB
parameters, in order to select the right firmware. This works with all other
frontends. Not sure what's broken on xc3028 design that it requires a
per-country
hack. I suspect that it is not a pure per-country hack, but it is also per
demod.
As we don't have much complains about it nowadays, I assume that the current
behavior is ok for most users. So, a parameter would be used only for those
where the default behavior doesn't work.
Btw, we already have a similar parameter to force the audio demodulation
standard,
due to the same reasons.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
Il 07/12/2011 16:45, Gianluca Gennari ha scritto:
Il 07/12/2011 16:05, Mauro Carvalho Chehab ha scritto:
On 07-12-2011 12:53, Gianluca Gennari wrote:
Il 07/12/2011 15:20, Mauro Carvalho Chehab ha scritto:
On 07-12-2011 11:47, Gianluca Gennari wrote:
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
On 06-12-2011 12:33, Gianluca Gennari wrote:
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042).
This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;
For this device, the ZARLINK456 define is set to true so it is using
the
firmwares with type D2633 for the XC3028 tuner.
I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it
doesn not
work at all in VHF band (bw=7MHz);
In fact, when the DTV78 firmware is loaded and I try to tune a VHF
channel, the frequency lock is ciclically acquired for a second and
immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every
time a
7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or
viceversa is
slightly slower.
Devices using the D2620 firmwares are unaffected.
Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we
do,
we end by having troubles, as the issue is Country-dependent. For
example,
Australia requires a different firmware than Germany, due to the
differences
on the VHF/UHF bands.
I prefer if you could work into a patch that would add some modprobe
parameter
to disable the current autodetection way, allowing to override the
firmware
used for VHF and UHF.
Thanks,
Mauro
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on which
kind of firmware is needed on other parts of the world. All I know is
what is happening here in Italy, and what I can understand reading the
code. I suppose my findings can be extended to the rest of Europe, and
maybe Africa and Middle-East.
Even in Europe, there are some differences.
OK, so the validity of my findings are restricted to Italy.
Can you provide a reference about problems in other continents like
Australia?
All I know is from the constant reports at the ML from users. We used to
have a developer in Australia, but he moved away, and it seems that
he lost
interest on DVB development, as we were unable to contact him ever
since.
Do you think a simple module parameters that allows to enable/disable
the usage of the DTV78 firmware would do the trick?
Perhaps one or two module parameters to allow forcing a certain firmware
for
VHF and UHF.
Seems reasonable.
Eventually, do you agree that the default solution should be to DISABLE
DTV78 firmware, since this seems to be the more robust solution, and
let
the user enable it through the kernel parameter if it is working in his
country? Or do you prefer the other way around, so by default DTV78
firmware is enabled, and users with problems can disable it through the
kernel module parameter?
AFAIK, DTV78 should be used in Spain and in Germany. Changing the
current
default doesn't look a good idea, as it will cause regressions, if
the new
way is not backward-compatible.
With the proposed patch DTV78 will be used in UHF band, while DTV7 in
VHF band. Will this make any difference in Spain or Germany?
Not sure. I don't live there ;)
What about a kernel parameter to specify the country?
Something like:
country={0-4}
DEFAULT=0,ITALY=1,GERMANY=2,SPAIN=3,AUSTRALIA=4
Then we could specify a well-defined behavior for each country, hiding
the firmware-related problems to the user (which will have problems
understanding parameters like force-DTV7-firmware-in-VHF-band).
All I need to know is what is the best behavior for each country.
That's the hardest part ;) We would need someone on each possible Country,
in order to test. Also, a per-country setup like that sucks. Ideally, the
driver should use the bandwidh and the other information at the standard
DVB
parameters, in order to select the right firmware. This works with all
other
frontends. Not sure what's broken on xc3028 design that it requires a
per-country
hack. I suspect that it is not a pure per-country hack, but it is also per
demod.
As we don't have much complains about it nowadays, I assume that the
current
behavior is ok for most users. So, a parameter would be used only for those
where the default behavior doesn't work.
Btw, we already have a similar parameter to force the audio demodulation
standard,
due to the same reasons.
Regards,
Mauro
Probably there are no complains about the firmware because in most
countries VHF is not used at all, or is only used for marginal TV
stations. In Italy instead the main DTT mux (RAI mux 1) is broadcasted
in VHF band for
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Wed, Dec 07, 2011 at 03:01:18PM +0100, Andreas Oberritter wrote: Once and for all: We have *not* discussed a generic video streaming application. It's only, I repeat, only about accessing a remote DVB API tuner *as if it was local*. No data received from a satellite, cable or terrestrial DVB network shall be modified by this application! Virtually *every* user of it will use it in a LAN. It can't be so hard to understand. You're talking about a purely software defined thing that goes in the kernel - it pretty much has to be able to scale to other applications even if some of the implementation is left for later. Once things like this get included in the kernel they become part of the ABI and having multiple specific things ends up being a recipie for confusion as users have to work out which of the options is most appropriate for their application. Really this feels like the pattern we've got with audio where we restrict the drivers to driving hardware and there's a userspace which wraps that and can also dispatch to a userspace implementation without applications worrying about it. Perhaps given the current entirely in kernel implementation a simple loopback in the style of FUSE which bounces the kernel APIs up to userspace for virtual drivers would make sense. -- 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/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
On 07-12-2011 13:51, Gianluca Gennari wrote:
Il 07/12/2011 16:45, Gianluca Gennari ha scritto:
Il 07/12/2011 16:05, Mauro Carvalho Chehab ha scritto:
On 07-12-2011 12:53, Gianluca Gennari wrote:
Il 07/12/2011 15:20, Mauro Carvalho Chehab ha scritto:
On 07-12-2011 11:47, Gianluca Gennari wrote:
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
On 06-12-2011 12:33, Gianluca Gennari wrote:
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042).
This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;
For this device, the ZARLINK456 define is set to true so it is using
the
firmwares with type D2633 for the XC3028 tuner.
I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it
doesn not
work at all in VHF band (bw=7MHz);
In fact, when the DTV78 firmware is loaded and I try to tune a VHF
channel, the frequency lock is ciclically acquired for a second and
immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every
time a
7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or
viceversa is
slightly slower.
Devices using the D2620 firmwares are unaffected.
Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we
do,
we end by having troubles, as the issue is Country-dependent. For
example,
Australia requires a different firmware than Germany, due to the
differences
on the VHF/UHF bands.
I prefer if you could work into a patch that would add some modprobe
parameter
to disable the current autodetection way, allowing to override the
firmware
used for VHF and UHF.
Thanks,
Mauro
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on which
kind of firmware is needed on other parts of the world. All I know is
what is happening here in Italy, and what I can understand reading the
code. I suppose my findings can be extended to the rest of Europe, and
maybe Africa and Middle-East.
Even in Europe, there are some differences.
OK, so the validity of my findings are restricted to Italy.
Can you provide a reference about problems in other continents like
Australia?
All I know is from the constant reports at the ML from users. We used to
have a developer in Australia, but he moved away, and it seems that
he lost
interest on DVB development, as we were unable to contact him ever
since.
Do you think a simple module parameters that allows to enable/disable
the usage of the DTV78 firmware would do the trick?
Perhaps one or two module parameters to allow forcing a certain firmware
for
VHF and UHF.
Seems reasonable.
Eventually, do you agree that the default solution should be to DISABLE
DTV78 firmware, since this seems to be the more robust solution, and
let
the user enable it through the kernel parameter if it is working in his
country? Or do you prefer the other way around, so by default DTV78
firmware is enabled, and users with problems can disable it through the
kernel module parameter?
AFAIK, DTV78 should be used in Spain and in Germany. Changing the
current
default doesn't look a good idea, as it will cause regressions, if
the new
way is not backward-compatible.
With the proposed patch DTV78 will be used in UHF band, while DTV7 in
VHF band. Will this make any difference in Spain or Germany?
Not sure. I don't live there ;)
What about a kernel parameter to specify the country?
Something like:
country={0-4}
DEFAULT=0,ITALY=1,GERMANY=2,SPAIN=3,AUSTRALIA=4
Then we could specify a well-defined behavior for each country, hiding
the firmware-related problems to the user (which will have problems
understanding parameters like force-DTV7-firmware-in-VHF-band).
All I need to know is what is the best behavior for each country.
That's the hardest part ;) We would need someone on each possible Country,
in order to test. Also, a per-country setup like that sucks. Ideally, the
driver should use the bandwidh and the other information at the standard
DVB
parameters, in order to select the right firmware. This works with all
other
frontends. Not sure what's broken on xc3028 design that it requires a
per-country
hack. I suspect that it is not a pure per-country hack, but it is also per
demod.
As we don't have much complains about it nowadays, I assume that the
current
behavior is ok for most users. So, a parameter would be used only for those
where the default behavior doesn't work.
Btw, we already have a similar parameter to force the audio demodulation
standard,
due to the same reasons.
Regards,
Mauro
Probably there are no complains about the firmware because in most
countries VHF is not used at all, or is only used for marginal TV
stations.
Makes sense. Well, it is not hard to detect VHF. If the DTV bandwidth is
properly filled, detecting between 8/7/6 MHz is
[PATCH v2] media: vb2: vmalloc-based allocator user pointer handling
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch adds support for user pointer memory buffers to vmalloc
videobuf2 allocator.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/video/videobuf2-vmalloc.c | 97 ---
1 files changed, 89 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index a3a8842..8843ad0 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -12,6 +12,7 @@
#include linux/module.h
#include linux/mm.h
+#include linux/sched.h
#include linux/slab.h
#include linux/vmalloc.h
@@ -20,7 +21,10 @@
struct vb2_vmalloc_buf {
void*vaddr;
+ struct page **pages;
+ int write;
unsigned long size;
+ unsigned intn_pages;
atomic_trefcount;
struct vb2_vmarea_handler handler;
};
@@ -42,14 +46,14 @@ static void *vb2_vmalloc_alloc(void *alloc_ctx, unsigned
long size)
buf-handler.arg = buf;
if (!buf-vaddr) {
- printk(KERN_ERR vmalloc of size %ld failed\n, buf-size);
+ pr_err(vmalloc of size %ld failed\n, buf-size);
kfree(buf);
return NULL;
}
atomic_inc(buf-refcount);
- printk(KERN_DEBUG Allocated vmalloc buffer of size %ld at vaddr=%p\n,
- buf-size, buf-vaddr);
+ pr_err(Allocated vmalloc buffer of size %ld at vaddr=%p\n, buf-size,
+ buf-vaddr);
return buf;
}
@@ -59,13 +63,87 @@ static void vb2_vmalloc_put(void *buf_priv)
struct vb2_vmalloc_buf *buf = buf_priv;
if (atomic_dec_and_test(buf-refcount)) {
- printk(KERN_DEBUG %s: Freeing vmalloc mem at vaddr=%p\n,
- __func__, buf-vaddr);
+ pr_debug(%s: Freeing vmalloc mem at vaddr=%p\n, __func__,
+buf-vaddr);
vfree(buf-vaddr);
kfree(buf);
}
}
+static void *vb2_vmalloc_get_userptr(void *alloc_ctx, unsigned long vaddr,
+unsigned long size, int write)
+{
+ struct vb2_vmalloc_buf *buf;
+
+ unsigned long first, last;
+ int n_pages_from_user, offset;
+
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ if (!buf)
+ return NULL;
+
+ buf-write = write;
+ offset = vaddr ~PAGE_MASK;
+ buf-size = size;
+
+ first = (vaddr PAGE_MASK) PAGE_SHIFT;
+ last = ((vaddr + size - 1) PAGE_MASK) PAGE_SHIFT;
+ buf-n_pages = last - first + 1;
+ buf-pages = kzalloc(buf-n_pages * sizeof(struct page *), GFP_KERNEL);
+ if (!buf-pages)
+ goto userptr_fail_pages_array_alloc;
+
+ /* current-mm-mmap_sem is taken by videobuf core */
+ n_pages_from_user = get_user_pages(current, current-mm,
+vaddr PAGE_MASK,
+buf-n_pages,
+write,
+1, /* force */
+buf-pages,
+NULL);
+ if (n_pages_from_user != buf-n_pages)
+ goto userptr_fail_get_user_pages;
+
+ buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1, PAGE_KERNEL);
+
+ if (!buf-vaddr)
+ goto userptr_fail_get_user_pages;
+
+ buf-vaddr += offset;
+ return buf;
+
+userptr_fail_get_user_pages:
+ pr_debug(get_user_pages requested/got: %d/%d]\n, n_pages_from_user,
+buf-n_pages);
+ while (--n_pages_from_user = 0)
+ put_page(buf-pages[n_pages_from_user]);
+ kfree(buf-pages);
+
+userptr_fail_pages_array_alloc:
+ kfree(buf);
+
+ return NULL;
+}
+
+static void vb2_vmalloc_put_userptr(void *buf_priv)
+{
+ struct vb2_vmalloc_buf *buf = buf_priv;
+
+ unsigned int i;
+ int offset = (unsigned long)buf-vaddr ~PAGE_MASK;
+
+ if (buf-vaddr)
+ vm_unmap_ram((const void *)((unsigned long)buf-vaddr - offset),
+buf-n_pages);
+ for (i = 0; i buf-n_pages; ++i) {
+ if (buf-write)
+ set_page_dirty_lock(buf-pages[i]);
+ put_page(buf-pages[i]);
+ }
+ kfree(buf-pages);
+ kfree(buf);
+}
+
static void *vb2_vmalloc_vaddr(void *buf_priv)
{
struct vb2_vmalloc_buf *buf = buf_priv;
@@ -73,7 +151,8 @@ static void *vb2_vmalloc_vaddr(void *buf_priv)
BUG_ON(!buf);
if (!buf-vaddr) {
- printk(KERN_ERR Address of
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 07.12.2011 17:10, Mark Brown wrote: a simple loopback in the style of FUSE which bounces the kernel APIs up to userspace for virtual drivers would make sense. That's exactly what vtunerc is. -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 07.12.2011 17:10, Mark Brown wrote: You're talking about a purely software defined thing that goes in the kernel - it pretty much has to be able to scale to other applications even if some of the implementation is left for later. Once things like this get included in the kernel they become part of the ABI and having multiple specific things ends up being a recipie for confusion as users have to work out which of the options is most appropriate for their application. And to repeat myself once more: No networking is to be perfomed by the kernel in vtunerc. -- 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/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
Il 07/12/2011 17:21, Mauro Carvalho Chehab ha scritto:
On 07-12-2011 13:51, Gianluca Gennari wrote:
Il 07/12/2011 16:45, Gianluca Gennari ha scritto:
Il 07/12/2011 16:05, Mauro Carvalho Chehab ha scritto:
On 07-12-2011 12:53, Gianluca Gennari wrote:
Il 07/12/2011 15:20, Mauro Carvalho Chehab ha scritto:
On 07-12-2011 11:47, Gianluca Gennari wrote:
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
On 06-12-2011 12:33, Gianluca Gennari wrote:
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042).
This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;
For this device, the ZARLINK456 define is set to true so it is
using
the
firmwares with type D2633 for the XC3028 tuner.
I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it
doesn not
work at all in VHF band (bw=7MHz);
In fact, when the DTV78 firmware is loaded and I try to tune a VHF
channel, the frequency lock is ciclically acquired for a second
and
immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every
time a
7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or
viceversa is
slightly slower.
Devices using the D2620 firmwares are unaffected.
Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter
what we
do,
we end by having troubles, as the issue is Country-dependent. For
example,
Australia requires a different firmware than Germany, due to the
differences
on the VHF/UHF bands.
I prefer if you could work into a patch that would add some
modprobe
parameter
to disable the current autodetection way, allowing to override
the
firmware
used for VHF and UHF.
Thanks,
Mauro
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on
which
kind of firmware is needed on other parts of the world. All I
know is
what is happening here in Italy, and what I can understand
reading the
code. I suppose my findings can be extended to the rest of
Europe, and
maybe Africa and Middle-East.
Even in Europe, there are some differences.
OK, so the validity of my findings are restricted to Italy.
Can you provide a reference about problems in other continents like
Australia?
All I know is from the constant reports at the ML from users. We
used to
have a developer in Australia, but he moved away, and it seems that
he lost
interest on DVB development, as we were unable to contact him ever
since.
Do you think a simple module parameters that allows to
enable/disable
the usage of the DTV78 firmware would do the trick?
Perhaps one or two module parameters to allow forcing a certain
firmware
for
VHF and UHF.
Seems reasonable.
Eventually, do you agree that the default solution should be to
DISABLE
DTV78 firmware, since this seems to be the more robust solution, and
let
the user enable it through the kernel parameter if it is working
in his
country? Or do you prefer the other way around, so by default DTV78
firmware is enabled, and users with problems can disable it
through the
kernel module parameter?
AFAIK, DTV78 should be used in Spain and in Germany. Changing the
current
default doesn't look a good idea, as it will cause regressions, if
the new
way is not backward-compatible.
With the proposed patch DTV78 will be used in UHF band, while DTV7 in
VHF band. Will this make any difference in Spain or Germany?
Not sure. I don't live there ;)
What about a kernel parameter to specify the country?
Something like:
country={0-4}
DEFAULT=0,ITALY=1,GERMANY=2,SPAIN=3,AUSTRALIA=4
Then we could specify a well-defined behavior for each country, hiding
the firmware-related problems to the user (which will have problems
understanding parameters like force-DTV7-firmware-in-VHF-band).
All I need to know is what is the best behavior for each country.
That's the hardest part ;) We would need someone on each possible
Country,
in order to test. Also, a per-country setup like that sucks.
Ideally, the
driver should use the bandwidh and the other information at the
standard
DVB
parameters, in order to select the right firmware. This works with all
other
frontends. Not sure what's broken on xc3028 design that it requires a
per-country
hack. I suspect that it is not a pure per-country hack, but it is
also per
demod.
As we don't have much complains about it nowadays, I assume that the
current
behavior is ok for most users. So, a parameter would be used only
for those
where the default behavior doesn't work.
Btw, we already have a similar parameter to force the audio
demodulation
standard,
due to the same reasons.
Regards,
Mauro
Probably there are no complains about the firmware because in most
countries VHF is not used at all, or
Re: [PATCH] omap3isp: video: Don't WARN() on unknown pixel formats
On Wed, Dec 07, 2011 at 02:44:11PM +0100, Laurent Pinchart wrote:
Hi Sakari,
Moi,
On Thursday 01 December 2011 15:34:51 Sakari Ailus wrote:
On Thu, Dec 01, 2011 at 12:26:07AM +0100, Laurent Pinchart wrote:
On Wednesday 30 November 2011 09:35:38 Sakari Ailus wrote:
Laurent Pinchart wrote:
On Monday 28 November 2011 17:01:12 Sakari Ailus wrote:
On Mon, Nov 28, 2011 at 12:37:34PM +0100, Laurent Pinchart wrote:
When mapping from a V4L2 pixel format to a media bus format in the
VIDIOC_TRY_FMT and VIDIOC_S_FMT handlers, the requested format may
be unsupported by the driver. Return a hardcoded format instead of
WARN()ing in that case.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/ispvideo.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index d100072..ffe7ce9
100644 --- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -210,14 +210,14 @@ static void isp_video_pix_to_mbus(const
struct v4l2_pix_format *pix,
mbus-width = pix-width;
mbus-height = pix-height;
- for (i = 0; i ARRAY_SIZE(formats); ++i) {
+ /* Skip the last format in the loop so that it will be selected
if no
+* match is found.
+*/
+ for (i = 0; i ARRAY_SIZE(formats) - 1; ++i) {
if (formats[i].pixelformat == pix-pixelformat)
break;
}
- if (WARN_ON(i == ARRAY_SIZE(formats)))
- return;
-
mbus-code = formats[i].code;
mbus-colorspace = pix-colorspace;
mbus-field = pix-field;
In case of setting or trying an invalid format, instead of selecting
a default format, shouldn't we leave the format unchanced --- the
current setting is valid after all.
TRY/SET operations must succeed. The format we select when an invalid
format is requested isn't specified. We could keep the current
format, but wouldn't that be more confusing for applications ? The
format they would get in response to a TRY/SET operation would then
potentially depend on the previous SET operations.
I don't think a change to something that has nothing to do what was
requested is better than not changing it. The application has requested
a particular format; changing it to something else isn't useful for the
application. And if the application would try more than invalid format
in a row, they both would yield to the same default format.
I would personally not change it.
I can agree with you for S_FMT, but I have more doubts about TRY_FMT.
Making TRY_FMT return the current format if the requested format is not
supported seems confusing to me. And if we make TRY_FMT return a fixed
format in that case, why not making S_FMT do the same ? :-)
I'd rather have it the other way around. :-)
TRY_FMT means can I use this format?. If the format isn't supported, the
driver answers no, you should use this other format instead. I think that
making that other format depend on the current format would be confusing.
Also ENUM_FMT will depend on the format configured on the pipeline. If the
sensor connected to the CCDC produces YUV, the CCDC video capture node
musn't advertise YUV formats either.
I'm not saying this interface should be used by regular V4L2 applications,
but the pipeline configuration library.
For S_FMT I could agree with you. When asked please use this format, the
driver can answer I can't, so I'm going to use this other one instead. That
other format could be the current one. However, it might be confusing (and
more difficult to implement) to return different formats in TRY_FMT and
S_FMTfor the same input. That's why I'm inclined to make S_FMT report the
same
format as TRY_FMT.
This being said, the TRY_FMT/S_FMT behaviour of the OMAP3 ISP driver is
currently a bit broken, and ENUMFMT isn't implemented. Fixing this properly
requires getting rid of our current multiple video queues per video node hack
and using CREATE_BUFS instead. I'll see if I can find time to fix that. I
would still like to integrate this patch (or something close) in the meantime
to remove the WARN_ON.
Indeed, choosing a format, whether we agree on which one it should be or
not, is a big improvement over the current kernel warning. I reckon this is
might not reflect what the driver _should_ implement. It will take some time
to get the final answer for that, I guess. This is still one possible
solution.
So,
Acked-by: Sakari Ailus sakari.ai...@iki.fi
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe
Re: [PATCH] as3645a: Handle power on errors when registering the device
Hi Laurent, On Wed, Dec 07, 2011 at 02:27:40PM +0100, Laurent Pinchart wrote: Return an error in the registered handler if the device can't be powered on. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks for the patch! Acked-by: Sakari Ailus sakari.ai...@iki.fi -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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: ERRORS
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:Wed Dec 7 19:00:19 CET 2011 git hash:2a887d27708a4f9f3b5ad8258f9e19a150b58f03 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
On 07-12-2011 15:25, Gianluca Gennari wrote:
Il 07/12/2011 17:21, Mauro Carvalho Chehab ha scritto:
On 07-12-2011 13:51, Gianluca Gennari wrote:
Il 07/12/2011 16:45, Gianluca Gennari ha scritto:
Il 07/12/2011 16:05, Mauro Carvalho Chehab ha scritto:
On 07-12-2011 12:53, Gianluca Gennari wrote:
Il 07/12/2011 15:20, Mauro Carvalho Chehab ha scritto:
On 07-12-2011 11:47, Gianluca Gennari wrote:
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
On 06-12-2011 12:33, Gianluca Gennari wrote:
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042).
This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;
For this device, the ZARLINK456 define is set to true so it is
using
the
firmwares with type D2633 for the XC3028 tuner.
I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it
doesn not
work at all in VHF band (bw=7MHz);
In fact, when the DTV78 firmware is loaded and I try to tune a VHF
channel, the frequency lock is ciclically acquired for a second
and
immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every
time a
7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or
viceversa is
slightly slower.
Devices using the D2620 firmwares are unaffected.
Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter
what we
do,
we end by having troubles, as the issue is Country-dependent. For
example,
Australia requires a different firmware than Germany, due to the
differences
on the VHF/UHF bands.
I prefer if you could work into a patch that would add some
modprobe
parameter
to disable the current autodetection way, allowing to override
the
firmware
used for VHF and UHF.
Thanks,
Mauro
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on
which
kind of firmware is needed on other parts of the world. All I
know is
what is happening here in Italy, and what I can understand
reading the
code. I suppose my findings can be extended to the rest of
Europe, and
maybe Africa and Middle-East.
Even in Europe, there are some differences.
OK, so the validity of my findings are restricted to Italy.
Can you provide a reference about problems in other continents like
Australia?
All I know is from the constant reports at the ML from users. We
used to
have a developer in Australia, but he moved away, and it seems that
he lost
interest on DVB development, as we were unable to contact him ever
since.
Do you think a simple module parameters that allows to
enable/disable
the usage of the DTV78 firmware would do the trick?
Perhaps one or two module parameters to allow forcing a certain
firmware
for
VHF and UHF.
Seems reasonable.
Eventually, do you agree that the default solution should be to
DISABLE
DTV78 firmware, since this seems to be the more robust solution, and
let
the user enable it through the kernel parameter if it is working
in his
country? Or do you prefer the other way around, so by default DTV78
firmware is enabled, and users with problems can disable it
through the
kernel module parameter?
AFAIK, DTV78 should be used in Spain and in Germany. Changing the
current
default doesn't look a good idea, as it will cause regressions, if
the new
way is not backward-compatible.
With the proposed patch DTV78 will be used in UHF band, while DTV7 in
VHF band. Will this make any difference in Spain or Germany?
Not sure. I don't live there ;)
What about a kernel parameter to specify the country?
Something like:
country={0-4}
DEFAULT=0,ITALY=1,GERMANY=2,SPAIN=3,AUSTRALIA=4
Then we could specify a well-defined behavior for each country, hiding
the firmware-related problems to the user (which will have problems
understanding parameters like force-DTV7-firmware-in-VHF-band).
All I need to know is what is the best behavior for each country.
That's the hardest part ;) We would need someone on each possible
Country,
in order to test. Also, a per-country setup like that sucks.
Ideally, the
driver should use the bandwidh and the other information at the
standard
DVB
parameters, in order to select the right firmware. This works with all
other
frontends. Not sure what's broken on xc3028 design that it requires a
per-country
hack. I suspect that it is not a pure per-country hack, but it is
also per
demod.
As we don't have much complains about it nowadays, I assume that the
current
behavior is ok for most users. So, a parameter would be used only
for those
where the default behavior doesn't work.
Btw, we already have a similar parameter to force the audio
demodulation
standard,
due to the same reasons.
Regards,
Mauro
Probably there are no complains about the firmware because in most
countries VHF is not used at all, or is only used for marginal TV
stations.
Makes sense. Well,
Re: dvb_usb_vp7045 regression after upgrading from 2.6.39.4 to 3.1.1
Did a few more tests. The tuning problems with my USB DVB-t card also show with kernel 3.0.9 and 3.1.4. If I boot into 2.6.39.4 the card still works flawlessly as before. All the kernels tested were built with the same kernel .config (plus changes introduced by 'yes |make oldconfig'). So I'd say this regression is real. Is there anything else I can do to help diagnose the problem? Should this report go into kernel.org bugzilla? cheers, David David == David Kuehling dvdkh...@gmx.de writes: Hi, after upgrading from 2.6.39.4 to 3.1.1., my usb dvb-t receiver started having tuning problems. Tuning with 'tzap' now randomly fails, as does 'scan'. Of course I cannot rule out that the hardware is starting to wear down, or that there are problems on the transmission side, but these problems started after upgrading my kernel, so I thought I'd ask here. Googeling for any changes, I so far only found this commit that affects the vp7045 driver: http://patchwork.linuxtv.org/patch/258/ (committed as f2685ef0fbc5fff0a8f1cdc204bf37ab0c9a04a7) This is the output I get from 'tzap' when it fails: __ using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/home/spock/.tzap/channels.conf' tuning to 61800 Hz video pid 0x0221, audio pid 0x0222 status 00 | signal 5f00 | snr | ber 00ff | unc | status 1f | signal | snr | ber 00ff | unc | FE_HAS_LOCK status 1f | signal | snr | ber 00ff | unc | FE_HAS_LOCK [..] __ or sometimes I get this: __ [..] status 00 | signal 3000 | snr a0a0 | ber | unc | status 00 | signal 3000 | snr | ber | unc | status 00 | signal e146 | snr a0a0 | ber | unc | status 00 | signal f14a | snr | ber | unc | status 00 | signal 2154 | snr a0a0 | ber | unc | status 00 | signal c141 | snr | ber | unc | status 00 | signal f14c | snr a0a0 | ber | unc | status 00 | signal f133 | snr | ber | unc | [..] __ This is the output I get from 'scan', when it fails: __ scanning /usr/local/share/dvb/dvb-t/de-Berlin using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 50600 0 2 9 1 1 2 0 initial transponder 52200 0 2 9 1 1 2 0 initial transponder 57000 0 2 9 1 1 3 0 initial transponder 61800 0 2 9 3 1 2 0 initial transponder 65800 0 2 9 1 1 2 0 initial transponder 68200 0 2 9 1 1 2 0 initial transponder 70600 0 2 9 1 1 2 0 initial transponder 75400 0 2 9 1 1 2 0 initial transponder 77800 0 2 9 1 1 2 0 tune to: 50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x ARNING: filter timeout pid 0x0010 tune to: 52200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 tune to: 57000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 [..] __ (same 3 messages about filter timeout repeating for all transponders) This is the 3.1.1 kernel log when the receiver is plugged in: __ [ 178.48] usb 1-2: new high speed USB device number 4 using ehci_hcd [ 178.612000] usb 1-2: New USB device found, idVendor=13d3, idProduct=3205 [ 178.612000] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 180.588000] IR NEC protocol handler initialized [ 180.624000] IR RC5(x) protocol handler initialized [ 180.68] IR RC6 protocol handler initialized [ 180.724000] IR JVC protocol handler initialized [ 180.764000] IR Sony protocol handler initialized [ 180.828000] IR MCE Keyboard/mouse protocol handler initialized [ 180.884000] dvb-usb: found a 'Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox II)' in cold state, will try to load a firmware [ 180.904000] lirc_dev: IR Remote Control driver registered, major 251 [ 180.904000] IR LIRC bridge handler initialized [ 181.02] dvb-usb: downloading firmware from file 'dvb-usb-vp7045-01.fw' [ 181.104000] usbcore: registered new interface driver dvb_usb_vp7045 [ 181.104000] usb 1-2: USB disconnect, device number 4 [ 181.104000] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. [ 182.86] usb 1-2: new high speed USB device number 5 using ehci_hcd [ 182.992000] usb 1-2: New USB device found, idVendor=13d3, idProduct=3206 [ 182.992000] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 182.992000] usb 1-2: Product: VP-7045 [ 182.992000] usb 1-2:
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 12/07/2011 08:01 AM, Andreas Oberritter wrote: On 07.12.2011 14:49, Mark Brown wrote: On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote: On 06.12.2011 15:19, Mark Brown wrote: Your assertatation that applications should ignore the underlying transport (which seems to be a big part of what you're saying) isn't entirely in line with reality. Did you notice that we're talking about a very particular application? *sigh* VoIP really is totally off-topic. The B in DVB stands for broadcast. There's only one direction in which MPEG payload is to be sent (using RTP for example). You can't just re-encode the data on the fly without loss of information. This is pretty much exactly the case for VoIP some of the time (though obviously bidirectional use cases are rather common there's things like conferencing). I would really expect similar considerations to apply for video content as they certainly do in videoconferencing VoIP applications - if the application knows about the network it can tailor what it's doing to that network. For example, if it is using a network with a guaranteed bandwidth it can assume that bandwidth. If it knows something about the structure of the network it may be able to arrange to work around choke points. Depending on the situation even something lossy may be the answer - if it's the difference between working at all and not working then the cost may be worth it. Once and for all: We have *not* discussed a generic video streaming application. It's only, I repeat, only about accessing a remote DVB API tuner *as if it was local*. No data received from a satellite, cable or terrestrial DVB network shall be modified by this application! Virtually *every* user of it will use it in a LAN. It can't be so hard to understand. -- 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 I tend to stay out of these discussions, since like a couple of others, I'm not a kernel developer (or hacker). However, I wanted to chime in with my two cents here. 1. I agree that it's not acceptable to NACK purely for philosophical reasons (except when it's a clear violation of a license--be that open source or closed source (since we don't want to open ourselves up to lawsuits). 2. In this case, there have been technical reasons provided. Granted the developers (and people who are pro-inclusion) don't feel those are justified, but they have been cited. 3. You'll catch more flies with honey than vinegar (in other words, fighting with the person(s) who maintain the project will most definitely *not* get your code included). 4 (and the reason I decided to chime in here). This email sums everything up. Mark is pointing out that someone may want to use this in a non LAN setting, and they may/will have problems due to the Internet (and their specific way of accessing it). Andreas is arguing that it's not the case. I have to side with Mark on this one, solely because if I knew that it would work, I'd use it to watch television when I'm traveling (as some places don't carry the same channels that I have at home). So, I would prove Mark's point. Andreas, you said that virtually EVERY (emphasis mine) user of it will use it on a LAN. Virtually implies almost all-- NOT ALL. So, unless there's some restriction in the application, which prevents it from being used over the Internet, you can't guarantee that Mark's issues aren't valid. If as HoP pointed out in another reply on this thread, there's no kernel patching required, then I suggest that you keep on developing it as a userspace application. There's no law/rule/anything that says you can't install your own driver in the kernel. It just won't be supported upstream. That just means more work for you, if you want the application to continue working in the future. Truthfully, that has it's upsides also. If you find out about a way to improve the transmission, you don't have to wait (and hope) that it gets included in the kernel. You can include it in your driver. Sorry for butting into this. You're free to flame or ignore me, as you choose. Have a great day:) Patrick. -- 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 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support
* Sergio Aguirre saagui...@ti.com [30 15:40]: Hi everyone, This is the second version of the OMAP4 ISS driver, now ported to the Media Controller framework AND supporting videobuf2 framework. I suggest you do a device tree only binding for new drivers. arch/arm/mach-omap2/board-4430sdp-camera.c| 221 arch/arm/mach-omap2/board-omap4panda-camera.c | 198 arch/arm/mach-omap2/devices.c | 40 + That leaves out most of the code above. Regards, Tony -- 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/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
2011/12/7 Mauro Carvalho Chehab mche...@redhat.com: snip Several channels in Italy are marked as if they are using 8MHz for VHF (the auto-Italy is the most weird one, as it defines all VHF frequencies with both 7MHz and 8MHz). Well, auto-Italy is a superset of the it-* files. For example T 17750 7MHz exists in some files (Modena, Montevergina) and T 17750 8MHz in others (Sassari), so both possibilities have to appear in auto-Italy (similar for other VHF frequencies, it simply doesn't seem to be regulated). There's nothing to fix there, auto-Italy exists exactly because of these irregularities. snip Christoph -- 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/2] [media] V4L: atmel-isi: add code to enable/disableISI_MCK clock
On Wed, Dec 07, 2011 at 06:12:52PM +0800, Wu, Josh wrote:
Hi, Russell King
On Wed, Dec 07, 2011 at 4:50 PM, Russell King wrote:
On Wed, Nov 30, 2011 at 06:06:43PM +0800, Josh Wu wrote:
+ /* Get ISI_MCK, provided by programmable clock or external clock
*/
+ isi-mck = clk_get(dev, isi_mck);
+ if (IS_ERR_OR_NULL(isi-mck)) {
This should be IS_ERR()
So it means the clk_get() will never return NULL even when clk structure
is NULL in clk lookup entry. Right?
It is not the drivers business to know whether NULL is valid or not.
clk_get() is defined to either return an error pointer, or a cookie
which the rest of the clk API must accept.
If an implementation decides that clk_get() can return NULL and deals
with that in the rest of the API (eg, to mean 'there is no clock but
don't fail for this') then drivers must not reject that.
If a driver rejects NULL then it is performing checks outside of the
definition of the clk API, and making assumptions about the nature of
valid cookies.
--
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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
2011/12/7 Patrick Dickey pdickeyb...@gmail.com: On 12/07/2011 08:01 AM, Andreas Oberritter wrote: On 07.12.2011 14:49, Mark Brown wrote: On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote: On 06.12.2011 15:19, Mark Brown wrote: Your assertatation that applications should ignore the underlying transport (which seems to be a big part of what you're saying) isn't entirely in line with reality. Did you notice that we're talking about a very particular application? *sigh* VoIP really is totally off-topic. The B in DVB stands for broadcast. There's only one direction in which MPEG payload is to be sent (using RTP for example). You can't just re-encode the data on the fly without loss of information. This is pretty much exactly the case for VoIP some of the time (though obviously bidirectional use cases are rather common there's things like conferencing). I would really expect similar considerations to apply for video content as they certainly do in videoconferencing VoIP applications - if the application knows about the network it can tailor what it's doing to that network. For example, if it is using a network with a guaranteed bandwidth it can assume that bandwidth. If it knows something about the structure of the network it may be able to arrange to work around choke points. Depending on the situation even something lossy may be the answer - if it's the difference between working at all and not working then the cost may be worth it. Once and for all: We have *not* discussed a generic video streaming application. It's only, I repeat, only about accessing a remote DVB API tuner *as if it was local*. No data received from a satellite, cable or terrestrial DVB network shall be modified by this application! Virtually *every* user of it will use it in a LAN. It can't be so hard to understand. -- 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 I tend to stay out of these discussions, since like a couple of others, I'm not a kernel developer (or hacker). However, I wanted to chime in with my two cents here. 1. I agree that it's not acceptable to NACK purely for philosophical reasons (except when it's a clear violation of a license--be that open source or closed source (since we don't want to open ourselves up to lawsuits). 2. In this case, there have been technical reasons provided. Granted the developers (and people who are pro-inclusion) don't feel those are justified, but they have been cited. 3. You'll catch more flies with honey than vinegar (in other words, fighting with the person(s) who maintain the project will most definitely *not* get your code included). Yes, that I think we all know. But some problem is that the arguments against it are very weak. Believe me I would prefer to work on all hints which kernel hackers gave me after code reviewing and not to be member of flamewar. 4 (and the reason I decided to chime in here). This email sums everything up. Mark is pointing out that someone may want to use this in a non LAN setting, and they may/will have problems due to the Internet (and their specific way of accessing it). Andreas is arguing that it's not the case. I have to side with Mark on this one, solely because if I knew that it would work, I'd use it to watch television when I'm traveling (as some places don't carry the same channels that I have at home). So, I would prove Mark's point. Some features are designed for LAN use. I think nobody wants to use SMBFS over Internet. But in LAN it works perfectly stable. Andreas, you said that virtually EVERY (emphasis mine) user of it will use it on a LAN. Virtually implies almost all-- NOT ALL. So, unless there's some restriction in the application, which prevents it from being used over the Internet, you can't guarantee that Mark's issues aren't valid. If as HoP pointed out in another reply on this thread, there's no kernel patching required, then I suggest that you keep on developing it as a userspace application. I guess you mean by developing like userspave app variant of development kernel driver out of tree. There's no law/rule/anything that says you can't install your own driver in the kernel. It just won't be supported upstream. That just means more work for you, if you want the application to continue working in the future. Truthfully, that has it's upsides also. If you find out about a way to improve the transmission, you don't have to wait (and hope) that it gets included in the kernel. You can include it in your driver. As you stated already - maintaining kernel-space code out of kernel tree is much difficult. If anybody did any change in internal API, then you have to catch it yourself, find the way to change your code accordingly. If it would be in kernel, then such job is required to be
Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 07.12.2011 22:48, Patrick Dickey wrote: 4 (and the reason I decided to chime in here). This email sums everything up. Mark is pointing out that someone may want to use this in a non LAN setting, and they may/will have problems due to the Internet (and their specific way of accessing it). Andreas is arguing that it's not the case. I'm sorry if I was unclear, but I'm not doing that. Contrary, I'm sure that people using dreamtuner (which uses vtunerc from userspace) over the Internet will run into problems if they can't provide the necessary bandwidth. What I'm trying to point out is that dreamtuner is not trying to solve these problems, because it specifically has been designed for a different purpose. I have to side with Mark on this one, solely because if I knew that it would work, I'd use it to watch television when I'm traveling (as some places don't carry the same channels that I have at home). Yes, if you knew. But you wouldn't, because when travelling, it's unlikely that you could guarantee the necessary bandwidth all the time. I'd highly recommend you and Mark to use a different solution than dreamtuner for your use cases. So, I would prove Mark's point. I wonder how. Andreas, you said that virtually EVERY (emphasis mine) user of it will use it on a LAN. Virtually implies almost all-- NOT ALL. So, unless there's some restriction in the application, which prevents it from being used over the Internet, you can't guarantee that Mark's issues aren't valid. It may or may not work for some people. There's no need to artificially restrict dreamtuner to hosts on a LAN (which would be impossible anyway). If as HoP pointed out in another reply on this thread, there's no kernel patching required, then I suggest that you keep on developing it as a userspace application. There's no law/rule/anything that says you can't install your own driver in the kernel. It just won't be supported upstream. That just means more work for you, if you want the application to continue working in the future. Truthfully, that has it's upsides also. If you find out about a way to improve the transmission, you don't have to wait (and hope) that it gets included in the kernel. You can include it in your driver. FWIW, It's HoP's code. I'm not developing it. Although you seem to have noticed that all networking happens in userspace, you're still discussing networking issues, which may or may not be issues of dreamtuner, but provably not of vtunerc, which just relays DVB driver calls to userspace. Since the topic is about the inclusion of vtunerc, not dreamtuner, such stuff really is totally off-topic, but unfortunately got brought up again and again. You don't drive a formula one car or a truck if you want to have a picnic with your family, do you? I guess you'd rather choose the right tool for this task. So should you do if you want to stream television over the net. People complaining that they can't transport their family in a formula one car don't help anybody. Still both formula one cars and trucks may be useful for other purposes. You're free to replace dreamtuner with your superior tool solving all of Mark's issues, even without the need to change vtunerc. So far many people jumped into this discussion, but virtually(!) nobody took the time to understand what vtunerc actually does by looking at the code or at the various links HoP provided. Regards, Andreas -- 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
media_build script and Scientific Linux 6 / CentOS 6 / RHEL 6
I used the media_build script to build modules for the Scientific Linux 6 distro which is, I understand, one of the near-clones of RHEL 6, which are expected to have a working life of several years. My kernel version, with security updates, is currently 2.6.32-131.21.1.el6.i686 The build needed utilities that I did not have installed; the script provided their names but apologised for its inability to identify the packages that would provide them because it did not recognise the distro. This list is in response to its invitation to submit details. Utility:lsdiff Package name: patchutils Repo: SL6 Utility:Digest::SHA Package name: perl-Digest-SHA Repo: SL6 security updates Utility:Proc::ProcessTable Package name: perl-Proc-ProcessTable Repo: SL6 epel After installing these, and the kernel-devel package, the build completed and I have been able to bring into service a usb device that had resisted my earlier efforts on the nominally more up-to-date Fedora 14. dmesg identifies it as a 'KWorld UB499-2T T09(IT9137)' and some characteristics that I see are not mentioned on its wiki page. I'll report on that separately, but there's a narrative account here: http://www.mail-archive.com/atrpms-users@atrpms.net/msg09417.html Thanks! John Pilkington -- 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/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
Il 07/12/2011 22:54, Christoph Pfister ha scritto: 2011/12/7 Mauro Carvalho Chehab mche...@redhat.com: snip Several channels in Italy are marked as if they are using 8MHz for VHF (the auto-Italy is the most weird one, as it defines all VHF frequencies with both 7MHz and 8MHz). Well, auto-Italy is a superset of the it-* files. For example T 17750 7MHz exists in some files (Modena, Montevergina) and T 17750 8MHz in others (Sassari), so both possibilities have to appear in auto-Italy (similar for other VHF frequencies, it simply doesn't seem to be regulated). There's nothing to fix there, auto-Italy exists exactly because of these irregularities. snip Christoph Hi Christoph, since June 2009 all VHF channels in Italy use the European canalization, which means there is no 8 MHz VHF channel anymore. The data you have are outdated. If you need some reliable reference to know what is broadcasted in Italy, the best available source is this amatory website: http://www.otgtv.it/index2.html It is maniacally maintained by a single person, which is a real enthusiast of TV broadcasting and has access to reliable first-hand informations. There are also a few institutional websites, but they can not compete with this site in terms of accuracy. The auto-Italy table for DVB-T should be just: VHF: channels 5-12 with 7 MHz bandwidth; UHF: channels 21-69 with 8 MHZ bandwidth; The last 6 regions will switch-off analog broadcasting in the first half of 2012 (Abruzzo, Molise, Puglia, Basilicata, Calabria, Sicilia). Until then, there are a few analog channels using some weird frequency table, but all digital multiplexes are already converted to the new European frequency table. Best, Gianluca -- 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/2] [media] V4L: atmel-isi: add code toenable/disableISI_MCK clock
On Thursday, December 08, 2011 6:40AM, Russell King wrote:
On Wed, Dec 07, 2011 at 06:12:52PM +0800, Wu, Josh wrote:
Hi, Russell King
On Wed, Dec 07, 2011 at 4:50 PM, Russell King wrote:
On Wed, Nov 30, 2011 at 06:06:43PM +0800, Josh Wu wrote:
+ /* Get ISI_MCK, provided by programmable clock or external clock
*/
+ isi-mck = clk_get(dev, isi_mck);
+ if (IS_ERR_OR_NULL(isi-mck)) {
This should be IS_ERR()
So it means the clk_get() will never return NULL even when clk
structure
is NULL in clk lookup entry. Right?
It is not the drivers business to know whether NULL is valid or not.
clk_get() is defined to either return an error pointer, or a cookie
which the rest of the clk API must accept.
If an implementation decides that clk_get() can return NULL and deals
with that in the rest of the API (eg, to mean 'there is no clock but
don't fail for this') then drivers must not reject that.
If a driver rejects NULL then it is performing checks outside of the
definition of the clk API, and making assumptions about the nature of
valid cookies.
Thanks for the feedback. I will send v3 patch which will not check the
null return value.
Best Regards,
Josh Wu
--
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] [media] omap3isp: fix compilation of ispvideo.c
On Wed, Nov 23, 2011 at 3:53 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Sunday 20 November 2011 17:54:26 Dmitry Artamonow wrote: Fix following build error by explicitely including linux/module.h header file. CC drivers/media/video/omap3isp/ispvideo.o drivers/media/video/omap3isp/ispvideo.c:1267: error: 'THIS_MODULE' undeclared here (not in a function) make[4]: *** [drivers/media/video/omap3isp/ispvideo.o] Error 1 make[3]: *** [drivers/media/video/omap3isp] Error 2 make[2]: *** [drivers/media/video] Error 2 make[1]: *** [drivers/media] Error 2 make: *** [drivers] Error 2 Signed-off-by: Dmitry Artamonow mad_s...@inbox.ru Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro, can you pick this for v3.2, or would you like me to send a pull request ? Folks, was this one picked up by anyone ? We seem to still have this issue in mainline (at least in rc4). Thanks, Ohad. -- 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 3.3] v4l: add s5p-jpeg driver
Hi Mauro, It looks that the review process for s5p-jpeg driver has been finally finished and all the suggestions have been applied to the driver. I would ask You to pull the code to the for-v3.3 kernel tree. This driver depends on the selection api extension, which merge has been requested in '[GIT PATCHES FOR 3.3] v4l: introduce selection API' thread. Best regards, Marek Szyprowski The following changes since commit 2a887d27708a4f9f3b5ad8258f9e19a150b58f03: [media] tm6000: fix OOPS at tm6000_ir_int_stop() and tm6000_ir_int_start() (2011-11-30 16:49:45 -0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung s5p-jpeg Andrzej Pietrasiewicz (1): Exynos4 JPEG codec v4l2 driver drivers/media/video/Kconfig |8 + drivers/media/video/Makefile |1 + drivers/media/video/s5p-jpeg/Makefile|2 + drivers/media/video/s5p-jpeg/jpeg-core.c | 1481 ++ drivers/media/video/s5p-jpeg/jpeg-core.h | 143 +++ drivers/media/video/s5p-jpeg/jpeg-hw.h | 353 +++ drivers/media/video/s5p-jpeg/jpeg-regs.h | 170 7 files changed, 2158 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s5p-jpeg/Makefile create mode 100644 drivers/media/video/s5p-jpeg/jpeg-core.c create mode 100644 drivers/media/video/s5p-jpeg/jpeg-core.h create mode 100644 drivers/media/video/s5p-jpeg/jpeg-hw.h create mode 100644 drivers/media/video/s5p-jpeg/jpeg-regs.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
