cron job: media_tree daily build: OK

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Thu Jun 16 04:00:23 CEST 2016
git branch: test
git hash:   7579639f37abeb025aebd89a67c7469790eb3853
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.5.0-264

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-pxa: OK
linux-git-blackfin-bf561: 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.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.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: OK
linux-4.7-rc1-i686: 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.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
linux-4.7-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH 00/38] i.MX5/6 Video Capture

[Steve Longerbeam]

Hi Jack,

On 06/15/2016 03:43 AM, Jack Mitchell wrote:
> 
> Trying to use a user pointer rather than mmap also fails and causes a kernel 
> splat.
>

Hmm, I've tested userptr with the mem2mem driver, but maybe never
with video capture. I tried "v4l2-ctl -d/dev/video0 --stream-user=8" but
that returns "VIDIOC_QBUF: failed: Invalid argument", haven't tracked
down why (could be a bug in v4l2-ctl). Can you share the splat?


> Apart from that and a few v4l2-compliance tests failing which you already 
> mentioned, it seems to work OK. I'll try and do some more testing and see if 
> I can come back with some more feedback.

Thanks!


Steve

--
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 35/38] media: adv7180: add power pin control

[Steve Longerbeam]

Hi Lars,

On 06/15/2016 09:05 AM, Lars-Peter Clausen wrote:
> On 06/15/2016 12:49 AM, Steve Longerbeam wrote:
>> +usleep_range(5000, 5001);
> That's kind of not how usleep_range() (the emphasis is on range) is supposed
> to be used. You typically dont care too much about the upper limit here so
> something like maybe 1 is more appropriate.

Good point, I fixed this as well as all other instances of
usleep_range() in the patch set.

>
>> +static int adv7180_of_parse(struct adv7180_state *state)
>> +{
>> +struct i2c_client *client = state->client;
>> +struct device_node *np = client->dev.of_node;
>> +int ret;
>> +
>> +ret = of_get_named_gpio(np, "pwdn-gpio", 0);
>> +
>> +if (gpio_is_valid(ret)) {
>> +state->pwdn_gpio = ret;
>> +ret = devm_gpio_request_one(>dev,
>> +state->pwdn_gpio,
>> +GPIOF_OUT_INIT_HIGH,
>> +"adv7180_pwdn");
>
> This should use the new GPIO descriptor API. That will also make the code
> devicetree independent. Otherwise patch looks OK.

Thanks for the heads-up. I converted to gpiod here, and in all other
patches in the set that were using the deprecated API. Also took the
time to review the active low/high flags in the device tree, and made
sure they are correct and are using the explicit flags GPIO_ACTIVE_*.

The changes are in a new branch mx6-media-staging-v2.1 in my fork
on github (g...@github.com:slongerbeam/mediatree.git).

Retested on SabreSD and SabreAuto, still working as before.

Steve

--
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] videodev2.h: Fix V4L2_PIX_FMT_YUV411P description

[Laurent Pinchart]

YUV 4:1:1 uses 12 bits per pixel on average, not 16.

Signed-off-by: Laurent Pinchart 
---
 include/uapi/linux/videodev2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 587b3c1c257e..49bdbc8dc25e 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -537,7 +537,7 @@ struct v4l2_pix_format {
 /* three planes - Y Cb, Cr */
 #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1:0  
   */
 #define V4L2_PIX_FMT_YVU410  v4l2_fourcc('Y', 'V', 'U', '9') /*  9  YVU 4:1:0  
   */
-#define V4L2_PIX_FMT_YUV411P v4l2_fourcc('4', '1', '1', 'P') /* 16  YVU411 
planar */
+#define V4L2_PIX_FMT_YUV411P v4l2_fourcc('4', '1', '1', 'P') /* 12  YVU411 
planar */
 #define V4L2_PIX_FMT_YUV420  v4l2_fourcc('Y', 'U', '1', '2') /* 12  YUV 4:2:0  
   */
 #define V4L2_PIX_FMT_YVU420  v4l2_fourcc('Y', 'V', '1', '2') /* 12  YVU 4:2:0  
   */
 #define V4L2_PIX_FMT_YUV422P v4l2_fourcc('4', '2', '2', 'P') /* 16  YVU422 
planar */
-- 
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] videodev2.h: Group YUV 3 planes formats together

[Laurent Pinchart]

The formats are interleaved with the YUV packed and miscellaneous
formats, making the result confusing especially with the YUV444 format
being packed and not planar like YUV410 or YUV420. Move them to their
own group as the 2 planes or 3 non-contiguous planes formats to clarify
the header.

Signed-off-by: Laurent Pinchart 
---
 include/uapi/linux/videodev2.h | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 8f951917be74..50ff346c4118 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -504,22 +504,16 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /*  8  UV 4:4 */
 
 /* Luminance+Chrominance formats */
-#define V4L2_PIX_FMT_YVU410  v4l2_fourcc('Y', 'V', 'U', '9') /*  9  YVU 4:1:0  
   */
-#define V4L2_PIX_FMT_YVU420  v4l2_fourcc('Y', 'V', '1', '2') /* 12  YVU 4:2:0  
   */
 #define V4L2_PIX_FMT_YUYVv4l2_fourcc('Y', 'U', 'Y', 'V') /* 16  YUV 4:2:2  
   */
 #define V4L2_PIX_FMT_YYUVv4l2_fourcc('Y', 'Y', 'U', 'V') /* 16  YUV 4:2:2  
   */
 #define V4L2_PIX_FMT_YVYUv4l2_fourcc('Y', 'V', 'Y', 'U') /* 16 YVU 4:2:2 */
 #define V4L2_PIX_FMT_UYVYv4l2_fourcc('U', 'Y', 'V', 'Y') /* 16  YUV 4:2:2  
   */
 #define V4L2_PIX_FMT_VYUYv4l2_fourcc('V', 'Y', 'U', 'Y') /* 16  YUV 4:2:2  
   */
-#define V4L2_PIX_FMT_YUV422P v4l2_fourcc('4', '2', '2', 'P') /* 16  YVU422 
planar */
-#define V4L2_PIX_FMT_YUV411P v4l2_fourcc('4', '1', '1', 'P') /* 16  YVU411 
planar */
 #define V4L2_PIX_FMT_Y41Pv4l2_fourcc('Y', '4', '1', 'P') /* 12  YUV 4:1:1  
   */
 #define V4L2_PIX_FMT_YUV444  v4l2_fourcc('Y', '4', '4', '4') /* 16   
 */
 #define V4L2_PIX_FMT_YUV555  v4l2_fourcc('Y', 'U', 'V', 'O') /* 16  YUV-5-5-5  
   */
 #define V4L2_PIX_FMT_YUV565  v4l2_fourcc('Y', 'U', 'V', 'P') /* 16  YUV-5-6-5  
   */
 #define V4L2_PIX_FMT_YUV32   v4l2_fourcc('Y', 'U', 'V', '4') /* 32  
YUV-8-8-8-8   */
-#define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1:0  
   */
-#define V4L2_PIX_FMT_YUV420  v4l2_fourcc('Y', 'U', '1', '2') /* 12  YUV 4:2:0  
   */
 #define V4L2_PIX_FMT_HI240   v4l2_fourcc('H', 'I', '2', '4') /*  8  8-bit 
color   */
 #define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV 4:2:0 
16x16 macroblocks */
 #define V4L2_PIX_FMT_M420v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 
2 lines y, 1 line uv interleaved */
@@ -540,6 +534,14 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 
4:2:0 64x32 macroblocks */
 #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
Y/CbCr 4:2:0 16x16 macroblocks */
 
+/* three planes - Y Cb, Cr */
+#define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1:0  
   */
+#define V4L2_PIX_FMT_YVU410  v4l2_fourcc('Y', 'V', 'U', '9') /*  9  YVU 4:1:0  
   */
+#define V4L2_PIX_FMT_YUV411P v4l2_fourcc('4', '1', '1', 'P') /* 16  YVU411 
planar */
+#define V4L2_PIX_FMT_YUV420  v4l2_fourcc('Y', 'U', '1', '2') /* 12  YUV 4:2:0  
   */
+#define V4L2_PIX_FMT_YVU420  v4l2_fourcc('Y', 'V', '1', '2') /* 12  YVU 4:2:0  
   */
+#define V4L2_PIX_FMT_YUV422P v4l2_fourcc('4', '2', '2', 'P') /* 16  YVU422 
planar */
+
 /* three non contiguous planes - Y, Cb, Cr */
 #define V4L2_PIX_FMT_YUV420M v4l2_fourcc('Y', 'M', '1', '2') /* 12  YUV420 
planar */
 #define V4L2_PIX_FMT_YVU420M v4l2_fourcc('Y', 'M', '2', '1') /* 12  YVU420 
planar */
-- 
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 3/3] media: i2c/soc_camera: fix ov6650 sensor getting wrong clock

[Janusz Krzysztofik]

After changes to v4l2_clk API introduced in v4.1 by commits a37462b919
'[media] V4L: remove clock name from v4l2_clk API' and 4f528afcfb
'[media] V4L: add CCF support to the v4l2_clk API', ov6650 sensor
stopped responding because v4l2_clk_get(), still called with
depreciated V4L2 clock name "mclk", started to return respective CCF
clock instead of the V4l2 one registered by soc_camera. Fix it by
calling v4l2_clk_get() with NULL clock name.

Created and tested on Amstrad Delta against Linux-4.7-rc3 with
omap1_camera fixes.

Signed-off-by: Janusz Krzysztofik 
---
 drivers/media/i2c/soc_camera/ov6650.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/soc_camera/ov6650.c 
