Re: [PATCH 07/22] [media] imx: Add IPUv3 media common code

[Ian Arkver]

On 07/10/16 17:00, Philipp Zabel wrote:

From: Sascha Hauer 

Add video4linux API routines common to drivers for units that
accept or provide video data via the i.MX IPU IDMAC channels,
such as capture, mem2mem scaler or deinterlacer drivers.

Signed-off-by: Sascha Hauer 
Signed-off-by: Lucas Stach 
Signed-off-by: Philipp Zabel 
---
  drivers/media/platform/imx/Kconfig   |   3 +
  drivers/media/platform/imx/Makefile  |   1 +
  drivers/media/platform/imx/imx-ipu.c | 321 +++
  drivers/media/platform/imx/imx-ipu.h |  34 
  4 files changed, 359 insertions(+)
  create mode 100644 drivers/media/platform/imx/imx-ipu.c
  create mode 100644 drivers/media/platform/imx/imx-ipu.h

diff --git a/drivers/media/platform/imx/Kconfig 
b/drivers/media/platform/imx/Kconfig
index 3bd699c..1662bb0b 100644
--- a/drivers/media/platform/imx/Kconfig
+++ b/drivers/media/platform/imx/Kconfig
@@ -5,3 +5,6 @@ config MEDIA_IMX
---help---
  This driver provides a SoC wide media controller device that all
  multimedia components in i.MX5 and i.MX6 SoCs can register with.
+
+config VIDEO_IMX_IPU_COMMON
+   tristate
diff --git a/drivers/media/platform/imx/Makefile 
b/drivers/media/platform/imx/Makefile
index 74bed76..0ba601a 100644
--- a/drivers/media/platform/imx/Makefile
+++ b/drivers/media/platform/imx/Makefile
@@ -1 +1,2 @@
  obj-$(CONFIG_MEDIA_IMX)   += imx-media.o
+obj-$(CONFIG_VIDEO_IMX_IPU_COMMON) += imx-ipu.o
diff --git a/drivers/media/platform/imx/imx-ipu.c 
b/drivers/media/platform/imx/imx-ipu.c
new file mode 100644
index 000..da1deb0
--- /dev/null
+++ b/drivers/media/platform/imx/imx-ipu.c
@@ -0,0 +1,321 @@
+/*
+ * i.MX IPUv3 common v4l2 support
+ *
+ * Copyright (C) 2011 Pengutronix, Sascha Hauer 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-ipu.h"
+
+/*
+ * These formats are in order of preference: interleaved YUV first,
+ * because those are the most bandwidth efficient, followed by
+ * chroma-interleaved formats, and planar formats last.
+ * In each category, YUV 4:2:0 may be preferrable to 4:2:2 for bandwidth
+ * reasons, if the IDMAC channel supports double read/write reduction
+ * (all write channels, VDIC read channels).
+ */
+static struct ipu_fmt ipu_fmt_yuv[] = {
+   {
+   .fourcc = V4L2_PIX_FMT_YUYV,
+   .bytes_per_pixel = 2,
+   }, {
+   .fourcc = V4L2_PIX_FMT_UYVY,
+   .bytes_per_pixel = 2,
+   }, {
+   .fourcc = V4L2_PIX_FMT_NV12,
+   .bytes_per_pixel = 1,
+   }, {
+   .fourcc = V4L2_PIX_FMT_NV16,
+   .bytes_per_pixel = 1,
+   }, {
+   .fourcc = V4L2_PIX_FMT_YUV420,
+   .bytes_per_pixel = 1,
+   }, {
+   .fourcc = V4L2_PIX_FMT_YVU420,
+   .bytes_per_pixel = 1,
+   }, {
+   .fourcc = V4L2_PIX_FMT_YUV422P,
+   .bytes_per_pixel = 1,
+   },
+};
+
+static struct ipu_fmt ipu_fmt_rgb[] = {
+   {
+   .fourcc = V4L2_PIX_FMT_RGB32,
+   .bytes_per_pixel = 4,
+   }, {
+   .fourcc = V4L2_PIX_FMT_RGB24,
+   .bytes_per_pixel = 3,
+   }, {
+   .fourcc = V4L2_PIX_FMT_BGR24,
+   .bytes_per_pixel = 3,
+   }, {
+   .fourcc = V4L2_PIX_FMT_RGB565,
+   .bytes_per_pixel = 2,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_BGR32,
+   .bytes_per_pixel = 4,
+   },
+};


Maybe a trivial comment, but is it worthwhile to constify these two?

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

Re: [PATCH 06/10] mm: replace get_user_pages() write/force parameters with gup_flags

[Jesper Nilsson]

On Thu, Oct 13, 2016 at 01:20:16AM +0100, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from get_user_pages() and
> replaces them with a gup_flags parameter to make the use of FOLL_FORCE 
> explicit
> in callers as use of this flag can result in surprising behaviour (and hence
> bugs) within the mm subsystem.
> 
> Signed-off-by: Lorenzo Stoakes 
> ---
>  arch/cris/arch-v32/drivers/cryptocop.c |  4 +---

For the CRIS part:

Acked-by: Jesper Nilsson 

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

Re: [PATCH 10/10] mm: replace access_process_vm() write parameter with gup_flags

[Jesper Nilsson]

On Thu, Oct 13, 2016 at 01:20:20AM +0100, Lorenzo Stoakes wrote:
> This patch removes the write parameter from access_process_vm() and replaces 
> it
> with a gup_flags parameter as use of this function previously _implied_
> FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
> 
> We make this explicit as use of FOLL_FORCE can result in surprising behaviour
> (and hence bugs) within the mm subsystem.
> 
> Signed-off-by: Lorenzo Stoakes 
> ---
>  arch/cris/arch-v32/kernel/ptrace.c |  4 ++--

For the CRIS part:

Acked-by: Jesper Nilsson 

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

Re: [PATCH 2/2] [media] vb2: Add support for use_dma_bidirectional queue flag

[Sakari Ailus]

Hi Thierry,

Thanks for the set. A few comments below.

On Fri, Oct 14, 2016 at 02:08:14PM +0200, Thierry Escande wrote:
> From: Pawel Osciak 
> 
> When this flag is set for CAPTURE queues by the driver on calling
> vb2_queue_init(), it forces the buffers on the queue to be
> allocated/mapped with DMA_BIDIRECTIONAL direction flag, instead of
> DMA_FROM_DEVICE. This allows the device not only to write to the
> buffers, but also read out from them. This may be useful e.g. for codec
> hardware, which may be using CAPTURE buffers as reference to decode
> other buffers.

Just out of curiosity --- when do you return these buffers back to the user?
Once they're no longer needed as reference frames?

> 
> This flag is ignored for OUTPUT queues, as we don't want to allow HW to
> be able to write to OUTPUT buffers.
> 
> Signed-off-by: Pawel Osciak 
> Tested-by: Pawel Osciak 
> Reviewed-by: Tomasz Figa 
> Signed-off-by: Thierry Escande 
> ---
>  drivers/media/v4l2-core/videobuf2-v4l2.c | 8 ++--
>  include/media/videobuf2-core.h   | 4 
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> b/drivers/media/v4l2-core/videobuf2-v4l2.c
> index fde1e2d..9255291 100644
> --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> @@ -659,8 +659,12 @@ int vb2_queue_init(struct vb2_queue *q)
>* queues will always initialize waiting_for_buffers to false.
>*/
>   q->quirk_poll_must_check_waiting_for_buffers = true;
> - q->dma_dir = V4L2_TYPE_IS_OUTPUT(q->type)
> -? DMA_TO_DEVICE : DMA_FROM_DEVICE;
> +
> + if (V4L2_TYPE_IS_OUTPUT(q->type))
> + q->dma_dir = DMA_TO_DEVICE;
> + else
> + q->dma_dir = q->use_dma_bidirectional
> +? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE;
>  
>   return vb2_core_queue_init(q);
>  }
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index 38410dd..e613c74 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -433,6 +433,9 @@ struct vb2_buf_ops {
>   * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when 
> QBUF
>   *  has not been called. This is a vb1 idiom that has been 
> adopted
>   *  also by vb2.
> + * @use_dma_bidirectional:   use DMA_BIDIRECTIONAL for CAPTURE buffers; this
> + *   allows HW to read from the CAPTURE buffers in
> + *   addition to writing; ignored for OUTPUT queues
>   * @lock:pointer to a mutex that protects the vb2_queue struct. The
>   *   driver can set this to a mutex to let the v4l2 core serialize
>   *   the queuing ioctls. If the driver wants to handle locking
> @@ -500,6 +503,7 @@ struct vb2_queue {
>   unsignedfileio_write_immediately:1;
>   unsignedallow_zero_bytesused:1;
>   unsigned   quirk_poll_must_check_waiting_for_buffers:1;
> + unsigneduse_dma_bidirectional:1;

This field is in the same struct as dma_dir which it directly affects.

How about adding a macro instead to give you the queue DMA direction
instead?

E.g.

#define vb2_dma_dir(q) \
(V4L2_TYPE_IS_OUTPUT((q)->type) ? DMA_TO_DEVICE : \
 (q)->use_dma_bidirectional ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE)

I would call this capture_dma_bidirectional as it only affects capture. Or
simply choose DMA_BIDIRECTIONAL whenever the flag is set.

I wonder what others think.

>  
>   struct mutex*lock;
>   void*owner;

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support

[Gary Bisson]

Hi Philipp,

On Fri, Oct 14, 2016 at 07:34:20PM +0200, Philipp Zabel wrote:
> Hi,
> 
> the second round removes the prepare_stream callback and instead lets the
> intermediate subdevices propagate s_stream calls to their sources rather
> than individually calling s_stream on each subdevice from the bridge driver.
> This is similar to how drm bridges recursively call into their next neighbor.
> It makes it easier to do bringup ordering on a per-link level, as long as the
> source preparation can be done at s_power, and the sink can just prepare, call
> s_stream on its source, and then enable itself inside s_stream. Obviously this
> would only work in a generic fashion if all asynchronous subdevices with both
> inputs and outputs would propagate s_stream to their source subdevices.
> 
> Changes since v1:
>  - Propagate field and colorspace in ipucsi_subdev_set_format.
>  - Remove v4l2_media_subdev_prepare_stream and v4l2_media_subdev_s_stream,
>let subdevices propagate s_stream calls to their upstream subdevices
>themselves.
>  - Various fixes (see individual patches for details)

For the whole series:
Tested-by: Gary Bisson 

Tested on Nitrogen6x + BD_HDMI_MIPI daughter board on linux-next
20161016.

This required using your v4l2-ctl patch to set the EDID if the source
output can't be forced:
https://patchwork.kernel.org/patch/6097201/
BTW, do you have any update on this? Because it looks like the
VIDIOC_SUBDEV_QUERYCAP hasn't been implemented since your patch (March
2015).

Then I followed the procedure you gave here:
https://patchwork.kernel.org/patch/9366503/

For those interested in trying it out, note that kmssink requires to use
Gstreamer 1.9.x.

I have a few remarks:
- I believe it would help having a patch that sets imx_v6_v7_defconfig
  with the proper options in this series
- Not related to this series, I couldn't boot the board unless I disable
  the PCIe driver, have you experienced the same issue?
- Is there a way not to set all the links manually using media-ctl? I
  expected all the formats to be negotiated automatically once a stream
  is properly detected.
- As discussed last week, the Nitrogen6x dtsi file shouldn't be
  included, instead an overlay would be more appropriate. Maybe the log
  should contain a comment about this.

Let me know if I need to add that Tested-by to every single patch so it
appears on Patchwork.

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

Re: [PATCH v2 08/21] [media] imx: Add i.MX IPUv3 capture driver

[Jack Mitchell]

Hi Philipp,

I'm looking at how I would enable a parallel greyscale camera using this 
set of drivers and am a little bit confused. Do you have an example 
somewhere of a devicetree with an input node. I also have a further note 
below:





+
+static int ipu_capture_start_streaming(struct vb2_queue *vq, unsigned int 
count)
+{
+   struct ipu_capture *priv = vb2_get_drv_priv(vq);
+   struct v4l2_subdev *csi_sd = priv->csi_sd;
+   u32 width = priv->format.fmt.pix.width;
+   u32 height = priv->format.fmt.pix.height;
+   struct device *dev = priv->dev;
+   int burstsize;
+   struct ipu_capture_buffer *buf;
+   int nfack_irq;
+   int ret;
+   const char *irq_name[2] = { "CSI0", "CSI1" };
+   bool raw;
+
+   ret = ipu_capture_get_resources(priv);
+   if (ret < 0) {
+   dev_err(dev, "Failed to get resources: %d\n", ret);
+   goto err_dequeue;
+   }
+
+   ipu_cpmem_zero(priv->ipuch);
+
+   nfack_irq = ipu_idmac_channel_irq(priv->ipu, priv->ipuch,
+ IPU_IRQ_NFACK);
+   ret = request_threaded_irq(nfack_irq, NULL,
+  ipu_capture_new_frame_handler, IRQF_ONESHOT,
+  irq_name[priv->id], priv);
+   if (ret) {
+   dev_err(dev, "Failed to request NFACK interrupt: %d\n", 
nfack_irq);
+   goto put_resources;
+   }
+
+   dev_dbg(dev, "width: %d height: %d, %.4s\n",
+   width, height, (char *)&priv->format.fmt.pix.pixelformat);
+
+   ipu_cpmem_set_resolution(priv->ipuch, width, height);
+
+   raw = false;
+
+   if (raw && priv->smfc) {


How does this ever get used? If I were to set 1X8 greyscale it wouldn't 
ever take this path, correct?



+   /*
+* raw formats. We can only pass them through to memory
+*/
+   u32 fourcc = priv->format.fmt.pix.pixelformat;
+   int bytes;
+
+   switch (fourcc) {
+   case V4L2_PIX_FMT_GREY:
+   bytes = 1;
+   break;
+   case V4L2_PIX_FMT_Y10:
+   case V4L2_PIX_FMT_Y16:
+   case V4L2_PIX_FMT_UYVY:
+   case V4L2_PIX_FMT_YUYV:
+   bytes = 2;
+   break;
+   }
+
+   ipu_cpmem_set_stride(priv->ipuch, width * bytes);
+   ipu_cpmem_set_format_passthrough(priv->ipuch, bytes * 8);
+   /*
+* According to table 37-727 (SMFC Burst Size), burstsize should
+* be set to NBP[6:4] for PFS == 6. Unfortunately, with a 16-bit
+* bus any value below 4 doesn't produce proper images.
+*/
+   burstsize = (64 / bytes) >> 3;
+   } else {
+   /*
+* formats we understand, we can write it in any format not 
requiring
+* colorspace conversion.
+*/
+   u32 fourcc = priv->format.fmt.pix.pixelformat;
+
+   switch (fourcc) {
+   case V4L2_PIX_FMT_RGB32:
+   ipu_cpmem_set_stride(priv->ipuch, width * 4);
+   ipu_cpmem_set_fmt(priv->ipuch, fourcc);
+   break;
+   case V4L2_PIX_FMT_UYVY:
+   case V4L2_PIX_FMT_YUYV:
+   ipu_cpmem_set_stride(priv->ipuch, width * 2);
+   ipu_cpmem_set_yuv_interleaved(priv->ipuch, fourcc);
+   break;
+   case V4L2_PIX_FMT_YUV420:
+   case V4L2_PIX_FMT_YVU420:
+   case V4L2_PIX_FMT_NV12:
+   case V4L2_PIX_FMT_YUV422P:
+   ipu_cpmem_set_stride(priv->ipuch, width);
+   ipu_cpmem_set_fmt(priv->ipuch, fourcc);
+   ipu_cpmem_set_yuv_planar(priv->ipuch, fourcc,
+width, height);
+   burstsize = 16;
+   break;
+   default:
+   dev_err(dev, "invalid color format: %4.4s\n",
+   (char *)&fourcc);
+   ret = -EINVAL;
+   goto free_irq;
+   }
+   }
+



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

[ANN] Report of the V4L2 Request API brainstorm meeting

[Hans Verkuil]

Report of the V4L2 brainstorm meeting October 10-11 2016, Berlin

Attendees:

Sakari Ailus 
Kieran Bingham 
Lars-Peter Clausen 
Guennadi Liakhovetski 
Pawel Osciak 
Laurent Pinchart 
Maxime Ripard 
Hans Verkuil 

The raw etherpad notes are available here:

https://hverkuil.home.xs4all.nl/v4l2-requests-2016.html

If I misinterpreted something (perfectly possible), then please reply
with a correction!




Goal of the brainstorm meeting:

Drivers for stateless hardware codecs rely on the Request API, which
has still not been merged. As a result a bunch of drivers remain out
of tree. The purpose of the meeting is to determine what the factors
are that prevent the Request API from being merged and how that can be
resolved.

Note: ChromeOS uses an older version of the Request API patch series.
At that time it was called 'Configuration Store API', but other than
the different name it is pretty much the same API.


1. Request API background

The request API is a way of associating configuration data with buffers.

The original version associated controls with buffers:

https://lwn.net/Articles/641204/

This functionality is required to support stateless HW codecs where the
controls are used to pass the state (as maintained by userspace) to the
hardware together with the buffer that has to be en/decoded.

Android's cameraHAL v3 needs similar functionality, but there you also
want to associate formats, selection rectangles and topology changes to
the request.

A version of the Request API doing that is here:

https://lwn.net/Articles/688585/

However, that work doesn't contain the code to associate controls with
buffers.

So we have two versions: one suitable for codecs, one more geared towards
cameraHAL v3. But we need both.

1.1 Request IDs

The original patch series use integer IDs to identify requests. Pawel suggested
that we use file descriptors instead (similar to dmabuf) to keep track of
ownership and better permission handling. This was agreed to since this avoids
the risk of having request objects being hijacked by other applications.

1.2 Allocation of the request FD

Example with a device that has one media node and two video nodes where the 
sensor
sends video to one video node and e.g. statistics to another video node:

open("media0") -> fd10
open("video0") -> fd11 (capture queue)
open("video1") -> fd12 (capture queue)
ioctl(fd10, REQUEST, ALLOC) -> fd13
ioctl(fd11, QBUF, { buffer1, fd13 })
ioctl(fd12, QBUF, { buffer2, fd13 })
ioctl(fd10, REQUEST, QUEUE { fd13 })

While it makes sense to allocate the request via the media device node in most
cases, there was a lot of discussion if an exception should be made for mem2mem
devices such as hardware codecs. M2M devices today consist of a single video 
node,
and every time it is opened a new instance is created (as if a new virtual m2m
device was created). The driver then schedules hardware access for the various
instances.

This means that the request should be associated with a specific m2m instance 
(i.e.
file descriptor). The easiest way to do that is simply by allocating the request
via the video device instead of creating a new media device and come up with a
way to associate the request with a m2m instance. Note that today's out-of-tree
implementation *does* create the request via the video node.

A final decision on this was postponed until we have a working implementation
and have a better idea of the pros and cons of creating such an exception.

When allocating a request the framework will fill in the request state: this
will either be a copy of the current hardware state, or it will clone the
state of an existing request (it does this by passing the fd of the request
that should be cloned, or by passing 0 to copy the current state).

1.3 Request validation

Some request requirements:

- When you queue a request it is validated.
- The request has a full state, so the validation is independent of any 
previously
  queued requests.
- If an error occurs, no good error reporting is available. But the only reason 
for
  such errors would be hardware failures, which usually indicate a serious
  unrecoverable problem and should trigger a halt (requests cancelled, flagged 
with
  error)
- Change in hardware configuration (e.g. disconnecting an HDMI input) could also
  invalidate requests

1.4 Completing requests

- A request is completed when all buffers are dequeued and all results are
  copied to the request.
- An event of some sort is needed to signal that the request has been completed.
  Since the request is a FD, this can be used with poll() to signal this.
- To delete a request the application has to call close(). The request will be
  really deleted once the refcount goes to 0.
- A request cannot be re-used without re-initializing it first by cloning the
  current HW state or an existing request or by 'cloning' itself, in which
  case the request's configuration will be re-used. This last optio

Re: [PATCH v2 08/21] [media] imx: Add i.MX IPUv3 capture driver

[Marek Vasut]

On 10/17/2016 01:32 PM, Jack Mitchell wrote:
> Hi Philipp,

Hi,

> I'm looking at how I would enable a parallel greyscale camera using this
> set of drivers and am a little bit confused. Do you have an example
> somewhere of a devicetree with an input node. I also have a further note
> below:

Which sensor do you use ?

[...]

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

Re: [PATCH v2 08/21] [media] imx: Add i.MX IPUv3 capture driver

[Jack Mitchell]

On 17/10/16 12:35, Marek Vasut wrote:

On 10/17/2016 01:32 PM, Jack Mitchell wrote:

Hi Philipp,


Hi,


I'm looking at how I would enable a parallel greyscale camera using this
set of drivers and am a little bit confused. Do you have an example
somewhere of a devicetree with an input node. I also have a further note
below:


Which sensor do you use ?

[...]



One which has a driver yet to be written :)

Initial prototype board has an onsemi ar0135 on the parallel interface.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANN] Report of the V4L2 Request API brainstorm meeting

