cron job: media_tree daily build: OK
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: Thu Jul 10 04:00:21 CEST 2014 git branch: test git hash: 3c0d394ea7022bb9666d9df97a5776c4bcc3045c gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-14-gf11dd94 host hardware: x86_64 host os:3.14-5.slh.5-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] drivers/base/dma-buf.c: replace dma_buf_uninit_debugfs by debugfs_remove_recursive
On Fri, Jun 27, 2014 at 10:32:10PM +0200, Fabian Frederick wrote:
> null test before debugfs_remove_recursive is not needed so one line function
> dma_buf_uninit_debugfs can be removed.
>
> This patch calls debugfs_remove_recursive under CONFIG_DEBUG_FS
>
> Cc: Sumit Semwal
> Cc: Greg Kroah-Hartman
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Fabian Frederick
> ---
>
> This is untested.
>
> drivers/base/dma-buf.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index 840c7fa..184c0cb 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -701,12 +701,6 @@ static int dma_buf_init_debugfs(void)
> return err;
> }
>
> -static void dma_buf_uninit_debugfs(void)
> -{
> - if (dma_buf_debugfs_dir)
> - debugfs_remove_recursive(dma_buf_debugfs_dir);
> -}
> -
> int dma_buf_debugfs_create_file(const char *name,
> int (*write)(struct seq_file *))
> {
> @@ -722,9 +716,6 @@ static inline int dma_buf_init_debugfs(void)
> {
> return 0;
> }
> -static inline void dma_buf_uninit_debugfs(void)
> -{
> -}
> #endif
>
> static int __init dma_buf_init(void)
> @@ -738,6 +729,8 @@ subsys_initcall(dma_buf_init);
>
> static void __exit dma_buf_deinit(void)
> {
> - dma_buf_uninit_debugfs();
> +#ifdef CONFIG_DEBUG_FS
> + debugfs_remove_recursive(dma_buf_debugfs_dir);
> +#endif
That ifdef should not be needed at all, right? No ifdefs should be
needed for debugfs code, if it is written correctly :)
thanks,
greg k-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
Re: [GIT PULL FOR v3.16] mt9p031 fixes
Hi Enric,
On Wednesday 09 July 2014 17:56:59 Enric Balletbo Serra wrote:
> 2014-05-16 2:45 GMT+02:00 Laurent Pinchart wrote:
> > Hi Mauro,
> >
> > The following changes since commit
> > ba0d342ecc21fbbe2f6c178f4479944d1fb34f3b:
> > saa7134-alsa: include vmalloc.h (2014-05-13 23:05:15 -0300)
> >
> > are available in the git repository at:
> > git://linuxtv.org/pinchartl/media.git sensors/next
> >
> > for you to fetch changes up to a3a7145c6cecbd9752311b8ae1e431f6755ad5f3:
> > mt9p031: Fix BLC configuration restore when disabling test pattern
> >
> > (2014-05-16 02:43:50 +0200)
> >
> >
> >
> > Laurent Pinchart (2):
> > mt9p031: Really disable Black Level Calibration in test pattern mode
> > mt9p031: Fix BLC configuration restore when disabling test pattern
> >
> > drivers/media/i2c/mt9p031.c | 53 ++--
> >
> > 1 file changed, 39 insertions(+), 14 deletions(-)
>
> I'm trying to test omap3-isp and a board with mt9p031 sensor with
> current mainline. For now I'm using tag version 3.15 (which is close
> to current mainline). First, when I tried to use the test patterns I
> only saw a black screen, but after applying these two patches I saw an
> improvement, although I can see the test pattern correctly.
>
> After some modifications the subdevs_group for my board is as follows:
>
> +static struct isp_v4l2_subdevs_group igep00x0_camera_subdevs[] = {
> + {
> + .subdevs = cam0020_primary_subdevs,
> + .interface = ISP_INTERFACE_PARALLEL,
> + .bus = {
> + .parallel = {
> + /* CAM[11:0] */
> + .data_lane_shift = ISP_LANE_SHIFT_2,
> + /* Sample on falling edge */
> + .clk_pol = 1,
> + }
> + },
> + },
> + { },
> +};
>
> As I have some problems I would ask some questions, maybe you can help me.
>
> In the past in the data_lane_shift was ISP_LANE_SHIFT_0, but now, it
> seems I should to use ISP_LANE_SHIFT_2 (CAM[11:0] - as I saw in the
> include file). ISP_LANE_SHIFT_0 is for CAM[13:0] but OMAP3 has only 12
> data bus signals. Is that right ?
Not really. The CCDC input is actually 16 bits wide. The ISP parallel bus is
limited to 12 bits, the CSI2 receivers output up to 14 bits, and the bridge
can merge two 8-bit samples into a 16-bit sample for YUV formats.
When using a 12 bit parallel sensor, unless you want to restrict the dynamic
of the input image, you should use a data lane shift value of 0. This will
cause the CAMEXT[13:0] signal to be mapped to CAM[13:0]. As the parallel bus
is limited to 12 bits, the CAM[13:12] bits will be set to zero. When capturing
from the CCDC output to memory each pixel will be stored on 16 bits, with bits
[15:12] set to zero, and bits [11:0] containing image data. When forwarding
data to the preview engine, which has an input width of 10 bits, the ISP
driver will configure the CCDC video port to output bits [11:2] to the preview
engine, dropping the two LSBs.
> Another thing is I'm not able to capture the image correctly, also if
> if configure to ouput a test pattern, doesn't looks good. See as
> example [1] and [2]. Do you know what could be the problem ?
>
> For your information these are the pipeline that I'm using :
>
> media-ctl -v -r -l '"mt9p031 1-005d":0->"OMAP3 ISP CCDC":0[1],
> "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP
> preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3
> ISP resizer output":0[1]'
>
> media-ctl -v -f '"mt9p031 1-005d":0[SGRBG12 720x480], "OMAP3 ISP
> CCDC":2[SGRBG8 720x480], "OMAP3 ISP preview":1[UYVY 720x480], "OMAP3
> ISP resizer":1[UYVY 720x480]'
I would configure the pipeline with SGRBG10 at the output of the CCDC. The
resolutions you request through the pipeline can't be achieved exactly, as the
sensor can only perform binning/skipping to downscale. The resizer will take
care to scale the image to the requested 720x480, but it will get distorted.
You should use media-ctl -p to see what resolutions the above command actually
sets, and fix the configuration with appropriate cropping if you want to keep
the sensor aspect ratio intact.
> # Set Vertical Color Bars as test pattern
> yavta -w '0x009f0903 9' /dev/v4l-subdev8
>
> # Capture data with
> yavta -f UYVY -s 720x480 --capture=5 --skip=1 --file=image-# /dev/video6
>
> # And convert with
> raw2rgbpnm -s 720x480 image-0.uyuv image-0.pnm
>
> Thanks in advance and any help will be appreciate.
>
> Regards,
> Enric
>
> [1] http://downloads.isee.biz/pub/files/tmp/9-Vertical Color Bars.pnm
> [2] http://downloads.isee.biz/pub/files/tmp/9-Vertical Color Bars.uyvy
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
Re: [PATCH v1 1/5] seq_file: provide an analogue of print_hex_dump()
On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote: > The above function looks like almost verbatim copy of print_hex_dump(). The > only > difference I can spot is that it's calling seq_printf() instead of printk(). > Can > you not instead generalize print_hex_dump() and based on it's invocation, > make > it call either seq_printf() or printk() ? How do you propose doing that given any seq_ call requires a struct seq_file * and print_hex_dump needs a KERN_. Is there an actual value to 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: [PATCH v1 1/5] seq_file: provide an analogue of print_hex_dump()
On Wednesday, July 09, 2014 at 05:24:26 PM, Andy Shevchenko wrote:
> The new seq_hex_dump() is a complete analogue of print_hex_dump().
>
> We have few users of this functionality already. It allows to reduce their
> codebase.
>
> Signed-off-by: Andy Shevchenko
> ---
> fs/seq_file.c| 35 +++
> include/linux/seq_file.h | 4
> 2 files changed, 39 insertions(+)
>
> diff --git a/fs/seq_file.c b/fs/seq_file.c
> index 3857b72..fec4a6b 100644
> --- a/fs/seq_file.c
> +++ b/fs/seq_file.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -794,6 +795,40 @@ void seq_pad(struct seq_file *m, char c)
> }
> EXPORT_SYMBOL(seq_pad);
>
> +/* Analogue of print_hex_dump() */
> +void seq_hex_dump(struct seq_file *m, const char *prefix_str, int
> prefix_type, + int rowsize, int groupsize, const void *buf,
size_t len,
> + bool ascii)
> +{
> + const u8 *ptr = buf;
> + int i, linelen, remaining = len;
> + unsigned char linebuf[32 * 3 + 2 + 32 + 1];
> +
> + if (rowsize != 16 && rowsize != 32)
> + rowsize = 16;
> +
> + for (i = 0; i < len; i += rowsize) {
> + linelen = min(remaining, rowsize);
> + remaining -= rowsize;
> +
> + hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
> +linebuf, sizeof(linebuf), ascii);
> +
> + switch (prefix_type) {
> + case DUMP_PREFIX_ADDRESS:
> + seq_printf(m, "%s%p: %s\n", prefix_str, ptr + i,
linebuf);
> + break;
> + case DUMP_PREFIX_OFFSET:
> + seq_printf(m, "%s%.8x: %s\n", prefix_str, i, linebuf);
> + break;
> + default:
> + seq_printf(m, "%s%s\n", prefix_str, linebuf);
> + break;
> + }
> + }
> +}
> +EXPORT_SYMBOL(seq_hex_dump);
The above function looks like almost verbatim copy of print_hex_dump(). The
only
difference I can spot is that it's calling seq_printf() instead of printk().
Can
you not instead generalize print_hex_dump() and based on it's invocation, make
it call either seq_printf() or printk() ?
Best regards,
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 4/5] parisc: use seq_hex_dump() to dump buffers
In one case indeed it does, in another - no, though it seems it prints same data (by meaning) in both cases. I would like driver maintainer to say a word what they think about it. On Wed, Jul 9, 2014 at 9:26 PM, Joe Perches wrote: > On Wed, 2014-07-09 at 18:24 +0300, Andy Shevchenko wrote: >> Instead of custom approach let's use recently introduced seq_hex_dump() >> helper. > > Doesn't this also change the output from > > to > > > > -- > 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 -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: em28xx - remove reset_resume interface
em28xx uses resume interface as its reset_resume interface.
If usb device is reset during suspend, reset_resume doesn't
do the necessary initialization which leads to resume failure.
Many systems don't maintain do not maintain suspend current to
the USB host controllers during hibernation. Remove reset_resume
to allow disconnect to be called followed by device restore
sequence.
Signed-off-by: Shuah Khan
---
drivers/media/usb/em28xx/em28xx-cards.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 15ad470..c53fa77 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3522,7 +3522,6 @@ static struct usb_driver em28xx_usb_driver = {
.disconnect = em28xx_usb_disconnect,
.suspend = em28xx_usb_suspend,
.resume = em28xx_usb_resume,
- .reset_resume = em28xx_usb_resume,
.id_table = em28xx_id_table,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: em28xx - add error handling for KWORLD dvb_attach failures
Add error hanlding when EM2870_BOARD_KWORLD_A340 dvb_attach()
for fe and tuner fail in em28xx_dvb_init().
Signed-off-by: Shuah Khan
---
drivers/media/usb/em28xx/em28xx-dvb.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index d381861..8314f51 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1213,9 +1213,17 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb->fe[0] = dvb_attach(lgdt3305_attach,
&em2870_lgdt3304_dev,
&dev->i2c_adap[dev->def_i2c_bus]);
- if (dvb->fe[0] != NULL)
- dvb_attach(tda18271_attach, dvb->fe[0], 0x60,
- &dev->i2c_adap[dev->def_i2c_bus],
&kworld_a340_config);
+ if (!dvb->fe[0]) {
+ result = -EINVAL;
+ goto out_free;
+ }
+ if (!dvb_attach(tda18271_attach, dvb->fe[0], 0x60,
+ &dev->i2c_adap[dev->def_i2c_bus],
+ &kworld_a340_config)) {
+ dvb_frontend_detach(dvb->fe[0]);
+ result = -EINVAL;
+ goto out_free;
+ }
break;
case EM28174_BOARD_PCTV_290E:
/* set default GPIO0 for LNA, used if GPIOLIB is undefined */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: soc_camera, rcar_vin, and adv7604
Hi all, (disclaimer: I was away for the last two weeks with no proper access to my email, so, will be slowly fighting through my mail backlog, I know there have been a few mails re: soc-camera + DT etc., please, bear with me) On Wed, 9 Jul 2014, Ian Molton wrote: > Hi folks, > > My colleague and I are trying to work out what to do to support the > following combination: > > soc_camera + rcar_vin for capture, and the mainline adv7604 driver > (which we have modified to successfully drive the adv7612). > > The problem we face is that the 7604 driver uses the new "pads" API, but > soc_camera based drivers like rcar_vin do not. I'm not a huge expert in the pad-level API, but from what I understand there are at least two aspects to it: 1. subdevice pad-level API, which is just a newer, than the used by soc-camera subdevice API. 2. pad-level ioctl()s, exported to the user space, IIUC, as a part of the media controller API. For (2) - yes, soc-camera core support would need to be added, possibly with larger changes. Whereas for (1) it's only the host that has to use the pad-level API to access subdevice drivers. Interaction between camera host and subdevice drivers in soc-camera is direct, so, no soc-camera core modifications would be needed. Maybe we dould add some support, say, to help with (fake) file handles just to aid the transition. We might also add wrappers for subdev drivers, not implementing the pad-level API to avoid having host drivers support both APIs, but those are just convenience modifications. I might well be wrong. Please, correct me if so. Thanks Guennadi > Obviously, there are a few approaches we could take, but we could use > some guidance on this. > > One approach would be to bodge some non-pads older API support into the > 7604 driver. This would probably be the easiest solution. > > A better approach might be to add pad API support to soc_camera, but it > seems to me that the soc_camera API does not abstract away all of the > areas that might need to be touched, which would lead to much > pad-related churn in all the other soc_camera drivers. > > The codebase is rather large, and we're struggling to see a clear path > through this. Whatever we do, we would like to be acceptable upstream, > so we'd like to open a discussion. > > Perhaps a soc_camera2 with pads support? > > -- > Ian Molton > -- 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 be-all: tuning failed for 754mhz
I have the same issue with w_scan: http://pastebin.com/vCFD2972 On Wed, Jul 9, 2014 at 12:28 PM, Quentin Denis wrote: > Hi all, > > I am running a Terratec DVB Cinergy T stick MKII under openSUSE and cannot > find > all the channels available in my region (Brussels). I have all the channels > from on 482Mhz but none on 754mh, whereas on Windows I receive both. > > How can it be that it does not fully work under linux? Is there an > issue with the > driver? Neither kaffeine nor 'scan' will find it. The latter outputs a > tuning failure: > > quentin@linux-v3k0:~> scan be-All.txt > channels.conf > scanning be-All.txt > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > initial transponder 75400 0 3 9 1 1 3 0 > initial transponder 48200 0 1 9 3 1 3 0 > initial transponder 50600 0 1 9 3 1 3 0 > initial transponder 66600 0 3 9 1 1 3 0 > initial transponder 83400 0 3 9 1 1 3 0 tune to: > 75400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > WARNING: >>> tuning failed!!! tune to: > 75400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > (tuning failed) > WARNING: >>> tuning failed!!! tune to: > 48200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_1_2:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > Network Name 'VRTmux1' > 0x0001 0x1010: pmt_pid 0x1010 VRT -- EEN (running) > 0x0001 0x1020: pmt_pid 0x1020 VRT -- Canvas (running) > 0x0001 0x1030: pmt_pid 0x1030 VRT -- Ketnet op 12 (running) > 0x0001 0x1040: pmt_pid 0x1040 VRT -- Radio 1 (running) > 0x0001 0x1050: pmt_pid 0x1050 VRT -- Radio 2 (running) > 0x0001 0x1060: pmt_pid 0x1060 VRT -- Klara (running) > 0x0001 0x1070: pmt_pid 0x1070 VRT -- Studio Brussel (running) > 0x0001 0x1080: pmt_pid 0x1080 VRT -- MNM (running) > 0x0001 0x1090: pmt_pid 0x1090 VRT -- Klara Continuo (running) > 0x0001 0x10a0: pmt_pid 0x10a0 VRT -- Sporza (running) > 0x0001 0x10c0: pmt_pid 0x10c0 VRT -- Nieuws+ (running) > 0x0001 0x10d0: pmt_pid 0x10d0 VRT -- MNM Hits (running) tune to: > 50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_1_2:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > WARNING: >>> tuning failed!!! tune to: > 50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_1_2:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > (tuning failed) > WARNING: >>> tuning failed!!! tune to: > 66600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > WARNING: >>> tuning failed!!! tune to: > 66600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > (tuning failed) > WARNING: >>> tuning failed!!! tune to: > 83400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > WARNING: >>> tuning failed!!! tune to: > 83400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > (tuning failed) > WARNING: >>> tuning failed!!! > dumping lists (12 services) > Done. > > Best regards, > Quentin -- 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: PCTV T292e whole DVBT2 mux/Ultra HD performance question
On 9 Jul 2014, at 20:18, Antti Palosaari wrote: > Moikka > > > On 07/09/2014 04:14 PM, Andre Newman wrote: >> I’m using a T290e for whole mux DVBT2 capture, using this to record the >> current BBC World Cup Ultra HD tests, works well. :-) >> >> It seems impossible to buy more T290e’s, everyone want to sell me a T292e, I >> understand there is a driver now, thanks Antti. I read on Antti’s blog that >> there is a limit on raw TS performance with the T292, that it didn’t work >> well with QAM256 because of this... >> >> I am wondering if this is a hardware limit, or a performance problem that >> may have been resolved now the driver is a little tiny bit more mature? >> >> I am very happy to get a T292e and make some tests, help debug if there is a >> hope that it can handle 40Mbps in hardware.If there is a hardware limit I’d >> rather not be stuck with a limited tuner! >> >> The mux I need to record is QAM256 at ~40Mbps and the UHD video is ~36Mbps >> of this. >> >> Otherwise what other DVBT2 tuners are there that can capture a raw QAM256 >> mux at 40Mbps? > > You simply confused two different devices. There is no such limit on PCTV > 292e as far as I know. It is another DVB-T2 device having RTL2832P bridge > having problem with stream bandwidth. Ok, great news, thanks. Sorry for the noise… I’ll get one to try tomorrow. Regards Andre > > regards > Antti > > > -- > http://palosaari.fi/ > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: PCTV T292e whole DVBT2 mux/Ultra HD performance question
Moikka On 07/09/2014 04:14 PM, Andre Newman wrote: I’m using a T290e for whole mux DVBT2 capture, using this to record the current BBC World Cup Ultra HD tests, works well. :-) It seems impossible to buy more T290e’s, everyone want to sell me a T292e, I understand there is a driver now, thanks Antti. I read on Antti’s blog that there is a limit on raw TS performance with the T292, that it didn’t work well with QAM256 because of this... I am wondering if this is a hardware limit, or a performance problem that may have been resolved now the driver is a little tiny bit more mature? I am very happy to get a T292e and make some tests, help debug if there is a hope that it can handle 40Mbps in hardware.If there is a hardware limit I’d rather not be stuck with a limited tuner! The mux I need to record is QAM256 at ~40Mbps and the UHD video is ~36Mbps of this. Otherwise what other DVBT2 tuners are there that can capture a raw QAM256 mux at 40Mbps? You simply confused two different devices. There is no such limit on PCTV 292e as far as I know. It is another DVB-T2 device having RTL2832P bridge having problem with stream bandwidth. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 4/5] parisc: use seq_hex_dump() to dump buffers
On Wed, 2014-07-09 at 18:24 +0300, Andy Shevchenko wrote:
> Instead of custom approach let's use recently introduced seq_hex_dump()
> helper.
Doesn't this also change the output from
to
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/5] fs/seq_file: introduce seq_hex_dump() helper
On Wed, 2014-07-09 at 18:24 +0300, Andy Shevchenko wrote: > This introduces a new helper and switches current users to use it. While seq_print_hex_dump seems useful, I'm not sure existing forms can be changed to use it if any output content changes. seq_ is supposed to be a stable API. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/5] saa7164: convert to seq_hex_dump()
On Wed, Jul 9, 2014 at 11:24 AM, Andy Shevchenko wrote: > Instead of custom approach let's use recently added seq_hex_dump() helper. > > Signed-off-by: Andy Shevchenko ack Reviewed-by: Steven Toth -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: soc_camera, rcar_vin, and adv7604
Hi folks, My colleague and I are trying to work out what to do to support the following combination: soc_camera + rcar_vin for capture, and the mainline adv7604 driver (which we have modified to successfully drive the adv7612). The problem we face is that the 7604 driver uses the new "pads" API, but soc_camera based drivers like rcar_vin do not. Obviously, there are a few approaches we could take, but we could use some guidance on this. One approach would be to bodge some non-pads older API support into the 7604 driver. This would probably be the easiest solution. A better approach might be to add pad API support to soc_camera, but it seems to me that the soc_camera API does not abstract away all of the areas that might need to be touched, which would lead to much pad-related churn in all the other soc_camera drivers. The codebase is rather large, and we're struggling to see a clear path through this. Whatever we do, we would like to be acceptable upstream, so we'd like to open a discussion. Perhaps a soc_camera2 with pads support? -- Ian Molton -- 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] libv4lcontrol: sync control strings/flags with the kernel
On Tue, Jul 08, 2014 at 01:07:27PM +0200, Hans Verkuil wrote: > Hans, > > I'd like your opinion on this. I really don't think the (sw) suffix serves > any purpose and is just confusing to the end-user. > > If you think that it is important that apps/users know that a control is > emulated, > then I would propose adding a V4L2_CTRL_FLAG_EMULATED and setting it in > libv4lcontrol. Similar to the FMT_FLAG_EMULATED. IMHO it'd be important to know whether something is emulated or not, as emulation such as flipping carries often a significant CPU overhead. Format conversions are "easy" in this respect since not performing the conversion obviously avoids the overhead. I'm not sure if the information that a control is emulated is useful as such. For instance, how do you tell which choice of an emulated flipping control would avoid the overhead, if the sensor is mounted upside down? In this case the "default", "unflipped" configuration actually is implemented in software. This looks like another field next to default, min, max and step for QUERY_EXT_CTRL to me. Just my 5 euro cents. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: 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
Re: [GIT PULL FOR v3.16] mt9p031 fixes
Hi Laurent,
2014-05-16 2:45 GMT+02:00 Laurent Pinchart :
> Hi Mauro,
>
> The following changes since commit ba0d342ecc21fbbe2f6c178f4479944d1fb34f3b:
>
> saa7134-alsa: include vmalloc.h (2014-05-13 23:05:15 -0300)
>
> are available in the git repository at:
>
> git://linuxtv.org/pinchartl/media.git sensors/next
>
> for you to fetch changes up to a3a7145c6cecbd9752311b8ae1e431f6755ad5f3:
>
> mt9p031: Fix BLC configuration restore when disabling test pattern
> (2014-05-16 02:43:50 +0200)
>
>
> Laurent Pinchart (2):
> mt9p031: Really disable Black Level Calibration in test pattern mode
> mt9p031: Fix BLC configuration restore when disabling test pattern
>
> drivers/media/i2c/mt9p031.c | 53
> +++--
> 1 file changed, 39 insertions(+), 14 deletions(-)
>
I'm trying to test omap3-isp and a board with mt9p031 sensor with
current mainline. For now I'm using tag version 3.15 (which is close
to current mainline). First, when I tried to use the test patterns I
only saw a black screen, but after applying these two patches I saw an
improvement, although I can see the test pattern correctly.
After some modifications the subdevs_group for my board is as follows:
+static struct isp_v4l2_subdevs_group igep00x0_camera_subdevs[] = {
+ {
+ .subdevs = cam0020_primary_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ /* CAM[11:0] */
+ .data_lane_shift = ISP_LANE_SHIFT_2,
+ /* Sample on falling edge */
+ .clk_pol = 1,
+ }
+ },
+ },
+ { },
+};
As I have some problems I would ask some questions, maybe you can help me.
In the past in the data_lane_shift was ISP_LANE_SHIFT_0, but now, it
seems I should to use ISP_LANE_SHIFT_2 (CAM[11:0] - as I saw in the
include file). ISP_LANE_SHIFT_0 is for CAM[13:0] but OMAP3 has only 12
data bus signals. Is that right ?
Another thing is I'm not able to capture the image correctly, also if
if configure to ouput a test pattern, doesn't looks good. See as
example [1] and [2]. Do you know what could be the problem ?
For your information these are the pipeline that I'm using :
media-ctl -v -r -l '"mt9p031 1-005d":0->"OMAP3 ISP CCDC":0[1],
"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP
preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3
ISP resizer output":0[1]'
media-ctl -v -f '"mt9p031 1-005d":0[SGRBG12 720x480], "OMAP3 ISP
CCDC":2[SGRBG8 720x480], "OMAP3 ISP preview":1[UYVY 720x480], "OMAP3
ISP resizer":1[UYVY 720x480]'
# Set Vertical Color Bars as test pattern
yavta -w '0x009f0903 9' /dev/v4l-subdev8
# Capture data with
yavta -f UYVY -s 720x480 --capture=5 --skip=1 --file=image-# /dev/video6
# And convert with
raw2rgbpnm -s 720x480 image-0.uyuv image-0.pnm
Thanks in advance and any help will be appreciate.
Regards,
Enric
[1] http://downloads.isee.biz/pub/files/tmp/9-Vertical Color Bars.pnm
[2] http://downloads.isee.biz/pub/files/tmp/9-Vertical Color Bars.uyvy
> --
> 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
--
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 v1 4/5] parisc: use seq_hex_dump() to dump buffers
Instead of custom approach let's use recently introduced seq_hex_dump() helper.
Signed-off-by: Andy Shevchenko
---
drivers/parisc/ccio-dma.c | 14 +++---
drivers/parisc/sba_iommu.c | 11 +++
2 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index 8b490d7..9d353d2 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -1101,20 +1101,12 @@ static const struct file_operations ccio_proc_info_fops
= {
static int ccio_proc_bitmap_info(struct seq_file *m, void *p)
{
- int len = 0;
struct ioc *ioc = ioc_list;
while (ioc != NULL) {
- u32 *res_ptr = (u32 *)ioc->res_map;
- int j;
-
- for (j = 0; j < (ioc->res_size / sizeof(u32)); j++) {
- if ((j & 7) == 0)
- len += seq_puts(m, "\n ");
- len += seq_printf(m, "%08x", *res_ptr);
- res_ptr++;
- }
- len += seq_puts(m, "\n\n");
+ seq_hex_dump(m, " ", DUMP_PREFIX_NONE, 32, 4, ioc->res_map,
+ioc->res_size, false);
+ seq_putc(m, '\n');
ioc = ioc->next;
break; /* XXX - remove me */
}
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index 1ff1b67..fbc4db9 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -1857,15 +1857,10 @@ sba_proc_bitmap_info(struct seq_file *m, void *p)
{
struct sba_device *sba_dev = sba_list;
struct ioc *ioc = &sba_dev->ioc[0]; /* FIXME: Multi-IOC support! */
- unsigned int *res_ptr = (unsigned int *)ioc->res_map;
- int i, len = 0;
- for (i = 0; i < (ioc->res_size/sizeof(unsigned int)); ++i, ++res_ptr) {
- if ((i & 7) == 0)
- len += seq_printf(m, "\n ");
- len += seq_printf(m, " %08x", *res_ptr);
- }
- len += seq_printf(m, "\n");
+ seq_hex_dump(m, " ", DUMP_PREFIX_NONE, 32, 4, ioc->res_map,
+ioc->res_size, false);
+ seq_printf(m, "\n");
return 0;
}
--
2.0.1
--
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 v1 3/5] crypto: qat - use seq_hex_dump() to dump buffers
Instead of custom approach let's use recently introduced seq_hex_dump() helper.
In this case it slightly changes the output, namely the four tetrads will be
output on one line.
Signed-off-by: Andy Shevchenko
---
drivers/crypto/qat/qat_common/adf_transport_debug.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_transport_debug.c
b/drivers/crypto/qat/qat_common/adf_transport_debug.c
index 6b69745..8b103cf 100644
--- a/drivers/crypto/qat/qat_common/adf_transport_debug.c
+++ b/drivers/crypto/qat/qat_common/adf_transport_debug.c
@@ -86,9 +86,7 @@ static int adf_ring_show(struct seq_file *sfile, void *v)
{
struct adf_etr_ring_data *ring = sfile->private;
struct adf_etr_bank_data *bank = ring->bank;
- uint32_t *msg = v;
void __iomem *csr = ring->bank->csr_addr;
- int i, x;
if (v == SEQ_START_TOKEN) {
int head, tail, empty;
@@ -111,18 +109,8 @@ static int adf_ring_show(struct seq_file *sfile, void *v)
seq_puts(sfile, "--- Ring data \n");
return 0;
}
- seq_printf(sfile, "%p:", msg);
- x = 0;
- i = 0;
- for (; i < (ADF_MSG_SIZE_TO_BYTES(ring->msg_size) >> 2); i++) {
- seq_printf(sfile, " %08X", *(msg + i));
- if ((ADF_MSG_SIZE_TO_BYTES(ring->msg_size) >> 2) != i + 1 &&
- (++x == 8)) {
- seq_printf(sfile, "\n%p:", msg + i + 1);
- x = 0;
- }
- }
- seq_puts(sfile, "\n");
+ seq_hex_dump(sfile, "", DUMP_PREFIX_ADDRESS, 16, 4,
+v, ADF_MSG_SIZE_TO_BYTES(ring->msg_size), false);
return 0;
}
--
2.0.1
--
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 v1 5/5] [S390] zcrypt: use seq_hex_dump() to dump buffers
Instead of custom approach let's use recently introduced seq_hex_dump() helper.
In this case it slightly changes the output, namely the four tetrads will be
output on one line.
Signed-off-by: Andy Shevchenko
---
drivers/s390/crypto/zcrypt_api.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/s390/crypto/zcrypt_api.c b/drivers/s390/crypto/zcrypt_api.c
index 0e18c5d..d1f9983 100644
--- a/drivers/s390/crypto/zcrypt_api.c
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -1203,16 +1203,8 @@ static void sprinthx(unsigned char *title, struct
seq_file *m,
static void sprinthx4(unsigned char *title, struct seq_file *m,
unsigned int *array, unsigned int len)
{
- int r;
-
seq_printf(m, "\n%s\n", title);
- for (r = 0; r < len; r++) {
- if ((r % 8) == 0)
- seq_printf(m, "");
- seq_printf(m, "%08X ", array[r]);
- if ((r % 8) == 7)
- seq_putc(m, '\n');
- }
+ seq_hex_dump(m, "", DUMP_PREFIX_NONE, 32, 4, array, len, false);
seq_putc(m, '\n');
}
--
2.0.1
--
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 v1 2/5] saa7164: convert to seq_hex_dump()
Instead of custom approach let's use recently added seq_hex_dump() helper.
Signed-off-by: Andy Shevchenko
---
drivers/media/pci/saa7164/saa7164-core.c | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/media/pci/saa7164/saa7164-core.c
b/drivers/media/pci/saa7164/saa7164-core.c
index 1bf0697..6f81584 100644
--- a/drivers/media/pci/saa7164/saa7164-core.c
+++ b/drivers/media/pci/saa7164/saa7164-core.c
@@ -1065,7 +1065,6 @@ static int saa7164_proc_show(struct seq_file *m, void *v)
struct saa7164_dev *dev;
struct tmComResBusInfo *b;
struct list_head *list;
- int i, c;
if (saa7164_devcount == 0)
return 0;
@@ -1089,35 +1088,13 @@ static int saa7164_proc_show(struct seq_file *m, void
*v)
seq_printf(m, " .m_pdwGetReadPos = 0x%x (0x%08x)\n",
b->m_dwGetWritePos, saa7164_readl(b->m_dwGetWritePos));
- c = 0;
seq_printf(m, "\n Set Ring:\n");
- seq_printf(m, "\n addr 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
0d 0e 0f\n");
- for (i = 0; i < b->m_dwSizeSetRing; i++) {
- if (c == 0)
- seq_printf(m, " %04x:", i);
+ seq_hex_dump(m, " ", DUMP_PREFIX_OFFSET, 16, 1,
+b->m_pdwSetRing, b->m_dwSizeSetRing, false);
- seq_printf(m, " %02x", *(b->m_pdwSetRing + i));
-
- if (++c == 16) {
- seq_printf(m, "\n");
- c = 0;
- }
- }
-
- c = 0;
seq_printf(m, "\n Get Ring:\n");
- seq_printf(m, "\n addr 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
0d 0e 0f\n");
- for (i = 0; i < b->m_dwSizeGetRing; i++) {
- if (c == 0)
- seq_printf(m, " %04x:", i);
-
- seq_printf(m, " %02x", *(b->m_pdwGetRing + i));
-
- if (++c == 16) {
- seq_printf(m, "\n");
- c = 0;
- }
- }
+ seq_hex_dump(m, " ", DUMP_PREFIX_OFFSET, 16, 1,
+b->m_pdwGetRing, b->m_dwSizeGetRing, false);
mutex_unlock(&b->lock);
--
2.0.1
--
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 v1 1/5] seq_file: provide an analogue of print_hex_dump()
The new seq_hex_dump() is a complete analogue of print_hex_dump().
We have few users of this functionality already. It allows to reduce their
codebase.
Signed-off-by: Andy Shevchenko
---
fs/seq_file.c| 35 +++
include/linux/seq_file.h | 4
2 files changed, 39 insertions(+)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 3857b72..fec4a6b 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -794,6 +795,40 @@ void seq_pad(struct seq_file *m, char c)
}
EXPORT_SYMBOL(seq_pad);
+/* Analogue of print_hex_dump() */
+void seq_hex_dump(struct seq_file *m, const char *prefix_str, int prefix_type,
+ int rowsize, int groupsize, const void *buf, size_t len,
+ bool ascii)
+{
+ const u8 *ptr = buf;
+ int i, linelen, remaining = len;
+ unsigned char linebuf[32 * 3 + 2 + 32 + 1];
+
+ if (rowsize != 16 && rowsize != 32)
+ rowsize = 16;
+
+ for (i = 0; i < len; i += rowsize) {
+ linelen = min(remaining, rowsize);
+ remaining -= rowsize;
+
+ hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
+ linebuf, sizeof(linebuf), ascii);
+
+ switch (prefix_type) {
+ case DUMP_PREFIX_ADDRESS:
+ seq_printf(m, "%s%p: %s\n", prefix_str, ptr + i,
linebuf);
+ break;
+ case DUMP_PREFIX_OFFSET:
+ seq_printf(m, "%s%.8x: %s\n", prefix_str, i, linebuf);
+ break;
+ default:
+ seq_printf(m, "%s%s\n", prefix_str, linebuf);
+ break;
+ }
+ }
+}
+EXPORT_SYMBOL(seq_hex_dump);
+
struct list_head *seq_list_start(struct list_head *head, loff_t pos)
{
struct list_head *lh;
diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index 52e0097..6a8be4c 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -107,6 +107,10 @@ int seq_write(struct seq_file *seq, const void *data,
size_t len);
__printf(2, 3) int seq_printf(struct seq_file *, const char *, ...);
__printf(2, 0) int seq_vprintf(struct seq_file *, const char *, va_list args);
+void seq_hex_dump(struct seq_file *m, const char *prefix_str, int prefix_type,
+ int rowsize, int groupsize, const void *buf, size_t len,
+ bool ascii);
+
int seq_path(struct seq_file *, const struct path *, const char *);
int seq_dentry(struct seq_file *, struct dentry *, const char *);
int seq_path_root(struct seq_file *m, const struct path *path,
--
2.0.1
--
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 v1 0/5] fs/seq_file: introduce seq_hex_dump() helper
This introduces a new helper and switches current users to use it. parisc and s390 weren't tested anyhow, the other are compile tested. Andy Shevchenko (5): seq_file: provide an analogue of print_hex_dump() saa7164: convert to seq_hex_dump() crypto: qat - use seq_hex_dump() to dump buffers parisc: use seq_hex_dump() to dump buffers [S390] zcrypt: use seq_hex_dump() to dump buffers .../crypto/qat/qat_common/adf_transport_debug.c| 16 ++ drivers/media/pci/saa7164/saa7164-core.c | 31 +++ drivers/parisc/ccio-dma.c | 14 ++--- drivers/parisc/sba_iommu.c | 11 ++- drivers/s390/crypto/zcrypt_api.c | 10 +-- fs/seq_file.c | 35 ++ include/linux/seq_file.h | 4 +++ 7 files changed, 52 insertions(+), 69 deletions(-) -- 2.0.1 -- 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
PCTV T292e whole DVBT2 mux/Ultra HD performance question
I’m using a T290e for whole mux DVBT2 capture, using this to record the current BBC World Cup Ultra HD tests, works well. :-) It seems impossible to buy more T290e’s, everyone want to sell me a T292e, I understand there is a driver now, thanks Antti. I read on Antti’s blog that there is a limit on raw TS performance with the T292, that it didn’t work well with QAM256 because of this... I am wondering if this is a hardware limit, or a performance problem that may have been resolved now the driver is a little tiny bit more mature? I am very happy to get a T292e and make some tests, help debug if there is a hope that it can handle 40Mbps in hardware.If there is a hardware limit I’d rather not be stuck with a limited tuner! The mux I need to record is QAM256 at ~40Mbps and the UHD video is ~36Mbps of this. Otherwise what other DVBT2 tuners are there that can capture a raw QAM256 mux at 40Mbps? Andre-- 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] staging: nokia_h4p: nokia_core.c - removed IRQF_DISABLED macro
On Wednesday 09 July 2014 05:16 PM, Pavel Machek wrote: > I wonder if it would maek sense to do > ./include/linux/interrupt.h:#define IRQF_DISABLED 0 to make it extra > clear that it is nop now? Pavel yes - it makes sense. there are still a few references to the macro in the code. Cheers, Anil -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: em28xx-dvb - fix em28xx_dvb_resume() to not unregister i2c and dvb
em28xx_dvb_resume() unregisters i2c tuner, i2c demod, and dvb.
This erroneous cleanup results in i2c tuner, i2c demod, and dvb
devices unregistered and removed during resume. This error is a
result of merge conflict between two patches that went into 3.15.
Signed-off-by: Shuah Khan
---
drivers/media/usb/em28xx/em28xx-dvb.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index a121ed9..d381861 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1712,7 +1712,6 @@ static int em28xx_dvb_resume(struct em28xx *dev)
em28xx_info("Resuming DVB extension");
if (dev->dvb) {
struct em28xx_dvb *dvb = dev->dvb;
- struct i2c_client *client = dvb->i2c_client_tuner;
if (dvb->fe[0]) {
ret = dvb_frontend_resume(dvb->fe[0]);
@@ -1723,22 +1722,6 @@ static int em28xx_dvb_resume(struct em28xx *dev)
ret = dvb_frontend_resume(dvb->fe[1]);
em28xx_info("fe1 resume %d", ret);
}
- /* remove I2C tuner */
- if (client) {
- module_put(client->dev.driver->owner);
- i2c_unregister_device(client);
- }
-
- /* remove I2C demod */
- client = dvb->i2c_client_demod;
- if (client) {
- module_put(client->dev.driver->owner);
- i2c_unregister_device(client);
- }
-
- em28xx_unregister_dvb(dvb);
- kfree(dvb);
- dev->dvb = NULL;
}
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Troubleshooting problematic DVB-T reception
> I am trying to troubleshoot a (non-linux related) DVB-T issue and I basically > want to create statistics about both DVB and MPEG framing, errors, corruption, > missing frames, etc. > > The reason is that I believe there is a problem on the transmitting radio > tower, RF is fine between the tower and me, but the actual payload (MPEG) is > somehow bogus, errored or sporadically misses frames (due to backhaul problems > or whatever). > > If I would be able to create some statistics confirming that I see all the DVB > frames without any errors, but that the actual DVB payload (MPEG) has some > problems, I could convince the tower guys to actually fix the issue, instead > of blaming my antennas. > > > So, can anyone suggest a tool or method to troubleshoot this issue further? > > > tzap output for example confirms not a single BER error and the tuner keeps > full LOCK on the channel while the actual stream is stuttering. I probably wouldn't rely on the BER stats from tzap. Their implementation varies in quality depending on which tuner you have, as well as how they are sampled. Almost all demods will set the TEI bit on the MPEG frame if it's determined that there was a decoding error - I would be much more inclined to look at that. Your best bet is to record the whole mux for a few minutes, then run it through some different tools to see what class of errors you are hitting. Tools such as tsreader or StreamEye will give you a better idea what's going on. Once you know what class of failure you have (e.g. TEI errors, MPEG discontinuities, etc), then you can better isolate where in the chain the failure is being introduced. Having the recording of the mux will also let you analyze in depth the actual nature of the problem, rather than trying to analyze an ever-changing stream in real-time, where signal conditions can change over time. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Troubleshooting problematic DVB-T reception
Hi list, I am trying to troubleshoot a (non-linux related) DVB-T issue and I basically want to create statistics about both DVB and MPEG framing, errors, corruption, missing frames, etc. The reason is that I believe there is a problem on the transmitting radio tower, RF is fine between the tower and me, but the actual payload (MPEG) is somehow bogus, errored or sporadically misses frames (due to backhaul problems or whatever). If I would be able to create some statistics confirming that I see all the DVB frames without any errors, but that the actual DVB payload (MPEG) has some problems, I could convince the tower guys to actually fix the issue, instead of blaming my antennas. So, can anyone suggest a tool or method to troubleshoot this issue further? tzap output for example confirms not a single BER error and the tuner keeps full LOCK on the channel while the actual stream is stuttering. I understand that this is not directly related to the DVB stack in the kernel, and I'm sorry if this is thus off-topic, but I am not sure where else to ask. Any help would be much appreciated! Thanks, Lukas -- 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: New v4l2 driver does not allow brightness/contrast control
Yeah, tested on kernel 3.15 and it worked. The problem is that my board doesn't have Android HAL's compatible with that version, so i'm trying to find where is the difference. 2014-07-08 15:10 GMT-03:00 Frank Schäfer : > > Am 07.07.2014 19:58, schrieb Rafael Coutinho: >> I have a v4l2 video capture board that using kernel 2.6 with v4l2 >> em28xx driver 3.0.36 allows me to control brightness, contrast etc... >> However in kernel 3.2 with v4l2 em28xx driver version 3.2.0 it does not. >> >> This is what I get from the latest driver: >> root@android:/ # v4l2-ctl --info >> Driver Info (not using libv4l2): >> Driver name : em28xx >> Card type : EM2860/SAA711X Reference Design >> Bus info : usb-musb-hdrc.1-1 >> Driver version: 3.2.0 >> Capabilities : 0x05020051 >> Video Capture >> VBI Capture >> Sliced VBI Capture >> Audio >> Read/Write >> Streaming >> root@android:/ # v4l2-ctl -d 0 -l >> volume (int): min=0 max=31 step=1 >> default=31 value=31 flags=slider >>mute (bool) : default=1 value=1 >> >> >> What could be wrong? > > Before kernel 3.10, the brightness (contrast, ...) controls are provided > by the subdevice drivers. > With kernel 3.10 I have introduced bridge level image controls, but they > are currently only used/activated if the subdevice doesn't already > provide them (as suggested by Mauro). > > Hth, > Frank Schäfer > -- Regards, Coutinho www.phiinnovations.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] staging: media: bcm2048: radio-bcm2048.c - removed IRQF_DISABLED macro
On Wed 2014-07-09 11:36:37, Anil Belur wrote: > From: Anil Belur > > - this patch removes IRQF_DISABLED macro, as this is > deprecated/noop. > > Signed-off-by: Anil Belur Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 2/2] staging: nokia_h4p: nokia_core.c - removed IRQF_DISABLED macro
On Wed 2014-07-09 11:36:38, Anil Belur wrote: > From: Anil Belur > > - this patch removes the IRQF_DISABLED macro, as this is > deprecated/noop. > > Signed-off-by: Anil Belur Acked-by: Pavel Machek I wonder if it would maek sense to do ./include/linux/interrupt.h:#define IRQF_DISABLED 0 to make it extra clear that it is nop now? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: No audio support in struct v4l2_subdev_format
On 07/09/2014 12:55 PM, Divneil Wadhawan wrote: > Hi Hans, > > > I agree that it was not a good implementation of using event. > > (Please discard the exact code, as it is erroneous in managing ctrl events > replace/merge and other ones) > > > I restart with the concern. > > Here, I have a v4l2 subdev, which can generate events from the time we load > it. > > We later found some use cases, where we would like the application to get the > events too. > > > v4l2_event_queue_fh() requires fh. > > I think, there's no way of gaining the access to this fh, except the > SUBSCRIBE_EVENT or any calls landing on subdev before this. > > The adding and deleting of fh in the list, is well managed by the event ops. > > However, adding fh to the list is the tricky part, as I don't want to fill in > the link list with the same fh over and over. I still don't understand your problem. So the application wants to subscribe to an event, it calls VIDIOC_SUBSCRIBE_EVENT and from that point onwards it will receive those events. All the driver does is to call v4l2_event_subscribe (possibly through helper functions like v4l2_src_change_event_subscribe). You never have to touch filehandles yourself, that's all done in v4l2-event.c. When your driver needs to raise the event it will typically call v4l2_event_queue() and in rare cases v4l2_event_queue_fh() to send an event to a specific filehandle (primarily used by m2m devices which have a per-filehandle state). If you would like to have an initial event that is issued as soon as a filehandle subscribes to an event, then the application has to set the V4L2_EVENT_SUB_FL_SEND_INITIAL flag and that event also has to support that flag. It would make sense that v4l2_src_change_event_subscribe() is extended to support that flag. The bottom line is that you never have to touch filehandles or keep track of them. Are you perhaps trying to receive events from a sub-device in a platform driver? If that's the case, then let me know since that is not supported and it should really be improved (I have some ideas about that). The only communication between a subdev and the bridge driver is via the notify callback in v4l2_device. 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: No audio support in struct v4l2_subdev_format
Hi Hans, I agree that it was not a good implementation of using event. (Please discard the exact code, as it is erroneous in managing ctrl events replace/merge and other ones) I restart with the concern. Here, I have a v4l2 subdev, which can generate events from the time we load it. We later found some use cases, where we would like the application to get the events too. v4l2_event_queue_fh() requires fh. I think, there's no way of gaining the access to this fh, except the SUBSCRIBE_EVENT or any calls landing on subdev before this. The adding and deleting of fh in the list, is well managed by the event ops. However, adding fh to the list is the tricky part, as I don't want to fill in the link list with the same fh over and over. If you know of any other way, please suggest. I hope I clarified the point this time. Regards, Divneil -- 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-T be-all: tuning failed for 754mhz
Hi all, I am running a Terratec DVB Cinergy T stick MKII under openSUSE and cannot find all the channels available in my region (Brussels). I have all the channels from on 482Mhz but none on 754mh, whereas on Windows I receive both. How can it be that it does not fully work under linux? Is there an issue with the driver? Neither kaffeine nor 'scan' will find it. The latter outputs a tuning failure: quentin@linux-v3k0:~> scan be-All.txt > channels.conf scanning be-All.txt using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 75400 0 3 9 1 1 3 0 initial transponder 48200 0 1 9 3 1 3 0 initial transponder 50600 0 1 9 3 1 3 0 initial transponder 66600 0 3 9 1 1 3 0 initial transponder 83400 0 3 9 1 1 3 0 >>> tune to: 75400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE WARNING: >>> tuning failed!!! >>> tune to: 75400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE (tuning failed) WARNING: >>> tuning failed!!! >>> tune to: 48200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_1_2:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE Network Name 'VRTmux1' 0x0001 0x1010: pmt_pid 0x1010 VRT -- EEN (running) 0x0001 0x1020: pmt_pid 0x1020 VRT -- Canvas (running) 0x0001 0x1030: pmt_pid 0x1030 VRT -- Ketnet op 12 (running) 0x0001 0x1040: pmt_pid 0x1040 VRT -- Radio 1 (running) 0x0001 0x1050: pmt_pid 0x1050 VRT -- Radio 2 (running) 0x0001 0x1060: pmt_pid 0x1060 VRT -- Klara (running) 0x0001 0x1070: pmt_pid 0x1070 VRT -- Studio Brussel (running) 0x0001 0x1080: pmt_pid 0x1080 VRT -- MNM (running) 0x0001 0x1090: pmt_pid 0x1090 VRT -- Klara Continuo (running) 0x0001 0x10a0: pmt_pid 0x10a0 VRT -- Sporza (running) 0x0001 0x10c0: pmt_pid 0x10c0 VRT -- Nieuws+ (running) 0x0001 0x10d0: pmt_pid 0x10d0 VRT -- MNM Hits (running) >>> tune to: 50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_1_2:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE WARNING: >>> tuning failed!!! >>> tune to: 50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_1_2:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE (tuning failed) WARNING: >>> tuning failed!!! >>> tune to: 66600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE WARNING: >>> tuning failed!!! >>> tune to: 66600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE (tuning failed) WARNING: >>> tuning failed!!! >>> tune to: 83400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE WARNING: >>> tuning failed!!! >>> tune to: 83400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE (tuning failed) WARNING: >>> tuning failed!!! dumping lists (12 services) Done. Best regards, Quentin -- 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
[PULL patches for 3.17]: New usb-id for gspca_pac7302
Hi Mauro, Please pull from my tree for a new usb-id for gspca_pac7302 The following changes since commit 3c0d394ea7022bb9666d9df97a5776c4bcc3045c: [media] dib8000: improve the message that reports per-layer locks (2014-07-07 09:59:01 -0300) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.17 for you to fetch changes up to d2cfd7d0ce530928dfacd5cca0a544e1b071e925: gspca_pac7302: Add new usb-id for Genius i-Look 317 (2014-07-09 11:20:44 +0200) Hans de Goede (1): gspca_pac7302: Add new usb-id for Genius i-Look 317 drivers/media/usb/gspca/pac7302.c | 1 + 1 file changed, 1 insertion(+) Thanks & Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.17] VSP1 transparency support
Hi Mauro, The following changes since commit 3c0d394ea7022bb9666d9df97a5776c4bcc3045c: [media] dib8000: improve the message that reports per-layer locks (2014-07-07 09:59:01 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/fbdev.git vsp1/upstream for you to fetch changes up to b44f3aa857f13c75ead85e6f2597024b259eabcc: v4l: vsp1: uds: Fix scaling of alpha layer (2014-07-09 11:23:46 +0200) Laurent Pinchart (23): v4l: Add ARGB and XRGB pixel formats DocBook: media: Document ALPHA_COMPONENT control usage on output devices v4l: Support extending the v4l2_pix_format structure v4l: Add premultiplied alpha flag for pixel formats v4l: vb2: Fix stream start and buffer completion race v4l: vsp1: Fix routing cleanup when stopping the stream v4l: vsp1: Release buffers at stream stop v4l: vsp1: Fix pipeline stop timeout v4l: vsp1: Fix typos v4l: vsp1: Cleanup video nodes at removal time v4l: vsp1: Propagate vsp1_device_get errors to the callers v4l: vsp1: Setup control handler automatically at stream on time v4l: vsp1: sru: Fix the intensity control default value v4l: vsp1: sru: Make the intensity controllable during streaming v4l: vsp1: wpf: Simplify cast to pipeline structure v4l: vsp1: wpf: Clear RPF to WPF association at stream off time v4l: vsp1: Switch to XRGB formats v4l: vsp1: Add alpha channel support to the memory ports v4l: vsp1: Add V4L2_CID_ALPHA_COMPONENT control support v4l: vsp1: bru: Support premultiplied alpha at the BRU inputs v4l: vsp1: bru: Support non-premultiplied colors at the BRU output v4l: vsp1: bru: Make the background color configurable v4l: vsp1: uds: Fix scaling of alpha layer Documentation/DocBook/media/Makefile | 2 +- Documentation/DocBook/media/v4l/controls.xml | 17 +- Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml | 415 -- Documentation/DocBook/media/v4l/pixfmt.xml| 56 +++- Documentation/DocBook/media/v4l/v4l2.xml | 8 + Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml | 12 +- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 6 + drivers/media/parport/bw-qcam.c | 2 - drivers/media/pci/cx18/cx18-ioctl.c | 1 - drivers/media/pci/cx25821/cx25821-video.c | 3 - drivers/media/pci/ivtv/ivtv-ioctl.c | 3 - drivers/media/pci/meye/meye.c | 2 - drivers/media/pci/saa7134/saa7134-empress.c | 3 - drivers/media/pci/saa7134/saa7134-video.c | 2 - drivers/media/pci/sta2x11/sta2x11_vip.c | 1 - drivers/media/platform/coda.c | 2 - drivers/media/platform/davinci/vpif_display.c | 1 - drivers/media/platform/mem2mem_testdev.c | 1 - drivers/media/platform/omap/omap_vout.c | 2 - drivers/media/platform/sh_veu.c | 2 - drivers/media/platform/vino.c | 5 - drivers/media/platform/vivi.c | 1 - drivers/media/platform/vsp1/vsp1.h| 14 +- drivers/media/platform/vsp1/vsp1_bru.c| 85 +- drivers/media/platform/vsp1/vsp1_bru.h| 9 +- drivers/media/platform/vsp1/vsp1_drv.c| 22 +- drivers/media/platform/vsp1/vsp1_entity.c | 42 +++ drivers/media/platform/vsp1/vsp1_entity.h | 10 + drivers/media/platform/vsp1/vsp1_regs.h | 2 + drivers/media/platform/vsp1/vsp1_rpf.c| 72 - drivers/media/platform/vsp1/vsp1_rwpf.h | 2 + drivers/media/platform/vsp1/vsp1_sru.c| 107 --- drivers/media/platform/vsp1/vsp1_sru.h| 1 - drivers/media/platform/vsp1/vsp1_uds.c| 63 ++-- drivers/media/platform/vsp1/vsp1_uds.h| 6 +- drivers/media/platform/vsp1/vsp1_video.c | 217 ++ drivers/media/platform/vsp1/vsp1_video.h | 10 +- drivers/media/platform/vsp1/vsp1_wpf.c| 72 - drivers/media/usb/cx231xx/cx231xx-417.c | 2 - drivers/media/usb/cx231xx/cx231xx-video.c | 2 - drivers/media/usb/gspca/gspca.c | 8 +- drivers/media/usb/hdpvr/hdpvr-video.c | 1 - drivers/media/usb/stkwebcam/stk-webcam.c | 2 - drivers/media/usb/tlg2300/pd-video.c | 1 - drivers/media/usb/tm6000/tm6000-video.c | 2 - drivers/media/usb/zr364xx/zr364xx.c | 3 - drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 19 +- drivers/media/v4l2-core/v4l2-ioctl.c | 70 - drivers/media/v4l2-core/video
Re: [PATCH 3/4] media: rcar_vin: Fix race condition terminating stream
On Tue, Jul 08, 2014 at 08:09:58PM +0400, Sergei Shtylyov wrote: > Hello. > > On 07/08/2014 01:41 PM, Ian Molton wrote: > > >This patch fixes a race condition whereby a frame being captured may > >generate an > > interrupt between requesting capture to halt and freeing buffers. > > >This condition is exposed by the earlier patch that explicitly calls > >vb2_buffer_done() during stop streaming. > > >The solution is to wait for capture to finish prior to finalising these > >buffers. > >Hm, my spell checker trips on "finalising"... I believe it is a valid spelling of the word in question. > > >Signed-off-by: Ian Molton > >Signed-off-by: William Towle > >--- > > drivers/media/platform/soc_camera/rcar_vin.c | 43 > > ++-- > > 1 file changed, 28 insertions(+), 15 deletions(-) > > >diff --git a/drivers/media/platform/soc_camera/rcar_vin.c > >b/drivers/media/platform/soc_camera/rcar_vin.c > >index 06ce705..aeda4e2 100644 > >--- a/drivers/media/platform/soc_camera/rcar_vin.c > >+++ b/drivers/media/platform/soc_camera/rcar_vin.c > [...] > >@@ -462,7 +485,6 @@ static void rcar_vin_videobuf_release(struct vb2_buffer > >*vb) > > struct rcar_vin_priv *priv = ici->priv; > > unsigned int i; > > int buf_in_use = 0; > >- > > spin_lock_irq(&priv->lock); > >This seems like a random whitespace change. This empty should be present. > > [...] > >@@ -517,12 +527,15 @@ static void rcar_vin_stop_streaming(struct vb2_queue > >*vq) > > > > spin_lock_irq(&priv->lock); > > > >+rcar_vin_wait_stop_streaming(priv); > >+ > > for (i = 0; i < vq->num_buffers; ++i) > > if (vq->bufs[i]->state == VB2_BUF_STATE_ACTIVE) > > vb2_buffer_done(vq->bufs[i], VB2_BUF_STATE_ERROR); > > > > list_for_each_safe(buf_head, tmp, &priv->capture) > > list_del_init(buf_head); > >+ > >Also quite a random "drove-by" change. > > > spin_unlock_irq(&priv->lock); > > } > > WBR, Sergei > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" 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