b/drivers/media/i2c/soc_camera/ov6650.c
index 1f8af1e..1e4783b 100644
--- a/drivers/media/i2c/soc_camera/ov6650.c
+++ b/drivers/media/i2c/soc_camera/ov6650.c
@@ -1033,7 +1033,7 @@ static int ov6650_probe(struct i2c_client *client,
priv->code= MEDIA_BUS_FMT_YUYV8_2X8;
priv->colorspace  = V4L2_COLORSPACE_JPEG;
 
-   priv->clk = v4l2_clk_get(>dev, "mclk");
+   priv->clk = v4l2_clk_get(>dev, NULL);
if (IS_ERR(priv->clk)) {
ret = PTR_ERR(priv->clk);
goto eclkget;
-- 
2.7.3

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

[PATCH 2/3] staging: media: omap1: fix sensor probe not working anymore

[Janusz Krzysztofik]

After clock_start() removal from from soc_camera_probe() (commit
9aea470b39 '[media] soc-camera: switch I2C subdevice drivers to use
v4l2-clk', introduced in v3.11), it occurred omap1_camera's sensor
can't be probed successfully without its clock being turned on in
advance. Fix that by surrounding soc_camera_host_register() invocation
with clock_start() / clock_stop().

Created and tested on Amstrad Delta against Linux-4.7-rc3 with
'staging: media: omap1: fix null pointer dereference in
omap1_cam_probe()' applied.

Signed-off-by: Janusz Krzysztofik 
---
 drivers/staging/media/omap1/omap1_camera.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/omap1/omap1_camera.c 
b/drivers/staging/media/omap1/omap1_camera.c
index dc35d30..9b6140a 100644
--- a/drivers/staging/media/omap1/omap1_camera.c
+++ b/drivers/staging/media/omap1/omap1_camera.c
@@ -1650,7 +1650,11 @@ static int omap1_cam_probe(struct platform_device *pdev)
pcdev->soc_host.v4l2_dev.dev= >dev;
pcdev->soc_host.nr  = pdev->id;
 
-   err = soc_camera_host_register(>soc_host);
+   err = omap1_cam_clock_start(>soc_host);
+   if (!err) {
+   err = soc_camera_host_register(>soc_host);
+   omap1_cam_clock_stop(>soc_host);
+   }
if (err)
return err;
 
-- 
2.7.3

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

[PATCH 1/3] staging: media: omap1: fix null pointer dereference in omap1_cam_probe()

[Janusz Krzysztofik]

Commit 76e543382bd4 ("staging: media: omap1: Switch to
devm_ioremap_resource") moved assignment of struct resource *res =
platform_get_resource() several lines down. That resulted in the
following error:

[3.793237] Unable to handle kernel NULL pointer dereference at virtual 
address 0004
[3.802198] pgd = c0004000
[3.805202] [0004] *pgd=
[3.809373] Internal error: Oops: c5 [#1] ARM
[3.814070] CPU: 0 PID: 1 Comm: swapper Not tainted 4.6.0-rc1+ #70
[3.820570] Hardware name: Amstrad E3 (Delta)
[3.825232] task: c1819440 ti: c181e000 task.ti: c181e000
[3.830973] PC is at omap1_cam_probe+0x48/0x2d4
[3.835873] LR is at devres_add+0x20/0x28

Move the assignment back up where it was before - it is used to build
an argument for a subsequent devm_kzalloc(). Also, restore the check
for null value of res - it shouldn't hurt.

While being at it:
- follow the recently introduced convention of direct return
  instead of jump to return with err value assigned,
- drop no longer needed res member from the definition of struct
  omap1_cam_dev.

Created and tested on Amstrad Delta aginst Linux-4.7-rc3

Signed-off-by: Janusz Krzysztofik 
---
 drivers/staging/media/omap1/omap1_camera.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/media/omap1/omap1_camera.c 
b/drivers/staging/media/omap1/omap1_camera.c
index 54b8dd2..dc35d30 100644
--- a/drivers/staging/media/omap1/omap1_camera.c
+++ b/drivers/staging/media/omap1/omap1_camera.c
@@ -158,7 +158,6 @@ struct omap1_cam_dev {
int dma_ch;
 
struct omap1_cam_platform_data  *pdata;
-   struct resource *res;
unsigned long   pflags;
unsigned long   camexclk;
 
@@ -1569,11 +1568,10 @@ static int omap1_cam_probe(struct platform_device *pdev)
unsigned int irq;
int err = 0;
 
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
irq = platform_get_irq(pdev, 0);
-   if ((int)irq <= 0) {
-   err = -ENODEV;
-   goto exit;
-   }
+   if (!res || (int)irq <= 0)
+   return -ENODEV;
 
clk = devm_clk_get(>dev, "armper_ck");
if (IS_ERR(clk))
@@ -1614,7 +1612,6 @@ static int omap1_cam_probe(struct platform_device *pdev)
INIT_LIST_HEAD(>capture);
spin_lock_init(>lock);
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(>dev, res);
if (IS_ERR(base))
return PTR_ERR(base);
@@ -1663,7 +1660,6 @@ static int omap1_cam_probe(struct platform_device *pdev)
 
 exit_free_dma:
omap_free_dma(pcdev->dma_ch);
-exit:
return err;
 }
 
-- 
2.7.3

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

[linuxtv-media:master 229/231] DockBook: include/media/media-devnode.h:102: warning: No description found for parameter 'media_dev'

[kbuild test robot]

tree:   git://linuxtv.org/media_tree.git master
head:   6f0dd24a084a17f9984dd49dffbf7055bf123993
commit: a087ce704b802becbb4b0f2a20f2cb3f6911802e [229/231] [media] 
media-device: dynamically allocate struct media_devnode
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   include/linux/init.h:1: warning: no structured comments found
   kernel/sched/core.c:2079: warning: No description found for parameter 
'cookie'
   kernel/sys.c:1: warning: no structured comments found
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/fence.h:84: warning: No description found for parameter 
'child_list'
   include/linux/fence.h:84: warning: No description found for parameter 
'active_list'
   drivers/dma-buf/reservation.c:1: warning: no structured comments found
   include/linux/reservation.h:1: warning: no structured comments found
>> include/media/media-devnode.h:102: warning: No description found for 
>> parameter 'media_dev'
>> include/media/media-devnode.h:126: warning: No description found for 
>> parameter 'mdev'
>> include/media/media-devnode.h:126: warning: Excess function parameter 
>> 'media_dev' description in 'media_devnode_register'

vim +/media_dev +102 include/media/media-devnode.h

cf4b9211 Laurent Pinchart  2009-12-09   96  /* device info */
cf4b9211 Laurent Pinchart  2009-12-09   97  int minor;
cf4b9211 Laurent Pinchart  2009-12-09   98  unsigned long flags;
/* Use bitops to access flags */
cf4b9211 Laurent Pinchart  2009-12-09   99  
cf4b9211 Laurent Pinchart  2009-12-09  100  /* callbacks */
163f1e93 Mauro Carvalho Chehab 2016-03-23  101  void (*release)(struct 
media_devnode *devnode);
cf4b9211 Laurent Pinchart  2009-12-09 @102  };
cf4b9211 Laurent Pinchart  2009-12-09  103  
cf4b9211 Laurent Pinchart  2009-12-09  104  /* dev to media_devnode */
cf4b9211 Laurent Pinchart  2009-12-09  105  #define to_media_devnode(cd) 
container_of(cd, struct media_devnode, dev)
cf4b9211 Laurent Pinchart  2009-12-09  106  
fe3c565e Mauro Carvalho Chehab 2015-12-13  107  /**
fe3c565e Mauro Carvalho Chehab 2015-12-13  108   * media_devnode_register - 
register a media device node
fe3c565e Mauro Carvalho Chehab 2015-12-13  109   *
a087ce70 Mauro Carvalho Chehab 2016-04-27  110   * @media_dev: struct 
media_device we want to register a device node
163f1e93 Mauro Carvalho Chehab 2016-03-23  111   * @devnode: media device node 
structure we want to register
fe3c565e Mauro Carvalho Chehab 2015-12-13  112   * @owner: should be filled 
with %THIS_MODULE
fe3c565e Mauro Carvalho Chehab 2015-12-13  113   *
fe3c565e Mauro Carvalho Chehab 2015-12-13  114   * The registration code 
assigns minor numbers and registers the new device node
fe3c565e Mauro Carvalho Chehab 2015-12-13  115   * with the kernel. An error is 
returned if no free minor number can be found,
fe3c565e Mauro Carvalho Chehab 2015-12-13  116   * or if the registration of 
the device node fails.
fe3c565e Mauro Carvalho Chehab 2015-12-13  117   *
fe3c565e Mauro Carvalho Chehab 2015-12-13  118   * Zero is returned on success.
fe3c565e Mauro Carvalho Chehab 2015-12-13  119   *
fe3c565e Mauro Carvalho Chehab 2015-12-13  120   * Note that if the 
media_devnode_register call fails, the release() callback of
fe3c565e Mauro Carvalho Chehab 2015-12-13  121   * the media_devnode structure 
is *not* called, so the caller is responsible for
fe3c565e Mauro Carvalho Chehab 2015-12-13  122   * freeing any data.
fe3c565e Mauro Carvalho Chehab 2015-12-13  123   */
a087ce70 Mauro Carvalho Chehab 2016-04-27  124  int __must_check 
media_devnode_register(struct media_device *mdev,
a087ce70 Mauro Carvalho Chehab 2016-04-27  125  
struct media_devnode *devnode,
85de721c Sakari Ailus  2013-12-12 @126  
struct module *owner);
fe3c565e Mauro Carvalho Chehab 2015-12-13  127  
fe3c565e Mauro Carvalho Chehab 2015-12-13  128  /**
fe3c565e Mauro Carvalho Chehab 2015-12-13  129   * media_devnode_unregister - 
unregister a media device node

:: The code at line 102 was first introduced by commit
:: cf4b9211b5680cd9ca004232e517fb7ec5bf5316 [media] media: Media device 
node support

:: TO: Laurent Pinchart 
:: CC: Mauro Carvalho Chehab 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH 0/3] media: fixes for Amstrad Delta camera

[Janusz Krzysztofik]

Janusz Krzysztofik (3):
  staging: media: omap1: fix null pointer dereference in
omap1_cam_probe()
  staging: media: omap1: fix sensor probe not working anymore
  media: i2c/soc_camera: fix ov6650 sensor getting wrong clock

 drivers/media/i2c/soc_camera/ov6650.c  |  2 +-
 drivers/staging/media/omap1/omap1_camera.c | 16 
 2 files changed, 9 insertions(+), 9 deletions(-)

-- 
2.7.3

--
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/3] drivers/media/media-device: fix double free bug in _unregister()

[Shuah Khan]

On 06/15/2016 02:37 PM, Max Kellermann wrote:
> On 2016/06/15 22:32, Shuah Khan  wrote:
>> This change introduces memory leaks, since drivers are relying on
>> media_device_unregister() to free interfaces.
> 
> This is what I thought, too, until I checked the code paths.  Who adds
> entries to that list?  Only media_gobj_create() does, and only when
> type==MEDIA_GRAPH_INTF_DEVNODE.  That is called via
> media_interface_init(), via media_devnode_create().
> 
> In the whole kernel, there are two calls to media_devnode_create():
> one in dvbdev.c and another one in v4l2-dev.c.  Both callers take care
> for freeing their interface.  Both would crash if somebody else would
> free it for them before they get a chance to do it.  Which is the very
> thing my patch addresses.
> 
> Did I miss something?
> 

Yes media_devnode_create() creates the interfaces links and these links
are deleted by media_devnode_remove(). media_device_unregister() still
needs to delete the interfaces links. The reason for that is the API
dynalic use-case.

Drivers (other than dvb-core and v4l2-core) can create and delete media
devnode interfaces during run-time, hence media_devnode_remove() has to
call media_remove_intf_links(). However, driver isn't required to call
media_devnode_remove() and media-core can't enforce that. So it is safe
for media_device_unregister() to remove interface links if the list isn't
empty. If driver does delete them,  media_device_unregister() has nothing
to do since the list is going to be empty.

So removing kfree() from media_device_unregister() isn't the correct
fix.

I don't see the stack trace for the double free error you are seeing? Could
it be that there is a driver problem in the order in which it is calling
media_device_unregister()?

thanks,
-- Shuah
--
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/3] drivers/media/media-device: fix double free bug in _unregister()

[Max Kellermann]

On 2016/06/15 22:32, Shuah Khan  wrote:
> This change introduces memory leaks, since drivers are relying on
> media_device_unregister() to free interfaces.

This is what I thought, too, until I checked the code paths.  Who adds
entries to that list?  Only media_gobj_create() does, and only when
type==MEDIA_GRAPH_INTF_DEVNODE.  That is called via
media_interface_init(), via media_devnode_create().

In the whole kernel, there are two calls to media_devnode_create():
one in dvbdev.c and another one in v4l2-dev.c.  Both callers take care
for freeing their interface.  Both would crash if somebody else would
free it for them before they get a chance to do it.  Which is the very
thing my patch addresses.

Did I miss something?

Max
--
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/3] drivers/media/media-device: fix double free bug in _unregister()

[Shuah Khan]

On 06/15/2016 02:15 PM, Max Kellermann wrote:
> While removing all interfaces in media_device_unregister(), all
> media_interface pointers are freed.  This is illegal and results in
> double kfree() if any media_interface is still linked at this point;
> maybe because a userspace process still has a file handle.  Once the
> process closes the file handle, dvb_media_device_free() gets called,
> which frees the dvb_device.intf_devnode again.
> 
> This patch removes the unnecessary kfree() call, and documents who's
> responsible for really freeing it.
> 
> Signed-off-by: Max Kellermann 
> ---
>  drivers/media/media-device.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 33a9952..1db4707 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -799,9 +799,11 @@ void media_device_unregister(struct media_device *mdev)
>   /* Remove all interfaces from the media device */
>   list_for_each_entry_safe(intf, tmp_intf, >interfaces,
>graph_obj.list) {
> + /* unlink the interface, but don't free it here; the
> +module which created it is responsible for freeing
> +it */
>   __media_remove_intf_links(intf);
>   media_gobj_destroy(>graph_obj);
> - kfree(intf);

This change introduces memory leaks, since drivers are relying on
media_device_unregister() to free interfaces.

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

[PATCH 1/3] drivers/media/dvb-core/en50221: use kref to manage struct dvb_ca_private

[Max Kellermann]

Don't free the object until the file handle has been closed.  Fixes
use-after-free bug which occurs when I disconnect my DVB-S received
while VDR is running.

Signed-off-by: Max Kellermann 
---
 drivers/media/dvb-core/dvb_ca_en50221.c |   24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c 
b/drivers/media/dvb-core/dvb_ca_en50221.c
index b1e3a26..b5b5b19 100644
--- a/drivers/media/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb-core/dvb_ca_en50221.c
@@ -123,6 +123,7 @@ struct dvb_ca_slot {
 
 /* Private CA-interface information */
 struct dvb_ca_private {
+   struct kref refcount;
 
/* pointer back to the public data structure */
struct dvb_ca_en50221 *pub;
@@ -173,6 +174,22 @@ static void dvb_ca_private_free(struct dvb_ca_private *ca)
kfree(ca);
 }
 
+static void dvb_ca_private_release(struct kref *ref)
+{
+   struct dvb_ca_private *ca = container_of(ref, struct dvb_ca_private, 
refcount);
+   dvb_ca_private_free(ca);
+}
+
+static void dvb_ca_private_get(struct dvb_ca_private *ca)
+{
+   kref_get(>refcount);
+}
+
+static void dvb_ca_private_put(struct dvb_ca_private *ca)
+{
+   kref_put(>refcount, dvb_ca_private_release);
+}
+
 static void dvb_ca_en50221_thread_wakeup(struct dvb_ca_private *ca);
 static int dvb_ca_en50221_read_data(struct dvb_ca_private *ca, int slot, u8 * 
ebuf, int ecount);
 static int dvb_ca_en50221_write_data(struct dvb_ca_private *ca, int slot, u8 * 
ebuf, int ecount);
@@ -1570,6 +1587,8 @@ static int dvb_ca_en50221_io_open(struct inode *inode, 
struct file *file)
dvb_ca_en50221_thread_update_delay(ca);
dvb_ca_en50221_thread_wakeup(ca);
 
+   dvb_ca_private_get(ca);
+
return 0;
 }
 
@@ -1598,6 +1617,8 @@ static int dvb_ca_en50221_io_release(struct inode *inode, 
struct file *file)
 
module_put(ca->pub->owner);
 
+   dvb_ca_private_put(ca);
+
return err;
 }
 
@@ -1693,6 +1714,7 @@ int dvb_ca_en50221_init(struct dvb_adapter *dvb_adapter,
ret = -ENOMEM;
goto exit;
}
+   kref_init(>refcount);
ca->pub = pubca;
ca->flags = flags;
ca->slot_count = slot_count;
@@ -1772,6 +1794,6 @@ void dvb_ca_en50221_release(struct dvb_ca_en50221 *pubca)
for (i = 0; i < ca->slot_count; i++) {
dvb_ca_en50221_slot_shutdown(ca, i);
}
-   dvb_ca_private_free(ca);
+   dvb_ca_private_put(ca);
pubca->private = NULL;
 }

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

[PATCH 2/3] drivers/media/media-entity: clear media_gobj.mdev in _destroy()

[Max Kellermann]

media_gobj_destroy() may be called twice on one instance - once by
media_device_unregister() and again by dvb_media_device_free().  The
function media_remove_intf_links() establishes and documents the
convention that mdev==NULL means that the object is not registered,
but nobody ever NULLs this variable.  So this patch really implements
this behavior, and adds another mdev==NULL check to
media_gobj_destroy() to protect against double removal.

Signed-off-by: Max Kellermann 
---
 drivers/media/media-entity.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index d8a2299..9526338 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -203,10 +203,16 @@ void media_gobj_destroy(struct media_gobj *gobj)
 {
dev_dbg_obj(__func__, gobj);
 
+   /* Do nothing if the object is not linked. */
+   if (gobj->mdev == NULL)
+   return;
+
gobj->mdev->topology_version++;
 
/* Remove the object from mdev list */
list_del(>list);
+
+   gobj->mdev = NULL;
 }
 
 int media_entity_pads_init(struct media_entity *entity, u16 num_pads,

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

[PATCH 3/3] drivers/media/media-device: fix double free bug in _unregister()

[Max Kellermann]

While removing all interfaces in media_device_unregister(), all
media_interface pointers are freed.  This is illegal and results in
double kfree() if any media_interface is still linked at this point;
maybe because a userspace process still has a file handle.  Once the
process closes the file handle, dvb_media_device_free() gets called,
which frees the dvb_device.intf_devnode again.

This patch removes the unnecessary kfree() call, and documents who's
responsible for really freeing it.

Signed-off-by: Max Kellermann 
---
 drivers/media/media-device.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 33a9952..1db4707 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -799,9 +799,11 @@ void media_device_unregister(struct media_device *mdev)
/* Remove all interfaces from the media device */
list_for_each_entry_safe(intf, tmp_intf, >interfaces,
 graph_obj.list) {
+   /* unlink the interface, but don't free it here; the
+  module which created it is responsible for freeing
+  it */
__media_remove_intf_links(intf);
media_gobj_destroy(>graph_obj);
-   kfree(intf);
}
 
mutex_unlock(>graph_mutex);

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

Need help with ir-keytable imon bug report

[Gregor Jasny]

Hello,

could someone please help me triaging the following ir-keytable bug? The
reporter complains that the 'other' IR protocol results in double clicks
and we should set the device to RC6 instead:

https://bugs.launchpad.net/ubuntu/+source/v4l-utils/+bug/1579760

This is what we have in v4l-utils:
https://git.linuxtv.org/v4l-utils.git/tree/utils/keytable/rc_keymaps/imon_pad

Thanks for you help,
Gregor
--
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

BUSINESS VORSCHLAG

[Mr. phil]

BUSINESS VORSCHLAG

Ich vertrete eine Investition Interesse von Dubai für die wir Ihre Teilnahme 
als Vertreter Übersee suchen. Die Antwort auf e-Mail unten, wenn interessiert.
E-Mail: philipber...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] media: et8ek8: Add documentation

[Ivaylo Dimitrov]

On 15.06.2016 21:41, Rob Herring wrote:

On Tue, Jun 14, 2016 at 11:31 PM, Sakari Ailus  wrote:

Hi Rob,

On Tue, Jun 14, 2016 at 05:05:17PM -0500, Rob Herring wrote:

On Sat, Jun 11, 2016 at 06:39:53PM +0300, Ivaylo Dimitrov wrote:

Add DT bindings description


Not exactly the best commit msg.



will elaborate a bit more in the next patch version



Signed-off-by: Ivaylo Dimitrov 
---
  .../bindings/media/i2c/toshiba,et8ek8.txt  | 50 ++
  1 file changed, 50 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt 
b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
new file mode 100644
index 000..997d268
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
@@ -0,0 +1,50 @@
+Toshiba et8ek8 5MP sensor
+
+Toshiba et8ek8 5MP sensor is an image sensor found in Nokia N900 device
+
+More detailed documentation can be found in
+Documentation/devicetree/bindings/media/video-interfaces.txt .
+
+
+Mandatory properties
+
+
+- compatible: "toshiba,et8ek8"
+- reg: I2C address (0x3e, or an alternative address)
+- vana-supply: Analogue voltage supply (VANA), 2.8 volts



+- clocks: External clock to the sensor
+- clock-frequency: Frequency of the external clock to the sensor


These should be mutually-exclusive. If you have a clock, then you can
get the frequency at runtime.


Yes, you can. But the intention is to set the frequency: the sensor requires
a particular, pre-determined frequency. Typically this is specific to the
board.


Okay, then state that in the description.



ok, will do in the next patch version

Thanks,
Ivo
--
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 v3 2/2] media: et8ek8: Add documentation

[Rob Herring]

On Tue, Jun 14, 2016 at 11:31 PM, Sakari Ailus  wrote:
> Hi Rob,
>
> On Tue, Jun 14, 2016 at 05:05:17PM -0500, Rob Herring wrote:
>> On Sat, Jun 11, 2016 at 06:39:53PM +0300, Ivaylo Dimitrov wrote:
>> > Add DT bindings description
>>
>> Not exactly the best commit msg.
>>
>> >
>> > Signed-off-by: Ivaylo Dimitrov 
>> > ---
>> >  .../bindings/media/i2c/toshiba,et8ek8.txt  | 50 
>> > ++
>> >  1 file changed, 50 insertions(+)
>> >  create mode 100644 
>> > Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
>> >
>> > diff --git 
>> > a/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt 
>> > b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
>> > new file mode 100644
>> > index 000..997d268
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/i2c/toshiba,et8ek8.txt
>> > @@ -0,0 +1,50 @@
>> > +Toshiba et8ek8 5MP sensor
>> > +
>> > +Toshiba et8ek8 5MP sensor is an image sensor found in Nokia N900 device
>> > +
>> > +More detailed documentation can be found in
>> > +Documentation/devicetree/bindings/media/video-interfaces.txt .
>> > +
>> > +
>> > +Mandatory properties
>> > +
>> > +
>> > +- compatible: "toshiba,et8ek8"
>> > +- reg: I2C address (0x3e, or an alternative address)
>> > +- vana-supply: Analogue voltage supply (VANA), 2.8 volts
>>
>> > +- clocks: External clock to the sensor
>> > +- clock-frequency: Frequency of the external clock to the sensor
>>
>> These should be mutually-exclusive. If you have a clock, then you can
>> get the frequency at runtime.
>
> Yes, you can. But the intention is to set the frequency: the sensor requires
> a particular, pre-determined frequency. Typically this is specific to the
> board.

Okay, then state that in the description.

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

Re: [PATCH v2] [media] adv7604: Add support for hardware reset

[Laurent Pinchart]

Hi Dragos,

Thank you for the patch.

On Tuesday 24 May 2016 17:33:27 Dragos Bogdan wrote:
> The part can be reset by a low pulse on the RESET pin (i.e. a hardware
> reset) with a minimum width of 5 ms. It is recommended to wait 5 ms
> after the low pulse before an I2C write is performed to the part.
> For safety reasons, the delays will be between 5 and 10 ms.
> 
> The RESET pin can be tied high, so the GPIO is optional.
> 
> Signed-off-by: Dragos Bogdan 
> ---
> Changes since v1:
>  - Replace mdelay() with usleep_range();
>  - Limit the comments to 75 characters per line.
> 
>  drivers/media/i2c/adv7604.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 41a1bfc..73c79bb 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -164,6 +164,7 @@ struct adv76xx_state {
>   struct adv76xx_platform_data pdata;
> 
>   struct gpio_desc *hpd_gpio[4];
> + struct gpio_desc *reset_gpio;
> 
>   struct v4l2_subdev sd;
>   struct media_pad pads[ADV76XX_PAD_MAX];
> @@ -2996,6 +2997,21 @@ static int configure_regmaps(struct adv76xx_state
> *state) return 0;
>  }
> 
> +static int adv76xx_reset(struct adv76xx_state *state)

Given that the function always returns 0 and that the return value is never 
checked I'd turn it into a void function.

> +{
> + if (state->reset_gpio) {

Nitpicking, if you write this as

if (!state->reset_gpio)
return;

then you can lower the indendation of the following code block. That's a 
matter of style and preferences though, so I'll let you decide what you 
prefer.

Apart from that,

Acked-by: Laurent Pinchart 

> + /* ADV76XX can be reset by a low reset pulse of minimum 5 ms. */
> + gpiod_set_value_cansleep(state->reset_gpio, 0);
> + usleep_range(5000, 1);
> + gpiod_set_value_cansleep(state->reset_gpio, 1);
> + /* It is recommended to wait 5 ms after the low pulse before */
> + /* an I2C write is performed to the ADV76XX. */
> + usleep_range(5000, 1);
> + }
> +
> + return 0;
> +}
> +
>  static int adv76xx_probe(struct i2c_client *client,
>const struct i2c_device_id *id)
>  {
> @@ -3059,6 +3075,12 @@ static int adv76xx_probe(struct i2c_client *client,
>   if (state->hpd_gpio[i])
>   v4l_info(client, "Handling HPD %u GPIO\n", i);
>   }
> + state->reset_gpio = devm_gpiod_get_optional(>dev, "reset",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(state->reset_gpio))
> + return PTR_ERR(state->reset_gpio);
> +
> + adv76xx_reset(state);
> 
>   state->timings = cea640x480;
>   state->format = adv76xx_format_info(state, MEDIA_BUS_FMT_YUYV8_2X8);

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 35/38] media: adv7180: add power pin control

[Lars-Peter Clausen]

On 06/15/2016 12:49 AM, Steve Longerbeam wrote:
> + usleep_range(5000, 5001);

That's kind of not how usleep_range() (the emphasis is on range) is supposed
to be used. You typically dont care too much about the upper limit here so
something like maybe 1 is more appropriate.


> +static int adv7180_of_parse(struct adv7180_state *state)
> +{
> + struct i2c_client *client = state->client;
> + struct device_node *np = client->dev.of_node;
> + int ret;
> +
> + ret = of_get_named_gpio(np, "pwdn-gpio", 0);
> +
> + if (gpio_is_valid(ret)) {
> + state->pwdn_gpio = ret;
> + ret = devm_gpio_request_one(>dev,
> + state->pwdn_gpio,
> + GPIOF_OUT_INIT_HIGH,
> + "adv7180_pwdn");


This should use the new GPIO descriptor API. That will also make the code
devicetree independent. Otherwise patch looks OK.

> + if (ret < 0) {
> + v4l_err(client, "request for power pin failed\n");
> + return ret;
> + }
> + } else {
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + /* assume a power-down gpio is not required */
> + state->pwdn_gpio = -1;
> + }
> +
> + return 0;
> +}

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

Astrometa DVB-T2 not working correctly with Kernel 4.6

[Ferda Mravenec]

Hello everybody,

I own this TV stick:

https://www.linuxtv.org/wiki/index.php/Astrometa_DVB-T2

It uses different chips to decode DVB-T and DVB-T2 streams, the required 
modules are rtl2832 and mn88473.

Up until linux 4.5 it worked correctly, in 4.6 only DVB-T works.
In 4.6 the mn88473 module isn’t loaded automatically and can’t be loaded 
manually, since it doesn’t exist in the system.


In 4.6 the module has been moved from staging to dvb-frontends.
I tried to build it with

make M=drivers/media/dvb-frontends

which gave me *.ko files for the other frontends, but not for mn88473.

I attached the relevant output of dmesg.

Regards
Ferda
usb 2-4: new high-speed USB device number 6 using xhci_hcd
usb 2-4: dvb_usb_v2: found a 'Astrometa DVB-T2' in warm state
usb 2-4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the 
software demuxer
DVB: registering new adapter (Astrometa DVB-T2)
i2c i2c-8: Added multiplexed i2c bus 9
rtl2832 8-0010: Realtek RTL2832 successfully attached
mn88473: module is from the staging directory, the quality is unknown, you have 
been warned.
mn88473 8-0018: Panasonic MN88473 successfully attached
usb 2-4: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
usb 2-4: DVB: registering adapter 0 frontend 1 (Panasonic MN88473)...
r820t 9-003a: creating new instance
r820t 9-003a: Rafael Micro r820t successfully identified
r820t 9-003a: attaching existing instance
r820t 9-003a: Rafael Micro r820t successfully identified
rtl2832_sdr rtl2832_sdr.1.auto: Registered as swradio0
rtl2832_sdr rtl2832_sdr.1.auto: Realtek RTL2832 SDR attached
rtl2832_sdr rtl2832_sdr.1.auto: SDR API is still slightly experimental and 
functionality changes may follow
Registered IR keymap rc-empty
input: Astrometa DVB-T2 as 
/devices/pci:00/:00:14.0/usb2/2-4/rc/rc0/input17
rc rc0: Astrometa DVB-T2 as /devices/pci:00/:00:14.0/usb2/2-4/rc/rc0
usb 2-4: dvb_usb_v2: schedule remote query interval to 200 msecs
usb 2-4: dvb_usb_v2: 'Astrometa DVB-T2' successfully initialized and connected
usbcore: registered new interface driver dvb_usb_rtl28xxu
lirc_dev: IR Remote Control driver registered, major 244 
rc rc0: lirc_dev: driver ir-lirc-codec (dvb_usb_rtl28xxu) registered at minor = 0
IR LIRC bridge handler initialized
usb 2-4: new high-speed USB device number 6 using xhci_hcd
usb 2-4: dvb_usb_v2: found a 'Astrometa DVB-T2' in warm state
usb 2-4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the 
software demuxer
DVB: registering new adapter (Astrometa DVB-T2)
i2c i2c-8: Added multiplexed i2c bus 9
rtl2832 8-0010: Realtek RTL2832 successfully attached
usb 2-4: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
r820t 9-003a: creating new instance
r820t 9-003a: Rafael Micro r820t successfully identified
rtl2832_sdr rtl2832_sdr.1.auto: Registered as swradio0
rtl2832_sdr rtl2832_sdr.1.auto: Realtek RTL2832 SDR attached
SDR API is still slightly experimental and functionality changes may follow
Registered IR keymap rc-empty
input: Astrometa DVB-T2 as 
/devices/pci:00/:00:14.0/usb2/2-4/rc/rc0/input17
Astrometa DVB-T2 as /devices/pci:00/:00:14.0/usb2/2-4/rc/rc0
usb 2-4: dvb_usb_v2: schedule remote query interval to 200 msecs
usb 2-4: dvb_usb_v2: 'Astrometa DVB-T2' successfully initialized and connected
usbcore: registered new interface driver dvb_usb_rtl28xxu
lirc_dev: IR Remote Control driver registered, major 242 
rc rc0: lirc_dev: driver ir-lirc-codec (dvb_usb_rtl28xxu) registered at minor = 0
IR LIRC bridge handler initialized

[PATCHv2] v4l2-ctrl.h: fix comments

[Hans Verkuil]

The comments for the unlocked v4l2_ctrl_s_ctrl* functions were wrong (copy
and pasted from the locked variants). Fix this, since it is confusing.

Signed-off-by: Hans Verkuil 
---
Fixed the v4l2_ctrl_s_ctrl_int64() comment, which was inadvertently changed
as well.

Thanks to Ian Arkver for reporting this.
---
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 0bc9b35..5c2ed0c 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -759,9 +759,9 @@ s32 v4l2_ctrl_g_ctrl(struct v4l2_ctrl *ctrl);
  * @ctrl:  The control.
  * @val:   The new value.
  *
- * This set the control's new value safely by going through the control
- * framework. This function will lock the control's handler, so it cannot be
- * used from within the _ctrl_ops functions.
+ * This sets the control's new value safely by going through the control
+ * framework. This function assumes the control's handler is already locked,
+ * allowing it to be used from within the _ctrl_ops functions.
  *
  * This function is for integer type controls only.
  */
@@ -771,7 +771,7 @@ int __v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val);
  * @ctrl:  The control.
  * @val:   The new value.
  *
- * This set the control's new value safely by going through the control
+ * This sets the control's new value safely by going through the control
  * framework. This function will lock the control's handler, so it cannot be
  * used from within the _ctrl_ops functions.
  *
@@ -807,9 +807,9 @@ s64 v4l2_ctrl_g_ctrl_int64(struct v4l2_ctrl *ctrl);
  * @ctrl:  The control.
  * @val:   The new value.
  *
- * This set the control's new value safely by going through the control
- * framework. This function will lock the control's handler, so it cannot be
- * used from within the _ctrl_ops functions.
+ * This sets the control's new value safely by going through the control
+ * framework. This function assumes the control's handler is already locked,
+ * allowing it to be used from within the _ctrl_ops functions.
  *
  * This function is for 64-bit integer type controls only.
  */
@@ -821,7 +821,7 @@ int __v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl *ctrl, s64 
val);
  * @ctrl:  The control.
  * @val:   The new value.
  *