[Jose Abreu]

Hi,


On 17-10-2016 12:37, Hans Verkuil wrote:
> Report of the V4L2 brainstorm meeting October 10-11 2016, Berlin

[snip]

> 4.4 Streamon and streamoff
>
> - How to handle STREAMON/OFF?
>   - Pipelines without video nodes?
>   - Buffer size may change. Need to reallocate buffers, which is 
> currently done
> through streamoff, reqbufs and streamon.
> - We probably want a STREAM_CANCEL which would dequeue pending buffers 
> (requests)
>   without stopping streaming.
>
>

I am facing this scenario in my HDMI decoder driver. I have an
input stream which may change the resolution while streaming, so
I need to do off/reconfigure/on and request new buffer with the
new image size, and I also have to mark the previous buffers as
invalid. The automatic dequeue of pending buffers would help a
lot but still, at least in my case, I have to reconfigure the
controller and pipeline to propagate the new format.

Off topic: I am using the notify functions to inform user space
of a format change but it is not working at all with vlc or
mplayer :(. Does anyone know of any application which can handle
this format change correctly?

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

Re: [PATCH v2 08/21] [media] imx: Add i.MX IPUv3 capture driver

[Philipp Zabel]

Hi Jack,

Am Montag, den 17.10.2016, 12:32 +0100 schrieb Jack Mitchell:
> Hi Philipp,
> 
> I'm looking at how I would enable a parallel greyscale camera using this 
> set of drivers and am a little bit confused. Do you have an example 
> somewhere of a devicetree with an input node.

In your board device tree it should look somewhat like this:

&i2c1 {
sensor@48 {
compatible = "aptina,mt9v032m";
/* ... */

port {
cam_out: endpoint {
remote-endpoint = <&csi_in>;
}
};
};
};

/*
 * This is the input port node corresponding to the 'CSI0' pad group,
 * not necessarily the CSI0 port of IPU1 or IPU2. On i.MX6Q it's port@1
 * of the mipi_ipu1_mux, on i.MX6DL it's port@4 of the ipu_csi0_mux,
 * the csi0 label is added in patch 13/21.
 */
&csi0 {
#address-cells = <1>;
#size-cells = <0>;

csi_in: endpoint@0 {
bus-width = <8>;
data-shift = <12>;
hsync-active = <1>;
vsync-active = <1>;
pclk-sample = <1>;
remote-endpoint = <&cam_out>;
};
};

>  I also have a further note below:
[...]
> > +   if (raw && priv->smfc) {
> 
> How does this ever get used? If I were to set 1X8 greyscale it wouldn't 
> ever take this path, correct?

Thank you, that is a leftover from stripping down the driver to the
basics. I'll test with a grayscale camera and fix this in the next
version.

regards
Philipp

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

[PATCH 1/2] v4l-utils: fixed dvbv5 vdr format

[Markus Heiser]

From: Markus Heiser 

From: Heiser, Markus 

The vdr format was broken, I got '(null)' entries

HD:11494:S1HC23I0M5N1O35:S:(null):22000:5101:5102,5103,5106,5108:0:0:10301:0:0:0:
0-:1:2--:3:4-:

refering to the VDR Wikis ...

* LinuxTV: http://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
* german comunity Wiki: 
http://www.vdr-wiki.de/wiki/index.php/Channels.conf#Parameter_ab_VDR-1.7.4

There is no field at position 4 / in between "Source" and "SRate" which
might have a value. I suppose the '(null):' is the result of pointing
to *nothing*.

An other mistake is the ending colon (":") at the line. It is not
explicit specified but adding an collon to the end of an channel entry
will prevent players (like mpv or mplayer) from parsing the line (they
will ignore these lines).

At least: generating a channel list with

  dvbv5-scan --output-format=vdr ...

will result in the same defective channel entry, containing "(null):"
and the leading collon ":".

Signed-off-by: Markus Heiser 
---
 lib/libdvbv5/dvb-vdr-format.c | 45 +--
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/lib/libdvbv5/dvb-vdr-format.c b/lib/libdvbv5/dvb-vdr-format.c
index a4bd26b..ab0e5cf 100644
--- a/lib/libdvbv5/dvb-vdr-format.c
+++ b/lib/libdvbv5/dvb-vdr-format.c
@@ -309,13 +309,14 @@ int dvb_write_format_vdr(const char *fname,
fprintf(fp, "%s", entry->channel);
if (entry->vchannel)
fprintf(fp, ",%s", entry->vchannel);
+   fprintf(fp, ":");
 
/*
 * Output frequency:
 *  in kHz for terrestrial/cable
 *  in MHz for satellite
 */
-   fprintf(fp, ":%i:", freq / 1000);
+   fprintf(fp, "%i:", freq / 1000);
 
/* Output modulation parameters */
fmt = &formats[i];
@@ -349,20 +350,30 @@ int dvb_write_format_vdr(const char *fname,
 
fprintf(fp, "%s", table->table[data]);
}
-
-   /* Output format type */
-   fprintf(fp, ":%s:", id);
+   fprintf(fp, ":");
 
/*
-* Output satellite location
-* FIXME: probably require some adjustments to match the
-*format expected by VDR.
+* Output sources configuration for VDR
+*
+*   S (satellite) xy.z (orbital position in degrees) E or W 
(east or west)
+*
+*   FIXME: in case of ATSC we use "A", this is what w_scan does
 */
-   switch(delsys) {
-   case SYS_DVBS:
-   case SYS_DVBS2:
-   fprintf(fp, "%s:", entry->location);
+
+   if (entry->location) {
+   switch(delsys) {
+   case SYS_DVBS:
+   case SYS_DVBS2:
+   fprintf(fp, "%s", entry->location);
+   break;
+   default:
+   fprintf(fp, "%s", id);
+   break;
+   }
+   } else {
+   fprintf(fp, "%s", id);
}
+   fprintf(fp, ":");
 
/* Output symbol rate */
srate = 2750;
@@ -407,10 +418,16 @@ int dvb_write_format_vdr(const char *fname,
/* Output Service ID */
fprintf(fp, "%d:", entry->service_id);
 
-   /* Output SID, NID, TID and RID */
-   fprintf(fp, "0:0:0:");
+   /* Output Network ID */
+   fprintf(fp, "0:");
 
-   fprintf(fp, "\n");
+   /* Output Transport Stream ID */
+   fprintf(fp, "0:");
+
+   /* Output Radio ID
+* this is the last entry, tagged bei a new line (not a colon!)
+*/
+   fprintf(fp, "0\n");
line++;
};
fclose (fp);
-- 
2.7.4

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

[PATCH 2/2] libdvbv5: Improve vdr format output for DVB-T(2)

[Markus Heiser]

From: Chris Mayo 

Before (1.10.1):
BBC TWO:498000:S0B8C23D12I999M64T8G32Y0:T:27500:201:202,206:0:0:4287:0:0:0
BBC TWO 
HD:474167:S1B8C23D999I999M256T32G128Y0:T:27500:101:102,106:0:0:17472:0:0:0
After:
BBC TWO:498000:B8C23D12G32I999M64S0T8Y0:T:0:201:202,206:0:0:4287:0:0:0
BBC TWO 
HD:474167:B8C23D999G128I999M256S1T32Y0:T:27500:101:102,106:0:0:17472:0:0:0

channels.conf (vdr 2.2.0):
BBC 
TWO:49800:B8C23D12G32M64S0T8Y0:T:0:201=2:202=eng@3,206=eng@3:0;205=eng:0:4287:9018:4163:0
BBC TWO 
HD:474166670:C23G128M256P0Q16436S1T32X1Y0:T:27500:101=27:102=eng@17,106=eng@17:0;105=eng:0:17472:9018:16515:0

Signed-off-by: Chris Mayo 
---
 lib/libdvbv5/dvb-vdr-format.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lib/libdvbv5/dvb-vdr-format.c b/lib/libdvbv5/dvb-vdr-format.c
index ab0e5cf..3d09237 100644
--- a/lib/libdvbv5/dvb-vdr-format.c
+++ b/lib/libdvbv5/dvb-vdr-format.c
@@ -198,26 +198,26 @@ static const struct dvb_parse_table sys_dvbs2_table[] = {
 };
 
 static const struct dvb_parse_table sys_dvbt_table[] = {
-   { DTV_DELIVERY_SYSTEM, PTABLE(vdr_parse_delivery_system) },
{ DTV_BANDWIDTH_HZ, PTABLE(vdr_parse_bandwidth) },
{ DTV_CODE_RATE_HP, PTABLE(vdr_parse_code_rate_hp) },
{ DTV_CODE_RATE_LP, PTABLE(vdr_parse_code_rate_lp) },
+   { DTV_GUARD_INTERVAL, PTABLE(vdr_parse_guard_interval) },
{ DTV_INVERSION, PTABLE(vdr_parse_inversion) },
{ DTV_MODULATION, PTABLE(vdr_parse_modulation) },
+   { DTV_DELIVERY_SYSTEM, PTABLE(vdr_parse_delivery_system) },
{ DTV_TRANSMISSION_MODE, PTABLE(vdr_parse_trans_mode) },
-   { DTV_GUARD_INTERVAL, PTABLE(vdr_parse_guard_interval) },
{ DTV_HIERARCHY, PTABLE(vdr_parse_hierarchy) },
 };
 
 static const struct dvb_parse_table sys_dvbt2_table[] = {
-   { DTV_DELIVERY_SYSTEM, PTABLE(vdr_parse_delivery_system) },
{ DTV_BANDWIDTH_HZ, PTABLE(vdr_parse_bandwidth) },
{ DTV_CODE_RATE_HP, PTABLE(vdr_parse_code_rate_hp) },
{ DTV_CODE_RATE_LP, PTABLE(vdr_parse_code_rate_lp) },
+   { DTV_GUARD_INTERVAL, PTABLE(vdr_parse_guard_interval) },
{ DTV_INVERSION, PTABLE(vdr_parse_inversion) },
{ DTV_MODULATION, PTABLE(vdr_parse_modulation) },
+   { DTV_DELIVERY_SYSTEM, PTABLE(vdr_parse_delivery_system) },
{ DTV_TRANSMISSION_MODE, PTABLE(vdr_parse_trans_mode) },
-   { DTV_GUARD_INTERVAL, PTABLE(vdr_parse_guard_interval) },
{ DTV_HIERARCHY, PTABLE(vdr_parse_hierarchy) },
/* DVB-T2 specifics */
{ DTV_STREAM_ID, NULL, },
@@ -378,6 +378,9 @@ int dvb_write_format_vdr(const char *fname,
/* Output symbol rate */
srate = 2750;
switch(delsys) {
+   case SYS_DVBT:
+   srate = 0;
+   break;
case SYS_DVBS:
case SYS_DVBS2:
case SYS_DVBC_ANNEX_A:
-- 
2.7.4

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

[PATCH 0/2] v4l-utils: fixed dvbv5 vdr format

[Markus Heiser]

Hi Mauro, hi Chris

sorry (again) for my late reply [1]. I merged & tested the patches of Chris [2]
and mine [3] fixing the vdr channel format. Since the patches had a conflict,
I had to slightly modify the patch [2] from Chris. --> Chris, I hope this is OK
for you.

I tested DVB-S2 and DVB-T with vdr (2.2.0/2.2.0) / DVB-T(2) has also been tested
by Chris [2].

[1] https://www.mail-archive.com/linux-media@vger.kernel.org/msg102138.html
[2] https://patchwork.linuxtv.org/patch/35803/
[3] https://patchwork.linuxtv.org/patch/36293/

-- Markus --

Chris Mayo (1):
  libdvbv5: Improve vdr format output for DVB-T(2)

Markus Heiser (1):
  v4l-utils: fixed dvbv5 vdr format

 lib/libdvbv5/dvb-vdr-format.c | 56 +--
 1 file changed, 38 insertions(+), 18 deletions(-)

-- 
2.7.4

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

Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support

[Philipp Zabel]

Hi Gary,

Am Montag, den 17.10.2016, 12:18 +0200 schrieb Gary Bisson:
[...]
> For the whole series:
> Tested-by: Gary Bisson 
> 
> Tested on Nitrogen6x + BD_HDMI_MIPI daughter board on linux-next
> 20161016.
>
> This required using your v4l2-ctl patch to set the EDID if the source
> output can't be forced:
> https://patchwork.kernel.org/patch/6097201/
> BTW, do you have any update on this? Because it looks like the
> VIDIOC_SUBDEV_QUERYCAP hasn't been implemented since your patch (March
> 2015).
> 
> Then I followed the procedure you gave here:
> https://patchwork.kernel.org/patch/9366503/
> 
> For those interested in trying it out, note that kmssink requires to use
> Gstreamer 1.9.x.
> 
> I have a few remarks:
> - I believe it would help having a patch that sets imx_v6_v7_defconfig
>   with the proper options in this series

I can add that in the next round.

> - Not related to this series, I couldn't boot the board unless I disable
>   the PCIe driver, have you experienced the same issue?

I had not enabled the PCIe driver, but a quick boot test with
CONFIG_PCIE_DW enabled hangs after these messages:

[1.314298] OF: PCI: host bridge /soc/pcie@0x0100 ranges:
[1.317199] OF: PCI:   No bus range found for /soc/pcie@0x0100, using 
[bus 00-ff]
[1.325171] OF: PCI:IO 0x01f8..0x01f8 -> 0x
[1.331029] OF: PCI:   MEM 0x0100..0x01ef -> 0x0100

I've asked Lucas to have a look.

> - Is there a way not to set all the links manually using media-ctl? I
>   expected all the formats to be negotiated automatically once a stream
>   is properly detected.

This should be done in userspace, probably libv4l2.

> - As discussed last week, the Nitrogen6x dtsi file shouldn't be
>   included, instead an overlay would be more appropriate. Maybe the log
>   should contain a comment about this.

Ok.

> Let me know if I need to add that Tested-by to every single patch so it
> appears on Patchwork.

It's fine as is, thank you.

regards
Philipp

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

Re: [PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels

[Laurent Pinchart]

Hi Rob,

On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
> On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
> > On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
> >> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
> >>> LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> >>> Multiple incompatible data link layers have been used over time to
> >>> transmit image data to LVDS panels. This binding supports display
> >>> panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
> >>> specifications.
> >>> 
> >>> Signed-off-by: Laurent Pinchart
> >>> 
> >>> ---
> >>> 
> >>>  .../bindings/display/panel/panel-lvds.txt  | 119 ++
> >>>  1 file changed, 119 insertions(+)
> >>>  create mode 100644
> >>>  Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
> >>> 
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> >>> b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> >>> new file mode 100644
> >>> index ..250861f2673e
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> >>> @@ -0,0 +1,119 @@
> >>> +Generic LVDS Panel
> >>> +==
> >>> +
> >>> +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> >>> Multiple
> >>> +incompatible data link layers have been used over time to transmit
> >>> image data
> >>> +to LVDS panels. This bindings supports display panels compatible with
> >>> the
> >>> +following specifications.
> >>> +
> >>> +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
> >>> February
> >>> +1999 (Version 1.0), Japan Electronic Industry Development Association
> >>> (JEIDA)
> >>> +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
> >>> +Semiconductor
> >>> +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
> >>> Video
> >>> +Electronics Standards Association (VESA)
> >>> +
> >>> +Device compatible with those specifications have been marketed under
> >>> the
> >>> +FPD-Link and FlatLink brands.
> >>> +
> >>> +
> >>> +Required properties:
> >>> +- compatible: shall contain "panel-lvds"
> >> 
> >> Maybe as a fallback, but on its own, no way.
> > 
> > Which brings an interesting question: when designing generic DT bindings,
> > what's the rule regarding

Looks like I forgot part of the question. I meant to ask what is the rule 
regarding usage of more precise compatible strings ?

For instance (but perhaps not the best example), the input/rotary-encoder.txt 
bindings define a "rotary-encoder" compatible string, with no other bindings 
defining more precise compatible strings for the exact rotary encoder model. 
When it comes to panels I believe it makes sense to define model-specific 
compatible strings even if they're unused by drivers. I'm however wondering 
what the rule is there, and where those device-specific compatible strings 
should be defined. I'd like to avoid using one file per panel model as done 
today for the simple-panel bindings.

> Call it "simple" so I can easily NAK it. :)
> 
> Define a generic structure, not a single binding trying to serve all.
> 
> >> > +- width-mm: panel display width in millimeters
> >> > +- height-mm: panel display height in millimeters
> >> 
> >> This is already documented for all panels IIRC.
> > 
> > Note that this DT binding has nothing to do with the simple-panel binding.
> > It is instead similar to the panel-dpi and panel-dsi-cm bindings (which
> > currently don't but should specify the panel size in DT). The LVDS panel
> > driver will *not* include any panel-specific information such as size or
> > timings, these are specified in DT.
> 
> The panel bindings aren't really different. The biggest difference was
> location in the tree, but we now generally allow panels to be either a
> child of the LCD controller or connected with OF graph. We probably
> need to work on restructuring the panel bindings a bit. We should have
> an inheritance with a base panel binding of things like size, label,
> graph, backlight, etc, then perhaps an interface specific bindings for
> LVDS, DSI, and parallel, then a panel specific binding. With this the
> panel specific binding is typically just a compatible string and which
> inherited properties apply to it.

That sounds good to me, but we have multiple models for panel bindings.

As you mentioned panels can be referenced through an LCD controller node 
property containing a phandle to the panel node, or through OF graph. That's a 
situation we have today, and we need to keep supporting both (at least for 
existing panels, perhaps not for the new ones).

Another difference is how to express panel data such as size and timings. The 
simple-panel DT bindings don't contain such data and expects the drivers to 
contain a table of panel data for all models supported, while the DPI, DSI and 
now the proposed LVDS panel bindings contain properties for panel

Re: [PATCH 54/57] [media] platform: don't break long lines

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Friday 14 Oct 2016 17:20:42 Mauro Carvalho Chehab wrote:
> Due to the 80-cols checkpatch warnings, several strings
> were broken into multiple lines. This is not considered
> a good practice anymore, as it makes harder to grep for
> strings at the source code. So, join those continuation
> lines.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/platform/mx2_emmaprp.c | 3 +--
>  drivers/media/platform/pxa_camera.c  | 6 ++
>  drivers/media/platform/via-camera.c  | 7 ++-
>  3 files changed, 5 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/platform/mx2_emmaprp.c
> b/drivers/media/platform/mx2_emmaprp.c index e68d271b10af..ea572718a638
> 100644
> --- a/drivers/media/platform/mx2_emmaprp.c
> +++ b/drivers/media/platform/mx2_emmaprp.c
> @@ -724,8 +724,7 @@ static int emmaprp_buf_prepare(struct vb2_buffer *vb)
>   q_data = get_q_data(ctx, vb->vb2_queue->type);
> 
>   if (vb2_plane_size(vb, 0) < q_data->sizeimage) {
> - dprintk(ctx->dev, "%s data will not fit into plane"
> -   "(%lu < %lu)\n", __func__,
> + dprintk(ctx->dev, "%s data will not fit into plane(%lu < 
%lu)\n",
> __func__, vb2_plane_size(vb, 0),
> (long)q_data->sizeimage);

If you really want to perform such a change, let's not make lines 
unnecessarily long either. You should add a line break after the first and 
second argument:

dprintk(ctx->dev,
"%s data will not fit into plane(%lu < %lu)\n",
__func__, vb2_plane_size(vb, 0),
(long)q_data->sizeimage);

And everything will fit in 80 columns.

>   return -EINVAL;
> diff --git a/drivers/media/platform/pxa_camera.c
> b/drivers/media/platform/pxa_camera.c index c12209c701d3..bcdac4932fb1
> 100644
> --- a/drivers/media/platform/pxa_camera.c
> +++ b/drivers/media/platform/pxa_camera.c
> @@ -2347,8 +2347,7 @@ static int pxa_camera_probe(struct platform_device
> *pdev) * Platform hasn't set available data widths. This is bad.
>* Warn and use a default.
>*/
> - dev_warn(&pdev->dev, "WARNING! Platform hasn't set available "
> -  "data widths, using default 10 bit\n");
> + dev_warn(&pdev->dev, "WARNING! Platform hasn't set available 
data widths,
> using default 10 bit\n");

Same comment here, you should add a line break after the first argument.

I assume the same comment applied to the 56 other patches in the series.

>   pcdev->platform_flags |= PXA_CAMERA_DATAWIDTH_10;
>   }
>   if (pcdev->platform_flags & PXA_CAMERA_DATAWIDTH_8)
> @@ -2359,8 +2358,7 @@ static int pxa_camera_probe(struct platform_device
> *pdev) pcdev->width_flags |= 1 << 9;
>   if (!pcdev->mclk) {
>   dev_warn(&pdev->dev,
> -  "mclk == 0! Please, fix your platform data. "
> -  "Using default 20MHz\n");
> +  "mclk == 0! Please, fix your platform data. Using 
default 20MHz\n");
>   pcdev->mclk = 2000;
>   }
> 
> diff --git a/drivers/media/platform/via-camera.c
> b/drivers/media/platform/via-camera.c index 7ca12deba89c..e16f70a5df1d
> 100644
> --- a/drivers/media/platform/via-camera.c
> +++ b/drivers/media/platform/via-camera.c
> @@ -39,15 +39,12 @@ MODULE_LICENSE("GPL");
>  static bool flip_image;
>  module_param(flip_image, bool, 0444);
>  MODULE_PARM_DESC(flip_image,
> - "If set, the sensor will be instructed to flip the image "
> - "vertically.");
> + "If set, the sensor will be instructed to flip the image 
vertically.");
> 
>  static bool override_serial;
>  module_param(override_serial, bool, 0444);
>  MODULE_PARM_DESC(override_serial,
> - "The camera driver will normally refuse to load if "
> - "the XO 1.5 serial port is enabled.  Set this option "
> - "to force-enable the camera.");
> + "The camera driver will normally refuse to load if the XO 1.5 
serial port
> is enabled.  Set this option to force-enable the camera.");
> 
>  /*
>   * The structure describing our camera.

-- 
Regards,

Laurent Pinchart

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

Re: V4L2_DEC_CMD_STOP and last_buffer_dequeued

[Nicolas Dufresne]

Le samedi 15 octobre 2016 à 08:16 +0800, Wu-Cheng Li (李務誠) a écrit :
> last_buffer_dequeued is only cleared to false when CAPTURE queue is
> STREAMOFF (#1). Queuing a header to OUTPUT queue won't clear
> last_buffer_dequeued of CAPTURE queue. It looks to me that v4l2 core
> needs to intercept CMD_START and clear last_buffer_dequeued. What do
> you think?
> 
> http://lxr.free-electrons.com/source/drivers/media/v4l2-core/videobuf2-core.c#L1951

That sounds reasonable, assuming it does not break drivers.

> >
> >
> > Note that for many a flush is the action of getting rid of the pending
> > images and achieve by using STREAMOFF. While the effect of CMD_STOP is
> > to signal the decoder that no more encoded image will be queued, hence
> > remaining images should be delivered to userspace. They will
> > differentiate as a flush operation vs as drain operation. This is no
> > rocket science of course.
> 
> I see. What I want is drain operation. In Chromium terms, CMD_STOP
> maps to flush and STREAMOFF maps to reset.

Yes, that's the reason I was mentioning. This was a great source of
confusion during a workshop with some Google/Chromium folks.

A question on top of this, what are the use cases for you to drain
without flushing afteward ? Is it really needed ?

regards,
Nicolas

signature.asc
Description: This is a digitally signed message part

Re: [PATCH 25/57] [media] omap: don't break long lines

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Friday 14 Oct 2016 17:20:13 Mauro Carvalho Chehab wrote:
> Due to the 80-cols checkpatch warnings, several strings
> were broken into multiple lines. This is not considered
> a good practice anymore, as it makes harder to grep for
> strings at the source code. So, join those continuation
> lines.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/platform/omap/omap_vout.c  | 12 
>  drivers/media/platform/omap/omap_vout_vrfb.c |  3 +--
>  2 files changed, 5 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/media/platform/omap/omap_vout.c
> b/drivers/media/platform/omap/omap_vout.c index e668dde6d857..ab0b941c64a4
> 100644
> --- a/drivers/media/platform/omap/omap_vout.c
> +++ b/drivers/media/platform/omap/omap_vout.c
> @@ -1657,8 +1657,7 @@ static int vidioc_streamoff(struct file *file, void
> *fh, enum v4l2_buf_type i) /* Turn of the pipeline */
>   ret = omapvid_apply_changes(vout);
>   if (ret)
> - v4l2_err(&vout->vid_dev->v4l2_dev, "failed to change mode in"
> - " streamoff\n");
> + v4l2_err(&vout->vid_dev->v4l2_dev, "failed to change mode in
> streamoff\n");

As mentioned in a reply to patch 54/57 (if I recall correctly), you should add 
a line break after the first argument of the function.

> 
>   INIT_LIST_HEAD(&vout->dma_queue);
>   ret = videobuf_streamoff(&vout->vbq);
> @@ -1858,8 +1857,7 @@ static int __init omap_vout_setup_video_data(struct
> omap_vout_device *vout) vfd = vout->vfd = video_device_alloc();
> 
>   if (!vfd) {
> - printk(KERN_ERR VOUT_NAME ": could not allocate"
> - " video device struct\n");
> + printk(KERN_ERR VOUT_NAME ": could not allocate video device 
struct\n");
>   v4l2_ctrl_handler_free(hdl);
>   return -ENOMEM;
>   }
> @@ -1984,16 +1982,14 @@ static int __init
> omap_vout_create_video_devices(struct platform_device *pdev) */
>   vfd = vout->vfd;
>   if (video_register_device(vfd, VFL_TYPE_GRABBER, -1) < 0) {
> - dev_err(&pdev->dev, ": Could not register "
> - "Video for Linux device\n");
> + dev_err(&pdev->dev, ": Could not register Video for 
Linux device\n");

Same here.

>   vfd->minor = -1;
>   ret = -ENODEV;
>   goto error2;
>   }
>   video_set_drvdata(vfd, vout);
> 
> - dev_info(&pdev->dev, ": registered and initialized"
> - " video device %d\n", vfd->minor);
> + dev_info(&pdev->dev, ": registered and initialized video 
device %d\n",
> vfd->minor);

And here, with a line break after the second argument too.

>   if (k == (pdev->num_resources - 1))
>   return 0;
> 
> diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c
> b/drivers/media/platform/omap/omap_vout_vrfb.c index
> b8638e4e1627..19768f249192 100644
> --- a/drivers/media/platform/omap/omap_vout_vrfb.c
> +++ b/drivers/media/platform/omap/omap_vout_vrfb.c
> @@ -139,8 +139,7 @@ int omap_vout_setup_vrfb_bufs(struct platform_device
> *pdev, int vid_num, (void *) &vout->vrfb_dma_tx,
> &vout->vrfb_dma_tx.dma_ch);
>   if (ret < 0) {
>   vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
> - dev_info(&pdev->dev, ": failed to allocate DMA Channel for"
> - " video%d\n", vfd->minor);
> + dev_info(&pdev->dev, ": failed to allocate DMA Channel for 
video%d\n",
> vfd->minor);

Ditto.

>   }
>   init_waitqueue_head(&vout->vrfb_dma_tx.wait);

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 26/57] [media] omap3isp: don't break long lines

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

As commented before, please add line breaks after function arguments to keep 
lines within the 80 columns limit where possible.

On Friday 14 Oct 2016 17:20:14 Mauro Carvalho Chehab wrote:
> Due to the 80-cols checkpatch warnings, several strings
> were broken into multiple lines. This is not considered
> a good practice anymore, as it makes harder to grep for
> strings at the source code. So, join those continuation
> lines.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/platform/omap3isp/isp.c |  3 +--
>  drivers/media/platform/omap3isp/ispccdc.c |  6 ++---
>  drivers/media/platform/omap3isp/ispcsi2.c | 11 ++--
>  drivers/media/platform/omap3isp/ispcsiphy.c   |  3 +--
>  drivers/media/platform/omap3isp/isph3a_aewb.c |  6 ++---
>  drivers/media/platform/omap3isp/isph3a_af.c   |  6 ++---
>  drivers/media/platform/omap3isp/ispstat.c | 36 
>  7 files changed, 22 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 0321d84addc7..a9d4347bf100
> 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -480,8 +480,7 @@ void omap3isp_hist_dma_done(struct isp_device *isp)
>   omap3isp_stat_pcr_busy(&isp->isp_hist)) {
>   /* Histogram cannot be enabled in this frame anymore */
>   atomic_set(&isp->isp_hist.buf_err, 1);
> - dev_dbg(isp->dev, "hist: Out of synchronization with "
> -   "CCDC. Ignoring next buffer.\n");
> + dev_dbg(isp->dev, "hist: Out of synchronization with CCDC. 
Ignoring next
> buffer.\n"); }
>  }
> 
> diff --git a/drivers/media/platform/omap3isp/ispccdc.c
> b/drivers/media/platform/omap3isp/ispccdc.c index
> 882310eb45cc..3f8e71c8ea48 100644
> --- a/drivers/media/platform/omap3isp/ispccdc.c
> +++ b/drivers/media/platform/omap3isp/ispccdc.c
> @@ -151,8 +151,7 @@ static int ccdc_lsc_validate_config(struct
> isp_ccdc_device *ccdc, }
> 
>   if (lsc_cfg->offset & 3) {
> - dev_dbg(isp->dev, "CCDC: LSC: Offset must be a multiple of "
> - "4\n");
> + dev_dbg(isp->dev, "CCDC: LSC: Offset must be a multiple of 
4\n");
>   return -EINVAL;
>   }
> 
> @@ -416,8 +415,7 @@ static int ccdc_lsc_config(struct isp_ccdc_device *ccdc,
> return 0;
> 
>   if (update != (OMAP3ISP_CCDC_CONFIG_LSC | OMAP3ISP_CCDC_TBL_LSC)) {
> - dev_dbg(to_device(ccdc), "%s: Both LSC configuration and table 
"
> - "need to be supplied\n", __func__);
> + dev_dbg(to_device(ccdc), "%s: Both LSC configuration and table 
need to be
> supplied\n", __func__); return -EINVAL;
>   }
> 
> diff --git a/drivers/media/platform/omap3isp/ispcsi2.c
> b/drivers/media/platform/omap3isp/ispcsi2.c index
> f75a1be29d84..53a7573ed2a5 100644
> --- a/drivers/media/platform/omap3isp/ispcsi2.c
> +++ b/drivers/media/platform/omap3isp/ispcsi2.c
> @@ -753,8 +753,7 @@ void omap3isp_csi2_isr(struct isp_csi2_device *csi2)
>ISPCSI2_PHY_IRQSTATUS);
>   isp_reg_writel(isp, cpxio1_irqstatus,
>  csi2->regs1, ISPCSI2_PHY_IRQSTATUS);
> - dev_dbg(isp->dev, "CSI2: ComplexIO Error IRQ "
> - "%x\n", cpxio1_irqstatus);
> + dev_dbg(isp->dev, "CSI2: ComplexIO Error IRQ %x\n", 
cpxio1_irqstatus);
>   pipe->error = true;
>   }
> 
> @@ -763,13 +762,7 @@ void omap3isp_csi2_isr(struct isp_csi2_device *csi2)
> ISPCSI2_IRQSTATUS_ECC_NO_CORRECTION_IRQ |
> ISPCSI2_IRQSTATUS_COMPLEXIO2_ERR_IRQ |
> ISPCSI2_IRQSTATUS_FIFO_OVF_IRQ)) {
> - dev_dbg(isp->dev, "CSI2 Err:"
> - " OCP:%d,"
> - " Short_pack:%d,"
> - " ECC:%d,"
> - " CPXIO2:%d,"
> - " FIFO_OVF:%d,"
> - "\n",
> + dev_dbg(isp->dev, "CSI2 Err: OCP:%d, Short_pack:%d, ECC:%d, 
CPXIO2:%d,
> FIFO_OVF:%d,\n", (csi2_irqstatus &
>ISPCSI2_IRQSTATUS_OCP_ERR_IRQ) ? 1 : 0,
>   (csi2_irqstatus &
> diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
> b/drivers/media/platform/omap3isp/ispcsiphy.c index
> 495447d66cfd..f67fd2f09f00 100644
> --- a/drivers/media/platform/omap3isp/ispcsiphy.c
> +++ b/drivers/media/platform/omap3isp/ispcsiphy.c
> @@ -267,8 +267,7 @@ int omap3isp_csiphy_acquire(struct isp_csiphy *phy)
>   int rval;
> 
>   if (phy->vdd == NULL) {
> - dev_err(phy->isp->dev, "Power regulator for CSI PHY not "
> - "available\n");
> + dev_err(phy->isp->dev, "Power regulator for CSI PHY not 
available\n");
>   return -ENODEV;
>   }
> 
> diff 

Re: [PATCH 49/57] [media] uvc: don't break long lines

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

Same comment, please add line breaks where applicable.

On Friday 14 Oct 2016 17:20:37 Mauro Carvalho Chehab wrote:
> Due to the 80-cols checkpatch warnings, several strings
> were broken into multiple lines. This is not considered
> a good practice anymore, as it makes harder to grep for
> strings at the source code. So, join those continuation
> lines.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/uvc/uvc_ctrl.c|  24 ++
>  drivers/media/usb/uvc/uvc_debugfs.c |   3 +-
>  drivers/media/usb/uvc/uvc_driver.c  | 148 ++--
>  drivers/media/usb/uvc/uvc_entity.c  |   6 +-
>  drivers/media/usb/uvc/uvc_isight.c  |   9 +--
>  drivers/media/usb/uvc/uvc_status.c  |  15 ++--
>  drivers/media/usb/uvc/uvc_v4l2.c|   6 +-
>  drivers/media/usb/uvc/uvc_video.c   |  69 ++---
>  8 files changed, 91 insertions(+), 189 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> b/drivers/media/usb/uvc/uvc_ctrl.c index c2ee6e39fd0c..6f26451bcb75 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -960,8 +960,7 @@ static int uvc_ctrl_populate_cache(struct
> uvc_video_chain *chain, * resolution value to zero.
>*/
>   uvc_warn_once(chain->dev, UVC_WARN_XU_GET_RES,
> -   "UVC non compliance - GET_RES failed on 
"
> -   "an XU control. Enabling workaround.
\n");
> +   "UVC non compliance - GET_RES failed on 
an XU control. Enabling
> workaround.\n"); memset(uvc_ctrl_data(ctrl, UVC_CTRL_DATA_RES), 0,
>  ctrl->info.size);
>   }
> @@ -1680,8 +1679,7 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device
> *dev,
> 
>   uvc_ctrl_fixup_xu_info(dev, ctrl, info);
> 
> - uvc_trace(UVC_TRACE_CONTROL, "XU control %pUl/%u queried: len %u, "
> -   "flags { get %u set %u auto %u }.\n",
> + uvc_trace(UVC_TRACE_CONTROL, "XU control %pUl/%u queried: len %u, 
flags {
> get %u set %u auto %u }.\n", info->entity, info->selector, info->size,
> (info->flags & UVC_CTRL_FLAG_GET_CUR) ? 1 : 0,
> (info->flags & UVC_CTRL_FLAG_SET_CUR) ? 1 : 0,
> @@ -1710,8 +1708,7 @@ static int uvc_ctrl_init_xu_ctrl(struct uvc_device
> *dev,
> 
>   ret = uvc_ctrl_add_info(dev, ctrl, &info);
>   if (ret < 0)
> - uvc_trace(UVC_TRACE_CONTROL, "Failed to initialize control "
> -   "%pUl/%u on device %s entity %u\n", info.entity,
> + uvc_trace(UVC_TRACE_CONTROL, "Failed to initialize control 
%pUl/%u on
> device %s entity %u\n", info.entity, info.selector, dev->udev->devpath,
> ctrl->entity->id);
> 
>   return ret;
> @@ -1904,8 +1901,7 @@ static int uvc_ctrl_add_info(struct uvc_device *dev,
> struct uvc_control *ctrl,
> 
>   ctrl->initialized = 1;
> 
> - uvc_trace(UVC_TRACE_CONTROL, "Added control %pUl/%u to device %s "
> - "entity %u\n", ctrl->info.entity, ctrl->info.selector,
> + uvc_trace(UVC_TRACE_CONTROL, "Added control %pUl/%u to device %s 
entity
> %u\n", ctrl->info.entity, ctrl->info.selector, dev->udev->devpath,
> ctrl->entity->id);
> 
>  done:
> @@ -1964,8 +1960,7 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain
> *chain, int ret;
> 
>   if (mapping->id & ~V4L2_CTRL_ID_MASK) {
> - uvc_trace(UVC_TRACE_CONTROL, "Can't add mapping '%s', control 
"
> - "id 0x%08x is invalid.\n", mapping->name,
> + uvc_trace(UVC_TRACE_CONTROL, "Can't add mapping '%s', control 
id 0x%08x
> is invalid.\n", mapping->name, mapping->id);
>   return -EINVAL;
>   }
> @@ -2004,8 +1999,7 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain
> *chain,
> 
>   list_for_each_entry(map, &ctrl->info.mappings, list) {
>   if (mapping->id == map->id) {
> - uvc_trace(UVC_TRACE_CONTROL, "Can't add mapping '%s', 
"
> - "control id 0x%08x already exists.\n",
> + uvc_trace(UVC_TRACE_CONTROL, "Can't add mapping '%s', 
control id 0x%08x
> already exists.\n", mapping->name, mapping->id);
>   ret = -EEXIST;
>   goto done;
> @@ -2015,8 +2009,7 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain
> *chain, /* Prevent excess memory consumption */
>   if (atomic_inc_return(&dev->nmappings) > UVC_MAX_CONTROL_MAPPINGS) {
>   atomic_dec(&dev->nmappings);
> - uvc_trace(UVC_TRACE_CONTROL, "Can't add mapping '%s', maximum 
"
> - "mappings count (%u) exceeded.\n", mapping->name,
> + uvc_trace(UVC_TRACE_CONTROL, "Can't add mapping '%s', maximum 
mappings
> count (%u) exceeded.\n", mapping->name, UVC_MAX_CONTROL_MAPPINGS);
>   ret = -ENOMEM;
>   goto done;
> @@ -2086,8 +2079,7 @@ static void uvc_ctrl_p

Re: Trying to get TBS5880 to work on Ubuntu with Hauppauge

[Joacim J]

Hi

I have a fresh Ubuntu Server 16.04 install (for third time this
weekend) and trying to get my TBS5880 to work.

I have two "'Hauppauge Nova-T 500 Dual DVB-T" in the computer and
being recognized directly during install using:

root@frodo:~/tbs/linux-tbs-drivers# lsmod | grep dvb
dvb_usb_dib0700   147456  0
dib7000m   24576  1 dvb_usb_dib0700
dib009040960  1 dvb_usb_dib0700
dib007020480  1 dvb_usb_dib0700
dib3000mc  20480  3 dvb_usb_dib0700
dibx000_common 20480  3 dvb_usb_dib0700,dib3000mc,dib7000m
dvb_usb24576  1 dvb_usb_dib0700
dvb_core  122880  1 dvb_usb
rc_core28672  4 dvb_usb,dvb_usb_dib0700,rc_dib0700_rc5


When installing TBS5880 drivers as described it works fine:

# mv dvb-usb-tbsqbox-id5880.fw /lib/firmware/
# tar xjvf linux-tbs-drivers.tar.bz2
# cd linux-tbs-drivers
# ./v4l/tbs-x86_64.sh
# make && make install
# shutdown -r now

But afterwards, my Hauppauge cards are gone and no TBS either.
So the driver install doesn't work and also mess up Hauppauge cards.

What should I do?
How can I test with drivers without messing up the system?

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

Re: [PATCH 18/25] [media] uvc_driver: use KERN_CONT where needed

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Friday 14 Oct 2016 14:45:56 Mauro Carvalho Chehab wrote:
> Some continuation messages are not using KERN_CONT.
> 
> Since commit 563873318d32 ("Merge branch 'printk-cleanups"),
> this won't work as expected anymore. So, let's add KERN_CONT
> to those lines.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/usb/uvc/uvc_driver.c | 30 +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index 302e284a95eb..9c4b56b4a9c6
> 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1309,7 +1309,7 @@ static int uvc_scan_chain_entity(struct
> uvc_video_chain *chain, switch (UVC_ENTITY_TYPE(entity)) {
>   case UVC_VC_EXTENSION_UNIT:
>   if (uvc_trace_param & UVC_TRACE_PROBE)
> - printk(" <- XU %d", entity->id);
> + printk(KERN_CONT " <- XU %d", entity->id);
> 
>   if (entity->bNrInPins != 1) {
>   uvc_trace(UVC_TRACE_DESCR, "Extension unit %d has more 
"
> @@ -1321,7 +1321,7 @@ static int uvc_scan_chain_entity(struct
> uvc_video_chain *chain,
> 
>   case UVC_VC_PROCESSING_UNIT:
>   if (uvc_trace_param & UVC_TRACE_PROBE)
> - printk(" <- PU %d", entity->id);
> + printk(KERN_CONT " <- PU %d", entity->id);
> 
>   if (chain->processing != NULL) {
>   uvc_trace(UVC_TRACE_DESCR, "Found multiple "
> @@ -1334,7 +1334,7 @@ static int uvc_scan_chain_entity(struct
> uvc_video_chain *chain,
> 
>   case UVC_VC_SELECTOR_UNIT:
>   if (uvc_trace_param & UVC_TRACE_PROBE)
> - printk(" <- SU %d", entity->id);
> + printk(KERN_CONT " <- SU %d", entity->id);
> 
>   /* Single-input selector units are ignored. */
>   if (entity->bNrInPins == 1)
> @@ -1353,7 +1353,7 @@ static int uvc_scan_chain_entity(struct
> uvc_video_chain *chain, case UVC_ITT_CAMERA:
>   case UVC_ITT_MEDIA_TRANSPORT_INPUT:
>   if (uvc_trace_param & UVC_TRACE_PROBE)
> - printk(" <- IT %d\n", entity->id);
> + printk(KERN_CONT " <- IT %d\n", entity->id);
> 
>   break;
> 
> @@ -1361,17 +1361,17 @@ static int uvc_scan_chain_entity(struct
> uvc_video_chain *chain, case UVC_OTT_DISPLAY:
>   case UVC_OTT_MEDIA_TRANSPORT_OUTPUT:
>   if (uvc_trace_param & UVC_TRACE_PROBE)
> - printk(" OT %d", entity->id);
> + printk(KERN_CONT " OT %d", entity->id);
> 
>   break;
> 
>   case UVC_TT_STREAMING:
>   if (UVC_ENTITY_IS_ITERM(entity)) {
>   if (uvc_trace_param & UVC_TRACE_PROBE)
> - printk(" <- IT %d\n", entity->id);
> + printk(KERN_CONT " <- IT %d\n", entity->id);
>   } else {
>   if (uvc_trace_param & UVC_TRACE_PROBE)
> - printk(" OT %d", entity->id);
> + printk(KERN_CONT " OT %d", entity->id);
>   }
> 
>   break;
> @@ -1416,9 +1416,9 @@ static int uvc_scan_chain_forward(struct
> uvc_video_chain *chain, list_add_tail(&forward->chain, &chain->entities);
>   if (uvc_trace_param & UVC_TRACE_PROBE) {
>   if (!found)
> - printk(" (->");
> + printk(KERN_CONT " (->");
> 
> - printk(" XU %d", forward->id);
> + printk(KERN_CONT " XU %d", forward->id);
>   found = 1;
>   }
>   break;
> @@ -1436,16 +1436,16 @@ static int uvc_scan_chain_forward(struct
> uvc_video_chain *chain, list_add_tail(&forward->chain, &chain->entities);
>   if (uvc_trace_param & UVC_TRACE_PROBE) {
>   if (!found)
> - printk(" (->");
> + printk(KERN_CONT " (->");
> 
> - printk(" OT %d", forward->id);
> + printk(KERN_CONT " OT %d", forward->id);
>   found = 1;
>   }
>   break;
>   }
>   }
>   if (found)
> - printk(")");
> + printk(KERN_CONT ")");
> 
>   return 0;
>  }
> @@ -1471,7 +1471,7 @@ static int uvc_scan_chain_backward(struct
> uvc_video_chain *chain, }
> 
>   if (uvc_trace_param & UVC_TRACE_PROBE)
> - printk(" <- IT");
> + printk(KERN_CONT " <- IT");
> 
>   chain->selector = entity;
>  

Re: [PATCH 53/57] [media] i2c: don't break long lines

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Friday 14 Oct 2016 17:20:41 Mauro Carvalho Chehab wrote:
> Due to the 80-cols checkpatch warnings, several strings
> were broken into multiple lines. This is not considered
> a good practice anymore, as it makes harder to grep for
> strings at the source code. So, join those continuation
> lines.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/i2c/as3645a.c  | 9 +++--
>  drivers/media/i2c/msp3400-kthreads.c | 3 +--
>  drivers/media/i2c/mt9m032.c  | 3 +--
>  drivers/media/i2c/mt9p031.c  | 3 +--
>  drivers/media/i2c/saa7115.c  | 3 +--
>  drivers/media/i2c/saa717x.c  | 3 +--
>  drivers/media/i2c/ths8200.c  | 4 +---
>  drivers/media/i2c/tvp5150.c  | 3 +--
>  drivers/media/i2c/tvp7002.c  | 3 +--
>  drivers/media/i2c/upd64083.c | 3 +--
>  10 files changed, 12 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/media/i2c/as3645a.c b/drivers/media/i2c/as3645a.c
> index 2e90e4094b79..95fcb8f68a1a 100644
> --- a/drivers/media/i2c/as3645a.c
> +++ b/drivers/media/i2c/as3645a.c
> @@ -299,8 +299,7 @@ static int as3645a_read_fault(struct as3645a *flash)
>   dev_dbg(&client->dev, "Inductor Peak limit fault\n");
> 
>   if (rval & AS_FAULT_INFO_INDICATOR_LED)
> - dev_dbg(&client->dev, "Indicator LED fault: "
> - "Short circuit or open loop\n");
> + dev_dbg(&client->dev, "Indicator LED fault: Short circuit or 
open
> loop\n");
> 
>   dev_dbg(&client->dev, "%u connected LEDs\n",
>   rval & AS_FAULT_INFO_LED_AMOUNT ? 2 : 1);
> @@ -315,8 +314,7 @@ static int as3645a_read_fault(struct as3645a *flash)
>   dev_dbg(&client->dev, "Short circuit fault\n");
> 
>   if (rval & AS_FAULT_INFO_OVER_VOLTAGE)
> - dev_dbg(&client->dev, "Over voltage fault: "
> - "Indicates missing capacitor or open connection\n");
> + dev_dbg(&client->dev, "Over voltage fault: Indicates missing 
capacitor or
> open connection\n");
> 
>   return rval;
>  }
> @@ -588,8 +586,7 @@ static int as3645a_registered(struct v4l2_subdev *sd)
> 
>   /* Verify the chip model and version. */
>   if (model != 0x01 || rfu != 0x00) {
> - dev_err(&client->dev, "AS3645A not detected "
> - "(model %d rfu %d)\n", model, rfu);
> + dev_err(&client->dev, "AS3645A not detected (model %d rfu 
%d)\n", model,
> rfu); rval = -ENODEV;
>   goto power_off;
>   }
> diff --git a/drivers/media/i2c/msp3400-kthreads.c
> b/drivers/media/i2c/msp3400-kthreads.c index 17120804fab7..022bea68cbf0
> 100644
> --- a/drivers/media/i2c/msp3400-kthreads.c
> +++ b/drivers/media/i2c/msp3400-kthreads.c
> @@ -775,8 +775,7 @@ int msp3410d_thread(void *data)
>   if (msp_amsound && !state->radio &&
>   (state->v4l2_std & V4L2_STD_SECAM) && (val != 0x0009)) {
>   /* autodetection has failed, let backup */
> - v4l_dbg(1, msp_debug, client, "autodetection failed,"
> - " switching to backup standard: %s 
(0x%04x)\n",
> + v4l_dbg(1, msp_debug, client, "autodetection failed, 
switching to backup
> standard: %s (0x%04x)\n", msp_stdlist[8].name ?
>   msp_stdlist[8].name : "unknown", val);
>   state->std = val = 0x0009;
> diff --git a/drivers/media/i2c/mt9m032.c b/drivers/media/i2c/mt9m032.c
> index da076796999e..a045425887d5 100644
> --- a/drivers/media/i2c/mt9m032.c
> +++ b/drivers/media/i2c/mt9m032.c
> @@ -746,8 +746,7 @@ static int mt9m032_probe(struct i2c_client *client,
> 
>   chip_version = mt9m032_read(client, MT9M032_CHIP_VERSION);
>   if (chip_version != MT9M032_CHIP_VERSION_VALUE) {
> - dev_err(&client->dev, "MT9M032 not detected, wrong version "
> - "0x%04x\n", chip_version);
> + dev_err(&client->dev, "MT9M032 not detected, wrong version 
0x%04x\n",
> chip_version); ret = -ENODEV;
>   goto error_sensor;
>   }
> diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
> index 237737fec09c..4d7b56b96a92 100644
> --- a/drivers/media/i2c/mt9p031.c
> +++ b/drivers/media/i2c/mt9p031.c
> @@ -929,8 +929,7 @@ static int mt9p031_registered(struct v4l2_subdev
> *subdev) mt9p031_power_off(mt9p031);
> 
>   if (data != MT9P031_CHIP_VERSION_VALUE) {
> - dev_err(&client->dev, "MT9P031 not detected, wrong version "
> - "0x%04x\n", data);
> + dev_err(&client->dev, "MT9P031 not detected, wrong version 
0x%04x\n",
> data); return -ENODEV;
>   }
> 
> diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
> index 58062b41c923..5db914b7d5ae 100644
> --- a/drivers/media/i2c/saa7115.c
> +++ b/drivers/media/i2c/saa7115.c
> @@ -53,8 +53,7 @@
>  #define VRES_60HZ(480+16)
> 
>  MO

Re: [ANN] Report of the V4L2 Request API brainstorm meeting

[Nicolas Dufresne]

Le lundi 17 octobre 2016 à 13:37 +0200, Hans Verkuil a écrit :
> 1.5 Requests vs. w/o requests
> 
> There are three options for drivers w.r.t. the request API:
> 
> 1) The driver doesn't use the request API
> 2) The driver requires the request API
> 3) The request API is optional.
> 
> It is not clear at this stage if 3 is ever needed. So for now just
> add a capability
> flag for "requests required". And add a "requests supported with
> legacy" flag later
> on if needed.

Simply adding a new flag will make both state-less and current CODEC
M2M drivers look the same. This will likely trick existing generic code
into trying those stateless decoder.

For backward compatibility, we need to replace an existing
categorization flag, like STREAMING or similar.

regards,
Nicolas

signature.asc
Description: This is a digitally signed message part

Re: [Patch 06/35] media: ti-vpe: vpe: Do not perform job transaction atomically

[Hans Verkuil]

On 09/28/2016 11:20 PM, Benoit Parrot wrote:
> From: Nikhil Devshatwar 
> 
> Current VPE driver does not start the job until all the buffers for
> a transaction are not queued. When running in multiple context, this might

I think this should be: s/not queued/queued/, right?

> increase the processing latency.
> 
> Alternate solution would be to try to continue the same context as long as
> buffers for the transaction are ready; else switch the context. This may
> increase number of context switches but it reduces latency significantly.
> 
> In this approach, the job_ready always succeeds as long as there are
> buffers on the CAPTURE and OUTPUT stream. Processing may start immediately
> as the first 2 iterations don't need extra source buffers. Shift all the
> source buffers after each iteration and remove the oldest buffer.
> 
> Also, with this removes the constraint of pre buffering 3 buffers before
> call to STREAMON in case of de-interlacing.
> 
> Signed-off-by: Nikhil Devshatwar 
> Signed-off-by: Benoit Parrot 
> ---
>  drivers/media/platform/ti-vpe/vpe.c | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/media/platform/ti-vpe/vpe.c 
> b/drivers/media/platform/ti-vpe/vpe.c
> index a0b29685fb69..9c38eff5df46 100644
> --- a/drivers/media/platform/ti-vpe/vpe.c
> +++ b/drivers/media/platform/ti-vpe/vpe.c
> @@ -898,15 +898,14 @@ static struct vpe_ctx *file2ctx(struct file *file)
>  static int job_ready(void *priv)
>  {
>   struct vpe_ctx *ctx = priv;
> - int needed = ctx->bufs_per_job;
>  
> - if (ctx->deinterlacing && ctx->src_vbs[2] == NULL)
> - needed += 2;/* need additional two most recent fields */
> -
> - if (v4l2_m2m_num_src_bufs_ready(ctx->fh.m2m_ctx) < needed)
> - return 0;
> -
> - if (v4l2_m2m_num_dst_bufs_ready(ctx->fh.m2m_ctx) < needed)
> + /*
> +  * This check is needed as this might be called directly from driver
> +  * When called by m2m framework, this will always satisy, but when

typo: satisfy

> +  * called from vpe_irq, this might fail. (src stream with zero buffers)
> +  */
> + if (v4l2_m2m_num_src_bufs_ready(ctx->fh.m2m_ctx) <= 0 ||
> + v4l2_m2m_num_dst_bufs_ready(ctx->fh.m2m_ctx) <= 0)
>   return 0;
>  
>   return 1;
> @@ -1116,19 +1115,20 @@ static void device_run(void *priv)
>   struct sc_data *sc = ctx->dev->sc;
>   struct vpe_q_data *d_q_data = &ctx->q_data[Q_DATA_DST];
>  
> - if (ctx->deinterlacing && ctx->src_vbs[2] == NULL) {
> - ctx->src_vbs[2] = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> - WARN_ON(ctx->src_vbs[2] == NULL);
> - ctx->src_vbs[1] = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> - WARN_ON(ctx->src_vbs[1] == NULL);
> - }
> -
>   ctx->src_vbs[0] = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
>   WARN_ON(ctx->src_vbs[0] == NULL);
>   ctx->dst_vb = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
>   WARN_ON(ctx->dst_vb == NULL);
>  
>   if (ctx->deinterlacing) {
> +
> + if (ctx->src_vbs[2] == NULL) {
> + ctx->src_vbs[2] = ctx->src_vbs[0];
> + WARN_ON(ctx->src_vbs[2] == NULL);
> + ctx->src_vbs[1] = ctx->src_vbs[0];
> + WARN_ON(ctx->src_vbs[1] == NULL);
> + }
> +
>   /*
>* we have output the first 2 frames through line average, we
>* now switch to EDI de-interlacer
> @@ -1349,7 +1349,7 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
>   }
>  
>   ctx->bufs_completed++;
> - if (ctx->bufs_completed < ctx->bufs_per_job) {
> + if (ctx->bufs_completed < ctx->bufs_per_job && job_ready(ctx)) {
>   device_run(ctx);
>   goto handled;
>   }
> 

Regards,

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

Re: [Patch 01/35] media: ti-vpe: vpdma: Make vpdma library into its own module

[Hans Verkuil]

On 09/28/2016 11:16 PM, Benoit Parrot wrote:
> The VPDMA (Video Port DMA) as found in devices such as DRA7xx is
> used for both the Video Processing Engine (VPE) and the Video Input
> Port (VIP).
> 
> In preparation for this we need to turn vpdma into its own
> kernel module.
> 
> Signed-off-by: Benoit Parrot 
> ---
>  drivers/media/platform/Kconfig |  6 ++
>  drivers/media/platform/ti-vpe/Makefile |  4 +++-
>  drivers/media/platform/ti-vpe/vpdma.c  | 28 +++-
>  3 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index f98ed3fd0efd..3c15c5a53bd5 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -334,6 +334,7 @@ config VIDEO_TI_VPE
>   depends on HAS_DMA
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_MEM2MEM_DEV
> + select VIDEO_TI_VPDMA
>   default n
>   ---help---
> Support for the TI VPE(Video Processing Engine) block
> @@ -347,6 +348,11 @@ config VIDEO_TI_VPE_DEBUG
>  
>  endif # V4L_MEM2MEM_DRIVERS
>  
> +# TI VIDEO PORT Helper Modules
> +# These will be selected by VPE and VIP
> +config VIDEO_TI_VPDMA
> + tristate
> +
>  menuconfig V4L_TEST_DRIVERS
>   bool "Media test drivers"
>   depends on MEDIA_CAMERA_SUPPORT
> diff --git a/drivers/media/platform/ti-vpe/Makefile 
> b/drivers/media/platform/ti-vpe/Makefile
> index e236059a60ad..faca5e115c1d 100644
> --- a/drivers/media/platform/ti-vpe/Makefile
> +++ b/drivers/media/platform/ti-vpe/Makefile
> @@ -1,6 +1,8 @@
>  obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe.o
> +obj-$(CONFIG_VIDEO_TI_VPDMA) += ti-vpdma.o
>  
> -ti-vpe-y := vpe.o sc.o csc.o vpdma.o
> +ti-vpe-y := vpe.o sc.o csc.o
> +ti-vpdma-y := vpdma.o
>  
>  ccflags-$(CONFIG_VIDEO_TI_VPE_DEBUG) += -DDEBUG
>  
> diff --git a/drivers/media/platform/ti-vpe/vpdma.c 
> b/drivers/media/platform/ti-vpe/vpdma.c
> index 3e2e3a33e6ed..e55cb58213bf 100644
> --- a/drivers/media/platform/ti-vpe/vpdma.c
> +++ b/drivers/media/platform/ti-vpe/vpdma.c
> @@ -75,6 +75,7 @@ const struct vpdma_data_format vpdma_yuv_fmts[] = {
>   .depth  = 16,
>   },
>  };
> +EXPORT_SYMBOL(vpdma_yuv_fmts);

EXPORT_SYMBOL_GPL?

(Up to you).

Regards,

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

Re: [Patch 05/35] media: ti-vpe: Use line average de-interlacing for first 2 frames

[Hans Verkuil]

On 09/28/2016 11:20 PM, Benoit Parrot wrote:
> From: Archit Taneja 
> 
> For n input fields, the VPE de-interlacer creates n - 2 progressive frames.

That's confusing. I think you mean '(n / 2) - 1'? Two fields make one frame, 
right?

Regards,

Hans

> 
> To support this, we use line average mode of de-interlacer for the first 2
> input fields to generate 2 progressive frames. We then revert back to the
> preferred EDI method, and create n - 2 frames, creating a sum of n frames.
> 
> Signed-off-by: Archit Taneja 
> Signed-off-by: Nikhil Devshatwar 
> Signed-off-by: Benoit Parrot 
> ---
>  drivers/media/platform/ti-vpe/vpe.c | 33 +++--
>  1 file changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/ti-vpe/vpe.c 
> b/drivers/media/platform/ti-vpe/vpe.c
> index 3921fd8cdf1d..a0b29685fb69 100644
> --- a/drivers/media/platform/ti-vpe/vpe.c
> +++ b/drivers/media/platform/ti-vpe/vpe.c
> @@ -141,7 +141,7 @@ struct vpe_dei_regs {
>   */
>  static const struct vpe_dei_regs dei_regs = {
>   .mdt_spacial_freq_thr_reg = 0x020C0804u,
> - .edi_config_reg = 0x0118100Fu,
> + .edi_config_reg = 0x0118100Cu,
>   .edi_lut_reg0 = 0x08040200u,
>   .edi_lut_reg1 = 0x1010100Cu,
>   .edi_lut_reg2 = 0x10101010u,
> @@ -798,6 +798,23 @@ static void set_dei_shadow_registers(struct vpe_ctx *ctx)
>   ctx->load_mmrs = true;
>  }
>  
> +static void config_edi_input_mode(struct vpe_ctx *ctx, int mode)
> +{
> + struct vpe_mmr_adb *mmr_adb = ctx->mmr_adb.addr;
> + u32 *edi_config_reg = &mmr_adb->dei_regs[3];
> +
> + if (mode & 0x2)
> + write_field(edi_config_reg, 1, 1, 2);   /* EDI_ENABLE_3D */
> +
> + if (mode & 0x3)
> + write_field(edi_config_reg, 1, 1, 3);   /* EDI_CHROMA_3D  */
> +
> + write_field(edi_config_reg, mode, VPE_EDI_INP_MODE_MASK,
> + VPE_EDI_INP_MODE_SHIFT);
> +
> + ctx->load_mmrs = true;
> +}
> +
>  /*
>   * Set the shadow registers whose values are modified when either the
>   * source or destination format is changed.
> @@ -,6 +1128,15 @@ static void device_run(void *priv)
>   ctx->dst_vb = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
>   WARN_ON(ctx->dst_vb == NULL);
>  
> + if (ctx->deinterlacing) {
> + /*
> +  * we have output the first 2 frames through line average, we
> +  * now switch to EDI de-interlacer
> +  */
> + if (ctx->sequence == 2)
> + config_edi_input_mode(ctx, 0x3); /* EDI (Y + UV) */
> + }
> +
>   /* config descriptors */
>   if (ctx->dev->loaded_mmrs != ctx->mmr_adb.dma_addr || ctx->load_mmrs) {
>   vpdma_map_desc_buf(ctx->dev->vpdma, &ctx->mmr_adb);
> @@ -1865,7 +1891,10 @@ static void vpe_buf_queue(struct vb2_buffer *vb)
>  
>  static int vpe_start_streaming(struct vb2_queue *q, unsigned int count)
>  {
> - /* currently we do nothing here */
> + struct vpe_ctx *ctx = vb2_get_drv_priv(q);
> +
> + if (ctx->deinterlacing)
> + config_edi_input_mode(ctx, 0x0);
>  
>   return 0;
>  }
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Patch 00/35] media: ti-vpe: fixes and enhancements

[Hans Verkuil]

On 09/28/2016 11:16 PM, Benoit Parrot wrote:
> This patch series is to publish a number of enhancements
> we have been carrying for a while.
> 
> A number of bug fixes and feature enhancements have been
> included.
> 
> We also need to prepare the way for the introduction of
> the VIP (Video Input Port) driver (coming soon) which
> has internal IP module in common with VPE.
> 
> The relevant modules (vpdma, sc and csc) are therefore converted
> into individual kernel modules.

Other than the few comments I made this patch series looks OK.

You can add my

Acked-by: Hans Verkuil 

to those patches where I didn't make any comments.

Regards,

Hans

> 
> Archit Taneja (1):
>   media: ti-vpe: Use line average de-interlacing for first 2 frames
> 
> Benoit Parrot (16):
>   media: ti-vpe: vpdma: Make vpdma library into its own module
>   media: ti-vpe: vpdma: Add multi-instance and multi-client support
>   media: ti-vpe: vpdma: Add helper to set a background color
>   media: ti-vpe: vpdma: Fix bus error when vpdma is writing a descriptor
>   media: ti-vpe: vpe: Added MODULE_DEVICE_TABLE hint
>   media: ti-vpe: vpdma: Corrected YUV422 data type label.
>   media: ti-vpe: vpdma: RGB data type yield inverted data
>   media: ti-vpe: vpe: Fix vb2 buffer cleanup
>   media: ti-vpe: vpe: Enable DMABUF export
>   media: ti-vpe: Make scaler library into its own module
>   media: ti-vpe: scaler: Add debug support for multi-instance
>   media: ti-vpe: vpe: Make sure frame size dont exceed scaler capacity
>   media: ti-vpe: vpdma: Add RAW8 and RAW16 data types
>   media: ti-vpe: Make colorspace converter library into its own module
>   media: ti-vpe: csc: Add debug support for multi-instance
>   media: ti-vpe: vpe: Add proper support single and multi-plane buffer
> 
> Harinarayan Bhatta (2):
>   media: ti-vpe: Increasing max buffer height and width
>   media: ti-vpe: Free vpdma buffers in vpe_release
> 
> Nikhil Devshatwar (16):
>   media: ti-vpe: vpe: Do not perform job transaction atomically
>   media: ti-vpe: Add support for SEQ_TB buffers
>   media: ti-vpe: vpe: Return NULL for invalid buffer type
>   media: ti-vpe: vpdma: Add support for setting max width height
>   media: ti-vpe: vpdma: Add abort channel desc and cleanup APIs
>   media: ti-vpe: vpdma: Make list post atomic operation
>   media: ti-vpe: vpdma: Clear IRQs for individual lists
>   media: ti-vpe: vpe: configure line mode separately
>   media: ti-vpe: vpe: Setup srcdst parameters in start_streaming
>   media: ti-vpe: vpe: Post next descriptor only for list complete IRQ
>   media: ti-vpe: vpe: Add RGB565 and RGB5551 support
>   media: ti-vpe: vpdma: allocate and maintain hwlist
>   media: ti-vpe: sc: Fix incorrect optimization
>   media: ti-vpe: vpdma: Fix race condition for firmware loading
>   media: ti-vpe: vpdma: Use bidirectional cached buffers
>   media: ti-vpe: vpe: Fix line stride for output motion vector
> 
>  drivers/media/platform/Kconfig |  14 +
>  drivers/media/platform/ti-vpe/Makefile |  10 +-
>  drivers/media/platform/ti-vpe/csc.c|  18 +-
>  drivers/media/platform/ti-vpe/csc.h|   2 +-
>  drivers/media/platform/ti-vpe/sc.c |  28 +-
>  drivers/media/platform/ti-vpe/sc.h |  11 +-
>  drivers/media/platform/ti-vpe/vpdma.c  | 349 +++---
>  drivers/media/platform/ti-vpe/vpdma.h  |  85 +-
>  drivers/media/platform/ti-vpe/vpdma_priv.h | 130 -
>  drivers/media/platform/ti-vpe/vpe.c| 450 
> -
>  10 files changed, 891 insertions(+), 206 deletions(-)
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] videobuf2-dma-contig: Support cacheable MMAP

[Sakari Ailus]

Hi Thierry,

On Fri, Oct 14, 2016 at 03:21:49PM +0200, Thierry Escande wrote:
> From: Heng-Ruey Hsu 
> 
> DMA allocations for MMAP type are uncached by default. But for
> some cases, CPU has to access the buffers. ie: memcpy for format
> converter. Supporting cacheable MMAP improves huge performance.

Does this patch basically make videobuf2-dma-contig work if you use the
DMA_ATTR_NO_KERNEL_MAPPING and DMA_ATTR_NON_CONSISTENT attributes? If so, it
should be mentioned in the commit message. No driver appears to be using
either of the two flags right now.

> 
> Signed-off-by: Heng-Ruey Hsu 
> Tested-by: Heng-ruey Hsu 
> Reviewed-by: Tomasz Figa 
> Signed-off-by: Thierry Escande 
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> index fb6a177..c953c24 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -42,6 +42,12 @@ struct vb2_dc_buf {
>  };
>  
>  /*/
> +/*   Forward declarations*/
> +/*/
> +
> +static struct sg_table *vb2_dc_get_base_sgt(struct vb2_dc_buf *buf);

If you need this above from where the function is right now, could you move
it up instead in a separate patch?

> +
> +/*/
>  /*scatterlist table functions*/
>  /*/
>  
> @@ -129,6 +135,10 @@ static void vb2_dc_put(void *buf_priv)
>   sg_free_table(buf->sgt_base);
>   kfree(buf->sgt_base);
>   }
> + if (buf->dma_sgt) {
> + sg_free_table(buf->dma_sgt);
> + kfree(buf->dma_sgt);
> + }
>   dma_free_attrs(buf->dev, buf->size, buf->cookie, buf->dma_addr,
>  buf->attrs);
>   put_device(buf->dev);
> @@ -170,6 +180,10 @@ static void *vb2_dc_alloc(struct device *dev, unsigned 
> long attrs,
>   buf->handler.put = vb2_dc_put;
>   buf->handler.arg = buf;
>  

It'd be nice to add a comment why this is being done. I don't think it's
entirely trivial.

> + if (!(buf->attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> +  (buf->attrs & DMA_ATTR_NON_CONSISTENT))
> + buf->dma_sgt = vb2_dc_get_base_sgt(buf);
> +
>   atomic_inc(&buf->refcount);
>  
>   return buf;
> @@ -205,6 +219,11 @@ static int vb2_dc_mmap(void *buf_priv, struct 
> vm_area_struct *vma)
>  
>   vma->vm_ops->open(vma);
>  
> + if ((buf->attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&

Is the DMA_ATTR_NO_KERNEL_MAPPING flag relevant here? I understand the
mapping is used to flush the cache, but you do need it independently of
whether or not the DMA_ATTR_NO_KERNEL_MAPPING flag is present, don't you?

> + (buf->attrs & DMA_ATTR_NON_CONSISTENT) &&
> + !buf->dma_sgt)

I think it'd be nicer to check for buf->dma_sgt first; up to you. You don't
need the extra parentheses either (some extra in the above chunk as well).

> + buf->dma_sgt = vb2_dc_get_base_sgt(buf);

What if vb2_dc_get_base_sgt() returns NULL here or in the chunk above?

> +
>   pr_debug("%s: mapped dma addr 0x%08lx at 0x%08lx, size %ld\n",
>   __func__, (unsigned long)buf->dma_addr, vma->vm_start,
>   buf->size);

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] HSV formats

[Laurent Pinchart]

Hi Ricardo,

I've rebased your branch on top of the latest linuxtv/master, fixed the 
documentation conflicts, and tested compilation of the documentation. You'll 
find the result at

git://linuxtv.org/pinchartl/media.git vsp1/hsv

Could you please check it and submit another pull request if everything looks 
correct to you ?

On Wednesday 05 Oct 2016 17:40:14 Laurent Pinchart wrote:
> Hi Mauro,
> 
> I don't see the patches below in your tree. Is there a specific reason why
> this pull request hasn't been processed, or did it just fall through the
> cracks ?
> 
> On Wednesday 07 Sep 2016 10:44:09 Ricardo Ribalda Delgado wrote:
> > Hi Mauro,
> > 
> > 
> > These patches add support for HSV.
> > 
> > HSV formats are extremely useful for image segmentation. This set of
> > patches makes v4l2 aware of this kind of formats.
> > 
> > Vivid changes have been divided to ease the reviewing process.
> > 
> > We are working on patches for Gstreamer and OpenCV that will make use
> > of these formats.
> > 
> > This pull request contains [PATCH v5 00/12] Add HSV format, plus the
> > following chanes:
> > 
> > -It has been rebased to media/master
> > -Laurent patch to add support for vsp1
> > -Hans Ack-by
> > -Documentation now make use of tabularcolumn (latex)
> > 
> > This is my first pull request :)
> > 
> > Please pull
> > 
> > The following changes since commit 
036bbb8213ecca49799217f30497dc0484178e53:
> >   [media] cobalt: update EDID (2016-09-06 16:46:39 -0300)
> > 
> > are available in the git repository at:
> >   https://github.com/ribalda/linux.git vivid-hsv-v6
> > 
> > for you to fetch changes up to 1242d7e43b9053cd649ac5ec81aad8597e88ab46:
> >   [media] vsp1: Add support for capture and output in HSV formats
> > 
> > (2016-09-07 10:41:52 +0200)
> > 
> > 
> > 
> > Laurent Pinchart (1):
> >   [media] vsp1: Add support for capture and output in HSV formats
> > 
> > Ricardo Ribalda Delgado (12):
> >   [media] videodev2.h Add HSV formats
> >   [media] Documentation: Add HSV format
> >   [media] Documentation: Add Ricardo Ribalda
> >   [media] vivid: Code refactor for color encoding
> >   [media] vivid: Add support for HSV formats
> >   [media] vivid: Rename variable
> >   [media] vivid: Introduce TPG_COLOR_ENC_LUMA
> >   [media] vivid: Fix YUV555 and YUV565 handling
> >   [media] vivid: Local optimization
> >   [media] videodev2.h Add HSV encoding
> >   [media] Documentation: Add HSV encodings
> >   [media] vivid: Add support for HSV encoding
> >  
> >  Documentation/media/uapi/v4l/hsv-formats.rst   |  19 
> >  Documentation/media/uapi/v4l/pixfmt-002.rst|  12 +-
> >  Documentation/media/uapi/v4l/pixfmt-003.rst|  14 ++-
> >  Documentation/media/uapi/v4l/pixfmt-006.rst|  43 ++-
> >  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 164 +
> >  Documentation/media/uapi/v4l/pixfmt.rst|   1 +
> >  Documentation/media/uapi/v4l/v4l2.rst  |   9 ++
> >  Documentation/media/videodev2.h.rst.exceptions |   4 +
> >  drivers/media/common/v4l2-tpg/v4l2-tpg-core.c  | 411 
> >  drivers/media/platform/vivid/vivid-core.h  |   3 +-
> >  drivers/media/platform/vivid/vivid-ctrls.c |  25 +
> >  drivers/media/platform/vivid/vivid-vid-cap.c   |  17 ++-
> >  drivers/media/platform/vivid/vivid-vid-common.c|  68 ++-
> >  drivers/media/platform/vivid/vivid-vid-out.c   |   1 +
> >  drivers/media/platform/vsp1/vsp1_pipe.c|   8 ++
> >  drivers/media/platform/vsp1/vsp1_rwpf.c|   2 +
> >  drivers/media/platform/vsp1/vsp1_video.c   |   5 +
> >  drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
> >  include/media/v4l2-tpg.h   |  24 +++-
> >  include/uapi/linux/videodev2.h |  36 +-
> >  20 files changed, 685 insertions(+), 183 deletions(-)
> >  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
> >  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst

-- 
Regards,

Laurent Pinchart

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

[PATCH 1/5] [media] v4l: vsp1: Fix module autoload for OF registration

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/media/platform/vsp1/vsp1.ko | grep alias
alias:  vsp1

After this patch:

$ modinfo drivers/media/platform/vsp1/vsp1.ko | grep alias
alias:  vsp1
alias:  of:N*T*Crenesas,vsp2C*
alias:  of:N*T*Crenesas,vsp2
alias:  of:N*T*Crenesas,vsp1C*
alias:  of:N*T*Crenesas,vsp1

Signed-off-by: Javier Martinez Canillas 
---

 drivers/media/platform/vsp1/vsp1_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 57c713a4e1df..aa237b48ad55 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -770,6 +770,7 @@ static const struct of_device_id vsp1_of_match[] = {
{ .compatible = "renesas,vsp2" },
{ },
 };
+MODULE_DEVICE_TABLE(of, vsp1_of_match);
 
 static struct platform_driver vsp1_platform_driver = {
.probe  = vsp1_probe,
-- 
2.7.4

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

[PATCH 2/5] [media] v4l: rcar-fcp: Fix module autoload for OF registration

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/media/platform/rcar-fcp.ko | grep alias
alias:  rcar-fcp

After this patch:

$ modinfo drivers/media/platform/rcar-fcp.ko | grep alias
alias:  rcar-fcp
alias:  of:N*T*Crenesas,fcpvC*
alias:  of:N*T*Crenesas,fcpv
alias:  of:N*T*Crenesas,fcpfC*
alias:  of:N*T*Crenesas,fcpf

Signed-off-by: Javier Martinez Canillas 
---

 drivers/media/platform/rcar-fcp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/rcar-fcp.c 
b/drivers/media/platform/rcar-fcp.c
index f3a3f31cdfa9..7146fc5ef168 100644
--- a/drivers/media/platform/rcar-fcp.c
+++ b/drivers/media/platform/rcar-fcp.c
@@ -169,6 +169,7 @@ static const struct of_device_id rcar_fcp_of_match[] = {
{ .compatible = "renesas,fcpv" },
{ },
 };
+MODULE_DEVICE_TABLE(of, rcar_fcp_of_match);
 
 static struct platform_driver rcar_fcp_platform_driver = {
.probe  = rcar_fcp_probe,
-- 
2.7.4

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

[PATCH 0/5] [media] Fix module autoload for media platform drivers

[Javier Martinez Canillas]

Hello Mauro,

I noticed that module autoload won't be working in a bunch of media
platform drivers because the module alias information is not filled
in the modules. This patch series contains the fixes for them.

Best regards,
Javier


Javier Martinez Canillas (5):
  [media] v4l: vsp1: Fix module autoload for OF registration
  [media] v4l: rcar-fcp: Fix module autoload for OF registration
  [media] rc: meson-ir: Fix module autoload
  [media] s5p-cec: Fix module autoload
  [media] st-cec: Fix module autoload

 drivers/media/platform/rcar-fcp.c   | 1 +
 drivers/media/platform/vsp1/vsp1_drv.c  | 1 +
 drivers/media/rc/meson-ir.c | 1 +
 drivers/staging/media/s5p-cec/s5p_cec.c | 1 +
 drivers/staging/media/st-cec/stih-cec.c | 1 +
 5 files changed, 5 insertions(+)

-- 
2.7.4

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

[PATCH 5/5] [media] st-cec: Fix module autoload

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/staging/media//st-cec/stih-cec.ko | grep alias
$

After this patch:

$ modinfo drivers/staging/media//st-cec/stih-cec.ko | grep alias
alias:  of:N*T*Cst,stih-cecC*
alias:  of:N*T*Cst,stih-cec

Signed-off-by: Javier Martinez Canillas 

---

 drivers/staging/media/st-cec/stih-cec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/st-cec/stih-cec.c 
b/drivers/staging/media/st-cec/stih-cec.c
index 214344866a6b..19d3ff30c8f8 100644
--- a/drivers/staging/media/st-cec/stih-cec.c
+++ b/drivers/staging/media/st-cec/stih-cec.c
@@ -363,6 +363,7 @@ static const struct of_device_id stih_cec_match[] = {
},
{},
 };
+MODULE_DEVICE_TABLE(of, stih_cec_match);
 
 static struct platform_driver stih_cec_pdrv = {
.probe  = stih_cec_probe,
-- 
2.7.4

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

[PATCH 3/5] [media] rc: meson-ir: Fix module autoload

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/media/rc/meson-ir.ko | grep alias
$

After this patch:

$ modinfo drivers/media/rc/meson-ir.ko | grep alias
alias:  of:N*T*Camlogic,meson-gxbb-irC*
alias:  of:N*T*Camlogic,meson-gxbb-ir
alias:  of:N*T*Camlogic,meson8b-irC*
alias:  of:N*T*Camlogic,meson8b-ir
alias:  of:N*T*Camlogic,meson6-irC*
alias:  of:N*T*Camlogic,meson6-ir

Signed-off-by: Javier Martinez Canillas 
---

 drivers/media/rc/meson-ir.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
index 003fff07ade2..7eb3f4f1ddcd 100644
--- a/drivers/media/rc/meson-ir.c
+++ b/drivers/media/rc/meson-ir.c
@@ -218,6 +218,7 @@ static const struct of_device_id meson_ir_match[] = {
{ .compatible = "amlogic,meson-gxbb-ir" },
{ },
 };
+MODULE_DEVICE_TABLE(of, meson_ir_match);
 
 static struct platform_driver meson_ir_driver = {
.probe  = meson_ir_probe,
-- 
2.7.4

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

[PATCH 4/5] [media] s5p-cec: Fix module autoload

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/staging/media/s5p-cec/s5p-cec.ko | grep alias
$

After this patch:

$ modinfo drivers/staging/media/s5p-cec/s5p-cec.ko | grep alias
alias:  of:N*T*Csamsung,s5p-cecC*
alias:  of:N*T*Csamsung,s5p-cec

Signed-off-by: Javier Martinez Canillas 
---

 drivers/staging/media/s5p-cec/s5p_cec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/s5p-cec/s5p_cec.c 
b/drivers/staging/media/s5p-cec/s5p_cec.c
index 1780a08b73c9..4e41f72dbfaa 100644
--- a/drivers/staging/media/s5p-cec/s5p_cec.c
+++ b/drivers/staging/media/s5p-cec/s5p_cec.c
@@ -263,6 +263,7 @@ static const struct of_device_id s5p_cec_match[] = {
},
{},
 };
+MODULE_DEVICE_TABLE(of, s5p_cec_match);
 
 static struct platform_driver s5p_cec_pdrv = {
.probe  = s5p_cec_probe,
-- 
2.7.4

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

Re: [PATCH 1/5] [media] v4l: vsp1: Fix module autoload for OF registration

[Laurent Pinchart]

Hi Javier,

Thank you for the patch.

On Monday 17 Oct 2016 12:44:08 Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
> 
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
> 
> Before this patch:
> 
> $ modinfo drivers/media/platform/vsp1/vsp1.ko | grep alias
> alias:  vsp1
> 
> After this patch:
> 
> $ modinfo drivers/media/platform/vsp1/vsp1.ko | grep alias
> alias:  vsp1
> alias:  of:N*T*Crenesas,vsp2C*
> alias:  of:N*T*Crenesas,vsp2
> alias:  of:N*T*Crenesas,vsp1C*
> alias:  of:N*T*Crenesas,vsp1
> 
> Signed-off-by: Javier Martinez Canillas 

Reviewed-by: Laurent Pinchart 

> ---
> 
>  drivers/media/platform/vsp1/vsp1_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
> b/drivers/media/platform/vsp1/vsp1_drv.c index 57c713a4e1df..aa237b48ad55
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> @@ -770,6 +770,7 @@ static const struct of_device_id vsp1_of_match[] = {
>   { .compatible = "renesas,vsp2" },
>   { },
>  };
> +MODULE_DEVICE_TABLE(of, vsp1_of_match);
> 
>  static struct platform_driver vsp1_platform_driver = {
>   .probe  = vsp1_probe,

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 2/5] [media] v4l: rcar-fcp: Fix module autoload for OF registration

[Laurent Pinchart]

Hi Javier,

Thank you for the patch.

On Monday 17 Oct 2016 12:44:09 Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
> 
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
> 
> Before this patch:
> 
> $ modinfo drivers/media/platform/rcar-fcp.ko | grep alias
> alias:  rcar-fcp
> 
> After this patch:
> 
> $ modinfo drivers/media/platform/rcar-fcp.ko | grep alias
> alias:  rcar-fcp
> alias:  of:N*T*Crenesas,fcpvC*
> alias:  of:N*T*Crenesas,fcpv
> alias:  of:N*T*Crenesas,fcpfC*
> alias:  of:N*T*Crenesas,fcpf
> 
> Signed-off-by: Javier Martinez Canillas 

Reviewed-by: Laurent Pinchart 

> ---
> 
>  drivers/media/platform/rcar-fcp.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/rcar-fcp.c
> b/drivers/media/platform/rcar-fcp.c index f3a3f31cdfa9..7146fc5ef168 100644
> --- a/drivers/media/platform/rcar-fcp.c
> +++ b/drivers/media/platform/rcar-fcp.c
> @@ -169,6 +169,7 @@ static const struct of_device_id rcar_fcp_of_match[] = {
> { .compatible = "renesas,fcpv" },
>   { },
>  };
> +MODULE_DEVICE_TABLE(of, rcar_fcp_of_match);
> 
>  static struct platform_driver rcar_fcp_platform_driver = {
>   .probe  = rcar_fcp_probe,

-- 
Regards,

Laurent Pinchart

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

Re: V4L2_DEC_CMD_STOP and last_buffer_dequeued

[李務誠]

We found videobuf2-core.h has a function
vb2_clear_last_buffer_dequeued to clear last_buffer_dequeued. We call
vb2_clear_last_buffer_dequeued in the driver when it gets CMD_START.
Everything works now.

On Mon, Oct 17, 2016 at 9:46 PM, Nicolas Dufresne  wrote:
> Le samedi 15 octobre 2016 à 08:16 +0800, Wu-Cheng Li (李務誠) a écrit :
>> last_buffer_dequeued is only cleared to false when CAPTURE queue is
>> STREAMOFF (#1). Queuing a header to OUTPUT queue won't clear
>> last_buffer_dequeued of CAPTURE queue. It looks to me that v4l2 core
>> needs to intercept CMD_START and clear last_buffer_dequeued. What do
>> you think?
We found
>>
>> http://lxr.free-electrons.com/source/drivers/media/v4l2-core/videobuf2-core.c#L1951
>
> That sounds reasonable, assuming it does not break drivers.
>
>> >
>> >
>> > Note that for many a flush is the action of getting rid of the pending
>> > images and achieve by using STREAMOFF. While the effect of CMD_STOP is
>> > to signal the decoder that no more encoded image will be queued, hence
>> > remaining images should be delivered to userspace. They will
>> > differentiate as a flush operation vs as drain operation. This is no
>> > rocket science of course.
>>
>> I see. What I want is drain operation. In Chromium terms, CMD_STOP
>> maps to flush and STREAMOFF maps to reset.
>
> Yes, that's the reason I was mentioning. This was a great source of
> confusion during a workshop with some Google/Chromium folks.
>
> A question on top of this, what are the use cases for you to drain
> without flushing afteward ? Is it really needed ?
>
> regards,
> Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] [media] rc: meson-ir: Fix module autoload

[Kevin Hilman]

On Mon, Oct 17, 2016 at 8:44 AM, Javier Martinez Canillas
 wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/media/rc/meson-ir.ko | grep alias
> $
>
> After this patch:
>
> $ modinfo drivers/media/rc/meson-ir.ko | grep alias
> alias:  of:N*T*Camlogic,meson-gxbb-irC*
> alias:  of:N*T*Camlogic,meson-gxbb-ir
> alias:  of:N*T*Camlogic,meson8b-irC*
> alias:  of:N*T*Camlogic,meson8b-ir
> alias:  of:N*T*Camlogic,meson6-irC*
> alias:  of:N*T*Camlogic,meson6-ir
>
> Signed-off-by: Javier Martinez Canillas 

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

Re: [PATCH 1/4] doc-rst: reST-directive kernel-cmd / include contentent from scripts

[Mauro Carvalho Chehab]

Hi Markus,

Em Thu,  6 Oct 2016 09:20:17 +0200
Markus Heiser  escreveu:

> From: Markus Heiser 
> 
> The ``kernel-cmd`` directive includes contend from the stdout of a
> command-line. With the ``kernel-cmd`` directive we can include the
> output of any (Perl or whatever) script. This is a more general solution
> for other workarounds like the "kernel_include + parseheaders" solution.

Unfortunately, there are some problems with kernel-cmd: it seems
that it only partially parses the ReST file, not accepting several ReST tags.

See the enclosed patch and see the produced html file at:
Documentation/output/user/MAINTAINERS.html

Then run the script manually with:
./Documentation/sphinx/format_maintainers.pl MAINTAINERS 
>Documentation/user/MAINTAINERS.rst

And see the produced html output after re-building the user book.


PS.: You can test it on my git tree, with has the code to produce
it at the lkml-books branch, at
http:://git.linuxtv.org/mchehab/experimental.git

Regards,
Mauro


[PATCH] docs-rst: user: add MAINTAINERS

including MAINTAINERS using ReST is tricky, because all
maintainer's entries are like:

FOO SUBSYSTEM:
M: My Name 
L: mailing@list
S: Maintained
F: foo/bar

On ReST, this would be displayed on a single line. Using
alias, like |M|, |L|, ... won't solve, as an alias in
Sphinx doesn't accept breaking lines.

So, instead of changing every line at MAINTAINERS, let's
use kernel-cmd extension in order to parse it via a script.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/sphinx/format_maintainers.pl 
b/Documentation/sphinx/format_maintainers.pl
new file mode 100755
index ..fb3af2a30c36
--- /dev/null
+++ b/Documentation/sphinx/format_maintainers.pl
@@ -0,0 +1,44 @@
+#!/usr/bin/perl
+
+my $is_rst = 1;
+
+# For now, ignore file tags, like F, N, X, K.
+my %tags = (
+   'P' => 'Person',
+   'M' => 'Mail',
+   'R' => 'Designated reviewer',
+   'L' => 'Mailing list',
+   'W' => 'Web page',
+   'Q' => 'Patchwork',
+   'T' => 'Develoment tree',
+   'S' => 'Status',
+);
+
+while (<>) {
+   if ($is_rst) {
+   if (m/^\s+\-+$/) {
+   $is_rst = 0;
+   next;
+   }
+   print $_;
+   next;
+   }
+
+   next if (m/^$/);
+
+   if (m/^([A-Z])\:(.*)/) {
+   my $tag = $1;
+   my $value = $2;
+
+   my $meaning;
+
+   next if (!defined($tags{$tag}));
+
+   printf " - %s:\n   %s\n\n", $tags{$tag}, $value;
+   next;
+   }
+
+   print "\n$_";
+}
+
+print "\n";
diff --git a/Documentation/user/MAINTAINERS.rst 
b/Documentation/user/MAINTAINERS.rst
new file mode 100644
index ..9b01b51749bd
--- /dev/null
+++ b/Documentation/user/MAINTAINERS.rst
@@ -0,0 +1 @@
+.. kernel-cmd:: format_maintainers.pl $srctree/MAINTAINERS
diff --git a/Documentation/user/index.rst b/Documentation/user/index.rst
index 6fbb2dc4b3b7..c4bfd45f0649 100644
--- a/Documentation/user/index.rst
+++ b/Documentation/user/index.rst
@@ -32,3 +32,4 @@ Contents:
java
bad_memory
basic_profiling
+   MAINTAINERS
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7e0064..d46ffec4e682 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,12 +1,14 @@
-
-
-   List of maintainers and how to submit kernel changes
+List of maintainers and how to submit kernel changes
+
 
 Please try to follow the guidelines below.  This will make things
 easier on the maintainers.  Not all of these guidelines matter for every
 trivial patch so apply some common sense.
 
-1. Always _test_ your changes, however small, on at least 4 or
+Tips for patch submitters
+-
+
+1. Always **test** your changes, however small, on at least 4 or
5 people, preferably many more.
 
 2. Try to release a few ALPHA test versions to the net. Announce
@@ -15,7 +17,7 @@ trivial patch so apply some common sense.
you will find things like the fact version 3 firmware needs
a magic fix you didn't know about, or some clown changed the
chips on a board and not its name.  (Don't laugh!  Look at the
-   SMC etherpower for that.)
+   SMC ``etherpower`` for that.)
 
 3. Make sure your changes compile correctly in multiple
configurations. In particular check that changes work both as a
@@ -25,7 +27,7 @@ trivial patch so apply some common sense.
testing and await feedback.
 
 5. Make a patch available to the relevant maintainer in the list. Use
-   'diff -u' to make the patch easy to merge. Be prepared to get your
+   ``diff -u`` to make the patch easy to merge. Be prepared to get your
changes sent back with seemingly silly requests about formatting
and variable names.  These aren't as silly as they seem. One
job the maintainers (and especially Linus) do is 

Re: [PATCH v2 02/31] cinergyT2-core: don't do DMA on stack

[Mauro Carvalho Chehab]

Em Sat, 15 Oct 2016 22:54:49 +0200
Johannes Stezenbach  escreveu:

> On Tue, Oct 11, 2016 at 07:09:17AM -0300, Mauro Carvalho Chehab wrote:
> > --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> > +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> > @@ -41,6 +41,8 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
> >  
> >  struct cinergyt2_state {
> > u8 rc_counter;
> > +   unsigned char data[64];
> > +   struct mutex data_mutex;
> >  };  
> 
> Sometimes my thinking is slow but it just occured to me
> that this creates a potential issue with cache line sharing.
> On an architecture which manages cache coherence in software
> (ARM, MIPS etc.) a write to e.g. rc_counter in this example
> would dirty the cache line, and a later writeback from the
> cache could overwrite parts of data[] which was received via DMA.
> In contrast, if the DMA buffer is allocated seperately via
> kmalloc it is guaranteed to be safe wrt cache line sharing.
> (see bottom of Documentation/DMA-API-HOWTO.txt).
> 

Interesting point. I'm not sure well this would work with non-fully
coherent cache lines. I guess that will depend on how the USB
driver will be handling it.

> But of course DMA on stack also had the same issue
> and no one ever noticed so it's apparently not critical...

Yes, this shouldn't do it any worse than what we currently have.
In the past, I tested some drivers that uses a shared buffed for control
URB transfers in the past, on arm32 and arm64. I don't remember seeing
anything weird there that could be related to cache coherency, although
I remember several problems with USB on OMAP and RPi version 1, leading
troubles after several minutes of ISOC transfers on analog TV,
but they seemed to be unrelated to URB control traffic.

I'd say that we should keep our eyes on those drivers, after applying
this patch series and see if people will notice bad behavior on non-x86
archs.

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

[PATCH v1] media: saa7146: Fix for "[BUG] process stuck when closing saa7146 [dvb_ttpci]"

[Andrey Utkin]

Release queued DMA buffers when ending streaming, so that
videobuf_waiton() doesn't block forever.

As reported, this fixes avoids occasional lockup of process reading from
video device, which manifests in such log:

INFO: task ffmpeg:9864 blocked for more than 120 seconds.
  Tainted: P   O4.6.7 #3
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ffmpeg  D 880177cc7b00 0  9864  1 0x
 880177cc7b00 0202 0202 8180b4c0
 88019d79e4c0 81064050 880177cc7ae0 880177cc8000
 880177cc7b18 8801fd41d648 8802307acca0 8802307acc70
Call Trace:
 [] ? preempt_count_add+0x89/0xab
 [] schedule+0x86/0x9e
 [] ? schedule+0x86/0x9e
 [] videobuf_waiton+0x131/0x15e [videobuf_core]
 [] ? wait_woken+0x6d/0x6d
 [] saa7146_dma_free+0x39/0x5b [saa7146_vv]
 [] buffer_release+0x2a/0x3e [saa7146_vv]
 [] videobuf_vm_close+0xd8/0x103 [videobuf_dma_sg]
 [] remove_vma+0x25/0x4d
 [] exit_mmap+0xce/0xf7
 [] mmput+0x4e/0xe2
 [] do_exit+0x372/0x920
 [] do_group_exit+0x3c/0x98
 [] get_signal+0x4e8/0x56e
 [] ? task_dead_fair+0xd/0xf
 [] do_signal+0x23/0x521
 [] ? _raw_spin_unlock_irqrestore+0x13/0x25
 [] ? hrtimer_try_to_cancel+0xd7/0x104
 [] ? ktime_get+0x4c/0xa1
 [] ? update_rmtp+0x46/0x5b
 [] ? hrtimer_nanosleep+0xe4/0x10e
 [] ? hrtimer_init+0xeb/0xeb
 [] exit_to_usermode_loop+0x4f/0x93
 [] syscall_return_slowpath+0x3b/0x46
 [] entry_SYSCALL_64_fastpath+0x8d/0x8f

Reported-by: Philipp Matthias Hahn 
Tested-by: Philipp Matthias Hahn 
Signed-off-by: Andrey Utkin 
---

Dear maintainers,
Please check whether the used buffer status (DONE) is correct for this
situation. I am in doubt, shouldn't it be VIDEOBUF_ERROR? However, ERROR
wasn't tested by Philipp and I guess it may indicate some undesired failure
status to application.

[PATCH v1] prefix is used to distinguish it from old letter with subj
"[PATCH] ..." which was a quick reply to Philipp's request and wasn't signed
off and otherwise properly formatted for submission.

 drivers/media/common/saa7146/saa7146_video.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/common/saa7146/saa7146_video.c 
b/drivers/media/common/saa7146/saa7146_video.c
index ea2f3bf..e034bcf 100644
--- a/drivers/media/common/saa7146/saa7146_video.c
+++ b/drivers/media/common/saa7146/saa7146_video.c
@@ -390,6 +390,7 @@ static int video_end(struct saa7146_fh *fh, struct file 
*file)
 {
struct saa7146_dev *dev = fh->dev;
struct saa7146_vv *vv = dev->vv_data;
+   struct saa7146_dmaqueue *q = &vv->video_dmaq;
struct saa7146_format *fmt = NULL;
unsigned long flags;
unsigned int resource;
@@ -428,6 +429,9 @@ static int video_end(struct saa7146_fh *fh, struct file 
*file)
/* shut down all used video dma transfers */
saa7146_write(dev, MC1, dmas);
 
+   if (q->curr)
+   saa7146_buffer_finish(dev, q, VIDEOBUF_DONE);
+
spin_unlock_irqrestore(&dev->slock, flags);
 
vv->video_fh = NULL;
-- 
2.10.1

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

Re: [PATCH 54/57] [media] platform: don't break long lines

[Andrey Utkin]

On Mon, Oct 17, 2016 at 04:45:06PM +0300, Laurent Pinchart wrote:
> If you really want to perform such a change, let's not make lines 
> unnecessarily long either. You should add a line break after the first and 
> second argument:
> 
>   dprintk(ctx->dev,
>   "%s data will not fit into plane(%lu < %lu)\n",
>   __func__, vb2_plane_size(vb, 0),
>   (long)q_data->sizeimage);
> 
> And everything will fit in 80 columns.

Same happens in other places, e.g. the hunk for
cx8802_unregister_driver() in another patch in this series, and not just
one time (looked just patches where I was a direct recipient).
There is a printing function call with previously split string literal,
followed by several arguments. This unnecessarily long function call is
now a single line.
Maybe the remaining manual work may be outsourced to seekers of janitor
tasks?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 54/57] [media] platform: don't break long lines

[Laurent Pinchart]

Hi Andrey,

On Monday 17 Oct 2016 20:39:45 Andrey Utkin wrote:
> On Mon, Oct 17, 2016 at 04:45:06PM +0300, Laurent Pinchart wrote:
> > If you really want to perform such a change, let's not make lines
> > unnecessarily long either. You should add a line break after the first and
> > 
> > second argument:
> > dprintk(ctx->dev,
> > 
> > "%s data will not fit into plane(%lu < %lu)\n",
> > __func__, vb2_plane_size(vb, 0),
> > (long)q_data->sizeimage);
> > 
> > And everything will fit in 80 columns.
> 
> Same happens in other places, e.g. the hunk for
> cx8802_unregister_driver() in another patch in this series, and not just
> one time (looked just patches where I was a direct recipient).
> There is a printing function call with previously split string literal,
> followed by several arguments. This unnecessarily long function call is
> now a single line.
> Maybe the remaining manual work may be outsourced to seekers of janitor
> tasks?

I'm fine with that, but we should rework the original patches, not merge fixes 
on top of them.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] [media] tw5864: crop picture width to 704

[Andrey Utkin]

On Thu, Sep 22, 2016 at 03:04:20AM +0300, Andrey Utkin wrote:
> Previously, width of 720 was used, but it gives 16-pixel wide black bar
> at right side of encoded picture.
> 
> Signed-off-by: Andrey Utkin 
> ---
>  drivers/media/pci/tw5864/tw5864-reg.h   |  8 
>  drivers/media/pci/tw5864/tw5864-video.c | 13 +++--
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/pci/tw5864/tw5864-reg.h 
> b/drivers/media/pci/tw5864/tw5864-reg.h
> index 92a1b07..30ac142 100644
> --- a/drivers/media/pci/tw5864/tw5864-reg.h
> +++ b/drivers/media/pci/tw5864/tw5864-reg.h
> @@ -1879,6 +1879,14 @@
>  #define TW5864_INDIR_IN_PIC_HEIGHT(channel) (0x201 + 4 * channel)
>  #define TW5864_INDIR_OUT_PIC_WIDTH(channel) (0x202 + 4 * channel)
>  #define TW5864_INDIR_OUT_PIC_HEIGHT(channel) (0x203 + 4 * channel)
> +
> +/* Some registers skipped */
> +
> +#define TW5864_INDIR_CROP_ETC 0x260
> +/* Define controls in register TW5864_INDIR_CROP_ETC */
> +/* Enable cropping from 720 to 704 */
> +#define TW5864_INDIR_CROP_ETC_CROP_EN 0x4
> +
>  /*
>   * Interrupt status register from the front-end. Write "1" to each bit to 
> clear
>   * the interrupt
> diff --git a/drivers/media/pci/tw5864/tw5864-video.c 
> b/drivers/media/pci/tw5864/tw5864-video.c
> index ff94e6c..3c8c302 100644
> --- a/drivers/media/pci/tw5864/tw5864-video.c
> +++ b/drivers/media/pci/tw5864/tw5864-video.c
> @@ -590,6 +590,15 @@ static int tw5864_enable_input(struct tw5864_input 
> *input)
>   tw_indir_writeb(TW5864_INDIR_OUT_PIC_WIDTH(nr), input->width / 4);
>   tw_indir_writeb(TW5864_INDIR_OUT_PIC_HEIGHT(nr), input->height / 4);
>  
> + /*
> +  * Crop width from 720 to 704.
> +  * Above register settings need value 720 involved.
> +  */
> + input->width = 704;
> + tw_indir_writeb(TW5864_INDIR_CROP_ETC,
> + tw_indir_readb(TW5864_INDIR_CROP_ETC) |
> + TW5864_INDIR_CROP_ETC_CROP_EN);
> +
>   tw_writel(TW5864_DSP_PIC_MAX_MB,
> ((input->width / 16) << 8) | (input->height / 16));
>  
> @@ -792,7 +801,7 @@ static int tw5864_fmt_vid_cap(struct file *file, void 
> *priv,
>  {
>   struct tw5864_input *input = video_drvdata(file);
>  
> - f->fmt.pix.width = 720;
> + f->fmt.pix.width = 704;
>   switch (input->std) {
>   default:
>   WARN_ON_ONCE(1);
> @@ -998,7 +1007,7 @@ static int tw5864_enum_framesizes(struct file *file, 
> void *priv,
>   return -EINVAL;
>  
>   fsize->type = V4L2_FRMSIZE_TYPE_DISCRETE;
> - fsize->discrete.width = 720;
> + fsize->discrete.width = 704;
>   fsize->discrete.height = input->std == STD_NTSC ? 480 : 576;
>  
>   return 0;
> -- 
> 2.9.2
> 

Mauro, Hans,
Please pick this up. This has been around for a month, I expected it
would get to v4.9-rc1 easily.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 54/57] [media] platform: don't break long lines

[Andrey Utkin]

On Mon, Oct 17, 2016 at 09:44:19PM +0300, Laurent Pinchart wrote:
> Hi Andrey,
> 
> On Monday 17 Oct 2016 20:39:45 Andrey Utkin wrote:
> > Maybe the remaining manual work may be outsourced to seekers of janitor
> > tasks?
> 
> I'm fine with that, but we should rework the original patches, not merge 
> fixes 
> on top of them.

I haven't meant that :) What I had in mind was a singular patchset with
combination of automated and manual work, just as you say, I just didn't
state it clearly.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] solo6x10: avoid delayed register write

[Andrey Utkin]

On Thu, Sep 22, 2016 at 03:03:31AM +0300, Andrey Utkin wrote:
> This fixes a lockup at device probing which happens on some solo6010
> hardware samples. This is a regression introduced by commit e1ceb25a1569
> ("[media] SOLO6x10: remove unneeded register locking and barriers")
> 
> The observed lockup happens in solo_set_motion_threshold() called from
> solo_motion_config().
> 
> This extra "flushing" is not fundamentally needed for every write, but
> apparently the code in driver assumes such behaviour at last in some
> places.
> 
> Actual fix was proposed by Hans Verkuil.
> 
> Signed-off-by: Andrey Utkin 
> ---
>  drivers/media/pci/solo6x10/solo6x10.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/media/pci/solo6x10/solo6x10.h 
> b/drivers/media/pci/solo6x10/solo6x10.h
> index 5bd4987..3f8da5e 100644
> --- a/drivers/media/pci/solo6x10/solo6x10.h
> +++ b/drivers/media/pci/solo6x10/solo6x10.h
> @@ -284,7 +284,10 @@ static inline u32 solo_reg_read(struct solo_dev 
> *solo_dev, int reg)
>  static inline void solo_reg_write(struct solo_dev *solo_dev, int reg,
> u32 data)
>  {
> + u16 val;
> +
>   writel(data, solo_dev->reg_base + reg);
> + pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val);
>  }
>  
>  static inline void solo_irq_on(struct solo_dev *dev, u32 mask)
> -- 
> 2.9.2
> 

Mauro, Hans,
Please pick this up. This has been around for a month, I expected it
would get to v4.9-rc1 easily.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] HSV formats v2

[Ricardo Ribalda Delgado]

Hi Mauro,

These is the last PULL request rebased to your last master thanks to Laurent :)


These patches add support for HSV.

HSV formats are extremely useful for image segmentation. This set of
patches makes v4l2 aware of this kind of formats.

Vivid changes have been divided to ease the reviewing process.

We are working on patches for Gstreamer and OpenCV that will make use
of these formats.

This pull request contains [PATCH v5 00/12] Add HSV format, plus the
following chanes:

-It has been rebased to media/master
-Laurent patch to add support for vsp1
-Hans Ack-by
-Documentation now make use of tabularcolumn (latex)

Please pull:

The following changes since commit 11a1e0ed7908f04c896e69d0eb65e478c12f8519:

  [media] dvb-usb: warn if return value for USB read/write routines is
not checked (2016-10-14 12:52:31 -0300)

are available in the git repository at:

  https://github.com/ribalda/linux.git vivid-hsv-v7

for you to fetch changes up to 7cb9d88402c4f674887af165e1425f1fd347583f:

  v4l: vsp1: Add support for capture and output in HSV formats
(2016-10-17 23:20:10 +0200)


Laurent Pinchart (1):
  v4l: vsp1: Add support for capture and output in HSV formats

Ricardo Ribalda Delgado (12):
  videodev2.h Add HSV formats
  Documentation: Add HSV format
  Documentation: Add Ricardo Ribalda
  vivid: Code refactor for color encoding
  vivid: Add support for HSV formats
  vivid: Rename variable
  vivid: Introduce TPG_COLOR_ENC_LUMA
  vivid: Fix YUV555 and YUV565 handling
  vivid: Local optimization
  videodev2.h Add HSV encoding
  Documentation: Add HSV encodings
  vivid: Add support for HSV encoding

 Documentation/media/uapi/v4l/hsv-formats.rst   |  19 +
 Documentation/media/uapi/v4l/pixfmt-002.rst|   5 +
 Documentation/media/uapi/v4l/pixfmt-003.rst|   5 +
 Documentation/media/uapi/v4l/pixfmt-006.rst|  31 +-
 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 157 
 Documentation/media/uapi/v4l/pixfmt.rst|   1 +
 Documentation/media/uapi/v4l/v4l2.rst  |   9 +
 Documentation/media/videodev2.h.rst.exceptions |   4 +
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c  | 411 ++---
 drivers/media/platform/vivid/vivid-core.h  |   3 +-
 drivers/media/platform/vivid/vivid-ctrls.c |  25 ++
 drivers/media/platform/vivid/vivid-vid-cap.c   |  17 +-
 drivers/media/platform/vivid/vivid-vid-common.c|  68 ++--
 drivers/media/platform/vivid/vivid-vid-out.c   |   1 +
 drivers/media/platform/vsp1/vsp1_pipe.c|   8 +
 drivers/media/platform/vsp1/vsp1_rwpf.c|   2 +
 drivers/media/platform/vsp1/vsp1_video.c   |   5 +
 drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
 include/media/v4l2-tpg.h   |  24 +-
 include/uapi/linux/videodev2.h |  36 +-
 20 files changed, 653 insertions(+), 180 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst

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

[PATCH 00/28] Reenable maybe-uninitialized warnings

[Arnd Bergmann]

This is a set of patches that I hope to get into v4.9 in some form
in order to turn on the -Wmaybe-uninitialized warnings again.

After talking to Linus in person at Linaro Connect about this, I
spent some time on finding all the remaining warnings, and this
is the resulting patch series. More details are in the description
of the last patch that actually enables the warning.

Let me know if there are other warnings that I missed, and whether
you think these are still appropriate for v4.9 or not.
A couple of patches are non-obvious, and could use some more
detailed review.

Arnd

Arnd Bergmann (28):
  [v2] netfilter: nf_tables: avoid uninitialized variable warning
  [v2] mtd: mtk: avoid warning in mtk_ecc_encode
  [v2] infiniband: shut up a maybe-uninitialized warning
  f2fs: replace a build-time warning with runtime WARN_ON
  ext2: avoid bogus -Wmaybe-uninitialized warning
  NFSv4.1: work around -Wmaybe-uninitialized warning
  ceph: avoid false positive maybe-uninitialized warning
  staging: lustre: restore initialization of return code
  staging: lustre: remove broken dead code in
cfs_cpt_table_create_pattern
  UBI: fix uninitialized access of vid_hdr pointer
  block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized
  [media] rc: print correct variable for z8f0811
  [media] dib0700: fix uninitialized data on 'repeat' event
  iio: accel: sca3000_core: avoid potentially uninitialized variable
  crypto: aesni: avoid -Wmaybe-uninitialized warning
  pcmcia: fix return value of soc_pcmcia_regulator_set
  spi: fsl-espi: avoid processing uninitalized data on error
  drm: avoid uninitialized timestamp use in wait_vblank
  brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
  net: bcm63xx: avoid referencing uninitialized variable
  net/hyperv: avoid uninitialized variable
  x86: apm: avoid uninitialized data
  x86: mark target address as output in 'insb' asm
  x86: math-emu: possible uninitialized variable use
  s390: pci: don't print uninitialized data for debugging
  nios2: fix timer initcall return value
  rocker: fix maybe-uninitialized warning
  Kbuild: bring back -Wmaybe-uninitialized warning

 Makefile   |  10 +-
 arch/arc/Makefile  |   4 +-
 arch/nios2/kernel/time.c   |   1 +
 arch/s390/pci/pci_dma.c|   2 +-
 arch/x86/crypto/aesni-intel_glue.c | 121 +
 arch/x86/include/asm/io.h  |   4 +-
 arch/x86/kernel/apm_32.c   |   5 +-
 arch/x86/math-emu/Makefile |   4 +-
 arch/x86/math-emu/reg_compare.c|  16 +--
 drivers/block/rbd.c|   1 +
 drivers/gpu/drm/drm_irq.c  |   4 +-
 drivers/infiniband/core/cma.c  |  56 +-
 drivers/media/i2c/ir-kbd-i2c.c |   2 +-
 drivers/media/usb/dvb-usb/dib0700_core.c   |  10 +-
 drivers/mtd/nand/mtk_ecc.c |  19 ++--
 drivers/mtd/ubi/eba.c  |   2 +-
 drivers/net/ethernet/broadcom/bcm63xx_enet.c   |   3 +-
 drivers/net/ethernet/rocker/rocker_ofdpa.c |   4 +-
 drivers/net/hyperv/netvsc_drv.c|   2 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c |   2 +-
 drivers/pcmcia/soc_common.c|   2 +-
 drivers/spi/spi-fsl-espi.c |   2 +-
 drivers/staging/iio/accel/sca3000_core.c   |   2 +
 .../staging/lustre/lnet/libcfs/linux/linux-cpu.c   |   7 --
 drivers/staging/lustre/lustre/lov/lov_pack.c   |   2 +
 fs/ceph/super.c|   3 +-
 fs/ext2/inode.c|   7 +-
 fs/f2fs/data.c |   7 ++
 fs/nfs/nfs4session.c   |  10 +-
 net/netfilter/nft_range.c  |  10 +-
 scripts/Makefile.ubsan |   4 +
 31 files changed, 187 insertions(+), 141 deletions(-)

-- 
Cc: x...@kernel.org
Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab 
Cc: Martin Schwidefsky 
Cc: linux-s...@vger.kernel.org
Cc: Ilya Dryomov 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-...@lists.infradead.org
Cc: Herbert Xu 
Cc: linux-cry...@vger.kernel.org
Cc: "David S. Miller" 
Cc: net...@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: ceph-de...@vger.kernel.org
Cc: linux-f2fs-de...@lists.sourceforge.net
Cc: linux-e...@vger.kernel.org
Cc: netfilter-de...@vger.kernel.org
2.9.0

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

[PATCH 12/28] [media] rc: print correct variable for z8f0811

[Arnd Bergmann]

A recent rework accidentally left a debugging printk untouched
while changing the meaning of the variables, leading to an
uninitialized variable being printed:

drivers/media/i2c/ir-kbd-i2c.c: In function 'get_key_haup_common':
drivers/media/i2c/ir-kbd-i2c.c:62:2: error: 'toggle' may be used uninitialized 
in this function [-Werror=maybe-uninitialized]

This prints the correct one instead, as we did before the patch.

Fixes: 00bb820755ed ("[media] rc: Hauppauge z8f0811 can decode RC6")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/i2c/ir-kbd-i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index f95a6bc..cede397 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -118,7 +118,7 @@ static int get_key_haup_common(struct IR_i2c *ir, enum 
rc_type *protocol,
*protocol = RC_TYPE_RC6_MCE;
dev &= 0x7f;
dprintk(1, "ir hauppauge (rc6-mce): t%d vendor=%d 
dev=%d code=%d\n",
-   toggle, vendor, dev, code);
+   *ptoggle, vendor, dev, code);
} else {
*ptoggle = 0;
*protocol = RC_TYPE_RC6_6A_32;
-- 
2.9.0

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

[PATCH 13/28] [media] dib0700: fix uninitialized data on 'repeat' event

[Arnd Bergmann]

After a recent cleanup patch, "gcc -Wmaybe-uninitialized" reports a new
warning about an existing bug:

drivers/media/usb/dvb-usb/dib0700_core.c: In function 
‘dib0700_rc_urb_completion’:
drivers/media/usb/dvb-usb/dib0700_core.c:763:2: error: ‘protocol’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]

It turns out that the "0 0 0 FF" sequence of input data has already
caused an uninitialized data use for the keycode variable, but that
was hidden with the 'uninitialized_var()' macro. Now, the protocol
is also uninitialized.

This changes the code to not report any key for this sequence, which
fixes both problems, and allows us to also remove the misleading
uninitialized_var() annotation.

It is possible that we should call rc_repeat() here, but I'm not
sure about that.

Fixes: 2ceeca0499d7 ("[media] rc: split nec protocol into its three variants")
Fixes: d3c501d1938c ("V4L/DVB: dib0700: Fix RC protocol logic to properly 
handle NEC/NECx and RC-5")
Cc: Sean Young 
Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/dvb-usb/dib0700_core.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c 
b/drivers/media/usb/dvb-usb/dib0700_core.c
index f319665..3678ebf 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -677,7 +677,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
struct dvb_usb_device *d = purb->context;
struct dib0700_rc_response *poll_reply;
enum rc_type protocol;
-   u32 uninitialized_var(keycode);
+   u32 keycode;
u8 toggle;
 
deb_info("%s()\n", __func__);
@@ -742,11 +742,10 @@ static void dib0700_rc_urb_completion(struct urb *purb)
protocol = RC_TYPE_NEC;
}
 
+   rc_keydown(d->rc_dev, protocol, keycode, toggle);
break;
default:
deb_data("RC5 protocol\n");
-   protocol = RC_TYPE_RC5;
-   toggle = poll_reply->report_id;
keycode = RC_SCANCODE_RC5(poll_reply->rc5.system, 
poll_reply->rc5.data);
 
if ((poll_reply->rc5.data ^ poll_reply->rc5.not_data) != 0xff) {
@@ -754,14 +753,13 @@ static void dib0700_rc_urb_completion(struct urb *purb)
err("key failed integrity check: %02x %02x %02x %02x",
poll_reply->rc5.not_used, poll_reply->rc5.system,
poll_reply->rc5.data, poll_reply->rc5.not_data);
-   goto resubmit;
+   break;
}
 
+   rc_keydown(d->rc_dev, RC_TYPE_RC5, keycode, 
poll_reply->report_id);
break;
}
 
-   rc_keydown(d->rc_dev, protocol, keycode, toggle);
-
 resubmit:
/* Clean the buffer before we requeue */
memset(purb->transfer_buffer, 0, RC_MSG_SIZE_V1_20);
-- 
2.9.0

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

[PATCH 28/28] Kbuild: bring back -Wmaybe-uninitialized warning

[Arnd Bergmann]

Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].

Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE.  This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.

With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.

However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that
I had not addressed until then. This caused a lot of actual bugs to
get merged into mainline, and I sent several dozen patches for these
during the v4.9 development cycle. Most of these are actual bugs,
some are for correct code that is safe because it is only called
under external constraints that make it impossible to run into
the case that gcc sees, and in a few cases gcc is just stupid and
finds something that can obviously never happen.

I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got
(I can provide the combined patch for the other warnings if anyone
is interested), so I hope we can get the warning back and let people
catch the actual bugs earlier.

Note that the majority of the patches I created are for the third kind
of problem (stupid false-positives), for one of two reasons:
- some of them only get triggered in certain combinations of config
  options, so we don't always run into them, and
- the actual bugs tend to get addressed much quicker as they also
  lead to incorrect runtime behavior.

These 27 patches address the warnings that either occur in one of the more
common configurations (defconfig, allmodconfig, or something built by the
kbuild robot or kernelci.org), or they are about a real bug. It would be
good to get these all into v4.9 if we want to turn on the warning again.
I have tested these extensively with gcc-4.9 and gcc-6 and done a bit
of testing with gcc-5, and all of these should now be fine. gcc-4.8
is much worse about the false-positive warnings and is also fairly old
now, so I'm leaving the warning disabled with that version. gcc-4.7 and
older don't understand the -Wno-maybe-uninitialized option and are not
affected by this patch either way.

I have another (smaller) series of patches for warnings that are both
harmless and not as easy to trigger, and I will send them for inclusion
in v4.10.

Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann 
---
 Makefile   | 10 ++
 arch/arc/Makefile  |  4 +++-
 scripts/Makefile.ubsan |  4 
 3 files changed, 13 insertions(+), 5 deletions(-)

Cc: x...@kernel.org
Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab 
Cc: Martin Schwidefsky 
Cc: linux-s...@vger.kernel.org
Cc: Ilya Dryomov 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-...@lists.infradead.org
Cc: Herbert Xu 
Cc: linux-cry...@vger.kernel.org
Cc: "David S. Miller" 
Cc: net...@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: ceph-de...@vger.kernel.org
Cc: linux-f2fs-de...@lists.sourceforge.net
Cc: linux-e...@vger.kernel.org
Cc: netfilter-de...@vger.kernel.org

diff --git a/Makefile b/Makefile
index 512e47a..43cd3d9 100644
--- a/Makefile
+++ b/Makefile
@@ -370,7 +370,7 @@ LDFLAGS_MODULE  =
 CFLAGS_KERNEL  =
 AFLAGS_KERNEL  =
 LDFLAGS_vmlinux =
-CFLAGS_GCOV= -fprofile-arcs -ftest-coverage -fno-tree-loop-im
+CFLAGS_GCOV= -fprofile-arcs -ftest-coverage -fno-tree-loop-im  
-Wno-maybe-uninitialized
 CFLAGS_KCOV:= $(call cc-option,-fsanitize-coverage=trace-pc,)
 
 
@@ -620,7 +620,6 @@ ARCH_CFLAGS :=
 include arch/$(SRCARCH)/Makefile
 
 KBUILD_CFLAGS  += $(call cc-option,-fno-delete-null-pointer-checks,)
-KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
 KBUILD_CFLAGS  += $(call cc-disable-warning,frame-address,)
 
 ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
@@ -629,15 +628,18 @@ KBUILD_CFLAGS += $(call cc-option,-fdata-sections,)
 endif
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS  += -Os
+KBUILD_CFLAGS  += -Os $(call cc-disabl

Re: [PATCH v4 3/8] media: adv7180: add support for NEWAVMODE

[Steve Longerbeam]

On 10/16/2016 05:18 AM, Laurent Pinchart wrote:

Hi Steve,

Thank you for the patch.

On Wednesday 03 Aug 2016 11:03:45 Steve Longerbeam wrote:

Parse the optional v4l2 endpoint DT node. If the bus type is
V4L2_MBUS_BT656 and the endpoint node specifies "newavmode",
configure the BT.656 bus in NEWAVMODE.

Signed-off-by: Steve Longerbeam 

---

v4: no changes
v3:
- the newavmode endpoint property is now private to adv7180.
---
  .../devicetree/bindings/media/i2c/adv7180.txt  |  4 ++
  drivers/media/i2c/adv7180.c| 46 +--
  2 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.txt
b/Documentation/devicetree/bindings/media/i2c/adv7180.txt index
0d50115..6c175d2 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7180.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
@@ -15,6 +15,10 @@ Required Properties :
"adi,adv7282"
"adi,adv7282-m"

+Optional Endpoint Properties :
+- newavmode: a boolean property to indicate the BT.656 bus is operating
+  in Analog Device's NEWAVMODE. Valid for BT.656 busses only.

This is a vendor-specific property, it should be prefixed with "adi,".


Ok, I'll do that in next version.


  Could
you also explain how this mode works ? I'd like to make sure it qualifies for
a DT property.


The blurb in the ADV718x manual is terse:

"When NEWAVMODE is 0 (enabled), EAV/SAV codes are generated to
suit Analog Devices encoders. No adjustments are possible."

"Setting NEWAVMODE to 1 (default) enables the manual position
of the VSYNC, FIELD, and AV codes using Register 0x32 to
Register 0x33 and Register 0xE5 to Register 0xEA. Default register
settings are CCIR656 compliant;"

So it's not clear to me how the generated EAV and SAV codes are
different from standard CCIR656, but apparently they are.

Steve





+
  Example:

i2c0@1c22000 {
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 6e093c22..467953e 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

@@ -106,6 +107,7 @@
  #define ADV7180_REG_SHAP_FILTER_CTL_1 0x0017
  #define ADV7180_REG_CTRL_20x001d
  #define ADV7180_REG_VSYNC_FIELD_CTL_1 0x0031
+#define ADV7180_VSYNC_FIELD_CTL_1_NEWAVMODE 0x02
  #define ADV7180_REG_MANUAL_WIN_CTL_1  0x003d
  #define ADV7180_REG_MANUAL_WIN_CTL_2  0x003e
  #define ADV7180_REG_MANUAL_WIN_CTL_3  0x003f
@@ -214,6 +216,7 @@ struct adv7180_state {
struct mutexmutex; /* mutual excl. when accessing chip */
int irq;
v4l2_std_id curr_norm;
+   boolnewavmode;
boolpowered;
boolstreaming;
u8  input;
@@ -864,9 +867,15 @@ static int adv7180_init(struct adv7180_state *state)
if (ret < 0)
return ret;

-   /* Manually set V bit end position in NTSC mode */
-   return adv7180_write(state, ADV7180_REG_NTSC_V_BIT_END,
-   ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
+   if (!state->newavmode) {
+   /* Manually set V bit end position in NTSC mode */
+   ret = adv7180_write(state, ADV7180_REG_NTSC_V_BIT_END,
+   ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
+   if (ret < 0)
+   return ret;
+   }
+
+   return 0;
  }

  static int adv7180_set_std(struct adv7180_state *state, unsigned int std)
@@ -1217,6 +1226,13 @@ static int init_device(struct adv7180_state *state)
if (ret)
goto out_unlock;

+   if (state->newavmode) {
+   ret = adv7180_write(state, ADV7180_REG_VSYNC_FIELD_CTL_1,
+   ADV7180_VSYNC_FIELD_CTL_1_NEWAVMODE);
+   if (ret < 0)
+   goto out_unlock;
+   }
+
ret = adv7180_program_std(state);
if (ret)
goto out_unlock;
@@ -1257,6 +1273,28 @@ out_unlock:
return ret;
  }

+static void adv7180_of_parse(struct adv7180_state *state)
+{
+   struct i2c_client *client = state->client;
+   struct device_node *np = client->dev.of_node;
+   struct device_node *endpoint;
+   struct v4l2_of_endpoint ep;
+
+   endpoint = of_graph_get_next_endpoint(np, NULL);
+   if (!endpoint) {
+   v4l_warn(client, "endpoint node not found\n");
+   return;
+   }
+
+   v4l2_of_parse_endpoint(endpoint, &ep);
+   if (ep.bus_type == V4L2_MBUS_BT656) {
+   if (of_property_read_bool(endpoint, "newavmode"))
+   state->newavmode = true;
+   }
+
+   of_node_put(endpoint);
+}
+
  static int adv7180_probe(struct i2c_client *client,
 const struct i2c_device_id

[PATCH] media: s5p-mfc include buffer size in error message

[Shuah Khan]

Include buffer size in s5p_mfc_alloc_priv_buf() the error message when it
fails to allocate the buffer. Remove the debug message that does the same.

Signed-off-by: Shuah Khan 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
index 1e72502..eee16a1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
@@ -40,12 +40,11 @@ void s5p_mfc_init_regs(struct s5p_mfc_dev *dev)
 int s5p_mfc_alloc_priv_buf(struct device *dev, dma_addr_t base,
struct s5p_mfc_priv_buf *b)
 {
-   mfc_debug(3, "Allocating priv: %zu\n", b->size);
-
b->virt = dma_alloc_coherent(dev, b->size, &b->dma, GFP_KERNEL);
 
if (!b->virt) {
-   mfc_err("Allocating private buffer failed\n");
+   mfc_err("Allocating private buffer of size %zu failed\n",
+   b->size);
return -ENOMEM;
}
 
-- 
2.7.4

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

amazing and exciting

[Xen-devel]

Hello! 
I've just heard from  a friend about  that  amazing stuff,  I'm so excited, 
you've got to take a look  
Kind regards, Xen-devel

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

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Tue Oct 18 05:00:24 CEST 2016
media-tree git hash:43ea43b9d8b27b7acd443ec59319faa3cdb8a616
media_build git hash:   ecfc9bfca3012b0c6e19967ce90f621f71a6da94
v4l-utils git hash: 79186f9d3d9d3b6bee4a611bd92435d11807
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.7.0-164

linux-git-arm-at91: ERRORS
linux-git-arm-davinci: ERRORS
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: ERRORS
linux-git-blackfin-bf561: ERRORS
linux-git-i686: OK
linux-git-m32r: WARNINGS
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: ERRORS
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
smatch: ERRORS
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH 00/28] Reenable maybe-uninitialized warnings

[Christoph Hellwig]

On Tue, Oct 18, 2016 at 12:03:28AM +0200, Arnd Bergmann wrote:
> This is a set of patches that I hope to get into v4.9 in some form
> in order to turn on the -Wmaybe-uninitialized warnings again.

Hi Arnd,

I jsut complained to Geert that I was introducing way to many
bugs or pointless warnings for some compilers lately, but gcc didn't
warn me about them.  From a little research the lack of
-Wmaybe-uninitialized seems to be the reason for it, so I'm all
for re-enabling it.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] doc-rst: reST-directive kernel-cmd / include contentent from scripts

[Jani Nikula]

On Mon, 17 Oct 2016, Mauro Carvalho Chehab  wrote:
> [PATCH] docs-rst: user: add MAINTAINERS
>
> including MAINTAINERS using ReST is tricky, because all
> maintainer's entries are like:
>
> FOO SUBSYSTEM:
> M: My Name 
> L: mailing@list
> S: Maintained
> F: foo/bar
>
> On ReST, this would be displayed on a single line. Using
> alias, like |M|, |L|, ... won't solve, as an alias in
> Sphinx doesn't accept breaking lines.
>
> So, instead of changing every line at MAINTAINERS, let's
> use kernel-cmd extension in order to parse it via a script.

Soon I'm going to stop fighting the windmills...

If you're going to insist on getting kernel-cmd upstream (and I haven't
changed my opinion on that) please at least have the sense to have just
*one* perl script to parse MAINTAINERS, not many. The one script should
be scripts/get_maintainer.pl.


BR,
Jani.

>
> Signed-off-by: Mauro Carvalho Chehab 
>
> diff --git a/Documentation/sphinx/format_maintainers.pl 
> b/Documentation/sphinx/format_maintainers.pl
> new file mode 100755
> index ..fb3af2a30c36
> --- /dev/null
> +++ b/Documentation/sphinx/format_maintainers.pl
> @@ -0,0 +1,44 @@
> +#!/usr/bin/perl
> +
> +my $is_rst = 1;
> +
> +# For now, ignore file tags, like F, N, X, K.
> +my %tags = (
> + 'P' => 'Person',
> + 'M' => 'Mail',
> + 'R' => 'Designated reviewer',
> + 'L' => 'Mailing list',
> + 'W' => 'Web page',
> + 'Q' => 'Patchwork',
> + 'T' => 'Develoment tree',
> + 'S' => 'Status',
> +);
> +
> +while (<>) {
> + if ($is_rst) {
> + if (m/^\s+\-+$/) {
> + $is_rst = 0;
> + next;
> + }
> + print $_;
> + next;
> + }
> +
> + next if (m/^$/);
> +
> + if (m/^([A-Z])\:(.*)/) {
> + my $tag = $1;
> + my $value = $2;
> +
> + my $meaning;
> +
> + next if (!defined($tags{$tag}));
> +
> + printf " - %s:\n   %s\n\n", $tags{$tag}, $value;
> + next;
> + }
> +
> + print "\n$_";
> +}
> +
> +print "\n";
> diff --git a/Documentation/user/MAINTAINERS.rst 
> b/Documentation/user/MAINTAINERS.rst
> new file mode 100644
> index ..9b01b51749bd
> --- /dev/null
> +++ b/Documentation/user/MAINTAINERS.rst
> @@ -0,0 +1 @@
> +.. kernel-cmd:: format_maintainers.pl $srctree/MAINTAINERS
> diff --git a/Documentation/user/index.rst b/Documentation/user/index.rst
> index 6fbb2dc4b3b7..c4bfd45f0649 100644
> --- a/Documentation/user/index.rst
> +++ b/Documentation/user/index.rst
> @@ -32,3 +32,4 @@ Contents:
> java
> bad_memory
> basic_profiling
> +   MAINTAINERS
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1cd38a7e0064..d46ffec4e682 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1,12 +1,14 @@
> -
> -
> - List of maintainers and how to submit kernel changes
> +List of maintainers and how to submit kernel changes
> +
>  
>  Please try to follow the guidelines below.  This will make things
>  easier on the maintainers.  Not all of these guidelines matter for every
>  trivial patch so apply some common sense.
>  
> -1.   Always _test_ your changes, however small, on at least 4 or
> +Tips for patch submitters
> +-
> +
> +1.   Always **test** your changes, however small, on at least 4 or
>   5 people, preferably many more.
>  
>  2.   Try to release a few ALPHA test versions to the net. Announce
> @@ -15,7 +17,7 @@ trivial patch so apply some common sense.
>   you will find things like the fact version 3 firmware needs
>   a magic fix you didn't know about, or some clown changed the
>   chips on a board and not its name.  (Don't laugh!  Look at the
> - SMC etherpower for that.)
> + SMC ``etherpower`` for that.)
>  
>  3.   Make sure your changes compile correctly in multiple
>   configurations. In particular check that changes work both as a
> @@ -25,7 +27,7 @@ trivial patch so apply some common sense.
>   testing and await feedback.
>  
>  5.   Make a patch available to the relevant maintainer in the list. Use
> - 'diff -u' to make the patch easy to merge. Be prepared to get your
> + ``diff -u`` to make the patch easy to merge. Be prepared to get your
>   changes sent back with seemingly silly requests about formatting
>   and variable names.  These aren't as silly as they seem. One
>   job the maintainers (and especially Linus) do is to keep things
> @@ -33,28 +35,34 @@ trivial patch so apply some common sense.
>   your driver to get around a problem actually needs to become a
>   generalized kernel feature ready for next time.
>  
> - PLEASE check your patch with the automated style checker
> - (scripts/checkpatch.pl) to catch trivial style violations.
> - See Documentation/CodingStyle for guidance here.
> + .. attention::
> +
> +   **PLEASE:**
> +
> +   - check your patch with the automate

[RESEND][PATCH] [media] atmel-isc: start dma in some scenario

[Songjun Wu]

If a new vb buf is added to vb queue, the queue is
empty and steaming, dma should be started.

Signed-off-by: Songjun Wu 
---

 drivers/media/platform/atmel/atmel-isc.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index ccfe13b..ff403d5 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -617,7 +617,14 @@ static void isc_buffer_queue(struct vb2_buffer *vb)
unsigned long flags;
 
spin_lock_irqsave(&isc->dma_queue_lock, flags);
-   list_add_tail(&buf->list, &isc->dma_queue);
+   if (!isc->cur_frm && list_empty(&isc->dma_queue) &&
+   vb2_is_streaming(vb->vb2_queue)) {
+   isc->cur_frm = buf;
+   isc_start_dma(isc->regmap, isc->cur_frm,
+   isc->current_fmt->reg_dctrl_dview);
+   } else {
+   list_add_tail(&buf->list, &isc->dma_queue);
+   }
spin_unlock_irqrestore(&isc->dma_queue_lock, flags);
 }
 
-- 
2.7.4

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

Re: [PATCH 1/4] doc-rst: reST-directive kernel-cmd / include contentent from scripts

[Markus Heiser]

Am 18.10.2016 um 08:07 schrieb Jani Nikula :

> If you're going to insist on getting kernel-cmd upstream (and I haven't
> changed my opinion on that) please at least have the sense to have just
> *one* perl script to parse MAINTAINERS, not many. The one script should
> be scripts/get_maintainer.pl.

Great minds think alike. ;-)

-- Markus --

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

Re: [PATCH 1/2] media: platform: pxa_camera: add missing sensor power on

[Robert Jarzmik]

Robert Jarzmik  writes:

> During sensors binding, there is a window where the sensor is switched
> off, while there is a call it to set a new format, which can end up in
> an access to the sensor, especially an I2C based sensor.
>
> Remove this window by activating the sensor.
Hi guys,

I can't remember if I have review issues I have to address for this serie or
not. My mailer seems to tell no, but let's check again.

This serie is adding back the "power on" of the sensors through the generic
regulator API, and is my prequisite for pxa submitted changes, which were
formerly a "hook" in soc_camera_link structure, see:
 https://www.spinics.net/lists/kernel/msg2350167.html

Cheers.

--
Robert

[1] Remaining of the patch for reference

> Signed-off-by: Robert Jarzmik 
> ---
>  drivers/media/platform/pxa_camera.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/pxa_camera.c 
> b/drivers/media/platform/pxa_camera.c
> index 2978cd6efa63..794c41d24d9f 100644
> --- a/drivers/media/platform/pxa_camera.c
> +++ b/drivers/media/platform/pxa_camera.c
> @@ -2128,17 +2128,22 @@ static int pxa_camera_sensor_bound(struct 
> v4l2_async_notifier *notifier,
>   pix->bytesperline, pix->height);
>   pix->pixelformat = pcdev->current_fmt->host_fmt->fourcc;
>   v4l2_fill_mbus_format(mf, pix, pcdev->current_fmt->code);
> - err = sensor_call(pcdev, pad, set_fmt, NULL, &format);
> +
> + err = sensor_call(pcdev, core, s_power, 1);
>   if (err)
>   goto out;
>  
> + err = sensor_call(pcdev, pad, set_fmt, NULL, &format);
> + if (err)
> + goto out_sensor_poweroff;
> +
>   v4l2_fill_pix_format(pix, mf);
>   pr_info("%s(): colorspace=0x%x pixfmt=0x%x\n",
>   __func__, pix->colorspace, pix->pixelformat);
>  
>   err = pxa_camera_init_videobuf2(pcdev);
>   if (err)
> - goto out;
> + goto out_sensor_poweroff;
>  
>   err = video_register_device(&pcdev->vdev, VFL_TYPE_GRABBER, -1);
>   if (err) {
> @@ -2149,6 +2154,9 @@ static int pxa_camera_sensor_bound(struct 
> v4l2_async_notifier *notifier,
>"PXA Camera driver attached to camera %s\n",
>subdev->name);
>   }
> +
> +out_sensor_poweroff:
> + err = sensor_call(pcdev, core, s_power, 0);
>  out:
>   mutex_unlock(&pcdev->mlock);
>   return err;

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