cron job: media_tree daily build: OK

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Thu May  3 05:00:11 CEST 2018
media-tree git hash:a2b2eff6ac2716f499defa590a6ec4ba379d765e
media_build git hash:   2945d108c680b3c09c9843e001e84a9797d7f379
v4l-utils git hash: 03e763fd4b361b2082019032fc315b7606669335
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: 0.5.2-RC1
smatch version: 0.5.1
host hardware:  x86_64
host os:4.15.0-3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-i686: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-i686: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-i686: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.101-i686: OK
linux-3.0.101-x86_64: OK
linux-3.1.10-i686: OK
linux-3.1.10-x86_64: OK
linux-3.2.101-i686: OK
linux-3.2.101-x86_64: OK
linux-3.3.8-i686: OK
linux-3.3.8-x86_64: OK
linux-3.4.113-i686: OK
linux-3.4.113-x86_64: OK
linux-3.5.7-i686: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-i686: OK
linux-3.6.11-x86_64: OK
linux-3.7.10-i686: OK
linux-3.7.10-x86_64: OK
linux-3.8.13-i686: OK
linux-3.8.13-x86_64: OK
linux-3.9.11-i686: OK
linux-3.9.11-x86_64: OK
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.56-i686: OK
linux-3.16.56-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.102-i686: OK
linux-3.18.102-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.51-i686: OK
linux-4.1.51-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.109-i686: OK
linux-4.4.109-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.91-i686: OK
linux-4.9.91-x86_64: OK
linux-4.14.31-i686: OK
linux-4.14.31-x86_64: OK
linux-4.15.14-i686: OK
linux-4.15.14-x86_64: OK
linux-4.16-i686: OK
linux-4.16-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: [PATCH v2 10/15] ARM: dts: imx7s: add multiplexer controls

[Shawn Guo]

On Mon, Apr 23, 2018 at 02:47:45PM +0100, Rui Miguel Silva wrote:
> The IOMUXC General Purpose Register has bitfield to control video bus
> multiplexer to control the CSI input between the MIPI-CSI2 and parallel
> interface. Add that register and mask.
> 
> Signed-off-by: Rui Miguel Silva 
> ---
>  arch/arm/boot/dts/imx7s.dtsi | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index d913c3f9c284..3027d6a62021 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -534,8 +534,15 @@
>  
>   gpr: iomuxc-gpr@3034 {
>   compatible = "fsl,imx7d-iomuxc-gpr",
> - "fsl,imx6q-iomuxc-gpr", "syscon";
> + "fsl,imx6q-iomuxc-gpr", "syscon", 
> "simple-mfd";
>   reg = <0x3034 0x1>;
> +
> + mux: mux-controller {
> + compatible = "mmio-mux";
> + #mux-control-cells = <1>;
> +

The newline in between property list is not really necessary.

Shawn

> + mux-reg-masks = <0x14 0x0010>;
> + };
>   };
>  
>   ocotp: ocotp-ctrl@3035 {
> -- 
> 2.17.0
> 

[PATCH v5 6/8] v4l: xilinx: dma: Add multi-planar support

[Satish Kumar Nagireddy]

The current v4l driver supports single plane formats. This patch
adds support to handle multi-planar formats. Driver can handle
both single and multi-planar formats.

Signed-off-by: Satish Kumar Nagireddy 
---
Changes in v5:
 - Added default height
 - Corrected sizeimage declaration with u32

Changes in v4:
 - Single plane implementation is removed as multi-plane supports both
 - num_buffers and bpl_factor parameters are removed to have clean
   implementation

 drivers/media/platform/xilinx/xilinx-dma.c  | 150 +---
 drivers/media/platform/xilinx/xilinx-dma.h  |   4 +-
 drivers/media/platform/xilinx/xilinx-vipp.c |  16 +--
 3 files changed, 104 insertions(+), 66 deletions(-)

diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
b/drivers/media/platform/xilinx/xilinx-dma.c
index 518d572..2ffc276 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -74,8 +74,8 @@ static int xvip_dma_verify_format(struct xvip_dma *dma)
return ret == -ENOIOCTLCMD ? -EINVAL : ret;
 
if (dma->fmtinfo->code != fmt.format.code ||
-   dma->format.height != fmt.format.height ||
-   dma->format.width != fmt.format.width)
+   dma->format.fmt.pix_mp.width != fmt.format.width ||
+   dma->format.fmt.pix_mp.height != fmt.format.height)
return -EINVAL;
 
return 0;
@@ -310,7 +310,8 @@ static void xvip_dma_complete(void *param)
buf->buf.field = V4L2_FIELD_NONE;
buf->buf.sequence = dma->sequence++;
buf->buf.vb2_buf.timestamp = ktime_get_ns();
-   vb2_set_plane_payload(>buf.vb2_buf, 0, dma->format.sizeimage);
+   vb2_set_plane_payload(>buf.vb2_buf, 0,
+ dma->format.fmt.pix_mp.plane_fmt[0].sizeimage);
vb2_buffer_done(>buf.vb2_buf, VB2_BUF_STATE_DONE);
 }
 
@@ -320,13 +321,15 @@ xvip_dma_queue_setup(struct vb2_queue *vq,
 unsigned int sizes[], struct device *alloc_devs[])
 {
struct xvip_dma *dma = vb2_get_drv_priv(vq);
+   u32 sizeimage;
 
/* Make sure the image size is large enough. */
+   sizeimage = dma->format.fmt.pix_mp.plane_fmt[0].sizeimage;
if (*nplanes)
-   return sizes[0] < dma->format.sizeimage ? -EINVAL : 0;
+   return sizes[0] < sizeimage ? -EINVAL : 0;
 
*nplanes = 1;
-   sizes[0] = dma->format.sizeimage;
+   sizes[0] = sizeimage;
 
return 0;
 }
@@ -350,8 +353,9 @@ static void xvip_dma_buffer_queue(struct vb2_buffer *vb)
struct dma_async_tx_descriptor *desc;
dma_addr_t addr = vb2_dma_contig_plane_dma_addr(vb, 0);
u32 flags;
+   struct v4l2_pix_format_mplane *pix_mp = >format.fmt.pix_mp;
 
-   if (dma->queue.type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+   if (dma->queue.type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
flags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK;
dma->xt.dir = DMA_DEV_TO_MEM;
dma->xt.src_sgl = false;
@@ -365,10 +369,11 @@ static void xvip_dma_buffer_queue(struct vb2_buffer *vb)
dma->xt.src_start = addr;
}
 
-   dma->xt.frame_size = 1;
-   dma->sgl[0].size = dma->format.width * dma->fmtinfo->bpp[0];
-   dma->sgl[0].icg = dma->format.bytesperline - dma->sgl[0].size;
-   dma->xt.numf = dma->format.height;
+   dma->xt.frame_size = dma->fmtinfo->num_planes;
+   dma->sgl[0].size = pix_mp->width * dma->fmtinfo->bpp[0];
+   dma->sgl[0].icg = pix_mp->plane_fmt[0].bytesperline - dma->sgl[0].size;
+   dma->xt.numf = pix_mp->height;
+   dma->sgl[0].dst_icg = 0;
 
desc = dmaengine_prep_interleaved_dma(dma->dma, >xt, flags);
if (!desc) {
@@ -496,11 +501,12 @@ xvip_dma_querycap(struct file *file, void *fh, struct 
v4l2_capability *cap)
 
cap->capabilities = V4L2_CAP_DEVICE_CAPS | V4L2_CAP_STREAMING
  | dma->xdev->v4l2_caps;
+   cap->device_caps = V4L2_CAP_STREAMING;
 
-   if (dma->queue.type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
-   cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+   if (dma->queue.type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+   cap->device_caps |= V4L2_CAP_VIDEO_CAPTURE_MPLANE;
else
-   cap->device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
+   cap->device_caps |= V4L2_CAP_VIDEO_OUTPUT_MPLANE;
 
strlcpy(cap->driver, "xilinx-vipp", sizeof(cap->driver));
strlcpy(cap->card, dma->video.name, sizeof(cap->card));
@@ -524,7 +530,7 @@ xvip_dma_enum_format(struct file *file, void *fh, struct 
v4l2_fmtdesc *f)
if (f->index > 0)
return -EINVAL;
 
-   f->pixelformat = dma->format.pixelformat;
+   f->pixelformat = dma->format.fmt.pix_mp.pixelformat;
strlcpy(f->description, dma->fmtinfo->description,
sizeof(f->description));
 
@@ 

[PATCH v5 3/8] xilinx: v4l: dma: Terminate DMA when media pipeline fail to start

[Satish Kumar Nagireddy]

From: Vishal Sagar 

If an incorrectly configured media pipeline is started, the allocated
dma descriptors aren't freed. This leads to kernel oops when pipeline
is configured correctly and run subsequently.

This patch also replaces dmaengine_terminate_all() with
dmaengine_terminate_sync() as the former one is deprecated.

Signed-off-by: Vishal Sagar 
Signed-off-by: Satish Kumar Nagireddy 
---
 drivers/media/platform/xilinx/xilinx-dma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
b/drivers/media/platform/xilinx/xilinx-dma.c
index 5426efe..727dc6e 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -437,6 +437,7 @@ static int xvip_dma_start_streaming(struct vb2_queue *vq, 
unsigned int count)
media_pipeline_stop(>video.entity);
 
 error:
+   dmaengine_terminate_sync(dma->dma);
/* Give back all queued buffers to videobuf2. */
spin_lock_irq(>queued_lock);
list_for_each_entry_safe(buf, nbuf, >queued_bufs, queue) {
@@ -458,7 +459,7 @@ static void xvip_dma_stop_streaming(struct vb2_queue *vq)
xvip_pipeline_set_stream(pipe, false);
 
/* Stop and reset the DMA engine. */
-   dmaengine_terminate_all(dma->dma);
+   dmaengine_terminate_sync(dma->dma);
 
/* Cleanup the pipeline and mark it as being stopped. */
xvip_pipeline_cleanup(pipe);
-- 
2.7.4

[PATCH v5 1/8] v4l: xilinx: dma: Remove colorspace check in xvip_dma_verify_format

[Satish Kumar Nagireddy]

From: Radhey Shyam Pandey 

In current implementation driver only checks the colorspace
between the last subdev in the pipeline and the connected video node,
the pipeline could be configured with wrong colorspace information
until the very end. It thus makes little sense to check the
colorspace only at the video node. So check can be dropped until
we find a better solution to carry colorspace information
through pipelines and to userspace.

Signed-off-by: Radhey Shyam Pandey 
Signed-off-by: Satish Kumar Nagireddy 
---
 drivers/media/platform/xilinx/xilinx-dma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
b/drivers/media/platform/xilinx/xilinx-dma.c
index 522cdfd..cb20ada 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -75,8 +75,7 @@ static int xvip_dma_verify_format(struct xvip_dma *dma)
 
if (dma->fmtinfo->code != fmt.format.code ||
dma->format.height != fmt.format.height ||
-   dma->format.width != fmt.format.width ||
-   dma->format.colorspace != fmt.format.colorspace)
+   dma->format.width != fmt.format.width)
return -EINVAL;
 
return 0;
-- 
2.7.4

[PATCH v5 8/8] v4l: xilinx: dma: Add support for 10 bit formats

[Satish Kumar Nagireddy]

This patch adds xvip_format_plane_width_bytes function to
calculate number of bytes for a macropixel formats and also
adds new 10 bit pixel formats to video descriptor table.

Signed-off-by: Satish Kumar Nagireddy 
---
Changes in v4:
 - Introduced macropixel concept to calculate bytes for a given width for 10 
bit formats

 drivers/media/platform/xilinx/xilinx-dma.c |  5 ++--
 drivers/media/platform/xilinx/xilinx-vip.c | 37 ++
 drivers/media/platform/xilinx/xilinx-vip.h |  5 
 3 files changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
b/drivers/media/platform/xilinx/xilinx-dma.c
index 2ffc276..89afa24 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -370,7 +370,8 @@ static void xvip_dma_buffer_queue(struct vb2_buffer *vb)
}
 
dma->xt.frame_size = dma->fmtinfo->num_planes;
-   dma->sgl[0].size = pix_mp->width * dma->fmtinfo->bpp[0];
+   dma->sgl[0].size = xvip_fmt_plane_width_bytes(dma->fmtinfo,
+ pix_mp->width);
dma->sgl[0].icg = pix_mp->plane_fmt[0].bytesperline - dma->sgl[0].size;
dma->xt.numf = pix_mp->height;
dma->sgl[0].dst_icg = 0;
@@ -591,7 +592,7 @@ __xvip_dma_try_format(struct xvip_dma *dma,
 * with the minimum in that case.
 */
max_bpl = rounddown(XVIP_DMA_MAX_WIDTH, align);
-   min_bpl = pix_mp->width * info->bpp[0];
+   min_bpl = xvip_fmt_plane_width_bytes(info, pix_mp->width);
min_bpl = roundup(min_bpl, align);
bpl = roundup(plane_fmt[0].bytesperline, align);
plane_fmt[0].bytesperline = clamp(bpl, min_bpl, max_bpl);
diff --git a/drivers/media/platform/xilinx/xilinx-vip.c 
b/drivers/media/platform/xilinx/xilinx-vip.c
index fb1a08f..7569f05 100644
--- a/drivers/media/platform/xilinx/xilinx-vip.c
+++ b/drivers/media/platform/xilinx/xilinx-vip.c
@@ -28,23 +28,25 @@
 
 static const struct xvip_video_format xvip_video_formats[] = {
{ XVIP_VF_YUV_420, 8, NULL, MEDIA_BUS_FMT_VYYUYY8_1X24,
- {1, 2, 0}, V4L2_PIX_FMT_NV12, 2, 2, 2, "4:2:0, semi-planar, YUV" },
+ {1, 2, 0}, V4L2_PIX_FMT_NV12, 2, 2, 2, 1, 1, "4:2:0, semi-planar, 
YUV" },
{ XVIP_VF_YUV_422, 8, NULL, MEDIA_BUS_FMT_UYVY8_1X16,
- {2, 0, 0}, V4L2_PIX_FMT_YUYV, 1, 2, 1, "4:2:2, packed, YUYV" },
+ {2, 0, 0}, V4L2_PIX_FMT_YUYV, 1, 2, 1, 1, 1, "4:2:2, packed, YUYV" },
{ XVIP_VF_YUV_444, 8, NULL, MEDIA_BUS_FMT_VUY8_1X24,
- {3, 0, 0}, V4L2_PIX_FMT_YUV444, 1, 1, 1, "4:4:4, packed, YUYV" },
+ {3, 0, 0}, V4L2_PIX_FMT_YUV444, 1, 1, 1, 1, 1, "4:4:4, packed, YUYV" 
},
+   { XVIP_VF_YUV_420, 10, NULL, MEDIA_BUS_FMT_VYYUYY8_1X24,
+ {1, 2, 0}, V4L2_PIX_FMT_XV15, 2, 2, 2, 4, 3, "4:2:0, 10-bit 2-plane 
cont" },
{ XVIP_VF_RBG, 8, NULL, MEDIA_BUS_FMT_RBG888_1X24,
- {3, 0, 0}, V4L2_PIX_FMT_RGB24, 1, 1, 1, "24-bit RGB" },
+ {3, 0, 0}, V4L2_PIX_FMT_RGB24, 1, 1, 1, 1, 1, "24-bit RGB" },
{ XVIP_VF_MONO_SENSOR, 8, "mono", MEDIA_BUS_FMT_Y8_1X8,
- {1, 0, 0}, V4L2_PIX_FMT_GREY, 1, 1, 1, "Greyscale 8-bit" },
+ {1, 0, 0}, V4L2_PIX_FMT_GREY, 1, 1, 1, 1, 1, "Greyscale 8-bit" },
{ XVIP_VF_MONO_SENSOR, 8, "rggb", MEDIA_BUS_FMT_SRGGB8_1X8,
- {1, 0, 0}, V4L2_PIX_FMT_SGRBG8, 1, 1, 1, "Bayer 8-bit RGGB" },
+ {1, 0, 0}, V4L2_PIX_FMT_SGRBG8, 1, 1, 1, 1, 1, "Bayer 8-bit RGGB" },
{ XVIP_VF_MONO_SENSOR, 8, "grbg", MEDIA_BUS_FMT_SGRBG8_1X8,
- {1, 0, 0}, V4L2_PIX_FMT_SGRBG8, 1, 1, 1, "Bayer 8-bit GRBG" },
+ {1, 0, 0}, V4L2_PIX_FMT_SGRBG8, 1, 1, 1, 1, 1, "Bayer 8-bit GRBG" },
{ XVIP_VF_MONO_SENSOR, 8, "gbrg", MEDIA_BUS_FMT_SGBRG8_1X8,
- {1, 0, 0}, V4L2_PIX_FMT_SGBRG8, 1, 1, 1, "Bayer 8-bit GBRG" },
+ {1, 0, 0}, V4L2_PIX_FMT_SGBRG8, 1, 1, 1, 1, 1, "Bayer 8-bit GBRG" },
{ XVIP_VF_MONO_SENSOR, 8, "bggr", MEDIA_BUS_FMT_SBGGR8_1X8,
- {1, 0, 0}, V4L2_PIX_FMT_SBGGR8, 1, 1, 1, "Bayer 8-bit BGGR" },
+ {1, 0, 0}, V4L2_PIX_FMT_SBGGR8, 1, 1, 1, 1, 1, "Bayer 8-bit BGGR" },
 };
 
 /**
@@ -94,6 +96,23 @@ const struct xvip_video_format 
*xvip_get_format_by_fourcc(u32 fourcc)
 EXPORT_SYMBOL_GPL(xvip_get_format_by_fourcc);
 
 /**
+ * xvip_fmt_plane_width_bytes - bytes of the given width of the plane
+ * @info: VIP format description
+ * @width: width
+ *
+ * Return: Returns the number of bytes for given @width
+ */
+int xvip_fmt_plane_width_bytes(const struct xvip_video_format *info, u32 width)
+{
+   if (!info)
+   return 0;
+
+   return DIV_ROUND_UP(width * info->bytes_per_macropixel * info->bpp[0],
+   info->pixels_per_macropixel);
+}
+EXPORT_SYMBOL_GPL(xvip_fmt_plane_width_bytes);
+
+/**
  * xvip_of_get_format - Parse a device tree node and return format information
  * @node: the device tree node
  *
diff 

[PATCH v5 0/8] Add support for multi-planar formats and 10 bit formats

[Satish Kumar Nagireddy]

 The patches are for xilinx v4l. The patcheset enable support to handle 
multiplanar
 formats and 10 bit formats. Single planar implementation is removed as mplane 
can
 handle both.

 Patch-set has downstream changes and bug fixes. Added new media bus format
 MEDIA_BUS_FMT_VYYUYY8_1X24, new pixel format V4L2_PIX_FMT_XV15 and rst
 documentation.

Jeffrey Mouroux (1):
  uapi: media: New fourcc code and rst for 10 bit format

Radhey Shyam Pandey (1):
  v4l: xilinx: dma: Remove colorspace check in xvip_dma_verify_format

Rohit Athavale (1):
  xilinx: v4l: dma: Update driver to allow for probe defer

Satish Kumar Nagireddy (4):
  media-bus: uapi: Add YCrCb 420 media bus format and rst
  v4l: xilinx: dma: Update video format descriptor
  v4l: xilinx: dma: Add multi-planar support
  v4l: xilinx: dma: Add support for 10 bit formats

Vishal Sagar (1):
  xilinx: v4l: dma: Terminate DMA when media pipeline fail to start

 Documentation/media/uapi/v4l/pixfmt-xv15.rst| 134 +++
 Documentation/media/uapi/v4l/subdev-formats.rst |  38 +-
 Documentation/media/uapi/v4l/yuv-formats.rst|   1 +
 drivers/media/platform/xilinx/xilinx-dma.c  | 170 +++-
 drivers/media/platform/xilinx/xilinx-dma.h  |   4 +-
 drivers/media/platform/xilinx/xilinx-vip.c  |  37 --
 drivers/media/platform/xilinx/xilinx-vip.h  |  15 ++-
 drivers/media/platform/xilinx/xilinx-vipp.c |  16 +--
 include/uapi/linux/media-bus-format.h   |   3 +-
 include/uapi/linux/videodev2.h  |   1 +
 10 files changed, 333 insertions(+), 86 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-xv15.rst

-- 
2.7.4

[PATCH v5 4/8] media-bus: uapi: Add YCrCb 420 media bus format and rst

[Satish Kumar Nagireddy]

This commit adds YUV 420 media bus format. VYYUYY8_1X24
is an approximate way to descrive the pixels sent over
the bus.

This patch also contain rst documentation for media bus format.

Signed-off-by: Satish Kumar Nagireddy 
---
Changes in v3:
 - Fixed table alignment issue in rst file. Ensured the output is proper uisng
   'make pdfdocs'

Changes in v2:
 - Added rst documentation for MEDIA_BUS_FMT_VYYUYY8_1X24

 Documentation/media/uapi/v4l/subdev-formats.rst | 38 -
 include/uapi/linux/media-bus-format.h   |  3 +-
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index 9fcabe7..904c52b 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -6640,6 +6640,43 @@ the following codes.
   - u\ :sub:`2`
   - u\ :sub:`1`
   - u\ :sub:`0`
+* .. _MEDIA-BUS-FMT-VYYUYY8-1X24:
+
+  - MEDIA_BUS_FMT_VYYUYY8_1X24
+  - 0x202c
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  - v\ :sub:`3`
+  - v\ :sub:`2`
+  - v\ :sub:`1`
+  - v\ :sub:`0`
+  - y\ :sub:`7`
+  - y\ :sub:`6`
+  - y\ :sub:`5`
+  - y\ :sub:`4`
+  - y\ :sub:`3`
+  - y\ :sub:`2`
+  - y\ :sub:`1`
+  - y\ :sub:`0`
+  - u\ :sub:`3`
+  - u\ :sub:`2`
+  - u\ :sub:`1`
+  - u\ :sub:`0`
+  - y\ :sub:`7`
+  - y\ :sub:`6`
+  - y\ :sub:`5`
+  - y\ :sub:`4`
+  - y\ :sub:`3`
+  - y\ :sub:`2`
+  - y\ :sub:`1`
+  - y\ :sub:`0`
 * .. _MEDIA-BUS-FMT-YUV10-1X30:
 
   - MEDIA_BUS_FMT_YUV10_1X30
@@ -7287,7 +7324,6 @@ The following table list existing packed 48bit wide YUV 
formats.
   - y\ :sub:`1`
   - y\ :sub:`0`
 
-
 .. raw:: latex
 
\endgroup
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 9e35117..ade7e9d 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -62,7 +62,7 @@
 #define MEDIA_BUS_FMT_RGB121212_1X36   0x1019
 #define MEDIA_BUS_FMT_RGB161616_1X48   0x101a
 
-/* YUV (including grey) - next is  0x202c */
+/* YUV (including grey) - next is  0x202d */
 #define MEDIA_BUS_FMT_Y8_1X8   0x2001
 #define MEDIA_BUS_FMT_UV8_1X8  0x2015
 #define MEDIA_BUS_FMT_UYVY8_1_5X8  0x2002