- * This set the control's new value safely by going through the control
+ * This sets the control's new value safely by going through the control
  * framework. This function will lock the control's handler, so it cannot be
  * used from within the _ctrl_ops functions.
  *
@@ -843,9 +843,9 @@ static inline int v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl 
*ctrl, s64 val)
  * @ctrl:  The control.
  * @s: The new string.
  *
- * This set the control's new string safely by going through the control
- * framework. This function will lock the control's handler, so it cannot be
- * used from within the _ctrl_ops functions.
+ * This sets the control's new string safely by going through the control
+ * framework. This function assumes the control's handler is already locked,
+ * allowing it to be used from within the _ctrl_ops functions.
  *
  * This function is for string type controls only.
  */
@@ -857,7 +857,7 @@ int __v4l2_ctrl_s_ctrl_string(struct v4l2_ctrl *ctrl, const 
char *s);
  * @ctrl:  The control.
  * @s: The new string.
  *
- * This set the control's new string safely by going through the control
+ * This sets the control's new string safely by going through the control
  * framework. This function will lock the control's handler, so it cannot be
  * used from within the _ctrl_ops functions.
  *
--
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] hsi: Build hsi_boardinfo.c into hsi core if enabled

[Sebastian Reichel]

Hi Andrew,

On Tue, Jun 14, 2016 at 11:13:04AM -0500, Andrew F. Davis wrote:
> If the HSI core is built as a module hsi_boardinfo may still
> be built-in as its Kconfig type is bool, which can cause build
> issues. Fix this by building this code into the HSI core when
> enabled.
> 
> Reported-by: kbuild test robot 
> Signed-off-by: Andrew F. Davis 
> ---
> This build error seems to be due to Kconfig symbol CONFIG_HSI_BOARDINFO
> being a bool but depending on a tristate (CONFIG_HSI). This is normally
> okay when it is just a flag to enable a feature in source, but the
> helper code file hsi_boardinfo.c is built as a separate entity when
> enabled. This patch is probably how it was intended, and is more like
> how others do this kind of thing.
> 
> This patch should be applied before the parent patch:

