date:20140801

Re: ddbridge -- kernel 3.15.6

2014-08-01 Thread Thomas Kaiser


On 08/01/2014 07:08 AM, Georgi Chorbadzhiyski wrote:

On 8/1/14 7:54 AM, Bjoern wrote:

On Do, 2014-07-31 at 09:38 +0200, Ralph Metzler wrote:



It is not like drivers are not available and supported, just
not in the mainline kernel tree.


Right... and I hope that can be changed. I really really like the DD
hardware I have, but always having to rebuild everything with a new
kernel is just not my idea of how hardware should run in 2014 on Linux
anymore.


I have more than 30 ddbridge dvb-s devices and more than 30 dvb-c/t devices.

The fact that the drivers are not in the main tree is the biggest problem
with these devices. The hardware is great (never had a problem with it)
but having to install experimental media build is just stupid.

When I bought the devices I knew that the driver is not in the main tree
but I really hoped that this would change. Now 3 years later it is still
not the case. That's bullshit.

Come on Digital Devices, you have the drivers, please, pretty please, submit
them upstream, go through the merge process and make us - our clients a
happy bunch.

Like Bjoern said, it's 2014, you have the drivers, keeping them out
of main kernel and having your customers go through hoops to get them
working is not acceptable.



I would love to see the driver in the kernel mainline tree for the above 
mentioned reasons!

Thomas


--
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: s5p_mfc_dec: delete the redundant code

2014-08-01 Thread panpan liu

Because the api s5p_mfc_queue_setup has already realized the same function

Signed-off-by: panpan liu 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c

--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -544,14 +544,7 @@ static int vidioc_reqbufs(struct file *file, void *priv,
mfc_err("vb2_reqbufs on capture failed\n");
return ret;
}
-   if (reqbufs->count < ctx->pb_count) {
-   mfc_err("Not enough buffers allocated\n");
-   reqbufs->count = 0;
-   s5p_mfc_clock_on();
-   ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
-   s5p_mfc_clock_off();
-   return -ENOMEM;
-   }
+
ctx->total_dpb_count = reqbufs->count;
ret = s5p_mfc_hw_call(dev->mfc_ops, alloc_codec_buffers, ctx);
if (ret) {
--
1.7.9.5

--
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: [PATCHv1 02/12] vivid.txt: add documentation for the vivid driver.

2014-08-01 Thread Hans Verkuil

On 07/31/2014 09:16 PM, Andy Walls wrote:
> On Wed, 2014-07-30 at 16:23 +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> The vivid Virtual Video Test Driver helps testing V4L2 applications
>> and can emulate V4L2 hardware. Add the documentation for this driver
>> first.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  Documentation/video4linux/vivid.txt | 1108 
>> +++
>>  1 file changed, 1108 insertions(+)
>>  create mode 100644 Documentation/video4linux/vivid.txt
>>
>> diff --git a/Documentation/video4linux/vivid.txt 
>> b/Documentation/video4linux/vivid.txt
>> new file mode 100644
>> index 000..2dc7354
>> --- /dev/null
>> +++ b/Documentation/video4linux/vivid.txt
>> @@ -0,0 +1,1108 @@
>> +vivid: Virtual Video Test Driver
>> +
> 
>> +
>> +Section 8: Software Defined Radio Receiver
>> +--
>> +
>> +The SDR receiver has three frequency bands for the ADC tuner:
>> +
>> +- 300 kHz
>> +- 900 kHz - 2800 kHz
>> +- 3200 kHz
>> +
>> +The RF tuner supports 50 MHz - 2000 MHz.
>> +
>> +The generated data contains sinus and cosinus signals.
>> +
> 
> In (American) English the names are "sine" and "cosine" for sin(x) and
> cos(x).

I knew that. Really :-)

One of the rare (I think) cases where my native Dutch interfered with English.

> 
> Maybe say:
> 
> "The generated data contains the In-phase and Quadrature components of a
> 1 kHz tone that has an amplitude of sqrt(2)."
> 
> FWIW, the signals are the In-phase and Quadrature components of the
> signal A*cos(2*pi*f + phi), where f = 1 kHz, A = sqrt(2), and phi =
> -pi/4
> 
>> +
>> +Section 15: Some Future Improvements
>> +
>> +
>> +Just as a reminder and in no particular order:
>> +
>> +- Add a virtual alsa driver to test audio
>> +- Add virtual sub-devices and media controller support
>> +- Some support for testing compressed video
>> +- Add support to loop raw VBI output to raw VBI input
>> +- Fix sequence/field numbering when looping of video with alternate fields
>> +- Add support for V4L2_CID_BG_COLOR for video outputs
>> +- Add ARGB888 overlay support: better testing of the alpha channel
>> +- Add custom DV timings support
>> +- Add support for V4L2_DV_FL_REDUCED_FPS
>> +- Improve pixel aspect support in the tpg code by passing a real v4l2_fract
>> +- Use per-queue locks and/or per-device locks to improve throughput
>> +- Add support to loop from a specific output to a specific input across
>> +  vivid instances
>> +- Add support for VIDIOC_EXPBUF once support for that has been added to vb2
>> +- The SDR radio should use the same 'frequencies' for stations as the normal
>> +  radio receiver, and give back noise if the frequency doesn't match up with
>> +  a station frequency
>> +- Improve the sinus generation of the SDR radio.
> 
> Maybe a lookup table, containing the first quarter wave of cos() from 0
> to pi/2 in pi/200 steps, and then linear interpolation for cos() of
> angles in between those steps.  You could go with a larger lookup table
> with finer grained steps to reduce the approximation errors.  A lookup
> table with linear interpolation, I would think, requires fewer
> mutliplies and divides than the current Taylor expansion computation.

Yeah, I had plans for that. There actually is a sine-table already in 
vivid-tpg.c
since I'm using that to implement Hue support.

Regards,

Hans

> 
> 
>> +- Make a thread for the RDS generation, that would help in particular for 
>> the
>> +  "Controls" RDS Rx I/O Mode as the read-only RDS controls could be updated
>> +  in real-time.
> 
> Regards,
> Andy
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media: s5p_mfc_dec: delete the redundant code

2014-08-01 Thread Joonyoung Shim

Hi,

On 08/01/2014 06:15 PM, panpan liu wrote:
> Because the api s5p_mfc_queue_setup has already realized the same function
> 
> Signed-off-by: panpan liu 
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> 
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -544,14 +544,7 @@ static int vidioc_reqbufs(struct file *file, void *priv,
>   mfc_err("vb2_reqbufs on capture failed\n");
>   return ret;
>   }
> - if (reqbufs->count < ctx->pb_count) {
> - mfc_err("Not enough buffers allocated\n");
> - reqbufs->count = 0;
> - s5p_mfc_clock_on();
> - ret = vb2_reqbufs(&ctx->vq_dst, reqbufs);
> - s5p_mfc_clock_off();
> - return -ENOMEM;
> - }
> +

As Hans said, you should always check the latest upstream kernel. Why do
you post patches based on old kernel at ML continuously?
--
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 for v3.17] videobuf2-dma-sg: fix for wrong GFP mask to sg_alloc_table_from_pages

2014-08-01 Thread Hans Verkuil

sg_alloc_table_from_pages() only allocates a sg_table, so it should just use
GFP_KERNEL, not gfp_flags. If gfp_flags contains __GFP_DMA32 then mm/sl[au]b.c
will call BUG_ON:

[  358.027515] [ cut here ]
[  358.027546] kernel BUG at mm/slub.c:1416!
[  358.027558] invalid opcode:  [#1] PREEMPT SMP 
[  358.027576] Modules linked in: mt2131 s5h1409 tda8290 tuner cx25840 cx23885 
btcx_risc altera_ci tda18271 altera_stapl videobuf2_dvb tveeprom cx2341x 
videobuf2_dma_sg dvb_core rc_core videobuf2_memops videobuf2_core nouveau 
zr36067 videocodec v4l2_common videodev media x86_pkg_temp_thermal cfbfillrect 
cfbimgblt cfbcopyarea ttm drm_kms_helper processor button isci
[  358.027712] CPU: 19 PID: 3654 Comm: cat Not tainted 3.16.0-rc6-telek #167
[  358.027723] Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 
5404 02/10/2014
[  358.027741] task: 880897c7d960 ti: 88089b4d4000 task.ti: 
88089b4d4000
[  358.027753] RIP: 0010:[]  [] 
new_slab+0x280/0x320
[  358.027776] RSP: 0018:88089b4d7ae8  EFLAGS: 00010002
[  358.027787] RAX: 880897c7d960 RBX:  RCX: 88089b4d7b50
[  358.027798] RDX:  RSI: 0004 RDI: 88089f803b00
[  358.027809] RBP: 88089b4d7bb8 R08:  R09: 000100400040
[  358.027821] R10: 1600 R11: 88109bc02c40 R12: 0001
[  358.027832] R13: 88089f8000c0 R14: 88089f803b00 R15: 8810bfcf4be0
[  358.027845] FS:  7f83fe5c0700() GS:8810bfce() 
knlGS:
[  358.027858] CS:  0010 DS:  ES:  CR0: 80050033
[  358.027868] CR2: 01dfd568 CR3: 001097d5a000 CR4: 000407e0
[  358.027878] Stack:
[  358.027885]  81198860 8810bfcf4be0 880897c7d960 
1b00
[  358.027905]  880897c7d960  8810bfcf4bf0 

[  358.027924]   00010100 813ef84a 
0004
[  358.027944] Call Trace:
[  358.027956]  [] ? __slab_alloc+0x400/0x4e0
[  358.027973]  [] ? sg_kmalloc+0x1a/0x30
[  358.027985]  [] __kmalloc+0x127/0x150
[  358.027997]  [] ? sg_kmalloc+0x1a/0x30
[  358.028009]  [] sg_kmalloc+0x1a/0x30
[  358.028023]  [] __sg_alloc_table+0x74/0x180
[  358.028035]  [] ? sg_kfree+0x20/0x20
[  358.028048]  [] sg_alloc_table+0x1f/0x60
[  358.028061]  [] sg_alloc_table_from_pages+0x84/0x1f0
[  358.028077]  [] vb2_dma_sg_alloc+0x159/0x230 
[videobuf2_dma_sg]
[  358.028095]  [] __vb2_queue_alloc+0x10a/0x680 
[videobuf2_core]
[  358.028113]  [] __reqbufs.isra.14+0x220/0x3e0 
[videobuf2_core]
[  358.028130]  [] __vb2_init_fileio+0xbd/0x380 
[videobuf2_core]
[  358.028147]  [] __vb2_perform_fileio+0x5b3/0x6e0 
[videobuf2_core]
[  358.028164]  [] vb2_fop_read+0xb1/0x100 [videobuf2_core]
[  358.028184]  [] v4l2_read+0x65/0xb0 [videodev]
[  358.028198]  [] vfs_read+0x8f/0x170
[  358.028210]  [] SyS_read+0x41/0xb0
[  358.028224]  [] system_call_fastpath+0x16/0x1b
[  358.028234] Code: 66 90 e9 dc fd ff ff 0f 1f 40 00 41 8b 4d 68 e9 d5 fe ff 
ff 0f 1f 80 00 00 00 00 f0 41 80 4d 00 40 e9 03 ff ff ff 0f 1f 44 00 00 <0f> 0b 
66 0f 1f 44 00 00 44 89 c6 4c 89 45 d0 e8 0c 82 ff ff 48 
[  358.028415] RIP  [] new_slab+0x280/0x320
[  358.028432]  RSP 
[  358.032208] ---[ end trace 6443240199c706e4 ]---

Signed-off-by: Hans Verkuil 
Cc: sta...@vger.kernel.org  # for v3.13 and up

diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index adefc31..9b163a4 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -113,7 +113,7 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned 
long size, gfp_t gfp_fla
goto fail_pages_alloc;
 
ret = sg_alloc_table_from_pages(&buf->sg_table, buf->pages,
-   buf->num_pages, 0, size, gfp_flags);
+   buf->num_pages, 0, size, GFP_KERNEL);
if (ret)
goto fail_table_alloc;
 
--
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 for v3.17] videobuf2-dma-sg: fix for wrong GFP mask to sg_alloc_table_from_pages

2014-08-01 Thread Marek Szyprowski


Hello,

