cron job: media_tree daily build: OK

2014-07-09 Thread Hans Verkuil
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

2014-07-09 Thread Greg Kroah-Hartman
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

2014-07-09 Thread Laurent Pinchart
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()

2014-07-09 Thread Joe Perches
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()

2014-07-09 Thread Marek Vasut
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

2014-07-09 Thread Andy Shevchenko
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

2014-07-09 Thread Shuah Khan
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

2014-07-09 Thread Shuah Khan
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

2014-07-09 Thread Guennadi Liakhovetski
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

2014-07-09 Thread Quentin Denis
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

2014-07-09 Thread Andre Newman

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

2014-07-09 Thread Antti Palosaari

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

2014-07-09 Thread Joe Perches
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

2014-07-09 Thread Joe Perches
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()

2014-07-09 Thread Steven Toth
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

2014-07-09 Thread Ian Molton
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

2014-07-09 Thread Sakari Ailus
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

2014-07-09 Thread Enric Balletbo Serra
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

2014-07-09 Thread Andy Shevchenko
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

2014-07-09 Thread Andy Shevchenko
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

2014-07-09 Thread Andy Shevchenko
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()

2014-07-09 Thread Andy Shevchenko
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()

2014-07-09 Thread Andy Shevchenko
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

2014-07-09 Thread Andy Shevchenko
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

2014-07-09 Thread Andre Newman
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

2014-07-09 Thread Anil Shashikumar Belur

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

2014-07-09 Thread Shuah Khan
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

2014-07-09 Thread Devin Heitmueller
> 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

2014-07-09 Thread Lukas Tribus
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

2014-07-09 Thread Rafael Coutinho
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

2014-07-09 Thread Pavel Machek
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

2014-07-09 Thread Pavel Machek
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

2014-07-09 Thread Hans Verkuil
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

2014-07-09 Thread Divneil Wadhawan
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

2014-07-09 Thread Quentin Denis
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

2014-07-09 Thread Hans de Goede
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

2014-07-09 Thread Laurent Pinchart
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

2014-07-09 Thread Simon Horman
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