Thanks, I applied both patches.

-- Sebastian


signature.asc
Description: PGP signature

Re: [very-RFC 7/8] AVB ALSA - Add ALSA shim for TSN

[Richard Cochran]

On Wed, Jun 15, 2016 at 02:13:03PM +0200, Henrik Austad wrote:
> On Wed, Jun 15, 2016 at 01:49:08PM +0200, Richard Cochran wrote:
> And how would v4l2 benefit from this being in alsalib? Should we require 
> both V4L and ALSA to implement the same, or should we place it in a common 
> place for all.

I don't require V4L to implement anything.  You were the one wanting
AVB "devices".  Go ahead and do that, but in user space please.  We
don't want to have kernel code that sends arbitrary Layer2 and UDP
media packets.

The example you present of using aplay over the network is a cute
idea, but after all it is a trivial application.  I have nothing
against creating virtual ALSA devices (if done properly), but that
model won't work for more realistic AVB networks.

> And what about those systems that want to use TSN but is not a 
> media-device, they should be given a raw-socket to send traffic over, 
> should they also implement something in a library?

A raw socket is the way to do it, yes.

Since TSN is about bandwidth reservation and time triggered Ethernet,
decoupled from the contents of the streams, each new TSN application
will have to see what works best.  If common ground is found, then a
library makes sense to do.