@@ -106,6 +106,7 @@
 #define MEDIA_BUS_FMT_YUV12_1X36   0x2029
 #define MEDIA_BUS_FMT_YUV16_1X48   0x202a
 #define MEDIA_BUS_FMT_UYYVYY16_0_5X48  0x202b
+#define MEDIA_BUS_FMT_VYYUYY8_1X24 0x202c
 
 /* Bayer - next is 0x3021 */
 #define MEDIA_BUS_FMT_SBGGR8_1X8   0x3001
-- 
2.7.4

[PATCH v5 7/8] uapi: media: New fourcc code and rst for 10 bit format

[Satish Kumar Nagireddy]

From: Jeffrey Mouroux 

This patch adds new fourcc code and rst documentation for
YUV420 10 bit format.

Signed-off-by: Jeffrey Mouroux 
Signed-off-by: Satish Kumar Nagireddy 
---
Changes in v5:
 - Squashed rst documentation and new pixel format of YUV420 10 bit into single 
patch

Changes in v4:
 - Added rst documentation for YUV420 10 bit format

 Documentation/media/uapi/v4l/pixfmt-xv15.rst | 134 +++
 Documentation/media/uapi/v4l/yuv-formats.rst |   1 +
 include/uapi/linux/videodev2.h   |   1 +
 3 files changed, 136 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-xv15.rst

diff --git a/Documentation/media/uapi/v4l/pixfmt-xv15.rst 
b/Documentation/media/uapi/v4l/pixfmt-xv15.rst
new file mode 100644
index 000..fc829c3
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-xv15.rst
@@ -0,0 +1,134 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _V4L2-PIX-FMT-XV15:
+
+**
+V4L2_PIX_FMT_XV15 ('XV15')
+**
+
+
+Semi-planar YUV 420 10-bit
+
+
+Description
+===
+
+This is the 10-bit version of YUV 420 semi-planar format. XV15 is the one
+where chroma plane is contiguous with the luma plane in memory.
+
+Each pixel of YUV 420 contains a single luma component of 10-bits in length.
+Three luma components are stored per word with the remaining two bits serving
+as padding.
+
+The chroma plane is subsampled and is only 1/2 the size of the luma plane.  A
+single chroma component serves two pixels on a given row and is re-used on the
+adjacent row of luma data.
+
+**Data Layout of Luma Plane**
+Each cell is one 32-bit word.
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* - word + 0:
+  - X'\ :sub:`[31:30]`
+  - Y'\ :sub:`02 [29:20]`
+  - Y'\ :sub:`01 [19:10]`
+  - Y'\ :sub:`00 [09:00]`
+  -
+* - word + 1:
+  - X'\ :sub:`[31:30]`
+  - Y'\ :sub:`05 [29:20]`
+  - Y'\ :sub:`04 [19:10]`
+  - Y'\ :sub:`03 [09:00]`
+  -
+* - word + 2:
+  - X'\ :sub:`[31:30]`
+  - Y'\ :sub:`08 [29:20]`
+  - Y'\ :sub:`07 [19:10]`
+  - Y'\ :sub:`06 [09:00]`
+  -
+
+
+**Data Layout of Chroma Plane**
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* - word + 0:
+  - X'\ :sub:`[31:30]`
+  - U'\ :sub:`02 [29:20]`
+  - V'\ :sub:`01 [19:10]`
+  - U'\ :sub:`00 [09:00]`
+  -
+* - word + 1:
+  - X'\ :sub:`[31:30]`
+  - V'\ :sub:`05 [29:20]`
+  - U'\ :sub:`04 [19:10]`
+  - V'\ :sub:`03 [09:00]`
+  -
+* - word + 2:
+  - X'\ :sub:`[31:30]`
+  - U'\ :sub:`08 [29:20]`
+  - V'\ :sub:`07 [19:10]`
+  - U'\ :sub:`06 [09:00]`
+  -
+
+**Color Sample Location**
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* -
+  - 0
+  -
+  - 1
+  - 2
+  -
+  - 3
+* - 0
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+  -
+  - C
+  -
+  -
+  - C
+  -
+* - 1
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+* - 2
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
+* -
+  -
+  - C
+  -
+  -
+  - C
+  -
+* - 3
+  - Y
+  -
+  - Y
+  - Y
+  -
+  - Y
diff --git a/Documentation/media/uapi/v4l/yuv-formats.rst 
b/Documentation/media/uapi/v4l/yuv-formats.rst
index 3334ea4..c500bc1 100644
--- a/Documentation/media/uapi/v4l/yuv-formats.rst
+++ b/Documentation/media/uapi/v4l/yuv-formats.rst
@@ -49,6 +49,7 @@ to brightness information.
 pixfmt-nv12
 pixfmt-nv12m
 pixfmt-nv12mt
+pixfmt-xv15
 pixfmt-nv16
 pixfmt-nv16m
 pixfmt-nv24
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 600877b..873bafa 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -551,6 +551,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 
4:2:2  */
 #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 
4:4:4  */
 #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 
4:4:4  */
+#define V4L2_PIX_FMT_XV15v4l2_fourcc('X', 'V', '1', '5') /* 32  XY/UV 
4:2:0 10-bit */
 
 /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
 #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 
4:2:0  */
-- 
2.7.4

[PATCH v5 5/8] v4l: xilinx: dma: Update video format descriptor

[Satish Kumar Nagireddy]

This patch updates video format descriptor to help information
viz., number of planes per color format and chroma sub sampling
factors.

Signed-off-by: Satish Kumar Nagireddy 
---
Changes in v5:
 - Added YUV420 10 bit format to video descriptor table

Changes in v4:
 - Introduced bpp (bits per pixel) per plane

 drivers/media/platform/xilinx/xilinx-dma.c | 12 ++--
 drivers/media/platform/xilinx/xilinx-vip.c | 18 ++
 drivers/media/platform/xilinx/xilinx-vip.h | 10 --
 3 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
b/drivers/media/platform/xilinx/xilinx-dma.c
index 727dc6e..518d572 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -366,7 +366,7 @@ static void xvip_dma_buffer_queue(struct vb2_buffer *vb)
}
 
dma->xt.frame_size = 1;
-   dma->sgl[0].size = dma->format.width * dma->fmtinfo->bpp;
+   dma->sgl[0].size = dma->format.width * dma->fmtinfo->bpp[0];
dma->sgl[0].icg = dma->format.bytesperline - dma->sgl[0].size;
dma->xt.numf = dma->format.height;
 