On 2014-08-01 14:18, Hans Verkuil wrote:

sg_alloc_table_from_pages() only allocates a sg_table, so it should just use
GFP_KERNEL, not gfp_flags. If gfp_flags contains __GFP_DMA32 then mm/sl[au]b.c
will call BUG_ON:

[  358.027515] [ cut here ]
[  358.027546] kernel BUG at mm/slub.c:1416!
[  358.027558] invalid opcode:  [#1] PREEMPT SMP
[  358.027576] Modules linked in: mt2131 s5h1409 tda8290 tuner cx25840 cx23885 
btcx_risc altera_ci tda18271 altera_stapl videobuf2_dvb tveeprom cx2341x 
videobuf2_dma_sg dvb_core rc_core videobuf2_memops videobuf2_core nouveau 
zr36067 videocodec v4l2_common videodev media x86_pkg_temp_thermal cfbfillrect 
cfbimgblt cfbcopyarea ttm drm_kms_helper processor button isci
[  358.027712] CPU: 19 PID: 3654 Comm: cat Not tainted 3.16.0-rc6-telek #167
[  358.027723] Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 
5404 02/10/2014
[  358.027741] task: 880897c7d960 ti: 88089b4d4000 task.ti: 
88089b4d4000
[  358.027753] RIP: 0010:[]  [] 
new_slab+0x280/0x320
[  358.027776] RSP: 0018:88089b4d7ae8  EFLAGS: 00010002
[  358.027787] RAX: 880897c7d960 RBX:  RCX: 88089b4d7b50
[  358.027798] RDX:  RSI: 0004 RDI: 88089f803b00
[  358.027809] RBP: 88089b4d7bb8 R08:  R09: 000100400040
[  358.027821] R10: 1600 R11: 88109bc02c40 R12: 0001
[  358.027832] R13: 88089f8000c0 R14: 88089f803b00 R15: 8810bfcf4be0
[  358.027845] FS:  7f83fe5c0700() GS:8810bfce() 
knlGS:
[  358.027858] CS:  0010 DS:  ES:  CR0: 80050033
[  358.027868] CR2: 01dfd568 CR3: 001097d5a000 CR4: 000407e0
[  358.027878] Stack:
[  358.027885]  81198860 8810bfcf4be0 880897c7d960 
1b00
[  358.027905]  880897c7d960  8810bfcf4bf0 

[  358.027924]   00010100 813ef84a 
0004
[  358.027944] Call Trace:
[  358.027956]  [] ? __slab_alloc+0x400/0x4e0
[  358.027973]  [] ? sg_kmalloc+0x1a/0x30
[  358.027985]  [] __kmalloc+0x127/0x150
[  358.027997]  [] ? sg_kmalloc+0x1a/0x30
[  358.028009]  [] sg_kmalloc+0x1a/0x30
[  358.028023]  [] __sg_alloc_table+0x74/0x180
[  358.028035]  [] ? sg_kfree+0x20/0x20
[  358.028048]  [] sg_alloc_table+0x1f/0x60
[  358.028061]  [] sg_alloc_table_from_pages+0x84/0x1f0
[  358.028077]  [] vb2_dma_sg_alloc+0x159/0x230 
[videobuf2_dma_sg]
[  358.028095]  [] __vb2_queue_alloc+0x10a/0x680 
[videobuf2_core]
[  358.028113]  [] __reqbufs.isra.14+0x220/0x3e0 
[videobuf2_core]
[  358.028130]  [] __vb2_init_fileio+0xbd/0x380 
[videobuf2_core]
[  358.028147]  [] __vb2_perform_fileio+0x5b3/0x6e0 
[videobuf2_core]
[  358.028164]  [] vb2_fop_read+0xb1/0x100 [videobuf2_core]
[  358.028184]  [] v4l2_read+0x65/0xb0 [videodev]
[  358.028198]  [] vfs_read+0x8f/0x170
[  358.028210]  [] SyS_read+0x41/0xb0
[  358.028224]  [] system_call_fastpath+0x16/0x1b
[  358.028234] Code: 66 90 e9 dc fd ff ff 0f 1f 40 00 41 8b 4d 68 e9 d5 fe ff ff 0f 
1f 80 00 00 00 00 f0 41 80 4d 00 40 e9 03 ff ff ff 0f 1f 44 00 00 <0f> 0b 66 0f 
1f 44 00 00 44 89 c6 4c 89 45 d0 e8 0c 82 ff ff 48
[  358.028415] RIP  [] new_slab+0x280/0x320
[  358.028432]  RSP 
[  358.032208] ---[ end trace 6443240199c706e4 ]---

Signed-off-by: Hans Verkuil 
Cc: sta...@vger.kernel.org  # for v3.13 and up


Acked-by: Marek Szyprowski 


diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c 
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index adefc31..9b163a4 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -113,7 +113,7 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned 
long size, gfp_t gfp_fla
goto fail_pages_alloc;
  
  	ret = sg_alloc_table_from_pages(&buf->sg_table, buf->pages,

-   buf->num_pages, 0, size, gfp_flags);
+   buf->num_pages, 0, size, GFP_KERNEL);
if (ret)
goto fail_table_alloc;
  


Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL FOR 3.17] smiapp: use unlocked control functions

2014-08-01 Thread Sakari Ailus

Hi Mauro,

This set makes use of unlocked controls functions in the smiapp driver.
Please pull.

The following changes since commit 27dcb00d0dc1d532b0da940e35a6d020ee33bd47:

  [media] radio-miropcm20: fix sparse NULL pointer warning (2014-07-30 19:50:09 
-0300)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git unlocked-ctrls

for you to fetch changes up to c2685f81e4d37ab93523a20246b95a63e47d7fcc:

  smiapp: Set 64-bit integer control using v4l2_ctrl_s_ctrl_int64() (2014-08-01 
12:27:42 +0300)


Sakari Ailus (2):
  smiapp: Use unlocked __v4l2_ctrl_modify_range()
  smiapp: Set 64-bit integer control using v4l2_ctrl_s_ctrl_int64()

 drivers/media/i2c/smiapp/smiapp-core.c |   56 +---
 1 file changed, 22 insertions(+), 34 deletions(-)

-- 
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

[PATCH 1/8] omap3isp: ccdc: Disable the video port when unused

2014-08-01 Thread Laurent Pinchart

The video port doesn't support YUV formats. Disable it when the CCDC
sink pad format is set to YUV instead of leaving it enabled and relying
on downstream modules not to process data they receive from the video
port.

Experiments showed that this fixes some of the CCDC failures to stop,
especially in BT.656 mode.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/omap3isp/ispccdc.c | 70 +--
 1 file changed, 29 insertions(+), 41 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index 150bbf0..ecc37f2 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -808,29 +808,48 @@ static void ccdc_config_vp(struct isp_ccdc_device *ccdc)
struct isp_pipeline *pipe = to_isp_pipeline(&ccdc->subdev.entity);
struct isp_device *isp = to_isp_device(ccdc);
const struct isp_format_info *info;
+   struct v4l2_mbus_framefmt *format;
unsigned long l3_ick = pipe->l3_ick;
unsigned int max_div = isp->revision == ISP_REVISION_15_0 ? 64 : 8;
unsigned int div = 0;
-   u32 fmtcfg_vp;
+   u32 fmtcfg = ISPCCDC_FMTCFG_VPEN;
+
+   format = &ccdc->formats[CCDC_PAD_SOURCE_VP];
+
+   if (!format->code) {
+   /* Disable the video port when the input format isn't supported.
+* This is indicated by a pixel code set to 0.
+*/
+   isp_reg_writel(isp, 0, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMTCFG);
+   return;
+   }
+
+   isp_reg_writel(isp, (0 << ISPCCDC_FMT_HORZ_FMTSPH_SHIFT) |
+  (format->width << ISPCCDC_FMT_HORZ_FMTLNH_SHIFT),
+  OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_HORZ);
+   isp_reg_writel(isp, (0 << ISPCCDC_FMT_VERT_FMTSLV_SHIFT) |
+  ((format->height + 1) << ISPCCDC_FMT_VERT_FMTLNV_SHIFT),
+  OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_VERT);
 
-   fmtcfg_vp = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMTCFG)
- & ~(ISPCCDC_FMTCFG_VPIN_MASK | ISPCCDC_FMTCFG_VPIF_FRQ_MASK);
+   isp_reg_writel(isp, (format->width << ISPCCDC_VP_OUT_HORZ_NUM_SHIFT) |
+  (format->height << ISPCCDC_VP_OUT_VERT_NUM_SHIFT),
+  OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VP_OUT);
 
info = omap3isp_video_format_info(ccdc->formats[CCDC_PAD_SINK].code);
 
switch (info->width) {
case 8:
case 10:
-   fmtcfg_vp |= ISPCCDC_FMTCFG_VPIN_9_0;
+   fmtcfg |= ISPCCDC_FMTCFG_VPIN_9_0;
break;
case 11:
-   fmtcfg_vp |= ISPCCDC_FMTCFG_VPIN_10_1;
+   fmtcfg |= ISPCCDC_FMTCFG_VPIN_10_1;
break;
case 12:
-   fmtcfg_vp |= ISPCCDC_FMTCFG_VPIN_11_2;
+   fmtcfg |= ISPCCDC_FMTCFG_VPIN_11_2;
break;
case 13:
-   fmtcfg_vp |= ISPCCDC_FMTCFG_VPIN_12_3;
+   fmtcfg |= ISPCCDC_FMTCFG_VPIN_12_3;
break;
}
 
@@ -840,24 +859,9 @@ static void ccdc_config_vp(struct isp_ccdc_device *ccdc)
div = l3_ick / pipe->external_rate;
 
div = clamp(div, 2U, max_div);
-   fmtcfg_vp |= (div - 2) << ISPCCDC_FMTCFG_VPIF_FRQ_SHIFT;
+   fmtcfg |= (div - 2) << ISPCCDC_FMTCFG_VPIF_FRQ_SHIFT;
 
-   isp_reg_writel(isp, fmtcfg_vp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMTCFG);
-}
-
-/*
- * ccdc_enable_vp - Enable Video Port.
- * @ccdc: Pointer to ISP CCDC device.
- * @enable: 0 Disables VP, 1 Enables VP
- *
- * This is needed for outputting image to Preview, H3A and HIST ISP submodules.
- */
-static void ccdc_enable_vp(struct isp_ccdc_device *ccdc, u8 enable)
-{
-   struct isp_device *isp = to_isp_device(ccdc);
-
-   isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMTCFG,
-   ISPCCDC_FMTCFG_VPEN, enable ? ISPCCDC_FMTCFG_VPEN : 0);
+   isp_reg_writel(isp, fmtcfg, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMTCFG);
 }
 
 /*
@@ -1282,18 +1286,7 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
 
/* CCDC_PAD_SOURCE_VP */
-   format = &ccdc->formats[CCDC_PAD_SOURCE_VP];
-
-   isp_reg_writel(isp, (0 << ISPCCDC_FMT_HORZ_FMTSPH_SHIFT) |
-  (format->width << ISPCCDC_FMT_HORZ_FMTLNH_SHIFT),
-  OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_HORZ);
-   isp_reg_writel(isp, (0 << ISPCCDC_FMT_VERT_FMTSLV_SHIFT) |
-  ((format->height + 1) << ISPCCDC_FMT_VERT_FMTLNV_SHIFT),
-  OMAP3_ISP_IOMEM_CCDC, ISPCCDC_FMT_VERT);
-
-   isp_reg_writel(isp, (format->width << ISPCCDC_VP_OUT_HORZ_NUM_SHIFT) |
-  (format->height << ISPCCDC_VP_OUT_VERT_NUM_SHIFT),
-  OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VP_OUT);
+   ccdc_config_vp(ccdc);
 