At this point, it is way too early to guess how that will look.  But
media packet formats clearly belong in user space.

> So no, here I think configfs is an apt choice.
> 
> > Heck, if done properly, your layer could discover the AVB nodes in the
> > network and present each one as a separate device...
> 
> No, you definately do not want the kernel to automagically add devices 
> whenever something pops up on the network, for this you need userspace to 
> be in control. 1722.1 should not be handled in-kernel.

The layer should be in user space.  Alsa-lib *is* user space.

Thanks,
Richard
--
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] v4l2-ctrl.h: fix comments

[Ian Arkver]

On 15/06/16 11:10, Hans Verkuil wrote:

The comments for the unlocked v4l2_ctrl_s_ctrl* functions were wrong (copy
and pasted from the locked variants). Fix this, since it is confusing.

Signed-off-by: Hans Verkuil 

diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 0bc9b35..e9e87e023 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -759,9 +759,9 @@ s32 v4l2_ctrl_g_ctrl(struct v4l2_ctrl *ctrl);
   * @ctrl: The control.
   * @val:  The new value.
   *
- * This set the control's new value safely by going through the control
- * framework. This function will lock the control's handler, so it cannot be
- * used from within the _ctrl_ops functions.
+ * This sets the control's new value safely by going through the control
+ * framework. This function assumes the control's handler is already locked,
+ * allowing it to be used from within the _ctrl_ops functions.
   *
   * This function is for integer type controls only.
   */
@@ -771,7 +771,7 @@ int __v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val);
   * @ctrl: The control.
   * @val:  The new value.
   *
- * This set the control's new value safely by going through the control
+ * This sets the control's new value safely by going through the control
   * framework. This function will lock the control's handler, so it cannot be
   * used from within the _ctrl_ops functions.
   *
@@ -807,9 +807,9 @@ s64 v4l2_ctrl_g_ctrl_int64(struct v4l2_ctrl *ctrl);
   * @ctrl: The control.
   * @val:  The new value.
   *
- * This set the control's new value safely by going through the control
- * framework. This function will lock the control's handler, so it cannot be
- * used from within the _ctrl_ops functions.
+ * This sets the control's new value safely by going through the control
+ * framework. This function assumes the control's handler is already locked,
+ * allowing it to be used from within the _ctrl_ops functions.
   *
   * This function is for 64-bit integer type controls only.
   */
@@ -821,9 +821,9 @@ int __v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl *ctrl, s64 
val);
   * @ctrl: The control.
   * @val:  The new value.
   *
- * This set the control's new value safely by going through the control
- * framework. This function will lock the control's handler, so it cannot be
- * used from within the _ctrl_ops functions.
+ * This sets the control's new value safely by going through the control
+ * framework. This function does not lock the control's handler, allowing it to
+ * be used from within the _ctrl_ops functions.
   *
   * This function is for 64-bit integer type controls only.
   */
I think this comment is above v4l2_ctrl_s_ctrl_int64, without the 
underscores. Doesn't this fn take the lock, or have I missed a patch 
that removes that?



@@ -843,9 +843,9 @@ static inline int v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl 
*ctrl, s64 val)
   * @ctrl: The control.
   * @s:The new string.
   *
- * This set the control's new string safely by going through the control
- * framework. This function will lock the control's handler, so it cannot be
- * used from within the _ctrl_ops functions.
+ * This sets the control's new string safely by going through the control
+ * framework. This function assumes the control's handler is already locked,
+ * allowing it to be used from within the _ctrl_ops functions.
   *
   * This function is for string type controls only.
   */
@@ -857,7 +857,7 @@ int __v4l2_ctrl_s_ctrl_string(struct v4l2_ctrl *ctrl, const 
char *s);
   * @ctrl: The control.
   * @s:The new string.
   *
- * This set the control's new string safely by going through the control
+ * This sets the control's new string safely by going through the control
   * framework. This function will lock the control's handler, so it cannot be
   * used from within the _ctrl_ops functions.
   *
--
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

Regards,
Ian
--
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: [very-RFC 7/8] AVB ALSA - Add ALSA shim for TSN

[Henrik Austad]