@@ -569,12 +569,12 @@ __xvip_dma_try_format(struct xvip_dma *dma, struct 
v4l2_pix_format *pix,
 * the minimum and maximum values, clamp the requested width and convert
 * it back to pixels.
 */
-   align = lcm(dma->align, info->bpp);
+   align = lcm(dma->align, info->bpp[0]);
min_width = roundup(XVIP_DMA_MIN_WIDTH, align);
max_width = rounddown(XVIP_DMA_MAX_WIDTH, align);
-   width = rounddown(pix->width * info->bpp, align);
+   width = rounddown(pix->width * info->bpp[0], align);
 
-   pix->width = clamp(width, min_width, max_width) / info->bpp;
+   pix->width = clamp(width, min_width, max_width) / info->bpp[0];
pix->height = clamp(pix->height, XVIP_DMA_MIN_HEIGHT,
XVIP_DMA_MAX_HEIGHT);
 
@@ -582,7 +582,7 @@ __xvip_dma_try_format(struct xvip_dma *dma, struct 
v4l2_pix_format *pix,
 * line value is zero, the module doesn't support user configurable line
 * sizes. Override the requested value with the minimum in that case.
 */
-   min_bpl = pix->width * info->bpp;
+   min_bpl = pix->width * info->bpp[0];
max_bpl = rounddown(XVIP_DMA_MAX_WIDTH, dma->align);
bpl = rounddown(pix->bytesperline, dma->align);
 
@@ -676,7 +676,7 @@ int xvip_dma_init(struct xvip_composite_device *xdev, 
struct xvip_dma *dma,
dma->format.field = V4L2_FIELD_NONE;
dma->format.width = XVIP_DMA_DEF_WIDTH;
dma->format.height = XVIP_DMA_DEF_HEIGHT;
-   dma->format.bytesperline = dma->format.width * dma->fmtinfo->bpp;
+   dma->format.bytesperline = dma->format.width * dma->fmtinfo->bpp[0];
dma->format.sizeimage = dma->format.bytesperline * dma->format.height;
 
/* Initialize the media entity... */
diff --git a/drivers/media/platform/xilinx/xilinx-vip.c 
b/drivers/media/platform/xilinx/xilinx-vip.c
index 3112591..fb1a08f 100644
--- a/drivers/media/platform/xilinx/xilinx-vip.c
+++ b/drivers/media/platform/xilinx/xilinx-vip.c
@@ -27,22 +27,24 @@
  */
 
 static const struct xvip_video_format xvip_video_formats[] = {
+   { XVIP_VF_YUV_420, 8, NULL, MEDIA_BUS_FMT_VYYUYY8_1X24,
+ {1, 2, 0}, V4L2_PIX_FMT_NV12, 2, 2, 2, "4:2:0, semi-planar, YUV" },
{ XVIP_VF_YUV_422, 8, NULL, MEDIA_BUS_FMT_UYVY8_1X16,
- 2, V4L2_PIX_FMT_YUYV, "4:2:2, packed, YUYV" },
+ {2, 0, 0}, V4L2_PIX_FMT_YUYV, 1, 2, 1, "4:2:2, packed, YUYV" },
{ XVIP_VF_YUV_444, 8, NULL, MEDIA_BUS_FMT_VUY8_1X24,
- 3, V4L2_PIX_FMT_YUV444, "4:4:4, packed, YUYV" },
+ {3, 0, 0}, V4L2_PIX_FMT_YUV444, 1, 1, 1, "4:4:4, packed, YUYV" },
{ XVIP_VF_RBG, 8, NULL, MEDIA_BUS_FMT_RBG888_1X24,
- 3, 0, NULL },
+ {3, 0, 0}, V4L2_PIX_FMT_RGB24, 1, 1, 1, "24-bit RGB" },
{ XVIP_VF_MONO_SENSOR, 8, "mono", MEDIA_BUS_FMT_Y8_1X8,
- 1, V4L2_PIX_FMT_GREY, "Greyscale 8-bit" },
+ {1, 0, 0}, V4L2_PIX_FMT_GREY, 1, 1, 1, "Greyscale 8-bit" },
{ XVIP_VF_MONO_SENSOR, 8, "rggb", MEDIA_BUS_FMT_SRGGB8_1X8,
- 1, V4L2_PIX_FMT_SGRBG8, "Bayer 8-bit RGGB" },
+ {1, 0, 0}, V4L2_PIX_FMT_SGRBG8, 1, 1, 1, "Bayer 8-bit RGGB" },
{ XVIP_VF_MONO_SENSOR, 8, "grbg", MEDIA_BUS_FMT_SGRBG8_1X8,
- 1, V4L2_PIX_FMT_SGRBG8, "Bayer 8-bit GRBG" },
+ {1, 0, 0}, V4L2_PIX_FMT_SGRBG8, 1, 1, 1, "Bayer 8-bit GRBG" },
{ XVIP_VF_MONO_SENSOR, 8, "gbrg", MEDIA_BUS_FMT_SGBRG8_1X8,
- 1, V4L2_PIX_FMT_SGBRG8, "Bayer 8-bit GBRG" },
+ {1, 0, 0}, V4L2_PIX_FMT_SGBRG8, 1, 1, 1, "Bayer 8-bit GBRG" },
{ XVIP_VF_MONO_SENSOR, 8, "bggr", MEDIA_BUS_FMT_SBGGR8_1X8,
- 1, V4L2_PIX_FMT_SBGGR8, "Bayer 8-bit BGGR" },
+ {1, 0, 0}, V4L2_PIX_FMT_SBGGR8, 1, 1, 1, "Bayer 8-bit BGGR" },
 };
 
 /**
diff --git 

[PATCH v5 2/8] xilinx: v4l: dma: Update driver to allow for probe defer

[Satish Kumar Nagireddy]

From: Rohit Athavale 

Update xvip_dma_init() to use dma_request_chan(), enabling probe
deferral. Also update the cleanup routine to prevent dereferencing
an ERR_PTR().

Signed-off-by: Rohit Athavale 
Signed-off-by: Satish Kumar Nagireddy 
---
 drivers/media/platform/xilinx/xilinx-dma.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/xilinx/xilinx-dma.c 
b/drivers/media/platform/xilinx/xilinx-dma.c
index cb20ada..5426efe 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -729,10 +729,13 @@ int xvip_dma_init(struct xvip_composite_device *xdev, 
struct xvip_dma *dma,
 
/* ... and the DMA channel. */
snprintf(name, sizeof(name), "port%u", port);
-   dma->dma = dma_request_slave_channel(dma->xdev->dev, name);
-   if (dma->dma == NULL) {
-   dev_err(dma->xdev->dev, "no VDMA channel found\n");
-   ret = -ENODEV;
+   dma->dma = dma_request_chan(dma->xdev->dev, name);
+   if (IS_ERR(dma->dma)) {
+   ret = PTR_ERR(dma->dma);
+   if (ret != -EPROBE_DEFER)
+   dev_err(dma->xdev->dev,
+   "No Video DMA channel found");
+
goto error;
}
 
@@ -756,7 +759,7 @@ void xvip_dma_cleanup(struct xvip_dma *dma)
if (video_is_registered(>video))
video_unregister_device(>video);
 
-   if (dma->dma)
+   if (!IS_ERR(dma->dma))
dma_release_channel(dma->dma);
 
media_entity_cleanup(>video.entity);
-- 
2.7.4

Re: [PATCH v2 07/15] ARM: dts: increase default cma size to 40MB

[Shawn Guo]

On Mon, Apr 23, 2018 at 02:47:42PM +0100, Rui Miguel Silva wrote:
> To support camera in i.MX7 the cma heap is used to allocate frame buffers. The
> default size of CMA is 16MB which is not enough for higher resolutions (ex:
> 1600x1200).
> 
> So, increase the default CMA size to 40MB.
> 
> Signed-off-by: Rui Miguel Silva 

CMA size can be adjusted by kernel cmdline.  I'm not sure it's necessary
to make it fixed in DT.

Shawn

> ---
>  arch/arm/boot/dts/imx7s.dtsi | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 4d42335c0dee..142ea709d296 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -182,6 +182,20 @@
> IRQ_TYPE_LEVEL_LOW)>;
>   };
>  
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /* global autoconfigured region for contiguous allocations */
> + linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + size = <0x280>;
> + linux,cma-default;
> + };
> + };
> +
>   soc {
>   #address-cells = <1>;
>   #size-cells = <1>;
> -- 
> 2.17.0
> 

Re: [PATCH v2 04/15] clk: imx7d: reset parent for mipi csi root

[Shawn Guo]

On Mon, Apr 23, 2018 at 02:47:39PM +0100, Rui Miguel Silva wrote:
> To guarantee that we do not get Overflow in image FIFO the outer bandwidth has
> to be faster than inputer bandwidth. For that it must be possible to set a
> faster frequency clock. So set new parent to sys_pfd3 clock for the mipi csi
> block.
> 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rui Miguel Silva 
> ---
>  drivers/clk/imx/clk-imx7d.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
> index f7f4db2e6fa6..9a1a18ceb132 100644
> --- a/drivers/clk/imx/clk-imx7d.c
> +++ b/drivers/clk/imx/clk-imx7d.c
> @@ -891,6 +891,9 @@ static void __init imx7d_clocks_init(struct device_node 
> *ccm_node)
>   clk_set_parent(clks[IMX7D_PLL_AUDIO_MAIN_BYPASS], 
> clks[IMX7D_PLL_AUDIO_MAIN]);
>   clk_set_parent(clks[IMX7D_PLL_VIDEO_MAIN_BYPASS], 
> clks[IMX7D_PLL_VIDEO_MAIN]);
>  
> + clk_set_parent(clks[IMX7D_MIPI_CSI_ROOT_SRC],
> +clks[IMX7D_PLL_SYS_PFD3_CLK]);
> +

For i.MX clock driver, we intentionally ignore line over 80 columns
warning to make the file easier for read.  So I would suggest you keep
it on a single line to stay consistent with other clk_set_parent() calls.

Other than that,

Acked-by: Shawn Guo 

>   /* use old gpt clk setting, gpt1 root clk must be twice as gpt counter 
> freq */
>   clk_set_parent(clks[IMX7D_GPT1_ROOT_SRC], clks[IMX7D_OSC_24M_CLK]);
>  
> -- 
> 2.17.0
> 

RE: [PATCH v2 03/15] clk: imx7d: fix mipi dphy div parent

[A.s. Dong]

> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Thursday, May 3, 2018 9:08 AM
> To: Rui Miguel Silva ; Anson Huang
> 
> Cc: mche...@kernel.org; sakari.ai...@linux.intel.com; Steve Longerbeam
> ; Philipp Zabel ; Rob
> Herring ; linux-media@vger.kernel.org;
> de...@driverdev.osuosl.org; Fabio Estevam ;
> devicet...@vger.kernel.org; Greg Kroah-Hartman
> ; Ryan Harkin ;
> linux-...@vger.kernel.org; dl-linux-imx 
> Subject: Re: [PATCH v2 03/15] clk: imx7d: fix mipi dphy div parent
> 
> Anson,
> 
> Please have a look at this change.
> 
> Shawn
> 
> On Mon, Apr 23, 2018 at 02:47:38PM +0100, Rui Miguel Silva wrote:
> > Fix the mipi dphy root divider to mipi_dphy_pre_div, this would remove
> > a orphan clock and set the correct parent.
> >
> > before:
> > cat clk_orphan_summary
> >  enable  prepare  protect
> >clock  countcountcountrate   
> > accuracy   phase
> > 
> >  mipi_dphy_post_div   110   0   
> >0 0
> > mipi_dphy_root_clk110   0   
> >0 0
> >
> > cat clk_dump | grep mipi_dphy
> > mipi_dphy_post_div110   0   
> >0 0
> > mipi_dphy_root_clk110   0   
> >0 0
> >
> > after:
> > cat clk_dump | grep mipi_dphy
> >mipi_dphy_src 1102400
> >   0 0
> >mipi_dphy_cg  1102400
> >   0 0
> >   mipi_dphy_pre_div  1102400
> >   0 0
> >  mipi_dphy_post_div  1102400
> >   0 0
> > mipi_dphy_root_clk   1102400
> >   0 0
> >
> > Cc: linux-...@vger.kernel.org
> > Signed-off-by: Rui Miguel Silva 
> >
> > Signed-off-by: Rui Miguel Silva 

Two sign-off?

Otherwise, the patch looks ok to me.
Acked-by: Dong Aisheng 

Regards
Dong Aisheng

> > ---
> >  drivers/clk/imx/clk-imx7d.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
> > index 975a20d3cc94..f7f4db2e6fa6 100644
> > --- a/drivers/clk/imx/clk-imx7d.c
> > +++ b/drivers/clk/imx/clk-imx7d.c
> > @@ -729,7 +729,7 @@ static void __init imx7d_clocks_init(struct
> device_node *ccm_node)
> > clks[IMX7D_LCDIF_PIXEL_ROOT_DIV] =
> imx_clk_divider2("lcdif_pixel_post_div", "lcdif_pixel_pre_div", base +
> 0xa300, 0, 6);
> > clks[IMX7D_MIPI_DSI_ROOT_DIV] =
> imx_clk_divider2("mipi_dsi_post_div", "mipi_dsi_pre_div", base + 0xa380, 0,
> 6);
> > clks[IMX7D_MIPI_CSI_ROOT_DIV] =
> imx_clk_divider2("mipi_csi_post_div", "mipi_csi_pre_div", base + 0xa400, 0,
> 6);
> > -   clks[IMX7D_MIPI_DPHY_ROOT_DIV] =
> imx_clk_divider2("mipi_dphy_post_div", "mipi_csi_dphy_div", base +
> 0xa480, 0, 6);
> > +   clks[IMX7D_MIPI_DPHY_ROOT_DIV] =
> > +imx_clk_divider2("mipi_dphy_post_div", "mipi_dphy_pre_div", base +
> > +0xa480, 0, 6);
> > clks[IMX7D_SAI1_ROOT_DIV] = imx_clk_divider2("sai1_post_div",
> "sai1_pre_div", base + 0xa500, 0, 6);
> > clks[IMX7D_SAI2_ROOT_DIV] = imx_clk_divider2("sai2_post_div",
> "sai2_pre_div", base + 0xa580, 0, 6);
> > clks[IMX7D_SAI3_ROOT_DIV] = imx_clk_divider2("sai3_post_div",
> > "sai3_pre_div", base + 0xa600, 0, 6);
> > --
> > 2.17.0
> >

Re: [PATCH v2 03/15] clk: imx7d: fix mipi dphy div parent

[Shawn Guo]

Anson,

Please have a look at this change.

Shawn

On Mon, Apr 23, 2018 at 02:47:38PM +0100, Rui Miguel Silva wrote:
> Fix the mipi dphy root divider to mipi_dphy_pre_div, this would remove a 
> orphan
> clock and set the correct parent.
> 
> before:
> cat clk_orphan_summary
>  enable  prepare  protect
>clock  countcountcountrate   
> accuracy   phase
> 
>  mipi_dphy_post_div   110   0 
>  0 0
> mipi_dphy_root_clk110   0 
>  0 0
> 
> cat clk_dump | grep mipi_dphy
> mipi_dphy_post_div110   0 
>  0 0
> mipi_dphy_root_clk110   0 
>  0 0
> 
> after:
> cat clk_dump | grep mipi_dphy
>mipi_dphy_src 1102400  
> 0 0
>mipi_dphy_cg  1102400  
> 0 0
>   mipi_dphy_pre_div  1102400  
> 0 0
>  mipi_dphy_post_div  1102400  
> 0 0
> mipi_dphy_root_clk   1102400  
> 0 0
> 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rui Miguel Silva 
> 
> Signed-off-by: Rui Miguel Silva 
> ---
>  drivers/clk/imx/clk-imx7d.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
> index 975a20d3cc94..f7f4db2e6fa6 100644
> --- a/drivers/clk/imx/clk-imx7d.c
> +++ b/drivers/clk/imx/clk-imx7d.c
> @@ -729,7 +729,7 @@ static void __init imx7d_clocks_init(struct device_node 
> *ccm_node)
>   clks[IMX7D_LCDIF_PIXEL_ROOT_DIV] = 
> imx_clk_divider2("lcdif_pixel_post_div", "lcdif_pixel_pre_div", base + 
> 0xa300, 0, 6);
>   clks[IMX7D_MIPI_DSI_ROOT_DIV] = imx_clk_divider2("mipi_dsi_post_div", 
> "mipi_dsi_pre_div", base + 0xa380, 0, 6);
>   clks[IMX7D_MIPI_CSI_ROOT_DIV] = imx_clk_divider2("mipi_csi_post_div", 
> "mipi_csi_pre_div", base + 0xa400, 0, 6);
> - clks[IMX7D_MIPI_DPHY_ROOT_DIV] = imx_clk_divider2("mipi_dphy_post_div", 
> "mipi_csi_dphy_div", base + 0xa480, 0, 6);
> + clks[IMX7D_MIPI_DPHY_ROOT_DIV] = imx_clk_divider2("mipi_dphy_post_div", 
> "mipi_dphy_pre_div", base + 0xa480, 0, 6);
>   clks[IMX7D_SAI1_ROOT_DIV] = imx_clk_divider2("sai1_post_div", 
> "sai1_pre_div", base + 0xa500, 0, 6);
>   clks[IMX7D_SAI2_ROOT_DIV] = imx_clk_divider2("sai2_post_div", 
> "sai2_pre_div", base + 0xa580, 0, 6);
>   clks[IMX7D_SAI3_ROOT_DIV] = imx_clk_divider2("sai3_post_div", 
> "sai3_pre_div", base + 0xa600, 0, 6);
> -- 
> 2.17.0
> 

[PATCH] drivers: dma-buf: Change %p to %pK in debug messages

[Daniel Rosenberg]

The format specifier %p can leak kernel addresses
while not valuing the kptr_restrict system settings.
Use %pK instead of %p, which also evaluates whether
kptr_restrict is set.

Signed-off-by: Divya Ponnusamy 
Signed-off-by: Daniel Rosenberg 
Cc: stable 
---
 drivers/dma-buf/sync_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index c4c8ecb24aa9..d8d340542a79 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -133,7 +133,7 @@ static void sync_print_sync_file(struct seq_file *s,
char buf[128];
int i;
 
-   seq_printf(s, "[%p] %s: %s\n", sync_file,
+   seq_printf(s, "[%pK] %s: %s\n", sync_file,
   sync_file_get_name(sync_file, buf, sizeof(buf)),
   sync_status_str(dma_fence_get_status(sync_file->fence)));
 
-- 
2.17.0.441.gb46fe60e1d-goog

[PATCH 1/2] intel-ipu3: Kconfig coding style issue

[Brad Love]

Kconfig Help statements are two-spaced after a single tab.

The incorrect spacing breaks menuconfig on older kernels.

Signed-off-by: Brad Love 
---
 drivers/media/pci/intel/ipu3/Kconfig | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
b/drivers/media/pci/intel/ipu3/Kconfig
index a82d3fe..7f5b7a5 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -10,10 +10,10 @@ config VIDEO_IPU3_CIO2
select VIDEOBUF2_DMA_SG
 
---help---
-   This is the Intel IPU3 CIO2 CSI-2 receiver unit, found in Intel
-   Skylake and Kaby Lake SoCs and used for capturing images and
-   video from a camera sensor.
+ This is the Intel IPU3 CIO2 CSI-2 receiver unit, found in Intel
+ Skylake and Kaby Lake SoCs and used for capturing images and
+ video from a camera sensor.
 
-   Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
-   connected camera.
-   The module will be called ipu3-cio2.
+ Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
+ connected camera.
+ The module will be called ipu3-cio2.
-- 
2.7.4

[PATCH 0/2] Whitespace fixes

[Brad Love]

In intel/ipu3 and media Kconfig files there
are whitespace issues, which cause failure when
doing menuconfig on older kernels during backport
operations. The kernel rules are applied to both
Kconfigs. Initial spacing of one tab, then help is
further indented by two spaces.

Brad Love (2):
  intel-ipu3: Kconfig coding style issue
  cec: Kconfig coding style issue

 drivers/media/Kconfig | 12 ++--
 drivers/media/pci/intel/ipu3/Kconfig  | 12 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

-- 
2.7.4

[PATCH 2/2] cec: Kconfig coding style issue

[Brad Love]

Use tabs instead of spaces and help is two-spaced after single tab.

The incorrect spacing breaks menuconfig on older kernels.

Signed-off-by: Brad Love 
---
 drivers/media/Kconfig | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 37124c3..8add62a 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -78,13 +78,13 @@ config MEDIA_SDR_SUPPORT
  Say Y when you have a software defined radio device.
 
 config MEDIA_CEC_SUPPORT
-   bool "HDMI CEC support"
-   ---help---
-Enable support for HDMI CEC (Consumer Electronics Control),
-which is an optional HDMI feature.
+   bool "HDMI CEC support"
+   ---help---
+ Enable support for HDMI CEC (Consumer Electronics Control),
+ which is an optional HDMI feature.
 
-Say Y when you have an HDMI receiver, transmitter or a USB CEC
-adapter that supports HDMI CEC.
+ Say Y when you have an HDMI receiver, transmitter or a USB CEC
+ adapter that supports HDMI CEC.
 
 source "drivers/media/cec/Kconfig"
 
-- 
2.7.4

[PATCH] saa7164: Fix driver name in debug output

[Brad Love]

This issue was reported by a user who downloaded a corrupt saa7164
firmware, then went looking for a valid xc5000 firmware to fix the
error displayed...but the device in question has no xc5000, thus after
much effort, the wild goose chase eventually led to a support call.

The xc5000 has nothing to do with saa7164 (as far as I can tell),
so replace the string with saa7164 as well as give a meaningful
hint on the firmware mismatch.

Signed-off-by: Brad Love 
---
 drivers/media/pci/saa7164/saa7164-fw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/saa7164/saa7164-fw.c 
b/drivers/media/pci/saa7164/saa7164-fw.c
index ef49064..ee65ea8 100644
--- a/drivers/media/pci/saa7164/saa7164-fw.c
+++ b/drivers/media/pci/saa7164/saa7164-fw.c
@@ -426,7 +426,8 @@ int saa7164_downloadfirmware(struct saa7164_dev *dev)
__func__, fw->size);
 
if (fw->size != fwlength) {
-   printk(KERN_ERR "xc5000: firmware incorrect size\n");
+   printk(KERN_ERR "saa7164: firmware incorrect size %d != 
%d\n",
+   fw->size, fwlength);
ret = -ENOMEM;
goto out;
}
-- 
2.7.4

[PATCH] media: staging: atomisp: fix a potential missing-check bug

[Wenwen Wang]

At the end of atomisp_subdev_set_selection(), the function
atomisp_subdev_get_rect() is invoked to get the pointer to v4l2_rect. Since
this function may return a NULL pointer, it is firstly invoked to check
the returned pointer. If the returned pointer is not NULL, then the
function is invoked again to obtain the pointer and the memory content
at the location of the returned pointer is copied to the memory location of
r. In most cases, the pointers returned by the two invocations are same.
However, given that the pointer returned by the function
atomisp_subdev_get_rect() is not a constant, it is possible that the two
invocations return two different pointers. For example, another thread may
race to modify the related pointers during the two invocations. In that
case, even if the first returned pointer is not null, the second returned
pointer might be null, which will cause issues such as null pointer
dereference.

This patch saves the pointer returned by the first invocation and removes
the second invocation. If the returned pointer is not NULL, the memory
content is copied according to the original code.

Signed-off-by: Wenwen Wang 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
index 49a9973..d5fa513 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
@@ -366,6 +366,7 @@ int atomisp_subdev_set_selection(struct v4l2_subdev *sd,
unsigned int i;
unsigned int padding_w = pad_w;
unsigned int padding_h = pad_h;
+   struct v4l2_rect *p;
 
stream_id = atomisp_source_pad_to_stream_id(isp_sd, vdev_pad);
 
@@ -536,9 +537,10 @@ int atomisp_subdev_set_selection(struct v4l2_subdev *sd,
ffmt[pad]->height = comp[pad]->height;
}
 
-   if (!atomisp_subdev_get_rect(sd, cfg, which, pad, target))
+   p = atomisp_subdev_get_rect(sd, cfg, which, pad, target);
+   if (!p)
return -EINVAL;
-   *r = *atomisp_subdev_get_rect(sd, cfg, which, pad, target);
+   *r = *p;
 
dev_dbg(isp->dev, "sel actual: l %d t %d w %d h %d\n",
r->left, r->top, r->width, r->height);
-- 
2.7.4

Re: [RFCv12 PATCH 03/29] media-request: implement media requests

[Sakari Ailus]

Hi Hans,

On Tue, May 01, 2018 at 11:00:25AM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add initial media request support.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/Makefile|   3 +-
>  drivers/media/media-device.c  |  13 ++
>  drivers/media/media-request.c | 418 ++
>  include/media/media-device.h  |  17 ++
>  include/media/media-request.h | 193 
>  5 files changed, 643 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/media-request.c
>  create mode 100644 include/media/media-request.h
> 
> diff --git a/drivers/media/Makefile b/drivers/media/Makefile
> index 594b462ddf0e..985d35ec6b29 100644
> --- a/drivers/media/Makefile
> +++ b/drivers/media/Makefile
> @@ -3,7 +3,8 @@
>  # Makefile for the kernel multimedia device drivers.
>  #
>  
> -media-objs   := media-device.o media-devnode.o media-entity.o
> +media-objs   := media-device.o media-devnode.o media-entity.o \
> +media-request.o
>  
>  #
>  # I2C drivers should come before other drivers, otherwise they'll fail
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 35e81f7c0d2f..25d7e2a3ee84 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_MEDIA_CONTROLLER
>  
> @@ -366,6 +367,15 @@ static long media_device_get_topology(struct 
> media_device *mdev,
>   return ret;
>  }
>  
> +static long media_device_request_alloc(struct media_device *mdev,
> +struct media_request_alloc *alloc)
> +{
> + if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
> + return -ENOTTY;
> +
> + return media_request_alloc(mdev, alloc);
> +}
> +
>  static long copy_arg_from_user(void *karg, void __user *uarg, unsigned int 
> cmd)
>  {
>   /* All media IOCTLs are _IOWR() */
> @@ -414,6 +424,7 @@ static const struct media_ioctl_info ioctl_info[] = {
>   MEDIA_IOC(ENUM_LINKS, media_device_enum_links, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
>   MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
>   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> + MEDIA_IOC(REQUEST_ALLOC, media_device_request_alloc, 0),
>  };
>  
>  static long media_device_ioctl(struct file *filp, unsigned int cmd,
> @@ -686,6 +697,8 @@ void media_device_init(struct media_device *mdev)
>   INIT_LIST_HEAD(>pads);
>   INIT_LIST_HEAD(>links);
>   INIT_LIST_HEAD(>entity_notify);
> +
> + mutex_init(>req_queue_mutex);

You'll need to add the corresponding mutex_destroy() to
media_device_cleanup().

>   mutex_init(>graph_mutex);
>   ida_init(>entity_internal_idx);
>  
> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> new file mode 100644
> index ..22881d5700c8
> --- /dev/null
> +++ b/drivers/media/media-request.c
> @@ -0,0 +1,418 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Media device request objects
> + *
> + * Copyright (C) 2018 Intel Corporation
> + * Copyright (C) 2018 Google, Inc.
> + *
> + * Author: Sakari Ailus 
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static const char * const request_state[] = {
> + [MEDIA_REQUEST_STATE_IDLE]   = "idle",
> + [MEDIA_REQUEST_STATE_VALIDATING] = "validating",
> + [MEDIA_REQUEST_STATE_QUEUED] = "queued",
> + [MEDIA_REQUEST_STATE_COMPLETE]   = "complete",
> + [MEDIA_REQUEST_STATE_CLEANING]   = "cleaning",
> +};
> +
> +static const char *
> +media_request_state_str(enum media_request_state state)
> +{
> + if (WARN_ON(state >= ARRAY_SIZE(request_state)))
> + return "unknown";

Unknown or invalid? I'd think that states that are not defined in
request_state above are not valid.

> + return request_state[state];
> +}
> +
> +static void media_request_clean(struct media_request *req)
> +{
> + struct media_request_object *obj, *obj_safe;
> +
> + WARN_ON(atomic_read(>state) != MEDIA_REQUEST_STATE_CLEANING);
> +
> + list_for_each_entry_safe(obj, obj_safe, >objects, list) {
> + media_request_object_unbind(obj);
> + media_request_object_put(obj);
> + }
> +
> + req->num_incomplete_objects = 0;
> + wake_up_interruptible_all(>poll_wait);
> +}
> +
> +static void media_request_release(struct kref *kref)
> +{
> + struct media_request *req =
> + container_of(kref, struct media_request, kref);
> + struct media_device *mdev = req->mdev;
> +
> + dev_dbg(mdev->dev, "request: release %s\n", req->debug_str);
> +
> + atomic_set(>state, MEDIA_REQUEST_STATE_CLEANING);
> +
> + media_request_clean(req);
> +
> + if (mdev->ops->req_free)
> + mdev->ops->req_free(req);
> + else
> +   

Re: [RFCv12 PATCH 05/29] media-request: add media_request_find

[Sakari Ailus]

Hi Hans,

Thanks for the update.

On Tue, May 01, 2018 at 11:00:27AM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add media_request_find() to find a request based on the file
> descriptor.

What would you think of calling this media_request_get_by_fd() instead?

I think what the function does has changed over the time a bit but the name
has stayed.

> 
> The caller has to call media_request_put() for the returned
> request since this function increments the refcount.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/media-request.c | 44 +++
>  include/media/media-request.h | 10 
>  2 files changed, 54 insertions(+)
> 
> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> index 22881d5700c8..a186db290d51 100644
> --- a/drivers/media/media-request.c
> +++ b/drivers/media/media-request.c
> @@ -234,6 +234,50 @@ static const struct file_operations request_fops = {
>   .release = media_request_close,
>  };
>  
> +/**
> + * media_request_find - Find a request based on the file descriptor
> + * @mdev: The media device
> + * @request_fd: The request file handle
> + *
> + * Find and return the request associated with the given file descriptor, or
> + * an error if no such request exists.
> + *
> + * When the function returns a request it increases its reference count. The
> + * caller is responsible for releasing the reference by calling
> + * media_request_put() on the request.
> + */
> +struct media_request *
> +media_request_find(struct media_device *mdev, int request_fd)
> +{
> + struct file *filp;
> + struct media_request *req;
> +
> + if (!mdev || !mdev->ops ||
> + !mdev->ops->req_validate || !mdev->ops->req_queue)
> + return ERR_PTR(-EPERM);
> +
> + filp = fget(request_fd);
> + if (!filp)
> + return ERR_PTR(-ENOENT);
> +
> + if (filp->f_op != _fops)
> + goto err_fput;
> + req = filp->private_data;
> + if (req->mdev != mdev)
> + goto err_fput;
> +
> + media_request_get(req);
> + fput(filp);
> +
> + return req;
> +
> +err_fput:
> + fput(filp);
> +
> + return ERR_PTR(-ENOENT);
> +}
> +EXPORT_SYMBOL_GPL(media_request_find);
> +
>  int media_request_alloc(struct media_device *mdev,
>   struct media_request_alloc *alloc)
>  {
> diff --git a/include/media/media-request.h b/include/media/media-request.h
> index 9051dfbc7d30..ce62fe74ebd6 100644
> --- a/include/media/media-request.h
> +++ b/include/media/media-request.h
> @@ -70,6 +70,9 @@ static inline void media_request_get(struct media_request 
> *req)
>  void media_request_put(struct media_request *req);
>  void media_request_cancel(struct media_request *req);
>  
> +struct media_request *
> +media_request_find(struct media_device *mdev, int request_fd);
> +
>  int media_request_alloc(struct media_device *mdev,
>   struct media_request_alloc *alloc);
>  #else
> @@ -85,6 +88,12 @@ static inline void media_request_cancel(struct 
> media_request *req)
>  {
>  }
>  
> +static inline struct media_request *
> +media_request_find(struct media_device *mdev, int request_fd)
> +{
> + return ERR_PTR(-ENOENT);
> +}
> +
>  #endif
>  
>  struct media_request_object_ops {
> @@ -188,6 +197,7 @@ static inline void media_request_object_unbind(struct 
> media_request_object *obj)
>  static inline void media_request_object_complete(struct media_request_object 
> *obj)
>  {
>  }
> +
>  #endif
>  
>  #endif
> -- 
> 2.17.0
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

[PATCH] [BUG] em28xx: Fix DualHD broken second tuner

[Brad Love]

The use of a hard coded i2c address breaks the creation of the
second tuner in DualHD 01595 models. The issue is compounded
by lack of any error message stating that a driver failed
initialization. Use addr, which contains the correct address
for each tuner.

Fixes: ad32495b1513 ("media: em28xx-dvb: simplify DVB module probing logic")

Signed-off-by: Brad Love 
---
 drivers/media/usb/em28xx/em28xx-dvb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index a54cb8d..4ab71a2 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1392,7 +1392,7 @@ static int 
em28174_dvb_init_hauppauge_wintv_dualhd_01595(struct em28xx *dev)
 
dvb->i2c_client_tuner = dvb_module_probe("si2157", NULL,
 adapter,
-0x60, _config);
+addr, _config);
if (!dvb->i2c_client_tuner) {
dvb_module_release(dvb->i2c_client_demod);
return -ENODEV;
-- 
2.7.4

Re: [PATCH v2 08/12] media: ov5640: Adjust the clock based on the expected rate

[Sakari Ailus]

On Tue, Apr 24, 2018 at 09:36:44PM +0200, Maxime Ripard wrote:
> Hi Sakari,
> 
> On Tue, Apr 24, 2018 at 10:21:47AM +0300, Sakari Ailus wrote:
> > >  /* download ov5640 settings to sensor through i2c */
> > >  static int ov5640_load_regs(struct ov5640_dev *sensor,
> > >   const struct ov5640_mode_info *mode)
> > > @@ -1620,6 +1830,14 @@ static int ov5640_set_mode(struct ov5640_dev 
> > > *sensor,
> > >   if (ret)
> > >   return ret;
> > >  
> > > + if (sensor->ep.bus_type == V4L2_MBUS_CSI2)
> > > + ret = ov5640_set_mipi_pclk(sensor, mode->clock);
> > 
> > What is the value of the mode->clock expected to signify? It'd seem like
> > that this changes from this patch to the next. Which one is correct?
> 
> It doesn't, this is the clock rate computed through the formula
> described above (and that might be incorrect for MIPI-CSI, given
> Samuel feedback) from the way the registers are initialized in the
> arrays.
> 
> This shouldn't bring any change to the clock rate, but instead of
> hardcoding it, we now have the infrastructure to calculate the factors
> for any given rate.
> 
> The subsequent patch will remove that hardcoded clock rate and
> generate it dynamically from the timings / format.
> 
> Does that make sense? Or maybe I should split this some other way?

I guess it's ok as it is. I think I must have misread a chunk in the
following patch --- sorry about the noise.

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [RESEND PATCH v9 1/2] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

[Sakari Ailus]

On Wed, May 02, 2018 at 11:53:47PM +0800, Andy Yeh wrote:
> From: Alan Chiang 
> 
> Dongwoon DW9807 is a voice coil lens driver.
> 
> Signed-off-by: Andy Yeh 
> Reviewed-by: Sakari Ailus 
> Reviewed-by: Tomasz Figa 
> Reviewed-by: Jacopo Mondi 

I don't remember seeing these two on the first patch nor giving mine. For
what it's worth, I've applied v8 to my tree here:



I.e. there's no need to resend the same patch to just add the regular
acked-by or reviewed-by tags. "RESEND" in the subject suggests you're
sending exactly the same patch, and in that case the version would be
unchanged as well.

> Acked-by: Rob Herring 
> 
> ---
>  Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt | 9 +
>  1 file changed, 9 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt 
> b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> new file mode 100644
> index 000..0a1a860
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
> @@ -0,0 +1,9 @@
> +Dongwoon Anatech DW9807 voice coil lens driver
> +
> +DW9807 is a 10-bit DAC with current sink capability. It is intended for
> +controlling voice coil lenses.
> +
> +Mandatory properties:
> +
> +- compatible: "dongwoon,dw9807"
> +- reg: I2C slave address

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

[PATCH 0/2] Add a property to tell camera sensor orientation, support it in smiapp

[Sakari Ailus]

Hi,

The two patches add an "upside-down" property to the video bindings and
support for the property in the smiapp driver.

Sakari Ailus (2):
  dt-bindings: media: Add "upside-down" property to tell sensor
orientation
  smiapp: Support the "upside-down" property

 Documentation/devicetree/bindings/media/i2c/nokia,smia.txt   | 2 ++
 Documentation/devicetree/bindings/media/video-interfaces.txt | 3 +++
 drivers/media/i2c/smiapp/smiapp-core.c   | 3 +++
 3 files changed, 8 insertions(+)

-- 
2.11.0

[PATCH 2/2] smiapp: Support the "upside-down" property

[Sakari Ailus]

Use the "upside-down" property to tell that the sensor is mounted upside
down. This reverses the behaviour of the VFLIP and HFLIP controls as well
as the pixel order.

Signed-off-by: Sakari Ailus 
---
 Documentation/devicetree/bindings/media/i2c/nokia,smia.txt | 2 ++
 drivers/media/i2c/smiapp/smiapp-core.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt 
b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
index 33f10a94c381..c824cd7025b3 100644
--- a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
+++ b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
@@ -29,6 +29,8 @@ Optional properties
 - reset-gpios: XSHUTDOWN GPIO
 - flash-leds: See ../video-interfaces.txt
 - lens-focus: See ../video-interfaces.txt
+- upside-down: A boolean property. Tells that the sensor is mounted upside
+  down.
 
 
 Endpoint node mandatory properties
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index 3b7ace395ee6..5bc91b5a5998 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2801,6 +2801,9 @@ static struct smiapp_hwconfig *smiapp_get_hwconfig(struct 
device *dev)
 
dev_dbg(dev, "lanes %u\n", hwcfg->lanes);
 
+   if (fwnode_property_read_bool(fwnode, "upside-down"))
+   hwcfg->module_board_orient = SMIAPP_MODULE_BOARD_ORIENT_180;
+
/* NVM size is not mandatory */
fwnode_property_read_u32(fwnode, "nokia,nvm-size", >nvm_size);
 
-- 
2.11.0

[PATCH 1/2] dt-bindings: media: Add "upside-down" property to tell sensor orientation

[Sakari Ailus]

Camera sensors are occasionally mounted upside down. In order to use such
a sensor without having to turn every image upside down separately, most
camera sensors support reversing the readout order by setting both
horizontal and vertical flipping.

This patch adds a boolean property to tell a sensor is mounted upside
down.

Signed-off-by: Sakari Ailus 
---
 Documentation/devicetree/bindings/media/video-interfaces.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index 258b8dfddf48..2a3e4ec4ea27 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -85,6 +85,9 @@ Optional properties
 
 - lens-focus: A phandle to the node of the focus lens controller.
 
+- upside-down: The device, typically an image sensor, is mounted upside
+  down in the system.
+
 
 Optional endpoint properties
 
-- 
2.11.0

[linux-stable-rc:linux-4.4.y 8340/8366] drivers/media//v4l2-core/videobuf2-vmalloc.c:103:20: error: implicit declaration of function '__pfn_to_phys'; did you mean 'dma_to_phys'?

[kbuild test robot]

tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.4.y
head:   a33ce4af3470ca75091b7a05ed6259e938186054
commit: 38b2082959efe95b2aa41c38c6a4f2dcdd6c2df1 [8340/8366] media: vb2: Fix 
videobuf2 to map correct area
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 38b2082959efe95b2aa41c38c6a4f2dcdd6c2df1
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   drivers/media//v4l2-core/videobuf2-vmalloc.c: In function 
'vb2_vmalloc_get_userptr':
>> drivers/media//v4l2-core/videobuf2-vmalloc.c:103:20: error: implicit 
>> declaration of function '__pfn_to_phys'; did you mean 'dma_to_phys'? 
>> [-Werror=implicit-function-declaration]
   ioremap_nocache(__pfn_to_phys(nums[0]), size + offset);
   ^
   dma_to_phys
   cc1: some warnings being treated as errors

vim +103 drivers/media//v4l2-core/videobuf2-vmalloc.c

71  
72  static void *vb2_vmalloc_get_userptr(void *alloc_ctx, unsigned long 
vaddr,
73   unsigned long size,
74   enum dma_data_direction dma_dir)
75  {
76  struct vb2_vmalloc_buf *buf;
77  struct frame_vector *vec;
78  int n_pages, offset, i;
79  
80  buf = kzalloc(sizeof(*buf), GFP_KERNEL);
81  if (!buf)
82  return NULL;
83  
84  buf->dma_dir = dma_dir;
85  offset = vaddr & ~PAGE_MASK;
86  buf->size = size;
87  vec = vb2_create_framevec(vaddr, size, dma_dir == 
DMA_FROM_DEVICE);
88  if (IS_ERR(vec))
89  goto fail_pfnvec_create;
90  buf->vec = vec;
91  n_pages = frame_vector_count(vec);
92  if (frame_vector_to_pages(vec) < 0) {
93  unsigned long *nums = frame_vector_pfns(vec);
94  
95  /*
96   * We cannot get page pointers for these pfns. Check 
memory is
97   * physically contiguous and use direct mapping.
98   */
99  for (i = 1; i < n_pages; i++)
   100  if (nums[i-1] + 1 != nums[i])
   101  goto fail_map;
   102  buf->vaddr = (__force void *)
 > 103  ioremap_nocache(__pfn_to_phys(nums[0]), size + 
 > offset);
   104  } else {
   105  buf->vaddr = vm_map_ram(frame_vector_pages(vec), 
n_pages, -1,
   106  PAGE_KERNEL);
   107  }
   108  
   109  if (!buf->vaddr)
   110  goto fail_map;
   111  buf->vaddr += offset;
   112  return buf;
   113  
   114  fail_map:
   115  vb2_destroy_framevec(vec);
   116  fail_pfnvec_create:
   117  kfree(buf);
   118  
   119  return NULL;
   120  }
   121  

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


.config.gz
Description: application/gzip

Re: [PATCH v2 00/12] media: ov5640: Misc cleanup and improvements

[Sam Bobrowicz]

On Fri, Apr 27, 2018 at 2:27 AM, Laurent Pinchart
 wrote:
> Hi Sam,
>
> On Wednesday, 25 April 2018 01:11:19 EEST Sam Bobrowicz wrote:
>> FYI, still hard at work on this. Did some more experiments last week
>> that seemed to corroborate the clock tree in the spreadsheet. It also
>> seems that the output of the P divider cell, SCLK cell and MIPI Rate
>> cell in the spreadsheet must have a ratio of 2x:1x:8x (respectively)
>> in order for the sensor to work properly on my platform, and that the
>> SCLK value must be close to the "rate" variable that you calculate and
>> pass to set_mipi_pclk. Unfortunately, I've only got the sensor working
>> well for 1080p@15Hz and 720p@30Hz, both with a SCLK of 42MHz (aka
>> 84:42:336). I'm running experiments now trying to adjust the htot and
>> vtot values to create different required rates, and also to try to get
>> faster Mipi rates working. Any information you have on the
>> requirements of the htot and vtot values with respect to vact and hact
>> values would likely be helpful.
>>
>> I'm also keeping an eye on the scaler clock, which I think may be
>> affecting certain resolutions, but haven't been able to see it make a
>> difference yet (see register 0x3824 and 0x460c)
>>
>> I plan on pushing a set of patches once I get this figured out, we can
>> discuss what I should base them on when I get closer to that point.
>> I'm new to this process :)
>
> I'm also interested in getting the ov5640 driver working with MIPI CSI-2.
> Studying the datasheet and the driver code, I found the stream on sequence to
> be a bit weird. In particular the configuration of OV5640_REG_IO_MIPI_CTRL00,
> OV5640_REG_PAD_OUTPUT00 and OV5640_REG_MIPI_CTRL00 caught my attention.
>
> OV5640_REG_IO_MIPI_CTRL00 (0x300e) is set to 0x45 in the large array of init
> mode data and never touched for MIPI CSI-2 (the register is only touched in
> ov5640_set_stream_dvp). The value means
>
> - mipi_lane_mode: 010 is documented as "debug mode", I would have expected 000
> for one lane or 001 for two lanes.

I noticed this too, but it seems that 010 is the correct value for two
lane mode. I think this is a typo in the datasheet.

>
> - MIPI TX PHY power down: 0 is documented as "debug mode" and 1 as "Power down
> PHY HS TX", so I suppose 0 is correct.
>
> - MIPI RX PHY power down: 0 is documented as "debug mode" and 1 as "Power down
> PHY LP RX module", so I suppose 0 is correct. I however wonder why there's a
> RX PHY, it could be a typo.
>
> - mipi_en: 1 means MIPI enable, which should be correct.
>
> - BIT(0) is undocumented.
>
> OV5640_REG_PAD_OUTPUT00 (0x3019) isn't initialized explicitly and thus retains
> its default value of 0x00, and is controlled when starting and stopping the
> stream where it's set to 0x00 and 0x70 respectively. Bits 6:4 control the
> "sleep mode" state of lane 2, lane 1 and clock lane respectively, and should
> be LP11 in my opinion (that's the PHY stop state). However, setting them to
> 0x00 when starting the stream mean that LP00 is selected as the sleep state at
> stream start, and LP11 when stopping the stream. Maybe "sleep mode" means
> LPDT, but I would expect that to be controlled by the idle status bit in
> register 0x4800.
>

I did not need to mess with the accesses to 0x3019 in order to get
things working on my system. I'm not sure of this registers actual
behavior, but it might affect idling while not streaming (after power
on). My pipeline currently only powers the sensor while streaming, so
I might be missing some ramifications of this register.

> OV5640_REG_MIPI_CTRL00 (0x4800) is set to 0x04 in the large array of init mode
> data, and BIT(5) is then cleared at stream on time and set at stream off time.
> This means:
>
> - Clock lane gate enable: Clock lane is free running
> - Line sync enable: Do not send line short packets for each line (I assume
> that's LS/LE)
> - Lane select: Use lane1 as default data lane.
> - Idle status: MIPI bus will be LP11 when no packet to transmit. I would have
> expected the idle status to correspond to LPDT, and thus be LP00 (as opposed
> to the stop state that should be LP11, which I believe is named "sleep mode"
> in the datasheet and controlled in register 0x3019).
>
> BIT(5) is the clock lane gate enable, so at stream on time the clock is set to
> free running, and at stream off time to "Gate clock lane when no packet to
> transmit". Couldn't we always enable clock gating ?

Good question, it might be worth testing. Same as above, I didn't need
to mess with this reg either.

> Do you have any insight on this ? Have you modified the MIPI CSI-2
> configuration to get the CSI-2 output working ?
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>

Good news, MIPI is now working on my platform. I had to make several
changes to how the mipi clocking is calculated in order to get things
stable, but I think I got it figured out. Maxime's changes were really
helpful.

I will try to get some patches out today or 

RE: [RESEND PATCH v8 2/2] media: dw9807: Add dw9807 vcm driver

[Yeh, Andy]

Thanks for your kindly review.
Submitted v9 only with Reviewed/Acked-by. 

Regards, Andy

-Original Message-
From: jacopo mondi [mailto:jac...@jmondi.org] 
Sent: Wednesday, May 2, 2018 3:17 PM
To: Yeh, Andy 
Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; 
devicet...@vger.kernel.org; tf...@chromium.org; Chiang, AlanX 

Subject: Re: [RESEND PATCH v8 2/2] media: dw9807: Add dw9807 vcm driver

Hi Andy,
thanks for addressing comments on previous versions

On Wed, Apr 25, 2018 at 10:12:08AM +0800, Andy Yeh wrote:
> From: Alan Chiang 
>
> DW9807 is a 10 bit DAC from Dongwoon, designed for linear control of 
> voice coil motor.
>
> This driver creates a V4L2 subdevice and provides control to set the 
> desired focus.
>
> Signed-off-by: Andy Yeh 

Reviewed-by: Jacopo Mondi 

Thanks
   j

> ---
> since v1:
> - changed author.
> since v2:
> - addressed outstanding comments.
> - enabled sequential write to update 2 registers in a single transaction.
> since v3:
> - addressed comments for v3.
> - Remove redundant codes and declare some variables as constant variable.
> - separate DT binding to another patch since v4:
> - sent patchset included DT binding with cover page since v6:
> - change the return code of i2c_check
> - fix long cols exceed 80 chars
> - remove #define DW9807_NAME since only used once since v7:
> - Remove some redundant type cast
> - Modify to meet the coding style
> - Replace a while loop by readx_poll_timeout function
> - Return the i2c error directly.
>
>  MAINTAINERS|   7 +
>  drivers/media/i2c/Kconfig  |  10 ++
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/dw9807.c | 329 
> +
>  4 files changed, 347 insertions(+)
>  create mode 100644 drivers/media/i2c/dw9807.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS index 845fc25..a339bb5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4385,6 +4385,13 @@ T: git git://linuxtv.org/media_tree.git
>  S:   Maintained
>  F:   drivers/media/i2c/dw9714.c
>
> +DONGWOON DW9807 LENS VOICE COIL DRIVER
> +M:   Sakari Ailus 
> +L:   linux-media@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Maintained
> +F:   drivers/media/i2c/dw9807.c
> +
>  DOUBLETALK DRIVER
>  M:   "James R. Van Zandt" 
>  L:   blinux-l...@redhat.com
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig 
> index cb5d7ff..fd01842 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -325,6 +325,16 @@ config VIDEO_DW9714
> capability. This is designed for linear control of
> voice coil motors, controlled via I2C serial interface.
>
> +config VIDEO_DW9807
> + tristate "DW9807 lens voice coil support"
> + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + ---help---
> +   This is a driver for the DW9807 camera lens voice coil.
> +   DW9807 is a 10 bit DAC with 100mA output current sink
> +   capability. This is designed for linear control of
> +   voice coil motors, controlled via I2C serial interface.
> +
>  config VIDEO_SAA7110
>   tristate "Philips SAA7110 video decoder"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile 
> index 548a9ef..1b62639 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
>  obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
>  obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
>  obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
> +obj-$(CONFIG_VIDEO_DW9807)  += dw9807.o
>  obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
>  obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
>  obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o diff --git 
> a/drivers/media/i2c/dw9807.c b/drivers/media/i2c/dw9807.c new file 
> mode 100644 index 000..28ede2b
> --- /dev/null
> +++ b/drivers/media/i2c/dw9807.c
> @@ -0,0 +1,329 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2018 Intel Corporation
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DW9807_MAX_FOCUS_POS 1023
> +/*
> + * This sets the minimum granularity for the focus positions.
> + * A value of 1 gives maximum accuracy for a desired focus position.
> + */
> +#define DW9807_FOCUS_STEPS   1
> +/*
> + * This acts as the minimum granularity of lens movement.
> + * Keep this value power of 2, so the control steps can be
> + * uniformly adjusted for gradual lens movement, with desired
> + * number of control steps.
> + */
> +#define DW9807_CTRL_STEPS16
> +#define DW9807_CTRL_DELAY_US 1000
> +
> +#define DW9807_CTL_ADDR  0x02
> +/*
> + * DW9807 separates two registers to control the VCM position.
> + * One for MSB value, another is 

[RESEND PATCH v9 1/2] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

[Andy Yeh]

From: Alan Chiang 

Dongwoon DW9807 is a voice coil lens driver.

Signed-off-by: Andy Yeh 
Reviewed-by: Sakari Ailus 
Reviewed-by: Tomasz Figa 
Reviewed-by: Jacopo Mondi 
Acked-by: Rob Herring 

---
 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt 
b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
new file mode 100644
index 000..0a1a860
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
@@ -0,0 +1,9 @@
+Dongwoon Anatech DW9807 voice coil lens driver
+
+DW9807 is a 10-bit DAC with current sink capability. It is intended for
+controlling voice coil lenses.
+
+Mandatory properties:
+
+- compatible: "dongwoon,dw9807"
+- reg: I2C slave address
-- 
2.7.4

[RESEND PATCH v9 2/2] media: dw9807: Add dw9807 vcm driver

[Andy Yeh]

From: Alan Chiang 

DW9807 is a 10 bit DAC from Dongwoon, designed for linear
control of voice coil motor.

This driver creates a V4L2 subdevice and
provides control to set the desired focus.

Signed-off-by: Andy Yeh 
Reviewed-by: Sakari Ailus 
Reviewed-by: Tomasz Figa 
Reviewed-by: Jacopo Mondi 
Acked-by: Rob Herring 

---
since v1:
- changed author.
since v2:
- addressed outstanding comments.
- enabled sequential write to update 2 registers in a single transaction.
since v3:
- addressed comments for v3.
- Remove redundant codes and declare some variables as constant variable.
- separate DT binding to another patch
since v4:
- sent patchset included DT binding with cover page
since v6:
- change the return code of i2c_check
- fix long cols exceed 80 chars
- remove #define DW9807_NAME since only used once
since v7:
- Remove some redundant type cast
- Modify to meet the coding style
- Replace a while loop by readx_poll_timeout function
- Return the i2c error directly.
since v8:
- Added Reviewed-by and Acked-by

 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  10 ++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/dw9807.c | 329 +
 4 files changed, 347 insertions(+)
 create mode 100644 drivers/media/i2c/dw9807.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 845fc25..a339bb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4385,6 +4385,13 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/i2c/dw9714.c
 
+DONGWOON DW9807 LENS VOICE COIL DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/dw9807.c
+
 DOUBLETALK DRIVER
 M: "James R. Van Zandt" 
 L: blinux-l...@redhat.com
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff..fd01842 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -325,6 +325,16 @@ config VIDEO_DW9714
  capability. This is designed for linear control of
  voice coil motors, controlled via I2C serial interface.
 
+config VIDEO_DW9807
+   tristate "DW9807 lens voice coil support"
+   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+   depends on VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a driver for the DW9807 camera lens voice coil.
+ DW9807 is a 10 bit DAC with 100mA output current sink
+ capability. This is designed for linear control of
+ voice coil motors, controlled via I2C serial interface.
+
 config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..1b62639 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
 obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
 obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
 obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
+obj-$(CONFIG_VIDEO_DW9807)  += dw9807.o
 obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
 obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
 obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
diff --git a/drivers/media/i2c/dw9807.c b/drivers/media/i2c/dw9807.c
new file mode 100644
index 000..28ede2b
--- /dev/null
+++ b/drivers/media/i2c/dw9807.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DW9807_MAX_FOCUS_POS   1023
+/*
+ * This sets the minimum granularity for the focus positions.
+ * A value of 1 gives maximum accuracy for a desired focus position.
+ */
+#define DW9807_FOCUS_STEPS 1
+/*
+ * This acts as the minimum granularity of lens movement.
+ * Keep this value power of 2, so the control steps can be
+ * uniformly adjusted for gradual lens movement, with desired
+ * number of control steps.
+ */
+#define DW9807_CTRL_STEPS  16
+#define DW9807_CTRL_DELAY_US   1000
+
+#define DW9807_CTL_ADDR0x02
+/*
+ * DW9807 separates two registers to control the VCM position.
+ * One for MSB value, another is LSB value.
+ */
+#define DW9807_MSB_ADDR0x03
+#define DW9807_LSB_ADDR0x04
+#define DW9807_STATUS_ADDR 0x05
+#define DW9807_MODE_ADDR   0x06
+#define DW9807_RESONANCE_ADDR  0x07
+
+#define MAX_RETRY  10
+
+struct dw9807_device {
+   struct v4l2_ctrl_handler ctrls_vcm;
+   struct v4l2_subdev sd;
+   u16 current_val;
+};
+
+static inline struct dw9807_device *sd_to_dw9807_vcm(
+   struct v4l2_subdev *subdev)
+{
+   return container_of(subdev, struct dw9807_device, sd);
+}
+
+static int 

[RESEND PATCH v9 0/2] DW9807 DT binding and driver patches

[Andy Yeh]

Hi Sakari and Tomasz,

The two patches are the DT binding and driver for DW9807 VCM controller.

Alan Chiang (2):
  media: dw9807: Add dw9807 vcm driver
  media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

 .../bindings/media/i2c/dongwoon,dw9807.txt |   9 +
 MAINTAINERS|   7 +
 drivers/media/i2c/Kconfig  |  10 +
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/dw9807.c | 320 +
 5 files changed, 347 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt
 create mode 100644 drivers/media/i2c/dw9807.c

-- 
2.7.4

[PATCH v11] media: imx258: Add imx258 camera sensor driver

[Andy Yeh]

From: Jason Chen 

Add a V4L2 sub-device driver for the Sony IMX258 image sensor.
This is a camera sensor using the I2C bus for control and the
CSI-2 bus for data.

Signed-off-by: Andy Yeh 
Signed-off-by: Alan Chiang 
Reviewed-by: Sakari Ailus 
Reviewed-by: Tomasz Figa 

---
since v2:
-- Update the streaming function to remove SW_STANDBY in the beginning.
-- Adjust the delay time from 1ms to 12ms before set stream-on register.
since v3:
-- fix the sd.entity to make code be compiled on the mainline kernel.
since v4:
-- Enabled AG, DG, and Exposure time control correctly.
since v5:
-- Sensor vendor provided a new setting to fix different CLK issue
-- Add one more resolution for 1048x780, used for VGA streaming
since v6:
-- improved i2c read/write function to support writing 2 registers
-- modified i2c reg read/write function with a more portable way
-- utilized v4l2_find_nearest_size instead of the local find_best_fit function
-- defined an enum for the link freq entries for explicit indexing
since v7:
-- Removed usleep due to sufficient delay implemented in coreboot
-- Added handling for VBLANK control that auto frame-line-control is enabled
since v8:
-- Fix some error return and intents
since v9:
-- Fix a typo (fmr -> fmt)
since v9.1:
-- Add code for test pattern control
-- set vblank and read only since auto-FLL is enabled
since v10:
-- Implement test pattern feature: 
-- Output order of test pattern is always BGGR, so it needs a flip to rotate 
bayer pattern to required one (GRBG)


 MAINTAINERS|7 +
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/imx258.c | 1321 
 4 files changed, 1340 insertions(+)
 create mode 100644 drivers/media/i2c/imx258.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a339bb5..9f75510 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12646,6 +12646,13 @@ S: Maintained
 F: drivers/ssb/
 F: include/linux/ssb/
 
+SONY IMX258 SENSOR DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/imx258.c
+
 SONY IMX274 SENSOR DRIVER
 M: Leon Luo 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index fd01842..bcd4bf1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -565,6 +565,17 @@ config VIDEO_APTINA_PLL
 config VIDEO_SMIAPP_PLL
tristate
 
+config VIDEO_IMX258
+   tristate "Sony IMX258 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the Sony
+ IMX258 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx258.
+
 config VIDEO_IMX274
tristate "Sony IMX274 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 1b62639..4bf7d00 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)   += tc358743.o
+obj-$(CONFIG_VIDEO_IMX258) += imx258.o
 obj-$(CONFIG_VIDEO_IMX274) += imx274.o
 
 obj-$(CONFIG_SDR_MAX2175) += max2175.o
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
new file mode 100644
index 000..b2e6d06
--- /dev/null
+++ b/drivers/media/i2c/imx258.c
@@ -0,0 +1,1321 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMX258_REG_VALUE_08BIT 1
+#define IMX258_REG_VALUE_16BIT 2
+
+#define IMX258_REG_MODE_SELECT 0x0100
+#define IMX258_MODE_STANDBY0x00
+#define IMX258_MODE_STREAMING  0x01
+
+/* Chip ID */
+#define IMX258_REG_CHIP_ID 0x0016
+#define IMX258_CHIP_ID 0x0258
+
+/* V_TIMING internal */
+#define IMX258_VTS_30FPS   0x0c98
+#define IMX258_VTS_30FPS_2K0x0638
+#define IMX258_VTS_30FPS_VGA   0x034c
+#define IMX258_VTS_MAX 0x
+
+/*Frame Length Line*/
+#define IMX258_FLL_MIN 0x08a6
+#define IMX258_FLL_MAX 0x
+#define IMX258_FLL_STEP1
+#define IMX258_FLL_DEFAULT 0x0c98
+
+/* HBLANK control - read only */
+#define IMX258_PPL_DEFAULT 5352
+
+/* Exposure control */
+#define IMX258_REG_EXPOSURE0x0202
+#define IMX258_EXPOSURE_MIN4

Re: [PATCH 26/28] venus: implementing multi-stream support

[Vikash Garodia]

On 2018-05-02 18:58, Nicolas Dufresne wrote:

Le mercredi 02 mai 2018 à 13:10 +0530, Vikash Garodia a écrit :

Hello Stanimir,

On 2018-04-24 18:14, Stanimir Varbanov wrote:
> This is implementing a multi-stream decoder support. The multi
> stream gives an option to use the secondary decoder output
> with different raw format (or the same in case of crop).
>
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/media/platform/qcom/venus/core.h|   1 +
>  drivers/media/platform/qcom/venus/helpers.c | 204
> +++-
>  drivers/media/platform/qcom/venus/helpers.h |   6 +
>  drivers/media/platform/qcom/venus/vdec.c|  91 -
>  drivers/media/platform/qcom/venus/venc.c|   1 +
>  5 files changed, 299 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/core.h
> b/drivers/media/platform/qcom/venus/core.h
> index 4d6c05f156c4..85e66e2dd672 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -259,6 +259,7 @@ struct venus_inst {
>struct list_head list;
>struct mutex lock;
>struct venus_core *core;
> +  struct list_head dpbbufs;
>struct list_head internalbufs;
>struct list_head registeredbufs;
>struct list_head delayed_process;
> diff --git a/drivers/media/platform/qcom/venus/helpers.c
> b/drivers/media/platform/qcom/venus/helpers.c
> index ed569705ecac..87dcf9973e6f 100644
> --- a/drivers/media/platform/qcom/venus/helpers.c
> +++ b/drivers/media/platform/qcom/venus/helpers.c
> @@ -85,6 +85,112 @@ bool venus_helper_check_codec(struct venus_inst
> *inst, u32 v4l2_pixfmt)
>  }
>  EXPORT_SYMBOL_GPL(venus_helper_check_codec);
>
> +static int venus_helper_queue_dpb_bufs(struct venus_inst *inst)
> +{
> +  struct intbuf *buf;
> +  int ret = 0;
> +
> +  if (list_empty(>dpbbufs))
> +  return 0;
> +
> +  list_for_each_entry(buf, >dpbbufs, list) {
> +  struct hfi_frame_data fdata;
> +
> +  memset(, 0, sizeof(fdata));
> +  fdata.alloc_len = buf->size;
> +  fdata.device_addr = buf->da;
> +  fdata.buffer_type = buf->type;
> +
> +  ret = hfi_session_process_buf(inst, );
> +  if (ret)
> +  goto fail;
> +  }
> +
> +fail:
> +  return ret;
> +}
> +
> +int venus_helper_free_dpb_bufs(struct venus_inst *inst)
> +{
> +  struct intbuf *buf, *n;
> +
> +  if (list_empty(>dpbbufs))
> +  return 0;
> +
> +  list_for_each_entry_safe(buf, n, >dpbbufs, list) {
> +  list_del_init(>list);
> +  dma_free_attrs(inst->core->dev, buf->size, buf-
> >va, buf->da,
> + buf->attrs);
> +  kfree(buf);
> +  }
> +
> +  INIT_LIST_HEAD(>dpbbufs);
> +
> +  return 0;
> +}
> +EXPORT_SYMBOL_GPL(venus_helper_free_dpb_bufs);
> +
> +int venus_helper_alloc_dpb_bufs(struct venus_inst *inst)
> +{
> +  struct venus_core *core = inst->core;
> +  struct device *dev = core->dev;
> +  enum hfi_version ver = core->res->hfi_version;
> +  struct hfi_buffer_requirements bufreq;
> +  u32 buftype = inst->dpb_buftype;
> +  unsigned int dpb_size = 0;
> +  struct intbuf *buf;
> +  unsigned int i;
> +  u32 count;
> +  int ret;
> +
> +  /* no need to allocate dpb buffers */
> +  if (!inst->dpb_fmt)
> +  return 0;
> +
> +  if (inst->dpb_buftype == HFI_BUFFER_OUTPUT)
> +  dpb_size = inst->output_buf_size;
> +  else if (inst->dpb_buftype == HFI_BUFFER_OUTPUT2)
> +  dpb_size = inst->output2_buf_size;
> +
> +  if (!dpb_size)
> +  return 0;
> +
> +  ret = venus_helper_get_bufreq(inst, buftype, );
> +  if (ret)
> +  return ret;
> +
> +  count = HFI_BUFREQ_COUNT_MIN(, ver);
> +
> +  for (i = 0; i < count; i++) {
> +  buf = kzalloc(sizeof(*buf), GFP_KERNEL);
> +  if (!buf) {
> +  ret = -ENOMEM;
> +  goto fail;
> +  }
> +
> +  buf->type = buftype;
> +  buf->size = dpb_size;
> +  buf->attrs = DMA_ATTR_WRITE_COMBINE |
> +   DMA_ATTR_NO_KERNEL_MAPPING;
> +  buf->va = dma_alloc_attrs(dev, buf->size, 
> >da, GFP_KERNEL,
> +buf->attrs);
> +  if (!buf->va) {
> +  kfree(buf);
> +  ret = -ENOMEM;
> +  goto fail;
> +  }
> +
> +  list_add_tail(>list, >dpbbufs);
> +  }
> +
> +  return 0;
> +
> +fail:
> +  venus_helper_free_dpb_bufs(inst);
> +  return ret;
> +}
> +EXPORT_SYMBOL_GPL(venus_helper_alloc_dpb_bufs);
> +
>  static int intbufs_set_buffer(struct venus_inst *inst, u32 type)
>  {
>struct venus_core *core = inst->core;
> @@ -342,7 +448,10 @@ session_process_buf(struct venus_inst *inst,
> struct vb2_v4l2_buffer *vbuf)
>if (vbuf->flags & V4L2_BUF_FLAG_LAST ||
> !fdata.filled_len)
>fdata.flags |= HFI_BUFFERFLAG_EOS;
>} else if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> -  fdata.buffer_type = 

Re: [PATCH 26/28] venus: implementing multi-stream support

[Nicolas Dufresne]

Le mercredi 02 mai 2018 à 13:10 +0530, Vikash Garodia a écrit :
> Hello Stanimir,
> 
> On 2018-04-24 18:14, Stanimir Varbanov wrote:
> > This is implementing a multi-stream decoder support. The multi
> > stream gives an option to use the secondary decoder output
> > with different raw format (or the same in case of crop).
> > 
> > Signed-off-by: Stanimir Varbanov 
> > ---
> >  drivers/media/platform/qcom/venus/core.h|   1 +
> >  drivers/media/platform/qcom/venus/helpers.c | 204 
> > +++-
> >  drivers/media/platform/qcom/venus/helpers.h |   6 +
> >  drivers/media/platform/qcom/venus/vdec.c|  91 -
> >  drivers/media/platform/qcom/venus/venc.c|   1 +
> >  5 files changed, 299 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/media/platform/qcom/venus/core.h
> > b/drivers/media/platform/qcom/venus/core.h
> > index 4d6c05f156c4..85e66e2dd672 100644
> > --- a/drivers/media/platform/qcom/venus/core.h
> > +++ b/drivers/media/platform/qcom/venus/core.h
> > @@ -259,6 +259,7 @@ struct venus_inst {
> > struct list_head list;
> > struct mutex lock;
> > struct venus_core *core;
> > +   struct list_head dpbbufs;
> > struct list_head internalbufs;
> > struct list_head registeredbufs;
> > struct list_head delayed_process;
> > diff --git a/drivers/media/platform/qcom/venus/helpers.c
> > b/drivers/media/platform/qcom/venus/helpers.c
> > index ed569705ecac..87dcf9973e6f 100644
> > --- a/drivers/media/platform/qcom/venus/helpers.c
> > +++ b/drivers/media/platform/qcom/venus/helpers.c
> > @@ -85,6 +85,112 @@ bool venus_helper_check_codec(struct venus_inst
> > *inst, u32 v4l2_pixfmt)
> >  }
> >  EXPORT_SYMBOL_GPL(venus_helper_check_codec);
> > 
> > +static int venus_helper_queue_dpb_bufs(struct venus_inst *inst)
> > +{
> > +   struct intbuf *buf;
> > +   int ret = 0;
> > +
> > +   if (list_empty(>dpbbufs))
> > +   return 0;
> > +
> > +   list_for_each_entry(buf, >dpbbufs, list) {
> > +   struct hfi_frame_data fdata;
> > +
> > +   memset(, 0, sizeof(fdata));
> > +   fdata.alloc_len = buf->size;
> > +   fdata.device_addr = buf->da;
> > +   fdata.buffer_type = buf->type;
> > +
> > +   ret = hfi_session_process_buf(inst, );
> > +   if (ret)
> > +   goto fail;
> > +   }
> > +
> > +fail:
> > +   return ret;
> > +}
> > +
> > +int venus_helper_free_dpb_bufs(struct venus_inst *inst)
> > +{
> > +   struct intbuf *buf, *n;
> > +
> > +   if (list_empty(>dpbbufs))
> > +   return 0;
> > +
> > +   list_for_each_entry_safe(buf, n, >dpbbufs, list) {
> > +   list_del_init(>list);
> > +   dma_free_attrs(inst->core->dev, buf->size, buf-
> > >va, buf->da,
> > +  buf->attrs);
> > +   kfree(buf);
> > +   }
> > +
> > +   INIT_LIST_HEAD(>dpbbufs);
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(venus_helper_free_dpb_bufs);
> > +
> > +int venus_helper_alloc_dpb_bufs(struct venus_inst *inst)
> > +{
> > +   struct venus_core *core = inst->core;
> > +   struct device *dev = core->dev;
> > +   enum hfi_version ver = core->res->hfi_version;
> > +   struct hfi_buffer_requirements bufreq;
> > +   u32 buftype = inst->dpb_buftype;
> > +   unsigned int dpb_size = 0;
> > +   struct intbuf *buf;
> > +   unsigned int i;
> > +   u32 count;
> > +   int ret;
> > +
> > +   /* no need to allocate dpb buffers */
> > +   if (!inst->dpb_fmt)
> > +   return 0;
> > +
> > +   if (inst->dpb_buftype == HFI_BUFFER_OUTPUT)
> > +   dpb_size = inst->output_buf_size;
> > +   else if (inst->dpb_buftype == HFI_BUFFER_OUTPUT2)
> > +   dpb_size = inst->output2_buf_size;
> > +
> > +   if (!dpb_size)
> > +   return 0;
> > +
> > +   ret = venus_helper_get_bufreq(inst, buftype, );
> > +   if (ret)
> > +   return ret;
> > +
> > +   count = HFI_BUFREQ_COUNT_MIN(, ver);
> > +
> > +   for (i = 0; i < count; i++) {
> > +   buf = kzalloc(sizeof(*buf), GFP_KERNEL);
> > +   if (!buf) {
> > +   ret = -ENOMEM;
> > +   goto fail;
> > +   }
> > +
> > +   buf->type = buftype;
> > +   buf->size = dpb_size;
> > +   buf->attrs = DMA_ATTR_WRITE_COMBINE |
> > +DMA_ATTR_NO_KERNEL_MAPPING;
> > +   buf->va = dma_alloc_attrs(dev, buf->size, 
> > >da, GFP_KERNEL,
> > + buf->attrs);
> > +   if (!buf->va) {
> > +   kfree(buf);
> > +   ret = -ENOMEM;
> > +   goto fail;
> > +   }
> > +
> > +   list_add_tail(>list, >dpbbufs);
> > +   }
> > +
> > +   return 0;
> > +
> > +fail:
> > +   venus_helper_free_dpb_bufs(inst);
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(venus_helper_alloc_dpb_bufs);
> > +
> >  static int intbufs_set_buffer(struct venus_inst *inst, u32 type)
> >  {
> > struct venus_core *core = 

Re: [PATCH v14 03/33] rcar-vin: add Gen3 devicetree bindings documentation

[Geert Uytterhoeven]

Hi Niklas,

Some comments, triggered by seeing Simon's "[PATCH 00/10]
ARM, arm64: dts: renesas: update register properties"  series.

On Sat, Apr 14, 2018 at 1:56 PM, Niklas Söderlund
 wrote:
> Document the devicetree bindings for the CSI-2 inputs available on Gen3.
>
> There is a need to add a custom property 'renesas,id' and to define
> which CSI-2 input is described in which endpoint under the port@1 node.
> This information is needed since there are a set of predefined routes
> between each VIN and CSI-2 block. This routing table will be kept
> inside the driver but in order for it to act on it it must know which
> VIN and CSI-2 is which.
>
> Signed-off-by: Niklas Söderlund 
> Acked-by: Rob Herring 
> Reviewed-by: Laurent Pinchart 

> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
>  ---
>
>  The rcar_vin device provides video input capabilities for the Renesas R-Car
> -family of devices. The current blocks are always slaves and suppot one input
> -channel which can be either RGB, YUYV or BT656.
> +family of devices.
> +
> +Each VIN instance has a single parallel input that supports RGB and YUV 
> video,
> +with both external synchronization and BT.656 synchronization for the latter.
> +Depending on the instance the VIN input is connected to external SoC pins, or
> +on Gen3 platforms to a CSI-2 receiver.
>
>   - compatible: Must be one or more of the following
> - "renesas,vin-r8a7743" for the R8A7743 device
> @@ -16,6 +20,8 @@ channel which can be either RGB, YUYV or BT656.
> - "renesas,vin-r8a7793" for the R8A7793 device
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> +   - "renesas,vin-r8a7796" for the R8A7796 device
> +   - "renesas,vin-r8a77970" for the R8A77970 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
>   device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
> @@ -31,21 +37,38 @@ channel which can be either RGB, YUYV or BT656.
>  Additionally, an alias named vinX will need to be created to specify
>  which video input device this is.
>
> -The per-board settings:
> +The per-board settings Gen2 platforms:
>   - port sub-node describing a single endpoint connected to the vin
> as described in video-interfaces.txt[1]. Only the first one will
> be considered as each vin interface has one input port.
>
> -   These settings are used to work out video input format and widths
> -   into the system.
> +The per-board settings Gen3 platforms:
>
> +Gen3 platforms can support both a single connected parallel input source
> +from external SoC pins (port0) and/or multiple parallel input sources

port@0?

> +from local SoC CSI-2 receivers (port1) depending on SoC.

port@1?

>
> -Device node example
> 
> +- renesas,id - ID number of the VIN, VINx in the documentation.
> +- ports
> +- port 0 - sub-node describing a single endpoint connected to the VIN

port@0?

> +  from external SoC pins described in video-interfaces.txt[1].
> +  Describing more then one endpoint in port 0 is invalid. Only VIN

port@0?

> +  instances that are connected to external pins should have port 0.

port@0?

> +- port 1 - sub-nodes describing one or more endpoints connected to

port@1?

> +  the VIN from local SoC CSI-2 receivers. The endpoint numbers must
> +  use the following schema.
>
> -   aliases {
> -  vin0 = 
> -   };
> +- Endpoint 0 - sub-node describing the endpoint connected to CSI20

endpoint@0 (lower case and unit address)?

> +- Endpoint 1 - sub-node describing the endpoint connected to CSI21

endpoint@1?

> +- Endpoint 2 - sub-node describing the endpoint connected to CSI40

endpoint@2?

> +- Endpoint 3 - sub-node describing the endpoint connected to CSI41

endpoint@3?

> +
> +Device node example for Gen2 platforms
> +--
> +
> +aliases {
> +vin0 = 
> +};
>
>  vin0: vin@e6ef {
>  compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin";
> @@ -55,8 +78,8 @@ Device node example
>  status = "disabled";
>  };
>
> -Board setup example (vin1 composite video input)
> -
> +Board setup example for Gen2 platforms (vin1 composite video input)
> +---
>
> {
>  status = "okay";
> @@ -95,6 +118,77 @@ Board setup example (vin1 composite video input)
>  };
>  };
>
> +Device node example for Gen3 platforms
> 

Re: [RFCv12 PATCH 03/29] media-request: implement media requests

[Hans Verkuil]

On 01/05/18 11:00, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add initial media request support.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/Makefile|   3 +-
>  drivers/media/media-device.c  |  13 ++
>  drivers/media/media-request.c | 418 ++
>  include/media/media-device.h  |  17 ++
>  include/media/media-request.h | 193 
>  5 files changed, 643 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/media-request.c
>  create mode 100644 include/media/media-request.h
> 
> diff --git a/drivers/media/Makefile b/drivers/media/Makefile
> index 594b462ddf0e..985d35ec6b29 100644
> --- a/drivers/media/Makefile
> +++ b/drivers/media/Makefile
> @@ -3,7 +3,8 @@
>  # Makefile for the kernel multimedia device drivers.
>  #
>  
> -media-objs   := media-device.o media-devnode.o media-entity.o
> +media-objs   := media-device.o media-devnode.o media-entity.o \
> +media-request.o
>  
>  #
>  # I2C drivers should come before other drivers, otherwise they'll fail
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 35e81f7c0d2f..25d7e2a3ee84 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_MEDIA_CONTROLLER
>  
> @@ -366,6 +367,15 @@ static long media_device_get_topology(struct 
> media_device *mdev,
>   return ret;
>  }
>  
> +static long media_device_request_alloc(struct media_device *mdev,
> +struct media_request_alloc *alloc)
> +{
> + if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
> + return -ENOTTY;
> +
> + return media_request_alloc(mdev, alloc);
> +}
> +
>  static long copy_arg_from_user(void *karg, void __user *uarg, unsigned int 
> cmd)
>  {
>   /* All media IOCTLs are _IOWR() */
> @@ -414,6 +424,7 @@ static const struct media_ioctl_info ioctl_info[] = {
>   MEDIA_IOC(ENUM_LINKS, media_device_enum_links, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
>   MEDIA_IOC(SETUP_LINK, media_device_setup_link, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
>   MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, 
> MEDIA_IOC_FL_GRAPH_MUTEX),
> + MEDIA_IOC(REQUEST_ALLOC, media_device_request_alloc, 0),
>  };
>  
>  static long media_device_ioctl(struct file *filp, unsigned int cmd,
> @@ -686,6 +697,8 @@ void media_device_init(struct media_device *mdev)
>   INIT_LIST_HEAD(>pads);
>   INIT_LIST_HEAD(>links);
>   INIT_LIST_HEAD(>entity_notify);
> +
> + mutex_init(>req_queue_mutex);
>   mutex_init(>graph_mutex);
>   ida_init(>entity_internal_idx);
>  
> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> new file mode 100644
> index ..22881d5700c8
> --- /dev/null
> +++ b/drivers/media/media-request.c
> @@ -0,0 +1,418 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Media device request objects
> + *
> + * Copyright (C) 2018 Intel Corporation
> + * Copyright (C) 2018 Google, Inc.
> + *
> + * Author: Sakari Ailus 
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static const char * const request_state[] = {
> + [MEDIA_REQUEST_STATE_IDLE]   = "idle",
> + [MEDIA_REQUEST_STATE_VALIDATING] = "validating",
> + [MEDIA_REQUEST_STATE_QUEUED] = "queued",
> + [MEDIA_REQUEST_STATE_COMPLETE]   = "complete",
> + [MEDIA_REQUEST_STATE_CLEANING]   = "cleaning",
> +};
> +
> +static const char *
> +media_request_state_str(enum media_request_state state)
> +{
> + if (WARN_ON(state >= ARRAY_SIZE(request_state)))
> + return "unknown";
> + return request_state[state];
> +}
> +
> +static void media_request_clean(struct media_request *req)
> +{
> + struct media_request_object *obj, *obj_safe;
> +
> + WARN_ON(atomic_read(>state) != MEDIA_REQUEST_STATE_CLEANING);
> +
> + list_for_each_entry_safe(obj, obj_safe, >objects, list) {
> + media_request_object_unbind(obj);
> + media_request_object_put(obj);
> + }
> +
> + req->num_incomplete_objects = 0;
> + wake_up_interruptible_all(>poll_wait);
> +}
> +
> +static void media_request_release(struct kref *kref)
> +{
> + struct media_request *req =
> + container_of(kref, struct media_request, kref);
> + struct media_device *mdev = req->mdev;
> +
> + dev_dbg(mdev->dev, "request: release %s\n", req->debug_str);
> +
> + atomic_set(>state, MEDIA_REQUEST_STATE_CLEANING);
> +
> + media_request_clean(req);
> +
> + if (mdev->ops->req_free)
> + mdev->ops->req_free(req);
> + else
> + kfree(req);
> +}
> +
> +void media_request_put(struct media_request *req)
> +{
> + kref_put(>kref, media_request_release);
> +}
> +EXPORT_SYMBOL_GPL(media_request_put);
> +
> +void media_request_cancel(struct 

[PATCH][media-next][V2] media: davinci_vpfe: fix memory leaks of params

[Colin King]

From: Colin Ian King 

There are memory leaks of params; when copy_to_user fails and also
the exit via the label 'error'. Also, there is a bogos memory allocation
check on pointer 'to' when memory allocation fails on params.

Fix this by kfree'ing params in error exit path and jumping to this on
the copy_to_user failure path.  Also check the to see if the allocation
of params fails and remove the bogus null pointer checks on pointer 'to'.

Also explicitly return 0 on success rather than rval.

Detected by CoverityScan, CID#1467966 ("Resource leak")

Fixes: da43b6ccadcf ("[media] davinci: vpfe: dm365: add IPIPE support for media 
controller driver")
Signed-off-by: Colin Ian King 
---

V2: Add checks on allocation of params.  Remove bogus checks on
pointer 'to'. Explicitly return 0 on success. Thanks to
Dan Carpenter for the suggested improvements.

---
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 95942768639c..b135e38a18b3 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1252,12 +1252,12 @@ static const struct ipipe_module_if 
ipipe_modules[VPFE_IPIPE_MAX_MODULES] = {
 static int ipipe_s_config(struct v4l2_subdev *sd, struct vpfe_ipipe_config 
*cfg)
 {
struct vpfe_ipipe_device *ipipe = v4l2_get_subdevdata(sd);
+   struct ipipe_module_params *params;
unsigned int i;
int rval = 0;
 
for (i = 0; i < ARRAY_SIZE(ipipe_modules); i++) {
const struct ipipe_module_if *module_if;
-   struct ipipe_module_params *params;
void *from, *to;
size_t size;
 
@@ -1269,25 +1269,31 @@ static int ipipe_s_config(struct v4l2_subdev *sd, 
struct vpfe_ipipe_config *cfg)
 
params = kmalloc(sizeof(struct ipipe_module_params),
 GFP_KERNEL);
+   if (!params) {
+   rval = -ENOMEM;
+   goto error;
+   }
to = (void *)params + module_if->param_offset;
size = module_if->param_size;
 
-   if (to && from && size) {
+   if (from && size) {
if (copy_from_user(to, (void __user *)from, size)) {
rval = -EFAULT;
-   break;
+   goto error;
}
rval = module_if->set(ipipe, to);
if (rval)
goto error;
-   } else if (to && !from && size) {
+   } else if (!from && size) {
rval = module_if->set(ipipe, NULL);
if (rval)
goto error;
}
kfree(params);
}
+   return 0;
 error:
+   kfree(params);
return rval;
 }
 
-- 
2.17.0

Re: [PATCH][media-next] media: davinci_vpfe: fix memory leaks of params

[Dan Carpenter]

On Wed, May 02, 2018 at 10:16:58AM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> There are memory leaks of params; when copy_to_user fails and also
> the exit via the label 'error'.  Fix this by kfree'ing params in
> error exit path and jumping to this on the copy_to_user failure path.
> 
> Detected by CoverityScan, CID#1467966 ("Resource leak")
> 
> Fixes: da43b6ccadcf ("[media] davinci: vpfe: dm365: add IPIPE support for 
> media controller driver")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
> b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> index 95942768639c..3e67ee6e92f9 100644
> --- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
> @@ -1252,12 +1252,12 @@ static const struct ipipe_module_if 
> ipipe_modules[VPFE_IPIPE_MAX_MODULES] = {
>  static int ipipe_s_config(struct v4l2_subdev *sd, struct vpfe_ipipe_config 
> *cfg)
>  {
>   struct vpfe_ipipe_device *ipipe = v4l2_get_subdevdata(sd);
> + struct ipipe_module_params *params;
>   unsigned int i;
>   int rval = 0;
>  
>   for (i = 0; i < ARRAY_SIZE(ipipe_modules); i++) {
>   const struct ipipe_module_if *module_if;
> - struct ipipe_module_params *params;
>   void *from, *to;
>   size_t size;
>  
> @@ -1275,7 +1275,7 @@ static int ipipe_s_config(struct v4l2_subdev *sd, 
> struct vpfe_ipipe_config *cfg)
>   if (to && from && size) {
^^

This "to" check is wrong.  Say "params" is NULL and
module_if->param_offset is non-zero then "to" is a bogus pointer.  We
should just test "params" and give up the first time an allocation
fails.

>   if (copy_from_user(to, (void __user *)from, size)) {
>   rval = -EFAULT;
> - break;
> + goto error;
>   }
>   rval = module_if->set(ipipe, to);
>   if (rval)
> @@ -1287,7 +1287,9 @@ static int ipipe_s_config(struct v4l2_subdev *sd, 
> struct vpfe_ipipe_config *cfg)
>   }
>   kfree(params);
>   }
> + return rval;

Doing a "return 0;" is more readable than "return rval;".

regards,
dan carpenter

[PATCH][media-next] media: davinci_vpfe: fix memory leaks of params

[Colin King]

From: Colin Ian King 

There are memory leaks of params; when copy_to_user fails and also
the exit via the label 'error'.  Fix this by kfree'ing params in
error exit path and jumping to this on the copy_to_user failure path.

Detected by CoverityScan, CID#1467966 ("Resource leak")

Fixes: da43b6ccadcf ("[media] davinci: vpfe: dm365: add IPIPE support for media 
controller driver")
Signed-off-by: Colin Ian King 
---
 drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c 
b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
index 95942768639c..3e67ee6e92f9 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe.c
@@ -1252,12 +1252,12 @@ static const struct ipipe_module_if 
ipipe_modules[VPFE_IPIPE_MAX_MODULES] = {
 static int ipipe_s_config(struct v4l2_subdev *sd, struct vpfe_ipipe_config 
*cfg)
 {
struct vpfe_ipipe_device *ipipe = v4l2_get_subdevdata(sd);
+   struct ipipe_module_params *params;
unsigned int i;
int rval = 0;
 
for (i = 0; i < ARRAY_SIZE(ipipe_modules); i++) {
const struct ipipe_module_if *module_if;
-   struct ipipe_module_params *params;
void *from, *to;
size_t size;
 
@@ -1275,7 +1275,7 @@ static int ipipe_s_config(struct v4l2_subdev *sd, struct 
vpfe_ipipe_config *cfg)
if (to && from && size) {
if (copy_from_user(to, (void __user *)from, size)) {
rval = -EFAULT;
-   break;
+   goto error;
}
rval = module_if->set(ipipe, to);
if (rval)
@@ -1287,7 +1287,9 @@ static int ipipe_s_config(struct v4l2_subdev *sd, struct 
vpfe_ipipe_config *cfg)
}
kfree(params);
}
+   return rval;
 error:
+   kfree(params);
return rval;
 }
 
-- 
2.17.0

Re: [PATCHv5, 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Hans Verkuil]

On 02/05/18 10:24, Dariusz Marcinkiewicz wrote:
> Hello, pretty late here but I have a small comment.
> 
> 
>> From: Hans Verkuil 
> 
>> This adds support for the DisplayPort CEC-Tunneling-over-AUX
>> feature that is part of the DisplayPort 1.3 standard.
> 
> 
>> +int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char
> *name,
>> +struct device *parent, const struct edid
> *edid)
>> +{
>> +   u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD;
> It seems there is a slight issue here when kernel is compiled w/o
> CONFIG_MEDIA_CEC_RC, in such case
> https://github.com/torvalds/linux/blob/master/drivers/media/cec/cec-core.c#L255
> strips CEC_CAP_RC from the adapter's caps. As a result the below check
> always fails and a new adapter is created every time this is run.

Ah, good one. I missed that.

I've fixed it in my tree.

I still haven't had the time to finish this patch series :-(
It's high on my TODO list, but not high enough yet...

Regards,

Hans

> 
>> +   if (aux->cec_adap->capabilities == cec_caps &&
>> +   aux->cec_adap->available_log_addrs == num_las) {
>> +   cec_s_phys_addr_from_edid(aux->cec_adap, edid);
>> +   return 0;
>> +   }
>> +   cec_unregister_adapter(aux->cec_adap);
>> +   }
>> +
> ...
> 
> Thank you and best regards.
> 

Re: [PATCHv5, 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Dariusz Marcinkiewicz]

Hello, pretty late here but I have a small comment.


> From: Hans Verkuil 

> This adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature that is part of the DisplayPort 1.3 standard.


> +int drm_dp_cec_configure_adapter(struct drm_dp_aux *aux, const char
*name,
> +struct device *parent, const struct edid
*edid)
> +{
> +   u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD;
It seems there is a slight issue here when kernel is compiled w/o
CONFIG_MEDIA_CEC_RC, in such case
https://github.com/torvalds/linux/blob/master/drivers/media/cec/cec-core.c#L255
strips CEC_CAP_RC from the adapter's caps. As a result the below check
always fails and a new adapter is created every time this is run.

> +   if (aux->cec_adap->capabilities == cec_caps &&
> +   aux->cec_adap->available_log_addrs == num_las) {
> +   cec_s_phys_addr_from_edid(aux->cec_adap, edid);
> +   return 0;
> +   }
> +   cec_unregister_adapter(aux->cec_adap);
> +   }
> +
...

Thank you and best regards.

Re: [RFCv12 PATCH 21/29] videobuf2-v4l2: export request_fd

[Hans Verkuil]

On 01/05/18 11:00, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Requested by Sakari

This should have been merged with patch 18, I forgot about that. Will be done 
in v13.

Regards,

Hans

> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/common/videobuf2/videobuf2-v4l2.c | 6 --
>  include/media/videobuf2-v4l2.h  | 2 ++
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 7fced0a503f4..b6142041418e 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -184,6 +184,7 @@ static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer 
> *vb, struct v4l2_buffer *b
>   return -EINVAL;
>   }
>   vbuf->sequence = 0;
> + vbuf->request_fd = -1;
>  
>   if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
>   switch (b->memory) {
> @@ -399,6 +400,7 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q, 
> struct media_device *md
>   }
>  
>   *p_req = req;
> + vbuf->request_fd = b->request_fd;
>  
>   return 0;
>  }
> @@ -504,9 +506,9 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
> void *pb)
>  
>   if (vb2_buffer_in_use(q, vb))
>   b->flags |= V4L2_BUF_FLAG_MAPPED;
> - if (vb->req_obj.req) {
> + if (vbuf->request_fd >= 0) {
>   b->flags |= V4L2_BUF_FLAG_REQUEST_FD;
> - b->request_fd = -1;
> + b->request_fd = vbuf->request_fd;
>   }
>  
>   if (!q->is_output &&
> diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
> index 33210221a621..727855463838 100644
> --- a/include/media/videobuf2-v4l2.h
> +++ b/include/media/videobuf2-v4l2.h
> @@ -32,6 +32,7 @@
>   *v4l2_field.
>   * @timecode:frame timecode.
>   * @sequence:sequence count of this frame.
> + * @request_fd:  the request_fd associated with this buffer
>   * @planes:  plane information (userptr/fd, length, bytesused, data_offset).
>   *
>   * Should contain enough information to be able to cover all the fields
> @@ -44,6 +45,7 @@ struct vb2_v4l2_buffer {
>   __u32   field;
>   struct v4l2_timecodetimecode;
>   __u32   sequence;
> + __s32   request_fd;
>   struct vb2_planeplanes[VB2_MAX_PLANES];
>  };
>  
> 

Re: [RFCv12 PATCH 04/29] v4l2-dev: lock req_queue_mutex

[Hans Verkuil]

On 01/05/18 11:00, Hans Verkuil wrote:
> From: Hans Verkuil 
> 

Oops, missing commit log. That should be:

We need to serialize streamon/off with queueing new requests.
These ioctls may trigger the cancellation of a streaming
operation, and that should not be mixed with queuing a new
request at the same time.

Also TRY/S_EXT_CTRLS needs this lock to correctly serialize
with MEDIA_REQUEST_IOC_QUEUE.

Finally close() needs this lock since that too can trigger the
cancellation of a streaming operation.

We take the req_queue_mutex here before any other locks since
it is a very high-level lock.

Hans

> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/v4l2-core/v4l2-dev.c | 37 +-
>  1 file changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
> b/drivers/media/v4l2-core/v4l2-dev.c
> index 1d0b2208e8fb..3368bd5537a7 100644
> --- a/drivers/media/v4l2-core/v4l2-dev.c
> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> @@ -353,13 +353,36 @@ static long v4l2_ioctl(struct file *filp, unsigned int 
> cmd, unsigned long arg)
>  
>   if (vdev->fops->unlocked_ioctl) {
>   struct mutex *lock = v4l2_ioctl_get_lock(vdev, cmd);
> + struct mutex *queue_lock = NULL;
>  
> - if (lock && mutex_lock_interruptible(lock))
> + /*
> +  * We need to serialize streamon/off with queuing new requests.
> +  * These ioctls may trigger the cancellation of a streaming
> +  * operation, and that should not be mixed with queuing a new
> +  * request at the same time.
> +  *
> +  * Also TRY/S_EXT_CTRLS needs this lock to correctly serialize
> +  * with MEDIA_REQUEST_IOC_QUEUE.
> +  */
> + if (vdev->v4l2_dev->mdev &&
> + (cmd == VIDIOC_STREAMON || cmd == VIDIOC_STREAMOFF ||
> +  cmd == VIDIOC_S_EXT_CTRLS || cmd == VIDIOC_TRY_EXT_CTRLS))
> + queue_lock = >v4l2_dev->mdev->req_queue_mutex;
> +
> + if (queue_lock && mutex_lock_interruptible(queue_lock))
> + return -ERESTARTSYS;
> +
> + if (lock && mutex_lock_interruptible(lock)) {
> + if (queue_lock)
> + mutex_unlock(queue_lock);
>   return -ERESTARTSYS;
> + }
>   if (video_is_registered(vdev))
>   ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
>   if (lock)
>   mutex_unlock(lock);
> + if (queue_lock)
> + mutex_unlock(queue_lock);
>   } else
>   ret = -ENOTTY;
>  
> @@ -442,8 +465,20 @@ static int v4l2_release(struct inode *inode, struct file 
> *filp)
>   struct video_device *vdev = video_devdata(filp);
>   int ret = 0;
>  
> + /*
> +  * We need to serialize the release() with queuing new requests.
> +  * The release() may trigger the cancellation of a streaming
> +  * operation, and that should not be mixed with queuing a new
> +  * request at the same time.
> +  */
> + if (vdev->v4l2_dev->mdev)
> + mutex_lock(>v4l2_dev->mdev->req_queue_mutex);
> +
>   if (vdev->fops->release)
>   ret = vdev->fops->release(filp);
> +
> + if (vdev->v4l2_dev->mdev)
> + mutex_unlock(>v4l2_dev->mdev->req_queue_mutex);
>   if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
>   printk(KERN_DEBUG "%s: release\n",
>   video_device_node_name(vdev));
> 

Re: [PATCH 26/28] venus: implementing multi-stream support

[Vikash Garodia]

Hello Stanimir,

On 2018-04-24 18:14, Stanimir Varbanov wrote:

This is implementing a multi-stream decoder support. The multi
stream gives an option to use the secondary decoder output
with different raw format (or the same in case of crop).

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/core.h|   1 +
 drivers/media/platform/qcom/venus/helpers.c | 204 
+++-

 drivers/media/platform/qcom/venus/helpers.h |   6 +
 drivers/media/platform/qcom/venus/vdec.c|  91 -
 drivers/media/platform/qcom/venus/venc.c|   1 +
 5 files changed, 299 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 4d6c05f156c4..85e66e2dd672 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -259,6 +259,7 @@ struct venus_inst {
struct list_head list;
struct mutex lock;
struct venus_core *core;
+   struct list_head dpbbufs;
struct list_head internalbufs;
struct list_head registeredbufs;
struct list_head delayed_process;
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index ed569705ecac..87dcf9973e6f 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -85,6 +85,112 @@ bool venus_helper_check_codec(struct venus_inst
*inst, u32 v4l2_pixfmt)
 }
 EXPORT_SYMBOL_GPL(venus_helper_check_codec);

+static int venus_helper_queue_dpb_bufs(struct venus_inst *inst)
+{
+   struct intbuf *buf;
+   int ret = 0;
+
+   if (list_empty(>dpbbufs))
+   return 0;
+
+   list_for_each_entry(buf, >dpbbufs, list) {
+   struct hfi_frame_data fdata;
+
+   memset(, 0, sizeof(fdata));
+   fdata.alloc_len = buf->size;
+   fdata.device_addr = buf->da;
+   fdata.buffer_type = buf->type;
+
+   ret = hfi_session_process_buf(inst, );
+   if (ret)
+   goto fail;
+   }
+
+fail:
+   return ret;
+}
+
+int venus_helper_free_dpb_bufs(struct venus_inst *inst)
+{
+   struct intbuf *buf, *n;
+
+   if (list_empty(>dpbbufs))
+   return 0;
+
+   list_for_each_entry_safe(buf, n, >dpbbufs, list) {
+   list_del_init(>list);
+   dma_free_attrs(inst->core->dev, buf->size, buf->va, buf->da,
+  buf->attrs);
+   kfree(buf);
+   }
+
+   INIT_LIST_HEAD(>dpbbufs);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(venus_helper_free_dpb_bufs);
+
+int venus_helper_alloc_dpb_bufs(struct venus_inst *inst)
+{
+   struct venus_core *core = inst->core;
+   struct device *dev = core->dev;
+   enum hfi_version ver = core->res->hfi_version;
+   struct hfi_buffer_requirements bufreq;
+   u32 buftype = inst->dpb_buftype;
+   unsigned int dpb_size = 0;
+   struct intbuf *buf;
+   unsigned int i;
+   u32 count;
+   int ret;
+
+   /* no need to allocate dpb buffers */
+   if (!inst->dpb_fmt)
+   return 0;
+
+   if (inst->dpb_buftype == HFI_BUFFER_OUTPUT)
+   dpb_size = inst->output_buf_size;
+   else if (inst->dpb_buftype == HFI_BUFFER_OUTPUT2)
+   dpb_size = inst->output2_buf_size;
+
+   if (!dpb_size)
+   return 0;
+
+   ret = venus_helper_get_bufreq(inst, buftype, );
+   if (ret)
+   return ret;
+
+   count = HFI_BUFREQ_COUNT_MIN(, ver);
+
+   for (i = 0; i < count; i++) {
+   buf = kzalloc(sizeof(*buf), GFP_KERNEL);
+   if (!buf) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   buf->type = buftype;
+   buf->size = dpb_size;
+   buf->attrs = DMA_ATTR_WRITE_COMBINE |
+DMA_ATTR_NO_KERNEL_MAPPING;
+   buf->va = dma_alloc_attrs(dev, buf->size, >da, GFP_KERNEL,
+ buf->attrs);
+   if (!buf->va) {
+   kfree(buf);
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   list_add_tail(>list, >dpbbufs);
+   }
+
+   return 0;
+
+fail:
+   venus_helper_free_dpb_bufs(inst);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(venus_helper_alloc_dpb_bufs);
+
 static int intbufs_set_buffer(struct venus_inst *inst, u32 type)
 {
struct venus_core *core = inst->core;
@@ -342,7 +448,10 @@ session_process_buf(struct venus_inst *inst,
struct vb2_v4l2_buffer *vbuf)
if (vbuf->flags & V4L2_BUF_FLAG_LAST || !fdata.filled_len)
fdata.flags |= HFI_BUFFERFLAG_EOS;
} else if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
-   fdata.buffer_type = 

Re: [Intel-gfx] [PATCH 01/17] dma-fence: Some kerneldoc polish for dma-fence.h

[Daniel Vetter]

On Mon, Apr 30, 2018 at 10:49:00AM -0700, Eric Anholt wrote:
> Daniel Vetter  writes:
> > +   /**
> > +* @fill_driver_data:
> > +*
> > +* Callback to fill in free-form debug info Returns amount of bytes
> > +* filled, or negative error on failure.
> 
> Maybe this "Returns" should be on a new line?  Or at least a '.' in
> between.

Indeed I've missed this, thanks for spotting it. Done both

Thanks, Daniel

> 
> Other than that,
> 
> Reviewed-by: Eric Anholt 
> 
> Thanks!



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3 7/8] v4l: vsp1: Integrate DISCOM in display pipeline

[jacopo mondi]

Hi Laurent,
thanks for addressing comments on v2

On Sat, Apr 28, 2018 at 11:50:26PM +0300, Laurent Pinchart wrote:
> The DISCOM is used to compute CRCs on display frames. Integrate it in
> the display pipeline at the output of the blending unit to process
> output frames.
>
> Computing CRCs on input frames is possible by positioning the DISCOM at
> a different point in the pipeline. This use case isn't supported at the
> moment and could be implemented by extending the API between the VSP1
> and DU drivers if needed.
>
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Kieran Bingham 

Reviewed-by: Jacopo Mondi 

Thanks
   j

> ---
> Changes since v2:
>
> - Reduce indentation in vsp1_du_insert_uif()
> - Use vsp1_du_crc_config structure in vsp1_drm_pipeline
> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 115 
> -
>  drivers/media/platform/vsp1/vsp1_drm.h |   7 ++
>  2 files changed, 119 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index 5fc31578f9b0..08667e3640b2 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -22,6 +22,7 @@
>  #include "vsp1_lif.h"
>  #include "vsp1_pipe.h"
>  #include "vsp1_rwpf.h"
> +#include "vsp1_uif.h"
>
>  #define BRX_NAME(e)  (e)->type == VSP1_ENTITY_BRU ? "BRU" : "BRS"
>
> @@ -35,8 +36,13 @@ static void vsp1_du_pipeline_frame_end(struct 
> vsp1_pipeline *pipe,
>   struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
>   bool complete = completion == VSP1_DL_FRAME_END_COMPLETED;
>
> - if (drm_pipe->du_complete)
> - drm_pipe->du_complete(drm_pipe->du_private, complete, 0);
> + if (drm_pipe->du_complete) {
> + struct vsp1_entity *uif = drm_pipe->uif;
> + u32 crc;
> +
> + crc = uif ? vsp1_uif_get_crc(to_uif(>subdev)) : 0;
> + drm_pipe->du_complete(drm_pipe->du_private, complete, crc);
> + }
>
>   if (completion & VSP1_DL_FRAME_END_INTERNAL) {
>   drm_pipe->force_brx_release = false;
> @@ -48,10 +54,66 @@ static void vsp1_du_pipeline_frame_end(struct 
> vsp1_pipeline *pipe,
>   * Pipeline Configuration
>   */
>
> +/*
> + * Insert the UIF in the pipeline between the prev and next entities. If no 
> UIF
> + * is available connect the two entities directly.
> + */
> +static int vsp1_du_insert_uif(struct vsp1_device *vsp1,
> +   struct vsp1_pipeline *pipe,
> +   struct vsp1_entity *uif,
> +   struct vsp1_entity *prev, unsigned int prev_pad,
> +   struct vsp1_entity *next, unsigned int next_pad)
> +{
> + struct v4l2_subdev_format format;
> + int ret;
> +
> + if (!uif) {
> + /*
> +  * If there's no UIF to bee inserted connected the previous and
> +  * next entities directly.
> +  */
> + prev->sink = next;
> + prev->sink_pad = next_pad;
> + return 0;
> + }
> +
> + prev->sink = uif;
> + prev->sink_pad = UIF_PAD_SINK;
> +
> + memset(, 0, sizeof(format));
> + format.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> + format.pad = prev_pad;
> +
> + ret = v4l2_subdev_call(>subdev, pad, get_fmt, NULL, );
> + if (ret < 0)
> + return ret;
> +
> + format.pad = UIF_PAD_SINK;
> +
> + ret = v4l2_subdev_call(>subdev, pad, set_fmt, NULL, );
> + if (ret < 0)
> + return ret;
> +
> + dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on UIF sink\n",
> + __func__, format.format.width, format.format.height,
> + format.format.code);
> +
> + /*
> +  * The UIF doesn't mangle the format between its sink and source pads,
> +  * so there is no need to retrieve the format on its source pad.
> +  */
> +
> + uif->sink = next;
> + uif->sink_pad = next_pad;
> +
> + return 0;
> +}
> +
>  /* Setup one RPF and the connected BRx sink pad. */
>  static int vsp1_du_pipeline_setup_rpf(struct vsp1_device *vsp1,
> struct vsp1_pipeline *pipe,
> struct vsp1_rwpf *rpf,
> +   struct vsp1_entity *uif,
> unsigned int brx_input)
>  {
>   struct v4l2_subdev_selection sel;
> @@ -122,6 +184,12 @@ static int vsp1_du_pipeline_setup_rpf(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>
> + /* Insert and configure the UIF if available. */
> + ret = vsp1_du_insert_uif(vsp1, pipe, uif, >entity, RWPF_PAD_SOURCE,
> +  pipe->brx, brx_input);
> + if (ret < 0)
> + return ret;
> +
>   /* BRx sink, propagate the format from the RPF source. 

Re: [PATCH v3 5/8] v4l: vsp1: Extend the DU API to support CRC computation

[jacopo mondi]

Hi Laurent,
thanks for the patch

On Sat, Apr 28, 2018 at 11:50:24PM +0300, Laurent Pinchart wrote:
> Add a parameter (in the form of a structure to ease future API
> extensions) to the VSP atomic flush handler to pass CRC source
> configuration, and pass the CRC value to the completion callback.
>
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Kieran Bingham 

Reviewed-by: Jacopo Mondi 

Thanks
   j

> ---
> Changes since v2:
>
> - Name the CRC computation configuration parameters structure
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  6 --
>  drivers/media/platform/vsp1/vsp1_drm.c |  6 --
>  drivers/media/platform/vsp1/vsp1_drm.h |  2 +-
>  include/media/vsp1.h   | 35 
> --
>  4 files changed, 42 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index 2c260c33840b..bdcec201591f 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -31,7 +31,7 @@
>  #include "rcar_du_kms.h"
>  #include "rcar_du_vsp.h"
>
> -static void rcar_du_vsp_complete(void *private, bool completed)
> +static void rcar_du_vsp_complete(void *private, bool completed, u32 crc)
>  {
>   struct rcar_du_crtc *crtc = private;
>
> @@ -102,7 +102,9 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
>
>  void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
>  {
> - vsp1_du_atomic_flush(crtc->vsp->vsp, crtc->vsp_pipe);
> + struct vsp1_du_atomic_pipe_config cfg = { { 0, } };
> +
> + vsp1_du_atomic_flush(crtc->vsp->vsp, crtc->vsp_pipe, );
>  }
>
>  /* Keep the two tables in sync. */
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index 2b29a83dceb9..5fc31578f9b0 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -36,7 +36,7 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline 
> *pipe,
>   bool complete = completion == VSP1_DL_FRAME_END_COMPLETED;
>
>   if (drm_pipe->du_complete)
> - drm_pipe->du_complete(drm_pipe->du_private, complete);
> + drm_pipe->du_complete(drm_pipe->du_private, complete, 0);
>
>   if (completion & VSP1_DL_FRAME_END_INTERNAL) {
>   drm_pipe->force_brx_release = false;
> @@ -739,8 +739,10 @@ EXPORT_SYMBOL_GPL(vsp1_du_atomic_update);
>   * vsp1_du_atomic_flush - Commit an atomic update
>   * @dev: the VSP device
>   * @pipe_index: the DRM pipeline index
> + * @cfg: atomic pipe configuration
>   */
> -void vsp1_du_atomic_flush(struct device *dev, unsigned int pipe_index)
> +void vsp1_du_atomic_flush(struct device *dev, unsigned int pipe_index,
> +   const struct vsp1_du_atomic_pipe_config *cfg)
>  {
>   struct vsp1_device *vsp1 = dev_get_drvdata(dev);
>   struct vsp1_drm_pipeline *drm_pipe = >drm->pipe[pipe_index];
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
> b/drivers/media/platform/vsp1/vsp1_drm.h
> index f4af1b2b12d6..e5b88b28806c 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.h
> +++ b/drivers/media/platform/vsp1/vsp1_drm.h
> @@ -35,7 +35,7 @@ struct vsp1_drm_pipeline {
>   wait_queue_head_t wait_queue;
>
>   /* Frame synchronisation */
> - void (*du_complete)(void *, bool);
> + void (*du_complete)(void *data, bool completed, u32 crc);
>   void *du_private;
>  };
>
> diff --git a/include/media/vsp1.h b/include/media/vsp1.h
> index ff7ef894465d..678c24de1ac6 100644
> --- a/include/media/vsp1.h
> +++ b/include/media/vsp1.h
> @@ -34,7 +34,7 @@ struct vsp1_du_lif_config {
>   unsigned int width;
>   unsigned int height;
>
> - void (*callback)(void *, bool);
> + void (*callback)(void *data, bool completed, u32 crc);
>   void *callback_data;
>  };
>
> @@ -61,11 +61,42 @@ struct vsp1_du_atomic_config {
>   unsigned int zpos;
>  };
>
> +/**
> + * enum vsp1_du_crc_source - Source used for CRC calculation
> + * @VSP1_DU_CRC_NONE: CRC calculation disabled
> + * @VSP1_DU_CRC_PLANE: Perform CRC calculation on an input plane
> + * @VSP1_DU_CRC_OUTPUT: Perform CRC calculation on the composed output
> + */
> +enum vsp1_du_crc_source {
> + VSP1_DU_CRC_NONE,
> + VSP1_DU_CRC_PLANE,
> + VSP1_DU_CRC_OUTPUT,
> +};
> +
> +/**
> + * struct vsp1_du_crc_config - VSP CRC computation configuration parameters
> + * @source: source for CRC calculation
> + * @index: index of the CRC source plane (when source is set to plane)
> + */
> +struct vsp1_du_crc_config {
> + enum vsp1_du_crc_source source;
> + unsigned int index;
> +};
> +
> +/**
> + * struct vsp1_du_atomic_pipe_config - VSP atomic pipe configuration 
> parameters
> + * @crc: CRC computation configuration
> + */
> +struct vsp1_du_atomic_pipe_config {
> + struct vsp1_du_crc_config crc;
> +};
> 

Re: [RESEND PATCH v8 2/2] media: dw9807: Add dw9807 vcm driver

[jacopo mondi]

Hi Andy,
thanks for addressing comments on previous versions

On Wed, Apr 25, 2018 at 10:12:08AM +0800, Andy Yeh wrote:
> From: Alan Chiang 
>
> DW9807 is a 10 bit DAC from Dongwoon, designed for linear
> control of voice coil motor.
>
> This driver creates a V4L2 subdevice and
> provides control to set the desired focus.
>
> Signed-off-by: Andy Yeh 

Reviewed-by: Jacopo Mondi 

Thanks
   j

> ---
> since v1:
> - changed author.
> since v2:
> - addressed outstanding comments.
> - enabled sequential write to update 2 registers in a single transaction.
> since v3:
> - addressed comments for v3.
> - Remove redundant codes and declare some variables as constant variable.
> - separate DT binding to another patch
> since v4:
> - sent patchset included DT binding with cover page
> since v6:
> - change the return code of i2c_check
> - fix long cols exceed 80 chars
> - remove #define DW9807_NAME since only used once
> since v7:
> - Remove some redundant type cast
> - Modify to meet the coding style
> - Replace a while loop by readx_poll_timeout function
> - Return the i2c error directly.
>
>  MAINTAINERS|   7 +
>  drivers/media/i2c/Kconfig  |  10 ++
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/dw9807.c | 329 
> +
>  4 files changed, 347 insertions(+)
>  create mode 100644 drivers/media/i2c/dw9807.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 845fc25..a339bb5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4385,6 +4385,13 @@ T: git git://linuxtv.org/media_tree.git
>  S:   Maintained
>  F:   drivers/media/i2c/dw9714.c
>
> +DONGWOON DW9807 LENS VOICE COIL DRIVER
> +M:   Sakari Ailus 
> +L:   linux-media@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Maintained
> +F:   drivers/media/i2c/dw9807.c
> +
>  DOUBLETALK DRIVER
>  M:   "James R. Van Zandt" 
>  L:   blinux-l...@redhat.com
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index cb5d7ff..fd01842 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -325,6 +325,16 @@ config VIDEO_DW9714
> capability. This is designed for linear control of
> voice coil motors, controlled via I2C serial interface.
>
> +config VIDEO_DW9807
> + tristate "DW9807 lens voice coil support"
> + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + ---help---
> +   This is a driver for the DW9807 camera lens voice coil.
> +   DW9807 is a 10 bit DAC with 100mA output current sink
> +   capability. This is designed for linear control of
> +   voice coil motors, controlled via I2C serial interface.
> +
>  config VIDEO_SAA7110
>   tristate "Philips SAA7110 video decoder"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 548a9ef..1b62639 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
>  obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
>  obj-$(CONFIG_VIDEO_AD5820)  += ad5820.o
>  obj-$(CONFIG_VIDEO_DW9714)  += dw9714.o
> +obj-$(CONFIG_VIDEO_DW9807)  += dw9807.o
>  obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
>  obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
>  obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
> diff --git a/drivers/media/i2c/dw9807.c b/drivers/media/i2c/dw9807.c
> new file mode 100644
> index 000..28ede2b
> --- /dev/null
> +++ b/drivers/media/i2c/dw9807.c
> @@ -0,0 +1,329 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2018 Intel Corporation
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DW9807_MAX_FOCUS_POS 1023
> +/*
> + * This sets the minimum granularity for the focus positions.
> + * A value of 1 gives maximum accuracy for a desired focus position.
> + */
> +#define DW9807_FOCUS_STEPS   1
> +/*
> + * This acts as the minimum granularity of lens movement.
> + * Keep this value power of 2, so the control steps can be
> + * uniformly adjusted for gradual lens movement, with desired
> + * number of control steps.
> + */
> +#define DW9807_CTRL_STEPS16
> +#define DW9807_CTRL_DELAY_US 1000
> +
> +#define DW9807_CTL_ADDR  0x02
> +/*
> + * DW9807 separates two registers to control the VCM position.
> + * One for MSB value, another is LSB value.
> + */
> +#define DW9807_MSB_ADDR  0x03
> +#define DW9807_LSB_ADDR  0x04
> +#define DW9807_STATUS_ADDR   0x05
> +#define DW9807_MODE_ADDR 0x06
> +#define DW9807_RESONANCE_ADDR0x07
> +
> +#define MAX_RETRY10
> +
> +struct dw9807_device {
> + struct v4l2_ctrl_handler ctrls_vcm;
> + struct v4l2_subdev sd;
> + u16 current_val;
> +};
> +
> +static inline struct dw9807_device 

Re: [PATCH 10/28] venus: vdec: call session_continue in insufficient event

[Vikash Garodia]

Hello Stanimir,

On 2018-04-24 18:14, Stanimir Varbanov wrote:

Call session_continue for Venus 4xx version even when the event
says that the buffer resources are not sufficient. Leaving a
comment with more information about the workaround.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/vdec.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/vdec.c
b/drivers/media/platform/qcom/venus/vdec.c
index c45452634e7e..91c7384ff9c8 100644
--- a/drivers/media/platform/qcom/venus/vdec.c
+++ b/drivers/media/platform/qcom/venus/vdec.c
@@ -873,6 +873,14 @@ static void vdec_event_notify(struct venus_inst
*inst, u32 event,

dev_dbg(dev, "event not sufficient resources (%ux%u)\n",
data->width, data->height);
+   /*
+* Workaround: Even that the firmware send and event for
+* insufficient buffer resources it is safe to call
+* session_continue because actually the event says that
+* the number of capture buffers is lower.
+*/
+   if (IS_V4(core))
+   hfi_session_continue(inst);
break;
case HFI_EVENT_RELEASE_BUFFER_REFERENCE:
venus_helper_release_buf_ref(inst, data->tag);


Insufficient event from video firmware could be sent either,
1. due to insufficient buffer resources
2. due to lower capture buffers

It cannot be assumed that the event received by the host is due to lower 
capture
buffers. Incase the buffer resource is insufficient, let say there is a 
bitstream
resolution switch from 720p to 1080p, capture buffers needs to be 
reallocated.


The driver should be sending the V4L2_EVENT_SOURCE_CHANGE to client 
instead of ignoring

the event from firmware.

Thanks,
Vikash

Re: [PATCH 08/28] venus: hfi_venus: add suspend function for 4xx version

[vgarodia]

Hello Stanimir,

On 2018-04-24 18:14, Stanimir Varbanov wrote:

This adds suspend (power collapse) function with slightly
different order of calls comparing with Venus 3xx.

Signed-off-by: Stanimir Varbanov 
---
 drivers/media/platform/qcom/venus/hfi_venus.c | 52 
+++

 1 file changed, 52 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c
b/drivers/media/platform/qcom/venus/hfi_venus.c
index 53546174aab8..f61d34bf61b4 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus.c
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -1443,6 +1443,55 @@ static int venus_suspend_1xx(struct venus_core 
*core)

return 0;
 }

+static int venus_suspend_4xx(struct venus_core *core)
+{
+   struct venus_hfi_device *hdev = to_hfi_priv(core);
+   struct device *dev = core->dev;
+   u32 val;
+   int ret;
+
+   if (!hdev->power_enabled || hdev->suspended)
+   return 0;
+
+   mutex_lock(>lock);
+   ret = venus_is_valid_state(hdev);
+   mutex_unlock(>lock);
+
+   if (!ret) {
+   dev_err(dev, "bad state, cannot suspend\n");
+   return -EINVAL;
+   }
+
+   ret = venus_prepare_power_collapse(hdev, false);
+   if (ret) {
+   dev_err(dev, "prepare for power collapse fail (%d)\n", ret);
+   return ret;
+   }
+
+   ret = readl_poll_timeout(core->base + CPU_CS_SCIACMDARG0, val,
+val & CPU_CS_SCIACMDARG0_PC_READY,
+POLL_INTERVAL_US, 10);
+   if (ret) {
+   dev_err(dev, "Polling power collapse ready timed out\n");
+   return ret;
+   }
+
+   mutex_lock(>lock);
+
+   ret = venus_power_off(hdev);
+   if (ret) {
+   dev_err(dev, "venus_power_off (%d)\n", ret);
+   mutex_unlock(>lock);
+   return ret;
+   }
+
+   hdev->suspended = true;
+
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
 static int venus_suspend_3xx(struct venus_core *core)
 {
struct venus_hfi_device *hdev = to_hfi_priv(core);
@@ -1507,6 +1556,9 @@ static int venus_suspend(struct venus_core *core)
if (core->res->hfi_version == HFI_VERSION_3XX)
return venus_suspend_3xx(core);

+   if (core->res->hfi_version == HFI_VERSION_4XX)
+   return venus_suspend_4xx(core);
+
return venus_suspend_1xx(core);
 }


Let me brief on the power collapse sequence for Venus_4xx
1. Host checks for ARM9 and Video core to be idle.
   This can be done by checking for WFI bit (bit 0) in CPU status 
register for ARM9 and by checking bit 30 in Control status reg for video 
core/s.

2. Host then sends command to ARM9 to prepare for power collapse.
3. Host then checks for WFI bit and PC_READY bit before withdrawing 
going for power off.


As per this patch, host is preparing for power collapse without checking 
for #1.

Update the code to handle #3.

Thanks
Vikash