/* Lens shading corr

[PATCH 8/8] omap3isp: ccdc: Restart the CCDC immediately after an underrun in BT.656

2014-08-01 Thread Laurent Pinchart

As the CCDC doesn't generate interrupts when stopped in BT.656 mode,
restart it immediately when the next buffer after an underrun is queued
instead of relying on the interrupt handler to restart the CCDC.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/omap3isp/ispccdc.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index ec0a0e8..cabf46b 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1789,6 +1789,8 @@ int omap3isp_ccdc_isr(struct isp_ccdc_device *ccdc, u32 
events)
 static int ccdc_video_queue(struct isp_video *video, struct isp_buffer *buffer)
 {
struct isp_ccdc_device *ccdc = &video->isp->isp_ccdc;
+   unsigned long flags;
+   bool restart = false;
 
if (!(ccdc->output & CCDC_OUTPUT_MEMORY))
return -ENODEV;
@@ -1797,9 +1799,20 @@ static int ccdc_video_queue(struct isp_video *video, 
struct isp_buffer *buffer)
 
/* We now have a buffer queued on the output, restart the pipeline
 * on the next CCDC interrupt if running in continuous mode (or when
-* starting the stream).
+* starting the stream) in external sync mode, or immediately in BT.656
+* sync mode as no CCDC interrupt is generated when the CCDC is stopped
+* in that case.
 */
-   ccdc->underrun = 1;
+   spin_lock_irqsave(&ccdc->lock, flags);
+   if (ccdc->state == ISP_PIPELINE_STREAM_CONTINUOUS && !ccdc->running &&
+   ccdc->bt656)
+   restart = 1;
+   else
+   ccdc->underrun = 1;
+   spin_unlock_irqrestore(&ccdc->lock, flags);
+
+   if (restart)
+   ccdc_enable(ccdc);
 
return 0;
 }
-- 
1.8.5.5

--
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 6/8] omap3isp: ccdc: Fix freeze when a short frame is received

2014-08-01 Thread Laurent Pinchart

In BT.656 mode the synchronization signals are generated by the CCDC
from the embedded sync codes. The VD0 and VD1 interrupts are thus only
triggered when the CCDC is enabled, unlike external sync mode where the
line counter runs even when the CCDC is stopped. We can't disable the
CCDC at VD1 time, as no VD0 interrupt would be generated for a short
frame, which would result in the CCDC being stopped and no VD interrupt
generated anymore. The CCDC is stopped from the VD0 interrupt handler
instead for BT.656.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/omap3isp/ispccdc.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index 112bced..ff2ea2b 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1647,10 +1647,27 @@ static void ccdc_vd0_isr(struct isp_ccdc_device *ccdc)
atomic_inc(&pipe->frame_number);
}
 
+   /* Emulate a VD1 interrupt for BT.656 mode, as we can't stop the CCDC in
+* the VD1 interrupt handler in that mode without risking a CCDC stall
+* if a short frame is received.
+*/
+   if (ccdc->bt656) {
+   spin_lock_irqsave(&ccdc->lock, flags);
+   if (ccdc->state == ISP_PIPELINE_STREAM_CONTINUOUS &&
+   ccdc->output & CCDC_OUTPUT_MEMORY) {
+   if (ccdc->lsc.state != LSC_STATE_STOPPED)
+   __ccdc_lsc_enable(ccdc, 0);
+   __ccdc_enable(ccdc, 0);
+   }
+   ccdc_handle_stopping(ccdc, CCDC_EVENT_VD1);
+   spin_unlock_irqrestore(&ccdc->lock, flags);
+   }
+
if (ccdc->output & CCDC_OUTPUT_MEMORY)
restart = ccdc_isr_buffer(ccdc);
 
spin_lock_irqsave(&ccdc->lock, flags);
+
if (ccdc_handle_stopping(ccdc, CCDC_EVENT_VD0)) {
spin_unlock_irqrestore(&ccdc->lock, flags);
return;
@@ -1672,6 +1689,18 @@ static void ccdc_vd1_isr(struct isp_ccdc_device *ccdc)
 {
unsigned long flags;
 
+   /* In BT.656 mode the synchronization signals are generated by the CCDC
+* from the embedded sync codes. The VD0 and VD1 interrupts are thus
+* only triggered when the CCDC is enabled, unlike external sync mode
+* where the line counter runs even when the CCDC is stopped. We can't
+* disable the CCDC at VD1 time, as no VD0 interrupt would be generated
+* for a short frame, which would result in the CCDC being stopped and
+* no VD interrupt generated anymore. The CCDC is stopped from the VD0
+* interrupt handler instead for BT.656.
+*/
+   if (ccdc->bt656)
+   return;
+
spin_lock_irqsave(&ccdc->lsc.req_lock, flags);
 
/*
-- 
1.8.5.5

--
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 00/11] OMAP3 ISP BT.656 support

2014-08-01 Thread Laurent Pinchart

Hi Enrico,

On Thursday 31 July 2014 12:21:09 Enrico wrote:
> On Wed, Jul 30, 2014 at 11:01 PM, Laurent Pinchart wrote:
> > On Wednesday 23 July 2014 15:57:51 Enrico wrote:
> >> On Wed, Jul 23, 2014 at 3:54 PM, Enrico wrote:
> >
> > [snip]
> > 
> >> > You were right i was using the wrong binary, now the output is:
> >> > 
> >> > ...
> >> > - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
> >> > type V4L2 subdev subtype Unknown flags 0
> >> > device node name /dev/v4l-subdev2
> >> > pad0: Sink
> >> > [fmt:UYVY2X8/720x625 field:interlaced]
> >> > ...
> >> > pad1: Source
> >> > [fmt:UYVY/720x624 field:interlaced
> >> >  crop.bounds:(0,0)/720x624
> >> >  crop:(0,0)/720x624]
> >> > ...
> >> > - entity 16: tvp5150 1-005c (1 pad, 1 link)
> >> >  type V4L2 subdev subtype Unknown flags 0
> >> >  device node name /dev/v4l-subdev8
> >> > pad0: Source
> >> > [fmt:UYVY2X8/720x625 field:interlaced]
> > 
> > That's surprising. Have you applied the tvp5150 patches from the
> > omap3isp/bt656 branch ? The field should be hardcoded to
> > V4L2_FIELD_ALTERNATE (reported as "alternate" by media-ctl), as the
> > tvp5150 alternates between the top and bottom fields in consecutive
> > frames. The CCDC input should then be configured to V4L2_FIELD_ALTERNATE
> > as well, and the CCDC output to V4L2_FIELD_ALTERNATE ("alternate"),
> > V4L2_FIELD_INTERLACED_TB ("interlaced-tb") or V4L2_FIELD_INTERLACED_BT
> > ("interlaced-bt").
> 
> No, i missed those patches i was using only the omap3isp patches you
> posted here.
> With those patches and configuring the pipleline as you suggested i
> could finally capture some good frames with yavta.
> 
> But i think there is some race, because it's not very "reliable". This
> is what i see:
> 
> (with yavta -c50 -f UYVY -s 720x576 --field interlaced-tb /dev/video2)
> 
> 1) first run, ok
> 
> 2) if i re-run it soon after it finishes, it just hangs on start (in
> VIDIOC_DQBUF).
> I have to stop it with ctrl+c and after some seconds it exits, and the
> kernel prints the ccdc stop timeout message.
> 
> in any case when it doesn't hang i can capture 200 frames with no
> errors. And if i wait some seconds before running it again it usually
> works (not always).
> 
> 3) if i add -F to yavta (saving to a tmpfs in ram), it hangs after
> capturing some frames (usually between 20 and 30).
> yet again, same ctrl+c thing (it exits, ccdc stop timeout...).
>
> Apart from these issues your patches are much better then the old ones!

Thank you. Feel free to ack them if you want ;-) I'd like to get them merged 
in v3.18, even if they're not perfect, provided they don't cause regressions 
in the non-BT.656 case.

> Any hints on what i can try to fix these issues?

I've just sent a patch series that might help (you've been CC'ed). Lucky you 
;-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/8] OMAP3 ISP CCDC fixes

2014-08-01 Thread Laurent Pinchart

Hello,

This patch series fixes several stability issues related to the CCDC,
especially (but not exclusively) in BT.656 mode.

The patches apply on top of the OMAP3 ISP CCDC BT.656 mode support series
previously posted. You can find both series at

git://linuxtv.org/pinchartl/media.git omap3isp/bt656

I'm not sure to be completely happy with the last three patches. The CCDC
state machine is getting too complex for my tastes, race conditions becoming
too hard to spot. This doesn't mean the code is wrong, but a rewrite of the
state machine will probably needed sooner than later.

Laurent Pinchart (8):
  omap3isp: ccdc: Disable the video port when unused
  omap3isp: ccdc: Only complete buffer when all fields are captured
  omap3isp: ccdc: Rename __ccdc_handle_stopping to ccdc_handle_stopping
  omap3isp: ccdc: Simplify ccdc_lsc_is_configured()
  omap3isp: ccdc: Increment the frame number at VD0 time for BT.656
  omap3isp: ccdc: Fix freeze when a short frame is received
  omap3isp: ccdc: Don't timeout on stream off when the CCDC is stopped
  omap3isp: ccdc: Restart the CCDC immediately after an underrun in
BT.656

 drivers/media/platform/omap3isp/ispccdc.c | 233 +++---
 drivers/media/platform/omap3isp/ispccdc.h |   9 ++
 2 files changed, 154 insertions(+), 88 deletions(-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/8] omap3isp: ccdc: Increment the frame number at VD0 time for BT.656

2014-08-01 Thread Laurent Pinchart

We will stop using VD1 in BT.656 mode, move frame number increment to
the VD0 interrupt handler.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/omap3isp/ispccdc.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index 6a62cb7..112bced 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1637,6 +1637,16 @@ static void ccdc_vd0_isr(struct isp_ccdc_device *ccdc)
unsigned long flags;
int restart = 0;
 
+   /* In BT.656 mode the CCDC doesn't generate an HS/VS interrupt. We thus
+* need to increment the frame counter here.
+*/
+   if (ccdc->bt656) {
+   struct isp_pipeline *pipe =
+   to_isp_pipeline(&ccdc->subdev.entity);
+
+   atomic_inc(&pipe->frame_number);
+   }
+
if (ccdc->output & CCDC_OUTPUT_MEMORY)
restart = ccdc_isr_buffer(ccdc);
 
@@ -1662,16 +1672,6 @@ static void ccdc_vd1_isr(struct isp_ccdc_device *ccdc)
 {
unsigned long flags;
 
-   /* In BT.656 mode the CCDC doesn't generate an HS/VS interrupt. We thus
-* need to increment the frame counter here.
-*/
-   if (ccdc->bt656) {
-   struct isp_pipeline *pipe =
-   to_isp_pipeline(&ccdc->subdev.entity);
-
-   atomic_inc(&pipe->frame_number);
-   }
-
spin_lock_irqsave(&ccdc->lsc.req_lock, flags);
 
/*
-- 
1.8.5.5

--
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 7/8] omap3isp: ccdc: Don't timeout on stream off when the CCDC is stopped

2014-08-01 Thread Laurent Pinchart

When the CCDC is already stopped due to a buffer underrun, the stop
state machine won't advance in BT.656 mode as no interrupt are generated
by the stopped CCDC in that mode. Handle this case explicitly in the
ccdc_disable() function.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/omap3isp/ispccdc.c | 4 
 drivers/media/platform/omap3isp/ispccdc.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index ff2ea2b..ec0a0e8 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1320,6 +1320,8 @@ static void __ccdc_enable(struct isp_ccdc_device *ccdc, 
int enable)
 
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_PCR,
ISPCCDC_PCR_EN, enable ? ISPCCDC_PCR_EN : 0);
+
+   ccdc->running = enable;
 }
 
 static int ccdc_disable(struct isp_ccdc_device *ccdc)
@@ -1330,6 +1332,8 @@ static int ccdc_disable(struct isp_ccdc_device *ccdc)
spin_lock_irqsave(&ccdc->lock, flags);
if (ccdc->state == ISP_PIPELINE_STREAM_CONTINUOUS)
ccdc->stopping = CCDC_STOP_REQUEST;
+   if (!ccdc->running)
+   ccdc->stopping = CCDC_STOP_FINISHED;
spin_unlock_irqrestore(&ccdc->lock, flags);
 
ret = wait_event_timeout(ccdc->wait,
diff --git a/drivers/media/platform/omap3isp/ispccdc.h 
b/drivers/media/platform/omap3isp/ispccdc.h
index 731ecc7..3440a70 100644
--- a/drivers/media/platform/omap3isp/ispccdc.h
+++ b/drivers/media/platform/omap3isp/ispccdc.h
@@ -124,6 +124,7 @@ struct ispccdc_lsc {
  * @lock: Serializes shadow_update with interrupt handler
  * @wait: Wait queue used to stop the module
  * @stopping: Stopping state
+ * @running: Is the CCDC hardware running
  * @ioctl_lock: Serializes ioctl calls and LSC requests freeing
  */
 struct isp_ccdc_device {
@@ -155,6 +156,7 @@ struct isp_ccdc_device {
spinlock_t lock;
wait_queue_head_t wait;
unsigned int stopping;
+   bool running;
struct mutex ioctl_lock;
 };
 
-- 
1.8.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/8] omap3isp: ccdc: Simplify ccdc_lsc_is_configured()

2014-08-01 Thread Laurent Pinchart

Use a local variable to avoid the duplicate spin_unlock_irqrestore()
call.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/omap3isp/ispccdc.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index cd62d29..6a62cb7 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -481,14 +481,13 @@ done:
 static inline int ccdc_lsc_is_configured(struct isp_ccdc_device *ccdc)
 {
unsigned long flags;
+   int ret;
 
spin_lock_irqsave(&ccdc->lsc.req_lock, flags);
-   if (ccdc->lsc.active) {
-   spin_unlock_irqrestore(&ccdc->lsc.req_lock, flags);
-   return 1;
-   }
+   ret = ccdc->lsc.active != NULL;
spin_unlock_irqrestore(&ccdc->lsc.req_lock, flags);
-   return 0;
+
+   return ret;
 }
 
 static int ccdc_lsc_enable(struct isp_ccdc_device *ccdc)
-- 
1.8.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/8] omap3isp: ccdc: Only complete buffer when all fields are captured

2014-08-01 Thread Laurent Pinchart

Checking that the captured field corresponds to the last required field
depending on the requested field order before completing the buffer
isn't enough. When the first field at stream start corresponds to the
last required field, this would result in returning an interlaced buffer
containing a single field.

Fix this by keeping track of the fields captured in the buffer, and make
sure that both fields are present for alternate field orders.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/omap3isp/ispccdc.c | 78 ---
 drivers/media/platform/omap3isp/ispccdc.h |  7 +++
 2 files changed, 58 insertions(+), 27 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index ecc37f2..56c3129 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1134,6 +1134,7 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
u32 ccdc_pattern;
 
ccdc->bt656 = false;
+   ccdc->fields = 0;
 
pad = media_entity_remote_pad(&ccdc->pads[CCDC_PAD_SINK]);
sensor = media_entity_to_v4l2_subdev(pad->entity);
@@ -1529,12 +1530,59 @@ done:
spin_unlock_irqrestore(&ccdc->lsc.req_lock, flags);
 }
 
+/*
+ * Check whether the CCDC has captured all fields necessary to complete the
+ * buffer.
+ */
+static bool ccdc_has_all_fields(struct isp_ccdc_device *ccdc)
+{
+   struct isp_pipeline *pipe = to_isp_pipeline(&ccdc->subdev.entity);
+   struct isp_device *isp = to_isp_device(ccdc);
+   enum v4l2_field of_field = ccdc->formats[CCDC_PAD_SOURCE_OF].field;
+   enum v4l2_field field;
+
+   /* When the input is progressive fields don't matter. */
+   if (of_field == V4L2_FIELD_NONE)
+   return true;
+
+   /* Read the current field identifier. */
+   field = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE)
+ & ISPCCDC_SYN_MODE_FLDSTAT
+ ? V4L2_FIELD_BOTTOM : V4L2_FIELD_TOP;
+
+   /* When capturing fields in alternate order just store the current field
+* identifier in the pipeline.
+*/
+   if (of_field == V4L2_FIELD_ALTERNATE) {
+   pipe->field = field;
+   return true;
+   }
+
+   /* The format is interlaced. Make sure we've captured both fields. */
+   ccdc->fields |= field == V4L2_FIELD_BOTTOM
+ ? CCDC_FIELD_BOTTOM : CCDC_FIELD_TOP;
+
+   if (ccdc->fields != CCDC_FIELD_BOTH)
+   return false;
+
+   /* Verify that the field just captured corresponds to the last field
+* needed based on the desired field order.
+*/
+   if ((of_field == V4L2_FIELD_INTERLACED_TB && field == V4L2_FIELD_TOP) ||
+   (of_field == V4L2_FIELD_INTERLACED_BT && field == 
V4L2_FIELD_BOTTOM))
+   return false;
+
+   /* The buffer can be completed, reset the fields for the next buffer. */
+   ccdc->fields = 0;
+
+   return true;
+}
+
 static int ccdc_isr_buffer(struct isp_ccdc_device *ccdc)
 {
struct isp_pipeline *pipe = to_isp_pipeline(&ccdc->subdev.entity);
struct isp_device *isp = to_isp_device(ccdc);
struct isp_buffer *buffer;
-   enum v4l2_field field;
 
/* The CCDC generates VD0 interrupts even when disabled (the datasheet
 * doesn't explicitly state if that's supposed to happen or not, so it
@@ -1554,11 +1602,6 @@ static int ccdc_isr_buffer(struct isp_ccdc_device *ccdc)
return 1;
}
 
-   /* Read the current field identifier. */
-   field = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE)
- & ISPCCDC_SYN_MODE_FLDSTAT
- ? V4L2_FIELD_BOTTOM : V4L2_FIELD_TOP;
-
/* Wait for the CCDC to become idle. */
if (ccdc_sbl_wait_idle(ccdc, 1000)) {
dev_info(isp->dev, "CCDC won't become idle!\n");
@@ -1567,27 +1610,8 @@ static int ccdc_isr_buffer(struct isp_ccdc_device *ccdc)
return 0;
}
 