On Wed, Jun 15, 2016 at 01:49:08PM +0200, Richard Cochran wrote:
> Now that I understand better...
> 
> On Sun, Jun 12, 2016 at 01:01:35AM +0200, Henrik Austad wrote:
> > Userspace is supposed to reserve bandwidth, find StreamID etc.
> > 
> > To use as a Talker:
> > 
> > mkdir /config/tsn/test/eth0/talker
> > cd /config/tsn/test/eth0/talker
> > echo 65535 > buffer_size
> > echo 08:00:27:08:9f:c3 > remote_mac
> > echo 42 > stream_id
> > echo alsa > enabled
> 
> This is exactly why configfs is the wrong interface.  If you implement
> the AVB device in alsa-lib user space, then you can handle the
> reservations, configuration, UDP sockets, etc, in a way transparent to
> the aplay program.

And how would v4l2 benefit from this being in alsalib? Should we require 
both V4L and ALSA to implement the same, or should we place it in a common 
place for all.

And what about those systems that want to use TSN but is not a 
media-device, they should be given a raw-socket to send traffic over, 
should they also implement something in a library?

So no, here I think configfs is an apt choice.

> Heck, if done properly, your layer could discover the AVB nodes in the
> network and present each one as a separate device...

No, you definately do not want the kernel to automagically add devices 
whenever something pops up on the network, for this you need userspace to 
be in control. 1722.1 should not be handled in-kernel.


-- 
Henrik Austad


signature.asc
Description: Digital signature

Re: [PATCH] [media] v4l2-ioctl.c: fix warning due wrong check in v4l_cropcap()

[Javier Martinez Canillas]

Hello Hans,

On 06/15/2016 02:09 AM, Hans Verkuil wrote:
> On 06/14/2016 10:18 PM, Javier Martinez Canillas wrote:
>> Commit 95dd7b7e30f3 ("[media] v4l2-ioctl.c: improve cropcap compatibility
>> code") tried to check if both .vidioc_cropcap and .vidioc_g_selection are
>> NULL ops and warn if that was the case, but unfortunately the logic isn't
>> correct and instead checks for .vidioc_cropcap == NULL twice.
>>
>> So the v4l2 core will print the following warning if a driver has the ops
>> .vidioc_g_selection set but no .vidioc_cropcap callback:
> 
> This fix is already queued up for 4.7.
>

Thanks, and sorry for missing that you already had a fix queued for this.
 
> Regards,
> 
>   Hans
> 
>>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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: [very-RFC 7/8] AVB ALSA - Add ALSA shim for TSN

[Richard Cochran]

Now that I understand better...

On Sun, Jun 12, 2016 at 01:01:35AM +0200, Henrik Austad wrote:
> Userspace is supposed to reserve bandwidth, find StreamID etc.
> 
> To use as a Talker:
> 
> mkdir /config/tsn/test/eth0/talker
> cd /config/tsn/test/eth0/talker
> echo 65535 > buffer_size
> echo 08:00:27:08:9f:c3 > remote_mac
> echo 42 > stream_id
> echo alsa > enabled

This is exactly why configfs is the wrong interface.  If you implement
the AVB device in alsa-lib user space, then you can handle the
reservations, configuration, UDP sockets, etc, in a way transparent to
the aplay program.

Heck, if done properly, your layer could discover the AVB nodes in the
network and present each one as a separate device...

Thanks,
Richard


--
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: [very-RFC 0/8] TSN driver for the kernel

[Richard Cochran]

On Wed, Jun 15, 2016 at 09:04:41AM +0200, Richard Cochran wrote:
> On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote:
> > Whereas I want to do 
> > 
> > aplay some_song.wav
> 
> Can you please explain how your patches accomplish this?

Never mind.  Looking back, I found it in patch #7.

Thanks,
Richard
--
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/38] i.MX5/6 Video Capture

[Hans Verkuil]

On 06/15/16 12:43, Jack Mitchell wrote:
> On 14/06/16 23:48, Steve Longerbeam wrote:
>> Tested on imx6q SabreAuto with ADV7180, and imx6q SabreSD with
>> mipi-csi2 OV5640. There is device-tree support also for imx6qdl
>> SabreLite, but that is not tested. Also, this driver should
>> theoretically work on i.MX5 targets, but that is also untested.
> 
> I tested this on a sabrelite with ov5640 MIPI camera. I managed to capture 
> multiple images of a few different resolutions without issue. I did get a 
> kernel splat at one point though:
> 
> [  905.469680] WARNING: CPU: 3 PID: 349 at 
> drivers/media/v4l2-core/v4l2-ioctl.c:2174 v4l_cropcap+0x15c/0x190

Known bug. Fix is waiting to be merged.

Regards,

Hans

> [  905.482308] Modules linked in: dw_hdmi_ahb_audio evbug
> [  905.489079] CPU: 3 PID: 349 Comm: capture-example Tainted: GW  
>  4.7.0-rc1-00095-g921736c0-dirty #7
> [  905.502069] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [  905.510116] Backtrace:
> [  905.514066] [] (dump_backtrace) from [] 
> (show_stack+0x18/0x1c)
> [  905.523161]  r7: r6:600f0013 r5: r4:c0e21bbc
> [  905.530442] [] (show_stack) from [] 
> (dump_stack+0xb4/0xe8)
> [  905.539210] [] (dump_stack) from [] (__warn+0xd8/0x104)
> [  905.547680]  r9:c06219b0 r8:087e r7:0009 r6:c0c51b10 r5: 
> r4:
> [  905.557086] [] (__warn) from [] 
> (warn_slowpath_null+0x28/0x30)
> [  905.566172]  r9:c5e09680 r8: r7:c63c0e00 r6:c5e09680 r5:c0a7b2fc 
> r4:c6223e18
> [  905.575577] [] (warn_slowpath_null) from [] 
> (v4l_cropcap+0x15c/0x190)
> [  905.585296] [] (v4l_cropcap) from [] 
> (__video_do_ioctl+0x280/0x300)
> [  905.594824]  r8: r7:c6248000 r6:c02c563a r5:0003 r4:c0621854
> [  905.603176] [] (__video_do_ioctl) from [] 
> (video_usercopy+0x208/0x520)
> [  905.612994]  r10:c6223e18 r9:c5e09680 r8:bef3fb60 r7: r6: 
> r5:002c
> [  905.622542]  r4:c02c563a
> [  905.626692] [] (video_usercopy) from [] 
> (video_ioctl2+0x14/0x1c)
> [  905.636129]  r10: r9:c6222000 r8:c62e0088 r7:bef3fb60 r6:c02c563a 
> r5:c5e09680
> [  905.645837]  r4:c6248000
> [  905.650146] [] (video_ioctl2) from [] 
> (v4l2_ioctl+0xac/0xe8)
> [  905.659402] [] (v4l2_ioctl) from [] 
> (do_vfs_ioctl+0x9c/0xa28)
> [  905.668768]  r9:c6222000 r8:0003 r7:c022cc90 r6:c5e09680 r5:c61fcc68 
> r4:bef3fb60
> [  905.678598] [] (do_vfs_ioctl) from [] 
> (SyS_ioctl+0x3c/0x64)
> [  905.687898]  r10: r9:c6222000 r8:bef3fb60 r7:c02c563a r6:c5e09680 
> r5:0003
> [  905.697911]  r4:c5e09680
> [  905.702505] [] (SyS_ioctl) from [] 
> (ret_fast_syscall+0x0/0x1c)
> [  905.712135]  r9:c6222000 r8:c0107dc4 r7:0036 r6:000107cc r5: 
> r4:00012170
> [  905.722143] ---[ end trace 772a5fdfa424cbd1 ]---
> 
> Trying to use a user pointer rather than mmap also fails and causes a kernel 
> splat.
> 
> Apart from that and a few v4l2-compliance tests failing which you already 
> mentioned, it seems to work OK. I'll try and do some more testing and see if 
> I can come back with some more feedback.
> 
> Tested-by: Jack Mitchell 
> 
> Cheers,
> Jack.
> 
>>
>> Not run through v4l2-compliance yet, but that is in my queue.
>>
>>
>> Philipp Zabel (2):
>>   ARM: dts: imx6qdl: Add mipi_ipu1/2 video muxes, mipi_csi, and their
>> connections
>>   media: imx: Add video switch
>>
>> Steve Longerbeam (35):
>>   gpu: ipu-v3: Add Video Deinterlacer unit
>>   gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset()
>>   gpu: ipu-cpmem: Add ipu_cpmem_get_burstsize()
>>   gpu: ipu-v3: Add ipu_get_num()
>>   gpu: ipu-v3: Add IDMA channel linking support
>>   gpu: ipu-v3: Add ipu_set_vdi_src_mux()
>>   gpu: ipu-v3: Add VDI input IDMAC channels
>>   gpu: ipu-v3: Add ipu_csi_set_src()
>>   gpu: ipu-v3: Add ipu_ic_set_src()
>>   gpu: ipu-v3: set correct full sensor frame for PAL/NTSC
>>   gpu: ipu-v3: Fix CSI data format for 16-bit media bus formats
>>   gpu: ipu-v3: Fix IRT usage
>>   gpu: ipu-ic: Add complete image conversion support with tiling
>>   gpu: ipu-ic: allow multiple handles to ic
>>   gpu: ipu-v3: rename CSI client device
>>   ARM: dts: imx6qdl: Flesh out MIPI CSI2 receiver node
>>   ARM: dts: imx6-sabrelite: add video capture ports and connections
>>   ARM: dts: imx6-sabresd: add video capture ports and connections
>>   ARM: dts: imx6-sabreauto: create i2cmux for i2c3
>>   ARM: dts: imx6-sabreauto: add reset-gpios property for max7310
>>   ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
>>   ARM: dts: imx6-sabreauto: add video capture ports and connections
>>   ARM: dts: imx6qdl: add mem2mem device for sabre* boards
>>   gpio: pca953x: Add reset-gpios property
>>   clocksource/drivers/imx: add input capture support
>>   v4l: Add signal lock status to source change events
>>   media: Add camera interface driver for i.MX5/6
>>   media: imx: Add MIPI CSI-2 Receiver driver
>>   media: imx: Add support for MIPI CSI-2 OV5640
>>   media: imx: Add 

Re: [PATCH 00/38] i.MX5/6 Video Capture

[Jack Mitchell]

On 14/06/16 23:48, Steve Longerbeam wrote:

