Re: [PATCH v4] media: v4l2-ctrls: add control for dpcm predictor
Hi Sakari, Thanks for the review. On Wednesday 05 September 2012 12:42 AM, Sakari Ailus wrote: > Hi Prabhakar, > > Thanks for the patch. I've got a few comments below. > > On Tue, Sep 04, 2012 at 11:07:52AM +0530, Prabhakar Lad wrote: >> From: Lad, Prabhakar >> >> add V4L2_CID_DPCM_PREDICTOR control of type menu, which >> determines the dpcm predictor. The predictor can be either >> simple or advanced. >> >> Signed-off-by: Lad, Prabhakar >> Signed-off-by: Manjunath Hadli >> Acked-by: Hans Verkuil >> Reviewed-by: Sylwester Nawrocki >> Cc: Sakari Ailus >> Cc: Laurent Pinchart >> Cc: Mauro Carvalho Chehab >> Cc: Hans de Goede >> Cc: Kyungmin Park >> Cc: Rob Landley >> --- >> This patches has one checkpatch warning for line over >> 80 characters altough it can be avoided I have kept it >> for consistency. >> >> Changes for v4: >> 1: Aligned the description to fit appropriately in the >> para tag, pointed by Sylwester. >> >> Changes for v3: >> 1: Added better explanation for DPCM, pointed by Hans. >> >> Changes for v2: >> 1: Added documentaion in controls.xml pointed by Sylwester. >> 2: Chnaged V4L2_DPCM_PREDICTOR_ADVANCE to V4L2_DPCM_PREDICTOR_ADVANCED >>pointed by Sakari. >> >> Documentation/DocBook/media/v4l/controls.xml | 46 >> +- >> drivers/media/v4l2-core/v4l2-ctrls.c |9 + >> include/linux/videodev2.h|5 +++ >> 3 files changed, 59 insertions(+), 1 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/controls.xml >> b/Documentation/DocBook/media/v4l/controls.xml >> index 93b9c68..ad873ea 100644 >> --- a/Documentation/DocBook/media/v4l/controls.xml >> +++ b/Documentation/DocBook/media/v4l/controls.xml >> @@ -4267,7 +4267,51 @@ interface and may change in the future. >> pixels / second. >> >> >> - >> + >> +> spanname="id">V4L2_CID_DPCM_PREDICTOR >> +menu >> + >> + >> + Differential pulse-code modulation (DPCM) >> is a signal >> +encoder that uses the baseline of pulse-code modulation (PCM) but >> adds some >> +functionalities based on the prediction of the samples of the >> signal. The input >> +can be an analog signal or a digital signal. >> + >> +If the input is a continuous-time analog signal, it needs to >> be sampled >> +first so that a discrete-time signal is the input to the DPCM >> encoder. >> + >> +Simple: take the values of two consecutive samples; if they >> are analog >> +samples, quantize them; calculate the difference between the first >> one and the >> +next; the output is the difference, and it can be further entropy >> coded. >> + >> +Advanced: instead of taking a difference relative to a >> previous input sample, >> +take the difference relative to the output of a local model of the >> decoder process; >> +in this option, the difference can be quantized, which allows a >> good way to >> +incorporate a controlled loss in the encoding. > > This is directly from Wikipedia, isn't it? > Yes. > What comes to the content, DPCM in the context of V4L2 media bus codes, as a > digital interface, is always digital. So there's no need to document it. > Entropy coding is also out of the question: the samples of the currently > defined formats are equal in size. > Ok. > Another thing what I'm not sure is the definition of the simple and advanced > encoders. I've seen sensors that allow you to choose which one to use, but > the documentation hasn't stated what the actual implementation is. Does TI > documentation do so? > Couldn't find much apart from this 'The DPCM compression system uses two different predictors; one is simple and the other is complex. Predictor1 is very simple, so the processing power and the memory requirements are reduced with it (when the image quality is already high enough). Predictor2 gives a slightly better prediction for pixel value and the image quality can be improved with it.' > In V4L2 documentation we should state what is common in the hardware > documentation, and that is mostly limited to "simple" and "advanced". I > really don't know enough that I could say what the exact implamentation of > those two are in all of the cases. > > I suggest we leave just a few words of the DPCM compression itself (roughly > the factual content of the first paragraph with the exception of the > reference to analogue signal) and a link to Wikipedia. > Ok. >> +Applying one of these two processes, short-term redundancy >> (positive correlation of >> +nearby values) of the signal is eliminated; compression ratios on >> the order of 2 to 4 >> +can be achieved if differences are subsequently entropy coded, >> because the entropy of >> +the difference signal is much smaller than that of the original >> discrete signal treated >> +as independent samples.For more info
SAA7231 chipset support
Hi, Google tries to convince me that the Philips / NXP / Trident / SigmaDesigns SAA7231 chip is not (and will probably not be) supported on Linux (mostly because of bad will from the hardware companies). Could you please confirm that this chip is not (and will probably not be) supported [1] ? Thanks for your time [1] as opposed to other SAA71x chips, as seen in 3.2 kernel headers and on http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards You'll find details below (chip details / history, partial output of lspci -v / vv, hardware, uname -a) 1. Chip history: - announced by NXP (2008-03): http://www.nxp.com/news/press-releases/2008/03/nxp-launches-world-s-smallest-single-chip-triple-mode-pctv-solution.html - some guy at a German company began devlopments but this seems discontinued http://osdir.com/ml/video4linux-list/2010-07/msg00016.html and the src code url is dead / 404: http://www.jusst.de/hg/saa7231/ - Trident was the next owner. See TV > PC TV > SAAA link from the CX2450X page http://www.tridentmicro.com/producttree/stb/satellite-stb/cx2450x/ but they refused to give any help to linux develpers -- then finally filed for bankrupcy http://forums.opensuse.org/english/get-technical-help-here/hardware/450034-saa7231-module-2.html https://www.linux.com/community/forums/multimedia/installing-and-using-a-saa7231-tv-card/limit/20/offset/0 - the current owner seems to be Sigma Design for the SAA71x (and perhaps the SAA72) chips http://www.sigmadesigns.com/uploads/library/press_releases/120402.pdf 2. Output of lspci -v 02:00.0 Multimedia controller: Philips Semiconductors SAA7231 (rev ca) Subsystem: Yuan Yuan Enterprise Co., Ltd. Device 0762 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at dcc0 (64-bit, non-prefetchable) [size=4M] Memory at dc80 (64-bit, non-prefetchable) [size=4M] Capabilities: [40] MSI: Enable- Count=1/16 Maskable- 64bit+ Capabilities: [50] Express Endpoint, MSI 00 Capabilities: [74] Power Management version 3 Capabilities: [7c] Vendor Specific Information: Len=84 Capabilities: [100] Vendor Specific Information: ID= Rev=0 Len=094 and lspci -vv 02:00.0 Multimedia controller: Philips Semiconductors SAA7231 (rev ca) Subsystem: Yuan Yuan Enterprise Co., Ltd. Device 0762 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [100 v1] Vendor Specific Information: ID= Rev=0 Len=094 3. Other details: Hardware: the laptop with this chipset is an Asus N73S. Software: Linux Kubuntu. uname -a: Linux Newton 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Tue Sep 4 19:00:18 CEST 2012 git hash:79e8c7bebb467bbc3f2514d75bba669a3f354324 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-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.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-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.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The 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 v4] media: v4l2-ctrls: add control for dpcm predictor
Hi Prabhakar, Thanks for the patch. I've got a few comments below. On Tue, Sep 04, 2012 at 11:07:52AM +0530, Prabhakar Lad wrote: > From: Lad, Prabhakar > > add V4L2_CID_DPCM_PREDICTOR control of type menu, which > determines the dpcm predictor. The predictor can be either > simple or advanced. > > Signed-off-by: Lad, Prabhakar > Signed-off-by: Manjunath Hadli > Acked-by: Hans Verkuil > Reviewed-by: Sylwester Nawrocki > Cc: Sakari Ailus > Cc: Laurent Pinchart > Cc: Mauro Carvalho Chehab > Cc: Hans de Goede > Cc: Kyungmin Park > Cc: Rob Landley > --- > This patches has one checkpatch warning for line over > 80 characters altough it can be avoided I have kept it > for consistency. > > Changes for v4: > 1: Aligned the description to fit appropriately in the > para tag, pointed by Sylwester. > > Changes for v3: > 1: Added better explanation for DPCM, pointed by Hans. > > Changes for v2: > 1: Added documentaion in controls.xml pointed by Sylwester. > 2: Chnaged V4L2_DPCM_PREDICTOR_ADVANCE to V4L2_DPCM_PREDICTOR_ADVANCED >pointed by Sakari. > > Documentation/DocBook/media/v4l/controls.xml | 46 > +- > drivers/media/v4l2-core/v4l2-ctrls.c |9 + > include/linux/videodev2.h|5 +++ > 3 files changed, 59 insertions(+), 1 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > b/Documentation/DocBook/media/v4l/controls.xml > index 93b9c68..ad873ea 100644 > --- a/Documentation/DocBook/media/v4l/controls.xml > +++ b/Documentation/DocBook/media/v4l/controls.xml > @@ -4267,7 +4267,51 @@ interface and may change in the future. > pixels / second. > > > - > + > + spanname="id">V4L2_CID_DPCM_PREDICTOR > + menu > + > + > + Differential pulse-code modulation (DPCM) > is a signal > + encoder that uses the baseline of pulse-code modulation (PCM) but > adds some > + functionalities based on the prediction of the samples of the > signal. The input > + can be an analog signal or a digital signal. > + > + If the input is a continuous-time analog signal, it needs to > be sampled > + first so that a discrete-time signal is the input to the DPCM > encoder. > + > + Simple: take the values of two consecutive samples; if they > are analog > + samples, quantize them; calculate the difference between the first > one and the > + next; the output is the difference, and it can be further entropy > coded. > + > + Advanced: instead of taking a difference relative to a > previous input sample, > + take the difference relative to the output of a local model of the > decoder process; > + in this option, the difference can be quantized, which allows a > good way to > + incorporate a controlled loss in the encoding. This is directly from Wikipedia, isn't it? What comes to the content, DPCM in the context of V4L2 media bus codes, as a digital interface, is always digital. So there's no need to document it. Entropy coding is also out of the question: the samples of the currently defined formats are equal in size. Another thing what I'm not sure is the definition of the simple and advanced encoders. I've seen sensors that allow you to choose which one to use, but the documentation hasn't stated what the actual implementation is. Does TI documentation do so? In V4L2 documentation we should state what is common in the hardware documentation, and that is mostly limited to "simple" and "advanced". I really don't know enough that I could say what the exact implamentation of those two are in all of the cases. I suggest we leave just a few words of the DPCM compression itself (roughly the factual content of the first paragraph with the exception of the reference to analogue signal) and a link to Wikipedia. > + Applying one of these two processes, short-term redundancy > (positive correlation of > + nearby values) of the signal is eliminated; compression ratios on > the order of 2 to 4 > + can be achieved if differences are subsequently entropy coded, > because the entropy of > + the difference signal is much smaller than that of the original > discrete signal treated > + as independent samples.For more information about DPCM see + > url="http://en.wikipedia.org/wiki/Differential_pulse-code_modulation";>Wikipedia. > + > + > + > + > + > + > + V4L2_DPCM_PREDICTOR_SIMPLE > + Predictor type is simple > + > + > + > V4L2_DPCM_PREDICTOR_ADVANCED > + Predictor type is advanced > + > + > + > + > + > > > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c > b/drivers/media/v4l2-core/v4l2-ctrls.c > index b6a2ee7
[PATCH 3/5] drivers/media/platform/s5p-tv/mixer_video.c: fix error return code
From: Peter Senna Tschudin Convert a nonnegative error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // Signed-off-by: Peter Senna Tschudin --- drivers/media/platform/s5p-tv/mixer_video.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-tv/mixer_video.c b/drivers/media/platform/s5p-tv/mixer_video.c index a9c6be3..f139fed 100644 --- a/drivers/media/platform/s5p-tv/mixer_video.c +++ b/drivers/media/platform/s5p-tv/mixer_video.c @@ -83,6 +83,7 @@ int __devinit mxr_acquire_video(struct mxr_device *mdev, mdev->alloc_ctx = vb2_dma_contig_init_ctx(mdev->dev); if (IS_ERR_OR_NULL(mdev->alloc_ctx)) { mxr_err(mdev, "could not acquire vb2 allocator\n"); + ret = -ENODEV; goto fail_v4l2_dev; } @@ -764,8 +765,10 @@ static int mxr_video_open(struct file *file) } /* leaving if layer is already initialized */ - if (!v4l2_fh_is_singular_file(file)) + if (!v4l2_fh_is_singular_file(file)) { + ret = -EBUSY; /* Not sure if EBUSY is the best for here */ goto unlock; + } /* FIXME: should power be enabled on open? */ ret = mxr_power_get(mdev); -- 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 4/5] drivers/media/platform/vino.c: fix error return code
From: Peter Senna Tschudin Convert a nonnegative error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // Signed-off-by: Peter Senna Tschudin --- drivers/media/platform/vino.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/vino.c b/drivers/media/platform/vino.c index cc9110c..6654a28 100644 --- a/drivers/media/platform/vino.c +++ b/drivers/media/platform/vino.c @@ -2061,6 +2061,7 @@ static int vino_capture_next(struct vino_channel_settings *vcs, int start) } if (incoming == 0) { dprintk("vino_capture_next(): no buffers available\n"); + err = -ENOMEM; goto out; } -- 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 5/5] drivers/media/platform/omap3isp/isp.c: fix error return code
From: Peter Senna Tschudin Convert a nonnegative error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // Signed-off-by: Peter Senna Tschudin --- drivers/media/platform/omap3isp/isp.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c index e0096e0..91fcaef 100644 --- a/drivers/media/platform/omap3isp/isp.c +++ b/drivers/media/platform/omap3isp/isp.c @@ -2102,8 +2102,10 @@ static int __devinit isp_probe(struct platform_device *pdev) if (ret < 0) goto error; - if (__omap3isp_get(isp, false) == NULL) + if (__omap3isp_get(isp, false) == NULL) { + ret = -EBUSY; /* Not sure if EBUSY is best for here */ goto error; + } ret = isp_reset(isp); if (ret < 0) -- 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 1/5] drivers/media/platform/davinci/vpbe.c: fix error return code
From: Peter Senna Tschudin Convert a nonnegative error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // Signed-off-by: Peter Senna Tschudin --- drivers/media/platform/davinci/vpbe.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/media/platform/davinci/vpbe.c b/drivers/media/platform/davinci/vpbe.c index c4a82a1..2e4a0da 100644 --- a/drivers/media/platform/davinci/vpbe.c +++ b/drivers/media/platform/davinci/vpbe.c @@ -603,7 +603,6 @@ static int vpbe_initialize(struct device *dev, struct vpbe_device *vpbe_dev) int output_index; int num_encoders; int ret = 0; - int err; int i; /* @@ -646,10 +645,10 @@ static int vpbe_initialize(struct device *dev, struct vpbe_device *vpbe_dev) } v4l2_info(&vpbe_dev->v4l2_dev, "vpbe v4l2 device registered\n"); - err = bus_for_each_dev(&platform_bus_type, NULL, vpbe_dev, + ret = bus_for_each_dev(&platform_bus_type, NULL, vpbe_dev, platform_device_get); - if (err < 0) - return err; + if (ret < 0) + return ret; vpbe_dev->venc = venc_sub_dev_init(&vpbe_dev->v4l2_dev, vpbe_dev->cfg->venc.module_name); @@ -664,11 +663,11 @@ static int vpbe_initialize(struct device *dev, struct vpbe_device *vpbe_dev) osd_device = vpbe_dev->osd_device; if (NULL != osd_device->ops.initialize) { - err = osd_device->ops.initialize(osd_device); - if (err) { + ret = osd_device->ops.initialize(osd_device); + if (ret) { v4l2_err(&vpbe_dev->v4l2_dev, "unable to initialize the OSD device"); - err = -ENOMEM; + ret = -ENOMEM; goto vpbe_fail_v4l2_device; } } -- 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 2/5] drivers/media/platform/s5p-tv/sdo_drv.c: fix error return code
From: Peter Senna Tschudin Convert a nonnegative error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // Signed-off-by: Peter Senna Tschudin --- drivers/media/platform/s5p-tv/sdo_drv.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/s5p-tv/sdo_drv.c b/drivers/media/platform/s5p-tv/sdo_drv.c index ad68bbe..58cf56d 100644 --- a/drivers/media/platform/s5p-tv/sdo_drv.c +++ b/drivers/media/platform/s5p-tv/sdo_drv.c @@ -369,6 +369,7 @@ static int __devinit sdo_probe(struct platform_device *pdev) sdev->fout_vpll = clk_get(dev, "fout_vpll"); if (IS_ERR_OR_NULL(sdev->fout_vpll)) { dev_err(dev, "failed to get clock 'fout_vpll'\n"); + ret = -ENODEV; goto fail_dacphy; } dev_info(dev, "fout_vpll.rate = %lu\n", clk_get_rate(sclk_vpll)); @@ -377,11 +378,13 @@ static int __devinit sdo_probe(struct platform_device *pdev) sdev->vdac = devm_regulator_get(dev, "vdd33a_dac"); if (IS_ERR_OR_NULL(sdev->vdac)) { dev_err(dev, "failed to get regulator 'vdac'\n"); + ret = -ENODEV; goto fail_fout_vpll; } sdev->vdet = devm_regulator_get(dev, "vdet"); if (IS_ERR_OR_NULL(sdev->vdet)) { dev_err(dev, "failed to get regulator 'vdet'\n"); + ret = -ENODEV; goto fail_fout_vpll; } -- 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] tlg2300: fix missing check for audio creation
From: Alan Cox If we fail to set up the capture device we go through negative indexes and badness happens. Add the missing test. Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44551 Signed-off-by: Alan Cox --- drivers/media/usb/tlg2300/pd-alsa.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/media/usb/tlg2300/pd-alsa.c b/drivers/media/usb/tlg2300/pd-alsa.c index 9f8b7da..0c77869 100644 --- a/drivers/media/usb/tlg2300/pd-alsa.c +++ b/drivers/media/usb/tlg2300/pd-alsa.c @@ -305,6 +305,10 @@ int poseidon_audio_init(struct poseidon *p) return ret; ret = snd_pcm_new(card, "poseidon audio", 0, 0, 1, &pcm); + if (ret < 0) { + snd_free_card(card); + return ret; + } snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &pcm_capture_ops); pcm->info_flags = 0; pcm->private_data = p; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cx88: Fix reset delays
From: Alan Cox This was reported in March 2011 by Mirek Slugen, and a simple fix posted at the time then never got fixed and applied. The bug is still present. Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=37703 Signed-off-by: Alan Cox --- drivers/media/pci/cx88/cx88-cards.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/pci/cx88/cx88-cards.c b/drivers/media/pci/cx88/cx88-cards.c index 4e9d4f7..0c25524 100644 --- a/drivers/media/pci/cx88/cx88-cards.c +++ b/drivers/media/pci/cx88/cx88-cards.c @@ -3028,9 +3028,9 @@ static int cx88_xc3028_winfast1800h_callback(struct cx88_core *core, cx_set(MO_GP1_IO, 0x1010); mdelay(50); cx_clear(MO_GP1_IO, 0x10); - mdelay(50); + mdelay(75); cx_set(MO_GP1_IO, 0x10); - mdelay(50); + mdelay(75); return 0; } return -EINVAL; -- 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.6] VIDIOC_OVERLAY regression fix
Hi Mauro, While working on something else I suddenly saw that the VIDIOC_OVERLAY support was broken in 3.6. The vidioc_overlay op in v4l2-ioctls.h receives an unsigned int, whereas the ioctl table in v4l2-ioctls.c assumed that it would be an unsigned int pointer. To fix this a small conversion function was made. This patch applies to 3.7. By checking 'v4l2-core' to 'video' in the path of the file this patch will also apply to 3.6. All other ioctls that do this dereferencing are fine, it's just this one that's failing. Regards, Hans The following changes since commit 79e8c7bebb467bbc3f2514d75bba669a3f354324: Merge tag 'v3.6-rc3' into staging/for_v3.7 (2012-08-24 11:25:10 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git overlay for you to fetch changes up to 22ffede236c77ad0d4bff19a9cffe4f27bd05819: v4l2-ioctl.c: fix overlay support. (2012-09-04 15:08:01 +0200) Hans Verkuil (1): v4l2-ioctl.c: fix overlay support. drivers/media/v4l2-core/v4l2-ioctl.c |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) -- 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: [PATCHv3 2/9] ir-rx51: Handle signals properly
On Mon, Sep 03, 2012 at 11:41:55PM +0200, David Härdeman wrote: > Hej, > > On Mon, Sep 03, 2012 at 01:36:53PM +0100, Sean Young wrote: > >On Sun, Sep 02, 2012 at 11:08:20PM +0300, Timo Kokkonen wrote: > >> I guess the assumption is to avoid > >> breaking the transmission in the middle in case the process is signaled. > >> And that's why we shouldn't use interruptible waits. > >> > >> However, if we allow simply breaking the transmitting in case the > >> process is signaled any way during the transmission, then the handling > >> would be trivial in the driver. That is, if someone for example kills or > >> stops the lirc daemon process, then the IR code just wouldn't finish ever. > >> > >> Sean, do you have an opinion how this should or is allowed to work? > > > >You want to know when the hardware is done sending the IR. If you return > >EINTR to user space, how would user space know how much IR has been sent, > >if any? > > > >This ABI is not particularily elegant so there are proposals for a better > >interface which would obsolete the lirc interface. David Hardeman has > >worked on this: > > > >http://patchwork.linuxtv.org/patch/11411/ > > > > Yes, the first step is an asynchronous interface using a kfifo which is > managed/fed using functionality in rc-core and drained by the drivers. > > The size of the kfifo() itself is the only limiting factor right now, > but I do think we should eventually add some restrictions on the combined > duration of the pulse/space timings that are in the queue at any given > point. While we're at it, it would be useful to check that there no 0s in the timings, I'm not sure how well the drivers deal with those. > Say, for example, that any given pulse/space value is not allowed to be > above 500ms and the total duration of the queue is not allowed to be > above 1000ms. In case user-space wants (for whatever reason)...to write > a 4000ms space, it would have to do so in 8 messages of 500ms each. > > Each message write() provides the opportunity for a interruptible wait > (in the regular case) or returning EAGAIN (in the O_NONBLOCK case) - > assuming that the kfifo already holds pulse/space timing totalling > 1000ms and/or is full. > > EINTR should only be returned if nothing has been written to the kfifo > at all. This interface is much better but it's also an ABI change. How should this be handled? Should rc-core expose it's own /dev/rc[0-9] device with its own ioctls? > That way we would avoid policy in kernel while still making it possible > to kill a misbehaving user-space process by forcing it to drip feed long > TX sequences. Is the purpose of this to prevent one user space program from writing minutes worth of IR and then killing the process won't help since it's already in the kfifo? In that case I'd say that close() should purge the kfifo and user space needs to do fsync to ensure that all IR has been sent. Sean -- 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: use of timestamp/sequence in v4l2_buffer
Le mardi 4 septembre 2012 13:38:06, Hans Verkuil a écrit : > 7) Should the timestamp field always be monotonically increasing? Or it is > possible to get timestamps that jump around? This makes sense for encoders > that create B-frames referring to frames captured earlier than an I-frame. I would expect an encoder to output frames in DTS order rather than PTS and a decoder to output frames in PTS order. The timestamp field is the only indication of the PCR, so an application might not recover if the timestamp jumps backward. If there is an ambiguity between PTS and DTS, I think it should be documented and specified per format what the timestamp is. -- Rémi Denis-Courmont http://www.remlab.net/ -- 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] [media] rc: filter out not allowed protocols when decoding
On Tue, Sep 04, 2012 at 11:06:07AM +0800, Changbin Du wrote: > > > mutex_lock(&ir_raw_handler_lock); > > > - list_for_each_entry(handler, &ir_raw_handler_list, list) > > > - handler->decode(raw->dev, ev); > > > + list_for_each_entry(handler, &ir_raw_handler_list, list) { > > > + /* use all protocol by default */ > > > + if (raw->dev->allowed_protos == RC_TYPE_UNKNOWN || > > > + raw->dev->allowed_protos & handler->protocols) > > > + handler->decode(raw->dev, ev); > > > + } > > > > Each IR protocol decoder already checks whether it is enabled or not; > > should it not be so that only allowed protocols can be enabled rather > > than checking both enabled_protocols and allowed_protocols? > > > > Just from reading store_protocols it looks like decoders which aren't > > in allowed_protocols can be enabled, which makes no sense. Also > > ir_raw_event_register all protocols are enabled rather than the > > allowed ones. > > > > > > Lastely I don't know why raw ir drivers should dictate which protocols > > can be enabled. Would it not be better to remove it entirely? > > > I agree with you. I just thought that the only thing a decoder should care > is its decoding logic, but not including decoder management. My idaea is: > 1) use enabled_protocols to select decoders in ir_raw.c, but not > placed in decoders to do the judgement. > 2) remove allowed_protocols or just use it to set the default > decoder (also should rename allowed_protocols to default_protocol). The default decoder should be the one set by the rc keymap. > I also have a question: > Is there a requirement that one more decoders are enabled for a > IR device at the same time? Yes, you want to be able to multiple remotes on the IR device (which you can do as long as the scancodes don't overlap, I think), and the lirc device is implemented as a decoder, so you might want to see the raw IR as well as have it decoded. > And if that will lead to a issue that each decoder may decode a > same pulse sequence to different evnets since their protocol is > different? At the moment, no. David Hardeman has sent a patch for this: http://patchwork.linuxtv.org/patch/11388/ Sean -- 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 3/3] drivers/media/platform/davinci/vpfe_capture.c: fix error return code
From: Peter Senna Tschudin Convert a nonnegative error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // Signed-off-by: Peter Senna Tschudin --- drivers/media/platform/davinci/vpfe_capture.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/media/platform/davinci/vpfe_capture.c b/drivers/media/platform/davinci/vpfe_capture.c index 843b138..f99198c 100644 --- a/drivers/media/platform/davinci/vpfe_capture.c +++ b/drivers/media/platform/davinci/vpfe_capture.c @@ -1131,11 +1131,11 @@ static int vpfe_s_input(struct file *file, void *priv, unsigned int index) ret = -EBUSY; goto unlock_out; } - - if (vpfe_get_subdev_input_index(vpfe_dev, - &subdev_index, - &inp_index, - index) < 0) { + ret = vpfe_get_subdev_input_index(vpfe_dev, + &subdev_index, + &inp_index, + index); + if (ret < 0) { v4l2_err(&vpfe_dev->v4l2_dev, "invalid input index\n"); goto unlock_out; } @@ -1748,8 +1748,9 @@ static long vpfe_param_handler(struct file *file, void *priv, "Error setting parameters in CCDC\n"); goto unlock_out; } - if (vpfe_get_ccdc_image_format(vpfe_dev, - &vpfe_dev->fmt) < 0) { + ret = vpfe_get_ccdc_image_format(vpfe_dev, +&vpfe_dev->fmt); + if (ret < 0) { v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "Invalid image format at CCDC\n"); goto unlock_out; -- 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 1/3] drivers/media/rc/redrat3.c: fix error return code
From: Peter Senna Tschudin Convert a nonnegative error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // Signed-off-by: Peter Senna Tschudin --- drivers/media/rc/redrat3.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c index 2878b0e..49731b1 100644 --- a/drivers/media/rc/redrat3.c +++ b/drivers/media/rc/redrat3.c @@ -1217,9 +1217,10 @@ static int __devinit redrat3_dev_probe(struct usb_interface *intf, rr3->carrier = 38000; rr3->rc = redrat3_init_rc_dev(rr3); - if (!rr3->rc) + if (!rr3->rc) { + retval = -ENOMEM; goto error; - + } setup_timer(&rr3->rx_timeout, redrat3_rx_timeout, (unsigned long)rr3); /* we can register the device now, as it is ready */ -- 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 2/3] drivers/media/rc/ati_remote.c: fix error return code
From: Peter Senna Tschudin Convert a nonnegative error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // Signed-off-by: Peter Senna Tschudin --- drivers/media/rc/ati_remote.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c index 08aede5..49bb356 100644 --- a/drivers/media/rc/ati_remote.c +++ b/drivers/media/rc/ati_remote.c @@ -937,8 +937,10 @@ static int ati_remote_probe(struct usb_interface *interface, /* Set up and register mouse input device */ if (mouse) { input_dev = input_allocate_device(); - if (!input_dev) + if (!input_dev) { + err = -ENOMEM; goto fail4; + } ati_remote->idev = input_dev; ati_remote_input_init(ati_remote); -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: use of timestamp/sequence in v4l2_buffer
Hi all, During the Media Workshop last week we discussed how the timestamp and sequence fields in struct v4l2_buffer should be used. While trying to document the exact behavior I realized that there are a few missing pieces. Open questions with regards to the sequence field: 1) Should the first frame that was captured or displayed after starting streaming for the first time always start with sequence index 0? In my opinion it should. 2) Should the sequence counter be reset to 0 after a STREAMOFF? Or should it only be reset to 0 after REQBUFS/CREATE_BUFS is called? 3) Should the sequence counter behave differently for mem2mem devices? With the current definition both the capture and display sides of a mem2mem device just have their own independent sequence counter. 4) If frames are skipped, should the sequence counter skip as well? In my opinion it shouldn't. 5) Should the sequence counter always be monotonically increasing? I think it should. Open questions with regards to the timestamp field: 6) For output devices the timestamp field can be used to determine when to transmit the frame. In practice there are no output drivers that support this. It is also unclear how this would work: if the timestamp is 1 hour into the future, should the driver hold on to that frame for one hour? If another frame is queued with a timestamp that's earlier than the previous frame, should that frame be output first? I am inclined to drop this behavior from the spec. Should we get drivers that actually implement this, then we need to clarify the spec and add a new capability flag somewhere to tell userspace that you can actually use the timestamp for this purpose. 7) Should the timestamp field always be monotonically increasing? Or it is possible to get timestamps that jump around? This makes sense for encoders that create B-frames referring to frames captured earlier than an I-frame. 8) How should the timestamp field be handled for mem2mem devices? Setting the timestamp is pointless for the display side of a mem2mem device (as discussed above as well). One option is that the mem2mem driver sets the timestamp when it starts processing a queued frame. This timestamp is returned when the buffer is dequeued. This timestamp is also copied to the processed frame (on the capture side of the mem2mem device), thus allowing one to relate the captured processed frame to the source frame. Even if encoder devices rearrange the frames (as discussed in the previous point), the timestamp can still be used to map the frames. Comments are welcome! Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/5] video: Add generic display panel core
Hi Laurent, On Fri, Aug 17, 2012 at 02:49:39AM +0200, Laurent Pinchart wrote: > +/** > + * panel_get_modes - Get video modes supported by the panel > + * @panel: The panel > + * @modes: Pointer to an array of modes > + * > + * Fill the modes argument with a pointer to an array of video modes. The > array > + * is owned by the panel. > + * > + * Return the number of supported modes on success (including 0 if no mode is > + * supported) or a negative error code otherwise. > + */ > +int panel_get_modes(struct panel *panel, const struct fb_videomode **modes) > +{ > + if (!panel->ops || !panel->ops->get_modes) > + return 0; > + > + return panel->ops->get_modes(panel, modes); > +} > +EXPORT_SYMBOL_GPL(panel_get_modes); You have seen my of videomode helper proposal. One result there was that we want to have ranges for the margin/synclen fields. Does it make sense to base this new panel framework on a more sophisticated internal reprentation of the panel parameters? This could then be converted to struct fb_videomode / struct drm_display_mode as needed. This would also make it more suitable for drm drivers which are not interested in struct fb_videomode. Related to this I suggest to change the API to be able to iterate over the different modes, like: struct videomode *panel_get_mode(struct panel *panel, int num); This was we do not have to have an array of modes in memory, which may be a burden for some panel drivers. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 0/5] Generic panel framework
Hi Laurent, Basically I agree that we need a common panel framework. I just have some questions: 1. I think we should add color format in videomode - if we use such common video mode structure shared across subsystems. In HDMI, colors are bind with timings tightly. We need a combined videomode with timing and color format together. 2. I think we should add "set_videomode" interface. It helps HDMI monitors to set EDIDs. -- Thanks, -Zhou -- 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