cron job: media_tree daily build: ERRORS

[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 Dec 10 05:00:18 CET 2016
media-tree git hash:365fe4e0ce218dc5ad10df17b150a366b6015499
media_build git hash:   1606032398b1d79149c1507be2029e1a00d8dff0
v4l-utils git hash: 188e604d57bec065078ff772c802b93ddb6def4b
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: 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: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-rc5-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: OK
linux-3.12.67-x86_64: OK
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: OK
linux-4.9-rc5-x86_64: OK
apps: WARNINGS
spec-git: OK
smatch: ERRORS
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/index.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

cx231xx: how to disable V4L2 interface?

[Petri Gynther]

Hi linux-media:

For drivers/media/usb/cx231xx, I'd like to add a kernel config option:
CONFIG_VIDEO_CX231XX_V4L2

that allows us to disable the V4L2 interface when only the DVB
interface is needed.

au0828 driver handles this cleanly:
drivers/media/usb/au0828/Makefile
ifeq ($(CONFIG_VIDEO_AU0828_V4L2),y)
  au0828-objs   += au0828-video.o au0828-vbi.o
endif

Trying to do the same in cx231xx driver:
diff --git a/drivers/media/usb/cx231xx/Kconfig
b/drivers/media/usb/cx231xx/Kconfig
index 0cced3e..63d63aa 100644
--- a/drivers/media/usb/cx231xx/Kconfig
+++ b/drivers/media/usb/cx231xx/Kconfig
@@ -39,6 +39,13 @@ config VIDEO_CX231XX_ALSA
  To compile this driver as a module, choose M here: the
  module will be called cx231xx-alsa

+config VIDEO_CX231XX_V4L2
+   bool "Conexant cx231xx V4L2 interface"
+   depends on VIDEO_CX231XX
+   default y
+   ---help---
+ Enable or disable V4L2 interface of cx231xx
+
 config VIDEO_CX231XX_DVB
tristate "DVB/ATSC Support for Cx231xx based TV cards"
depends on VIDEO_CX231XX && DVB_CORE

diff --git a/drivers/media/usb/cx231xx/Makefile
b/drivers/media/usb/cx231xx/Makefile
index 52cf769..425d899 100644
--- a/drivers/media/usb/cx231xx/Makefile
+++ b/drivers/media/usb/cx231xx/Makefile
@@ -1,5 +1,6 @@
-cx231xx-y += cx231xx-video.o cx231xx-i2c.o cx231xx-cards.o cx231xx-core.o
-cx231xx-y += cx231xx-avcore.o cx231xx-417.o cx231xx-pcb-cfg.o cx231xx-vbi.o
+cx231xx-y += cx231xx-i2c.o cx231xx-cards.o cx231xx-core.o
+cx231xx-y += cx231xx-avcore.o cx231xx-417.o cx231xx-pcb-cfg.o
+cx231xx-$(CONFIG_VIDEO_CX231XX_V4L2) += cx231xx-video.o cx231xx-vbi.o
 cx231xx-$(CONFIG_VIDEO_CX231XX_RC) += cx231xx-input.o

 cx231xx-alsa-objs := cx231xx-audio.o

and then building with VIDEO_CX231XX_V4L2 unset, the result is:

drivers/built-in.o: In function `cx231xx_release_resources':
(.text+0x3528c9): undefined reference to `cx231xx_release_analog_resources'
drivers/built-in.o: In function `cx231xx_usb_probe':
cx231xx-cards.c:(.text+0x352f56): undefined reference to
`cx231xx_register_analog_devices'
cx231xx-cards.c:(.text+0x352f71): undefined reference to
`cx231xx_release_analog_resources'
cx231xx-cards.c:(.text+0x353429): undefined reference to
`cx231xx_release_analog_resources'
drivers/built-in.o: In function `cx231xx_init_bulk':
(.text+0x3544d8): undefined reference to `video_mux'
drivers/built-in.o:(.rodata+0x7fcc0): undefined reference to `cx231xx_querycap'
drivers/built-in.o:(.rodata+0x7fe98): undefined reference to
`cx231xx_enum_input'
drivers/built-in.o:(.rodata+0x7fea0): undefined reference to `cx231xx_g_input'
drivers/built-in.o:(.rodata+0x7fea8): undefined reference to `cx231xx_s_input'
drivers/built-in.o:(.rodata+0x7ffb8): undefined reference to `cx231xx_g_tuner'
drivers/built-in.o:(.rodata+0x7ffc0): undefined reference to `cx231xx_s_tuner'
drivers/built-in.o:(.rodata+0x7ffc8): undefined reference to
`cx231xx_g_frequency'
drivers/built-in.o:(.rodata+0x7ffd0): undefined reference to
`cx231xx_s_frequency'
make: *** [vmlinux] Error 1

Based on the above, looks like some functions would need to be moved
out from cx231xx-video.c to cx231xx-core.c (?) to accomplish this.

Any suggestions?

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

Re: [PATCH 2/4] si2168: Si2168-D60 support.

[Antti Palosaari]

On 12/09/2016 02:17 AM, CrazyCat wrote:

Support for new demod version.

Signed-off-by: CrazyCat 


Patch is correct. Could you still use your real name?

regards
Antti


---
 drivers/media/dvb-frontends/si2168.c  | 4 
 drivers/media/dvb-frontends/si2168_priv.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 20b4a65..28f3bbe 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -674,6 +674,9 @@ static int si2168_probe(struct i2c_client *client,
case SI2168_CHIP_ID_B40:
dev->firmware_name = SI2168_B40_FIRMWARE;
break;
+   case SI2168_CHIP_ID_D60:
+   dev->firmware_name = SI2168_D60_FIRMWARE;
+   break;
default:
dev_dbg(>dev, "unknown chip version Si21%d-%c%c%c\n",
cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
@@ -761,3 +764,4 @@ static int si2168_remove(struct i2c_client *client)
 MODULE_FIRMWARE(SI2168_A20_FIRMWARE);
 MODULE_FIRMWARE(SI2168_A30_FIRMWARE);
 MODULE_FIRMWARE(SI2168_B40_FIRMWARE);
+MODULE_FIRMWARE(SI2168_D60_FIRMWARE);
diff --git a/drivers/media/dvb-frontends/si2168_priv.h 
b/drivers/media/dvb-frontends/si2168_priv.h
index 7843ccb..4baa95b 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -25,6 +25,7 @@
 #define SI2168_A20_FIRMWARE "dvb-demod-si2168-a20-01.fw"
 #define SI2168_A30_FIRMWARE "dvb-demod-si2168-a30-01.fw"
 #define SI2168_B40_FIRMWARE "dvb-demod-si2168-b40-01.fw"
+#define SI2168_D60_FIRMWARE "dvb-demod-si2168-d60-01.fw"
 #define SI2168_B40_FIRMWARE_FALLBACK "dvb-demod-si2168-02.fw"

 /* state struct */
@@ -37,6 +38,7 @@ struct si2168_dev {
#define SI2168_CHIP_ID_A20 ('A' << 24 | 68 << 16 | '2' << 8 | '0' << 0)
#define SI2168_CHIP_ID_A30 ('A' << 24 | 68 << 16 | '3' << 8 | '0' << 0)
#define SI2168_CHIP_ID_B40 ('B' << 24 | 68 << 16 | '4' << 8 | '0' << 0)
+   #define SI2168_CHIP_ID_D60 ('D' << 24 | 68 << 16 | '6' << 8 | '0' << 0)
unsigned int chip_id;
unsigned int version;
const char *firmware_name;



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

Omap3-isp isp_remove() access subdev.entity after media_device_cleanup()

[Shuah Khan]

Hi Sakari,

I am looking at omap3 isp_remove() closely and I think there are a few
issues there that could cause problems during unbind.

isp_remove() tries to do media_entity_cleanup() after it unregisters
media_device

isp_remove() calls isp_unregister_entities() followed by
isp_cleanup_modules() - cleanup routines call media_entity_cleanup()

media_entity_cleanup() accesses csi2a->subdev.entity which should be gone
by now after media_device_unregister(). This is just one example. I think
all of these cleanup routines isp_cleanup_modules() call access subdev.entity.

static void isp_cleanup_modules(struct isp_device *isp)
{
omap3isp_h3a_aewb_cleanup(isp);
omap3isp_h3a_af_cleanup(isp);
omap3isp_hist_cleanup(isp);
omap3isp_resizer_cleanup(isp);
omap3isp_preview_cleanup(isp);
omap3isp_ccdc_cleanup(isp);
omap3isp_ccp2_cleanup(isp);
omap3isp_csi2_cleanup(isp);
}

This is all done after media_device_cleanup() which does
ida_destroy(>entity_internal_idx); and mutex_destroy(>graph_mutex);

I think there are some paths during unbind - isp_remove() that are unsafe.
I am trying to build https://github.com/gumstix/linux/tree/master now and
if I can get it to boot - I can send you some logs.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.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

[PATCH v2 6/7] [media] coda: use VDOA for un-tiling custom macroblock format

[Michael Tretter]

If the CODA driver is configured to produce NV12 output and the VDOA is
available, the VDOA can be used to transform the custom macroblock tiled
format to a raster-ordered format for scanout.

In this case, set the output format of the CODA to the custom macroblock
tiled format, disable the rotator, and use the VDOA to write to the v4l2
buffer. The VDOA is synchronized with the CODA to always un-tile the
frame that the CODA finished in the previous run.

Signed-off-by: Michael Tretter 
---
 drivers/media/platform/coda/coda-bit.c|  86 +
 drivers/media/platform/coda/coda-common.c | 102 --
 drivers/media/platform/coda/coda.h|   3 +
 3 files changed, 161 insertions(+), 30 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index 309eb4e..f608de4 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -30,6 +30,7 @@
 #include 
 
 #include "coda.h"
+#include "imx-vdoa.h"
 #define CREATE_TRACE_POINTS
 #include "trace.h"
 
@@ -1517,6 +1518,10 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
u32 val;
int ret;
 
+   v4l2_dbg(1, coda_debug, >v4l2_dev,
+"Video Data Order Adapter: %s\n",
+ctx->use_vdoa ? "Enabled" : "Disabled");
+
/* Start decoding */
q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
@@ -1535,7 +1540,8 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
if (dst_fourcc == V4L2_PIX_FMT_NV12)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
-   ctx->frame_mem_ctrl |= (0x3 << 9) | CODA9_FRAME_TILED2LINEAR;
+   ctx->frame_mem_ctrl |= (0x3 << 9) |
+   ((ctx->use_vdoa) ? 0 : CODA9_FRAME_TILED2LINEAR);
coda_write(dev, ctx->frame_mem_ctrl, CODA_REG_BIT_FRAME_MEM_CTRL);
 
ctx->display_idx = -1;
@@ -1618,6 +1624,15 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
 __func__, ctx->idx, width, height);
 
ctx->num_internal_frames = coda_read(dev, CODA_RET_DEC_SEQ_FRAME_NEED);
+   /*
+* If the VDOA is used, the decoder needs one additional frame,
+* because the frames are freed when the next frame is decoded.
+* Otherwise there are visible errors in the decoded frames (green
+* regions in displayed frames) and a broken order of frames (earlier
+* frames are sporadically displayed after later frames).
+*/
+   if (ctx->use_vdoa)
+   ctx->num_internal_frames += 1;
if (ctx->num_internal_frames > CODA_MAX_FRAMEBUFFERS) {
v4l2_err(>v4l2_dev,
 "not enough framebuffers to decode (%d < %d)\n",
@@ -1724,6 +1739,7 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
struct coda_q_data *q_data_dst;
struct coda_buffer_meta *meta;
unsigned long flags;
+   u32 rot_mode = 0;
u32 reg_addr, reg_stride;
 
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
@@ -1759,27 +1775,40 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
if (dev->devtype->product == CODA_960)
coda_set_gdi_regs(ctx);
 
-   if (dev->devtype->product == CODA_960) {
-   /*
-* The CODA960 seems to have an internal list of buffers with
-* 64 entries that includes the registered frame buffers as
-* well as the rotator buffer output.
-* ROT_INDEX needs to be < 0x40, but > ctx->num_internal_frames.
-*/
-   coda_write(dev, CODA_MAX_FRAMEBUFFERS + dst_buf->vb2_buf.index,
-   CODA9_CMD_DEC_PIC_ROT_INDEX);
-
-   reg_addr = CODA9_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA9_CMD_DEC_PIC_ROT_STRIDE;
+   if (ctx->use_vdoa &&
+   ctx->display_idx >= 0 &&
+   ctx->display_idx < ctx->num_internal_frames) {
+   vdoa_device_run(ctx->vdoa,
+   
vb2_dma_contig_plane_dma_addr(_buf->vb2_buf, 0),
+   ctx->internal_frames[ctx->display_idx].paddr);
} else {
-   reg_addr = CODA_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA_CMD_DEC_PIC_ROT_STRIDE;
+   if (dev->devtype->product == CODA_960) {
+   /*
+* The CODA960 seems to have an internal list of
+* buffers with 64 entries that includes the
+* registered frame buffers as well as the rotator
+* buffer output.
+*
+* ROT_INDEX needs to be < 0x40, but >
+* 

[PATCH v2 3/7] [media] coda: correctly set capture compose rectangle

[Michael Tretter]

From: Philipp Zabel 

Correctly store the rectangle of valid video data in the destination
q_data before rounding up to macroblock size. This fixes the output
of VIDIOC_G_SELECTION for the capture side compose rectangle.

Signed-off-by: Philipp Zabel 
Signed-off-by: Michael Tretter 
---
 drivers/media/platform/coda/coda-common.c | 37 ---
 1 file changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index c39718a..e0184194 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -566,7 +566,8 @@ static int coda_try_fmt_vid_out(struct file *file, void 
*priv,
return coda_try_fmt(ctx, codec, f);
 }
 
-static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
+static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f,
+ struct v4l2_rect *r)
 {
struct coda_q_data *q_data;
struct vb2_queue *vq;
@@ -589,10 +590,14 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f)
q_data->height = f->fmt.pix.height;
q_data->bytesperline = f->fmt.pix.bytesperline;
q_data->sizeimage = f->fmt.pix.sizeimage;
-   q_data->rect.left = 0;
-   q_data->rect.top = 0;
-   q_data->rect.width = f->fmt.pix.width;
-   q_data->rect.height = f->fmt.pix.height;
+   if (r) {
+   q_data->rect = *r;
+   } else {
+   q_data->rect.left = 0;
+   q_data->rect.top = 0;
+   q_data->rect.width = f->fmt.pix.width;
+   q_data->rect.height = f->fmt.pix.height;
+   }
 
switch (f->fmt.pix.pixelformat) {
case V4L2_PIX_FMT_NV12:
@@ -621,27 +626,37 @@ static int coda_s_fmt_vid_cap(struct file *file, void 
*priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_cap(file, priv, f);
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, f);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, f, );
 }
 
 static int coda_s_fmt_vid_out(struct file *file, void *priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
struct v4l2_format f_cap;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_out(file, priv, f);
if (ret)
return ret;
 
-   ret = coda_s_fmt(ctx, f);
+   ret = coda_s_fmt(ctx, f, NULL);
if (ret)
return ret;
 
@@ -657,7 +672,13 @@ static int coda_s_fmt_vid_out(struct file *file, void 
*priv,
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, _cap);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, _cap, );
 }
 
 static int coda_reqbufs(struct file *file, void *priv,
-- 
2.10.2

--
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 v2 5/7] [media] coda: fix frame index to returned error

[Michael Tretter]

display_idx refers to the frame that will be returned in the next round.
The currently processed frame is ctx->display_idx and errors should be
reported for this frame.

Signed-off-by: Michael Tretter 
Acked-by: Philipp Zabel 
---
 drivers/media/platform/coda/coda-bit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index b662504..309eb4e 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2057,7 +2057,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
}
vb2_set_plane_payload(_buf->vb2_buf, 0, payload);
 
-   coda_m2m_buf_done(ctx, dst_buf, ctx->frame_errors[display_idx] ?
+   coda_m2m_buf_done(ctx, dst_buf, 
ctx->frame_errors[ctx->display_idx] ?
  VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
 
v4l2_dbg(1, coda_debug, >v4l2_dev,
-- 
2.10.2

--
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 v2 7/7] [media] coda: support YUYV output if VDOA is used

[Michael Tretter]

The VDOA is able to transform the NV12 custom macroblock tiled format of
the CODA to YUYV format. If and only if the VDOA is available, the
driver can also provide YUYV support.

While the driver is configured to produce YUYV output, the CODA must be
configured to produce NV12 macroblock tiled frames and the VDOA must
transform the intermediate result into the final YUYV output.

Signed-off-by: Michael Tretter 
Reviewed-by: Philipp Zabel 
---
 drivers/media/platform/coda/coda-bit.c|  7 +--
 drivers/media/platform/coda/coda-common.c | 30 ++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index f608de4..466a44e 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -759,7 +759,7 @@ static void coda9_set_frame_cache(struct coda_ctx *ctx, u32 
fourcc)
cache_config = 1 << CODA9_CACHE_PAGEMERGE_OFFSET;
}
coda_write(ctx->dev, cache_size, CODA9_CMD_SET_FRAME_CACHE_SIZE);
-   if (fourcc == V4L2_PIX_FMT_NV12) {
+   if (fourcc == V4L2_PIX_FMT_NV12 || fourcc == V4L2_PIX_FMT_YUYV) {
cache_config |= 32 << CODA9_CACHE_LUMA_BUFFER_SIZE_OFFSET |
16 << CODA9_CACHE_CR_BUFFER_SIZE_OFFSET |
0 << CODA9_CACHE_CB_BUFFER_SIZE_OFFSET;
@@ -1537,7 +1537,7 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
 
ctx->frame_mem_ctrl &= ~(CODA_FRAME_CHROMA_INTERLEAVE | (0x3 << 9) |
 CODA9_FRAME_TILED2LINEAR);
-   if (dst_fourcc == V4L2_PIX_FMT_NV12)
+   if (dst_fourcc == V4L2_PIX_FMT_NV12 || dst_fourcc == V4L2_PIX_FMT_YUYV)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
ctx->frame_mem_ctrl |= (0x3 << 9) |
@@ -2079,6 +2079,9 @@ static void coda_finish_decode(struct coda_ctx *ctx)
trace_coda_dec_rot_done(ctx, dst_buf, meta);
 
switch (q_data_dst->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   payload = width * height * 2;
+   break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_NV12:
diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index c09cafd..43af428 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -95,6 +95,8 @@ void coda_write_base(struct coda_ctx *ctx, struct coda_q_data 
*q_data,
u32 base_cb, base_cr;
 
switch (q_data->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   /* Fallthrough: IN -H264-> CODA -NV12 MB-> VDOA -YUYV-> OUT */
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_YUV420:
default:
@@ -201,6 +203,11 @@ static const struct coda_video_device coda_bit_decoder = {
V4L2_PIX_FMT_NV12,
V4L2_PIX_FMT_YUV420,
V4L2_PIX_FMT_YVU420,
+   /*
+* If V4L2_PIX_FMT_YUYV should be default,
+* set_default_params() must be adjusted.
+*/
+   V4L2_PIX_FMT_YUYV,
},
 };
 
@@ -246,6 +253,7 @@ static u32 coda_format_normalize_yuv(u32 fourcc)
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_YUV422P:
+   case V4L2_PIX_FMT_YUYV:
return V4L2_PIX_FMT_YUV420;
default:
return fourcc;
@@ -434,6 +442,11 @@ static int coda_try_pixelformat(struct coda_ctx *ctx, 
struct v4l2_format *f)
return -EINVAL;
 
for (i = 0; i < CODA_MAX_FORMATS; i++) {
+   /* Skip YUYV if the vdoa is not available */
+   if (!ctx->vdoa && f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE &&
+   formats[i] == V4L2_PIX_FMT_YUYV)
+   continue;
+
if (formats[i] == f->fmt.pix.pixelformat) {
f->fmt.pix.pixelformat = formats[i];
return 0;
@@ -520,6 +533,11 @@ static int coda_try_fmt(struct coda_ctx *ctx, const struct 
coda_codec *codec,
f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
f->fmt.pix.height * 3 / 2;
break;
+   case V4L2_PIX_FMT_YUYV:
+   f->fmt.pix.bytesperline = round_up(f->fmt.pix.width, 16) * 2;
+   f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
+   f->fmt.pix.height;
+   break;
case V4L2_PIX_FMT_YUV422P:
f->fmt.pix.bytesperline = round_up(f->fmt.pix.width, 16);
f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
@@ -593,6 +611,15 @@ static int 

[PATCH v2 4/7] [media] coda: add debug output about tiling

[Michael Tretter]

From: Philipp Zabel 

In order to make the VDOA work correctly, the CODA must produce frames
in tiled format. Print this information in the debug output.

Also print the color format in fourcc instead of the numeric value.

Signed-off-by: Philipp Zabel 
Signed-off-by: Michael Tretter 
---
 drivers/media/platform/coda/coda-common.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index e0184194..f739873 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -616,8 +616,10 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f,
}
 
v4l2_dbg(1, coda_debug, >dev->v4l2_dev,
-   "Setting format for type %d, wxh: %dx%d, fmt: %d\n",
-   f->type, q_data->width, q_data->height, q_data->fourcc);
+   "Setting format for type %d, wxh: %dx%d, fmt: %4.4s %c\n",
+   f->type, q_data->width, q_data->height,
+   (char *)_data->fourcc,
+   (ctx->tiled_map_type == GDI_LINEAR_FRAME_MAP) ? 'L' : 'T');
 
return 0;
 }
-- 
2.10.2

--
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 v2 2/7] [media] coda: add i.MX6 VDOA driver

[Michael Tretter]

From: Philipp Zabel 

The i.MX6 Video Data Order Adapter's (VDOA) sole purpose is to convert
from a custom macroblock tiled format produced by the CODA960 decoder
into linear formats that can be used for scanout.

Signed-off-by: Philipp Zabel 
Signed-off-by: Michael Tretter 
---
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/coda/Makefile   |   1 +
 drivers/media/platform/coda/imx-vdoa.c | 335 +
 drivers/media/platform/coda/imx-vdoa.h |  58 ++
 4 files changed, 397 insertions(+)
 create mode 100644 drivers/media/platform/coda/imx-vdoa.c
 create mode 100644 drivers/media/platform/coda/imx-vdoa.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ce4a96f..41e007f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,9 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_IMX_VDOA
+   def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/coda/Makefile 
b/drivers/media/platform/coda/Makefile
index 9342ac5..8582843 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)
 coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-jpeg.o
 
 obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_IMX_VDOA) += imx-vdoa.o
diff --git a/drivers/media/platform/coda/imx-vdoa.c 
b/drivers/media/platform/coda/imx-vdoa.c
new file mode 100644
index 000..36ceffb
--- /dev/null
+++ b/drivers/media/platform/coda/imx-vdoa.c
@@ -0,0 +1,335 @@
+/*
+ * i.MX6 Video Data Order Adapter (VDOA)
+ *
+ * Copyright (C) 2014 Philipp Zabel
+ *
+ * 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 "imx-vdoa.h"
+
+#define VDOA_NAME "imx-vdoa"
+
+#define VDOAC  0x00
+#define VDOASRR0x04
+#define VDOAIE 0x08
+#define VDOAIST0x0c
+#define VDOAFP 0x10
+#define VDOAIEBA00 0x14
+#define VDOAIEBA01 0x18
+#define VDOAIEBA02 0x1c
+#define VDOAIEBA10 0x20
+#define VDOAIEBA11 0x24
+#define VDOAIEBA12 0x28
+#define VDOASL 0x2c
+#define VDOAIUBO   0x30
+#define VDOAVEBA0  0x34
+#define VDOAVEBA1  0x38
+#define VDOAVEBA2  0x3c
+#define VDOAVUBO   0x40
+#define VDOASR 0x44
+
+#define VDOAC_ISEL BIT(6)
+#define VDOAC_PFS  BIT(5)
+#define VDOAC_SO   BIT(4)
+#define VDOAC_SYNC BIT(3)
+#define VDOAC_NF   BIT(2)
+#define VDOAC_BNDM_MASK0x3
+#define VDOAC_BAND_HEIGHT_80x0
+#define VDOAC_BAND_HEIGHT_16   0x1
+#define VDOAC_BAND_HEIGHT_32   0x2
+
+#define VDOASRR_START  BIT(1)
+#define VDOASRR_SWRST  BIT(0)
+
+#define VDOAIE_EITERR  BIT(1)
+#define VDOAIE_EIEOT   BIT(0)
+
+#define VDOAIST_TERR   BIT(1)
+#define VDOAIST_EOTBIT(0)
+
+#define VDOAFP_FH_MASK (0x1fff << 16)
+#define VDOAFP_FW_MASK (0x3fff)
+
+#define VDOASL_VSLY_MASK   (0x3fff << 16)
+#define VDOASL_ISLY_MASK   (0x7fff)
+
+#define VDOASR_ERRWBIT(4)
+#define VDOASR_EOB BIT(3)
+#define VDOASR_CURRENT_FRAME   (0x3 << 1)
+#define VDOASR_CURRENT_BUFFER  BIT(1)
+
+enum {
+   V4L2_M2M_SRC = 0,
+   V4L2_M2M_DST = 1,
+};
+
+struct vdoa_data {
+   struct vdoa_ctx *curr_ctx;
+   struct device   *dev;
+   struct clk  *vdoa_clk;
+   void __iomem*regs;
+   int irq;
+};
+
+struct vdoa_q_data {
+   unsigned intwidth;
+   unsigned intheight;
+   unsigned intbytesperline;
+   unsigned intsizeimage;
+   u32 pixelformat;
+};
+
+struct vdoa_ctx {
+   struct vdoa_data*vdoa;
+   struct completion   completion;
+   struct vdoa_q_data  q_data[2];
+};
+
+static irqreturn_t vdoa_irq_handler(int irq, void *data)
+{
+   struct vdoa_data *vdoa = data;
+   struct vdoa_ctx *curr_ctx;
+   u32 val;
+
+   /* Disable interrupts */
+   writel(0, vdoa->regs + VDOAIE);
+

[PATCH v2 1/7] ARM: dts: imx6qdl: Add VDOA compatible and clocks properties

[Michael Tretter]

From: Philipp Zabel 

This adds a compatible property and the correct clock for the
i.MX6Q Video Data Order Adapter.

Signed-off-by: Philipp Zabel 
Signed-off-by: Michael Tretter 
---
 .../devicetree/bindings/media/fsl-vdoa.txt  | 21 +
 arch/arm/boot/dts/imx6qdl.dtsi  |  2 ++
 2 files changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt

diff --git a/Documentation/devicetree/bindings/media/fsl-vdoa.txt 
b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
new file mode 100644
index 000..5e45f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
@@ -0,0 +1,21 @@
+Freescale Video Data Order Adapter
+==
+
+The Video Data Order Adapter (VDOA) is present on the i.MX6q. Its sole purpose
+it to to reorder video data from the macroblock tiled order produced by the
+CODA 960 VPU to the conventional raster-scan order for scanout.
+
+Required properties:
+- compatible: must be "fsl,imx6q-vdoa"
+- reg: the register base and size for the device registers
+- interrupts: the VDOA interrupt
+- clocks: the vdoa clock
+
+Example:
+
+vdoa@021e4000 {
+compatible = "fsl,imx6q-vdoa";
+reg = <0x021e4000 0x4000>;
+interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+clocks = < IMX6QDL_CLK_VDOA>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b13b0b2..69e3668 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1153,8 +1153,10 @@
};
 
vdoa@021e4000 {
+   compatible = "fsl,imx6q-vdoa";
reg = <0x021e4000 0x4000>;
interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < IMX6QDL_CLK_VDOA>;
};
 
uart2: serial@021e8000 {
-- 
2.10.2

--
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 v2 0/7] Add support for Video Data Order Adapter

[Michael Tretter]

Hello,

This is v2 of a patch series that adds support for the Video Data Order
Adapter (VDOA) that can be found on Freescale i.MX6. It converts the
macroblock tiled format produced by the CODA 960 video decoder to a
raster-ordered format for scanout.

Changes since v1:

- Dropped patch 8/9 of v1
- Patch 1/7: Add devicetree binding documentation for fsl-vdoa
- Patch 6/7: I merged patch 5/9 and patch 8/9 of v1 into a single patch
- Patch 6/7: Use dt compatible instead of a phandle to find VDOA device
- Patch 6/7: Always check VDOA availability even if disabled via module
  parameter and do not print a message if VDOA cannot be found
- Patch 6/7: Do not change the CODA context in coda_try_fmt()
- Patch 6/7: Allocate an additional internal frame if the VDOA is in use

Michael


Michael Tretter (3):
  [media] coda: fix frame index to returned error
  [media] coda: use VDOA for un-tiling custom macroblock format
  [media] coda: support YUYV output if VDOA is used

Philipp Zabel (4):
  ARM: dts: imx6qdl: Add VDOA compatible and clocks properties
  [media] coda: add i.MX6 VDOA driver
  [media] coda: correctly set capture compose rectangle
  [media] coda: add debug output about tiling

 .../devicetree/bindings/media/fsl-vdoa.txt |  21 ++
 arch/arm/boot/dts/imx6qdl.dtsi |   2 +
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/coda/Makefile   |   1 +
 drivers/media/platform/coda/coda-bit.c |  93 --
 drivers/media/platform/coda/coda-common.c  | 175 ++-
 drivers/media/platform/coda/coda.h |   3 +
 drivers/media/platform/coda/imx-vdoa.c | 335 +
 drivers/media/platform/coda/imx-vdoa.h |  58 
 9 files changed, 649 insertions(+), 42 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt
 create mode 100644 drivers/media/platform/coda/imx-vdoa.c
 create mode 100644 drivers/media/platform/coda/imx-vdoa.h

-- 
2.10.2

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

exposure controlled by v4l2-ctl

[Nandor Balogh]

Hi,

I would like to talk to someone who knows how auto-exposure and exposure
algorithms work which controlled by v4l2-ctl command.

Or maybe source code of these would also help, I may understand it by
reading the code, though I am not an expert.

Thanks,

Nandor

--
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 v6 3/3] sound/usb: Use Media Controller API to share media resources

[Shuah Khan]

On 12/09/2016 06:17 AM, Sakari Ailus wrote:
> Hi Shuah,
> 
> On Fri, Dec 09, 2016 at 01:44:07AM +0200, Sakari Ailus wrote:
>> Hi Shuah,
>>
>> On Thu, Dec 08, 2016 at 07:46:03AM -0700, Shuah Khan wrote:
>>> Hi Sakari,
>>>
>>> On 12/07/2016 03:27 PM, Sakari Ailus wrote:
 Hi Shuah,

 On Wed, Dec 07, 2016 at 01:03:59PM -0700, Shuah Khan wrote:
> Hi Sakari,
>
> On 12/07/2016 03:52 AM, Sakari Ailus wrote:
>> Hi Shuah,
>>
>> On Mon, Dec 05, 2016 at 05:38:23PM -0700, Shuah Khan wrote:
>>> On 12/05/2016 04:21 PM, Laurent Pinchart wrote:
 Hi Shuah,

 On Monday 05 Dec 2016 15:44:30 Shuah Khan wrote:
> On 11/30/2016 03:01 PM, Shuah Khan wrote:
>> Change ALSA driver to use Media Controller API to share media 
>> resources
>> with DVB, and V4L2 drivers on a AU0828 media device.
>>
>> Media Controller specific initialization is done after sound card is
>> registered. ALSA creates Media interface and entity function graph
>> nodes for Control, Mixer, PCM Playback, and PCM Capture devices.
>>
>> snd_usb_hw_params() will call Media Controller enable source handler
>> interface to request the media resource. If resource request is 
>> granted,
>> it will release it from snd_usb_hw_free(). If resource is busy, 
>> -EBUSY is
>> returned.
>>
>> Media specific cleanup is done in usb_audio_disconnect().
>>
>> Signed-off-by: Shuah Khan 
>
> Hi Takashi,
>
> If you are good with this patch, could you please Ack it, so Mauro
> can pull it into media tree with the other two patches in this series,
> when he is ready to do so.

 I *really* want to address the concerns raised by Sakari before 
 pulling more 
 code that makes fixing the race conditions more difficult. Please, 
 let's all 
 work on fixing the core code to build a stable base on which we can 
 build 
 additional features. V4L2 and MC need teamwork, it's time to give the 
 subsystem the love it deserves.

>>>
>>> Hi Laurent,
>>>
>>> The issue Sakari brought up is specific to using devm for video_device 
>>> in
>>> omap3 and vsp1. I tried reproducing the problem on two different drivers
>>> and couldn't on Linux 4.9-rc7.
>>>
>>> After sharing that with Sakari, I suggested to Sakari to pull up his 
>>> patch
>>> that removes the devm usage and see if he still needs all the patches 
>>> in his
>>> patch series. He didn't back to me on that. I also requested him to 
>>> rebase on
>>
>> Just to see what remains, I made a small hack to test this with omap3isp 
>> by
>> just replacing the devm_() functions by their plain counterparts. The 
>> memory
>> is thus never released, for there is no really a proper moment to 
>> release it
>> --- something which the patchset resolves. The result is here:
>>
>> 
>
> Did you test this on 4.9-rc7 without any of your other patches? If you
> haven't could you please run this test with just the removing devm usage
> from omap3isp?
>
> It would be good to get a baseline on the current with just the not using
> devm first and then see what needs fixing.
>
> Also, could you please send me the complete dmesg.

 Updated from v4.9-rc6 to rc7 and with increased CONFIG_LOG_BUF_SHIFT. The
 diff and dmesg are here:

 
 

>>>
>>> Does unbind work on this even without streaming? Could you suppress
>>
>> It's been working as long as I remember. There are caveats though --- the
>> clock to the sensor is provided by the ISP, so obviously things will not
>> work until the sensor is rebound as well. That is unrelated to the media
>> framework though; just FYI.
>>
>>> debug messages and run unbind without streaming. It might fail. Let
>>> me know if what you see with just unbind on this driver.
>>
>> I don't think disabling debug messages makes a difference but sure I can
>> provide you a log on that. But that'll be tomorrow.
> 
> There you go:
> 
> 

Sakari,

I am changing the subject line and sending a new email about some oddities in
omap3remove sequence. I would have worked on cleaning these up and sending
patches, but I am still working on getting the latest gumstix booting on my
Gumstix overo board. I will spare audio folks from the email barrage of our
debug logs :)

https://github.com/gumstix/linux/tree/master

thanks,
-- Shuah

--
To unsubscribe from this list: send the line "unsubscribe linux-media" 

[GIT PULL FOR v4.11] Media pipeline and graph walk cleanups and fixes

[Sakari Ailus]

Hi Mauro,

This pull request contains fixes and cleanups to the media pipeline and
graph walk code.

Please pull.


The following changes since commit 365fe4e0ce218dc5ad10df17b150a366b6015499:

  [media] mn88472: fix chip id check on probe (2016-12-01 12:47:22 -0200)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git routing-prepare

for you to fetch changes up to 9860755b60c5164624fbe685f8d95c9bff9469f0:

  davinci: Use a local media device pointer instead (2016-12-09 17:41:35 +0200)


Sakari Ailus (9):
  media: entity: Fix stream count check
  media: entity: Be vocal about failing sanity checks
  media: Rename graph and pipeline structs and functions
  media: entity: Split graph walk iteration into two functions
  media: Use single quotes to quote entity names
  media: entity: Add debug information to graph walk
  omap3isp: Use a local media device pointer instead
  xilinx: Use a local media device pointer instead
  davinci: Use a local media device pointer instead

 Documentation/media/kapi/mc-core.rst   |  18 +--
 drivers/media/media-device.c   |   8 +-
 drivers/media/media-entity.c   | 162 -
 drivers/media/platform/exynos4-is/fimc-capture.c   |   8 +-
 drivers/media/platform/exynos4-is/fimc-isp-video.c |   8 +-
 drivers/media/platform/exynos4-is/fimc-lite.c  |   8 +-
 drivers/media/platform/exynos4-is/media-dev.c  |  16 +-
 drivers/media/platform/exynos4-is/media-dev.h  |   2 +-
 drivers/media/platform/omap3isp/ispvideo.c |  16 +-
 drivers/media/platform/s3c-camif/camif-capture.c   |   6 +-
 drivers/media/platform/vsp1/vsp1_drm.c |   4 +-
 drivers/media/platform/vsp1/vsp1_video.c   |  16 +-
 drivers/media/platform/xilinx/xilinx-dma.c |  16 +-
 drivers/media/usb/au0828/au0828-core.c |   4 +-
 drivers/media/v4l2-core/v4l2-mc.c  |  18 +--
 drivers/staging/media/davinci_vpfe/vpfe_video.c|  25 ++--
 drivers/staging/media/davinci_vpfe/vpfe_video.h|   2 +-
 drivers/staging/media/omap4iss/iss_video.c |  32 ++--
 include/media/media-device.h   |   2 +-
 include/media/media-entity.h   |  65 -
 20 files changed, 227 insertions(+), 209 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/1] smiapp: Fix error handling in power on sequence

[Sakari Ailus]

The error handling code in smiapp_power_on() returned in case of a failed
I2C write instead of cleaning up the mess. Fix this.

Signed-off-by: Sakari Ailus 
---
 drivers/media/i2c/smiapp/smiapp-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index f4e92bd..e290601 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -1310,7 +1310,7 @@ static int smiapp_power_on(struct device *dev)
rval = smiapp_write(sensor, SMIAPP_REG_U8_DPHY_CTRL,
SMIAPP_DPHY_CTRL_UI);
if (rval < 0)
-   return rval;
+   goto out_cci_addr_fail;
 
rval = smiapp_call_quirk(sensor, post_poweron);
if (rval) {
-- 
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: [PATCH v2 8/9] xilinx: Use a local media device pointer instead

[Laurent Pinchart]

Hi Sakari,

Thank you for the patch.

On Friday 09 Dec 2016 16:53:41 Sakari Ailus wrote:
> The function has a local variable that points to the media device; use
> that instead of finding the media device under the entity.
> 
> Signed-off-by: Sakari Ailus 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/xilinx/xilinx-dma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/xilinx/xilinx-dma.c
> b/drivers/media/platform/xilinx/xilinx-dma.c index 065df82..522cdfd 100644
> --- a/drivers/media/platform/xilinx/xilinx-dma.c
> +++ b/drivers/media/platform/xilinx/xilinx-dma.c
> @@ -187,7 +187,7 @@ static int xvip_pipeline_validate(struct xvip_pipeline
> *pipe, mutex_lock(>graph_mutex);
> 
>   /* Walk the graph to locate the video nodes. */
> - ret = media_graph_walk_init(, entity->graph_obj.mdev);
> + ret = media_graph_walk_init(, mdev);
>   if (ret) {
>   mutex_unlock(>graph_mutex);
>   return ret;

-- 
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 v2 9/9] davinci: Use a local media device pointer instead

[Laurent Pinchart]

Hi Sakari,

Thank you for the patch.

On Friday 09 Dec 2016 16:53:42 Sakari Ailus wrote:
> The function has a local variable that points to the media device; use
> that instead of finding the media device under the entity.
> 
> Signed-off-by: Sakari Ailus 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/staging/media/davinci_vpfe/vpfe_video.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> b/drivers/staging/media/davinci_vpfe/vpfe_video.c index 03269d3..8b2117e
> 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> @@ -145,7 +145,7 @@ static int vpfe_prepare_pipeline(struct
> vpfe_video_device *video) pipe->outputs[pipe->output_num++] = video;
> 
>   mutex_lock(>graph_mutex);
> - ret = media_graph_walk_init(, entity->graph_obj.mdev);
> + ret = media_graph_walk_init(, mdev);
>   if (ret) {
>   mutex_unlock(>graph_mutex);
>   return -ENOMEM;
> @@ -300,7 +300,7 @@ static int vpfe_pipeline_enable(struct vpfe_pipeline
> *pipe)
> 
>   mdev = entity->graph_obj.mdev;
>   mutex_lock(>graph_mutex);
> - ret = media_graph_walk_init(>graph, entity->graph_obj.mdev);
> + ret = media_graph_walk_init(>graph, mdev);
>   if (ret)
>   goto out;
>   media_graph_walk_start(>graph, entity);

-- 
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 v2 7/9] omap3isp: Use a local media device pointer instead

[Laurent Pinchart]

Hi Sakari,

Thank you for the patch.

On Friday 09 Dec 2016 16:53:40 Sakari Ailus wrote:
> The function has a local variable that points to the media device; use
> that instead of finding the media device under the entity.
> 
> Signed-off-by: Sakari Ailus 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/omap3isp/ispvideo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/omap3isp/ispvideo.c
> b/drivers/media/platform/omap3isp/ispvideo.c index 5b0d16e..25a8210 100644
> --- a/drivers/media/platform/omap3isp/ispvideo.c
> +++ b/drivers/media/platform/omap3isp/ispvideo.c
> @@ -232,7 +232,7 @@ static int isp_video_get_graph_data(struct isp_video
> *video, int ret;
> 
>   mutex_lock(>graph_mutex);
> - ret = media_graph_walk_init(, entity->graph_obj.mdev);
> + ret = media_graph_walk_init(, mdev);
>   if (ret) {
>   mutex_unlock(>graph_mutex);
>   return ret;

-- 
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 v2 5/9] media: Use single quotes to quote entity names

[Laurent Pinchart]

Hi Sakari,

Thank you for the patch.

On Friday 09 Dec 2016 16:53:38 Sakari Ailus wrote:
> Instead of double quotes, use single quotes to quote entity names. Using
> single quotes is consistent with the English language and is also in line
> with the practices across the kernel.
> 
> Signed-off-by: Sakari Ailus 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/media-entity.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> index 1de28ce..5064ba0 100644
> --- a/drivers/media/media-entity.c
> +++ b/drivers/media/media-entity.c
> @@ -444,7 +444,7 @@ __must_check int __media_pipeline_start(struct
> media_entity *entity, ret = entity->ops->link_validate(link);
>   if (ret < 0 && ret != -ENOIOCTLCMD) {
>   dev_dbg(entity->graph_obj.mdev->dev,
> - "link validation failed for \"%s\":%u 
-> \"%s\":%u, error %d\n",
> + "link validation failed for '%s':%u -> 
'%s':%u, error %d\n",
>   link->source->entity->name,
>   link->source->index,
>   entity->name, link->sink->index, ret);
> @@ -458,7 +458,7 @@ __must_check int __media_pipeline_start(struct
> media_entity *entity, if (!bitmap_full(active, entity->num_pads)) {
>   ret = -ENOLINK;
>   dev_dbg(entity->graph_obj.mdev->dev,
> - "\"%s\":%u must be connected by an enabled 
link\n",
> + "'%s':%u must be connected by an enabled 
link\n",
>   entity->name,
>   (unsigned)find_first_zero_bit(
>   active, entity->num_pads));

-- 
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 v2 6/9] media: entity: Add debug information to graph walk

[Sakari Ailus]

Use dev_dbg() to tell about the progress of the graph traversal algorithm.
This is intended to make debugging of the algorithm easier.

Signed-off-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/media-entity.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 5064ba0..caa13e6 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -325,6 +325,8 @@ void media_graph_walk_start(struct media_graph *graph,
graph->top = 0;
graph->stack[graph->top].entity = NULL;
stack_push(graph, entity);
+   dev_dbg(entity->graph_obj.mdev->dev,
+   "begin graph walk at '%s'\n", entity->name);
 }
 EXPORT_SYMBOL_GPL(media_graph_walk_start);
 
@@ -339,6 +341,10 @@ static void media_graph_walk_iter(struct media_graph 
*graph)
/* The link is not enabled so we do not follow. */
if (!(link->flags & MEDIA_LNK_FL_ENABLED)) {
link_top(graph) = link_top(graph)->next;
+   dev_dbg(entity->graph_obj.mdev->dev,
+   "walk: skipping disabled link '%s':%u -> '%s':%u\n",
+   link->source->entity->name, link->source->index,
+   link->sink->entity->name, link->sink->index);
return;
}
 
@@ -348,16 +354,23 @@ static void media_graph_walk_iter(struct media_graph 
*graph)
/* Has the entity already been visited? */
if (media_entity_enum_test_and_set(>ent_enum, next)) {
link_top(graph) = link_top(graph)->next;
+   dev_dbg(entity->graph_obj.mdev->dev,
+   "walk: skipping entity '%s' (already seen)\n",
+   next->name);
return;
}
 
/* Push the new entity to stack and start over. */
link_top(graph) = link_top(graph)->next;
stack_push(graph, next);
+   dev_dbg(entity->graph_obj.mdev->dev, "walk: pushing '%s' on stack\n",
+   next->name);
 }
 
 struct media_entity *media_graph_walk_next(struct media_graph *graph)
 {
+   struct media_entity *entity;
+
if (stack_top(graph) == NULL)
return NULL;
 
@@ -369,7 +382,11 @@ struct media_entity *media_graph_walk_next(struct 
media_graph *graph)
while (link_top(graph) != _top(graph)->links)
media_graph_walk_iter(graph);
 
-   return stack_pop(graph);
+   entity = stack_pop(graph);
+   dev_dbg(entity->graph_obj.mdev->dev,
+   "walk: returning entity '%s'\n", entity->name);
+
+   return entity;
 }
 EXPORT_SYMBOL_GPL(media_graph_walk_next);
 
-- 
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

[PATCH v2 3/9] media: Rename graph and pipeline structs and functions

[Sakari Ailus]

The media_entity_pipeline_start() and media_entity_pipeline_stop()
functions are renamed as media_pipeline_start() and media_pipeline_stop(),
respectively. The reason is two-fold: the pipeline struct is, rightly,
already called media_pipeline (rather than media_entity_pipeline) and what
this really is about is a pipeline. A pipeline consists of entities ---
and, well, other objects embedded in these entities.

As the pipeline object will be in the future moved from entities to pads
in order to support multiple pipelines through a single entity, do the
renaming now.

Similarly, functions operating on struct media_entity_graph as well as the
struct itself are renamed by dropping the "entity_" part from the prefix
of the function family and the data structure. The graph traversal which
is what the functions are about is not specifically about entities only
and will operate on pads for the same reason as the media pipeline.

The patch has been generated using the following command:

git grep -l media_entity |xargs perl -i -pe '
s/media_entity_pipeline/media_pipeline/g;
s/media_entity_graph/media_graph/g'

And a few manual edits related to line start alignment and line wrapping.

Signed-off-by: Sakari Ailus 
Acked-by: Laurent Pinchart 
---
 Documentation/media/kapi/mc-core.rst   | 18 ++---
 drivers/media/media-device.c   |  8 +--
 drivers/media/media-entity.c   | 77 +++---
 drivers/media/platform/exynos4-is/fimc-capture.c   |  8 +--
 drivers/media/platform/exynos4-is/fimc-isp-video.c |  8 +--
 drivers/media/platform/exynos4-is/fimc-lite.c  |  8 +--
 drivers/media/platform/exynos4-is/media-dev.c  | 16 ++---
 drivers/media/platform/exynos4-is/media-dev.h  |  2 +-
 drivers/media/platform/omap3isp/ispvideo.c | 16 ++---
 drivers/media/platform/s3c-camif/camif-capture.c   |  6 +-
 drivers/media/platform/vsp1/vsp1_drm.c |  4 +-
 drivers/media/platform/vsp1/vsp1_video.c   | 16 ++---
 drivers/media/platform/xilinx/xilinx-dma.c | 16 ++---
 drivers/media/usb/au0828/au0828-core.c |  4 +-
 drivers/media/v4l2-core/v4l2-mc.c  | 18 ++---
 drivers/staging/media/davinci_vpfe/vpfe_video.c| 25 ---
 drivers/staging/media/davinci_vpfe/vpfe_video.h|  2 +-
 drivers/staging/media/omap4iss/iss_video.c | 32 -
 include/media/media-device.h   |  2 +-
 include/media/media-entity.h   | 65 +-
 20 files changed, 174 insertions(+), 177 deletions(-)

diff --git a/Documentation/media/kapi/mc-core.rst 
b/Documentation/media/kapi/mc-core.rst
index 1a738e5..0c05503 100644
--- a/Documentation/media/kapi/mc-core.rst
+++ b/Documentation/media/kapi/mc-core.rst
@@ -162,13 +162,13 @@ framework provides a depth-first graph traversal API for 
that purpose.
currently defined as 16.
 
 Drivers initiate a graph traversal by calling
-:c:func:`media_entity_graph_walk_start()`
+:c:func:`media_graph_walk_start()`
 
 The graph structure, provided by the caller, is initialized to start graph
 traversal at the given entity.
 
 Drivers can then retrieve the next entity by calling
-:c:func:`media_entity_graph_walk_next()`
+:c:func:`media_graph_walk_next()`
 
 When the graph traversal is complete the function will return ``NULL``.
 
@@ -206,7 +206,7 @@ Pipelines and media streams
 
 When starting streaming, drivers must notify all entities in the pipeline to
 prevent link states from being modified during streaming by calling
-:c:func:`media_entity_pipeline_start()`.
+:c:func:`media_pipeline_start()`.
 
 The function will mark all entities connected to the given entity through
 enabled links, either directly or indirectly, as streaming.
@@ -218,17 +218,17 @@ in higher-level pipeline structures and can then access 
the
 pipeline through the struct :c:type:`media_entity`
 pipe field.
 
-Calls to :c:func:`media_entity_pipeline_start()` can be nested.
+Calls to :c:func:`media_pipeline_start()` can be nested.
 The pipeline pointer must be identical for all nested calls to the function.
 
-:c:func:`media_entity_pipeline_start()` may return an error. In that case,
+:c:func:`media_pipeline_start()` may return an error. In that case,
 it will clean up any of the changes it did by itself.
 
 When stopping the stream, drivers must notify the entities with
-:c:func:`media_entity_pipeline_stop()`.
+:c:func:`media_pipeline_stop()`.
 
-If multiple calls to :c:func:`media_entity_pipeline_start()` have been
-made the same number of :c:func:`media_entity_pipeline_stop()` calls
+If multiple calls to :c:func:`media_pipeline_start()` have been
+made the same number of :c:func:`media_pipeline_stop()` calls
 are required to stop streaming.
 The :c:type:`media_entity`.\ ``pipe`` field is reset to ``NULL`` on the last
 nested stop call.
@@ -245,7 +245,7 @@ operation must be done with 

[PATCH v2 1/9] media: entity: Fix stream count check

[Sakari Ailus]

There's a sanity check for the stream count remaining positive or zero on
error path, but instead of performing the check on the traversed entity it
is performed on the entity where traversal ends. Fix this.

Fixes: commit 3801bc7d1b8d ("[media] media: Media Controller fix to not let 
stream_count go negative")
Signed-off-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/media-entity.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index f9f723f..e3b7ecd 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -474,7 +474,7 @@ __must_check int __media_entity_pipeline_start(struct 
media_entity *entity,
 
while ((entity_err = media_entity_graph_walk_next(graph))) {
/* don't let the stream_count go negative */
-   if (entity->stream_count > 0) {
+   if (entity_err->stream_count > 0) {
entity_err->stream_count--;
if (entity_err->stream_count == 0)
entity_err->pipe = NULL;
-- 
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

[PATCH v2 7/9] omap3isp: Use a local media device pointer instead

[Sakari Ailus]

The function has a local variable that points to the media device; use
that instead of finding the media device under the entity.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/omap3isp/ispvideo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/omap3isp/ispvideo.c 
b/drivers/media/platform/omap3isp/ispvideo.c
index 5b0d16e..25a8210 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -232,7 +232,7 @@ static int isp_video_get_graph_data(struct isp_video *video,
int ret;
 
mutex_lock(>graph_mutex);
-   ret = media_graph_walk_init(, entity->graph_obj.mdev);
+   ret = media_graph_walk_init(, mdev);
if (ret) {
mutex_unlock(>graph_mutex);
return ret;
-- 
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

[PATCH v2 4/9] media: entity: Split graph walk iteration into two functions

[Sakari Ailus]

With media_entity_graph_walk_next() getting more and more complicated (and
especially so with has_routing() support added), split the function into
two.

Signed-off-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/media-entity.c | 56 
 1 file changed, 30 insertions(+), 26 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 26cea7d..1de28ce 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -328,6 +328,34 @@ void media_graph_walk_start(struct media_graph *graph,
 }
 EXPORT_SYMBOL_GPL(media_graph_walk_start);
 
+static void media_graph_walk_iter(struct media_graph *graph)
+{
+   struct media_entity *entity = stack_top(graph);
+   struct media_link *link;
+   struct media_entity *next;
+
+   link = list_entry(link_top(graph), typeof(*link), list);
+
+   /* The link is not enabled so we do not follow. */
+   if (!(link->flags & MEDIA_LNK_FL_ENABLED)) {
+   link_top(graph) = link_top(graph)->next;
+   return;
+   }
+
+   /* Get the entity in the other end of the link . */
+   next = media_entity_other(entity, link);
+
+   /* Has the entity already been visited? */
+   if (media_entity_enum_test_and_set(>ent_enum, next)) {
+   link_top(graph) = link_top(graph)->next;
+   return;
+   }
+
+   /* Push the new entity to stack and start over. */
+   link_top(graph) = link_top(graph)->next;
+   stack_push(graph, next);
+}
+
 struct media_entity *media_graph_walk_next(struct media_graph *graph)
 {
if (stack_top(graph) == NULL)
@@ -338,32 +366,8 @@ struct media_entity *media_graph_walk_next(struct 
media_graph *graph)
 * top of the stack until no more entities on the level can be
 * found.
 */
-   while (link_top(graph) != _top(graph)->links) {
-   struct media_entity *entity = stack_top(graph);
-   struct media_link *link;
-   struct media_entity *next;
-
-   link = list_entry(link_top(graph), typeof(*link), list);
-
-   /* The link is not enabled so we do not follow. */
-   if (!(link->flags & MEDIA_LNK_FL_ENABLED)) {
-   link_top(graph) = link_top(graph)->next;
-   continue;
-   }
-
-   /* Get the entity in the other end of the link . */
-   next = media_entity_other(entity, link);
-
-   /* Has the entity already been visited? */
-   if (media_entity_enum_test_and_set(>ent_enum, next)) {
-   link_top(graph) = link_top(graph)->next;
-   continue;
-   }
-
-   /* Push the new entity to stack and start over. */
-   link_top(graph) = link_top(graph)->next;
-   stack_push(graph, next);
-   }
+   while (link_top(graph) != _top(graph)->links)
+   media_graph_walk_iter(graph);
 
return stack_pop(graph);
 }
-- 
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

[PATCH v2 8/9] xilinx: Use a local media device pointer instead

[Sakari Ailus]

The function has a local variable that points to the media device; use
that instead of finding the media device under the entity.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/xilinx/xilinx-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
b/drivers/media/platform/xilinx/xilinx-dma.c
index 065df82..522cdfd 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -187,7 +187,7 @@ static int xvip_pipeline_validate(struct xvip_pipeline 
*pipe,
mutex_lock(>graph_mutex);
 
/* Walk the graph to locate the video nodes. */
-   ret = media_graph_walk_init(, entity->graph_obj.mdev);
+   ret = media_graph_walk_init(, mdev);
if (ret) {
mutex_unlock(>graph_mutex);
return ret;
-- 
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

[PATCH v2] Media pipeline and graph walk cleanups and fixes

[Sakari Ailus]

Hi folks,

This is the second version of the patchset that contains a few cleanups
and fixes for graph traversal and pipeline starting and stopping.

The set prepares for further routing changes without still making any of
them. I'll post further patches on routing in the near future.  

since v1:

- Rebase on media-tree master branch, i.e. this no longer depends on the
  routing patches.

- Use single quotes instead of double quotes. One additional patch was
  added (patch 5) to switch to single quotes in existing debug messages.

- Add three cleanup patches to various drivers to use a local mdev
  variable for the media device pointer rather than digging it up in a
  deep data structure.

-- 
Kind regards,
Sakari

--
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 v2 9/9] davinci: Use a local media device pointer instead

[Sakari Ailus]

The function has a local variable that points to the media device; use
that instead of finding the media device under the entity.

Signed-off-by: Sakari Ailus 
---
 drivers/staging/media/davinci_vpfe/vpfe_video.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c 
b/drivers/staging/media/davinci_vpfe/vpfe_video.c
index 03269d3..8b2117e 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
@@ -145,7 +145,7 @@ static int vpfe_prepare_pipeline(struct vpfe_video_device 
*video)
pipe->outputs[pipe->output_num++] = video;
 
mutex_lock(>graph_mutex);
-   ret = media_graph_walk_init(, entity->graph_obj.mdev);
+   ret = media_graph_walk_init(, mdev);
if (ret) {
mutex_unlock(>graph_mutex);
return -ENOMEM;
@@ -300,7 +300,7 @@ static int vpfe_pipeline_enable(struct vpfe_pipeline *pipe)
 
mdev = entity->graph_obj.mdev;
mutex_lock(>graph_mutex);
-   ret = media_graph_walk_init(>graph, entity->graph_obj.mdev);
+   ret = media_graph_walk_init(>graph, mdev);
if (ret)
goto out;
media_graph_walk_start(>graph, entity);
-- 
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

[PATCH v2 5/9] media: Use single quotes to quote entity names

[Sakari Ailus]

Instead of double quotes, use single quotes to quote entity names. Using
single quotes is consistent with the English language and is also in line
with the practices across the kernel.

Signed-off-by: Sakari Ailus 
---
 drivers/media/media-entity.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 1de28ce..5064ba0 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -444,7 +444,7 @@ __must_check int __media_pipeline_start(struct media_entity 
*entity,
ret = entity->ops->link_validate(link);
if (ret < 0 && ret != -ENOIOCTLCMD) {
dev_dbg(entity->graph_obj.mdev->dev,
-   "link validation failed for \"%s\":%u 
-> \"%s\":%u, error %d\n",
+   "link validation failed for '%s':%u -> 
'%s':%u, error %d\n",
link->source->entity->name,
link->source->index,
entity->name, link->sink->index, ret);
@@ -458,7 +458,7 @@ __must_check int __media_pipeline_start(struct media_entity 
*entity,
if (!bitmap_full(active, entity->num_pads)) {
ret = -ENOLINK;
dev_dbg(entity->graph_obj.mdev->dev,
-   "\"%s\":%u must be connected by an enabled 
link\n",
+   "'%s':%u must be connected by an enabled 
link\n",
entity->name,
(unsigned)find_first_zero_bit(
active, entity->num_pads));
-- 
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

[PATCH v2 2/9] media: entity: Be vocal about failing sanity checks

[Sakari Ailus]

Commit 3801bc7d1b8d ("[media] media: Media Controller fix to not let
stream_count go negative") added a sanity check for negative stream_count,
but a failure of the check remained silent. Make sure the failure is
noticed.

Signed-off-by: Sakari Ailus 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/media-entity.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index e3b7ecd..3809257 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -473,8 +473,8 @@ __must_check int __media_entity_pipeline_start(struct 
media_entity *entity,
media_entity_graph_walk_start(graph, entity_err);
 
while ((entity_err = media_entity_graph_walk_next(graph))) {
-   /* don't let the stream_count go negative */
-   if (entity_err->stream_count > 0) {
+   /* Sanity check for negative stream_count */
+   if (!WARN_ON_ONCE(entity_err->stream_count <= 0)) {
entity_err->stream_count--;
if (entity_err->stream_count == 0)
entity_err->pipe = NULL;
@@ -519,8 +519,8 @@ void __media_entity_pipeline_stop(struct media_entity 
*entity)
media_entity_graph_walk_start(graph, entity);
 
while ((entity = media_entity_graph_walk_next(graph))) {
-   /* don't let the stream_count go negative */
-   if (entity->stream_count > 0) {
+   /* Sanity check for negative stream_count */
+   if (!WARN_ON_ONCE(entity->stream_count <= 0)) {
entity->stream_count--;
if (entity->stream_count == 0)
entity->pipe = NULL;
-- 
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

[PATCH 1/2] si2168: implement ber statistics

[Antti Palosaari]

Implement DVBv5 BER.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-frontends/si2168.c  | 46 +--
 drivers/media/dvb-frontends/si2168_priv.h |  1 +
 2 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 20b4a65..5fbb6c1 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -85,7 +85,8 @@ static int si2168_read_status(struct dvb_frontend *fe, enum 
fe_status *status)
struct i2c_client *client = fe->demodulator_priv;
struct si2168_dev *dev = i2c_get_clientdata(client);
struct dtv_frontend_properties *c = >dtv_property_cache;
-   int ret;
+   int ret, i;
+   unsigned int utmp, utmp1, utmp2;
struct si2168_cmd cmd;
 
*status = 0;
@@ -144,6 +145,39 @@ static int si2168_read_status(struct dvb_frontend *fe, 
enum fe_status *status)
dev_dbg(>dev, "status=%02x args=%*ph\n",
*status, cmd.rlen, cmd.args);
 
+   /* BER */
+   if (*status & FE_HAS_VITERBI) {
+   memcpy(cmd.args, "\x82\x00", 2);
+   cmd.wlen = 2;
+   cmd.rlen = 3;
+   ret = si2168_cmd_execute(client, );
+   if (ret)
+   goto err;
+
+   /*
+* Firmware returns [0, 255] mantissa and [0, 8] exponent.
+* Convert to DVB API: mantissa * 10^(8 - exponent) / 10^8
+*/
+   utmp = clamp(8 - cmd.args[1], 0, 8);
+   for (i = 0, utmp1 = 1; i < utmp; i++)
+   utmp1 = utmp1 * 10;
+
+   utmp1 = cmd.args[2] * utmp1;
+   utmp2 = 1; /* 10^8 */
+
+   dev_dbg(>dev,
+   "post_bit_error=%u post_bit_count=%u ber=%u*10^-%u\n",
+   utmp1, utmp2, cmd.args[2], cmd.args[1]);
+
+   c->post_bit_error.stat[0].scale = FE_SCALE_COUNTER;
+   c->post_bit_error.stat[0].uvalue += utmp1;
+   c->post_bit_count.stat[0].scale = FE_SCALE_COUNTER;
+   c->post_bit_count.stat[0].uvalue += utmp2;
+   } else {
+   c->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   }
+
return 0;
 err:
dev_dbg(>dev, "failed=%d\n", ret);
@@ -355,6 +389,7 @@ static int si2168_init(struct dvb_frontend *fe)
 {
struct i2c_client *client = fe->demodulator_priv;
struct si2168_dev *dev = i2c_get_clientdata(client);
+   struct dtv_frontend_properties *c = >dtv_property_cache;
int ret, len, remaining;
const struct firmware *fw;
struct si2168_cmd cmd;
@@ -493,10 +528,17 @@ static int si2168_init(struct dvb_frontend *fe)
 
dev->warm = true;
 warm:
+   /* Init stats here to indicate which stats are supported */
+   c->cnr.len = 1;
+   c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   c->post_bit_error.len = 1;
+   c->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   c->post_bit_count.len = 1;
+   c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
dev->active = true;
 
return 0;
-
 err_release_firmware:
release_firmware(fw);
 err:
diff --git a/drivers/media/dvb-frontends/si2168_priv.h 
b/drivers/media/dvb-frontends/si2168_priv.h
index 7843ccb..2fecac6 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -21,6 +21,7 @@
 #include "dvb_frontend.h"
 #include 
 #include 
+#include 
 
 #define SI2168_A20_FIRMWARE "dvb-demod-si2168-a20-01.fw"
 #define SI2168_A30_FIRMWARE "dvb-demod-si2168-a30-01.fw"
-- 
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 2/2] si2168: implement ucb statistics

[Antti Palosaari]

Implement DVBv5 UCB. Only uncorrected blocks are currently counted.

Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-frontends/si2168.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 5fbb6c1..680ba06 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -178,6 +178,28 @@ static int si2168_read_status(struct dvb_frontend *fe, 
enum fe_status *status)
c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
}
 
+   /* UCB */
+   if (*status & FE_HAS_SYNC) {
+   memcpy(cmd.args, "\x84\x01", 2);
+   cmd.wlen = 2;
+   cmd.rlen = 3;
+   ret = si2168_cmd_execute(client, );
+   if (ret)
+   goto err;
+
+   utmp1 = cmd.args[2] << 8 | cmd.args[1] << 0;
+   dev_dbg(>dev, "block_error=%u\n", utmp1);
+
+   /* Sometimes firmware returns bogus value */
+   if (utmp1 == 0x)
+   utmp1 = 0;
+
+   c->block_error.stat[0].scale = FE_SCALE_COUNTER;
+   c->block_error.stat[0].uvalue += utmp1;
+   } else {
+   c->block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   }
+
return 0;
 err:
dev_dbg(>dev, "failed=%d\n", ret);
@@ -535,6 +557,8 @@ static int si2168_init(struct dvb_frontend *fe)
c->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
c->post_bit_count.len = 1;
c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   c->block_error.len = 1;
+   c->block_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
 
dev->active = true;
 
-- 
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 v6 3/3] sound/usb: Use Media Controller API to share media resources

[Sakari Ailus]

Hi Shuah,

On Fri, Dec 09, 2016 at 01:44:07AM +0200, Sakari Ailus wrote:
> Hi Shuah,
> 
> On Thu, Dec 08, 2016 at 07:46:03AM -0700, Shuah Khan wrote:
> > Hi Sakari,
> > 
> > On 12/07/2016 03:27 PM, Sakari Ailus wrote:
> > > Hi Shuah,
> > > 
> > > On Wed, Dec 07, 2016 at 01:03:59PM -0700, Shuah Khan wrote:
> > >> Hi Sakari,
> > >>
> > >> On 12/07/2016 03:52 AM, Sakari Ailus wrote:
> > >>> Hi Shuah,
> > >>>
> > >>> On Mon, Dec 05, 2016 at 05:38:23PM -0700, Shuah Khan wrote:
> >  On 12/05/2016 04:21 PM, Laurent Pinchart wrote:
> > > Hi Shuah,
> > >
> > > On Monday 05 Dec 2016 15:44:30 Shuah Khan wrote:
> > >> On 11/30/2016 03:01 PM, Shuah Khan wrote:
> > >>> Change ALSA driver to use Media Controller API to share media 
> > >>> resources
> > >>> with DVB, and V4L2 drivers on a AU0828 media device.
> > >>>
> > >>> Media Controller specific initialization is done after sound card is
> > >>> registered. ALSA creates Media interface and entity function graph
> > >>> nodes for Control, Mixer, PCM Playback, and PCM Capture devices.
> > >>>
> > >>> snd_usb_hw_params() will call Media Controller enable source handler
> > >>> interface to request the media resource. If resource request is 
> > >>> granted,
> > >>> it will release it from snd_usb_hw_free(). If resource is busy, 
> > >>> -EBUSY is
> > >>> returned.
> > >>>
> > >>> Media specific cleanup is done in usb_audio_disconnect().
> > >>>
> > >>> Signed-off-by: Shuah Khan 
> > >>
> > >> Hi Takashi,
> > >>
> > >> If you are good with this patch, could you please Ack it, so Mauro
> > >> can pull it into media tree with the other two patches in this 
> > >> series,
> > >> when he is ready to do so.
> > >
> > > I *really* want to address the concerns raised by Sakari before 
> > > pulling more 
> > > code that makes fixing the race conditions more difficult. Please, 
> > > let's all 
> > > work on fixing the core code to build a stable base on which we can 
> > > build 
> > > additional features. V4L2 and MC need teamwork, it's time to give the 
> > > subsystem the love it deserves.
> > >
> > 
> >  Hi Laurent,
> > 
> >  The issue Sakari brought up is specific to using devm for video_device 
> >  in
> >  omap3 and vsp1. I tried reproducing the problem on two different 
> >  drivers
> >  and couldn't on Linux 4.9-rc7.
> > 
> >  After sharing that with Sakari, I suggested to Sakari to pull up his 
> >  patch
> >  that removes the devm usage and see if he still needs all the patches 
> >  in his
> >  patch series. He didn't back to me on that. I also requested him to 
> >  rebase on
> > >>>
> > >>> Just to see what remains, I made a small hack to test this with 
> > >>> omap3isp by
> > >>> just replacing the devm_() functions by their plain counterparts. The 
> > >>> memory
> > >>> is thus never released, for there is no really a proper moment to 
> > >>> release it
> > >>> --- something which the patchset resolves. The result is here:
> > >>>
> > >>> 
> > >>
> > >> Did you test this on 4.9-rc7 without any of your other patches? If you
> > >> haven't could you please run this test with just the removing devm usage
> > >> from omap3isp?
> > >>
> > >> It would be good to get a baseline on the current with just the not using
> > >> devm first and then see what needs fixing.
> > >>
> > >> Also, could you please send me the complete dmesg.
> > > 
> > > Updated from v4.9-rc6 to rc7 and with increased CONFIG_LOG_BUF_SHIFT. The
> > > diff and dmesg are here:
> > > 
> > > 
> > > 
> > > 
> > 
> > Does unbind work on this even without streaming? Could you suppress
> 
> It's been working as long as I remember. There are caveats though --- the
> clock to the sensor is provided by the ISP, so obviously things will not
> work until the sensor is rebound as well. That is unrelated to the media
> framework though; just FYI.
> 
> > debug messages and run unbind without streaming. It might fail. Let
> > me know if what you see with just unbind on this driver.
> 
> I don't think disabling debug messages makes a difference but sure I can
> provide you a log on that. But that'll be tomorrow.

There you go:



-- 
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 v1.5 2/6] v4l: rcar-fcp: Add an API to retrieve the FCP device

[Ulrich Hecht]

From: Laurent Pinchart 

The new rcar_fcp_get_device() function retrieves the struct device
related to the FCP device. This is useful to handle DMA mapping through
the right device.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-fcp.c | 6 ++
 include/media/rcar-fcp.h  | 5 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/media/platform/rcar-fcp.c 
b/drivers/media/platform/rcar-fcp.c
index e9f609e..2988031 100644
--- a/drivers/media/platform/rcar-fcp.c
+++ b/drivers/media/platform/rcar-fcp.c
@@ -78,6 +78,12 @@ void rcar_fcp_put(struct rcar_fcp_device *fcp)
 }
 EXPORT_SYMBOL_GPL(rcar_fcp_put);
 
+struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp)
+{
+   return fcp->dev;
+}
+EXPORT_SYMBOL_GPL(rcar_fcp_get_device);
+
 /**
  * rcar_fcp_enable - Enable an FCP
  * @fcp: The FCP instance
diff --git a/include/media/rcar-fcp.h b/include/media/rcar-fcp.h
index 8723f05..b60a7b1 100644
--- a/include/media/rcar-fcp.h
+++ b/include/media/rcar-fcp.h
@@ -19,6 +19,7 @@ struct rcar_fcp_device;
 #if IS_ENABLED(CONFIG_VIDEO_RENESAS_FCP)
 struct rcar_fcp_device *rcar_fcp_get(const struct device_node *np);
 void rcar_fcp_put(struct rcar_fcp_device *fcp);
+struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp);
 int rcar_fcp_enable(struct rcar_fcp_device *fcp);
 void rcar_fcp_disable(struct rcar_fcp_device *fcp);
 #else
@@ -27,6 +28,10 @@ static inline struct rcar_fcp_device *rcar_fcp_get(const 
struct device_node *np)
return ERR_PTR(-ENOENT);
 }
 static inline void rcar_fcp_put(struct rcar_fcp_device *fcp) { }
+static inline struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp)
+{
+   return NULL;
+}
 static inline int rcar_fcp_enable(struct rcar_fcp_device *fcp)
 {
return 0;
-- 
2.7.4

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

[PATCH v1.5 0/6] R-Car DU: Fix IOMMU operation when connected to VSP

[Ulrich Hecht]

Hi!

This is a slightly updated version of Laurent's series that adds the fix
suggested by Magnus Damm and connects the FCP devices on M3-W to their
IPMMU. It also drops the patches that have already been picked up in the
media tree.

With this series and an assortment of patches from the renesas-drivers tree (
iommu/ipmmu-vmsa: Remove platform data handling
iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context
iommu/ipmmu-vmsa: Break out utlb parsing code
iommu/ipmmu-vmsa: Break out domain allocation code
iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops
iommu/ipmmu-vmsa: ARM and ARM64 archdata access
iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency
iommu/ipmmu-vmsa: Introduce features, break out alias
iommu/ipmmu-vmsa: Add optional root device feature
iommu/ipmmu-vmsa: Enable multi context support
iommu/ipmmu-vmsa: Reuse iommu groups
iommu/ipmmu-vmsa: Make use of IOMMU_OF_DECLARE()
iommu/ipmmu-vmsa: Teach xlate() to skip disabled iommus
iommu/ipmmu-vmsa: IPMMU device is 64-bit bus master
iommu/ipmmu-vmsa: Write IMCTR twice
iommu/ipmmu-vmsa: Make IMBUSCTR setup optional
iommu/ipmmu-vmsa: Allow two bit SL0
iommu/ipmmu-vmsa: Hook up r8a7795 DT matching code
iommu/ipmmu-vmsa: Add r8a7796 DT binding
iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
arm64: dts: r8a7795: Add IPMMU device nodes
arm64: dts: r8a7795: Hook up SYS-DMAC to IPMMU
arm64: dts: r8a7795: Point FCP devices to IPMMU
arm64: dts: r8a7795: Connect Ethernet AVB to IPMMU
arm64: dts: r8a7796: Add IPMMU device nodes
clk: renesas: r8a7796: Add FCP clocks
clk: renesas: r8a7796: Add VSP clocks
clk: renesas: r8a7796: Add DU and LVDS clocks
drm: rcar-du: Add R8A7796 device support
arm64: dts: renesas: r8a7795: Remove FCP SoC-specific compatible strings
arm64: dts: renesas: r8a7796: Add FCPF and FCPV instances
arm64: dts: renesas: r8a7796: Add VSP instances
arm64: dts: renesas: r8a7796: Add DU device to DT
arm64: dts: renesas: r8a7796-salvator-x: Enable DU
), I can enable IPMMU on both the H3 and M3-W Salvator-X boards with no ill
effects on the results of the vsp-tests suite.

CU
Uli


Laurent Pinchart (4):
  v4l: rcar-fcp: Don't get/put module reference
  v4l: rcar-fcp: Add an API to retrieve the FCP device
  v4l: vsp1: Add API to map and unmap DRM buffers through the VSP
  drm: rcar-du: Map memory through the VSP device

Ulrich Hecht (2):
  v4l: vsp1: Provide display list and VB2 queue with FCP device
  arm64: dts: r8a7796: Connect FCP devices to IPMMU

 arch/arm64/boot/dts/renesas/r8a7796.dtsi |  3 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 74 +---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h|  2 +
 drivers/media/platform/rcar-fcp.c| 17 
 drivers/media/platform/vsp1/vsp1_dl.c| 12 --
 drivers/media/platform/vsp1/vsp1_drm.c   | 24 +++
 drivers/media/platform/vsp1/vsp1_video.c |  6 ++-
 include/media/rcar-fcp.h |  5 +++
 include/media/vsp1.h |  3 ++
 9 files changed, 127 insertions(+), 19 deletions(-)

-- 
2.7.4

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

[PATCH v1.5 6/6] arm64: dts: r8a7796: Connect FCP devices to IPMMU

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 52e81bb..f5496d4 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -440,6 +440,7 @@
reg = <0 0xfea27000 0 0x200>;
clocks = < CPG_MOD 603>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
+   iommus = <_vi 8>;
};
 
vspd1: vsp@fea28000 {
@@ -457,6 +458,7 @@
reg = <0 0xfea2f000 0 0x200>;
clocks = < CPG_MOD 602>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
+   iommus = <_vi 9>;
};
 
vspd2: vsp@fea3 {
@@ -474,6 +476,7 @@
reg = <0 0xfea37000 0 0x200>;
clocks = < CPG_MOD 601>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
+   iommus = <_vi 10>;
};
 
du: display@feb0 {
-- 
2.7.4

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

[PATCH v1.5 1/6] v4l: rcar-fcp: Don't get/put module reference

[Ulrich Hecht]

From: Laurent Pinchart 

Direct callers of the FCP API hold a reference to the FCP module due to
module linkage, there's no need to take another one manually. Take a
reference to the device instead to ensure that it won't disappear behind
the caller's back.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-fcp.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/rcar-fcp.c 
b/drivers/media/platform/rcar-fcp.c
index 7146fc5..e9f609e 100644
--- a/drivers/media/platform/rcar-fcp.c
+++ b/drivers/media/platform/rcar-fcp.c
@@ -53,14 +53,7 @@ struct rcar_fcp_device *rcar_fcp_get(const struct 
device_node *np)
if (fcp->dev->of_node != np)
continue;
 
-   /*
-* Make sure the module won't be unloaded behind our back. This
-* is a poor man's safety net, the module should really not be
-* unloaded while FCP users can be active.
-*/
-   if (!try_module_get(fcp->dev->driver->owner))
-   fcp = NULL;
-
+   get_device(fcp->dev);
goto done;
}
 
@@ -81,7 +74,7 @@ EXPORT_SYMBOL_GPL(rcar_fcp_get);
 void rcar_fcp_put(struct rcar_fcp_device *fcp)
 {
if (fcp)
-   module_put(fcp->dev->driver->owner);
+   put_device(fcp->dev);
 }
 EXPORT_SYMBOL_GPL(rcar_fcp_put);
 
-- 
2.7.4

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

[PATCH v1.5 3/6] v4l: vsp1: Add API to map and unmap DRM buffers through the VSP

[Ulrich Hecht]

From: Laurent Pinchart 

The display buffers must be mapped for DMA through the device that
performs memory access. Expose an API to map and unmap memory through
the VSP device to be used by the DU.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 24 
 include/media/vsp1.h   |  3 +++
 2 files changed, 27 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index cd209dc..bb35603 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -12,9 +12,11 @@
  */
 
 #include 
+#include 
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -519,6 +521,28 @@ void vsp1_du_atomic_flush(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(vsp1_du_atomic_flush);
 
+int vsp1_du_map_sg(struct device *dev, struct sg_table *sgt)
+{
+   struct vsp1_device *vsp1 = dev_get_drvdata(dev);
+   struct device *map_dev;
+
+   map_dev = vsp1->fcp ? rcar_fcp_get_device(vsp1->fcp) : dev;
+
+   return dma_map_sg(map_dev, sgt->sgl, sgt->nents, DMA_TO_DEVICE);
+}
+EXPORT_SYMBOL_GPL(vsp1_du_map_sg);
+
+void vsp1_du_unmap_sg(struct device *dev, struct sg_table *sgt)
+{
+   struct vsp1_device *vsp1 = dev_get_drvdata(dev);
+   struct device *map_dev;
+
+   map_dev = vsp1->fcp ? rcar_fcp_get_device(vsp1->fcp) : dev;
+
+   dma_unmap_sg(map_dev, sgt->sgl, sgt->nents, DMA_TO_DEVICE);
+}
+EXPORT_SYMBOL_GPL(vsp1_du_unmap_sg);
+
 /* 
-
  * Initialization
  */
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 458b400..8d3d07a 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -13,6 +13,7 @@
 #ifndef __MEDIA_VSP1_H__
 #define __MEDIA_VSP1_H__
 
+#include 
 #include 
 #include 
 
@@ -37,5 +38,7 @@ void vsp1_du_atomic_begin(struct device *dev);
 int vsp1_du_atomic_update(struct device *dev, unsigned int rpf,
  const struct vsp1_du_atomic_config *cfg);
 void vsp1_du_atomic_flush(struct device *dev);
+int vsp1_du_map_sg(struct device *dev, struct sg_table *sgt);
+void vsp1_du_unmap_sg(struct device *dev, struct sg_table *sgt);
 
 #endif /* __MEDIA_VSP1_H__ */
-- 
2.7.4

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

[PATCH v1.5 5/6] v4l: vsp1: Provide display list and VB2 queue with FCP device

[Ulrich Hecht]

Prevents IPMMU trap during boot on r8a7795/6 Salvator-X boards:
ipmmu-vmsa febd.mmu: Unhandled faut: status 0x0101 iova 0x7f09a000

Code by Magnus Damm.

Signed-off-by: Ulrich Hecht 
---
 drivers/media/platform/vsp1/vsp1_dl.c| 12 +---
 drivers/media/platform/vsp1/vsp1_video.c |  6 +-
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index ad545af..f610c88 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 
+#include 
+
 #include "vsp1.h"
 #include "vsp1_dl.h"
 
@@ -133,12 +135,13 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
 size_t extra_size)
 {
size_t size = num_entries * sizeof(*dlb->entries) + extra_size;
+   struct device *fcp = rcar_fcp_get_device(vsp1->fcp);
 
dlb->vsp1 = vsp1;
dlb->size = size;
 
-   dlb->entries = dma_alloc_wc(vsp1->dev, dlb->size, >dma,
-   GFP_KERNEL);
+   dlb->entries = dma_alloc_wc(fcp ? fcp : vsp1->dev,
+   dlb->size, >dma, GFP_KERNEL);
if (!dlb->entries)
return -ENOMEM;
 
@@ -150,7 +153,10 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
  */
 static void vsp1_dl_body_cleanup(struct vsp1_dl_body *dlb)
 {
-   dma_free_wc(dlb->vsp1->dev, dlb->size, dlb->entries, dlb->dma);
+   struct device *fcp = rcar_fcp_get_device(dlb->vsp1->fcp);
+
+   dma_free_wc(fcp ? fcp : dlb->vsp1->dev,
+   dlb->size, dlb->entries, dlb->dma);
 }
 
 /**
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 41e8b09..8f8e57e 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 
+#include 
+
 #include "vsp1.h"
 #include "vsp1_bru.h"
 #include "vsp1_dl.h"
@@ -1094,6 +1096,7 @@ struct vsp1_video *vsp1_video_create(struct vsp1_device 
*vsp1,
 {
struct vsp1_video *video;
const char *direction;
+   struct device *fcp;
int ret;
 
video = devm_kzalloc(vsp1->dev, sizeof(*video), GFP_KERNEL);
@@ -1151,7 +1154,8 @@ struct vsp1_video *vsp1_video_create(struct vsp1_device 
*vsp1,
video->queue.ops = _video_queue_qops;
video->queue.mem_ops = _dma_contig_memops;
video->queue.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
-   video->queue.dev = video->vsp1->dev;
+   fcp = rcar_fcp_get_device(vsp1->fcp);
+   video->queue.dev = fcp ? fcp : video->vsp1->dev;
ret = vb2_queue_init(>queue);
if (ret < 0) {
dev_err(video->vsp1->dev, "failed to initialize vb2 queue\n");
-- 
2.7.4

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

[PATCH v1.5 4/6] drm: rcar-du: Map memory through the VSP device

[Ulrich Hecht]

From: Laurent Pinchart 

For planes handled by a VSP instance, map the framebuffer memory through
the VSP to ensure proper IOMMU handling.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 74 ---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h |  2 +
 2 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 83ebd16..851c2e7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -19,7 +19,9 @@
 #include 
 #include 
 
+#include 
 #include 
+#include 
 #include 
 
 #include 
@@ -166,12 +168,9 @@ static void rcar_du_vsp_plane_setup(struct 
rcar_du_vsp_plane *plane)
cfg.dst.width = state->state.crtc_w;
cfg.dst.height = state->state.crtc_h;
 
-   for (i = 0; i < state->format->planes; ++i) {
-   struct drm_gem_cma_object *gem;
-
-   gem = drm_fb_cma_get_gem_obj(fb, i);
-   cfg.mem[i] = gem->paddr + fb->offsets[i];
-   }
+   for (i = 0; i < state->format->planes; ++i)
+   cfg.mem[i] = sg_dma_address(state->sg_tables[i].sgl)
+  + fb->offsets[i];
 
for (i = 0; i < ARRAY_SIZE(formats_kms); ++i) {
if (formats_kms[i] == state->format->fourcc) {
@@ -183,6 +182,67 @@ static void rcar_du_vsp_plane_setup(struct 
rcar_du_vsp_plane *plane)
vsp1_du_atomic_update(plane->vsp->vsp, plane->index, );
 }
 
+static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
+   struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+   struct rcar_du_device *rcdu = vsp->dev;
+   unsigned int i;
+   int ret;
+
+   if (!state->fb)
+   return 0;
+
+   for (i = 0; i < rstate->format->planes; ++i) {
+   struct drm_gem_cma_object *gem =
+   drm_fb_cma_get_gem_obj(state->fb, i);
+   struct sg_table *sgt = >sg_tables[i];
+
+   ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr, gem->paddr,
+ gem->base.size);
+   if (ret)
+   goto fail;
+
+   ret = vsp1_du_map_sg(vsp->vsp, sgt);
+   if (!ret) {
+   sg_free_table(sgt);
+   ret = -ENOMEM;
+   goto fail;
+   }
+   }
+
+   return 0;
+
+fail:
+   for (i--; i >= 0; i--) {
+   struct sg_table *sgt = >sg_tables[i];
+
+   vsp1_du_unmap_sg(vsp->vsp, sgt);
+   sg_free_table(sgt);
+   }
+
+   return ret;
+}
+
+static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+   struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
+   struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+   unsigned int i;
+
+   if (!state->fb)
+   return;
+
+   for (i = 0; i < rstate->format->planes; ++i) {
+   struct sg_table *sgt = >sg_tables[i];
+
+   vsp1_du_unmap_sg(vsp->vsp, sgt);
+   sg_free_table(sgt);
+   }
+}
+
 static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
  struct drm_plane_state *state)
 {
@@ -223,6 +283,8 @@ static void rcar_du_vsp_plane_atomic_update(struct 
drm_plane *plane,
 }
 
 static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs = {
+   .prepare_fb = rcar_du_vsp_plane_prepare_fb,
+   .cleanup_fb = rcar_du_vsp_plane_cleanup_fb,
.atomic_check = rcar_du_vsp_plane_atomic_check,
.atomic_update = rcar_du_vsp_plane_atomic_update,
 };
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index 510dcc9..bbb4161 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -43,6 +43,7 @@ static inline struct rcar_du_vsp_plane 
*to_rcar_vsp_plane(struct drm_plane *p)
  * struct rcar_du_vsp_plane_state - Driver-specific plane state
  * @state: base DRM plane state
  * @format: information about the pixel format used by the plane
+ * @sg_tables: scatter-gather tables for the frame buffer memory
  * @alpha: value of the plane alpha property
  * @zpos: value of the plane zpos property
  */
@@ -50,6 +51,7 @@ struct rcar_du_vsp_plane_state {
struct drm_plane_state state;
 
const struct rcar_du_format_info *format;
+   struct sg_table sg_tables[3];
 
unsigned int alpha;
unsigned int zpos;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the 

[PATCH v2 0/6] Fix tvp5150 regression with em28xx

[Laurent Pinchart]

Hello,

This patch series fixes a regression reported by Devin Heitmueller that
affects a large number of em28xx. The problem was introduced by

commit 13d52fe40f1f7bbad49128e8ee6a2fe5e13dd18d
Author: Mauro Carvalho Chehab 
Date:   Tue Jan 26 06:59:39 2016 -0200

[media] em28xx: fix implementation of s_stream

that started calling s_stream(1) in the em28xx driver when enabling the
stream, resulting in the tvp5150 s_stream() operation writing several
registers with values fit for other platforms (namely OMAP3, possibly others)
but not for em28xx.

The series starts with two unrelated drive-by cleanups and an unrelated bug
fix. It then continues with a patch to remove an unneeded and armful call to
tvp5150_reset() when getting the format from the subdevice (4/6), an update of
an invalid comment and the addition of macros for register bits in order to
make the code more readable (5/6) and actually allow following the incorrect
code flow, and finally a rework of the s_stream() operation to fix the
problem.

Compared to v1,

- Patch 4/5 now calls tvp5150_reset() at probe time
- Patch 5/6 is fixed with an extra ~ removed

I haven't been able to test this with an em28xx device as I don't own any that
contains a tvp5150, but Mauro reported that the series fixes the issue with
his device.

I also haven't been able to test anything on an OMAP3 platform, as the tvp5150
driver go broken on DT-based systems by

commit f7b4b54e63643b740c598e044874c4bffa0f04f2
Author: Javier Martinez Canillas 
Date:   Fri Feb 5 17:09:58 2016 -0200

[media] tvp5150: add HW input connectors support

Fixing it will be the topic of another patch series.

Laurent Pinchart (6):
  v4l: tvp5150: Compile tvp5150_link_setup out if
!CONFIG_MEDIA_CONTROLLER
  v4l: tvp5150: Don't inline the tvp5150_selmux() function
  v4l: tvp5150: Add missing break in set control handler
  v4l: tvp5150: Reset device at probe time, not in get/set format
handlers
  v4l: tvp5150: Fix comment regarding output pin muxing
  v4l: tvp5150: Don't override output pinmuxing at stream on/off time

 drivers/media/i2c/tvp5150.c | 63 +
 drivers/media/i2c/tvp5150_reg.h |  9 ++
 2 files changed, 48 insertions(+), 24 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 v2 2/6] v4l: tvp5150: Don't inline the tvp5150_selmux() function

[Laurent Pinchart]

The function is large and called in several places, don't inline it.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/i2c/tvp5150.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 08384951c9e5..febe6833a504 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -258,7 +258,7 @@ static int tvp5150_log_status(struct v4l2_subdev *sd)
Basic functions
  /
 
-static inline void tvp5150_selmux(struct v4l2_subdev *sd)
+static void tvp5150_selmux(struct v4l2_subdev *sd)
 {
int opmode = 0;
struct tvp5150 *decoder = to_tvp5150(sd);
-- 
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 v2 1/6] v4l: tvp5150: Compile tvp5150_link_setup out if !CONFIG_MEDIA_CONTROLLER

[Laurent Pinchart]

The function is only referenced as a handler in the tvp5150_sd_media_ops
structure, which is only used when CONFIG_MEDIA_CONTROLLER is set. Don't
define the function and the structure when the configuration option is
unset to avoid an unused function warning.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/i2c/tvp5150.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 6737685d5be5..08384951c9e5 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1013,11 +1013,11 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev 
*sd,
Media entity ops
  /
 
+#ifdef CONFIG_MEDIA_CONTROLLER
 static int tvp5150_link_setup(struct media_entity *entity,
  const struct media_pad *local,
  const struct media_pad *remote, u32 flags)
 {
-#ifdef CONFIG_MEDIA_CONTROLLER
struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
struct tvp5150 *decoder = to_tvp5150(sd);
int i;
@@ -1034,7 +1034,6 @@ static int tvp5150_link_setup(struct media_entity *entity,
decoder->input = i;
 
tvp5150_selmux(sd);
-#endif
 
return 0;
 }
@@ -1042,6 +1041,7 @@ static int tvp5150_link_setup(struct media_entity *entity,
 static const struct media_entity_operations tvp5150_sd_media_ops = {
.link_setup = tvp5150_link_setup,
 };
+#endif
 
 /
I2C Command
-- 
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 v2 5/6] v4l: tvp5150: Fix comment regarding output pin muxing

[Laurent Pinchart]

The FID/GLCO/VLK/HVLK and INTREQ/GPCL/VBLK pins are muxed differently
depending on whether the input is an S-Video or composite signal. The
comment that explains the logic doesn't reflect the code. It appears
that the comment is incorrect, as disabling the output data bus in
composite mode makes no sense. Update the comment to match the code.

While at it define macros for the MISC_CTL register bits, the code is
too confusing with numerical values.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/i2c/tvp5150.c | 24 +---
 drivers/media/i2c/tvp5150_reg.h |  9 +
 2 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index a30bfcb4eec6..8852fa8c957b 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -291,8 +291,12 @@ static void tvp5150_selmux(struct v4l2_subdev *sd)
tvp5150_write(sd, TVP5150_OP_MODE_CTL, opmode);
tvp5150_write(sd, TVP5150_VD_IN_SRC_SEL_1, input);
 
-   /* Svideo should enable YCrCb output and disable GPCL output
-* For Composite and TV, it should be the reverse
+   /*
+* Setup the FID/GLCO/VLK/HVLK and INTREQ/GPCL/VBLK output signals. For
+* S-Video we output the vertical lock (VLK) signal on FID/GLCO/VLK/HVLK
+* and set INTREQ/GPCL/VBLK to logic 0. For composite we output the
+* field indicator (FID) signal on FID/GLCO/VLK/HVLK and set
+* INTREQ/GPCL/VBLK to logic 1.
 */
val = tvp5150_read(sd, TVP5150_MISC_CTL);
if (val < 0) {
@@ -301,9 +305,9 @@ static void tvp5150_selmux(struct v4l2_subdev *sd)
}
 
if (decoder->input == TVP5150_SVIDEO)
-   val = (val & ~0x40) | 0x10;
+   val = (val & ~TVP5150_MISC_CTL_GPCL) | TVP5150_MISC_CTL_HVLK;
else
-   val = (val & ~0x10) | 0x40;
+   val = (val & ~TVP5150_MISC_CTL_HVLK) | TVP5150_MISC_CTL_GPCL;
tvp5150_write(sd, TVP5150_MISC_CTL, val);
 };
 
@@ -455,7 +459,12 @@ static const struct i2c_reg_value tvp5150_init_enable[] = {
},{ /* Automatic offset and AGC enabled */
TVP5150_ANAL_CHL_CTL, 0x15
},{ /* Activate YCrCb output 0x9 or 0xd ? */
-   TVP5150_MISC_CTL, 0x6f
+   TVP5150_MISC_CTL, TVP5150_MISC_CTL_GPCL |
+ TVP5150_MISC_CTL_INTREQ_OE |
+ TVP5150_MISC_CTL_YCBCR_OE |
+ TVP5150_MISC_CTL_SYNC_OE |
+ TVP5150_MISC_CTL_VBLANK |
+ TVP5150_MISC_CTL_CLOCK_OE,
},{ /* Activates video std autodetection for all standards */
TVP5150_AUTOSW_MSK, 0x0
},{ /* Default format: 0x47. For 4:2:2: 0x40 */
@@ -1050,11 +1059,12 @@ static int tvp5150_s_stream(struct v4l2_subdev *sd, int 
enable)
 {
struct tvp5150 *decoder = to_tvp5150(sd);
/* Output format: 8-bit ITU-R BT.656 with embedded syncs */
-   int val = 0x09;
+   int val = TVP5150_MISC_CTL_YCBCR_OE | TVP5150_MISC_CTL_CLOCK_OE;
 
/* Output format: 8-bit 4:2:2 YUV with discrete sync */
if (decoder->mbus_type == V4L2_MBUS_PARALLEL)
-   val = 0x0d;
+   val = TVP5150_MISC_CTL_YCBCR_OE | TVP5150_MISC_CTL_SYNC_OE
+   | TVP5150_MISC_CTL_CLOCK_OE;
 
/* Initializes TVP5150 to its default values */
/* # set PCLK (27MHz) */
diff --git a/drivers/media/i2c/tvp5150_reg.h b/drivers/media/i2c/tvp5150_reg.h
index 25a994944918..30a48c28d05a 100644
--- a/drivers/media/i2c/tvp5150_reg.h
+++ b/drivers/media/i2c/tvp5150_reg.h
@@ -9,6 +9,15 @@
 #define TVP5150_ANAL_CHL_CTL 0x01 /* Analog channel controls */
 #define TVP5150_OP_MODE_CTL  0x02 /* Operation mode controls */
 #define TVP5150_MISC_CTL 0x03 /* Miscellaneous controls */
+#define TVP5150_MISC_CTL_VBLK_GPCL BIT(7)
+#define TVP5150_MISC_CTL_GPCL  BIT(6)
+#define TVP5150_MISC_CTL_INTREQ_OE BIT(5)
+#define TVP5150_MISC_CTL_HVLK  BIT(4)
+#define TVP5150_MISC_CTL_YCBCR_OE  BIT(3)
+#define TVP5150_MISC_CTL_SYNC_OE   BIT(2)
+#define TVP5150_MISC_CTL_VBLANKBIT(1)
+#define TVP5150_MISC_CTL_CLOCK_OE  BIT(0)
+
 #define TVP5150_AUTOSW_MSK   0x04 /* Autoswitch mask: TVP5150A / 
TVP5150AM */
 
 /* Reserved 05h */
-- 
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 v2 4/6] v4l: tvp5150: Reset device at probe time, not in get/set format handlers

[Laurent Pinchart]

The tvp5150 doesn't support format setting through the subdev pad API
and thus implements the set format handler as a get format operation.
The single handler, tvp5150_fill_fmt(), resets the device by calling
tvp5150_reset(). This causes malfunction as the device can be reset at
will, possibly from userspace when the subdev userspace API is enabled.

The reset call was added in commit ec2c4f3f93cb ("[media] media:
tvp5150: Add mbus_fmt callbacks"), probably as an attempt to set the
device to a known state before detecting the current TV standard.
However, the get format handler doesn't access the hardware to get the
TV standard since commit 963ddc63e20d ("[media] media: tvp5150: Add
cropping support"). There is thus no need to reset the device when
getting the format.

However, removing the tvp5150_reset() from the get/set format handlers
results in the function not being called at all if the bridge driver
doesn't use the .reset() operation. The operation is nowadays abused and
shouldn't be used, so shouldn't expect bridge drivers to call it. To
make sure the device is properly initialize, move the reset call from
the format handlers to the probe function.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/i2c/tvp5150.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 3a0fe8cc64e9..a30bfcb4eec6 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -861,8 +861,6 @@ static int tvp5150_fill_fmt(struct v4l2_subdev *sd,
 
f = >format;
 
-   tvp5150_reset(sd, 0);
-
f->width = decoder->rect.width;
f->height = decoder->rect.height / 2;
 
@@ -1524,7 +1522,6 @@ static int tvp5150_probe(struct i2c_client *c,
res = core->hdl.error;
goto err;
}
-   v4l2_ctrl_handler_setup(>hdl);
 
/* Default is no cropping */
core->rect.top = 0;
@@ -1535,6 +1532,8 @@ static int tvp5150_probe(struct i2c_client *c,
core->rect.left = 0;
core->rect.width = TVP5150_H_MAX;
 
+   tvp5150_reset(sd, 0);   /* Calls v4l2_ctrl_handler_setup() */
+
res = v4l2_async_register_subdev(sd);
if (res < 0)
goto err;
-- 
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 v2 3/6] v4l: tvp5150: Add missing break in set control handler

[Laurent Pinchart]

A break is missing resulting in the hue control enabling or disabling
the decode completely. Fix it.

Fixes: c43875f66140 ("[media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a 
control")
Signed-off-by: Laurent Pinchart 
---
 drivers/media/i2c/tvp5150.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index febe6833a504..3a0fe8cc64e9 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -818,6 +818,7 @@ static int tvp5150_s_ctrl(struct v4l2_ctrl *ctrl)
return 0;
case V4L2_CID_HUE:
tvp5150_write(sd, TVP5150_HUE_CTL, ctrl->val);
+   break;
case V4L2_CID_TEST_PATTERN:
decoder->enable = ctrl->val ? false : true;
tvp5150_selmux(sd);
-- 
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 v2 6/6] v4l: tvp5150: Don't override output pinmuxing at stream on/off time

[Laurent Pinchart]

The s_stream() handler incorrectly writes the whole MISC_CTL register to
enable or disable the outputs, overriding the output pinmuxing
configuration. Fix it to only touch the output enable bits.

The CONF_SHARED_PIN register is also written by the same function,
resulting in muxing the INTREQ signal instead of the VBLK/GPCL signal on
the INTREQ/GPCL/VBLK pin. As the driver doesn't support interrupts this
is obviously incorrect, and breaks operation on other devices. Fix it by
removing the write.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/i2c/tvp5150.c | 33 +++--
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 8852fa8c957b..48646a7f3fb0 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1058,22 +1058,27 @@ static const struct media_entity_operations 
tvp5150_sd_media_ops = {
 static int tvp5150_s_stream(struct v4l2_subdev *sd, int enable)
 {
struct tvp5150 *decoder = to_tvp5150(sd);
-   /* Output format: 8-bit ITU-R BT.656 with embedded syncs */
-   int val = TVP5150_MISC_CTL_YCBCR_OE | TVP5150_MISC_CTL_CLOCK_OE;
-
-   /* Output format: 8-bit 4:2:2 YUV with discrete sync */
-   if (decoder->mbus_type == V4L2_MBUS_PARALLEL)
-   val = TVP5150_MISC_CTL_YCBCR_OE | TVP5150_MISC_CTL_SYNC_OE
-   | TVP5150_MISC_CTL_CLOCK_OE;
+   int val;
 
-   /* Initializes TVP5150 to its default values */
-   /* # set PCLK (27MHz) */
-   tvp5150_write(sd, TVP5150_CONF_SHARED_PIN, 0x00);
+   /* Enable or disable the video output signals. */
+   val = tvp5150_read(sd, TVP5150_MISC_CTL);
+   if (val < 0)
+   return val;
+
+   val &= ~(TVP5150_MISC_CTL_YCBCR_OE | TVP5150_MISC_CTL_SYNC_OE |
+TVP5150_MISC_CTL_CLOCK_OE);
+
+   if (enable) {
+   /*
+* Enable the YCbCr and clock outputs. In discrete sync mode
+* (non-BT.656) additionally enable the the sync outputs.
+*/
+   val |= TVP5150_MISC_CTL_YCBCR_OE | TVP5150_MISC_CTL_CLOCK_OE;
+   if (decoder->mbus_type == V4L2_MBUS_PARALLEL)
+   val |= TVP5150_MISC_CTL_SYNC_OE;
+   }
 
-   if (enable)
-   tvp5150_write(sd, TVP5150_MISC_CTL, val);
-   else
-   tvp5150_write(sd, TVP5150_MISC_CTL, 0x00);
+   tvp5150_write(sd, TVP5150_MISC_CTL, val);
 
return 0;
 }
-- 
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] [media] s5k4ecgx: select CRC32 helper

[Arnd Bergmann]

A rare randconfig build failure shows up in this driver when
the CRC32 helper is not there:

drivers/media/built-in.o: In function `s5k4ecgx_s_power':
s5k4ecgx.c:(.text+0x9eb4): undefined reference to `crc32_le'

This adds the 'select' that all other users of this function have.

Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/i2c/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index b31fa6fae009..b979ea148251 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -655,6 +655,7 @@ config VIDEO_S5K6A3
 config VIDEO_S5K4ECGX
 tristate "Samsung S5K4ECGX sensor support"
 depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   select CRC32
 ---help---
   This is a V4L2 sensor-level driver for Samsung S5K4ECGX 5M
   camera sensor with an embedded SoC image signal processor.
-- 
2.9.0

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

[PATCH] [v3] [media] dvb: avoid warning in dvb_net

[Arnd Bergmann]

With gcc-5 or higher on x86, we can get a bogus warning in the
dvb-net code:

drivers/media/dvb-core/dvb_net.c: In function 'dvb_net_ule':
arch/x86/include/asm/string_32.h:78:22: error: '*((void *)_addr+4)' may be 
used uninitialized in this function [-Werror=maybe-uninitialized]

The problem here is that gcc doesn't track all of the conditions
to prove it can't end up copying uninitialized data.
This changes the logic around so we zero out the destination
address earlier when we determine that it is not set here.
This allows the compiler to figure it out.

Signed-off-by: Arnd Bergmann 
---
When I got the same warning earlier, Mauro created commit 8b0041db80dd
("[media] dvb-net: split the logic at dvb_net_ule() into other
functions") to clean up the code, and that addressed all the warnings
I saw earlier, but I now got a different randconfig build that
needs either this patch or Mauro's variant "dvb_net: simplify
the logic that fills the ethernet address" that does the same
change slightly differently.
---
 drivers/media/dvb-core/dvb_net.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c
index dfc03a95df71..f06e0488aa2c 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -719,6 +719,9 @@ static void dvb_net_ule_check_crc(struct dvb_net_ule_handle 
*h,
skb_copy_from_linear_data(h->priv->ule_skb, dest_addr,
  ETH_ALEN);
skb_pull(h->priv->ule_skb, ETH_ALEN);
+   } else {
+   /* dest_addr buffer is only valid if h->priv->ule_dbit == 0 */
+   eth_zero_addr(dest_addr);
}
 
/* Handle ULE Extension Headers. */
@@ -750,16 +753,8 @@ static void dvb_net_ule_check_crc(struct 
dvb_net_ule_handle *h,
if (!h->priv->ule_bridged) {
skb_push(h->priv->ule_skb, ETH_HLEN);
h->ethh = (struct ethhdr *)h->priv->ule_skb->data;
-   if (!h->priv->ule_dbit) {
-   /*
-* dest_addr buffer is only valid if
-* h->priv->ule_dbit == 0
-*/
-   memcpy(h->ethh->h_dest, dest_addr, ETH_ALEN);
-   eth_zero_addr(h->ethh->h_source);
-   } else /* zeroize source and dest */
-   memset(h->ethh, 0, ETH_ALEN * 2);
-
+   memcpy(h->ethh->h_dest, dest_addr, ETH_ALEN);
+   eth_zero_addr(h->ethh->h_source);
h->ethh->h_proto = htons(h->priv->ule_sndu_type);
}
/* else:  skb is in correct state; nothing to do. */
-- 
2.9.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

Re: [PATCH 3/4] si2157: Si2141/2151 tuner support.

[Antti Palosaari]

On 12/09/2016 02:19 AM, CrazyCat wrote:

Support for new tuner version.

Signed-off-by: CrazyCat 
---
 drivers/media/tuners/si2157.c  | 71 ++
 drivers/media/tuners/si2157_priv.h |  2 ++
 2 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 57b2508..69fd21e 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -1,5 +1,5 @@
 /*
- * Silicon Labs Si2146/2147/2148/2157/2158 silicon tuner driver
+ * Silicon Labs Si2141/2146/2147/2148/2151/2157/2158 silicon tuner driver
  *
  * Copyright (C) 2014 Antti Palosaari 
  *
@@ -84,7 +84,7 @@ static int si2157_init(struct dvb_frontend *fe)
struct si2157_cmd cmd;
const struct firmware *fw;
const char *fw_name;
-   unsigned int uitmp, chip_id;
+   unsigned int uitmp, chip_id, count;

dev_dbg(>dev, "\n");

@@ -102,14 +102,46 @@ static int si2157_init(struct dvb_frontend *fe)
if (uitmp == dev->if_frequency / 1000)
goto warm;

+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   count = 0;
+   do {
+   if (count > 10)
+   goto err;
+
+   /* reset */
+   memcpy(cmd.args, "\xc0\x05\x00\x00", 4);
+   cmd.wlen = 4;
+   cmd.rlen = 1;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+
+   memcpy(cmd.args, 
"\xc0\x00\x0d\x0e\x00\x01\x01\x01\x01\x03", 10);
+   cmd.wlen = 10;
+   cmd.rlen = 1;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+   count++;
+   } while (cmd.args[0] == 0xfe);
+   dev_info(>dev, "Si2141/2151 reset attempts %d\n", 
count);
+   }


Without any comment or description you added this kind of hackish 
looking thing? What it is, why it is needed, what happens without it?


Also, it is just N-times loop with exit condition => you should use 
typical for-looping with break as usual.




+
/* power up */
-   if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
+   switch (dev->chiptype) {
+   case SI2157_CHIPTYPE_SI2146:
memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
cmd.wlen = 9;
-   } else {
+   break;
+   case SI2157_CHIPTYPE_SI2141:
+   memcpy(cmd.args, "\xc0\x08\x01\x02\x00\x08\x01", 7);
+   cmd.wlen = 7;
+   break;
+   default:
memcpy(cmd.args, 
"\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01", 15);
cmd.wlen = 15;
}
+
cmd.rlen = 1;
ret = si2157_cmd_execute(client, );
if (ret)
@@ -131,6 +163,8 @@ static int si2157_init(struct dvb_frontend *fe)
#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
#define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
+   #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
+   #define SI2151_A10 ('A' << 24 | 51 << 16 | '1' << 8 | '0' << 0)

switch (chip_id) {
case SI2158_A20:
@@ -142,6 +176,10 @@ static int si2157_init(struct dvb_frontend *fe)
case SI2146_A10:
fw_name = NULL;
break;
+   case SI2141_A10:
+   case SI2151_A10:
+   fw_name = SI2141_A10_FIRMWARE;
+   break;
default:
dev_err(>dev, "unknown chip version Si21%d-%c%c%c\n",
cmd.args[2], cmd.args[1],
@@ -214,6 +252,23 @@ static int si2157_init(struct dvb_frontend *fe)

dev_info(>dev, "firmware version: %c.%c.%d\n",
cmd.args[6], cmd.args[7], cmd.args[8]);
+
+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   /* set clock */
+   memcpy(cmd.args, "\xc0\x00\x0d", 3);
+   cmd.wlen = 3;
+   cmd.rlen = 1;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+   /* setup PIN */
+   memcpy(cmd.args, "\x12\x80\x80\x85\x00\x81\x00", 7);
+   cmd.wlen = 7;
+   cmd.rlen = 7;
+   ret = si2157_cmd_execute(client, );
+   if (ret)
+   goto err;
+   }


These are also without almost any comment... First one seems to enable 
clock output and second one is GPIO? Tuner clock output is to feed clock 
for demod most likely. You do that same on init. Why?


You should implement kernel gpio and probably kernel common clock in 

Re: [PATCH v6 2/5] [media] davinci: vpif_capture: remove hard-coded I2C adapter id

[Sakari Ailus]

Hi Kevin,

On Wed, Dec 07, 2016 at 10:30:22AM -0800, Kevin Hilman wrote:
> Remove hard-coded I2C adapter in favor of getting the
> ID from platform_data.
> 
> Signed-off-by: Kevin Hilman 
> ---
>  drivers/media/platform/davinci/vpif_capture.c | 5 -
>  include/media/davinci/vpif_types.h| 1 +
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/davinci/vpif_capture.c 
> b/drivers/media/platform/davinci/vpif_capture.c
> index 20c4344ed118..c24049acd40a 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -1486,7 +1486,10 @@ static __init int vpif_probe(struct platform_device 
> *pdev)
>   }
>  
>   if (!vpif_obj.config->asd_sizes) {
> - i2c_adap = i2c_get_adapter(1);
> + int i2c_id = vpif_obj.config->i2c_adapter_id;

Is there a particular reason to use a temporary variable just once? I'd use
the i2c_adapter_field directly instead. Up to you.

Acked-by: Sakari Ailus 

> +
> + i2c_adap = i2c_get_adapter(i2c_id);
> + WARN_ON(!i2c_adap);
>   for (i = 0; i < subdev_count; i++) {
>   subdevdata = _obj.config->subdev_info[i];
>   vpif_obj.sd[i] =
> diff --git a/include/media/davinci/vpif_types.h 
> b/include/media/davinci/vpif_types.h
> index 3cb1704a0650..4282a7db99d4 100644
> --- a/include/media/davinci/vpif_types.h
> +++ b/include/media/davinci/vpif_types.h
> @@ -82,6 +82,7 @@ struct vpif_capture_config {
>   struct vpif_capture_chan_config chan_config[VPIF_CAPTURE_MAX_CHANNELS];
>   struct vpif_subdev_info *subdev_info;
>   int subdev_count;
> + int i2c_adapter_id;
>   const char *card_name;
>   struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
>   int *asd_sizes; /* 0-terminated array of asd group sizes */

-- 
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 0/6] Fix tvp5150 regression with em28xx

[Mauro Carvalho Chehab]

Em Fri,  9 Dec 2016 00:22:40 +0200
Laurent Pinchart  escreveu:

> Hello,
> 
> This patch series fixes a regression reported by Devin Heitmueller that
> affects a large number of em28xx. The problem was introduced by
> 
> commit 13d52fe40f1f7bbad49128e8ee6a2fe5e13dd18d
> Author: Mauro Carvalho Chehab 
> Date:   Tue Jan 26 06:59:39 2016 -0200
> 
> [media] em28xx: fix implementation of s_stream
> 
> that started calling s_stream(1) in the em28xx driver when enabling the
> stream, resulting in the tvp5150 s_stream() operation writing several
> registers with values fit for other platforms (namely OMAP3, possibly others)
> but not for em28xx.
> 
> The series starts with two unrelated drive-by cleanups and an unrelated bug
> fix. It then continues with a patch to remove an unneeded and armful call to
> tvp5150_reset() when getting the format from the subdevice (4/6), an update of
> an invalid comment and the addition of macros for register bits in order to
> make the code more readable (5/6) and actually allow following the incorrect
> code flow, and finally a rework of the s_stream() operation to fix the
> problem.
> 
> I haven't been able to test this with an em28xx device as I don't own any. I
> would appreciate if someone could give the series a go.
> 
> Laurent Pinchart (6):
>   v4l: tvp5150: Compile tvp5150_link_setup out if
> !CONFIG_MEDIA_CONTROLLER
>   v4l: tvp5150: Don't inline the tvp5150_selmux() function
>   v4l: tvp5150: Add missing break in set control handler
>   v4l: tvp5150: Don't reset device in get/set format handlers
>   v4l: tvp5150: Fix comment regarding output pin muxing
>   v4l: tvp5150: Don't override output pinmuxing at stream on/off time

Tested here with an interlaced video input on S-Video and/or Composite
entries of HVR-950:

It broke Composite selection. After this series, only S-Video input works.

VBI was not affected.

Regards,
Mauro
--
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 v6 1/5] [media] davinci: VPIF: fix module loading, init errors

[Sakari Ailus]

On Wed, Dec 07, 2016 at 10:30:21AM -0800, Kevin Hilman wrote:
> Fix problems with automatic module loading by adding MODULE_ALIAS.  Also
> fix various load-time errors cause by incorrect or not present
> platform_data.

Acked-by: Sakari Ailus 

-- 
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: uvcvideo logging kernel warnings on device disconnect

[Greg KH]

On Fri, Dec 09, 2016 at 11:14:41AM +0200, Laurent Pinchart wrote:
> Hi Greg,
> 
> On Friday 09 Dec 2016 10:11:13 Greg KH wrote:
> > On Fri, Dec 09, 2016 at 10:59:24AM +0200, Laurent Pinchart wrote:
> > > On Friday 09 Dec 2016 08:25:52 Greg KH wrote:
> > >> On Fri, Dec 09, 2016 at 01:09:21AM +0200, Laurent Pinchart wrote:
> > >>> On Thursday 08 Dec 2016 12:31:55 Dave Stevenson wrote:
> >  Hi All.
> >  
> >  I'm working with a USB webcam which has been seen to spontaneously
> >  disconnect when in use. That's a separate issue, but when it does it
> >  throws a load of warnings into the kernel log if there is a file
> >  handle on the device open at the time, even if not streaming.
> >  
> >  I've reproduced this with a generic Logitech C270 webcam on:
> >  - Ubuntu 16.04 (kernel 4.4.0-51) vanilla, and with the latest media
> >  tree from linuxtv.org
> >  - Ubuntu 14.04 (kernel 4.4.0-42) vanilla
> >  - an old 3.10.x tree on an embedded device.
> >  
> >  To reproduce:
> >  - connect USB webcam.
> >  - run a simple app that opens /dev/videoX, sleeps for a while, and
> >  then closes the handle.
> >  - disconnect the webcam whilst the app is running.
> >  - read kernel logs - observe warnings. We get the disconnect logged
> >  as it occurs, but the warnings all occur when the file descriptor is
> >  closed. (A copy of the logs from my Ubuntu 14.04 machine are below).
> >  
> >  I can fully appreciate that the open file descriptor is holding
> >  references to a now invalid device, but is there a way to avoid them?
> >  Or do we really not care and have to put up with the log noise when
> >  doing such silly things?
> > >>> 
> > >>> This is a known problem, caused by the driver core trying to remove
> > >>> the same sysfs attributes group twice.
> > >> 
> > >> Ick, not good.
> > >> 
> > >>> The group is first removed when the USB device is disconnected. The
> > >>> input device and media device created by the uvcvideo driver are
> > >>> children of the USB interface device, which is deleted from the system
> > >>> when the camera is unplugged. Due to the parent-child relationship,
> > >>> all sysfs attribute groups of the children are removed.
> > >> 
> > >> Wait, why is the USB device being removed from sysfs at this point,
> > >> didn't the input and media subsystems grab a reference to it so that it
> > >> does not disappear just yet?
> > > 
> > > References are taken in uvc_prove():
> > > dev->udev = usb_get_dev(udev);
> > > dev->intf = usb_get_intf(intf);
> > 
> > s/uvc_prove/uvc_probe/ ?  :)
> 
> Oops :-)
> 
> > > and released in uvc_delete(), called when the last video device node is
> > > closed. This prevents the device from being released (freed), but
> > > device_del() is synchronous to device unplug as far as I understand.
> > 
> > Ok, good, that means the UVC driver is doing the right thing here.
> > 
> > But the sysfs files should only be attempted to be removed by the driver
> > core once, when the device is removed from sysfs, not twice, which is
> > really odd.
> > 
> > Is there a copy of the "simple app that grabs the device node" anywhere
> > so that I can test it out here with my USB camera device to try to track
> > down where the problem is?
> 
> Sure. The easiest way is to grab http://git.ideasonboard.org/yavta.git and run
> 
> yavta -c /dev/video0
> 
> (your mileage may vary if you have other video devices)

I'll point it at the correct device, /dev/video0 is built into this
laptop and can't be physically removed :)

> While the application is running, unplug the webcam, and then terminate the 
> application with ctrl-C.

Ok, will try this out this afternoon and let you know how it goes.

thanks,

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

Re: uvcvideo logging kernel warnings on device disconnect

[Laurent Pinchart]

Hi Greg,

On Friday 09 Dec 2016 10:11:13 Greg KH wrote:
> On Fri, Dec 09, 2016 at 10:59:24AM +0200, Laurent Pinchart wrote:
> > On Friday 09 Dec 2016 08:25:52 Greg KH wrote:
> >> On Fri, Dec 09, 2016 at 01:09:21AM +0200, Laurent Pinchart wrote:
> >>> On Thursday 08 Dec 2016 12:31:55 Dave Stevenson wrote:
>  Hi All.
>  
>  I'm working with a USB webcam which has been seen to spontaneously
>  disconnect when in use. That's a separate issue, but when it does it
>  throws a load of warnings into the kernel log if there is a file
>  handle on the device open at the time, even if not streaming.
>  
>  I've reproduced this with a generic Logitech C270 webcam on:
>  - Ubuntu 16.04 (kernel 4.4.0-51) vanilla, and with the latest media
>  tree from linuxtv.org
>  - Ubuntu 14.04 (kernel 4.4.0-42) vanilla
>  - an old 3.10.x tree on an embedded device.
>  
>  To reproduce:
>  - connect USB webcam.
>  - run a simple app that opens /dev/videoX, sleeps for a while, and
>  then closes the handle.
>  - disconnect the webcam whilst the app is running.
>  - read kernel logs - observe warnings. We get the disconnect logged
>  as it occurs, but the warnings all occur when the file descriptor is
>  closed. (A copy of the logs from my Ubuntu 14.04 machine are below).
>  
>  I can fully appreciate that the open file descriptor is holding
>  references to a now invalid device, but is there a way to avoid them?
>  Or do we really not care and have to put up with the log noise when
>  doing such silly things?
> >>> 
> >>> This is a known problem, caused by the driver core trying to remove
> >>> the same sysfs attributes group twice.
> >> 
> >> Ick, not good.
> >> 
> >>> The group is first removed when the USB device is disconnected. The
> >>> input device and media device created by the uvcvideo driver are
> >>> children of the USB interface device, which is deleted from the system
> >>> when the camera is unplugged. Due to the parent-child relationship,
> >>> all sysfs attribute groups of the children are removed.
> >> 
> >> Wait, why is the USB device being removed from sysfs at this point,
> >> didn't the input and media subsystems grab a reference to it so that it
> >> does not disappear just yet?
> > 
> > References are taken in uvc_prove():
> > dev->udev = usb_get_dev(udev);
> > dev->intf = usb_get_intf(intf);
> 
> s/uvc_prove/uvc_probe/ ?  :)

Oops :-)

> > and released in uvc_delete(), called when the last video device node is
> > closed. This prevents the device from being released (freed), but
> > device_del() is synchronous to device unplug as far as I understand.
> 
> Ok, good, that means the UVC driver is doing the right thing here.
> 
> But the sysfs files should only be attempted to be removed by the driver
> core once, when the device is removed from sysfs, not twice, which is
> really odd.
> 
> Is there a copy of the "simple app that grabs the device node" anywhere
> so that I can test it out here with my USB camera device to try to track
> down where the problem is?

Sure. The easiest way is to grab http://git.ideasonboard.org/yavta.git and run

yavta -c /dev/video0

(your mileage may vary if you have other video devices)

While the application is running, unplug the webcam, and then terminate the 
application with ctrl-C.

-- 
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: uvcvideo logging kernel warnings on device disconnect

[Greg KH]

On Fri, Dec 09, 2016 at 10:59:24AM +0200, Laurent Pinchart wrote:
> Hi Greg,
> 
> On Friday 09 Dec 2016 08:25:52 Greg KH wrote:
> > On Fri, Dec 09, 2016 at 01:09:21AM +0200, Laurent Pinchart wrote:
> > > On Thursday 08 Dec 2016 12:31:55 Dave Stevenson wrote:
> > >> Hi All.
> > >> 
> > >> I'm working with a USB webcam which has been seen to spontaneously
> > >> disconnect when in use. That's a separate issue, but when it does it
> > >> throws a load of warnings into the kernel log if there is a file handle
> > >> on the device open at the time, even if not streaming.
> > >> 
> > >> I've reproduced this with a generic Logitech C270 webcam on:
> > >> - Ubuntu 16.04 (kernel 4.4.0-51) vanilla, and with the latest media tree
> > >> from linuxtv.org
> > >> - Ubuntu 14.04 (kernel 4.4.0-42) vanilla
> > >> - an old 3.10.x tree on an embedded device.
> > >> 
> > >> To reproduce:
> > >> - connect USB webcam.
> > >> - run a simple app that opens /dev/videoX, sleeps for a while, and then
> > >> closes the handle.
> > >> - disconnect the webcam whilst the app is running.
> > >> - read kernel logs - observe warnings. We get the disconnect logged as
> > >> it occurs, but the warnings all occur when the file descriptor is
> > >> closed. (A copy of the logs from my Ubuntu 14.04 machine are below).
> > >> 
> > >> I can fully appreciate that the open file descriptor is holding
> > >> references to a now invalid device, but is there a way to avoid them? Or
> > >> do we really not care and have to put up with the log noise when doing
> > >> such silly things?
> > > 
> > > This is a known problem, caused by the driver core trying to remove the
> > > same sysfs attributes group twice.
> > 
> > Ick, not good.
> > 
> > > The group is first removed when the USB device is disconnected. The input
> > > device and media device created by the uvcvideo driver are children of the
> > > USB interface device, which is deleted from the system when the camera is
> > > unplugged. Due to the parent-child relationship, all sysfs attribute
> > > groups of the children are removed.
> > 
> > Wait, why is the USB device being removed from sysfs at this point,
> > didn't the input and media subsystems grab a reference to it so that it
> > does not disappear just yet?
> 
> References are taken in uvc_prove():
> 
> dev->udev = usb_get_dev(udev);
> dev->intf = usb_get_intf(intf);

s/uvc_prove/uvc_probe/ ?  :)

> 
> and released in uvc_delete(), called when the last video device node is 
> closed. This prevents the device from being released (freed), but 
> device_del() 
> is synchronous to device unplug as far as I understand.

Ok, good, that means the UVC driver is doing the right thing here.

But the sysfs files should only be attempted to be removed by the driver
core once, when the device is removed from sysfs, not twice, which is
really odd.

Is there a copy of the "simple app that grabs the device node" anywhere
so that I can test it out here with my USB camera device to try to track
down where the problem is?

thanks,

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

Re: uvcvideo logging kernel warnings on device disconnect

[Laurent Pinchart]

Hi Greg,

On Friday 09 Dec 2016 08:25:52 Greg KH wrote:
> On Fri, Dec 09, 2016 at 01:09:21AM +0200, Laurent Pinchart wrote:
> > On Thursday 08 Dec 2016 12:31:55 Dave Stevenson wrote:
> >> Hi All.
> >> 
> >> I'm working with a USB webcam which has been seen to spontaneously
> >> disconnect when in use. That's a separate issue, but when it does it
> >> throws a load of warnings into the kernel log if there is a file handle
> >> on the device open at the time, even if not streaming.
> >> 
> >> I've reproduced this with a generic Logitech C270 webcam on:
> >> - Ubuntu 16.04 (kernel 4.4.0-51) vanilla, and with the latest media tree
> >> from linuxtv.org
> >> - Ubuntu 14.04 (kernel 4.4.0-42) vanilla
> >> - an old 3.10.x tree on an embedded device.
> >> 
> >> To reproduce:
> >> - connect USB webcam.
> >> - run a simple app that opens /dev/videoX, sleeps for a while, and then
> >> closes the handle.
> >> - disconnect the webcam whilst the app is running.
> >> - read kernel logs - observe warnings. We get the disconnect logged as
> >> it occurs, but the warnings all occur when the file descriptor is
> >> closed. (A copy of the logs from my Ubuntu 14.04 machine are below).
> >> 
> >> I can fully appreciate that the open file descriptor is holding
> >> references to a now invalid device, but is there a way to avoid them? Or
> >> do we really not care and have to put up with the log noise when doing
> >> such silly things?
> > 
> > This is a known problem, caused by the driver core trying to remove the
> > same sysfs attributes group twice.
> 
> Ick, not good.
> 
> > The group is first removed when the USB device is disconnected. The input
> > device and media device created by the uvcvideo driver are children of the
> > USB interface device, which is deleted from the system when the camera is
> > unplugged. Due to the parent-child relationship, all sysfs attribute
> > groups of the children are removed.
> 
> Wait, why is the USB device being removed from sysfs at this point,
> didn't the input and media subsystems grab a reference to it so that it
> does not disappear just yet?

References are taken in uvc_prove():

dev->udev = usb_get_dev(udev);
dev->intf = usb_get_intf(intf);

and released in uvc_delete(), called when the last video device node is 
closed. This prevents the device from being released (freed), but device_del() 
is synchronous to device unplug as far as I understand.

> > Then, when the device node is closed, the media device and input device
> > are unregistered, causing the corresponding devices to be deleted too. The
> > driver core tries to remove the sysfs attributes groups related to those
> > devices, and issues a warning as they have been removed already.
> > 
> > I'm not sure how to fix that, any hint from LKML would be appreciated.
> 
> Properly grab a reference to the USB device?  :)
> 
> If that's already happening, please let me know and I'll see what needs
> to be done, but I think that should solve the issue for 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