Tested on imx6q SabreAuto with ADV7180, and imx6q SabreSD with
mipi-csi2 OV5640. There is device-tree support also for imx6qdl
SabreLite, but that is not tested. Also, this driver should
theoretically work on i.MX5 targets, but that is also untested.


I tested this on a sabrelite with ov5640 MIPI camera. I managed to 
capture multiple images of a few different resolutions without issue. I 
did get a kernel splat at one point though:


[  905.469680] WARNING: CPU: 3 PID: 349 at 
drivers/media/v4l2-core/v4l2-ioctl.c:2174 v4l_cropcap+0x15c/0x190

[  905.482308] Modules linked in: dw_hdmi_ahb_audio evbug
[  905.489079] CPU: 3 PID: 349 Comm: capture-example Tainted: GW 
  4.7.0-rc1-00095-g921736c0-dirty #7

[  905.502069] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  905.510116] Backtrace:
[  905.514066] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)

[  905.523161]  r7: r6:600f0013 r5: r4:c0e21bbc
[  905.530442] [] (show_stack) from [] 
(dump_stack+0xb4/0xe8)
[  905.539210] [] (dump_stack) from [] 
(__warn+0xd8/0x104)
[  905.547680]  r9:c06219b0 r8:087e r7:0009 r6:c0c51b10 
r5: r4:
[  905.557086] [] (__warn) from [] 
(warn_slowpath_null+0x28/0x30)
[  905.566172]  r9:c5e09680 r8: r7:c63c0e00 r6:c5e09680 
r5:c0a7b2fc r4:c6223e18
[  905.575577] [] (warn_slowpath_null) from [] 
(v4l_cropcap+0x15c/0x190)
[  905.585296] [] (v4l_cropcap) from [] 
(__video_do_ioctl+0x280/0x300)

[  905.594824]  r8: r7:c6248000 r6:c02c563a r5:0003 r4:c0621854
[  905.603176] [] (__video_do_ioctl) from [] 
(video_usercopy+0x208/0x520)
[  905.612994]  r10:c6223e18 r9:c5e09680 r8:bef3fb60 r7: 
r6: r5:002c

[  905.622542]  r4:c02c563a
[  905.626692] [] (video_usercopy) from [] 
(video_ioctl2+0x14/0x1c)
[  905.636129]  r10: r9:c6222000 r8:c62e0088 r7:bef3fb60 
r6:c02c563a r5:c5e09680

[  905.645837]  r4:c6248000
[  905.650146] [] (video_ioctl2) from [] 
(v4l2_ioctl+0xac/0xe8)
[  905.659402] [] (v4l2_ioctl) from [] 
(do_vfs_ioctl+0x9c/0xa28)
[  905.668768]  r9:c6222000 r8:0003 r7:c022cc90 r6:c5e09680 
r5:c61fcc68 r4:bef3fb60
[  905.678598] [] (do_vfs_ioctl) from [] 
(SyS_ioctl+0x3c/0x64)
[  905.687898]  r10: r9:c6222000 r8:bef3fb60 r7:c02c563a 
r6:c5e09680 r5:0003

[  905.697911]  r4:c5e09680
[  905.702505] [] (SyS_ioctl) from [] 
(ret_fast_syscall+0x0/0x1c)
[  905.712135]  r9:c6222000 r8:c0107dc4 r7:0036 r6:000107cc 
r5: r4:00012170

[  905.722143] ---[ end trace 772a5fdfa424cbd1 ]---

Trying to use a user pointer rather than mmap also fails and causes a 
kernel splat.


Apart from that and a few v4l2-compliance tests failing which you 
already mentioned, it seems to work OK. I'll try and do some more 
testing and see if I can come back with some more feedback.


Tested-by: Jack Mitchell 

Cheers,
Jack.



Not run through v4l2-compliance yet, but that is in my queue.


Philipp Zabel (2):
  ARM: dts: imx6qdl: Add mipi_ipu1/2 video muxes, mipi_csi, and their
connections
  media: imx: Add video switch

Steve Longerbeam (35):
  gpu: ipu-v3: Add Video Deinterlacer unit
  gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset()
  gpu: ipu-cpmem: Add ipu_cpmem_get_burstsize()
  gpu: ipu-v3: Add ipu_get_num()
  gpu: ipu-v3: Add IDMA channel linking support
  gpu: ipu-v3: Add ipu_set_vdi_src_mux()
  gpu: ipu-v3: Add VDI input IDMAC channels
  gpu: ipu-v3: Add ipu_csi_set_src()
  gpu: ipu-v3: Add ipu_ic_set_src()
  gpu: ipu-v3: set correct full sensor frame for PAL/NTSC
  gpu: ipu-v3: Fix CSI data format for 16-bit media bus formats
  gpu: ipu-v3: Fix IRT usage
  gpu: ipu-ic: Add complete image conversion support with tiling
  gpu: ipu-ic: allow multiple handles to ic
  gpu: ipu-v3: rename CSI client device
  ARM: dts: imx6qdl: Flesh out MIPI CSI2 receiver node
  ARM: dts: imx6-sabrelite: add video capture ports and connections
  ARM: dts: imx6-sabresd: add video capture ports and connections
  ARM: dts: imx6-sabreauto: create i2cmux for i2c3
  ARM: dts: imx6-sabreauto: add reset-gpios property for max7310
  ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
  ARM: dts: imx6-sabreauto: add video capture ports and connections
  ARM: dts: imx6qdl: add mem2mem device for sabre* boards
  gpio: pca953x: Add reset-gpios property
  clocksource/drivers/imx: add input capture support
  v4l: Add signal lock status to source change events
  media: Add camera interface driver for i.MX5/6
  media: imx: Add MIPI CSI-2 Receiver driver
  media: imx: Add support for MIPI CSI-2 OV5640
  media: imx: Add support for Parallel OV5642
  media: imx: Add support for ADV7180 Video Decoder
  media: adv7180: add power pin control
  media: adv7180: implement g_parm
  media: Add i.MX5/6 mem2mem driver
  ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers

Suresh Dhandapani (1):
  gpu: ipu-v3: Fix CSI0 blur in NTSC format

 

[PATCH] v4l2-ctrl.h: fix comments

[Hans Verkuil]

The comments for the unlocked v4l2_ctrl_s_ctrl* functions were wrong (copy
and pasted from the locked variants). Fix this, since it is confusing.

Signed-off-by: Hans Verkuil 

diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 0bc9b35..e9e87e023 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -759,9 +759,9 @@ s32 v4l2_ctrl_g_ctrl(struct v4l2_ctrl *ctrl);
  * @ctrl:  The control.
  * @val:   The new value.
  *
- * This set the control's new value safely by going through the control
- * framework. This function will lock the control's handler, so it cannot be
- * used from within the _ctrl_ops functions.
+ * This sets the control's new value safely by going through the control
+ * framework. This function assumes the control's handler is already locked,
+ * allowing it to be used from within the _ctrl_ops functions.
  *
  * This function is for integer type controls only.
  */
@@ -771,7 +771,7 @@ int __v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val);
  * @ctrl:  The control.
  * @val:   The new value.
  *
- * This set the control's new value safely by going through the control
+ * This sets the control's new value safely by going through the control
  * framework. This function will lock the control's handler, so it cannot be
  * used from within the _ctrl_ops functions.
  *
@@ -807,9 +807,9 @@ s64 v4l2_ctrl_g_ctrl_int64(struct v4l2_ctrl *ctrl);
  * @ctrl:  The control.
  * @val:   The new value.
  *
- * This set the control's new value safely by going through the control
- * framework. This function will lock the control's handler, so it cannot be
- * used from within the _ctrl_ops functions.
+ * This sets the control's new value safely by going through the control
+ * framework. This function assumes the control's handler is already locked,
+ * allowing it to be used from within the _ctrl_ops functions.
  *
  * This function is for 64-bit integer type controls only.
  */
@@ -821,9 +821,9 @@ int __v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl *ctrl, s64 
val);
  * @ctrl:  The control.
  * @val:   The new value.
  *
- * This set the control's new value safely by going through the control
- * framework. This function will lock the control's handler, so it cannot be
- * used from within the _ctrl_ops functions.
+ * This sets the control's new value safely by going through the control
+ * framework. This function does not lock the control's handler, allowing it to
+ * be used from within the _ctrl_ops functions.
  *
  * This function is for 64-bit integer type controls only.
  */
@@ -843,9 +843,9 @@ static inline int v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl 
*ctrl, s64 val)
  * @ctrl:  The control.
  * @s: The new string.
  *
- * This set the control's new string safely by going through the control
- * framework. This function will lock the control's handler, so it cannot be
- * used from within the _ctrl_ops functions.
+ * This sets the control's new string safely by going through the control
+ * framework. This function assumes the control's handler is already locked,
+ * allowing it to be used from within the _ctrl_ops functions.
  *
  * This function is for string type controls only.
  */
@@ -857,7 +857,7 @@ int __v4l2_ctrl_s_ctrl_string(struct v4l2_ctrl *ctrl, const 
char *s);
  * @ctrl:  The control.
  * @s: The new string.
  *
- * This set the control's new string safely by going through the control
+ * This sets the control's new string safely by going through the control
  * framework. This function will lock the control's handler, so it cannot be
  * used from within the _ctrl_ops functions.
  *
--
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] jpeg_memsrcdest: extend feature check

[Patrick Ohly]

libjpeg.h in OpenEmbedded master (from libjpeg-turbo 1.5.0) provides
these methods if "JPEG_LIB_VERSION >= 80 ||
defined(MEM_SRCDST_SUPPORTED)".

The support for the jpeg_mem functions was added even when not
emulating the libjpeg8 API, controlled via the MEM_SRCDST_SUPPORTED
define, so checking for the version alone is not enough anymore.

See 
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/ab70623eb29e09e67222be5b9e1ea320fe5aa0e9

This fixes errors about conflicting declarations (signed vs. unsigned
char).

Signed-off-by: Patrick Ohly 
---
 lib/libv4lconvert/jpeg_memsrcdest.c | 4 ++--
 lib/libv4lconvert/jpeg_memsrcdest.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/libv4lconvert/jpeg_memsrcdest.c 