-   switch (ccdc->formats[CCDC_PAD_SOURCE_OF].field) {
-   case V4L2_FIELD_ALTERNATE:
-   /* When capturing fields in alternate order store the current
-* field identifier in the pipeline.
-*/
-   pipe->field = field;
-   break;
-
-   case V4L2_FIELD_INTERLACED_TB:
-   /* When interleaving fields only complete the buffer after
-* capturing the second field.
-*/
-   if (field == V4L2_FIELD_TOP)
-   return 1;
-   break;
-
-   case V4L2_FIELD_INTERLACED_BT:
-   if (field == V4L2_FIELD_BOTTOM)
-   return 1;
-   break;
-   }
+   if (!ccdc_has_all_fields(ccdc))
+   return 1;
 
buffer = omap3isp_video_buffer_next(&ccdc->video_out);
if (buffer != NULL)
diff --git a/drivers/media/p

[PATCH 3/8] omap3isp: ccdc: Rename __ccdc_handle_stopping to ccdc_handle_stopping

2014-08-01 Thread Laurent Pinchart

There's no need for a double underscore in the function name, remove it.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/omap3isp/ispccdc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index 56c3129..cd62d29 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1413,14 +1413,14 @@ static int ccdc_sbl_wait_idle(struct isp_ccdc_device 
*ccdc,
return -EBUSY;
 }
 
-/* __ccdc_handle_stopping - Handle CCDC and/or LSC stopping sequence
+/* ccdc_handle_stopping - Handle CCDC and/or LSC stopping sequence
  * @ccdc: Pointer to ISP CCDC device.
  * @event: Pointing which event trigger handler
  *
  * Return 1 when the event and stopping request combination is satisfied,
  * zero otherwise.
  */
-static int __ccdc_handle_stopping(struct isp_ccdc_device *ccdc, u32 event)
+static int ccdc_handle_stopping(struct isp_ccdc_device *ccdc, u32 event)
 {
int rval = 0;
 
@@ -1502,7 +1502,7 @@ static void ccdc_lsc_isr(struct isp_ccdc_device *ccdc, 
u32 events)
if (ccdc->lsc.state == LSC_STATE_STOPPING)
ccdc->lsc.state = LSC_STATE_STOPPED;
 
-   if (__ccdc_handle_stopping(ccdc, CCDC_EVENT_LSC_DONE))
+   if (ccdc_handle_stopping(ccdc, CCDC_EVENT_LSC_DONE))
goto done;
 
if (ccdc->lsc.state != LSC_STATE_RECONFIG)
@@ -1642,7 +1642,7 @@ static void ccdc_vd0_isr(struct isp_ccdc_device *ccdc)
restart = ccdc_isr_buffer(ccdc);
 
spin_lock_irqsave(&ccdc->lock, flags);
-   if (__ccdc_handle_stopping(ccdc, CCDC_EVENT_VD0)) {
+   if (ccdc_handle_stopping(ccdc, CCDC_EVENT_VD0)) {
spin_unlock_irqrestore(&ccdc->lock, flags);
return;
}
@@ -1702,7 +1702,7 @@ static void ccdc_vd1_isr(struct isp_ccdc_device *ccdc)
break;
}
 
-   if (__ccdc_handle_stopping(ccdc, CCDC_EVENT_VD1))
+   if (ccdc_handle_stopping(ccdc, CCDC_EVENT_VD1))
goto done;
 
if (ccdc->lsc.request == NULL)
-- 
1.8.5.5

--
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: Problems with the omap3isp

2014-08-01 Thread Laurent Pinchart

Hi Stefan,

On Thursday 31 July 2014 10:29:37 Stefan Herbrechtsmeier wrote:
> Am 31.07.2014 01:10, schrieb Laurent Pinchart:
> > On Tuesday 15 July 2014 12:04:09 Stefan Herbrechtsmeier wrote:
> >> Hi Laurent,
> >> 
> >> I have some problems with the omap3isp driver. At the moment I use a
> >> linux-stable 3.14.5 with your fixes for omap3xxx-clocks.dtsi.
> >> 
> >> 1. If I change the clock rate to 24 MHz in my camera driver the whole
> >> system freeze at the clk_prepare_enable. The first enable and disable
> >> works without any problem. The system freeze during a systemd / udev
> >> call of media-ctl.
> > 
> > I've never seen that before. Where does your sensor get its clock from ?
> > Is it connected to the ISP XCLKA or XCLKB output ?
> 
> XCLKA
> 
> > What happens if you don't change the clock rate to 24 MHz ? What rate is
> > it set to in that case ?
> 
> It works if I use a clock rate of 12 MHz or 36 MHz.
> 
> I use the following lines during power enable in the driver:
>  clk_set_rate(ov5647->clk, 2400);
>  clk_prepare_enable(ov5647->clk);
> 
> This works during probe, but the second time I try to power up the
> device the system stall after clk_prepare_enable.

Just to make sure I understand properly, if you change the above frequency
value to 1200 or 3600 without modifying anything else, the problem
doesn't occur ?

Do you start streaming at all at any point ?

> I see the following dump:

[snip]

Looks like the CPU spends all its time processing interrupts. Could you
please try the following patch ? It should disable the ISP interrupt after
10 occurrences, and create an isr_account property in sysfs that will
report the number of interrupts generated for each source. If my guess is
correct, you will hit the 10 interrupts limit very quickly and the system
will unfreeze. If so, please report the content of /proc/interrupts and of
the isr_account property (if I remember correctly it should be located in
/sys/class/video4linux/video0/device/media0/ but you might need to search for
it).

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index de2dec5..c4e6455 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -400,6 +400,38 @@ static inline void isp_isr_dbg(struct isp_device *isp, u32 
irqstatus)
printk(KERN_CONT "\n");
 }
 
+static unsigned int isp_isr_count[32];
+
+static inline void isp_isr_account(struct isp_device *isp, u32 irqstatus)
+{
+   unsigned int i;
+
+   spin_lock(&isp->isr_account_lock);
+   for (i = 0; i < 32; i++) {
+   if (irqstatus & (1 << i))
+   isp_isr_count[i]++;
+   }
+   spin_unlock(&isp->isr_account_lock);
+}
+
+static ssize_t isp_isr_account_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct isp_device *isp = 
container_of(to_media_device(to_media_devnode(dev)), struct isp_device, 
media_dev);
+   unsigned long flags;
+   unsigned int i;
+   int ret = 0;
+
+   spin_lock_irqsave(&isp->isr_account_lock, flags);
+   for (i = 0; i < 32; i++)
+   ret += sprintf(buf + ret, "%u\t%u\n", i, isp_isr_count[i]);
+   spin_unlock_irqrestore(&isp->isr_account_lock, flags);
+
+   return ret;
+}
+
+static DEVICE_ATTR(isr_account, S_IRUGO, isp_isr_account_show, NULL);
+
 static void isp_isr_sbl(struct isp_device *isp)
 {
struct device *dev = isp->dev;
@@ -462,6 +494,7 @@ static irqreturn_t isp_isr(int irq, void *_isp)
   IRQ0STATUS_CCDC_VD0_IRQ |
   IRQ0STATUS_CCDC_VD1_IRQ |
   IRQ0STATUS_HS_VS_IRQ;
+   static unsigned int count = 0;
struct isp_device *isp = _isp;
u32 irqstatus;
int ret;
@@ -469,6 +502,10 @@ static irqreturn_t isp_isr(int irq, void *_isp)
irqstatus = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
isp_reg_writel(isp, irqstatus, OMAP3_ISP_IOMEM_MAIN, ISP_IRQ0STATUS);
 
+   isp_isr_account(isp, irqstatus);
+   if (count++ >= 10)
+   isp_disable_interrupts(isp);
+
isp_isr_sbl(isp);
 
if (irqstatus & IRQ0STATUS_CSIA_IRQ) {
@@ -1971,6 +2008,7 @@ static int isp_remove(struct platform_device *pdev)
struct isp_device *isp = platform_get_drvdata(pdev);
int i;
 
+   device_remove_file(&isp->media_dev.devnode.dev, &dev_attr_isr_account);
isp_unregister_entities(isp);
isp_cleanup_modules(isp);
 
@@ -2067,6 +2105,7 @@ static int isp_probe(struct platform_device *pdev)
 
mutex_init(&isp->isp_mutex);
spin_lock_init(&isp->stat_lock);
+   spin_lock_init(&isp->isr_account_lock);
 
isp->dev = &pdev->dev;
isp->pdata = pdata;
@@ -2156,6 +2195,8 @@ static int isp_probe(struct platform_device *pdev)
isp_power_settings(isp, 1);
omap3isp_put(isp);
 
+

[GIT PULL FOR 3.17] smiapp: Set sub-device owner

2014-08-01 Thread Sakari Ailus

Hi Mauro,

This patch got accidentally dropped from my patchset which contained another
patch it required:

commit b2a06aecb24329e16edc3108b8192d65ace8da75
Author: Sakari Ailus 
Date:   Thu Dec 12 09:36:46 2013 -0300

[media] v4l: Only get module if it's different than the driver for v4l2_dev

When the sub-device is registered, increment the use count of the sub-device
owner only if it's different from the owner of the driver for the media
device. This avoids increasing the use count by the module itself and thus
making it possible to unload it when it's not in use.

Signed-off-by: Sakari Ailus 
Acked-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 

Thanks to Laurent for spotting this. Please pull.


The following changes since commit 27dcb00d0dc1d532b0da940e35a6d020ee33bd47:

  [media] radio-miropcm20: fix sparse NULL pointer warning (2014-07-30 19:50:09 
-0300)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git smiapp-subdev-owner

for you to fetch changes up to 7ac057ec6296b80529075c47fa5eb304e96344df:

  smiapp: Set sub-device owner (2014-08-01 16:47:15 +0300)


Sakari Ailus (1):
  smiapp: Set sub-device owner

 drivers/media/i2c/smiapp/smiapp-core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
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: [PATCH 01/28] ARM: dts: imx6qdl: Add ipu aliases

2014-08-01 Thread Shawn Guo

On Thu, Jul 31, 2014 at 05:28:06PM +0200, Philipp Zabel wrote:
> 
> Am Mittwoch, den 25.06.2014, 18:05 -0700 schrieb Steve Longerbeam:
> > Add ipu0 (and ipu1 for quad) aliases to ipu1/ipu2 nodes respectively.
> > 
> > Signed-off-by: Steve Longerbeam 
> 
> Acked-by: Philipp Zabel 

Please send the patch to LAKML and copy me if it's intended to be
applied on IMX tree.

Shawn
--
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] Add support for LMH0395

2014-08-01 Thread jean-michel . hautbois

From: Jean-Michel Hautbois 

This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.

Add routing support in order to select output
LMH0395 enables the use of up to two outputs.

Signed-off-by: Jean-Michel Hautbois 
---
 .../devicetree/bindings/media/spi/lmh0395.txt  |  24 ++
 drivers/media/Kconfig  |   1 +
 drivers/media/Makefile |   2 +-
 drivers/media/spi/Kconfig  |  14 ++
 drivers/media/spi/Makefile |   1 +
 drivers/media/spi/lmh0395.c| 256 +
 6 files changed, 297 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
 create mode 100644 drivers/media/spi/Kconfig
 create mode 100644 drivers/media/spi/Makefile
 create mode 100644 drivers/media/spi/lmh0395.c

diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt 
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..d55c4eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,24 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97 
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI 
standards.
+
+Required Properties :
+- compatible: Must be "ti,lmh0395"
+
+Example:
+
+ecspi@0201 {
+   ...
+   ...
+
+   lmh0395@1 {
+   compatible = "ti,lmh0395";
+   reg = <1>;
+   spi-max-frequency = <2000>;
+   };
+   ...
+};
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 1d0758a..ce193b0 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -199,6 +199,7 @@ config MEDIA_ATTACH
default MODULES
 
 source "drivers/media/i2c/Kconfig"
+source "drivers/media/spi/Kconfig"
 source "drivers/media/tuners/Kconfig"
 source "drivers/media/dvb-frontends/Kconfig"
 
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index 620f275..7578bcd 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -28,6 +28,6 @@ obj-y += rc/
 # Finally, merge the drivers that require the core
 #
 
-obj-y += common/ platform/ pci/ usb/ mmc/ firewire/ parport/
+obj-y += common/ platform/ pci/ usb/ mmc/ firewire/ parport/ spi/
 obj-$(CONFIG_VIDEO_DEV) += radio/
 
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..291e7ea
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+   tristate "LMH0395 equalizer"
+   depends on VIDEO_V4L2 && SPI && MEDIA_CONTROLLER
+   ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..e287725
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,256 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014  Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-1)");
+
+#defineLMH0395_SPI_CMD_WRITE   0x00
+#defineLMH0395_SPI_CMD_READ0x80
+
+/* Registers of LMH0395 */
+#define LMH0395_GENERAL_CTRL   0x00
+#define LMH0395_OUTPUT_DRIVER  0x01
+#define LMH0395_LAUNCH_AMP_CTRL0x02
+#define LMH0395_MUTE_REF   0x03
+#define LMH0395_DEVICE_ID  0x04
+#defineLMH0395_RATE_INDICATOR  0x05
+#defineLMH0395_CABLE_LENGTH_INDICATOR  0x0

Re: [PATCH 2/8] omap3isp: ccdc: Only complete buffer when all fields are captured

2014-08-01 Thread Laurent Pinchart

On Friday 01 August 2014 07:08:11 Raymond Jender wrote:
> Get me the f u c k  off this list!!

Swearing won't get you anywhere. There's (to my knowledge) nobody registered 
to this list who has administrative permissions needed to modify the 
subscribers list.

Unsubscription information is available at the end of every e-mail you get 
from the list. If you can't understand them, you could ask politely. If you're 
not successful following the procedure you could report the problem politely 
with enough *details* to allow someone to help you. If you still can't 
unsubscribe the footer also has a link to the mailing list manager website, 
which includes a contact e-mail address. If you can't unsubscribe despite all 
that information maybe you should stop using e-mail.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ITU BT2020 support in v4l2_colorspace

2014-08-01 Thread Jean-Marc VOLLE

From: vollejm 

UHD video content may be encoded using a new color space (BT2020). This patch
adds it to the  v4l2_colorspace enum


Signed-off-by: 
---
 Documentation/DocBook/media/v4l/biblio.xml | 10 ++
 Documentation/DocBook/media/v4l/pixfmt.xml | 14 ++
 include/uapi/linux/videodev2.h |  4 
 3 files changed, 28 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
b/Documentation/DocBook/media/v4l/biblio.xml
index d2eb79e..d3930cf 100644
--- a/Documentation/DocBook/media/v4l/biblio.xml
+++ b/Documentation/DocBook/media/v4l/biblio.xml
@@ -117,6 +117,16 @@ 
url="http://www.itu.ch";>http://www.itu.ch)
   ITU-R Recommendation BT.1119 "625-line
 television Wide Screen Signalling (WSS)"
 