b/lib/libv4lconvert/jpeg_memsrcdest.c
index 323e7af..578c465 100644
--- a/lib/libv4lconvert/jpeg_memsrcdest.c
+++ b/lib/libv4lconvert/jpeg_memsrcdest.c
@@ -30,8 +30,8 @@
 #include "jpeg_memsrcdest.h"
 
 /* libjpeg8 and later come with their own (API compatible) memory source
-   and dest */
-#if JPEG_LIB_VERSION < 80
+   and dest, and older versions may have it backported */
+#if JPEG_LIB_VERSION < 80 && !defined(MEM_SRCDST_SUPPORTED)
 
 /* Expanded data source object for memory input */
 
diff --git a/lib/libv4lconvert/jpeg_memsrcdest.h 
b/lib/libv4lconvert/jpeg_memsrcdest.h
index 28a6477..b13bf3f 100644
--- a/lib/libv4lconvert/jpeg_memsrcdest.h
+++ b/lib/libv4lconvert/jpeg_memsrcdest.h
@@ -1,6 +1,6 @@
 #include 
 
-#if JPEG_LIB_VERSION < 80
+#if JPEG_LIB_VERSION < 80 && !defined(MEM_SRCDST_SUPPORTED)
 
 void
 jpeg_mem_src (j_decompress_ptr cinfo, unsigned char * buffer,
-- 
2.1.4

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

Re: EIT off-air tables for HD in UK

[Jemma Denson]

On 14/06/16 19:31, Nick Whitehead wrote:
I've just started to use this to recover EIT information from the 
transmitted stream (UK, freeview).


I've managed to get the tables OK, but the EIT name / description for 
all HD channels is scrambled. Some research indicates these are 
huffman encoded for an unclear reason.


Given the right tables, it should be possible therefore to decode them 
when they appear in the linked list of descriptors in each event. 
However, it appears that dvb_parse_string() called all the way down 
from dvb_read_sections() converts the character sets name / 
description strings so that they can no longer be decoded. If huffman 
encoded, I think the first character of each is a 0x1f, followed by a 
0x01 or 0x02 which probably indicates the table to use.


It seems to me therefore that the 0x1f needs to be picked up in the 
switch (*src) {} at line 395 in parse_string.c, and huffman decode 
done there. After the return from dvb_parse_string(), and certainly 
when they appear in the EIT table, it's too late.


I am not sure if I'm right about all this as I know very little about 
DVB. However it looks like that to me. Have I got this right or is 
already successfully handled somewhere I haven't realised?





FYI mythtv decodes the EIT successfully so is probably a good place to 
start looking. The original patch to add it in is here: 
https://svn.mythtv.org/trac/attachment/ticket/5365/freesat_epg.diff

AFAIK Freeview HD is done the same way as Freesat.

Jemma.


--
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: [very-RFC 0/8] TSN driver for the kernel

[Richard Cochran]

On Wed, Jun 15, 2016 at 12:15:24PM +0900, Takashi Sakamoto wrote:
> > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> >> I have seen audio PLL/multiplier chips that will take, for example, a
> >> 10 kHz input and produce your 48 kHz media clock.  With the right HW
> >> design, you can tell your PTP Hardware Clock to produce a 1 PPS,
> >> and you will have a synchronized AVB endpoint.  The software is all
> >> there already.  Somebody should tell the ALSA guys about it.
> 
> Just from my curiosity, could I ask you more explanation for it in ALSA
> side?

(Disclaimer: I really don't know too much about ALSA, expect that is
fairly big and complex ;)

Here is what I think ALSA should provide:

- The DA and AD clocks should appear as attributes of the HW device.

- There should be a method for measuring the DA/AD clock rate with
  respect to both the system time and the PTP Hardware Clock (PHC)
  time.

- There should be a method for adjusting the DA/AD clock rate if
  possible.  If not, then ALSA should fall back to sample rate
  conversion.

- There should be a method to determine the time delay from the point
  when the audio data are enqueued into ALSA until they pass through
  the D/A converter.  If this cannot be known precisely, then the
  library should provide an estimate with an error bound.

- I think some AVB use cases will need to know the time delay from A/D
  until the data are available to the local application.  (Distributed
  microphones?  I'm not too sure about that.)

- If the DA/AD clocks are connected to other clock devices in HW,
  there should be a way to find this out in SW.  For example, if SW
  can see the PTP-PHC-PLL-DA relationship from the above example, then
  it knows how to synchronize the DA clock using the network.

  [ Implementing this point involves other subsystems beyond ALSA.  It
isn't really necessary for people designing AVB systems, since
they know their designs, but it would be nice to have for writing
generic applications that can deal with any kind of HW setup. ]

> In ALSA, sampling rate conversion should be in userspace, not in kernel
> land. In alsa-lib, sampling rate conversion is implemented in shared object.
> When userspace applications start playbacking/capturing, depending on PCM
> node to access, these applications load the shared object and convert PCM
> frames from buffer in userspace to mmapped DMA-buffer, then commit them.

The AVB use case places an additional requirement on the rate
conversion.  You will need to adjust the frequency on the fly, as the
stream is playing.  I would guess that ALSA doesn't have that option?

Thanks,
Richard
--
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: [very-RFC 0/8] TSN driver for the kernel

[Henrik Austad]

On Wed, Jun 15, 2016 at 09:04:41AM +0200, Richard Cochran wrote:
> On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote:
> > Whereas I want to do 
> > 
> > aplay some_song.wav
> 
> Can you please explain how your patches accomplish this?

In short:

modprobe tsn
modprobe avb_alsa
mkdir /sys/kernel/config/eth0/link
cd /sys/kernel/config/eth0/link

echo alsa > enabled
aplay -Ddefault:CARD=avb some_song.wav

Likewise on the receiver side, except add 'Listener' to end_station 
attribute

arecord -c2 -r48000 -f S16_LE -Ddefault:CARD=avb > some_recording.wav

I've not had time to fully fix the hw-aprams for alsa, so some manual 
tweaking of arecord is required.


Again, this is a very early attempt to get something useful done with TSN, 
I know there are rough edges, I know buffer handling and timestamping is 
not finished


Note: if you don't have an intel-card, load tsn in debug-mode and it will 
let you use all NICs present.

modprobe tsn in_debug=1


-- 
Henrik Austad


signature.asc
Description: Digital signature

Re: [very-RFC 0/8] TSN driver for the kernel

[Richard Cochran]

On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote:
> Where is your media-application in this?

Um, that *is* a media application.  It plays music on the sound card.

> You only loop the audio from 
> network to the dsp, is the media-application attached to the dsp-device?

Sorry, I thought the old OSS API would be familiar and easy to
understand.  The /dev/dsp is the sound card.

Thanks,
Richard
--
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: [very-RFC 0/8] TSN driver for the kernel

[Richard Cochran]

On Tue, Jun 14, 2016 at 10:38:10PM +0200, Henrik Austad wrote:
> Whereas I want to do 
> 
> aplay some_song.wav

Can you please explain how your patches accomplish this?

Thanks,
Richard
--
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 12/12] leds: Only descend into leds directory when CONFIG_NEW_LEDS is set

[Jacek Anaszewski]

Hi Andrew,

Thanks for the patch.

Please address the issue [1] raised by test bot and resubmit.

Thanks,
Jacek Anaszewski

[1] https://lkml.org/lkml/2016/6/13/1091

On 06/13/2016 10:02 PM, Andrew F. Davis wrote:

When CONFIG_NEW_LEDS is not set make will still descend into the leds
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.

Signed-off-by: Andrew F. Davis 
---
  drivers/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 567e32c..fa514d5 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -127,7 +127,7 @@ obj-$(CONFIG_CPU_FREQ)  += cpufreq/
  obj-$(CONFIG_CPU_IDLE)+= cpuidle/
  obj-$(CONFIG_MMC) += mmc/
  obj-$(CONFIG_MEMSTICK)+= memstick/
-obj-y  += leds/
+obj-$(CONFIG_NEW_LEDS) += leds/
  obj-$(CONFIG_INFINIBAND)  += infiniband/
  obj-$(CONFIG_SGI_SN)  += sn/
  obj-y += firmware/




--
Best regards,
Jacek Anaszewski
--
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] v4l2-ioctl.c: fix warning due wrong check in v4l_cropcap()

[Hans Verkuil]

On 06/14/2016 10:18 PM, Javier Martinez Canillas wrote:
> Commit 95dd7b7e30f3 ("[media] v4l2-ioctl.c: improve cropcap compatibility
> code") tried to check if both .vidioc_cropcap and .vidioc_g_selection are
> NULL ops and warn if that was the case, but unfortunately the logic isn't
> correct and instead checks for .vidioc_cropcap == NULL twice.
> 
> So the v4l2 core will print the following warning if a driver has the ops
> .vidioc_g_selection set but no .vidioc_cropcap callback:

This fix is already queued up for 4.7.

Regards,

Hans

> 
> WARNING: CPU: 2 PID: 4058 at drivers/media/v4l2-core/v4l2-ioctl.c:2174 
> v4l_cropcap+0x188/0x198 [videodev]
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x88/0x9c)
> [] (dump_stack) from [] (__warn+0xe8/0x100)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] (v4l_cropcap+0x188/0x198 
> [videodev])
> [] (v4l_cropcap [videodev]) from [] 
> (__video_do_ioctl+0x298/0x30c [videodev])
> [] (__video_do_ioctl [videodev]) from [] 
> (video_usercopy+0x174/0x4e8 [videodev])
> [] (video_usercopy [videodev]) from [] 
> (v4l2_ioctl+0xc4/0xd8 [videodev])
> [] (v4l2_ioctl [videodev]) from [] 
> (do_vfs_ioctl+0x9c/0x8e4)
> [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c)
> [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c)
> 
> Fixes: 95dd7b7e30f3 ("[media] v4l2-ioctl.c: improve cropcap compatibility 
> code")
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 28e5be2c2eef..528390f33b53 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -2171,7 +2171,7 @@ static int v4l_cropcap(const struct v4l2_ioctl_ops *ops,
>* The determine_valid_ioctls() call already should ensure
>* that this can never happen, but just in case...
>*/
> - if (WARN_ON(!ops->vidioc_cropcap && !ops->vidioc_cropcap))
> + if (WARN_ON(!ops->vidioc_cropcap && !ops->vidioc_g_selection))
>   return -ENOTTY;
>  
>   if (ops->vidioc_cropcap)
> 
--
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