+
+  ITU BT.2020
+  
+   International Telecommunication Union (http://www.itu.ch";>http://www.itu.ch)
+  
+  ITU-R Recommendation BT.2020 "Parameter values for
+ ultra-high definition television systems for production
+ and international programme exchange"
+
 
 
   JFIF
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 91dcbc8..f0c70dd 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -599,6 +599,20 @@ are still clamped to [0;255].
 
1.099 I0.45 - 0.099 for 0.018 < I
n/a
  
+ 
+   V4L2_COLORSPACE_BT2020
+   9
+   BT2020, see 
+   x = 0.708, y = 0.292
+   x = 0.170, y = 0.797
+   x = 0.131, y = 0.046
+   x = 0.3127, y = 0.3290,
+   Illuminant D65
+   see 
+   see 
+   see 
+   see 
+ 

   
 
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 168ff50..6af06e1 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -197,6 +197,10 @@ enum v4l2_colorspace {
 
/* For RGB colourspaces, this is probably a good start. */
V4L2_COLORSPACE_SRGB  = 8,
+
+   /* UHD BT2020 colorspace */
+   V4L2_COLORSPACE_BT2020  = 9,
+
 };
 
 enum v4l2_priority {
-- 
1.9.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

Re: [PATCH] ITU BT2020 support in v4l2_colorspace

2014-08-01 Thread Hans Verkuil

On 08/01/2014 05:02 PM, Jean-Marc VOLLE wrote:
> From: vollejm 
> 
> UHD video content may be encoded using a new color space (BT2020). This patch
> adds it to the  v4l2_colorspace enum

I'm not opposed to this, but have you actually seen video streams with this
colorspace?

More to the point, this colorspace is only valid for 10 and 12 bit deep colors
(something that should be documented as well), and I don't think we even have 
PIX_FMT
defines for that. Are there plans to add support for that?

Regards,

Hans

> 
> 
> Signed-off-by: 
> ---
>  Documentation/DocBook/media/v4l/biblio.xml | 10 ++
>  Documentation/DocBook/media/v4l/pixfmt.xml | 14 ++
>  include/uapi/linux/videodev2.h |  4 
>  3 files changed, 28 insertions(+)
> 
> diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
> b/Documentation/DocBook/media/v4l/biblio.xml
> index d2eb79e..d3930cf 100644
> --- a/Documentation/DocBook/media/v4l/biblio.xml
> +++ b/Documentation/DocBook/media/v4l/biblio.xml
> @@ -117,6 +117,16 @@ 
> url="http://www.itu.ch";>http://www.itu.ch)
>ITU-R Recommendation BT.1119 "625-line
>  television Wide Screen Signalling (WSS)"
>  
> +
> +  ITU BT.2020
> +  
> + International Telecommunication Union ( +url="http://www.itu.ch";>http://www.itu.ch)
> +  
> +  ITU-R Recommendation BT.2020 "Parameter values for
> +   ultra-high definition television systems for production
> +   and international programme exchange"
> +
>  
>  
>JFIF
> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
> b/Documentation/DocBook/media/v4l/pixfmt.xml
> index 91dcbc8..f0c70dd 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> @@ -599,6 +599,20 @@ are still clamped to [0;255].
>  
> 1.099 I0.45 - 0.099 for 0.018 < I
>   n/a
> 
> +   
> + V4L2_COLORSPACE_BT2020
> + 9
> + BT2020, see 
> + x = 0.708, y = 0.292
> + x = 0.170, y = 0.797
> + x = 0.131, y = 0.046
> + x = 0.3127, y = 0.3290,
> + Illuminant D65
> + see 
> + see 
> + see 
> + see 
> +   
>   
>
>  
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 168ff50..6af06e1 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -197,6 +197,10 @@ enum v4l2_colorspace {
>  
>   /* For RGB colourspaces, this is probably a good start. */
>   V4L2_COLORSPACE_SRGB  = 8,
> +
> + /* UHD BT2020 colorspace */
> + V4L2_COLORSPACE_BT2020  = 9,
> +
>  };
>  
>  enum v4l2_priority {
> 

--
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: [PATCHv1 02/12] vivid.txt: add documentation for the vivid driver.

2014-08-01 Thread Antonio Ospite

On Fri, 01 Aug 2014 12:14:15 +0200
Hans Verkuil  wrote:

> On 07/31/2014 09:16 PM, Andy Walls wrote:
> > On Wed, 2014-07-30 at 16:23 +0200, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
[..]
> >> +- Improve the sinus generation of the SDR radio.
> > 
> > Maybe a lookup table, containing the first quarter wave of cos() from 0
> > to pi/2 in pi/200 steps, and then linear interpolation for cos() of
> > angles in between those steps.  You could go with a larger lookup table
> > with finer grained steps to reduce the approximation errors.  A lookup
> > table with linear interpolation, I would think, requires fewer
> > mutliplies and divides than the current Taylor expansion computation.
> 
> Yeah, I had plans for that. There actually is a sine-table already in 
> vivid-tpg.c
> since I'm using that to implement Hue support.
> 

I don't know what your requirements are here but JFTR there is already a
simplistic implementation of fixed point operations in
include/linux/fixp-arith.h I used them in
drivers/media/usb/gspca/ov534.c for some hue calculation.

Ciao,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

re: [media] si2165: Add demod driver for DVB-T only

2014-08-01 Thread Dan Carpenter

Hello Matthias Schwarzott,

The patch 3e54a1697ace: "[media] si2165: Add demod driver for DVB-T
only" from Jul 22, 2014, leads to the following static checker
warning:

drivers/media/dvb-frontends/si2165.c:329 si2165_wait_init_done()
warn: signedness bug returning '(-22)'

drivers/media/dvb-frontends/si2165.c
   315  static bool si2165_wait_init_done(struct si2165_state *state)
   316  {
   317  int ret = -EINVAL;
   318  u8 val = 0;
   319  int i;
   320  
   321  for (i = 0; i < 3; ++i) {
   322  si2165_readreg8(state, 0x0054, &val);
   323  if (val == 0x01)
   324  return 0;

This is the success path?

   325  usleep_range(1000, 5);
   326  }
   327  dev_err(&state->i2c->dev, "%s: init_done was not set\n",
   328  KBUILD_MODNAME);
   329  return ret;

-EINVAL becomes 1 when casted to bool.

   330  }

regards,
dan carpenter
--
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: [PATCHv1 02/12] vivid.txt: add documentation for the vivid driver.

2014-08-01 Thread Antti Palosaari




On 08/01/2014 06:19 PM, Antonio Ospite wrote:

On Fri, 01 Aug 2014 12:14:15 +0200
Hans Verkuil  wrote:


On 07/31/2014 09:16 PM, Andy Walls wrote:

On Wed, 2014-07-30 at 16:23 +0200, Hans Verkuil wrote:

From: Hans Verkuil 


[..]

+- Improve the sinus generation of the SDR radio.


Maybe a lookup table, containing the first quarter wave of cos() from 0
to pi/2 in pi/200 steps, and then linear interpolation for cos() of
angles in between those steps.  You could go with a larger lookup table
with finer grained steps to reduce the approximation errors.  A lookup
table with linear interpolation, I would think, requires fewer
mutliplies and divides than the current Taylor expansion computation.


Yeah, I had plans for that. There actually is a sine-table already in 
vivid-tpg.c
since I'm using that to implement Hue support.



I don't know what your requirements are here but JFTR there is already a
simplistic implementation of fixed point operations in
include/linux/fixp-arith.h I used them in
drivers/media/usb/gspca/ov534.c for some hue calculation.


I looked that too, but there was very small LUT => very bad resolution. 
So I ended up copying sin/cos from cx88 driver (Taylor method).


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] ITU BT2020 support in v4l2_colorspace

2014-08-01 Thread Jean-Marc VOLLE

Hello Hans,
Thanks for you very quick feedback, it is my first patch and I'm happy it gets
some feedbacks.

> I'm not opposed to this, but have you actually seen video streams with this 
> colorspace?
I work on silicon for set top boxes and we are indeed starting testing support
for BT2020 encode streams.


> More to the point, this colorspace is only valid for 10 and 12 bit deep 
> colors 
> (something that should be documented as well), and I don't think we even
> have PIX_FMT defines for that. Are there plans to add support for that?

For the color space you are right, this is only valid for 10 & 12 bit deep 
colors
and current YUV formats do not explicitly state if pixel encoding is on 8,
10 or 12 bits as all formats so far used 8 bits encoding.

We do not plan to upstream our 10 bits formats because our HW has a really
fancy way of storing them and I doubt other hw vendor would do the same.
( no padding to 32 bits is performed ie the end of each YUV444 triplet starts 
with a new tripplet.)
Our driver code "quality" is far from beeing upstremable for the time beeing
so I did not think properly about "standard" 10/12 bits V4L2_PIX_FMT.

I can however propose a patch for PIX_FMT for 444, 420 and 422 10/8 bits
Let me know your thoughts about following naming scheme:

reuse any existing PIX_FMT name ( eg V4L2_PIX_FMT_NV16) and extend its
name with _10 or _12 on a need basis.

Other ways (to avoid creating a bunch of new names) could be:
- create 2 BT2020 entries in the color space (one for 10 bits one for 12 bits)
bitdepth would be inferred by those entries (not so nice)
- Add bit depth in v4l2_pix_format.priv 

Our current solution relies on extending the V4L2_PIX_FMT

Regards.
JM


-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl] 
Sent: vendredi 1 août 2014 17:10
To: Jean-Marc VOLLE; linux-media@vger.kernel.org
Cc: Divneil Rai WADHAWAN
Subject: Re: [PATCH] ITU BT2020 support in v4l2_colorspace

On 08/01/2014 05:02 PM, Jean-Marc VOLLE wrote:
> From: vollejm 
> 
> UHD video content may be encoded using a new color space (BT2020). 
> This patch adds it to the  v4l2_colorspace enum

I'm not opposed to this, but have you actually seen video streams with this 
colorspace?

More to the point, this colorspace is only valid for 10 and 12 bit deep colors 
(something that should be documented as well), and I don't think we even have 
PIX_FMT defines for that. Are there plans to add support for that?

Regards,

Hans

> 
> 
> Signed-off-by: 
> ---
>  Documentation/DocBook/media/v4l/biblio.xml | 10 ++  
> Documentation/DocBook/media/v4l/pixfmt.xml | 14 ++
>  include/uapi/linux/videodev2.h |  4 
>  3 files changed, 28 insertions(+)
> 
> diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
> b/Documentation/DocBook/media/v4l/biblio.xml
> index d2eb79e..d3930cf 100644
> --- a/Documentation/DocBook/media/v4l/biblio.xml
> +++ b/Documentation/DocBook/media/v4l/biblio.xml
> @@ -117,6 +117,16 @@ 
> url="http://www.itu.ch";>http://www.itu.ch)
>ITU-R Recommendation BT.1119 "625-line  television Wide 
> Screen Signalling (WSS)"
>  
> +
> +  ITU BT.2020
> +  
> + International Telecommunication Union ( +url="http://www.itu.ch";>http://www.itu.ch)
> +  
> +  ITU-R Recommendation BT.2020 "Parameter values for
> +   ultra-high definition television systems for production
> +   and international programme exchange"
> +
>  
>  
>JFIF
> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
> b/Documentation/DocBook/media/v4l/pixfmt.xml
> index 91dcbc8..f0c70dd 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> @@ -599,6 +599,20 @@ are still clamped to [0;255].  
> 1.099 I0.45 - 0.099 for 0.018 < I
>   n/a
> 
> +   
> + V4L2_COLORSPACE_BT2020
> + 9
> + BT2020, see 
> + x = 0.708, y = 0.292
> + x = 0.170, y = 0.797
> + x = 0.131, y = 0.046
> + x = 0.3127, y = 0.3290,
> + Illuminant D65
> + see 
> + see 
> + see 
> + see 
> +   
>   
>
>  
> diff --git a/include/uapi/linux/videodev2.h 
> b/include/uapi/linux/videodev2.h index 168ff50..6af06e1 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -197,6 +197,10 @@ enum v4l2_colorspace {
>  
>   /* For RGB colourspaces, this is probably a good start. */
>   V4L2_COLORSPACE_SRGB  = 8,
> +
> + /* UHD BT2020 colorspace */
> + V4L2_COLORSPACE_BT2020  = 9,
> +
>  };
>  
>  enum v4l2_priority {
> 

--
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] ITU BT2020 support in v4l2_colorspace

2014-08-01 Thread Hans Verkuil

On 08/01/2014 05:54 PM, Jean-Marc VOLLE wrote:
> Hello Hans,
> Thanks for you very quick feedback, it is my first patch and I'm happy it gets
> some feedbacks.
> 
>> I'm not opposed to this, but have you actually seen video streams with this 
>> colorspace?
> I work on silicon for set top boxes and we are indeed starting testing support
> for BT2020 encode streams.

So it is actually being used by studios to create 4k video?

> 
> 
>> More to the point, this colorspace is only valid for 10 and 12 bit deep 
>> colors 
>> (something that should be documented as well), and I don't think we even
>> have PIX_FMT defines for that. Are there plans to add support for that?
> 
> For the color space you are right, this is only valid for 10 & 12 bit deep 
> colors
> and current YUV formats do not explicitly state if pixel encoding is on 8,
> 10 or 12 bits as all formats so far used 8 bits encoding.
> 
> We do not plan to upstream our 10 bits formats because our HW has a really
> fancy way of storing them and I doubt other hw vendor would do the same.

That's no problem. If you look at the v4l2 spec you'll see a pile of vendor 
specific
pixel formats. As long as the format is also documented in the spec, then 
you're OK.

> ( no padding to 32 bits is performed ie the end of each YUV444 triplet starts 
> with a new tripplet.)
> Our driver code "quality" is far from beeing upstremable for the time beeing
> so I did not think properly about "standard" 10/12 bits V4L2_PIX_FMT.

If you are interested in eventually upstreaming your code, then it's no
problem to either post it to the mailinglist and ask for some initial feedback,
or mail it for example to me in private. We like new drivers as we want V4L2 to
be the de-facto API for video capture and hw codecs, so I'm happy to assist.

> 
> I can however propose a patch for PIX_FMT for 444, 420 and 422 10/8 bits
> Let me know your thoughts about following naming scheme:
> 
> reuse any existing PIX_FMT name ( eg V4L2_PIX_FMT_NV16) and extend its
> name with _10 or _12 on a need basis.

I would stick to your hardware specific format rather than inventing pixel
formats that nobody else is using yet.

> 
> Other ways (to avoid creating a bunch of new names) could be:
> - create 2 BT2020 entries in the color space (one for 10 bits one for 12 bits)
> bitdepth would be inferred by those entries (not so nice)

Colorspace is an independent property of the pixel format. The main thing
that is missing in V4L2 is a way to report whether full or limited range
quantization was used. Currently RGB pixel formats are assumed to be full
range and ycbcr (aka yuv) are limited range. But that really should be
signalled.

> - Add bit depth in v4l2_pix_format.priv 
> 
> Our current solution relies on extending the V4L2_PIX_FMT

For the 3.17 kernel we made it possible to extend v4l2_pix_format. See the priv
field description here:

http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-pix-format

Regards,

Hans

> 
> Regards.
> JM
> 
> 
> -Original Message-
> From: Hans Verkuil [mailto:hverk...@xs4all.nl] 
> Sent: vendredi 1 août 2014 17:10
> To: Jean-Marc VOLLE; linux-media@vger.kernel.org
> Cc: Divneil Rai WADHAWAN
> Subject: Re: [PATCH] ITU BT2020 support in v4l2_colorspace
> 
> On 08/01/2014 05:02 PM, Jean-Marc VOLLE wrote:
>> From: vollejm 
>>
>> UHD video content may be encoded using a new color space (BT2020). 
>> This patch adds it to the  v4l2_colorspace enum
> 
> I'm not opposed to this, but have you actually seen video streams with this 
> colorspace?
> 
> More to the point, this colorspace is only valid for 10 and 12 bit deep 
> colors (something that should be documented as well), and I don't think we 
> even have PIX_FMT defines for that. Are there plans to add support for that?
> 
> Regards,
> 
>   Hans
> 
>>
>>
>> Signed-off-by: 
>> ---
>>  Documentation/DocBook/media/v4l/biblio.xml | 10 ++  
>> Documentation/DocBook/media/v4l/pixfmt.xml | 14 ++
>>  include/uapi/linux/videodev2.h |  4 
>>  3 files changed, 28 insertions(+)
>>
>> diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
>> b/Documentation/DocBook/media/v4l/biblio.xml
>> index d2eb79e..d3930cf 100644
>> --- a/Documentation/DocBook/media/v4l/biblio.xml
>> +++ b/Documentation/DocBook/media/v4l/biblio.xml
>> @@ -117,6 +117,16 @@ 
>> url="http://www.itu.ch";>http://www.itu.ch)
>>ITU-R Recommendation BT.1119 "625-line  television Wide 
>> Screen Signalling (WSS)"
>>  
>> +
>> +  ITU BT.2020
>> +  
>> +International Telecommunication Union (> +url="http://www.itu.ch";>http://www.itu.ch)
>> +  
>> +  ITU-R Recommendation BT.2020 "Parameter values for
>> +  ultra-high definition television systems for production
>> +  and international programme exchange"
>> +
>>  
>>  
>>JFIF
>> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
>> b/Documentation/DocBook/media/v4l/pixfmt.xml
>> index 91dcbc8..f0c70dd

Re: [PATCH v2 00/11] CODA encoder/decoder device split

2014-08-01 Thread Fabio Estevam

Hi Mauro,

On Tue, Jul 29, 2014 at 5:27 AM, Philipp Zabel  wrote:
> Hi,
>
> Am Freitag, den 18.07.2014, 12:22 +0200 schrieb Philipp Zabel:
>> Hi,
>>
>> the following patches add a few fixes and cleanups and split the
>> coda video4linux2 device into encoder and decoder.
>> Following the principle of least surprise, this way the format
>> enumeration on the output and capture sides is fixed and does
>> not change depending on whether the given instance is currently
>> configured as encoder or decoder.
>>
>> Changes since v1:
>>  - Fixed "[media] coda: delay coda_fill_bitstream()", taking into account
>>"[media] v4l: vb2: Fix stream start and buffer completion race".
>>  - Added Hans' acks.
>
> is there still a chance to still get this series merged for v3.17?
> Most of it got acked by Hans right away, and I have received no other
> feedback.
> The split into separate encoder and decoder devices (patch 08/11) is
> necessary for this driver to work with the GStreamer v4l2videodec
> element.

You said in another email that Kamil is on vacation. Could you please
apply this series if you are happy with it?

Thanks
--
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: [PATCHv1 02/12] vivid.txt: add documentation for the vivid driver.

2014-08-01 Thread Andy Walls

On August 1, 2014 11:33:26 AM EDT, Antti Palosaari  wrote:
>
>
>On 08/01/2014 06:19 PM, Antonio Ospite wrote:
>> On Fri, 01 Aug 2014 12:14:15 +0200
>> Hans Verkuil  wrote:
>>
>>> On 07/31/2014 09:16 PM, Andy Walls wrote:
 On Wed, 2014-07-30 at 16:23 +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
>
>> [..]
> +- Improve the sinus generation of the SDR radio.

 Maybe a lookup table, containing the first quarter wave of cos()
>from 0
 to pi/2 in pi/200 steps, and then linear interpolation for cos() of
 angles in between those steps.  You could go with a larger lookup
>table
 with finer grained steps to reduce the approximation errors.  A
>lookup
 table with linear interpolation, I would think, requires fewer
 mutliplies and divides than the current Taylor expansion
>computation.
>>>
>>> Yeah, I had plans for that. There actually is a sine-table already
>in vivid-tpg.c
>>> since I'm using that to implement Hue support.
>>>
>>
>> I don't know what your requirements are here but JFTR there is
>already a
>> simplistic implementation of fixed point operations in
>> include/linux/fixp-arith.h I used them in
>> drivers/media/usb/gspca/ov534.c for some hue calculation.
>
>I looked that too, but there was very small LUT => very bad resolution.
>
>So I ended up copying sin/cos from cx88 driver (Taylor method).
>
>regards
>Antti

I was thinking of implementing a fixed point sine based on the quintic 
polynomial approximation of sin (pi/2 * x) described here:

http://www.coranac.com/2009/07/sines/

since I wanted to learn fixed point stuff anyway.

But probably -ENOTIME .

Regards,
Andy
--
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 3/4] media: rcar_vin: Fix race condition terminating stream

2014-08-01 Thread Sergei Shtylyov


Hello.

On 07/10/2014 02:15 PM, Ian Molton wrote:


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.



Agreed.



[...]

@@ -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.



Agreed.



Any further comments? If not, I can re-spin this ready for upstreaming.


   There has been no further comments but you've never re-appeared. :-(
Now I'm about to test these patches...

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: WARNINGS

2014-08-01 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:   Sat Aug  2 04:00:21 CEST 2014
git branch: test
git hash:   0f3bf3dc1ca394a8385079a5653088672b65c5c4
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-16-g1db35d0
host hardware:  x86_64
host os:3.15-7.slh.3-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.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.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: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.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

[PATCH 2/5] ddbridge: disable driver building

2014-08-01 Thread Antti Palosaari

Disable building that driver for a wile. We do massive driver
update from latest vendor driver and this is to avoid Kernel
compilation breakage.

Signed-off-by: Antti Palosaari 
---
 drivers/media/pci/ddbridge/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/ddbridge/Makefile 
b/drivers/media/pci/ddbridge/Makefile
index 7446c8b..39e922c 100644
--- a/drivers/media/pci/ddbridge/Makefile
+++ b/drivers/media/pci/ddbridge/Makefile
@@ -4,7 +4,8 @@
 
 ddbridge-objs := ddbridge-core.o
 
-obj-$(CONFIG_DVB_DDBRIDGE) += ddbridge.o
+#obj-$(CONFIG_DVB_DDBRIDGE) += ddbridge.o
+obj-$() += ddbridge.o
 
 ccflags-y += -Idrivers/media/dvb-core/
 ccflags-y += -Idrivers/media/dvb-frontends/
-- 
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

[PATCH 3/5] ddbridge: remove driver temporarily

2014-08-01 Thread Antti Palosaari

Remove driver (version 0.5) as we will update driver to latest
vendor version 0.9.15. Driver has changed too much for normal
feature by feature update, so better to remove it totally and
build new one based directly to latest vendor version.

Signed-off-by: Antti Palosaari 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 1887 
 drivers/media/pci/ddbridge/ddbridge-regs.h |  151 ---
 drivers/media/pci/ddbridge/ddbridge.h  |  188 ---
 3 files changed, 2226 deletions(-)
 delete mode 100644 drivers/media/pci/ddbridge/ddbridge-core.c
 delete mode 100644 drivers/media/pci/ddbridge/ddbridge-regs.h
 delete mode 100644 drivers/media/pci/ddbridge/ddbridge.h

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
deleted file mode 100644
index 9f5837f..000
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ /dev/null
@@ -1,1887 +0,0 @@
-/*
- * ddbridge.c: Digital Devices PCIe bridge driver
- *
- * Copyright (C) 2010-2011 Digital Devices GmbH
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 only, as published by the Free Software Foundation.
- *
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA
- * Or, point your browser to http://www.gnu.org/copyleft/gpl.html
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "ddbridge.h"
-
-#include "ddbridge-regs.h"
-
-#include "tda18271c2dd.h"
-#include "stv6110x.h"
-#include "stv090x.h"
-#include "lnbh24.h"
-#include "drxk.h"
-#include "cxd2843.h"
-#include "tda18212.h"
-
-DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
-
-/* MSI had problems with lost interrupts, fixed but needs testing */
-#undef CONFIG_PCI_MSI
-
-/**/
-
-static int i2c_read(struct i2c_adapter *adapter, u8 adr, u8 *val)
-{
-   struct i2c_msg msgs[1] = {{.addr = adr,  .flags = I2C_M_RD,
-  .buf  = val,  .len   = 1 } };
-   return (i2c_transfer(adapter, msgs, 1) == 1) ? 0 : -1;
-}
-
-static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr, u8 reg, u8 *val)
-{
-   struct i2c_msg msgs[2] = {{.addr = adr,  .flags = 0,
-  .buf  = ®, .len   = 1 },
- {.addr = adr,  .flags = I2C_M_RD,
-  .buf  = val,  .len   = 1 } };
-   return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
-}
-
-static int i2c_read_reg16(struct i2c_adapter *adapter, u8 adr,
- u16 reg, u8 *val)
-{
-   u8 msg[2] = {reg>>8, reg&0xff};
-   struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
-  .buf  = msg, .len   = 2},
- {.addr = adr, .flags = I2C_M_RD,
-  .buf  = val, .len   = 1} };
-   return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
-}
-
-static int i2c_write(struct i2c_adapter *adap, u8 adr, u8 *data, int len)
-{
-   struct i2c_msg msg = {.addr = adr, .flags = 0,
- .buf = data, .len = len};
-
-   return (i2c_transfer(adap, &msg, 1) == 1) ? 0 : -1;
-}
-
-static int i2c_write_reg(struct i2c_adapter *adap, u8 adr, u8 reg, u8 val)
-{
-   u8 msg[2] = {reg, val};
-
-   return i2c_write(adap, adr, msg, 2);
-}
-
-static int ddb_i2c_cmd(struct ddb_i2c *i2c, u32 adr, u32 cmd)
-{
-   struct ddb *dev = i2c->dev;
-   int stat;
-   u32 val;
-
-   i2c->done = 0;
-   ddbwritel((adr << 9) | cmd, i2c->regs + I2C_COMMAND);
-   stat = wait_event_timeout(i2c->wq, i2c->done == 1, HZ);
-   if (stat <= 0) {
-   printk(KERN_ERR "I2C timeout\n");
-   { /* MSI debugging*/
-   u32 istat = ddbreadl(INTERRUPT_STATUS);
-   printk(KERN_ERR "IRS %08x\n", istat);
-   ddbwritel(istat, INTERRUPT_ACK);
-   }
-   return -EIO;
-   }
-   val = ddbreadl(i2c->regs+I2C_COMMAND);
-   if (val & 0x7)
-   return -EIO;
-   return 0;
-}
-
-static int ddb_i2c_master_xfer(struct i2c_adapter *adapter,
-  struct i2c_msg msg[], int num)
-{
-   struct ddb_i2c *i2c = (struct ddb_i2c *)i2c_get_adapdata(adapter);
-   struct ddb *dev = i2c->dev;
-   u8 addr = 0;
-
-   if (num)
-   addr

[PATCH 4/5] ddbridge: add needed files from manufacturer driver 0.9.15a

2014-08-01 Thread Antti Palosaari

Add files:
ddbridge.c
ddbridge-core.c
ddbridge.h
ddbridge-i2c.c
ddbridge-regs.h

These files are taken, without any modification, from the latest
Digital Devices (device manufacturer) Linux driver version 0.9.15a.

md5sum dddvb-0.9.15a.tar.bz2 e7f313ce5b548aeb55d168ad8b34b91a

Signed-off-by: Antti Palosaari 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 3735 
 drivers/media/pci/ddbridge/ddbridge-i2c.c  |  257 ++
 drivers/media/pci/ddbridge/ddbridge-regs.h |  436 
 drivers/media/pci/ddbridge/ddbridge.c  |  460 
 drivers/media/pci/ddbridge/ddbridge.h  |  499 
 5 files changed, 5387 insertions(+)
 create mode 100644 drivers/media/pci/ddbridge/ddbridge-core.c
 create mode 100644 drivers/media/pci/ddbridge/ddbridge-i2c.c
 create mode 100644 drivers/media/pci/ddbridge/ddbridge-regs.h
 create mode 100644 drivers/media/pci/ddbridge/ddbridge.c
 create mode 100644 drivers/media/pci/ddbridge/ddbridge.h

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
new file mode 100644
index 000..a301be6
--- /dev/null
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -0,0 +1,3735 @@
+/*
+ * ddbridge-core.c: Digital Devices bridge core functions
+ *
+ * Copyright (C) 2010-2013 Digital Devices GmbH
+ * Ralph Metzler 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 only, as published by the Free Software Foundation.
+ *
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA
+ * Or, point your browser to http://www.gnu.org/copyleft/gpl.html
+ */
+
+DEFINE_MUTEX(redirect_lock);
+
+static int ci_bitrate = 72000;
+module_param(ci_bitrate, int, 0444);
+MODULE_PARM_DESC(ci_bitrate, " Bitrate for output to CI.");
+
+static int ts_loop = -1;
+module_param(ts_loop, int, 0444);
+MODULE_PARM_DESC(ts_loop, "TS in/out test loop on port ts_loop");
+
+static int vlan;
+module_param(vlan, int, 0444);
+MODULE_PARM_DESC(vlan, "VLAN and QoS IDs enabled");
+
+static int tt;
+module_param(tt, int, 0444);
+MODULE_PARM_DESC(tt, "");
+
+#define DDB_MAX_ADAPTER 32
+static struct ddb *ddbs[DDB_MAX_ADAPTER];
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+#include "ddbridge-mod.c"
+#include "ddbridge-i2c.c"
+#include "ddbridge-ns.c"
+
+
+static void ddb_set_dma_table(struct ddb *dev, struct ddb_dma *dma)
+{
+   u32 i, base;
+   u64 mem;
+
+   if (!dma)
+   return;
+   base = DMA_BASE_ADDRESS_TABLE + dma->nr * 0x100;
+   for (i = 0; i < dma->num; i++) {
+   mem = dma->pbuf[i];
+   ddbwritel(dev, mem & 0x, base + i * 8);
+   ddbwritel(dev, mem >> 32, base + i * 8 + 4);
+   }
+   dma->bufreg = (dma->div << 16) |
+   ((dma->num & 0x1f) << 11) |
+   ((dma->size >> 7) & 0x7ff);
+}
+
+static void ddb_set_dma_tables(struct ddb *dev)
+{
+   u32 i;
+
+   for (i = 0; i < dev->info->port_num * 2; i++)
+   ddb_set_dma_table(dev, dev->input[i].dma);
+   for (i = 0; i < dev->info->port_num; i++)
+   ddb_set_dma_table(dev, dev->output[i].dma);
+}
+
+
+//
+//
+//
+
+static void ddb_redirect_dma(struct ddb *dev,
+struct ddb_dma *sdma,
+struct ddb_dma *ddma)
+{
+   u32 i, base;
+   u64 mem;
+
+   sdma->bufreg = ddma->bufreg;
+   base = DMA_BASE_ADDRESS_TABLE + sdma->nr * 0x100;
+   for (i = 0; i < ddma->num; i++) {
+   mem = ddma->pbuf[i];
+   ddbwritel(dev, mem & 0x, base + i * 8);
+   ddbwritel(dev, mem >> 32, base + i * 8 + 4);
+   }
+}
+
+static int ddb_unredirect(struct ddb_port *port)
+{
+   struct ddb_input *oredi, *iredi = 0;
+   struct ddb_output *iredo = 0;
+
+   /*pr_info("unredirect %d.%d\n", port->dev->nr, port->nr);*/
+   mutex_lock(&redirect_lock);
+   if (port->output->dma->running) {
+   mutex_unlock(&redirect_lock);
+   return -EBUSY;
+   }
+   oredi = port->output->redi;
+   if (!oredi)
+   goto done;
+   if (port->input[0]) {
+   iredi = port->input[0]->redi;
+   iredo = port->input[0]->redo;
+
+   if (iredo) {
+

[PATCH 0/5] Digital Devices PCIe bridge update to 0.9.15a

2014-08-01 Thread Antti Palosaari

After cold power-on, my device wasn't able to find DuoFlex C/C2/T/T2
Expansion card, which I added yesterday. I looked old and new drivers
and tried many things, but no success. Old kernel driver was ages,
many years, behind manufacturer current Linux driver and there has
been a tons of changes. So I ended up upgrading Linux kernel driver
to 0.9.15a (it was 0.5).

Now it is very near Digital Devices official driver, only modulator
and network streaming stuff is removed and CI is abusing SEC like
earlier also.

Few device models are not supported due to missing kernel driver or
missing device profile. Those devices are based of following DTV
frontend chipsets:
MaxLinear MxL5xx
STMicroelectronics STV0910
STMicroelectronics STV0367


Tree for testing is here:
http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=digitaldevices

regards
Antti


Antti Palosaari (5):
  cxd2843: do not call get_if_frequency() when it is NULL
  ddbridge: disable driver building
  ddbridge: remove driver temporarily
  ddbridge: add needed files from manufacturer driver 0.9.15a
  ddbridge: clean up driver for release

 drivers/media/dvb-frontends/cxd2843.c  |3 +-
 drivers/media/pci/ddbridge/Makefile|2 -
 drivers/media/pci/ddbridge/ddbridge-core.c | 3175 +++-
 drivers/media/pci/ddbridge/ddbridge-i2c.c  |  232 ++
 drivers/media/pci/ddbridge/ddbridge-regs.h |  347 ++-
 drivers/media/pci/ddbridge/ddbridge.c  |  456 
 drivers/media/pci/ddbridge/ddbridge.h  |  407 +++-
 7 files changed, 3518 insertions(+), 1104 deletions(-)
 create mode 100644 drivers/media/pci/ddbridge/ddbridge-i2c.c
 create mode 100644 drivers/media/pci/ddbridge/ddbridge.c

-- 
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

[PATCH 1/5] cxd2843: do not call get_if_frequency() when it is NULL

2014-08-01 Thread Antti Palosaari

Calling NULL callback crash kernel. Check its existence before
call it.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-frontends/cxd2843.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cxd2843.c 
b/drivers/media/dvb-frontends/cxd2843.c
index 10fc240..433d913 100644
--- a/drivers/media/dvb-frontends/cxd2843.c
+++ b/drivers/media/dvb-frontends/cxd2843.c
@@ -1154,7 +1154,8 @@ static int set_parameters(struct dvb_frontend *fe)
state->plp = fe->dtv_property_cache.stream_id & 0xff;
}
/* printk("PLP = %08x, bw = %u\n", state->plp, state->bw); */
-   fe->ops.tuner_ops.get_if_frequency(fe, &IF);
+   if (fe->ops.tuner_ops.get_if_frequency)
+   fe->ops.tuner_ops.get_if_frequency(fe, &IF);
stat = Start(state, IF);
return stat;
 }
-- 
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

[PATCH 5/5] ddbridge: clean up driver for release

2014-08-01 Thread Antti Palosaari

Enable driver compilation. Clean up driver.
Remove network streaming and modulator functionality - needs API
first.

Remove few receivers which are not supported due to missing DTV
frontend chipset drivers or due to lack of correct device profile
(+ I don't have hw to implement profile). Those removed receivers
are based of following DTV chipsets:
MaxLinear MxL5xx
STMicroelectronics STV0910
STMicroelectronics STV0367

Signed-off-by: Antti Palosaari 
---
 drivers/media/pci/ddbridge/Makefile|   5 +-
 drivers/media/pci/ddbridge/ddbridge-core.c | 813 ++---
 drivers/media/pci/ddbridge/ddbridge-i2c.c  |  25 -
 drivers/media/pci/ddbridge/ddbridge.c  |  20 +-
 drivers/media/pci/ddbridge/ddbridge.h  |  16 -
 5 files changed, 65 insertions(+), 814 deletions(-)

diff --git a/drivers/media/pci/ddbridge/Makefile 
b/drivers/media/pci/ddbridge/Makefile
index 39e922c..2610161 100644
--- a/drivers/media/pci/ddbridge/Makefile
+++ b/drivers/media/pci/ddbridge/Makefile
@@ -2,10 +2,7 @@
 # Makefile for the ddbridge device driver
 #
 
-ddbridge-objs := ddbridge-core.o
-
-#obj-$(CONFIG_DVB_DDBRIDGE) += ddbridge.o
-obj-$() += ddbridge.o
+obj-$(CONFIG_DVB_DDBRIDGE) += ddbridge.o
 
 ccflags-y += -Idrivers/media/dvb-core/
 ccflags-y += -Idrivers/media/dvb-frontends/
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index a301be6..c66b1b3 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -45,10 +45,7 @@ static struct ddb *ddbs[DDB_MAX_ADAPTER];
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
-#include "ddbridge-mod.c"
 #include "ddbridge-i2c.c"
-#include "ddbridge-ns.c"
-
 
 static void ddb_set_dma_table(struct ddb *dev, struct ddb_dma *dma)
 {
@@ -281,9 +278,8 @@ static int ddb_buffers_alloc(struct ddb *dev)
if (dma_alloc(dev->pdev, port->input[0]->dma, 0) < 0)
return -1;
case DDB_PORT_MOD:
-   if (dma_alloc(dev->pdev, port->output->dma, 1) < 0)
-   return -1;
-   break;
+   /* TODO: modulator not supported */
+   return -1;
default:
break;
}
@@ -324,9 +320,9 @@ static void ddb_output_start(struct ddb_output *output)
output->dma->stat = 0;
ddbwritel(dev, 0, DMA_BUFFER_CONTROL(output->dma->nr));
}
-   if (output->port->class == DDB_PORT_MOD)
-   ddbridge_mod_output_start(output);
-   else {
+   if (output->port->class == DDB_PORT_MOD) {
+   /* TODO: modulator not supported */
+   } else {
ddbwritel(dev, 0, TS_OUTPUT_CONTROL(output->nr));
ddbwritel(dev, 2, TS_OUTPUT_CONTROL(output->nr));
ddbwritel(dev, 0, TS_OUTPUT_CONTROL(output->nr));
@@ -363,7 +359,8 @@ static void ddb_output_stop(struct ddb_output *output)
if (output->dma)
spin_lock_irq(&output->dma->lock);
if (output->port->class == DDB_PORT_MOD)
-   ddbridge_mod_output_stop(output);
+   /* TODO: modulator not supported */
+   ;
else
ddbwritel(dev, 0, TS_OUTPUT_CONTROL(output->nr));
if (output->dma) {
@@ -422,28 +419,6 @@ static void ddb_input_start(struct ddb_input *input)
/*pr_info("input_start %d.%d\n", dev->nr, input->nr);*/
 }
 
-
-static int ddb_dvb_input_start(struct ddb_input *input)
-{
-   struct ddb_dvb *dvb = &input->port->dvb[input->nr & 1];
-
-   if (!dvb->users)
-   ddb_input_start(input);
-
-   return ++dvb->users;
-}
-
-static int ddb_dvb_input_stop(struct ddb_input *input)
-{
-   struct ddb_dvb *dvb = &input->port->dvb[input->nr & 1];
-
-   if (--dvb->users)
-   return dvb->users;
-
-   ddb_input_stop(input);
-   return 0;
-}
-
 static void ddb_input_start_all(struct ddb_input *input)
 {
struct ddb_input *i = input;
@@ -496,25 +471,6 @@ static u32 ddb_output_free(struct ddb_output *output)
return 0;
 }
 
-#if 0
-static u32 ddb_dma_free(struct ddb_dma *dma)
-{
-   u32 idx, off, stat = dma->stat;
-   s32 p1, p2, diff;
-
-   idx = (stat >> 11) & 0x1f;
-   off = (stat & 0x7ff) << 7;
-
-   p1 = idx * dma->size + off;
-   p2 = dma->cbuf * dma->size + dma->coff;
-
-   diff = p1 - p2;
-   if (diff <= 0)
-   diff += dma->num * dma->size;
-   return diff;
-}
-#endif
-
 static ssize_t ddb_output_write(struct ddb_output *output,
const u8 *buf, size_t count)
 {
@@ -570,81 +526,6 @@ static ssize_t ddb_output_write(struct ddb_output *output,
return count - left;
 }
 
-#if 0
-static u32 ddb_input_free_bytes(struct ddb_input *input)
-{
-   struct ddb *dev = input->port->dev;
-   u32 idx, off, stat = input->dm

Hello

2014-08-01 Thread Gina Sayyed

Hello

Hi friend, hope you are fine, My name is Gina Sayyed, I am lonely, tender,
caring, faithful and honest girl, I am ready to give all my care,
love, attention and devotion.I promise to send my recent picture and
tell you more about myself.

Regards.
Gina Sayyed.
--
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

40 matches

Mail list logo