Re: cx88 invalid video opcodes when VBI enabled

[Daniel Glöckner]

Hi,

On Sun, Apr 15, 2018 at 01:37:50PM -0400, Devin Heitmueller wrote:
> Any suggestions on the best way to debug this without having to learn
> the intimate details of the RISC engine on the cx88?  From the state
> of the RISC engine it looks like there is some issue with queuing the
> opcodes/arguments (where in some cases arguments are interpreted as
> opcodes), but this is certainly not my area of expertise.

> [   54.427224] cx88[0]: irq vid [0x10088] vbi_risc1* vbi_risc2* opc_err*
> [   54.427232] cx88[0]/0: video risc op code error
> [   54.427238] cx88[0]: video y / packed - dma channel status dump

Since the video IRQ status register has vbi_risc2 set, which we never
generate with our RISC programs, I assume it is the VBI RISC engine
that is executing garbage. So the dump of the video y/packed RISC engine
does not help us here. Can you add a call to cx88_sram_channel_dump for
SRAM_CH24 next to the existing one in cx8800_vid_irq?

Best regards,

  Daniel

Re: [RFCv11 PATCH 25/29] media: vim2m: add media device

[Alexandre Courbot]

On Mon, Apr 9, 2018 at 11:20 PM Hans Verkuil  wrote:

> From: Alexandre Courbot 

> Request API requires a media node. Add one to the vim2m driver so we can
> use requests with it.

> This probably needs a bit more work to correctly represent m2m
> hardware in the media topology.

> Signed-off-by: Alexandre Courbot 

I don't remember writing this - actually IIRC you came with this patch
initially.

> ---
>   drivers/media/platform/vim2m.c | 43
+-
>   1 file changed, 38 insertions(+), 5 deletions(-)

> diff --git a/drivers/media/platform/vim2m.c
b/drivers/media/platform/vim2m.c
> index 065483e62db4..ef970434af13 100644
> --- a/drivers/media/platform/vim2m.c
> +++ b/drivers/media/platform/vim2m.c
> @@ -140,6 +140,10 @@ static struct vim2m_fmt *find_format(struct
v4l2_format *f)
>   struct vim2m_dev {
>  struct v4l2_device  v4l2_dev;
>  struct video_device vfd;
> +#ifdef CONFIG_MEDIA_CONTROLLER
> +   struct media_device mdev;
> +   struct media_padpad[2];
> +#endif

>  atomic_tnum_inst;
>  struct mutexdev_mutex;
> @@ -1000,11 +1004,6 @@ static int vim2m_probe(struct platform_device
*pdev)
>  return -ENOMEM;

>  spin_lock_init(>irqlock);
> -
> -   ret = v4l2_device_register(>dev, >v4l2_dev);
> -   if (ret)
> -   return ret;
> -
>  atomic_set(>num_inst, 0);
>  mutex_init(>dev_mutex);

> @@ -1013,6 +1012,22 @@ static int vim2m_probe(struct platform_device
*pdev)
>  vfd->lock = >dev_mutex;
>  vfd->v4l2_dev = >v4l2_dev;

> +#ifdef CONFIG_MEDIA_CONTROLLER
> +   dev->mdev.dev = >dev;
> +   strlcpy(dev->mdev.model, "vim2m", sizeof(dev->mdev.model));
> +   media_device_init(>mdev);
> +   dev->v4l2_dev.mdev = >mdev;
> +   dev->pad[0].flags = MEDIA_PAD_FL_SINK;
> +   dev->pad[1].flags = MEDIA_PAD_FL_SOURCE;
> +   ret = media_entity_pads_init(>entity, 2, dev->pad);
> +   if (ret)
> +   return ret;
> +#endif
> +
> +   ret = v4l2_device_register(>dev, >v4l2_dev);
> +   if (ret)
> +   goto unreg_media;
> +
>  ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0);
>  if (ret) {
>  v4l2_err(>v4l2_dev, "Failed to register video
device\n");
> @@ -1034,6 +1049,13 @@ static int vim2m_probe(struct platform_device
*pdev)
>  goto err_m2m;
>  }

> +#ifdef CONFIG_MEDIA_CONTROLLER
> +   /* Register the media device node */
> +   ret = media_device_register(>mdev);
> +   if (ret)
> +   goto err_m2m;
> +#endif
> +
>  return 0;

>   err_m2m:
> @@ -1041,6 +1063,10 @@ static int vim2m_probe(struct platform_device
*pdev)
>  video_unregister_device(>vfd);
>   unreg_dev:
>  v4l2_device_unregister(>v4l2_dev);
> +unreg_media:
> +#ifdef CONFIG_MEDIA_CONTROLLER
> +   media_device_unregister(>mdev);
> +#endif

>  return ret;
>   }
> @@ -1050,6 +1076,13 @@ static int vim2m_remove(struct platform_device
*pdev)
>  struct vim2m_dev *dev = platform_get_drvdata(pdev);

>  v4l2_info(>v4l2_dev, "Removing " MEM2MEM_NAME);
> +
> +#ifdef CONFIG_MEDIA_CONTROLLER
> +   if (media_devnode_is_registered(dev->mdev.devnode))
> +   media_device_unregister(>mdev);
> +   media_device_cleanup(>mdev);
> +#endif
> +
>  v4l2_m2m_release(dev->m2m_dev);
>  del_timer_sync(>timer);
>  video_unregister_device(>vfd);
> --
> 2.16.3

Re: [RFCv11 PATCH 27/29] vim2m: support requests

[Alexandre Courbot]

On Mon, Apr 9, 2018 at 11:20 PM Hans Verkuil  wrote:

> From: Hans Verkuil 

> Add support for requests to vim2m.

> Signed-off-by: Hans Verkuil 
> ---
>   drivers/media/platform/vim2m.c | 25 +
>   1 file changed, 25 insertions(+)

> diff --git a/drivers/media/platform/vim2m.c
b/drivers/media/platform/vim2m.c
> index 9b18b32c255d..2dcf0ea85705 100644
> --- a/drivers/media/platform/vim2m.c
> +++ b/drivers/media/platform/vim2m.c
> @@ -387,8 +387,26 @@ static void device_run(void *priv)
>  src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
>  dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);

> +   /* Apply request if needed */
> +   if (src_buf->vb2_buf.req_obj.req)
> +   v4l2_ctrl_request_setup(src_buf->vb2_buf.req_obj.req,
> +   >hdl);
> +   if (dst_buf->vb2_buf.req_obj.req &&
> +   dst_buf->vb2_buf.req_obj.req != src_buf->vb2_buf.req_obj.req)
> +   v4l2_ctrl_request_setup(dst_buf->vb2_buf.req_obj.req,
> +   >hdl);

This implies that we can have two different requests active at the same time
for the same device. Do we want to open that can of worms?

Valid scenarios for requests should be clearly defined. In the case of a
simple
buffer processor like vim2m, something like "request required for source
buffer,
optional and must be same as source if specified for destination", looks
simple
and sane.

> +
>  device_process(ctx, src_buf, dst_buf);

> +   /* Complete request if needed */
> +   if (src_buf->vb2_buf.req_obj.req)
> +   v4l2_ctrl_request_complete(src_buf->vb2_buf.req_obj.req,
> +   >hdl);
> +   if (dst_buf->vb2_buf.req_obj.req &&
> +   dst_buf->vb2_buf.req_obj.req != src_buf->vb2_buf.req_obj.req)
> +   v4l2_ctrl_request_complete(dst_buf->vb2_buf.req_obj.req,
> +   >hdl);
> +
>  /* Run a timer, which simulates a hardware irq  */
>  schedule_irq(dev, ctx->transtime);
>   }
> @@ -823,6 +841,8 @@ static void vim2m_stop_streaming(struct vb2_queue *q)
>  vbuf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
>  if (vbuf == NULL)
>  return;
> +   v4l2_ctrl_request_complete(vbuf->vb2_buf.req_obj.req,
> +  >hdl);
>  spin_lock_irqsave(>dev->irqlock, flags);
>  v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
>  spin_unlock_irqrestore(>dev->irqlock, flags);
> @@ -1003,6 +1023,10 @@ static const struct v4l2_m2m_ops m2m_ops = {
>  .job_abort  = job_abort,
>   };

> +static const struct media_device_ops m2m_media_ops = {
> +   .req_queue = vb2_request_queue,
> +};
> +
>   static int vim2m_probe(struct platform_device *pdev)
>   {
>  struct vim2m_dev *dev;
> @@ -1027,6 +1051,7 @@ static int vim2m_probe(struct platform_device *pdev)
>  dev->mdev.dev = >dev;
>  strlcpy(dev->mdev.model, "vim2m", sizeof(dev->mdev.model));
>  media_device_init(>mdev);
> +   dev->mdev.ops = _media_ops;
>  dev->v4l2_dev.mdev = >mdev;
>  dev->pad[0].flags = MEDIA_PAD_FL_SINK;
>  dev->pad[1].flags = MEDIA_PAD_FL_SOURCE;
> --
> 2.16.3

Re: [RFCv11 PATCH 20/29] videobuf2-v4l2: integrate with media requests

[Alexandre Courbot]

On Mon, Apr 9, 2018 at 11:21 PM Hans Verkuil  wrote:

> From: Hans Verkuil 

> This implements the V4L2 part of the request support. The main
> change is that vb2_qbuf and vb2_prepare_buf now have a new
> media_device pointer. This required changes to several drivers
> that did not use the vb2_ioctl_qbuf/prepare_buf helper functions.

> Signed-off-by: Hans Verkuil 
> ---
>   drivers/media/common/videobuf2/videobuf2-v4l2.c  | 84

>   drivers/media/platform/omap3isp/ispvideo.c   |  2 +-
>   drivers/media/platform/s3c-camif/camif-capture.c |  4 +-
>   drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |  4 +-
>   drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |  4 +-
>   drivers/media/platform/soc_camera/soc_camera.c   |  4 +-
>   drivers/media/usb/uvc/uvc_queue.c|  5 +-
>   drivers/media/usb/uvc/uvc_v4l2.c |  3 +-
>   drivers/media/usb/uvc/uvcvideo.h |  1 +
>   drivers/media/v4l2-core/v4l2-mem2mem.c   |  7 +-
>   drivers/staging/media/davinci_vpfe/vpfe_video.c  |  3 +-
>   drivers/staging/media/omap4iss/iss_video.c   |  3 +-
>   drivers/usb/gadget/function/uvc_queue.c  |  2 +-
>   include/media/videobuf2-v4l2.h   | 12 +++-
>   14 files changed, 106 insertions(+), 32 deletions(-)

> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index b8d370b97cca..73c1fd4da58a 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -25,6 +25,7 @@
>   #include 

>   #include 
> +#include 
>   #include 
>   #include 
>   #include 
> @@ -40,10 +41,12 @@ module_param(debug, int, 0644);
>  pr_info("vb2-v4l2: %s: " fmt, __func__, ## arg); \
>  } while (0)

> -/* Flags that are set by the vb2 core */
> +/* Flags that are set by us */
>   #define V4L2_BUFFER_MASK_FLAGS (V4L2_BUF_FLAG_MAPPED |
V4L2_BUF_FLAG_QUEUED | \
>   V4L2_BUF_FLAG_DONE | V4L2_BUF_FLAG_ERROR
| \
>   V4L2_BUF_FLAG_PREPARED | \
> +V4L2_BUF_FLAG_IN_REQUEST | \
> +V4L2_BUF_FLAG_REQUEST_FD | \
>   V4L2_BUF_FLAG_TIMESTAMP_MASK)
>   /* Output buffer flags that should be passed on to the driver */
>   #define V4L2_BUFFER_OUT_FLAGS  (V4L2_BUF_FLAG_PFRAME |
V4L2_BUF_FLAG_BFRAME | \
> @@ -318,13 +321,17 @@ static int vb2_fill_vb2_v4l2_buffer(struct
vb2_buffer *vb, struct v4l2_buffer *b
>  return 0;
>   }

> -static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct
v4l2_buffer *b,
> -   const char *opname)
> +static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct
media_device *mdev,
> +   struct v4l2_buffer *b,
> +   const char *opname,
> +   struct media_request **p_req)
>   {
> +   struct media_request *req;
>  struct vb2_v4l2_buffer *vbuf;
>  struct vb2_buffer *vb;
>  int ret;

> +   *p_req = NULL;
>  if (b->type != q->type) {
>  dprintk(1, "%s: invalid buffer type\n", opname);
>  return -EINVAL;
> @@ -354,7 +361,38 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue
*q, struct v4l2_buffer *b,

>  /* Copy relevant information provided by the userspace */
>  memset(vbuf->planes, 0, sizeof(vbuf->planes[0]) * vb->num_planes);
> -   return vb2_fill_vb2_v4l2_buffer(vb, b);
> +   ret = vb2_fill_vb2_v4l2_buffer(vb, b);
> +   if (ret)
> +   return ret;
> +
> +   if (!(b->flags & V4L2_BUF_FLAG_REQUEST_FD))
> +   return 0;
> +
> +   if (vb->state != VB2_BUF_STATE_DEQUEUED) {
> +   dprintk(1, "%s: buffer is not in dequeued state\n",
opname);
> +   return -EINVAL;
> +   }
> +
> +   if (b->request_fd < 0) {
> +   dprintk(1, "%s: request_fd < 0\n", opname);
> +   return -EINVAL;
> +   }
> +
> +   req = media_request_find(mdev, b->request_fd);
> +   if (IS_ERR(req)) {
> +   dprintk(1, "%s: invalid request_fd\n", opname);
> +   return PTR_ERR(req);
> +   }
> +
> +   if (req->state != MEDIA_REQUEST_STATE_IDLE) {
> +   dprintk(1, "%s: request is not idle\n", opname);
> +   media_request_put(req);
> +   return -EBUSY;
> +   }
> +
> +   *p_req = req;
> +
> +   return 0;
>   }

>   /*
> @@ -437,6 +475,9 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb,
void *pb)
>  case VB2_BUF_STATE_ACTIVE:
>  b->flags |= V4L2_BUF_FLAG_QUEUED;
>  break;
> +   case VB2_BUF_STATE_IN_REQUEST:
> +   b->flags |= 

Re: [RFCv11 PATCH 07/29] media-request: add media_request_object_find

[Alexandre Courbot]

On Mon, Apr 9, 2018 at 11:21 PM Hans Verkuil  wrote:

> From: Hans Verkuil 

> Add media_request_object_find to find a request object inside a
> request based on ops and/or priv values.

> Objects of the same type (vb2 buffer, control handler) will have
> the same ops value. And objects that refer to the same 'parent'
> object (e.g. the v4l2_ctrl_handler that has the current driver
> state) will have the same priv value.

> The caller has to call media_request_object_put() for the returned
> object since this function increments the refcount.

> Signed-off-by: Hans Verkuil 
> ---
>   drivers/media/media-request.c | 26 ++
>   include/media/media-request.h | 25 +
>   2 files changed, 51 insertions(+)

> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> index 02b620c81de5..415f7e31019d 100644
> --- a/drivers/media/media-request.c
> +++ b/drivers/media/media-request.c
> @@ -322,6 +322,32 @@ static void media_request_object_release(struct kref
*kref)
>  obj->ops->release(obj);
>   }

> +struct media_request_object *
> +media_request_object_find(struct media_request *req,
> + const struct media_request_object_ops *ops,
> + void *priv)
> +{
> +   struct media_request_object *obj;
> +   struct media_request_object *found = NULL;
> +   unsigned long flags;
> +
> +   if (!ops && !priv)
> +   return NULL;
> +
> +   spin_lock_irqsave(>lock, flags);
> +   list_for_each_entry(obj, >objects, list) {
> +   if ((!ops || obj->ops == ops) &&
> +   (!priv || obj->priv == priv)) {
> +   media_request_object_get(obj);
> +   found = obj;
> +   break;
> +   }
> +   }
> +   spin_unlock_irqrestore(>lock, flags);
> +   return found;
> +}
> +EXPORT_SYMBOL_GPL(media_request_object_find);
> +
>   void media_request_object_put(struct media_request_object *obj)
>   {
>  kref_put(>kref, media_request_object_release);
> diff --git a/include/media/media-request.h b/include/media/media-request.h
> index 033697d493cd..ea990c8f76bc 100644
> --- a/include/media/media-request.h
> +++ b/include/media/media-request.h
> @@ -130,6 +130,23 @@ static inline void media_request_object_get(struct
media_request_object *obj)
>*/
>   void media_request_object_put(struct media_request_object *obj);

> +/**
> + * media_request_object_find - Find an object in a request
> + *
> + * @ops: Find an object with this ops value, may be NULL.
> + * @priv: Find an object with this priv value, may be NULL.
> + *
> + * At least one of @ops and @priv must be non-NULL. If one of
> + * these is NULL, then skip checking for that field.
> + *
> + * Returns NULL if not found or the object (the refcount is increased
> + * in that case).
> + */
> +struct media_request_object *
> +media_request_object_find(struct media_request *req,
> + const struct media_request_object_ops *ops,
> + void *priv);

Mm, that signature is weird. I don't yet know how this function is going to
be
called, but wouldn't priv be enough? If we look for ops, this means we are
looking for the first object of a given class (IIUC the class/objects
mechanism
here), and I cannot see where we would want to do that.

> +
>   /**
>* media_request_object_init - Initialise a media request object
>*
> @@ -162,6 +179,14 @@ static inline void media_request_object_put(struct
media_request_object *obj)
>   {
>   }

> +static inline struct media_request_object *
> +media_request_object_find(struct media_request *req,
> + const struct media_request_object_ops *ops,
> + void *priv)
> +{
> +   return NULL;
> +}
> +
>   static inline void media_request_object_init(struct media_request_object
*obj)
>   {
>  obj->ops = NULL;
> --
> 2.16.3

RE: [PATCH v10] media: imx258: Add imx258 camera sensor driver

[Yeh, Andy]

We are re-implementing this patch. So obsolete this patch from list first.
https://patchwork.linuxtv.org/patch/48722/
Permalink   /patch/48722/
State   Obsoleted

Regards, Andy

-Original Message-
From: Yeh, Andy 
Sent: Monday, April 16, 2018 11:04 PM
To: linux-media@vger.kernel.org
Cc: sakari.ai...@linux.intel.com; Yeh, Andy ; 
tf...@chromium.org; Chen, JasonX Z ; Chiang, AlanX 

Subject: [PATCH v10] media: imx258: Add imx258 camera sensor driver

From: Jason Chen 

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

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


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

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

Re: [RFCv11 PATCH 04/29] media-request: core request support

[Alexandre Courbot]

On Mon, Apr 9, 2018 at 11:21 PM Hans Verkuil  wrote:

> From: Hans Verkuil 

> Implement the core of the media request processing.

> Drivers can bind request objects to a request. These objects
> can then be marked completed if the driver finished using them,
> or just be unbound if the results do not need to be kept (e.g.
> in the case of buffers).

> Once all objects that were added are either unbound or completed,
> the request is marked 'complete' and a POLLPRI signal is sent
> via poll.

> Both requests and request objects are refcounted.

> While a request is queued its refcount is incremented (since it
> is in use by a driver). Once it is completed the refcount is
> decremented. When the user closes the request file descriptor
> the refcount is also decremented. Once it reaches 0 all request
> objects in the request are unbound and put() and the request
> itself is freed.

> Signed-off-by: Hans Verkuil 
> ---
>   drivers/media/media-request.c | 284
+-
>   include/media/media-request.h | 156 +++
>   2 files changed, 439 insertions(+), 1 deletion(-)

> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> index ead78613fdbe..dffc290e4ada 100644
> --- a/drivers/media/media-request.c
> +++ b/drivers/media/media-request.c
> @@ -16,8 +16,290 @@
>   #include 
>   #include 

> +static const char * const request_state[] = {
> +   "idle",
> +   "queueing",
> +   "queued",
> +   "complete",
> +   "cleaning",
> +};
> +
> +static const char *
> +media_request_state_str(enum media_request_state state)
> +{
> +   if (WARN_ON(state >= ARRAY_SIZE(request_state)))
> +   return "unknown";
> +   return request_state[state];
> +}
> +
> +static void media_request_clean(struct media_request *req)
> +{
> +   struct media_request_object *obj, *obj_safe;
> +
> +   WARN_ON(req->state != MEDIA_REQUEST_STATE_CLEANING);
> +
> +   list_for_each_entry_safe(obj, obj_safe, >objects, list) {
> +   media_request_object_unbind(obj);
> +   media_request_object_put(obj);
> +   }
> +
> +   req->num_incomplete_objects = 0;
> +   wake_up_interruptible(>poll_wait);
> +}
> +
> +static void media_request_release(struct kref *kref)
> +{
> +   struct media_request *req =
> +   container_of(kref, struct media_request, kref);
> +   struct media_device *mdev = req->mdev;
> +   unsigned long flags;
> +
> +   dev_dbg(mdev->dev, "request: release %s\n", req->debug_str);
> +
> +   spin_lock_irqsave(>lock, flags);
> +   req->state = MEDIA_REQUEST_STATE_CLEANING;
> +   spin_unlock_irqrestore(>lock, flags);
> +
> +   media_request_clean(req);
> +
> +   if (mdev->ops->req_free)
> +   mdev->ops->req_free(req);
> +   else
> +   kfree(req);

Adding a third (different) opinion on this: if requests are to be embedded
into
other struct, then shouldn't we mandate an implementation for req_free
anyway?
Making it optional sounds error-prone to me.

> +}
> +
> +void media_request_put(struct media_request *req)
> +{
> +   kref_put(>kref, media_request_release);
> +}
> +EXPORT_SYMBOL_GPL(media_request_put);
> +
> +void media_request_cancel(struct media_request *req)
> +{
> +   struct media_request_object *obj, *obj_safe;
> +
> +   if (req->state != MEDIA_REQUEST_STATE_QUEUED)
> +   return;
> +
> +   list_for_each_entry_safe(obj, obj_safe, >objects, list)
> +   if (obj->ops->cancel)
> +   obj->ops->cancel(obj);
> +}
> +EXPORT_SYMBOL_GPL(media_request_cancel);
> +
> +static int media_request_close(struct inode *inode, struct file *filp)
> +{
> +   struct media_request *req = filp->private_data;
> +
> +   media_request_put(req);
> +   return 0;
> +}
> +
> +static unsigned int media_request_poll(struct file *filp,
> +  struct poll_table_struct *wait)
> +{
> +   struct media_request *req = filp->private_data;
> +   unsigned long flags;
> +   enum media_request_state state;
> +
> +   if (!(poll_requested_events(wait) & POLLPRI))
> +   return 0;
> +
> +   spin_lock_irqsave(>lock, flags);
> +   state = req->state;
> +   spin_unlock_irqrestore(>lock, flags);
> +
> +   if (state == MEDIA_REQUEST_STATE_COMPLETE)
> +   return POLLPRI;
> +   if (state == MEDIA_REQUEST_STATE_IDLE)
> +   return POLLERR;
> +
> +   poll_wait(filp, >poll_wait, wait);
> +   return 0;
> +}
> +
> +static long media_request_ioctl(struct file *filp, unsigned int cmd,
> +   unsigned long __arg)
> +{
> +   return -ENOIOCTLCMD;
> +}
> +
> +static const struct file_operations request_fops = {
> +   .owner = THIS_MODULE,
> +   .poll = media_request_poll,
> +   

Re: [RFCv11 PATCH 01/29] v4l2-device.h: always expose mdev

[Alexandre Courbot]

On Mon, Apr 9, 2018 at 11:21 PM Hans Verkuil  wrote:

> From: Hans Verkuil 

> The mdev field is only present if CONFIG_MEDIA_CONTROLLER is set.
> But since we will need to pass the media_device to vb2 snd the

Typo: s/snd/and

> control framework it is very convenient to just make this field
> available all the time. If CONFIG_MEDIA_CONTROLLER is not set,
> then it will just be NULL.

> Signed-off-by: Hans Verkuil 
> ---
>   include/media/v4l2-device.h | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)

> diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h
> index 0c9e4da55499..b330e4a08a6b 100644
> --- a/include/media/v4l2-device.h
> +++ b/include/media/v4l2-device.h
> @@ -33,7 +33,7 @@ struct v4l2_ctrl_handler;
>* struct v4l2_device - main struct to for V4L2 device drivers
>*
>* @dev: pointer to struct device.
> - * @mdev: pointer to struct media_device
> + * @mdev: pointer to struct media_device, may be NULL.
>* @subdevs: used to keep track of the registered subdevs
>* @lock: lock this struct; can be used by the driver as well
>* if this struct is embedded into a larger struct.
> @@ -58,9 +58,7 @@ struct v4l2_ctrl_handler;
>*/
>   struct v4l2_device {
>  struct device *dev;
> -#if defined(CONFIG_MEDIA_CONTROLLER)
>  struct media_device *mdev;
> -#endif
>  struct list_head subdevs;
>  spinlock_t lock;
>  char name[V4L2_DEVICE_NAME_SIZE];
> --
> 2.16.3

Re: [RFCv11 PATCH 02/29] uapi/linux/media.h: add request API

[Alexandre Courbot]

On Mon, Apr 9, 2018 at 11:20 PM Hans Verkuil  wrote:

> From: Hans Verkuil 

> Define the public request API.

> This adds the new MEDIA_IOC_REQUEST_ALLOC ioctl to allocate a request
> and two ioctls that operate on a request in order to queue the
> contents of the request to the driver and to re-initialize the
> request.

> Signed-off-by: Hans Verkuil 

Like it that the API stays simple, with request ioctls tied to request FDs.

Acked-by: Alexandre Courbot 

> ---
>   include/uapi/linux/media.h | 8 
>   1 file changed, 8 insertions(+)

> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index c7e9a5cba24e..f8769e74f847 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -342,11 +342,19 @@ struct media_v2_topology {

>   /* ioctls */

> +struct __attribute__ ((packed)) media_request_alloc {
> +   __s32 fd;
> +};
> +
>   #define MEDIA_IOC_DEVICE_INFO  _IOWR('|', 0x00, struct media_device_info)
>   #define MEDIA_IOC_ENUM_ENTITIES_IOWR('|', 0x01, struct
media_entity_desc)
>   #define MEDIA_IOC_ENUM_LINKS   _IOWR('|', 0x02, struct media_links_enum)
>   #define MEDIA_IOC_SETUP_LINK   _IOWR('|', 0x03, struct media_link_desc)
>   #define MEDIA_IOC_G_TOPOLOGY   _IOWR('|', 0x04, struct media_v2_topology)
> +#define MEDIA_IOC_REQUEST_ALLOC_IOWR('|', 0x05, struct
media_request_alloc)
> +
> +#define MEDIA_REQUEST_IOC_QUEUE_IO('|',  0x80)
> +#define MEDIA_REQUEST_IOC_REINIT   _IO('|',  0x81)

>   #if !defined(__KERNEL__) || defined(__NEED_MEDIA_LEGACY_API)

> --
> 2.16.3

Re: [RFCv11 PATCH 00/29] Request API

[Alexandre Courbot]

On Mon, Apr 9, 2018 at 11:20 PM Hans Verkuil  wrote:

> From: Hans Verkuil 

> Hi all,

> This is a cleaned up version of the v10 series (never posted to
> the list since it was messy).

Hi Hans,

It took me a while to test and review this, but finally have been able to
do it.

First the result of the test: I have tried porting my dummy vim2m test
program
(https://gist.github.com/Gnurou/34c35f1f8e278dad454b51578d239a42 for
reference),
and am getting a hang when trying to queue the second OUTPUT buffer (right
after
queuing the first request). If I move the calls the VIDIOC_STREAMON after
the
requests are queued, the hang seems to happen at that moment. Probably a
deadlock, haven't looked in detail yet.

I have a few other comments, will follow up per-patch.

Re: [RFCv11 PATCH 03/29] media-request: allocate media requests

[Alexandre Courbot]

On Mon, Apr 9, 2018 at 11:20 PM Hans Verkuil  wrote:

> From: Hans Verkuil 

> Add support for allocating a new request. This is only supported
> if mdev->ops->req_queue is set, i.e. the driver indicates that it
> supports queueing requests.

> Signed-off-by: Hans Verkuil 
> ---
>   drivers/media/Makefile|  3 ++-
>   drivers/media/media-device.c  | 14 ++
>   drivers/media/media-request.c | 23 +++
>   include/media/media-device.h  | 13 +
>   include/media/media-request.h | 22 ++
>   5 files changed, 74 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/media/media-request.c
>   create mode 100644 include/media/media-request.h

> diff --git a/drivers/media/Makefile b/drivers/media/Makefile
> index 594b462ddf0e..985d35ec6b29 100644
> --- a/drivers/media/Makefile
> +++ b/drivers/media/Makefile
> @@ -3,7 +3,8 @@
>   # Makefile for the kernel multimedia device drivers.
>   #

> -media-objs := media-device.o media-devnode.o media-entity.o
> +media-objs := media-device.o media-devnode.o media-entity.o \
> +  media-request.o

>   #
>   # I2C drivers should come before other drivers, otherwise they'll fail
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 35e81f7c0d2f..acb583c0eacd 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -32,6 +32,7 @@
>   #include 
>   #include 
>   #include 
> +#include 

>   #ifdef CONFIG_MEDIA_CONTROLLER

> @@ -366,6 +367,15 @@ static long media_device_get_topology(struct
media_device *mdev,
>  return ret;
>   }

> +static long media_device_request_alloc(struct media_device *mdev,
> +  struct media_request_alloc *alloc)
> +{
> +   if (!mdev->ops || !mdev->ops->req_queue)
> +   return -ENOTTY;
> +
> +   return media_request_alloc(mdev, alloc);
> +}
> +
>   static long copy_arg_from_user(void *karg, void __user *uarg, unsigned
int cmd)
>   {
>  /* All media IOCTLs are _IOWR() */
> @@ -414,6 +424,7 @@ static const struct media_ioctl_info ioctl_info[] = {
>  MEDIA_IOC(ENUM_LINKS, media_device_enum_links,
MEDIA_IOC_FL_GRAPH_MUTEX),
>  MEDIA_IOC(SETUP_LINK, media_device_setup_link,
MEDIA_IOC_FL_GRAPH_MUTEX),
>  MEDIA_IOC(G_TOPOLOGY, media_device_get_topology,
MEDIA_IOC_FL_GRAPH_MUTEX),
> +   MEDIA_IOC(REQUEST_ALLOC, media_device_request_alloc, 0),
>   };

>   static long media_device_ioctl(struct file *filp, unsigned int cmd,
> @@ -686,6 +697,9 @@ void media_device_init(struct media_device *mdev)
>  INIT_LIST_HEAD(>pads);
>  INIT_LIST_HEAD(>links);
>  INIT_LIST_HEAD(>entity_notify);
> +
> +   spin_lock_init(>req_lock);
> +   mutex_init(>req_queue_mutex);
>  mutex_init(>graph_mutex);
>  ida_init(>entity_internal_idx);

> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> new file mode 100644
> index ..ead78613fdbe
> --- /dev/null
> +++ b/drivers/media/media-request.c
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Media device request objects
> + *
> + * Copyright (C) 2018 Intel Corporation
> + * Copyright (C) 2018, The Chromium OS Authors.  All rights reserved.

Seconding Tomasz' comment - Chromium authorship should be something like

Copyright (C) 2018 Google, Inc.

(see
https://www.chromium.org/chromium-os/how-tos-and-troubleshooting/kernel-faq#TOC-Which-copyright-header-should-I-use-
)

Sorry since I think I am the one who introduced this line in my early
patches.

> + *
> + * Author: Sakari Ailus 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +int media_request_alloc(struct media_device *mdev,
> +   struct media_request_alloc *alloc)
> +{
> +   return -ENOMEM;

Probably not the best error code for now? And this function can probably be
declared later (i.e. along with its full definition) in the series anyway.

> +}
> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index bcc6ec434f1f..07e323c57202 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -19,6 +19,7 @@
>   #ifndef _MEDIA_DEVICE_H
>   #define _MEDIA_DEVICE_H

> +#include 
>   #include 
>   #include 

> @@ -27,6 +28,7 @@

>   struct ida;
>   struct device;
> +struct media_device;

>   /**
>* struct media_entity_notify - Media Entity Notify
> @@ -50,10 +52,16 @@ struct media_entity_notify {
>* struct media_device_ops - Media device operations
>* @link_notify: Link state change notification callback. This callback
is
>*  called with the graph_mutex held.
> + * @req_alloc: Allocate a request
> + * @req_free: Free a request
> + * @req_queue: Queue a request
>*/
>   struct media_device_ops {
>

Re: [PATCH] media: rc: mtk-cir: use of_device_get_match_data()

[Sean Wang]

On Mon, 2018-04-16 at 10:34 +0800, Ryder Lee wrote:
> The usage of of_device_get_match_data() reduce the code size a bit.
> 
> Signed-off-by: Ryder Lee 
> ---
>  drivers/media/rc/mtk-cir.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
> index e88eb64..e42efd9 100644
> --- a/drivers/media/rc/mtk-cir.c
> +++ b/drivers/media/rc/mtk-cir.c
> @@ -299,8 +299,6 @@ static int mtk_ir_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
>   struct device_node *dn = dev->of_node;
> - const struct of_device_id *of_id =
> - of_match_device(mtk_ir_match, >dev);
>   struct resource *res;
>   struct mtk_ir *ir;
>   u32 val;
> @@ -312,7 +310,7 @@ static int mtk_ir_probe(struct platform_device *pdev)
>   return -ENOMEM;
>  
>   ir->dev = dev;
> - ir->data = of_id->data;
> + ir->data = of_device_get_match_data(dev);
>  
>   ir->clk = devm_clk_get(dev, "clk");
>   if (IS_ERR(ir->clk)) {


Acked-by: Sean Wang 

cron job: media_tree daily build: OK

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Tue Apr 17 05:00:16 CEST 2018
media-tree git hash:60cc43fc888428bb2f18f08997432d426a243338
media_build git hash:   78d6ded165a133942a9615a80ca8e0d48749c592
v4l-utils git hash: 47d43b130dc6e9e0edc900759fb37649208371e4
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: 0.5.2-RC1
smatch version: 0.5.1
host hardware:  x86_64
host os:4.14.0-3-amd64

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

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

Re: [PATCH v13 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Niklas Söderlund]

Hi Jacopo,

On 2018-04-16 01:16:35 +0200, Niklas Söderlund wrote:

[snip]

> > > +
> > > + /* Set frequency range if we have it */
> > > + if (priv->info->csi0clkfreqrange)
> > > + rcar_csi2_write(priv, CSI0CLKFCPR_REG,
> > > + CSI0CLKFREQRANGE(priv->info->csi0clkfreqrange));
> > > +
> > > + rcar_csi2_write(priv, PHYCNT_REG, phycnt);
> > > + rcar_csi2_write(priv, LINKCNT_REG, LINKCNT_MONITOR_EN |
> > > + LINKCNT_REG_MONI_PACT_EN | LINKCNT_ICLK_NONSTOP);
> > > + rcar_csi2_write(priv, PHYCNT_REG, phycnt | PHYCNT_SHUTDOWNZ);
> > > + rcar_csi2_write(priv, PHYCNT_REG, phycnt | PHYCNT_SHUTDOWNZ |
> > > + PHYCNT_RSTZ);
> > 
> > Nit: from tables 25.[17-20] it seems to me you do not have to re-issue
> > PHYCNT_SHUTDOWNZ when writing PHYCNT_RSTZ to PHYCNT_REG.
> 
> You are correct, I miss read ' Here, the ENABLE_0 to ENABLE_3 and
> ENABLECLK values set above should be retained' as all previous PHYCNT 
> bits should be retained not just the ones explicitly listed. I will give 
> this a test and if it still works I will remove it for the next version.

This change breaks capture and LP-11 is never detected. So I will 
continue to retain the PHYCNT_SHUTDOWNZ here.

-- 
Regards,
Niklas Söderlund

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

[Samuel Bobrowicz]

I've been digging around the ov5640.c code for a few weeks now, these
look like some solid improvements. I'll give them a shot and let you
know how they work.

On that note, I'm bringing up a module that uses dual lane MIPI with a
12MHz fixed oscillator for xclk (Digilent's Pcam 5c). The mainline
version of the driver seems to only support xclk of 22MHz (or maybe
24MHz), despite allowing xclk values from 6-24MHz. Will any of these
patches add support for a 12MHz xclk while in MIPI mode?

Sam
---
Sam Bobrowicz
Elite Embedded Consulting LLC
elite-embedded.com


On Mon, Apr 16, 2018 at 5:36 AM, Maxime Ripard
 wrote:
> Hi,
>
> Here is a "small" series that mostly cleans up the ov5640 driver code,
> slowly getting rid of the big data array for more understandable code
> (hopefully).
>
> The biggest addition would be the clock rate computation at runtime,
> instead of relying on those arrays to setup the clock tree
> properly. As a side effect, it fixes the framerate that was off by
> around 10% on the smaller resolutions, and we now support 60fps.
>
> This also introduces a bunch of new features.
>
> Let me know what you think,
> Maxime
>
> Changes from v1:
>   - Integrated Hugues' suggestions to fix v4l2-compliance
>   - Fixed the bus width with JPEG
>   - Dropped the clock rate calculation loops for something simpler as
> suggested by Sakari
>   - Cache the exposure value instead of using the control value
>   - Rebased on top of 4.17
>
> Maxime Ripard (10):
>   media: ov5640: Don't force the auto exposure state at start time
>   media: ov5640: Init properly the SCLK dividers
>   media: ov5640: Change horizontal and vertical resolutions name
>   media: ov5640: Add horizontal and vertical totals
>   media: ov5640: Program the visible resolution
>   media: ov5640: Adjust the clock based on the expected rate
>   media: ov5640: Compute the clock rate at runtime
>   media: ov5640: Enhance FPS handling
>   media: ov5640: Add 60 fps support
>   media: ov5640: Remove duplicate auto-exposure setup
>
> Mylène Josserand (2):
>   media: ov5640: Add auto-focus feature
>   media: ov5640: Add light frequency control
>
>  drivers/media/i2c/ov5640.c | 752 +
>  1 file changed, 422 insertions(+), 330 deletions(-)
>
> --
> 2.17.0
>

Re: OV5640 with 12MHz xclk

[Samuel Bobrowicz]

Thanks all, that's what I was expecting. It clears some things up.

I'm going to check out Maxime's recent patches and see if those do the
trick, otherwise I'll get cracking on some patches myself.

Sam
---
Sam Bobrowicz
Elite Embedded Consulting LLC
elite-embedded.com


On Mon, Apr 16, 2018 at 11:44 AM, Steve Longerbeam
 wrote:
> Hi Sam,
>
> On 04/16/2018 05:26 AM, Hans Verkuil wrote:
>>
>> On 04/16/2018 03:39 AM, Samuel Bobrowicz wrote:
>>>
>>> Can anyone verify if the OV5640 driver works with input clocks other
>>> than the typical 24MHz? The driver suggests anything from 6MHz-24MHz
>>> is acceptable, but I am running into issues while bringing up a module
>>> that uses a 12MHz oscillator. I'd expect that different xclk's would
>>> necessitate different register settings for the various resolutions
>>> (PLL settings, PCLK width, etc.), however the driver does not seem to
>>> modify nearly enough based on the frequency of xclk.
>>>
>>> Sam
>>>
>> I'm pretty sure it has never been tested with 12 MHz. The i.MX SabreLite
>> seems to use 22 MHz, and I can't tell from the code what the SabreSD uses
>> (probably 22 or 24 MHz). Steve will probably know.
>
>
> On i.MX6, the sabrelite uses the PWM3 clock at 22MHz for the OV5640 xclk.
> The SabreSD uses the i.MX6 CKO clock, which is default sourced from the
> 24 MHz oscillator.
>
> I wouldn't be surprised that there are issues with a 12MHz xclk in the
> ov5640 driver. There's probably some assumptions made about the
> xclk range in the hardcoded values in those huge register tables. Sorry
> I don't have the time to look into it more.
>
> Steve
>

Re: [PATCH v2 06/10] media: dt-bindings: ov772x: add device tree binding

[Rob Herring]

On Mon, Apr 16, 2018 at 11:51:47AM +0900, Akinobu Mita wrote:
> This adds a device tree binding documentation for OV7720/OV7725 sensor.
> 
> Cc: Jacopo Mondi 
> Cc: Laurent Pinchart 
> Cc: Hans Verkuil 
> Cc: Sakari Ailus 
> Cc: Mauro Carvalho Chehab 
> Cc: Rob Herring 
> Signed-off-by: Akinobu Mita 
> ---
> * v2
> - Add "dt-bindings:" in the subject
> - Add a brief description of the sensor
> - Update the GPIO names
> - Indicate the GPIO active level
> 
>  .../devicetree/bindings/media/i2c/ov772x.txt   | 42 
> ++
>  MAINTAINERS|  1 +
>  2 files changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov772x.txt

Reviewed-by: Rob Herring 

Proposal

[MS Zeliha Omer Faruk]

Hello

Greeetings to you please did you get my previous email regarding my
investment proposal last week friday ?

MS.Zeliha ömer faruk
zeliha.omer.fa...@gmail.com

Re: [PATCH] media: v4l2-compat-ioctl32: better name userspace pointers

[Sakari Ailus]

On Mon, Apr 16, 2018 at 06:00:12PM +0200, Hans Verkuil wrote:
> On 04/16/2018 05:11 PM, Mauro Carvalho Chehab wrote:
> > In the past, "up" were an acronym for "user pointer" and "kp" for
> > "kernel pointer". However, since a1dfb4c48cc1 ("media:
> > v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"), both
> > are now __user pointers.
> > 
> > So, the usage of "kp" is really misleading there. So, rename
> > both to just "p32" and "p64" everywhere it occurs, in order to
> > make peace with this file's namespace.
> > 
> > There are two exceptions to "up/kp" nomenclature: at
> > alloc_userspace() and at do_video_ioctl().
> > 
> > There, a new userspace pointer were allocated, in order to store
> > the 64 bits version of the ioctl. Those were called as "up_native",
> > with is, IMHO, an even worse name, as "native" could mislead of
> > being the arguments that were filled from userspace. I almost
> > renamed it to just "p64", but, after thinking more about that,
> > it sounded better to call it as "new_p64", as this makes clearer
> > that this is the data structure that was allocated inside this
> > file in order to be used to pass/retrieve data when calling the
> > 64-bit ready file->f_op->unlocked_ioctl() function.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 578 
> > +-
> >  1 file changed, 289 insertions(+), 289 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> > b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > index 5c3408bdfd89..064e4a2bdba3 100644
> > --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> 
> 
> 
> > @@ -392,31 +392,31 @@ struct v4l2_buffer32 {
> > __u32   reserved;
> >  };
> >  
> > -static int get_v4l2_plane32(struct v4l2_plane __user *up,
> > +static int get_v4l2_plane32(struct v4l2_plane __user *p32,
> > struct v4l2_plane32 __user *up32,
> 
> This is confusing: there is now a p32 and a up32 pointer. In all
> fairness, this was already confusing. In this specific case 'up' should
> be 'p64' and 'up32' should be 'p32'.
> 
> > enum v4l2_memory memory)
> >  {
> > compat_ulong_t p;
> >  
> > -   if (copy_in_user(up, up32, 2 * sizeof(__u32)) ||
> > -   copy_in_user(>data_offset, >data_offset,
> > -sizeof(up->data_offset)))
> > +   if (copy_in_user(p32, up32, 2 * sizeof(__u32)) ||
> > +   copy_in_user(>data_offset, >data_offset,
> > +sizeof(p32->data_offset)))
> > return -EFAULT;
> >  
> > switch (memory) {
> > case V4L2_MEMORY_MMAP:
> > case V4L2_MEMORY_OVERLAY:
> > -   if (copy_in_user(>m.mem_offset, >m.mem_offset,
> > +   if (copy_in_user(>m.mem_offset, >m.mem_offset,
> >  sizeof(up32->m.mem_offset)))
> > return -EFAULT;
> > break;
> > case V4L2_MEMORY_USERPTR:
> > if (get_user(p, >m.userptr) ||
> > -   put_user((unsigned long)compat_ptr(p), >m.userptr))
> > +   put_user((unsigned long)compat_ptr(p), >m.userptr))
> > return -EFAULT;
> > break;
> > case V4L2_MEMORY_DMABUF:
> > -   if (copy_in_user(>m.fd, >m.fd, sizeof(up32->m.fd)))
> > +   if (copy_in_user(>m.fd, >m.fd, sizeof(up32->m.fd)))
> > return -EFAULT;
> > break;
> > }
> > @@ -424,32 +424,32 @@ static int get_v4l2_plane32(struct v4l2_plane __user 
> > *up,
> > return 0;
> >  }
> >  
> > -static int put_v4l2_plane32(struct v4l2_plane __user *up,
> > +static int put_v4l2_plane32(struct v4l2_plane __user *p32,
> > struct v4l2_plane32 __user *up32,
> > enum v4l2_memory memory)
> 
> Same here. up -> p64 and up32 -> p32.
> 
> >  {
> > unsigned long p;
> >  
> > -   if (copy_in_user(up32, up, 2 * sizeof(__u32)) ||
> > -   copy_in_user(>data_offset, >data_offset,
> > -sizeof(up->data_offset)))
> > +   if (copy_in_user(up32, p32, 2 * sizeof(__u32)) ||
> > +   copy_in_user(>data_offset, >data_offset,
> > +sizeof(p32->data_offset)))
> > return -EFAULT;
> >  
> > switch (memory) {
> > case V4L2_MEMORY_MMAP:
> > case V4L2_MEMORY_OVERLAY:
> > -   if (copy_in_user(>m.mem_offset, >m.mem_offset,
> > -sizeof(up->m.mem_offset)))
> > +   if (copy_in_user(>m.mem_offset, >m.mem_offset,
> > +sizeof(p32->m.mem_offset)))
> > return -EFAULT;
> > break;
> > case V4L2_MEMORY_USERPTR:
> > -   if (get_user(p, >m.userptr)||
> > +   if (get_user(p, >m.userptr)||
> > put_user((compat_ulong_t)ptr_to_compat((void __user *)p),
> >  

Re: [PATCHv2 4/9] media: add function field to struct media_entity_desc

[Hans Verkuil]

On 04/16/2018 09:40 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 16 Apr 2018 21:27:01 +0200
> Hans Verkuil  escreveu:
> 
>> On 04/16/2018 08:01 PM, Mauro Carvalho Chehab wrote:
>>> Em Mon, 16 Apr 2018 15:21:16 +0200
>>> Hans Verkuil  escreveu:
>>>   
 From: Hans Verkuil 

 This adds support for 'proper' functions to the existing API.
 This information was before only available through the new v2
 API, with this change it's available to both.

 Yes, the plan is to allow entities to expose multiple functions for
 multi-function devices, but we do not support it anywhere so this
 is still vaporware.  
>>>
>>> I'm not convinced about that. I would, instead, just keep it as-is
>>> and be sure that applications stop use the legacy calls.  
>>
>> You can't. First of all, since the new API does not provide the pad index
>> (fixed in patch 6/9) it is impossible to use the new API with any driver
>> that supports SETUP_LINK.
> 
> Yeah, unfortunately, the properties API was just an empty promise.
> 
> Anyway, as you said, patch 6/9 solves it.
> 
>> So any such driver that uses any of the newer
>> subdevs with a function that is mapped to MEDIA_ENT_T_DEVNODE_UNKNOWN
>> is currently not reporting that correctly. A good example is the
>> imx driver. But also others if they are combined with such newer subdevs.
> 
> As far as I remember, other drivers also return MEDIA_ENT_F_UNKNOWN
> (with also maps to MEDIA_ENT_T_DEVNODE_UNKNOWN) even via the new API, 
> as the developer never cared to fill the entity function, even 
> producing warnings.
> 
>> There is nothing wrong with the old API, except for not reporting the
>> proper function value in field 'type' due to historical concerns.
> 
> There is. That's why we took about one year developing a new API.

If you don't need the new functionality (like interfaces), then it is
perfectly fine. It's been in use for many years now.

> 
>> There is NO WAY we can suddenly prohibit applications from using the old
>> API since the new API was never usable. And besides that, we have no method
>> of knowing who uses the old API since such applications are likely custom
>> for specific hardware.
> 
> Nobody is forbidding anything. We're just freezing it, as its
> functionality was superseded.
> 
>> All that is really missing in the 'old' API (I hate the terms 'old' and
>> 'new', they are misleading) is a proper 'function' field. Let's just add it
>> and make it consistent with the documentation about entity functions.
> 
> It misses interfaces - with is needed to identify what interface controls
> what.

Sure, but for most use cases interfaces are not needed. But reporting the 
correct
function is very useful, makes the API consistent with the documentation (which
only talks about functions and no longer refers to types) and the new API and it
is trivial to add.

I'm not advocating any further chances, but while writing the compliance tests
for this it was incredibly ugly to have this mismatch between 'type' and 
'function'.

The function of an entity is a critical piece of information, and having it
clamped to UNKNOWN for the newer functions is just wrong.

Regards,

Hans

> 
>>
>>>   

 Signed-off-by: Hans Verkuil 
 ---
  drivers/media/media-device.c | 1 +
  include/uapi/linux/media.h   | 7 ++-
  2 files changed, 7 insertions(+), 1 deletion(-)

 diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
 index 7c3ab37c258a..dca1e5a3e0f9 100644
 --- a/drivers/media/media-device.c
 +++ b/drivers/media/media-device.c
 @@ -115,6 +115,7 @@ static long media_device_enum_entities(struct 
 media_device *mdev,
if (ent->name)
strlcpy(entd->name, ent->name, sizeof(entd->name));
entd->type = ent->function;
 +  entd->function = ent->function;
entd->revision = 0; /* Unused */  
>>>
>>> I got confused here, until I went to the code and noticed that
>>> entd->type is actually touched after this.
>>>
>>> If we're willing to do that, you should add a comment there explaining
>>> why we need to pass both type and function to userspace.  
>>
>> True.
>>
>> Regards,
>>
>>  Hans
>>
>>>   
entd->flags = ent->flags;
entd->group_id = 0; /* Unused */
 diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
 index 86c7dcc9cba3..ac08acffdb65 100644
 --- a/include/uapi/linux/media.h
 +++ b/include/uapi/linux/media.h
 @@ -146,6 +146,10 @@ struct media_device_info {
  /* OR with the entity id value to find the next entity */
  #define MEDIA_ENT_ID_FLAG_NEXT(1 << 31)
  
 +/* Appeared in 4.18.0 */
 +#define MEDIA_ENTITY_DESC_HAS_FUNCTION(media_version) \
 +  ((media_version) >= 0x00041200)
 +
  struct media_entity_desc {
__u32 id;
char 

Re: [PATCHv2 6/9] media: add 'index' to struct media_v2_pad

[Hans Verkuil]

On 04/16/2018 08:09 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 16 Apr 2018 15:03:35 -0300
> Mauro Carvalho Chehab  escreveu:
> 
>> Em Mon, 16 Apr 2018 15:21:18 +0200
>> Hans Verkuil  escreveu:
>>
>>> From: Hans Verkuil 
>>>
>>> The v2 pad structure never exposed the pad index, which made it impossible
>>> to call the MEDIA_IOC_SETUP_LINK ioctl, which needs that information.
>>>
>>> It is really trivial to just expose this information, so implement this.  
>>
>> Acked-by: Mauro Carvalho Chehab 
> 
> Err... I looked on it too fast... See my comments below.
> 
> The same applies to patch 8/9.
> 
>>>
>>> Signed-off-by: Hans Verkuil 
>>> ---
>>>  drivers/media/media-device.c | 1 +
>>>  include/uapi/linux/media.h   | 7 ++-
>>>  2 files changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
>>> index dca1e5a3e0f9..73ffea3e81c9 100644
>>> --- a/drivers/media/media-device.c
>>> +++ b/drivers/media/media-device.c
>>> @@ -331,6 +331,7 @@ static long media_device_get_topology(struct 
>>> media_device *mdev,
>>> kpad.id = pad->graph_obj.id;
>>> kpad.entity_id = pad->entity->graph_obj.id;
>>> kpad.flags = pad->flags;
>>> +   kpad.index = pad->index;
>>>  
>>> if (copy_to_user(upad, , sizeof(kpad)))
>>> ret = -EFAULT;
>>> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
>>> index ac08acffdb65..15f7f432f808 100644
>>> --- a/include/uapi/linux/media.h
>>> +++ b/include/uapi/linux/media.h
>>> @@ -310,11 +310,16 @@ struct media_v2_interface {
>>> };
>>>  } __attribute__ ((packed));
>>>  
>>> +/* Appeared in 4.18.0 */
>>> +#define MEDIA_V2_PAD_HAS_INDEX(media_version) \
>>> +   ((media_version) >= 0x00041200)
>>> +
> 
> I don't like this, for a couple of reasons:
> 
> 1) it has a magic number on it, with is actually a parsed
>version of LINUX_VERSION() macro;

I can/should change that to KERNEL_VERSION().

> 
> 2) it sounds really weird to ship a header file with a new
>kernel version meant to provide backward compatibility with
>older versions;
> 
> 3) this isn't any different than:
> 
>   #define MEDIA_V2_PAD_HAS_INDEX -1
> 
> I think we need to think a little bit more about that.

What typically happens is that applications (like those in v4l-utils
for example) copy the headers locally. So they are compiled with the headers
of a specific kernel version, but they can run with very different kernels.

This is normal for distros where you can install different kernel versions
without needing to modify applications.

In fact, we (Cisco) use the latest v4l-utils code on kernels ranging between
2.6.39 to 4.10 (I think that's the latest one in use).

The media version tells you whether or not the kernel supports this feature.
I don't see another way of doing this.

In most other cases we can just say that if the field value is 0, then it
should not be used. Unfortunately, 0 is a valid value for the pad index, for
the entity flags and for the entity function (some drivers set it to
MEDIA_ENT_F_UNKNOWN, which has value 0). This last one is most unfortunate,
since this should never have happened and would have been detected if we had
proper compliance tools.

Regards,

Hans

> 
> 
>>>  struct media_v2_pad {
>>> __u32 id;
>>> __u32 entity_id;
>>> __u32 flags;
>>> -   __u32 reserved[5];
>>> +   __u32 index;
>>> +   __u32 reserved[4];
>>>  } __attribute__ ((packed));
>>>  
>>>  struct media_v2_link {  
>>
>>
>>
>> Thanks,
>> Mauro
> 
> 
> 
> Thanks,
> Mauro
> 

Re: [PATCHv2 4/9] media: add function field to struct media_entity_desc

[Mauro Carvalho Chehab]

Em Mon, 16 Apr 2018 21:27:01 +0200
Hans Verkuil  escreveu:

> On 04/16/2018 08:01 PM, Mauro Carvalho Chehab wrote:
> > Em Mon, 16 Apr 2018 15:21:16 +0200
> > Hans Verkuil  escreveu:
> >   
> >> From: Hans Verkuil 
> >>
> >> This adds support for 'proper' functions to the existing API.
> >> This information was before only available through the new v2
> >> API, with this change it's available to both.
> >>
> >> Yes, the plan is to allow entities to expose multiple functions for
> >> multi-function devices, but we do not support it anywhere so this
> >> is still vaporware.  
> > 
> > I'm not convinced about that. I would, instead, just keep it as-is
> > and be sure that applications stop use the legacy calls.  
> 
> You can't. First of all, since the new API does not provide the pad index
> (fixed in patch 6/9) it is impossible to use the new API with any driver
> that supports SETUP_LINK.

Yeah, unfortunately, the properties API was just an empty promise.

Anyway, as you said, patch 6/9 solves it.

> So any such driver that uses any of the newer
> subdevs with a function that is mapped to MEDIA_ENT_T_DEVNODE_UNKNOWN
> is currently not reporting that correctly. A good example is the
> imx driver. But also others if they are combined with such newer subdevs.

As far as I remember, other drivers also return MEDIA_ENT_F_UNKNOWN
(with also maps to MEDIA_ENT_T_DEVNODE_UNKNOWN) even via the new API, 
as the developer never cared to fill the entity function, even 
producing warnings.

> There is nothing wrong with the old API, except for not reporting the
> proper function value in field 'type' due to historical concerns.

There is. That's why we took about one year developing a new API.

> There is NO WAY we can suddenly prohibit applications from using the old
> API since the new API was never usable. And besides that, we have no method
> of knowing who uses the old API since such applications are likely custom
> for specific hardware.

Nobody is forbidding anything. We're just freezing it, as its
functionality was superseded.

> All that is really missing in the 'old' API (I hate the terms 'old' and
> 'new', they are misleading) is a proper 'function' field. Let's just add it
> and make it consistent with the documentation about entity functions.

It misses interfaces - with is needed to identify what interface controls
what.

> 
> >   
> >>
> >> Signed-off-by: Hans Verkuil 
> >> ---
> >>  drivers/media/media-device.c | 1 +
> >>  include/uapi/linux/media.h   | 7 ++-
> >>  2 files changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> >> index 7c3ab37c258a..dca1e5a3e0f9 100644
> >> --- a/drivers/media/media-device.c
> >> +++ b/drivers/media/media-device.c
> >> @@ -115,6 +115,7 @@ static long media_device_enum_entities(struct 
> >> media_device *mdev,
> >>if (ent->name)
> >>strlcpy(entd->name, ent->name, sizeof(entd->name));
> >>entd->type = ent->function;
> >> +  entd->function = ent->function;
> >>entd->revision = 0; /* Unused */  
> > 
> > I got confused here, until I went to the code and noticed that
> > entd->type is actually touched after this.
> > 
> > If we're willing to do that, you should add a comment there explaining
> > why we need to pass both type and function to userspace.  
> 
> True.
> 
> Regards,
> 
>   Hans
> 
> >   
> >>entd->flags = ent->flags;
> >>entd->group_id = 0; /* Unused */
> >> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> >> index 86c7dcc9cba3..ac08acffdb65 100644
> >> --- a/include/uapi/linux/media.h
> >> +++ b/include/uapi/linux/media.h
> >> @@ -146,6 +146,10 @@ struct media_device_info {
> >>  /* OR with the entity id value to find the next entity */
> >>  #define MEDIA_ENT_ID_FLAG_NEXT(1 << 31)
> >>  
> >> +/* Appeared in 4.18.0 */
> >> +#define MEDIA_ENTITY_DESC_HAS_FUNCTION(media_version) \
> >> +  ((media_version) >= 0x00041200)
> >> +
> >>  struct media_entity_desc {
> >>__u32 id;
> >>char name[32];
> >> @@ -155,8 +159,9 @@ struct media_entity_desc {
> >>__u32 group_id;
> >>__u16 pads;
> >>__u16 links;
> >> +  __u32 function;
> >>  
> >> -  __u32 reserved[4];
> >> +  __u32 reserved[3];
> >>  
> >>union {
> >>/* Node specifications */  
> > 
> > 
> > 
> > Thanks,
> > Mauro
> >   
> 



Thanks,
Mauro

Re: [PATCHv2 4/9] media: add function field to struct media_entity_desc

[Hans Verkuil]

On 04/16/2018 08:01 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 16 Apr 2018 15:21:16 +0200
> Hans Verkuil  escreveu:
> 
>> From: Hans Verkuil 
>>
>> This adds support for 'proper' functions to the existing API.
>> This information was before only available through the new v2
>> API, with this change it's available to both.
>>
>> Yes, the plan is to allow entities to expose multiple functions for
>> multi-function devices, but we do not support it anywhere so this
>> is still vaporware.
> 
> I'm not convinced about that. I would, instead, just keep it as-is
> and be sure that applications stop use the legacy calls.

You can't. First of all, since the new API does not provide the pad index
(fixed in patch 6/9) it is impossible to use the new API with any driver
that supports SETUP_LINK. So any such driver that uses any of the newer
subdevs with a function that is mapped to MEDIA_ENT_T_DEVNODE_UNKNOWN
is currently not reporting that correctly. A good example is the
imx driver. But also others if they are combined with such newer subdevs.

There is nothing wrong with the old API, except for not reporting the
proper function value in field 'type' due to historical concerns.

There is NO WAY we can suddenly prohibit applications from using the old
API since the new API was never usable. And besides that, we have no method
of knowing who uses the old API since such applications are likely custom
for specific hardware.

All that is really missing in the 'old' API (I hate the terms 'old' and
'new', they are misleading) is a proper 'function' field. Let's just add it
and make it consistent with the documentation about entity functions.

> 
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  drivers/media/media-device.c | 1 +
>>  include/uapi/linux/media.h   | 7 ++-
>>  2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
>> index 7c3ab37c258a..dca1e5a3e0f9 100644
>> --- a/drivers/media/media-device.c
>> +++ b/drivers/media/media-device.c
>> @@ -115,6 +115,7 @@ static long media_device_enum_entities(struct 
>> media_device *mdev,
>>  if (ent->name)
>>  strlcpy(entd->name, ent->name, sizeof(entd->name));
>>  entd->type = ent->function;
>> +entd->function = ent->function;
>>  entd->revision = 0; /* Unused */
> 
> I got confused here, until I went to the code and noticed that
> entd->type is actually touched after this.
> 
> If we're willing to do that, you should add a comment there explaining
> why we need to pass both type and function to userspace.

True.

Regards,

Hans

> 
>>  entd->flags = ent->flags;
>>  entd->group_id = 0; /* Unused */
>> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
>> index 86c7dcc9cba3..ac08acffdb65 100644
>> --- a/include/uapi/linux/media.h
>> +++ b/include/uapi/linux/media.h
>> @@ -146,6 +146,10 @@ struct media_device_info {
>>  /* OR with the entity id value to find the next entity */
>>  #define MEDIA_ENT_ID_FLAG_NEXT  (1 << 31)
>>  
>> +/* Appeared in 4.18.0 */
>> +#define MEDIA_ENTITY_DESC_HAS_FUNCTION(media_version) \
>> +((media_version) >= 0x00041200)
>> +
>>  struct media_entity_desc {
>>  __u32 id;
>>  char name[32];
>> @@ -155,8 +159,9 @@ struct media_entity_desc {
>>  __u32 group_id;
>>  __u16 pads;
>>  __u16 links;
>> +__u32 function;
>>  
>> -__u32 reserved[4];
>> +__u32 reserved[3];
>>  
>>  union {
>>  /* Node specifications */
> 
> 
> 
> Thanks,
> Mauro
> 

Re: Donation

[M. M. Fridman]

--
I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to 
give

my fortune as charity.

Check the link below for confirmation:

http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604

Reply as soon as possible with further directives.

Best Regards,
Mikhail Fridman.

Re: OV5640 with 12MHz xclk

[Steve Longerbeam]

Hi Sam,

On 04/16/2018 05:26 AM, Hans Verkuil wrote:

On 04/16/2018 03:39 AM, Samuel Bobrowicz wrote:

Can anyone verify if the OV5640 driver works with input clocks other
than the typical 24MHz? The driver suggests anything from 6MHz-24MHz
is acceptable, but I am running into issues while bringing up a module
that uses a 12MHz oscillator. I'd expect that different xclk's would
necessitate different register settings for the various resolutions
(PLL settings, PCLK width, etc.), however the driver does not seem to
modify nearly enough based on the frequency of xclk.

Sam


I'm pretty sure it has never been tested with 12 MHz. The i.MX SabreLite
seems to use 22 MHz, and I can't tell from the code what the SabreSD uses
(probably 22 or 24 MHz). Steve will probably know.


On i.MX6, the sabrelite uses the PWM3 clock at 22MHz for the OV5640 xclk.
The SabreSD uses the i.MX6 CKO clock, which is default sourced from the
24 MHz oscillator.

I wouldn't be surprised that there are issues with a 12MHz xclk in the
ov5640 driver. There's probably some assumptions made about the
xclk range in the hardcoded values in those huge register tables. Sorry
I don't have the time to look into it more.

Steve

Re: [PATCHv2 1/9] v4l2-mediabus.h: add hsv_enc

[Mauro Carvalho Chehab]

Em Mon, 16 Apr 2018 15:21:13 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Just like struct v4l2_pix_format add a hsv_enc field to describe
> the HSV encoding. It is in a union with the ycbcr_enc, since it
> is one or the other.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  include/uapi/linux/v4l2-mediabus.h | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/v4l2-mediabus.h 
> b/include/uapi/linux/v4l2-mediabus.h
> index 123a231001a8..52fd6cc9d491 100644
> --- a/include/uapi/linux/v4l2-mediabus.h
> +++ b/include/uapi/linux/v4l2-mediabus.h
> @@ -24,6 +24,7 @@
>   * @field:   used interlacing type (from enum v4l2_field)
>   * @colorspace:  colorspace of the data (from enum v4l2_colorspace)
>   * @ycbcr_enc:   YCbCr encoding of the data (from enum 
> v4l2_ycbcr_encoding)
> + * @hsv_enc: HSV encoding of the data (from enum v4l2_hsv_encoding)
>   * @quantization: quantization of the data (from enum v4l2_quantization)
>   * @xfer_func:  transfer function of the data (from enum v4l2_xfer_func)
>   */
> @@ -33,7 +34,12 @@ struct v4l2_mbus_framefmt {
>   __u32   code;
>   __u32   field;
>   __u32   colorspace;
> - __u16   ycbcr_enc;
> + union {
> + /* enum v4l2_ycbcr_encoding */
> + __u16   ycbcr_enc;
> + /* enum v4l2_hsv_encoding */
> + __u16   hsv_enc;
> + };

While I'm OK with that, it currently doesn't make sense to apply
it, as no driver is currently using v4l2_mbus_framefmt.hsv_enc.

>   __u16   quantization;
>   __u16   xfer_func;
>   __u16   reserved[11];



Thanks,
Mauro

Re: [PATCHv2 9/9] media-ioc-g-topology.rst: document new 'flags' field

[Mauro Carvalho Chehab]

Em Mon, 16 Apr 2018 15:21:21 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Document the new struct media_v2_entity 'flags' field.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  Documentation/media/uapi/mediactl/media-ioc-g-topology.rst | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst 
> b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
> index 459818c3490c..6521ab7c9b58 100644
> --- a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
> +++ b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
> @@ -211,7 +211,18 @@ desired arrays with the media graph elements.
>  
> -  __u32
>  
> -   -  ``reserved``\ [6]
> +   -  ``flags``
> +
> +   -  Entity flags, see :ref:`media-entity-flag` for details.
> +  Only valid if ``MEDIA_V2_ENTITY_HAS_FLAGS(media_version)``
> +  returns true. The ``media_version`` is defined in struct
> +   :c:type:`media_device_info`.
> +
> +-  .. row 5

Same comment as before: let's not add new useless comments.

> +
> +   -  __u32
> +
> +   -  ``reserved``\ [5]
>  
> -  Reserved for future extensions. Drivers and applications must set
> this array to zero.



Thanks,
Mauro

Re: [PATCHv2 6/9] media: add 'index' to struct media_v2_pad

[Mauro Carvalho Chehab]

Em Mon, 16 Apr 2018 15:03:35 -0300
Mauro Carvalho Chehab  escreveu:

> Em Mon, 16 Apr 2018 15:21:18 +0200
> Hans Verkuil  escreveu:
> 
> > From: Hans Verkuil 
> > 
> > The v2 pad structure never exposed the pad index, which made it impossible
> > to call the MEDIA_IOC_SETUP_LINK ioctl, which needs that information.
> > 
> > It is really trivial to just expose this information, so implement this.  
> 
> Acked-by: Mauro Carvalho Chehab 

Err... I looked on it too fast... See my comments below.

The same applies to patch 8/9.

> > 
> > Signed-off-by: Hans Verkuil 
> > ---
> >  drivers/media/media-device.c | 1 +
> >  include/uapi/linux/media.h   | 7 ++-
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> > index dca1e5a3e0f9..73ffea3e81c9 100644
> > --- a/drivers/media/media-device.c
> > +++ b/drivers/media/media-device.c
> > @@ -331,6 +331,7 @@ static long media_device_get_topology(struct 
> > media_device *mdev,
> > kpad.id = pad->graph_obj.id;
> > kpad.entity_id = pad->entity->graph_obj.id;
> > kpad.flags = pad->flags;
> > +   kpad.index = pad->index;
> >  
> > if (copy_to_user(upad, , sizeof(kpad)))
> > ret = -EFAULT;
> > diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> > index ac08acffdb65..15f7f432f808 100644
> > --- a/include/uapi/linux/media.h
> > +++ b/include/uapi/linux/media.h
> > @@ -310,11 +310,16 @@ struct media_v2_interface {
> > };
> >  } __attribute__ ((packed));
> >  
> > +/* Appeared in 4.18.0 */
> > +#define MEDIA_V2_PAD_HAS_INDEX(media_version) \
> > +   ((media_version) >= 0x00041200)
> > +

I don't like this, for a couple of reasons:

1) it has a magic number on it, with is actually a parsed
   version of LINUX_VERSION() macro;

2) it sounds really weird to ship a header file with a new
   kernel version meant to provide backward compatibility with
   older versions;

3) this isn't any different than:

#define MEDIA_V2_PAD_HAS_INDEX -1

I think we need to think a little bit more about that.


> >  struct media_v2_pad {
> > __u32 id;
> > __u32 entity_id;
> > __u32 flags;
> > -   __u32 reserved[5];
> > +   __u32 index;
> > +   __u32 reserved[4];
> >  } __attribute__ ((packed));
> >  
> >  struct media_v2_link {  
> 
> 
> 
> Thanks,
> Mauro



Thanks,
Mauro

Re: [PATCHv2 7/9] media-ioc-g-topology.rst: document new 'index' field

[Mauro Carvalho Chehab]

Em Mon, 16 Apr 2018 15:21:19 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Document the new struct media_v2_pad 'index' field.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  Documentation/media/uapi/mediactl/media-ioc-g-topology.rst | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst 
> b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
> index c4055ddf070a..459818c3490c 100644
> --- a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
> +++ b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
> @@ -334,7 +334,17 @@ desired arrays with the media graph elements.
>  
> -  __u32
>  
> -   -  ``reserved``\ [5]
> +   -  ``index``
> +
> +   -  0-based pad index. Only valid if 
> ``MEDIA_V2_PAD_HAS_INDEX(media_version)``
> +  returns true. The ``media_version`` is defined in struct
> +   :c:type:`media_device_info`.
> +
> +-  .. row 5

Same comment as before: let's have just one patch removing those
script-generated comments from the doc files we touch.

> +
> +   -  __u32
> +
> +   -  ``reserved``\ [4]
>  
> -  Reserved for future extensions. Drivers and applications must set
> this array to zero.



Thanks,
Mauro

Re: [PATCHv2 6/9] media: add 'index' to struct media_v2_pad

[Mauro Carvalho Chehab]

Em Mon, 16 Apr 2018 15:21:18 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> The v2 pad structure never exposed the pad index, which made it impossible
> to call the MEDIA_IOC_SETUP_LINK ioctl, which needs that information.
> 
> It is really trivial to just expose this information, so implement this.

Acked-by: Mauro Carvalho Chehab 
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/media-device.c | 1 +
>  include/uapi/linux/media.h   | 7 ++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index dca1e5a3e0f9..73ffea3e81c9 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -331,6 +331,7 @@ static long media_device_get_topology(struct media_device 
> *mdev,
>   kpad.id = pad->graph_obj.id;
>   kpad.entity_id = pad->entity->graph_obj.id;
>   kpad.flags = pad->flags;
> + kpad.index = pad->index;
>  
>   if (copy_to_user(upad, , sizeof(kpad)))
>   ret = -EFAULT;
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index ac08acffdb65..15f7f432f808 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -310,11 +310,16 @@ struct media_v2_interface {
>   };
>  } __attribute__ ((packed));
>  
> +/* Appeared in 4.18.0 */
> +#define MEDIA_V2_PAD_HAS_INDEX(media_version) \
> + ((media_version) >= 0x00041200)
> +
>  struct media_v2_pad {
>   __u32 id;
>   __u32 entity_id;
>   __u32 flags;
> - __u32 reserved[5];
> + __u32 index;
> + __u32 reserved[4];
>  } __attribute__ ((packed));
>  
>  struct media_v2_link {



Thanks,
Mauro

Re: [PATCHv2 5/9] media-ioc-enum-entities.rst: document new 'function' field

[Mauro Carvalho Chehab]

Em Mon, 16 Apr 2018 15:21:17 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Document the new struct media_entity_desc 'function' field.

See my comments to patch 4/9.

> Signed-off-by: Hans Verkuil 
> ---
>  .../uapi/mediactl/media-ioc-enum-entities.rst  | 31 
> +-
>  1 file changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst 
> b/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst
> index 582fda488810..6b0ab65288c6 100644
> --- a/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst
> +++ b/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst
> @@ -90,6 +90,12 @@ id's until they get an error.
> -
> -
> -  Entity type, see :ref:`media-entity-functions` for details.
> +  Deprecated. If possible, use the ``function`` field instead.
> +   For backwards compatibility this ``type`` field will only
> +   expose functions ``MEDIA_ENT_F_IO_V4L``, ``MEDIA_ENT_F_CAM_SENSOR``,
> +   ``MEDIA_ENT_F_FLASH``, ``MEDIA_ENT_F_LENS``, 
> ``MEDIA_ENT_F_ATV_DECODER``
> +   and ``MEDIA_ENT_F_TUNER``. Other functions will be mapped to
> +   ``MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN`` or 
> ``MEDIA_ENT_T_DEVNODE_UNKNOWN``.
>  
>  -  .. row 4
>  
> @@ -146,18 +152,31 @@ id's until they get an error.
>  
> -  __u32
>  
> -   -  ``reserved[4]``
> +   -  ``function``
> +
> +   -
> +   -
> +   -  Entity main function, see :ref:`media-entity-functions` for 
> details.
> +  Only valid if ``MEDIA_ENTITY_DESC_HAS_FUNCTION(media_version)``
> +  returns true. The ``media_version`` is defined in struct
> +  :c:type:`media_device_info`.
> +
> +-  .. row 10
> +
> +   -  __u32
> +
> +   -  ``reserved[3]``
>  
> -
> -
> -  Reserved for future extensions. Drivers and applications must set
>the array to zero.
>  
> --  .. row 10
> +-  .. row 11

Instead of keep incrementing the ".. row \d+" comment, better to
just remove them all from this rst file on a previous patch.

>  
> -  union
>  
> --  .. row 11
> +-  .. row 12
>  
> -
> -  struct
> @@ -167,7 +186,7 @@ id's until they get an error.
> -
> -  Valid for (sub-)devices that create a single device node.
>  
> --  .. row 12
> +-  .. row 13
>  
> -
> -
> @@ -177,7 +196,7 @@ id's until they get an error.
>  
> -  Device node major number.
>  
> --  .. row 13
> +-  .. row 14
>  
> -
> -
> @@ -187,7 +206,7 @@ id's until they get an error.
>  
> -  Device node minor number.
>  
> --  .. row 14
> +-  .. row 15
>  
> -
> -  __u8



Thanks,
Mauro

Re: [PATCHv2 4/9] media: add function field to struct media_entity_desc

[Mauro Carvalho Chehab]

Em Mon, 16 Apr 2018 15:21:16 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> This adds support for 'proper' functions to the existing API.
> This information was before only available through the new v2
> API, with this change it's available to both.
> 
> Yes, the plan is to allow entities to expose multiple functions for
> multi-function devices, but we do not support it anywhere so this
> is still vaporware.

I'm not convinced about that. I would, instead, just keep it as-is
and be sure that applications stop use the legacy calls.

> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/media-device.c | 1 +
>  include/uapi/linux/media.h   | 7 ++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 7c3ab37c258a..dca1e5a3e0f9 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -115,6 +115,7 @@ static long media_device_enum_entities(struct 
> media_device *mdev,
>   if (ent->name)
>   strlcpy(entd->name, ent->name, sizeof(entd->name));
>   entd->type = ent->function;
> + entd->function = ent->function;
>   entd->revision = 0; /* Unused */

I got confused here, until I went to the code and noticed that
entd->type is actually touched after this.

If we're willing to do that, you should add a comment there explaining
why we need to pass both type and function to userspace.

>   entd->flags = ent->flags;
>   entd->group_id = 0; /* Unused */
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index 86c7dcc9cba3..ac08acffdb65 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -146,6 +146,10 @@ struct media_device_info {
>  /* OR with the entity id value to find the next entity */
>  #define MEDIA_ENT_ID_FLAG_NEXT   (1 << 31)
>  
> +/* Appeared in 4.18.0 */
> +#define MEDIA_ENTITY_DESC_HAS_FUNCTION(media_version) \
> + ((media_version) >= 0x00041200)
> +
>  struct media_entity_desc {
>   __u32 id;
>   char name[32];
> @@ -155,8 +159,9 @@ struct media_entity_desc {
>   __u32 group_id;
>   __u16 pads;
>   __u16 links;
> + __u32 function;
>  
> - __u32 reserved[4];
> + __u32 reserved[3];
>  
>   union {
>   /* Node specifications */



Thanks,
Mauro

Re: [PATCHv2 3/9] media.h: remove __NEED_MEDIA_LEGACY_API

[Mauro Carvalho Chehab]

Em Mon, 16 Apr 2018 15:21:15 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> The __NEED_MEDIA_LEGACY_API define is 1) ugly and 2) dangerous
> since it is all too easy for drivers to define it to get hold of
> legacy defines. Instead just define what we need in media-device.c
> which is the only place where we need the legacy define
> (MEDIA_ENT_T_DEVNODE_UNKNOWN).
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/media-device.c | 13 ++---
>  include/uapi/linux/media.h   |  2 +-
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 35e81f7c0d2f..7c3ab37c258a 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -16,9 +16,6 @@
>   * GNU General Public License for more details.
>   */
>  
> -/* We need to access legacy defines from linux/media.h */
> -#define __NEED_MEDIA_LEGACY_API
> -
>  #include 
>  #include 
>  #include 
> @@ -35,6 +32,16 @@
>  
>  #ifdef CONFIG_MEDIA_CONTROLLER
>  
> +/*
> + * Legacy defines from linux/media.h. This is the only place we need this
> + * so we just define it here. The media.h header doesn't expose it to the
> + * kernel to prevent it from being used by drivers, but here (and only here!)
> + * we need it to handle the legacy behavior.
> + */
> +#define MEDIA_ENT_SUBTYPE_MASK   0x
> +#define MEDIA_ENT_T_DEVNODE_UNKNOWN  (MEDIA_ENT_F_OLD_BASE | \
> +  MEDIA_ENT_SUBTYPE_MASK)

I don't like much the idea of duplicating defines at C code, but, 
in this specific case, I agree that this is better.

Acked-by: Mauro Carvalho Chehab 

> +
>  /* 
> -
>   * Userspace API
>   */
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index c7e9a5cba24e..86c7dcc9cba3 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -348,7 +348,7 @@ struct media_v2_topology {
>  #define MEDIA_IOC_SETUP_LINK _IOWR('|', 0x03, struct media_link_desc)
>  #define MEDIA_IOC_G_TOPOLOGY _IOWR('|', 0x04, struct media_v2_topology)
>  
> -#if !defined(__KERNEL__) || defined(__NEED_MEDIA_LEGACY_API)
> +#ifndef __KERNEL__
>  
>  /*
>   * Legacy symbols used to avoid userspace compilation breakages.



Thanks,
Mauro

[PATCH] [media] ddbridge: don't uselessly check for dma in start/stop functions

[Daniel Scheller]

From: Daniel Scheller 

The check for a valid ptr in ddb_io->dma isn't really necessary since only
devices that do data transport using DMA are supported by the driver, and
all previous initialisation code (through input_init(), output_init() and
dma_init(), has_dma is always true as it's set in ddb_probe() during
driver load) guarantees the ptr is set.

As a side effect, this silences these sparse warnings (albeit them being
false positives as ddb_io->dma won't change in these functions so the
condition always equals to the same result):

drivers/media/pci/ddbridge/ddbridge-core.c:495:9: warning: context 
imbalance in 'ddb_output_start' - different lock contexts for basic block
drivers/media/pci/ddbridge/ddbridge-core.c:510:9: warning: context 
imbalance in 'ddb_output_stop' - different lock contexts for basic block
drivers/media/pci/ddbridge/ddbridge-core.c:525:9: warning: context 
imbalance in 'ddb_input_stop' - different lock contexts for basic block
drivers/media/pci/ddbridge/ddbridge-core.c:560:9: warning: context 
imbalance in 'ddb_input_start' - different lock contexts for basic block

Signed-off-by: Daniel Scheller 
---
Superseds https://patchwork.linuxtv.org/patch/48593/

 drivers/media/pci/ddbridge/ddbridge-core.c | 85 --
 1 file changed, 35 insertions(+), 50 deletions(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 90687eff5909..c90f2933df8d 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -410,13 +410,11 @@ static void ddb_output_start(struct ddb_output *output)
struct ddb *dev = output->port->dev;
u32 con = 0x11c, con2 = 0;
 
-   if (output->dma) {
-   spin_lock_irq(>dma->lock);
-   output->dma->cbuf = 0;
-   output->dma->coff = 0;
-   output->dma->stat = 0;
-   ddbwritel(dev, 0, DMA_BUFFER_CONTROL(output->dma));
-   }
+   spin_lock_irq(>dma->lock);
+   output->dma->cbuf = 0;
+   output->dma->coff = 0;
+   output->dma->stat = 0;
+   ddbwritel(dev, 0, DMA_BUFFER_CONTROL(output->dma));
 
if (output->port->input[0]->port->class == DDB_PORT_LOOP)
con = (1UL << 13) | 0x14;
@@ -429,36 +427,29 @@ static void ddb_output_start(struct ddb_output *output)
ddbwritel(dev, con, TS_CONTROL(output));
ddbwritel(dev, con2, TS_CONTROL2(output));
 
-   if (output->dma) {
-   ddbwritel(dev, output->dma->bufval,
- DMA_BUFFER_SIZE(output->dma));
-   ddbwritel(dev, 0, DMA_BUFFER_ACK(output->dma));
-   ddbwritel(dev, 1, DMA_BASE_READ);
-   ddbwritel(dev, 7, DMA_BUFFER_CONTROL(output->dma));
-   }
+   ddbwritel(dev, output->dma->bufval,
+ DMA_BUFFER_SIZE(output->dma));
+   ddbwritel(dev, 0, DMA_BUFFER_ACK(output->dma));
+   ddbwritel(dev, 1, DMA_BASE_READ);
+   ddbwritel(dev, 7, DMA_BUFFER_CONTROL(output->dma));
 
ddbwritel(dev, con | 1, TS_CONTROL(output));
 
-   if (output->dma) {
-   output->dma->running = 1;
-   spin_unlock_irq(>dma->lock);
-   }
+   output->dma->running = 1;
+   spin_unlock_irq(>dma->lock);
 }
 
 static void ddb_output_stop(struct ddb_output *output)
 {
struct ddb *dev = output->port->dev;
 
-   if (output->dma)
-   spin_lock_irq(>dma->lock);
+   spin_lock_irq(>dma->lock);
 
ddbwritel(dev, 0, TS_CONTROL(output));
 
-   if (output->dma) {
-   ddbwritel(dev, 0, DMA_BUFFER_CONTROL(output->dma));
-   output->dma->running = 0;
-   spin_unlock_irq(>dma->lock);
-   }
+   ddbwritel(dev, 0, DMA_BUFFER_CONTROL(output->dma));
+   output->dma->running = 0;
+   spin_unlock_irq(>dma->lock);
 }
 
 static void ddb_input_stop(struct ddb_input *input)
@@ -466,45 +457,39 @@ static void ddb_input_stop(struct ddb_input *input)
struct ddb *dev = input->port->dev;
u32 tag = DDB_LINK_TAG(input->port->lnr);
 
-   if (input->dma)
-   spin_lock_irq(>dma->lock);
+   spin_lock_irq(>dma->lock);
+
ddbwritel(dev, 0, tag | TS_CONTROL(input));
-   if (input->dma) {
-   ddbwritel(dev, 0, DMA_BUFFER_CONTROL(input->dma));
-   input->dma->running = 0;
-   spin_unlock_irq(>dma->lock);
-   }
+
+   ddbwritel(dev, 0, DMA_BUFFER_CONTROL(input->dma));
+   input->dma->running = 0;
+   spin_unlock_irq(>dma->lock);
 }
 
 static void ddb_input_start(struct ddb_input *input)
 {
struct ddb *dev = input->port->dev;
 
-   if (input->dma) {
-   spin_lock_irq(>dma->lock);
-   input->dma->cbuf = 0;
-   input->dma->coff = 0;
-   input->dma->stat = 0;
-   ddbwritel(dev, 0, 

Re: [PATCH v3 1/2] media: imx-media-csi: Fix inconsistent IS_ERR and PTR_ERR

[Fabio Estevam]

On Mon, Apr 16, 2018 at 10:16 AM, Philipp Zabel  wrote:

> The second patch is applied now, but this part is still missing in
> v4.17-rc1, causing the CSI subdev probe to fail:
>
>   imx-ipuv3-csi: probe of imx-ipuv3-csi.0 failed with error -1369528304
>   imx-ipuv3-csi: probe of imx-ipuv3-csi.1 failed with error -1369528304
>   imx-ipuv3-csi: probe of imx-ipuv3-csi.5 failed with error -1369528304
>   imx-ipuv3-csi: probe of imx-ipuv3-csi.6 failed with error -1369528304

Yes, this original patch does not apply against 4.17-rc1 anymore, so I
rebased and resend it.

Thanks

[PATCH v2] media: imx-media-csi: Fix inconsistent IS_ERR and PTR_ERR

[Fabio Estevam]

From: From: Gustavo A. R. Silva 

Fix inconsistent IS_ERR and PTR_ERR in imx_csi_probe.
The proper pointer to be passed as argument is pinctrl
instead of priv->vdev.

This issue was detected with the help of Coccinelle.

Fixes: 52e17089d185 ("media: imx: Don't initialize vars that won't be used")
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Fabio Estevam 
Acked-by: Philipp Zabel 
---
Changes since v1:
- Rebased against 4.17-rc1

 drivers/staging/media/imx/imx-media-csi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 16cab40..aeab05f 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1799,7 +1799,7 @@ static int imx_csi_probe(struct platform_device *pdev)
priv->dev->of_node = pdata->of_node;
pinctrl = devm_pinctrl_get_select_default(priv->dev);
if (IS_ERR(pinctrl)) {
-   ret = PTR_ERR(priv->vdev);
+   ret = PTR_ERR(pinctrl);
dev_dbg(priv->dev,
"devm_pinctrl_get_select_default() failed: %d\n", ret);
if (ret != -ENODEV)
-- 
2.7.4

[PATCH 0/9] Do some atomisp cleanups

[Mauro Carvalho Chehab]

When I started building media subsystem with the atomisp driver,
I ended by adding several hacks on their Makefiles, in order to
get rid of thousands of warnings. I felt a little guty of hiding how
broken is this driver, so I decided t remove two Makefile hacks that
affect sensors and fix the warnings. 

Yet, there's still one such hack at 
drivers/staging/media/atomisp/pci/atomisp2/Makefile, with:

# HACK! While this driver is in bad shape, don't enable several warnings
#   that would be otherwise enabled with W=1
ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
ccflags-y += $(call cc-disable-warning, missing-prototypes)
ccflags-y += $(call cc-disable-warning, missing-declarations)
ccflags-y += $(call cc-disable-warning, suggest-attribute=format)
ccflags-y += $(call cc-disable-warning, unused-const-variable)
ccflags-y += $(call cc-disable-warning, unused-but-set-variable)

Getting his of those is a big task, as there are thousands of warnings
hidden there. In order to seriously get rid of them, one should start
getting rid of the several abstraction layers at the driver and have
hardware for test.

As I don't have any hardware to test, nor any reason why
dedicating myself to such task, I'll just leave this task for others
to do.

Mauro Carvalho Chehab (9):
  media: staging: atomisp: get rid of __KERNEL macros
  media: staging: atomisp: reenable warnings for I2C
  media: atomisp: ov2680.h: fix identation
  media: staging: atomisp-gc2235: don't fill an unused var
  media: staging: atomisp: Comment out several unused sensor resolutions
  media: atomisp: ov2680: don't declare unused vars
  media: atomisp-gc0310: return errors at gc0310_init()
  media: atomisp-mt9m114: remove dead data
  media: atomisp-mt9m114: comment out unused stuff

 drivers/staging/media/atomisp/i2c/Makefile |   7 -
 drivers/staging/media/atomisp/i2c/atomisp-gc0310.c |   2 +-
 drivers/staging/media/atomisp/i2c/atomisp-gc2235.c |   6 +-
 .../staging/media/atomisp/i2c/atomisp-mt9m114.c|  11 +-
 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c |   6 +-
 drivers/staging/media/atomisp/i2c/gc2235.h |   9 +-
 drivers/staging/media/atomisp/i2c/mt9m114.h|  13 +-
 drivers/staging/media/atomisp/i2c/ov2680.h | 900 +++--
 drivers/staging/media/atomisp/i2c/ov2722.h |   6 +
 drivers/staging/media/atomisp/i2c/ov5693/Makefile  |   7 -
 drivers/staging/media/atomisp/i2c/ov5693/ov5693.h  |  18 +-
 .../css_2401_csi2p_system/host/system_local.h  |  15 -
 .../hive_isp_css_common/host/system_local.h|  15 -
 .../css2400/hive_isp_css_include/math_support.h|   5 -
 .../css2400/hive_isp_css_include/print_support.h   |   3 -
 .../media/atomisp/pci/atomisp2/css2400/sh_css_sp.c |   4 -
 16 files changed, 503 insertions(+), 524 deletions(-)

-- 
2.14.3

[PATCH 8/9] media: atomisp-mt9m114: remove dead data

[Mauro Carvalho Chehab]

It seems that, originally, the logic would allow selecting between
fine and coarse integration. However, only coarse seems to be
implemented.

Get rid of this warning:

  drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c: In function 
'mt9m114_s_exposure':
  drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:1003:6: warning: variable 
'exposure_local' set but not used [-Wunused-but-set-variable]
u16 exposure_local[3];
^~

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c 
b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
index 44db9f9f1fc5..454a5c31a206 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
@@ -995,12 +995,10 @@ static long mt9m114_s_exposure(struct v4l2_subdev *sd,
struct mt9m114_device *dev = to_mt9m114_sensor(sd);
int ret = 0;
unsigned int coarse_integration = 0;
-   unsigned int fine_integration = 0;
unsigned int FLines = 0;
unsigned int FrameLengthLines = 0; /* ExposureTime.FrameLengthLines; */
unsigned int AnalogGain, DigitalGain;
u32 AnalogGainToWrite = 0;
-   u16 exposure_local[3];
 
dev_dbg(>dev, "%s(0x%X 0x%X 0x%X)\n", __func__,
exposure->integration_time[0], exposure->gain[0],
@@ -1032,10 +1030,7 @@ static long mt9m114_s_exposure(struct v4l2_subdev *sd,
return -EINVAL;
}
 
-   /* set coarse/fine integration */
-   exposure_local[0] = REG_EXPO_COARSE;
-   exposure_local[1] = (u16)coarse_integration;
-   exposure_local[2] = (u16)fine_integration;
+   /* set coarse integration */
/* 3A provide real exposure time.
should not translate to any value here. */
ret = mt9m114_write_reg(client, MISENSOR_16BIT,
-- 
2.14.3

Re: [PATCHv2 17/17] media: v4l2-compat-ioctl32: fix several __user annotations

[Mauro Carvalho Chehab]

> >>> @@ -898,7 +899,8 @@ static int put_v4l2_ext_controls32(struct file *file,
> >>>   if (ctrl_is_pointer(file, id))
> >>>   size -= sizeof(ucontrols->value64);
> >>>  
> >>> - if (copy_in_user(ucontrols, kcontrols, size))
> >>> + if (copy_in_user(ucontrols,
> >>> +  (unsigned int __user *)kcontrols, size))
> >>
> >> This is rather ugly. Would it be better to do something like this:
> >>
> >>struct v4l2_ext_control __user *kcontrols
> >>struct v4l2_ext_control *kcontrols_tmp;
> >>
> >>get_user(kcontrols_tmp, >controls);
> >>kcontrols = (void __user __force *)kcontrols_tmp;  
> > 
> > Nah, having two pointers with the same value, one with __user and another
> > one without it will make it really hard for people to review.
> >   
> >>
> >> And then there is no need to change anything else.
> >>
> >> Regardless of the chosen solution, this needs comments to explain what is 
> >> going
> >> on here, just as with v4l2_buffer above.  
> > 
> > Actually, the problem here happens before that. The problem
> > here (and on the previous one) is that get_user() expects that
> > the second argument to be a Kernelspace pointer.  
> 
> You mean the first argument? I'm actually not entirely sure if this is
> correct since __get_user calls __typeof__, but that might not know about
> __user. Anyway, it does not really matter for this patch and the uaccess.h
> code gives me a headache :-)

__typeof__ gets the type of the var, but __user is not a type. it is
something else (see include/linux/compiler_types.h):

#ifdef __CHECKER__
# define __user __attribute__((noderef, address_space(1)))
...
#else /* __CHECKER__ */
# ifdef STRUCTLEAK_PLUGIN
#  define __user __attribute__((user))
# else
#  define __user
# endif
...
#endif /* __CHECKER__ */

It is only built for sparse/smatch and uses __attribute__ definition,
with I guess __type_of__() won't parse.

Also, on almost all places where get_user() is called, what you expect
is to fill a Kernelspace var with something that came from userspace.

So, it expects that the first argument to be a pointer to an area
that is at Kernelspace.

> 
> > 
> > So, in this routine, it does (simplified):
> > 
> > struct v4l2_ext_control32 __user *ucontrols;
> > struct v4l2_ext_control *kcontrols;
> > 
> > ...
> > get_user(kcontrols, >controls);
> > 
> > Then, every time it needs to get something related to it,
> > it needs the __user, like here:
> > 
> > if (get_user(id, (unsigned int __user *)>id)
> > ...
> > 
> > In this specific case, only copy_in_user() was missing it; all the other
> > __user casts are there already.
> > 
> >   
> >> Note: the whole 'u' and 'k' naming is now hopelessly out of date 
> >> and
> >> confusing. It should really be '32' and '64' to denote 32 bit vs
> >> 64 bit layout. The pointers are now always in userspace, so 'k' no 
> >> longer
> >> makes sense.  
> > 
> > Yes, we need this change, but this should be at a separate patch.
> > 
> > I can do it, after we cleanup v4l2-compat-ioctl32.c from their namespace
> > mess.  
> 
> Of course, this is a separate patch.
> 
> > 
> >   
> >>  
> >>>   return -EFAULT;
> >>>  
> >>>   ucontrols++;
> >>> @@ -954,7 +956,7 @@ static int get_v4l2_edid32(struct v4l2_edid __user 
> >>> *kp,
> >>>   assign_in_user(>start_block, >start_block) ||
> >>>   assign_in_user(>blocks, >blocks) ||
> >>>   get_user(tmp, >edid) ||
> >>> - put_user(compat_ptr(tmp), >edid) ||
> >>> + put_user((void __force *)compat_ptr(tmp), >edid) ||
> >>>   copy_in_user(kp->reserved, up->reserved, sizeof(kp->reserved)))
> >>>   return -EFAULT;
> >>>   return 0;
> >>> @@ -970,7 +972,7 @@ static int put_v4l2_edid32(struct v4l2_edid __user 
> >>> *kp,
> >>>   assign_in_user(>start_block, >start_block) ||
> >>>   assign_in_user(>blocks, >blocks) ||
> >>>   get_user(edid, >edid) ||
> >>> - put_user(ptr_to_compat(edid), >edid) ||
> >>> + put_user(ptr_to_compat((void __user *)edid), >edid) ||
> >>>   copy_in_user(up->reserved, kp->reserved, sizeof(up->reserved)))
> >>>   return -EFAULT;
> >>>   return 0;
> >>> 
> >>
> >> Otherwise this patch looks good.
> >>
> >> Regards,
> >>
> >>Hans  
> > 
> > Would be ok if I fold (or add as a separate patch) the enclosed diff?
> > 
> > Thanks,
> > Mauro
> > 
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> > b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > index 1057ab8ce2b6..5c3408bdfd89 100644
> > --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > @@ -617,6 +617,15 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
> > *kp,
> >  
> > if (num_planes == 0)
> > return 0;
> > +   /*
> > +* We 

[PATCH 5/9] media: staging: atomisp: Comment out several unused sensor resolutions

[Mauro Carvalho Chehab]

The register settings for several resolutions aren't used
currently. So, comment them out.

Fix those warnings:

In file included from drivers/staging/media/atomisp/i2c/atomisp-gc2235.c:35:0:
drivers/staging/media/atomisp/i2c/gc2235.h:340:32: warning: 
'gc2235_960_640_30fps' defined but not used [-Wunused-const-variable=]
 static struct gc2235_reg const gc2235_960_640_30fps[] = {
^~~~
drivers/staging/media/atomisp/i2c/gc2235.h:287:32: warning: 
'gc2235_1296_736_30fps' defined but not used [-Wunused-const-variable=]
 static struct gc2235_reg const gc2235_1296_736_30fps[] = {
^
In file included from drivers/staging/media/atomisp/i2c/atomisp-ov2722.c:35:0:
drivers/staging/media/atomisp/i2c/ov2722.h:999:32: warning: 'ov2722_720p_30fps' 
defined but not used [-Wunused-const-variable=]
 static struct ov2722_reg const ov2722_720p_30fps[] = {
^
drivers/staging/media/atomisp/i2c/ov2722.h:787:32: warning: 'ov2722_1M3_30fps' 
defined but not used [-Wunused-const-variable=]
 static struct ov2722_reg const ov2722_1M3_30fps[] = {
^~~~
drivers/staging/media/atomisp/i2c/ov2722.h:476:32: warning: 'ov2722_VGA_30fps' 
defined but not used [-Wunused-const-variable=]
 static struct ov2722_reg const ov2722_VGA_30fps[] = {
^~~~
drivers/staging/media/atomisp/i2c/ov2722.h:367:32: warning: 'ov2722_480P_30fps' 
defined but not used [-Wunused-const-variable=]
 static struct ov2722_reg const ov2722_480P_30fps[] = {
^
drivers/staging/media/atomisp/i2c/ov2722.h:257:32: warning: 'ov2722_QVGA_30fps' 
defined but not used [-Wunused-const-variable=]
 static struct ov2722_reg const ov2722_QVGA_30fps[] = {
^
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c: In function 
'__ov2680_set_exposure':
In file included from drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:35:0:
At top level:
drivers/staging/media/atomisp/i2c/ov2680.h:736:33: warning: 
'ov2680_1616x1082_30fps' defined but not used [-Wunused-const-variable=]
  static struct ov2680_reg const ov2680_1616x1082_30fps[] = {
 ^~
drivers/staging/media/atomisp/i2c/ov2680.h:649:33: warning: 
'ov2680_1456x1096_30fps' defined but not used [-Wunused-const-variable=]
  static struct ov2680_reg const ov2680_1456x1096_30fps[]= {
 ^~
drivers/staging/media/atomisp/i2c/ov2680.h:606:33: warning: 
'ov2680_1296x976_30fps' defined but not used [-Wunused-const-variable=]
  static struct ov2680_reg const ov2680_1296x976_30fps[] = {
 ^
drivers/staging/media/atomisp/i2c/ov2680.h:563:33: warning: 'ov2680_720p_30fps' 
defined but not used [-Wunused-const-variable=]
  static struct ov2680_reg const ov2680_720p_30fps[] = {
 ^
drivers/staging/media/atomisp/i2c/ov2680.h:520:33: warning: 
'ov2680_800x600_30fps' defined but not used [-Wunused-const-variable=]
  static struct ov2680_reg const ov2680_800x600_30fps[] = {
 ^~~~
drivers/staging/media/atomisp/i2c/ov2680.h:475:33: warning: 
'ov2680_720x592_30fps' defined but not used [-Wunused-const-variable=]
  static struct ov2680_reg const ov2680_720x592_30fps[] = {
 ^~~~
drivers/staging/media/atomisp/i2c/ov2680.h:433:33: warning: 
'ov2680_656x496_30fps' defined but not used [-Wunused-const-variable=]
  static struct ov2680_reg const ov2680_656x496_30fps[] = {
 ^~~~
drivers/staging/media/atomisp/i2c/ov2680.h:389:33: warning: 'ov2680_QVGA_30fps' 
defined but not used [-Wunused-const-variable=]
  static struct ov2680_reg const ov2680_QVGA_30fps[] = {
 ^
drivers/staging/media/atomisp/i2c/ov2680.h:346:33: warning: 'ov2680_CIF_30fps' 
defined but not used [-Wunused-const-variable=]
  static struct ov2680_reg const ov2680_CIF_30fps[] = {
 ^~~~
drivers/staging/media/atomisp/i2c/ov2680.h:301:33: warning: 'ov2680_QCIF_30fps' 
defined but not used [-Wunused-const-variable=]
  static struct ov2680_reg const ov2680_QCIF_30fps[] = {
 ^
In file included from 
drivers/staging/media/atomisp/i2c/ov5693/atomisp-ov5693.c:36:0:
drivers/staging/media/atomisp/i2c/ov5693/ov5693.h:988:32: warning: 
'ov5693_1424x1168_30fps' defined but not used [-Wunused-const-variable=]
 static struct ov5693_reg const ov5693_1424x1168_30fps[] = {
^~
drivers/staging/media/atomisp/i2c/ov5693/ov5693.h:954:32: warning: 
'ov5693_2592x1944_30fps' defined but 

[PATCH 9/9] media: atomisp-mt9m114: comment out unused stuff

[Mauro Carvalho Chehab]

There are lots of data structs defined there but aren't used
anywhere.

Comment them out. Gets rid of those warnings:

drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:1808:45: warning: 
'mt9m114_entity_ops' defined but not used [-Wunused-const-variable=]
 static const struct media_entity_operations mt9m114_entity_ops = {
 ^~
In file included from drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c:35:0:
drivers/staging/media/atomisp/i2c/mt9m114.h:805:34: warning: 'mt9m114_iq' 
defined but not used [-Wunused-const-variable=]
 static struct misensor_reg const mt9m114_iq[] = {
  ^~
drivers/staging/media/atomisp/i2c/mt9m114.h:797:34: warning: 
'mt9m114_antiflicker_60hz' defined but not used [-Wunused-const-variable=]
 static struct misensor_reg const mt9m114_antiflicker_60hz[] = {
  ^~~~
drivers/staging/media/atomisp/i2c/mt9m114.h:789:34: warning: 
'mt9m114_antiflicker_50hz' defined but not used [-Wunused-const-variable=]
 static struct misensor_reg const mt9m114_antiflicker_50hz[] = {
  ^~~~
drivers/staging/media/atomisp/i2c/mt9m114.h:682:34: warning: 
'mt9m114_720_480P_init' defined but not used [-Wunused-const-variable=]
 static struct misensor_reg const mt9m114_720_480P_init[] = {
  ^
drivers/staging/media/atomisp/i2c/mt9m114.h:533:34: warning: 
'mt9m114_960P_init' defined but not used [-Wunused-const-variable=]
 static struct misensor_reg const mt9m114_960P_init[] = {
  ^
drivers/staging/media/atomisp/i2c/mt9m114.h:518:34: warning: 
'mt9m114_wakeup_reg' defined but not used [-Wunused-const-variable=]
 static struct misensor_reg const mt9m114_wakeup_reg[] = {
  ^~
drivers/staging/media/atomisp/i2c/mt9m114.h:504:34: warning: 
'mt9m114_streaming' defined but not used [-Wunused-const-variable=]
 static struct misensor_reg const mt9m114_streaming[] = {
  ^
drivers/staging/media/atomisp/i2c/mt9m114.h:497:34: warning: 'mt9m114_suspend' 
defined but not used [-Wunused-const-variable=]
 static struct misensor_reg const mt9m114_suspend[] = {
  ^~~
drivers/staging/media/atomisp/i2c/mt9m114.h:393:34: warning: 
'mt9m114_exitstandby' defined but not used [-Wunused-const-variable=]
 static struct misensor_reg const mt9m114_exitstandby[] = {
  ^~~

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c |  4 
 drivers/staging/media/atomisp/i2c/mt9m114.h | 13 -
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c 
b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
index 454a5c31a206..8e180f903335 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
@@ -1805,10 +1805,6 @@ static const struct v4l2_subdev_ops mt9m114_ops = {
.sensor = _sensor_ops,
 };
 
-static const struct media_entity_operations mt9m114_entity_ops = {
-   .link_setup = NULL,
-};
-
 static int mt9m114_remove(struct i2c_client *client)
 {
struct mt9m114_device *dev;
diff --git a/drivers/staging/media/atomisp/i2c/mt9m114.h 
b/drivers/staging/media/atomisp/i2c/mt9m114.h
index 0af79d77a404..de39cc141308 100644
--- a/drivers/staging/media/atomisp/i2c/mt9m114.h
+++ b/drivers/staging/media/atomisp/i2c/mt9m114.h
@@ -390,6 +390,7 @@ static struct mt9m114_res_struct mt9m114_res[] = {
 };
 #define N_RES (ARRAY_SIZE(mt9m114_res))
 
+#if 0 /* Currently unused */
 static struct misensor_reg const mt9m114_exitstandby[] = {
{MISENSOR_16BIT,  0x098E, 0xDC00},
/* exit-standby */
@@ -397,6 +398,7 @@ static struct misensor_reg const mt9m114_exitstandby[] = {
{MISENSOR_16BIT,  0x0080, 0x8002},
{MISENSOR_TOK_TERM, 0, 0}
 };
+#endif
 
 static struct misensor_reg const mt9m114_exp_win[5][5] = {
{
@@ -494,6 +496,7 @@ static struct misensor_reg const mt9m114_exp_center[] = {
{MISENSOR_TOK_TERM, 0, 0}
 };
 
+#if 0 /* Currently unused */
 static struct misensor_reg const mt9m114_suspend[] = {
 {MISENSOR_16BIT,  0x098E, 0xDC00},
 {MISENSOR_8BIT,  0xDC00, 0x40},
@@ -507,6 +510,7 @@ static struct misensor_reg const mt9m114_streaming[] = {
 {MISENSOR_16BIT,  0x0080, 0x8002},
 {MISENSOR_TOK_TERM, 0, 0}
 };
+#endif
 
 static struct misensor_reg const mt9m114_standby_reg[] = {
 {MISENSOR_16BIT,  0x098E, 0xDC00},
@@ -515,12 +519,14 @@ static struct misensor_reg const mt9m114_standby_reg[] = {
 {MISENSOR_TOK_TERM, 0, 0}
 };
 
+#if 0 /* Currently unused */
 static struct 

[PATCH 4/9] media: staging: atomisp-gc2235: don't fill an unused var

[Mauro Carvalho Chehab]

The code with uses the dummy var is commented out. So,
coment out its definition/initialization.

Fix this warning:

  drivers/staging/media/atomisp/i2c/atomisp-gc2235.c: In function 
'gc2235_get_intg_factor':
  drivers/staging/media/atomisp/i2c/atomisp-gc2235.c:249:26: warning: variable 
'dummy' set but not used [-Wunused-but-set-variable]
u16 reg_val, reg_val_h, dummy;
^

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/atomisp/i2c/atomisp-gc2235.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c 
b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
index 93f9c618f3d8..4b6b6568b3cf 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
@@ -246,7 +246,7 @@ static int gc2235_get_intg_factor(struct i2c_client *client,
struct v4l2_subdev *sd = i2c_get_clientdata(client);
struct gc2235_device *dev = to_gc2235_sensor(sd);
struct atomisp_sensor_mode_data *buf = >data;
-   u16 reg_val, reg_val_h, dummy;
+   u16 reg_val, reg_val_h;
int ret;
 
if (!info)
@@ -316,7 +316,9 @@ static int gc2235_get_intg_factor(struct i2c_client *client,
if (ret)
return ret;
 
-   dummy = (reg_val_h << 8) | reg_val;
+#if 0
+   u16 dummy = (reg_val_h << 8) | reg_val;
+#endif
 
ret = gc2235_read_reg(client, GC2235_8BIT,
GC2235_SH_DELAY_H, _val_h);
-- 
2.14.3

[PATCH 3/9] media: atomisp: ov2680.h: fix identation

[Mauro Carvalho Chehab]

The identation for several tables there are broken.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/atomisp/i2c/ov2680.h | 895 ++---
 1 file changed, 447 insertions(+), 448 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/ov2680.h 
b/drivers/staging/media/atomisp/i2c/ov2680.h
index cb38e6e79409..c83ae379f517 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.h
+++ b/drivers/staging/media/atomisp/i2c/ov2680.h
@@ -299,131 +299,131 @@ struct ov2680_format {
 * 176x144 30fps  VBlanking 1lane 10Bit (binning)
 */
static struct ov2680_reg const ov2680_QCIF_30fps[] = {
-   {OV2680_8BIT, 0x3086, 0x01},
-   {OV2680_8BIT, 0x3501, 0x24},
-   {OV2680_8BIT, 0x3502, 0x40},
-   {OV2680_8BIT, 0x370a, 0x23},
-   {OV2680_8BIT, 0x3801, 0xa0},
-   {OV2680_8BIT, 0x3802, 0x00},
-   {OV2680_8BIT, 0x3803, 0x78},
-   {OV2680_8BIT, 0x3804, 0x05},
-   {OV2680_8BIT, 0x3805, 0xaf},
-   {OV2680_8BIT, 0x3806, 0x04},
-   {OV2680_8BIT, 0x3807, 0x47},
-   {OV2680_8BIT, 0x3808, 0x00},
-   {OV2680_8BIT, 0x3809, 0xC0},
-   {OV2680_8BIT, 0x380a, 0x00},
-   {OV2680_8BIT, 0x380b, 0xa0},
-   {OV2680_8BIT, 0x380c, 0x06},
-   {OV2680_8BIT, 0x380d, 0xb0},
-   {OV2680_8BIT, 0x380e, 0x02},
-   {OV2680_8BIT, 0x380f, 0x84},
-   {OV2680_8BIT, 0x3810, 0x00},
-   {OV2680_8BIT, 0x3811, 0x04},
-   {OV2680_8BIT, 0x3812, 0x00},
-   {OV2680_8BIT, 0x3813, 0x04},
-   {OV2680_8BIT, 0x3814, 0x31},
-   {OV2680_8BIT, 0x3815, 0x31},
-   {OV2680_8BIT, 0x4000, 0x81},
-   {OV2680_8BIT, 0x4001, 0x40},
-   {OV2680_8BIT, 0x4008, 0x00},
-   {OV2680_8BIT, 0x4009, 0x03},
-   {OV2680_8BIT, 0x5081, 0x41},
-   {OV2680_8BIT, 0x5708, 0x00}, //add for full size flip off and mirror 
off 2014/09/11
-   {OV2680_8BIT, 0x5704, 0x10},
-   {OV2680_8BIT, 0x5705, 0xa0},
-   {OV2680_8BIT, 0x5706, 0x0c},
-   {OV2680_8BIT, 0x5707, 0x78},
-   {OV2680_8BIT, 0x3820, 0xc2},
-   {OV2680_8BIT, 0x3821, 0x01},
-// {OV2680_8BIT, 0x5090, 0x0c},
-{OV2680_TOK_TERM, 0, 0}
+   {OV2680_8BIT, 0x3086, 0x01},
+   {OV2680_8BIT, 0x3501, 0x24},
+   {OV2680_8BIT, 0x3502, 0x40},
+   {OV2680_8BIT, 0x370a, 0x23},
+   {OV2680_8BIT, 0x3801, 0xa0},
+   {OV2680_8BIT, 0x3802, 0x00},
+   {OV2680_8BIT, 0x3803, 0x78},
+   {OV2680_8BIT, 0x3804, 0x05},
+   {OV2680_8BIT, 0x3805, 0xaf},
+   {OV2680_8BIT, 0x3806, 0x04},
+   {OV2680_8BIT, 0x3807, 0x47},
+   {OV2680_8BIT, 0x3808, 0x00},
+   {OV2680_8BIT, 0x3809, 0xC0},
+   {OV2680_8BIT, 0x380a, 0x00},
+   {OV2680_8BIT, 0x380b, 0xa0},
+   {OV2680_8BIT, 0x380c, 0x06},
+   {OV2680_8BIT, 0x380d, 0xb0},
+   {OV2680_8BIT, 0x380e, 0x02},
+   {OV2680_8BIT, 0x380f, 0x84},
+   {OV2680_8BIT, 0x3810, 0x00},
+   {OV2680_8BIT, 0x3811, 0x04},
+   {OV2680_8BIT, 0x3812, 0x00},
+   {OV2680_8BIT, 0x3813, 0x04},
+   {OV2680_8BIT, 0x3814, 0x31},
+   {OV2680_8BIT, 0x3815, 0x31},
+   {OV2680_8BIT, 0x4000, 0x81},
+   {OV2680_8BIT, 0x4001, 0x40},
+   {OV2680_8BIT, 0x4008, 0x00},
+   {OV2680_8BIT, 0x4009, 0x03},
+   {OV2680_8BIT, 0x5081, 0x41},
+   {OV2680_8BIT, 0x5708, 0x00}, //add for full size flip off and 
mirror off 2014/09/11
+   {OV2680_8BIT, 0x5704, 0x10},
+   {OV2680_8BIT, 0x5705, 0xa0},
+   {OV2680_8BIT, 0x5706, 0x0c},
+   {OV2680_8BIT, 0x5707, 0x78},
+   {OV2680_8BIT, 0x3820, 0xc2},
+   {OV2680_8BIT, 0x3821, 0x01},
+   // {OV2680_8BIT, 0x5090, 0x0c},
+   {OV2680_TOK_TERM, 0, 0}
};
 
/*
 * 352x288 30fps  VBlanking 1lane 10Bit (binning)
 */
static struct ov2680_reg const ov2680_CIF_30fps[] = {
-   {OV2680_8BIT, 0x3086, 0x01},
-   {OV2680_8BIT, 0x3501, 0x24},
-   {OV2680_8BIT, 0x3502, 0x40},
-   {OV2680_8BIT, 0x370a, 0x23},
-   {OV2680_8BIT, 0x3801, 0xa0},
-   {OV2680_8BIT, 0x3802, 0x00},
-   {OV2680_8BIT, 0x3803, 0x78},
-   {OV2680_8BIT, 0x3804, 0x03},
-   {OV2680_8BIT, 0x3805, 0x8f},
-   {OV2680_8BIT, 0x3806, 0x02},
-   {OV2680_8BIT, 0x3807, 0xe7},
-   {OV2680_8BIT, 0x3808, 0x01},
-   {OV2680_8BIT, 0x3809, 0x70},
-   {OV2680_8BIT, 0x380a, 0x01},
-   {OV2680_8BIT, 0x380b, 0x30},
-   {OV2680_8BIT, 0x380c, 0x06},
-   {OV2680_8BIT, 0x380d, 0xb0},
-   {OV2680_8BIT, 0x380e, 0x02},
-   {OV2680_8BIT, 0x380f, 0x84},
-   {OV2680_8BIT, 0x3810, 0x00},
-   {OV2680_8BIT, 0x3811, 0x04},
-   {OV2680_8BIT, 0x3812, 0x00},
-   {OV2680_8BIT, 0x3813, 0x04},
-   

[PATCH 7/9] media: atomisp-gc0310: return errors at gc0310_init()

[Mauro Carvalho Chehab]

If something wrong gets there, return the error.

Get rid of this warning:

  drivers/staging/media/atomisp/i2c/atomisp-gc0310.c: In function 'gc0310_init':
  drivers/staging/media/atomisp/i2c/atomisp-gc0310.c:713:6: warning: variable 
'ret' set but not used [-Wunused-but-set-variable]
int ret;
^~~

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/atomisp/i2c/atomisp-gc0310.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c 
b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
index 512fa87fa11b..3b38cbccf294 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
@@ -727,7 +727,7 @@ static int gc0310_init(struct v4l2_subdev *sd)
mutex_unlock(>input_lock);
 
pr_info("%s E\n", __func__);
-   return 0;
+   return ret;
 }
 
 static int power_ctrl(struct v4l2_subdev *sd, bool flag)
-- 
2.14.3

[PATCH 1/9] media: staging: atomisp: get rid of __KERNEL macros

[Mauro Carvalho Chehab]

There's no sense for a Kernel driver to have __KERNEL macros
on it.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../css2400/css_2401_csi2p_system/host/system_local.h | 15 ---
 .../css2400/hive_isp_css_common/host/system_local.h   | 15 ---
 .../atomisp2/css2400/hive_isp_css_include/math_support.h  |  5 -
 .../atomisp2/css2400/hive_isp_css_include/print_support.h |  3 ---
 .../media/atomisp/pci/atomisp2/css2400/sh_css_sp.c|  4 
 5 files changed, 42 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/host/system_local.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/host/system_local.h
index c16670989702..5600b32e29f4 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/host/system_local.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/host/system_local.h
@@ -31,23 +31,8 @@
 #define HRT_ADDRESS_WIDTH  64  /* Surprise, this is a local 
property */
 #endif
 
-#if !defined(__KERNEL__) || (1 == 1)
 /* This interface is deprecated */
 #include "hrt/hive_types.h"
-#else  /* __KERNEL__ */
-#include 
-
-#if HRT_ADDRESS_WIDTH == 64
-typedef uint64_t   hrt_address;
-#elif HRT_ADDRESS_WIDTH == 32
-typedef uint32_t   hrt_address;
-#else
-#error "system_local.h: HRT_ADDRESS_WIDTH must be one of {32,64}"
-#endif
-
-typedef uint32_t   hrt_vaddress;
-typedef uint32_t   hrt_data;
-#endif /* __KERNEL__ */
 
 /*
  * Cell specific address maps
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/system_local.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/system_local.h
index 111b346dfafb..8be1cd020bf4 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/system_local.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/system_local.h
@@ -33,23 +33,8 @@
 #define HRT_ADDRESS_WIDTH  64  /* Surprise, this is a local 
property */
 #endif
 
-#if !defined(__KERNEL__) || (1==1)
 /* This interface is deprecated */
 #include "hrt/hive_types.h"
-#else  /* __KERNEL__ */
-#include 
-
-#if HRT_ADDRESS_WIDTH==64
-typedef uint64_t   hrt_address;
-#elif HRT_ADDRESS_WIDTH==32
-typedef uint32_t   hrt_address;
-#else
-#error "system_local.h: HRT_ADDRESS_WIDTH must be one of {32,64}"
-#endif
-
-typedef uint32_t   hrt_vaddress;
-typedef uint32_t   hrt_data;
-#endif /* __KERNEL__ */
 
 /*
  * Cell specific address maps
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
index 6436dae0007e..7c52ba54fcf1 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/math_support.h
@@ -15,9 +15,7 @@
 #ifndef __MATH_SUPPORT_H
 #define __MATH_SUPPORT_H
 
-#if defined(__KERNEL__)
 #include  /* Override the definition of max/min from linux 
kernel*/
-#endif /*__KERNEL__*/
 
 #if defined(_MSC_VER)
 #include  /* Override the definition of max/min from stdlib.h*/
@@ -216,8 +214,5 @@ static inline unsigned int ceil_pow2(unsigned int a)
 #define OP_std_modadd(base, offset, size) ((base+offset)%(size))
 #endif /* !defined(__ISP) */
 
-#if !defined(__KERNEL__)
-#define clamp(a, min_val, max_val) MIN(MAX((a), (min_val)), (max_val))
-#endif /* !defined(__KERNEL__) */
 
 #endif /* __MATH_SUPPORT_H */
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/print_support.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/print_support.h
index ca0fbbb57788..37e8116b74a4 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/print_support.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/print_support.h
@@ -17,9 +17,6 @@
 
 
 #include 
-#if !defined(__KERNEL__)
-#include 
-#endif
 
 extern int (*sh_css_printf) (const char *fmt, va_list args);
 /* depends on host supplied print function in ia_css_init() */
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c
index 85263725540d..cdbe914787c8 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_sp.c
@@ -1592,10 +1592,6 @@ ia_css_pipe_set_irq_mask(struct ia_css_pipe *pipe,
 * - compare with (uint16_t)~0 or 0x
 * - different assert for Linux and Windows
 */
-#ifndef __KERNEL__
-   assert(or_mask <= UINT16_MAX);

[PATCH 2/9] media: staging: atomisp: reenable warnings for I2C

[Mauro Carvalho Chehab]

When atomisp got merged, there were so many warnings with W=1
that we simply disabled the ones that were causing troubles.

Since then, several changes got applied to atomisp, and the
number of warnings are a way smaller than it used to be.

So, let's reenable warnings there and fix the issues.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/atomisp/i2c/Makefile| 7 ---
 drivers/staging/media/atomisp/i2c/ov5693/Makefile | 7 ---
 2 files changed, 14 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/Makefile 
b/drivers/staging/media/atomisp/i2c/Makefile
index 99ea35c043fd..8d022986e199 100644
--- a/drivers/staging/media/atomisp/i2c/Makefile
+++ b/drivers/staging/media/atomisp/i2c/Makefile
@@ -16,10 +16,3 @@ obj-$(CONFIG_VIDEO_ATOMISP_MSRLIST_HELPER) += 
atomisp-libmsrlisthelper.o
 #
 
 obj-$(CONFIG_VIDEO_ATOMISP_LM3554) += atomisp-lm3554.o
-
-# HACK! While this driver is in bad shape, don't enable several warnings
-#   that would be otherwise enabled with W=1
-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
-ccflags-y += $(call cc-disable-warning, unused-const-variable)
-ccflags-y += $(call cc-disable-warning, missing-prototypes)
-ccflags-y += $(call cc-disable-warning, missing-declarations)
diff --git a/drivers/staging/media/atomisp/i2c/ov5693/Makefile 
b/drivers/staging/media/atomisp/i2c/ov5693/Makefile
index aa6be85c5a60..3275f2be229e 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/Makefile
+++ b/drivers/staging/media/atomisp/i2c/ov5693/Makefile
@@ -1,9 +1,2 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_VIDEO_ATOMISP_OV5693) += atomisp-ov5693.o
-
-# HACK! While this driver is in bad shape, don't enable several warnings
-#   that would be otherwise enabled with W=1
-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
-ccflags-y += $(call cc-disable-warning, unused-const-variable)
-ccflags-y += $(call cc-disable-warning, missing-prototypes)
-ccflags-y += $(call cc-disable-warning, missing-declarations)
-- 
2.14.3

[PATCH 6/9] media: atomisp: ov2680: don't declare unused vars

[Mauro Carvalho Chehab]

drivers/staging/media/atomisp/i2c/atomisp-ov2680.c: In function 
‘__ov2680_set_exposure’:
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:400:10: warning: variable 
‘hts’ set but not used [-Wunused-but-set-variable]
  u16 vts,hts;
  ^~~
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c: In function ‘ov2680_detect’:
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:1164:5: warning: variable 
‘revision’ set but not used [-Wunused-but-set-variable]
  u8 revision;
 ^~~~

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-ov2680.c 
b/drivers/staging/media/atomisp/i2c/atomisp-ov2680.c
index c0849299d592..bba3d1745908 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-ov2680.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-ov2680.c
@@ -397,14 +397,13 @@ static long __ov2680_set_exposure(struct v4l2_subdev *sd, 
int coarse_itg,
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ov2680_device *dev = to_ov2680_sensor(sd);
-   u16 vts,hts;
+   u16 vts;
int ret,exp_val;
 
dev_dbg(>dev,
"+++__ov2680_set_exposure coarse_itg %d, gain %d, digitgain 
%d++\n",
coarse_itg, gain, digitgain);
 
-   hts = ov2680_res[dev->fmt_idx].pixels_per_line;
vts = ov2680_res[dev->fmt_idx].lines_per_frame;
 
/* group hold */
@@ -1185,7 +1184,8 @@ static int ov2680_detect(struct i2c_client *client)
OV2680_SC_CMMN_SUB_ID, );
revision = (u8) high & 0x0f;
 
-   dev_info(>dev, "sensor_revision id = 0x%x\n", id);
+   dev_info(>dev, "sensor_revision id = 0x%x, rev= %d\n",
+id, revision);
 
return 0;
 }
-- 
2.14.3

Re: [PATCH] media: v4l2-compat-ioctl32: better name userspace pointers

[Hans Verkuil]

On 04/16/2018 05:11 PM, Mauro Carvalho Chehab wrote:
> In the past, "up" were an acronym for "user pointer" and "kp" for
> "kernel pointer". However, since a1dfb4c48cc1 ("media:
> v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"), both
> are now __user pointers.
> 
> So, the usage of "kp" is really misleading there. So, rename
> both to just "p32" and "p64" everywhere it occurs, in order to
> make peace with this file's namespace.
> 
> There are two exceptions to "up/kp" nomenclature: at
> alloc_userspace() and at do_video_ioctl().
> 
> There, a new userspace pointer were allocated, in order to store
> the 64 bits version of the ioctl. Those were called as "up_native",
> with is, IMHO, an even worse name, as "native" could mislead of
> being the arguments that were filled from userspace. I almost
> renamed it to just "p64", but, after thinking more about that,
> it sounded better to call it as "new_p64", as this makes clearer
> that this is the data structure that was allocated inside this
> file in order to be used to pass/retrieve data when calling the
> 64-bit ready file->f_op->unlocked_ioctl() function.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 578 
> +-
>  1 file changed, 289 insertions(+), 289 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index 5c3408bdfd89..064e4a2bdba3 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c



> @@ -392,31 +392,31 @@ struct v4l2_buffer32 {
>   __u32   reserved;
>  };
>  
> -static int get_v4l2_plane32(struct v4l2_plane __user *up,
> +static int get_v4l2_plane32(struct v4l2_plane __user *p32,
>   struct v4l2_plane32 __user *up32,

This is confusing: there is now a p32 and a up32 pointer. In all
fairness, this was already confusing. In this specific case 'up' should
be 'p64' and 'up32' should be 'p32'.

>   enum v4l2_memory memory)
>  {
>   compat_ulong_t p;
>  
> - if (copy_in_user(up, up32, 2 * sizeof(__u32)) ||
> - copy_in_user(>data_offset, >data_offset,
> -  sizeof(up->data_offset)))
> + if (copy_in_user(p32, up32, 2 * sizeof(__u32)) ||
> + copy_in_user(>data_offset, >data_offset,
> +  sizeof(p32->data_offset)))
>   return -EFAULT;
>  
>   switch (memory) {
>   case V4L2_MEMORY_MMAP:
>   case V4L2_MEMORY_OVERLAY:
> - if (copy_in_user(>m.mem_offset, >m.mem_offset,
> + if (copy_in_user(>m.mem_offset, >m.mem_offset,
>sizeof(up32->m.mem_offset)))
>   return -EFAULT;
>   break;
>   case V4L2_MEMORY_USERPTR:
>   if (get_user(p, >m.userptr) ||
> - put_user((unsigned long)compat_ptr(p), >m.userptr))
> + put_user((unsigned long)compat_ptr(p), >m.userptr))
>   return -EFAULT;
>   break;
>   case V4L2_MEMORY_DMABUF:
> - if (copy_in_user(>m.fd, >m.fd, sizeof(up32->m.fd)))
> + if (copy_in_user(>m.fd, >m.fd, sizeof(up32->m.fd)))
>   return -EFAULT;
>   break;
>   }
> @@ -424,32 +424,32 @@ static int get_v4l2_plane32(struct v4l2_plane __user 
> *up,
>   return 0;
>  }
>  
> -static int put_v4l2_plane32(struct v4l2_plane __user *up,
> +static int put_v4l2_plane32(struct v4l2_plane __user *p32,
>   struct v4l2_plane32 __user *up32,
>   enum v4l2_memory memory)

Same here. up -> p64 and up32 -> p32.

>  {
>   unsigned long p;
>  
> - if (copy_in_user(up32, up, 2 * sizeof(__u32)) ||
> - copy_in_user(>data_offset, >data_offset,
> -  sizeof(up->data_offset)))
> + if (copy_in_user(up32, p32, 2 * sizeof(__u32)) ||
> + copy_in_user(>data_offset, >data_offset,
> +  sizeof(p32->data_offset)))
>   return -EFAULT;
>  
>   switch (memory) {
>   case V4L2_MEMORY_MMAP:
>   case V4L2_MEMORY_OVERLAY:
> - if (copy_in_user(>m.mem_offset, >m.mem_offset,
> -  sizeof(up->m.mem_offset)))
> + if (copy_in_user(>m.mem_offset, >m.mem_offset,
> +  sizeof(p32->m.mem_offset)))
>   return -EFAULT;
>   break;
>   case V4L2_MEMORY_USERPTR:
> - if (get_user(p, >m.userptr)||
> + if (get_user(p, >m.userptr)||
>   put_user((compat_ulong_t)ptr_to_compat((void __user *)p),
>>m.userptr))
>   return -EFAULT;
>   break;
>   case V4L2_MEMORY_DMABUF:
> - if (copy_in_user(>m.fd, >m.fd, sizeof(up->m.fd)))
> +  

Re: [PATCHv2 17/17] media: v4l2-compat-ioctl32: fix several __user annotations

[Hans Verkuil]

On 04/16/2018 04:50 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 16 Apr 2018 14:03:45 +0200
> Hans Verkuil  escreveu:
> 
>> On 04/13/2018 08:07 PM, Mauro Carvalho Chehab wrote:
>>> Smatch report several issues with bad __user annotations:
>>>
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect 
>>> type in argument 1 (different address spaces)
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:expected void 
>>> [noderef] *uptr
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:got void 
>>> *
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: warning: incorrect 
>>> type in argument 1 (different address spaces)
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:expected void 
>>> const volatile [noderef] *
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:got struct 
>>> v4l2_plane [noderef] **
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: warning: incorrect 
>>> type in argument 1 (different address spaces)
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:expected void 
>>> [noderef] *uptr
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:got void 
>>> *[assigned] base
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: warning: incorrect 
>>> type in assignment (different address spaces)
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:expected struct 
>>> v4l2_ext_control [noderef] *kcontrols
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:got struct 
>>> v4l2_ext_control *
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: warning: incorrect 
>>> type in assignment (different address spaces)
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:expected 
>>> unsigned char [usertype] *__pu_val
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:got void 
>>> [noderef] *
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: warning: incorrect 
>>> type in argument 1 (different address spaces)
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:expected void 
>>> [noderef] *uptr
>>>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:got void 
>>> *[assigned] edid
>>>
>>> Fix them.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab 
>>> ---
>>>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 32 
>>> ++-
>>>  1 file changed, 17 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
>>> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>>> index d03a44d89649..0b9dfe7dbfe7 100644
>>> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>>> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>>> @@ -443,8 +443,8 @@ static int put_v4l2_plane32(struct v4l2_plane __user 
>>> *up,
>>> return -EFAULT;
>>> break;
>>> case V4L2_MEMORY_USERPTR:
>>> -   if (get_user(p, >m.userptr) ||
>>> -   put_user((compat_ulong_t)ptr_to_compat((__force void *)p),
>>> +   if (get_user(p, >m.userptr)||
>>> +   put_user((compat_ulong_t)ptr_to_compat((void __user *)p),
>>>  >m.userptr))
>>> return -EFAULT;
>>> break;
>>> @@ -587,7 +587,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
>>> *kp,
>>> u32 length;
>>> enum v4l2_memory memory;
>>> struct v4l2_plane32 __user *uplane32;
>>> -   struct v4l2_plane __user *uplane;
>>> +   struct v4l2_plane *uplane;  
>>
>> This needs a comment (either here or before the get_user below). It really 
>> is a
>> pointer to userspace, but since videodev2.h has it without __user (since it 
>> is
>> copied to kernel space in v4l2-ioctl.c) we need to define it as a regular 
>> pointer
>> here and cast it to a __user pointer in the put_v4l2_plane32() call.
>>
>> This is not trivially obvious, so a comment would help a lot.
> 
> 
> 
>>
>>> compat_caddr_t p;
>>> int ret;
>>>  
>>> @@ -617,15 +617,14 @@ static int put_v4l2_buffer32(struct v4l2_buffer 
>>> __user *kp,
>>>  
>>> if (num_planes == 0)
>>> return 0;
>>> -
>>> -   if (get_user(uplane, ((__force struct v4l2_plane __user 
>>> **)>m.planes)))
>>> +   if (get_user(uplane, >m.planes))
>>> return -EFAULT;
>>> if (get_user(p, >m.planes))
>>> return -EFAULT;
>>> uplane32 = compat_ptr(p);
>>>  
>>> while (num_planes--) {
>>> -   ret = put_v4l2_plane32(uplane, uplane32, memory);
>>> +   ret = put_v4l2_plane32((void __user *)uplane, uplane32, 
>>> memory);
>>> if (ret)
>>> return ret;
>>> ++uplane;
>>> @@ -675,7 +674,7 @@ static int get_v4l2_framebuffer32(struct 
>>> v4l2_framebuffer __user *kp,
>>>  
>>> if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
>>>

Re: [PATCH v7] media: platform: Renesas IMR driver

[Sergei Shtylyov]

On 04/16/2018 04:27 PM, Geert Uytterhoeven wrote:

>> The image renderer, or the distortion correction engine, is a drawing
>> processor with a simple instruction system capable of referencing video
>> capture data or data in an external memory as the 2D texture data and
>> performing texture mapping and drawing with respect to any shape that is
>> split into triangular objects.
>>
>> This V4L2 memory-to-memory device driver only supports image renderer light
>> extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
>> can be added later...
>>
>> Based on the original patch by Konstantin Kozhevnikov.
>>
>> Signed-off-by: Konstantin Kozhevnikov 
>> 
>> Signed-off-by: Sergei Shtylyov 
>> Acked-by: Rob Herring 
> 
>>  Documentation/devicetree/bindings/media/rcar_imr.txt |   27
>>  Documentation/media/v4l-drivers/index.rst|1
>>  Documentation/media/v4l-drivers/rcar_imr.rst |  372 +++
>>  drivers/media/platform/Kconfig   |   13
>>  drivers/media/platform/Makefile  |1
>>  drivers/media/platform/rcar_imr.c| 1832 
>> +++
>>  include/uapi/linux/rcar_imr.h|  182 +
>>  7 files changed, 2428 insertions(+)
> 
> What's the status of this patch?

   Changes requested, and I'm still having no bandwidth to make them... 

> The compatible value "renesas,r8a7796-imr-lx4" has been in use since v4.14.

   That's because the SoC bindings are unlikely to change...

> Thanks!
> 
> Gr{oetje,eeting}s,
> 
> Geert

MBR, Sergei

[PATCH] media: v4l2-compat-ioctl32: better name userspace pointers

[Mauro Carvalho Chehab]

In the past, "up" were an acronym for "user pointer" and "kp" for
"kernel pointer". However, since a1dfb4c48cc1 ("media:
v4l2-compat-ioctl32.c: refactor compat ioctl32 logic"), both
are now __user pointers.

So, the usage of "kp" is really misleading there. So, rename
both to just "p32" and "p64" everywhere it occurs, in order to
make peace with this file's namespace.

There are two exceptions to "up/kp" nomenclature: at
alloc_userspace() and at do_video_ioctl().

There, a new userspace pointer were allocated, in order to store
the 64 bits version of the ioctl. Those were called as "up_native",
with is, IMHO, an even worse name, as "native" could mislead of
being the arguments that were filled from userspace. I almost
renamed it to just "p64", but, after thinking more about that,
it sounded better to call it as "new_p64", as this makes clearer
that this is the data structure that was allocated inside this
file in order to be used to pass/retrieve data when calling the
64-bit ready file->f_op->unlocked_ioctl() function.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 578 +-
 1 file changed, 289 insertions(+), 289 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 5c3408bdfd89..064e4a2bdba3 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -56,8 +56,8 @@ struct v4l2_window32 {
__u8global_alpha;
 };
 
-static int get_v4l2_window32(struct v4l2_window __user *kp,
-struct v4l2_window32 __user *up,
+static int get_v4l2_window32(struct v4l2_window __user *p64,
+struct v4l2_window32 __user *p32,
 void __user *aux_buf, u32 aux_space)
 {
struct v4l2_clip32 __user *uclips;
@@ -65,26 +65,26 @@ static int get_v4l2_window32(struct v4l2_window __user *kp,
compat_caddr_t p;
u32 clipcount;
 
-   if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
-   copy_in_user(>w, >w, sizeof(up->w)) ||
-   assign_in_user(>field, >field) ||
-   assign_in_user(>chromakey, >chromakey) ||
-   assign_in_user(>global_alpha, >global_alpha) ||
-   get_user(clipcount, >clipcount) ||
-   put_user(clipcount, >clipcount))
+   if (!access_ok(VERIFY_READ, p32, sizeof(*p32)) ||
+   copy_in_user(>w, >w, sizeof(p32->w)) ||
+   assign_in_user(>field, >field) ||
+   assign_in_user(>chromakey, >chromakey) ||
+   assign_in_user(>global_alpha, >global_alpha) ||
+   get_user(clipcount, >clipcount) ||
+   put_user(clipcount, >clipcount))
return -EFAULT;
if (clipcount > 2048)
return -EINVAL;
if (!clipcount)
-   return put_user(NULL, >clips);
+   return put_user(NULL, >clips);
 
-   if (get_user(p, >clips))
+   if (get_user(p, >clips))
return -EFAULT;
uclips = compat_ptr(p);
if (aux_space < clipcount * sizeof(*kclips))
return -EFAULT;
kclips = aux_buf;
-   if (put_user(kclips, >clips))
+   if (put_user(kclips, >clips))
return -EFAULT;
 
while (clipcount--) {
@@ -98,27 +98,27 @@ static int get_v4l2_window32(struct v4l2_window __user *kp,
return 0;
 }
 
-static int put_v4l2_window32(struct v4l2_window __user *kp,
-struct v4l2_window32 __user *up)
+static int put_v4l2_window32(struct v4l2_window __user *p64,
+struct v4l2_window32 __user *p32)
 {
struct v4l2_clip __user *kclips;
struct v4l2_clip32 __user *uclips;
compat_caddr_t p;
u32 clipcount;
 
-   if (copy_in_user(>w, >w, sizeof(kp->w)) ||
-   assign_in_user(>field, >field) ||
-   assign_in_user(>chromakey, >chromakey) ||
-   assign_in_user(>global_alpha, >global_alpha) ||
-   get_user(clipcount, >clipcount) ||
-   put_user(clipcount, >clipcount))
+   if (copy_in_user(>w, >w, sizeof(p64->w)) ||
+   assign_in_user(>field, >field) ||
+   assign_in_user(>chromakey, >chromakey) ||
+   assign_in_user(>global_alpha, >global_alpha) ||
+   get_user(clipcount, >clipcount) ||
+   put_user(clipcount, >clipcount))
return -EFAULT;
if (!clipcount)
return 0;
 
-   if (get_user(kclips, >clips))
+   if (get_user(kclips, >clips))
return -EFAULT;
-   if (get_user(p, >clips))
+   if (get_user(p, >clips))
return -EFAULT;
uclips = compat_ptr(p);
while (clipcount--) {
@@ -161,11 +161,11 @@ struct v4l2_create_buffers32 {
__u32   reserved[8];
 };
 
-static int __bufsize_v4l2_format(struct v4l2_format32 

[GIT PULL FOR v4.18] rc changes

[Sean Young]

Hi Mauro,

These patches include the low latency changes, which do make IR more
responsive. These patches could breaks things in subtle ways, so it
would be great to have these changes in early in the cycle.

Thanks,
Sean

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the Git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.18a

for you to fetch changes up to e3313098d94c3e6df414e72732bdb5ae9f581185:

  media: rc: mtk-cir: use of_device_get_match_data() (2018-04-16 14:37:52 +0100)


Andi Shyti (1):
  media: rc: ir-spi: update Andi's e-mail

Ryder Lee (1):
  media: rc: mtk-cir: use of_device_get_match_data()

Sean Young (11):
  media: rc: report receiver and transmitter type on device register
  media: rc: set timeout to smallest value required by enabled protocols
  media: rc: add ioctl to get the current timeout
  media: rc: per-protocol repeat period and minimum keyup timer
  media: rc: mce_kbd decoder: low timeout values cause double keydowns
  media: rc: mce_kbd protocol encodes two scancodes
  media: rc: mce_kbd decoder: fix stuck keys
  media: rc: mce_kbd decoder: remove superfluous call to input_sync
  media: rc: mce_kbd decoder: fix race condition
  media: rc: mceusb: allow the timeout to be configurable
  media: cx88: enable IR transmitter on HVR-1300

 Documentation/media/uapi/rc/lirc-dev-intro.rst |  2 +-
 Documentation/media/uapi/rc/lirc-func.rst  |  1 +
 .../media/uapi/rc/lirc-set-rec-timeout.rst | 14 +++--
 drivers/media/cec/cec-core.c   |  2 +-
 drivers/media/pci/cx88/cx88-input.c|  5 +-
 drivers/media/rc/ir-imon-decoder.c |  1 +
 drivers/media/rc/ir-jvc-decoder.c  |  1 +
 drivers/media/rc/ir-mce_kbd-decoder.c  | 58 +++---
 drivers/media/rc/ir-nec-decoder.c  |  1 +
 drivers/media/rc/ir-rc5-decoder.c  |  1 +
 drivers/media/rc/ir-rc6-decoder.c  |  1 +
 drivers/media/rc/ir-sanyo-decoder.c|  1 +
 drivers/media/rc/ir-sharp-decoder.c|  1 +
 drivers/media/rc/ir-sony-decoder.c |  1 +
 drivers/media/rc/ir-spi.c  |  4 +-
 drivers/media/rc/ir-xmp-decoder.c  |  1 +
 drivers/media/rc/lirc_dev.c| 31 +-
 drivers/media/rc/mceusb.c  | 22 +++
 drivers/media/rc/mtk-cir.c |  4 +-
 drivers/media/rc/rc-core-priv.h|  3 +
 drivers/media/rc/rc-ir-raw.c   | 31 +-
 drivers/media/rc/rc-main.c | 68 +++---
 include/uapi/linux/lirc.h  |  6 ++
 23 files changed, 188 insertions(+), 72 deletions(-)

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

[Andy Yeh]

From: Jason Chen 

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

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


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

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

Re: [PATCHv2 17/17] media: v4l2-compat-ioctl32: fix several __user annotations

[Mauro Carvalho Chehab]

Em Mon, 16 Apr 2018 14:03:45 +0200
Hans Verkuil  escreveu:

> On 04/13/2018 08:07 PM, Mauro Carvalho Chehab wrote:
> > Smatch report several issues with bad __user annotations:
> > 
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect 
> > type in argument 1 (different address spaces)
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:expected void 
> > [noderef] *uptr
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:got void 
> > *
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: warning: incorrect 
> > type in argument 1 (different address spaces)
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:expected void 
> > const volatile [noderef] *
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:got struct 
> > v4l2_plane [noderef] **
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: warning: incorrect 
> > type in argument 1 (different address spaces)
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:expected void 
> > [noderef] *uptr
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:got void 
> > *[assigned] base
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: warning: incorrect 
> > type in assignment (different address spaces)
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:expected struct 
> > v4l2_ext_control [noderef] *kcontrols
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:got struct 
> > v4l2_ext_control *
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: warning: incorrect 
> > type in assignment (different address spaces)
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:expected 
> > unsigned char [usertype] *__pu_val
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:got void 
> > [noderef] *
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: warning: incorrect 
> > type in argument 1 (different address spaces)
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:expected void 
> > [noderef] *uptr
> >   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:got void 
> > *[assigned] edid
> > 
> > Fix them.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 32 
> > ++-
> >  1 file changed, 17 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> > b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > index d03a44d89649..0b9dfe7dbfe7 100644
> > --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> > @@ -443,8 +443,8 @@ static int put_v4l2_plane32(struct v4l2_plane __user 
> > *up,
> > return -EFAULT;
> > break;
> > case V4L2_MEMORY_USERPTR:
> > -   if (get_user(p, >m.userptr) ||
> > -   put_user((compat_ulong_t)ptr_to_compat((__force void *)p),
> > +   if (get_user(p, >m.userptr)||
> > +   put_user((compat_ulong_t)ptr_to_compat((void __user *)p),
> >  >m.userptr))
> > return -EFAULT;
> > break;
> > @@ -587,7 +587,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
> > *kp,
> > u32 length;
> > enum v4l2_memory memory;
> > struct v4l2_plane32 __user *uplane32;
> > -   struct v4l2_plane __user *uplane;
> > +   struct v4l2_plane *uplane;  
> 
> This needs a comment (either here or before the get_user below). It really is 
> a
> pointer to userspace, but since videodev2.h has it without __user (since it is
> copied to kernel space in v4l2-ioctl.c) we need to define it as a regular 
> pointer
> here and cast it to a __user pointer in the put_v4l2_plane32() call.
> 
> This is not trivially obvious, so a comment would help a lot.



> 
> > compat_caddr_t p;
> > int ret;
> >  
> > @@ -617,15 +617,14 @@ static int put_v4l2_buffer32(struct v4l2_buffer 
> > __user *kp,
> >  
> > if (num_planes == 0)
> > return 0;
> > -
> > -   if (get_user(uplane, ((__force struct v4l2_plane __user 
> > **)>m.planes)))
> > +   if (get_user(uplane, >m.planes))
> > return -EFAULT;
> > if (get_user(p, >m.planes))
> > return -EFAULT;
> > uplane32 = compat_ptr(p);
> >  
> > while (num_planes--) {
> > -   ret = put_v4l2_plane32(uplane, uplane32, memory);
> > +   ret = put_v4l2_plane32((void __user *)uplane, uplane32, 
> > memory);
> > if (ret)
> > return ret;
> > ++uplane;
> > @@ -675,7 +674,7 @@ static int get_v4l2_framebuffer32(struct 
> > v4l2_framebuffer __user *kp,
> >  
> > if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
> > get_user(tmp, >base) ||
> > -   put_user((__force void 

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Mon, Apr 16, 2018 at 2:39 PM, Christoph Hellwig  wrote:
> On Tue, Apr 03, 2018 at 08:08:32PM +0200, Daniel Vetter wrote:
>> I did not mean you should dma_map_sg/page. I just meant that using
>> dma_map_resource to fill only the dma address part of the sg table seems
>> perfectly sufficient.
>
> But that is not how the interface work, especially facing sg_dma_len.
>
>> Assuming you get an sg table that's been mapping by calling dma_map_sg was
>> always a bit a case of bending the abstraction to avoid typing code. The
>> only thing an importer ever should have done is look at the dma addresses
>> in that sg table, nothing else.
>
> The scatterlist is not a very good abstraction unfortunately, but it
> it is spread all over the kernel.  And we do expect that anyone who
> gets passed a scatterlist can use sg_page() or sg_virt() (which calls
> sg_page()) on it.  Your changes would break that, and will cause major
> trouble because of that.
>
> If you want to expose p2p memory returned from dma_map_resource in
> dmabuf do not use scatterlists for this please, but with a new interface
> that explicitly passes a virtual address, a dma address and a length
> and make it very clear that virt_to_page will not work on the virtual
> address.

We've broken that assumption in i915 years ago. Not struct page backed
gpu memory is very real.

Of course we'll never feed such a strange sg table to a driver which
doesn't understand it, but allowing sg_page == NULL works perfectly
fine. At least for gpu drivers.

If that's not acceptable then I guess we could go over the entire tree
and frob all the gpu related code to switch over to a new struct
sg_table_might_not_be_struct_page_backed, including all the other
functions we added over the past few years to iterate over sg tables.
But seems slightly silly, given that sg tables seem to do exactly what
we need.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH v7] media: platform: Renesas IMR driver

[Geert Uytterhoeven]

Hi Sergei,

On Fri, Aug 4, 2017 at 8:03 PM, Sergei Shtylyov
 wrote:
> The image renderer, or the distortion correction engine, is a drawing
> processor with a simple instruction system capable of referencing video
> capture data or data in an external memory as the 2D texture data and
> performing texture mapping and drawing with respect to any shape that is
> split into triangular objects.
>
> This V4L2 memory-to-memory device driver only supports image renderer light
> extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
> can be added later...
>
> Based on the original patch by Konstantin Kozhevnikov.
>
> Signed-off-by: Konstantin Kozhevnikov 
> 
> Signed-off-by: Sergei Shtylyov 
> Acked-by: Rob Herring 

>  Documentation/devicetree/bindings/media/rcar_imr.txt |   27
>  Documentation/media/v4l-drivers/index.rst|1
>  Documentation/media/v4l-drivers/rcar_imr.rst |  372 +++
>  drivers/media/platform/Kconfig   |   13
>  drivers/media/platform/Makefile  |1
>  drivers/media/platform/rcar_imr.c| 1832 
> +++
>  include/uapi/linux/rcar_imr.h|  182 +
>  7 files changed, 2428 insertions(+)

What's the status of this patch?
The compatible value "renesas,r8a7796-imr-lx4" has been in use since v4.14.

Thanks!

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCHv2 4/9] media: add function field to struct media_entity_desc

[Hans Verkuil]

From: Hans Verkuil 

This adds support for 'proper' functions to the existing API.
This information was before only available through the new v2
API, with this change it's available to both.

Yes, the plan is to allow entities to expose multiple functions for
multi-function devices, but we do not support it anywhere so this
is still vaporware.

Signed-off-by: Hans Verkuil 
---
 drivers/media/media-device.c | 1 +
 include/uapi/linux/media.h   | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 7c3ab37c258a..dca1e5a3e0f9 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -115,6 +115,7 @@ static long media_device_enum_entities(struct media_device 
*mdev,
if (ent->name)
strlcpy(entd->name, ent->name, sizeof(entd->name));
entd->type = ent->function;
+   entd->function = ent->function;
entd->revision = 0; /* Unused */
entd->flags = ent->flags;
entd->group_id = 0; /* Unused */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 86c7dcc9cba3..ac08acffdb65 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -146,6 +146,10 @@ struct media_device_info {
 /* OR with the entity id value to find the next entity */
 #define MEDIA_ENT_ID_FLAG_NEXT (1 << 31)
 
+/* Appeared in 4.18.0 */
+#define MEDIA_ENTITY_DESC_HAS_FUNCTION(media_version) \
+   ((media_version) >= 0x00041200)
+
 struct media_entity_desc {
__u32 id;
char name[32];
@@ -155,8 +159,9 @@ struct media_entity_desc {
__u32 group_id;
__u16 pads;
__u16 links;
+   __u32 function;
 
-   __u32 reserved[4];
+   __u32 reserved[3];
 
union {
/* Node specifications */
-- 
2.15.1

[PATCHv2 5/9] media-ioc-enum-entities.rst: document new 'function' field

[Hans Verkuil]

From: Hans Verkuil 

Document the new struct media_entity_desc 'function' field.

Signed-off-by: Hans Verkuil 
---
 .../uapi/mediactl/media-ioc-enum-entities.rst  | 31 +-
 1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst 
b/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst
index 582fda488810..6b0ab65288c6 100644
--- a/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst
+++ b/Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst
@@ -90,6 +90,12 @@ id's until they get an error.
-
-
-  Entity type, see :ref:`media-entity-functions` for details.
+  Deprecated. If possible, use the ``function`` field instead.
+ For backwards compatibility this ``type`` field will only
+ expose functions ``MEDIA_ENT_F_IO_V4L``, ``MEDIA_ENT_F_CAM_SENSOR``,
+ ``MEDIA_ENT_F_FLASH``, ``MEDIA_ENT_F_LENS``, 
``MEDIA_ENT_F_ATV_DECODER``
+ and ``MEDIA_ENT_F_TUNER``. Other functions will be mapped to
+ ``MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN`` or 
``MEDIA_ENT_T_DEVNODE_UNKNOWN``.
 
 -  .. row 4
 
@@ -146,18 +152,31 @@ id's until they get an error.
 
-  __u32
 
-   -  ``reserved[4]``
+   -  ``function``
+
+   -
+   -
+   -  Entity main function, see :ref:`media-entity-functions` for details.
+  Only valid if ``MEDIA_ENTITY_DESC_HAS_FUNCTION(media_version)``
+  returns true. The ``media_version`` is defined in struct
+  :c:type:`media_device_info`.
+
+-  .. row 10
+
+   -  __u32
+
+   -  ``reserved[3]``
 
-
-
-  Reserved for future extensions. Drivers and applications must set
   the array to zero.
 
--  .. row 10
+-  .. row 11
 
-  union
 
--  .. row 11
+-  .. row 12
 
-
-  struct
@@ -167,7 +186,7 @@ id's until they get an error.
-
-  Valid for (sub-)devices that create a single device node.
 
--  .. row 12
+-  .. row 13
 
-
-
@@ -177,7 +196,7 @@ id's until they get an error.
 
-  Device node major number.
 
--  .. row 13
+-  .. row 14
 
-
-
@@ -187,7 +206,7 @@ id's until they get an error.
 
-  Device node minor number.
 
--  .. row 14
+-  .. row 15
 
-
-  __u8
-- 
2.15.1

[PATCHv2 6/9] media: add 'index' to struct media_v2_pad

[Hans Verkuil]

From: Hans Verkuil 

The v2 pad structure never exposed the pad index, which made it impossible
to call the MEDIA_IOC_SETUP_LINK ioctl, which needs that information.

It is really trivial to just expose this information, so implement this.

Signed-off-by: Hans Verkuil 
---
 drivers/media/media-device.c | 1 +
 include/uapi/linux/media.h   | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index dca1e5a3e0f9..73ffea3e81c9 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -331,6 +331,7 @@ static long media_device_get_topology(struct media_device 
*mdev,
kpad.id = pad->graph_obj.id;
kpad.entity_id = pad->entity->graph_obj.id;
kpad.flags = pad->flags;
+   kpad.index = pad->index;
 
if (copy_to_user(upad, , sizeof(kpad)))
ret = -EFAULT;
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index ac08acffdb65..15f7f432f808 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -310,11 +310,16 @@ struct media_v2_interface {
};
 } __attribute__ ((packed));
 
+/* Appeared in 4.18.0 */
+#define MEDIA_V2_PAD_HAS_INDEX(media_version) \
+   ((media_version) >= 0x00041200)
+
 struct media_v2_pad {
__u32 id;
__u32 entity_id;
__u32 flags;
-   __u32 reserved[5];
+   __u32 index;
+   __u32 reserved[4];
 } __attribute__ ((packed));
 
 struct media_v2_link {
-- 
2.15.1

[PATCHv2 8/9] media: add flags field to struct media_v2_entity

[Hans Verkuil]

From: Hans Verkuil 

The v2 entity structure never exposed the entity flags, which made it
impossible to detect connector or default entities.

It is really trivial to just expose this information, so implement this.

Signed-off-by: Hans Verkuil 
---
 drivers/media/media-device.c | 1 +
 include/uapi/linux/media.h   | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 73ffea3e81c9..00f7ce74e42a 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -266,6 +266,7 @@ static long media_device_get_topology(struct media_device 
*mdev,
memset(, 0, sizeof(kentity));
kentity.id = entity->graph_obj.id;
kentity.function = entity->function;
+   kentity.flags = entity->flags;
strlcpy(kentity.name, entity->name,
sizeof(kentity.name));
 
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 15f7f432f808..056100ef25cc 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -285,11 +285,16 @@ struct media_links_enum {
  * MC next gen API definitions
  */
 
+/* Appeared in 4.18.0 */
+#define MEDIA_V2_ENTITY_HAS_FLAGS(media_version) \
+   ((media_version) >= 0x00041200)
+
 struct media_v2_entity {
__u32 id;
char name[64];
__u32 function; /* Main function of the entity */
-   __u32 reserved[6];
+   __u32 flags;
+   __u32 reserved[5];
 } __attribute__ ((packed));
 
 /* Should match the specific fields at media_intf_devnode */
-- 
2.15.1

[PATCHv2 9/9] media-ioc-g-topology.rst: document new 'flags' field

[Hans Verkuil]

From: Hans Verkuil 

Document the new struct media_v2_entity 'flags' field.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/mediactl/media-ioc-g-topology.rst | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst 
b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
index 459818c3490c..6521ab7c9b58 100644
--- a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
+++ b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
@@ -211,7 +211,18 @@ desired arrays with the media graph elements.
 
-  __u32
 
-   -  ``reserved``\ [6]
+   -  ``flags``
+
+   -  Entity flags, see :ref:`media-entity-flag` for details.
+  Only valid if ``MEDIA_V2_ENTITY_HAS_FLAGS(media_version)``
+  returns true. The ``media_version`` is defined in struct
+ :c:type:`media_device_info`.
+
+-  .. row 5
+
+   -  __u32
+
+   -  ``reserved``\ [5]
 
-  Reserved for future extensions. Drivers and applications must set
  this array to zero.
-- 
2.15.1

[PATCHv2 3/9] media.h: remove __NEED_MEDIA_LEGACY_API

[Hans Verkuil]

From: Hans Verkuil 

The __NEED_MEDIA_LEGACY_API define is 1) ugly and 2) dangerous
since it is all too easy for drivers to define it to get hold of
legacy defines. Instead just define what we need in media-device.c
which is the only place where we need the legacy define
(MEDIA_ENT_T_DEVNODE_UNKNOWN).

Signed-off-by: Hans Verkuil 
---
 drivers/media/media-device.c | 13 ++---
 include/uapi/linux/media.h   |  2 +-
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 35e81f7c0d2f..7c3ab37c258a 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -16,9 +16,6 @@
  * GNU General Public License for more details.
  */
 
-/* We need to access legacy defines from linux/media.h */
-#define __NEED_MEDIA_LEGACY_API
-
 #include 
 #include 
 #include 
@@ -35,6 +32,16 @@
 
 #ifdef CONFIG_MEDIA_CONTROLLER
 
+/*
+ * Legacy defines from linux/media.h. This is the only place we need this
+ * so we just define it here. The media.h header doesn't expose it to the
+ * kernel to prevent it from being used by drivers, but here (and only here!)
+ * we need it to handle the legacy behavior.
+ */
+#define MEDIA_ENT_SUBTYPE_MASK 0x
+#define MEDIA_ENT_T_DEVNODE_UNKNOWN(MEDIA_ENT_F_OLD_BASE | \
+MEDIA_ENT_SUBTYPE_MASK)
+
 /* 
-
  * Userspace API
  */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index c7e9a5cba24e..86c7dcc9cba3 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -348,7 +348,7 @@ struct media_v2_topology {
 #define MEDIA_IOC_SETUP_LINK   _IOWR('|', 0x03, struct media_link_desc)
 #define MEDIA_IOC_G_TOPOLOGY   _IOWR('|', 0x04, struct media_v2_topology)
 
-#if !defined(__KERNEL__) || defined(__NEED_MEDIA_LEGACY_API)
+#ifndef __KERNEL__
 
 /*
  * Legacy symbols used to avoid userspace compilation breakages.
-- 
2.15.1

[PATCHv2 1/9] v4l2-mediabus.h: add hsv_enc

[Hans Verkuil]

From: Hans Verkuil 

Just like struct v4l2_pix_format add a hsv_enc field to describe
the HSV encoding. It is in a union with the ycbcr_enc, since it
is one or the other.

Signed-off-by: Hans Verkuil 
---
 include/uapi/linux/v4l2-mediabus.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/v4l2-mediabus.h 
b/include/uapi/linux/v4l2-mediabus.h
index 123a231001a8..52fd6cc9d491 100644
--- a/include/uapi/linux/v4l2-mediabus.h
+++ b/include/uapi/linux/v4l2-mediabus.h
@@ -24,6 +24,7 @@
  * @field: used interlacing type (from enum v4l2_field)
  * @colorspace:colorspace of the data (from enum v4l2_colorspace)
  * @ycbcr_enc: YCbCr encoding of the data (from enum v4l2_ycbcr_encoding)
+ * @hsv_enc:   HSV encoding of the data (from enum v4l2_hsv_encoding)
  * @quantization: quantization of the data (from enum v4l2_quantization)
  * @xfer_func:  transfer function of the data (from enum v4l2_xfer_func)
  */
@@ -33,7 +34,12 @@ struct v4l2_mbus_framefmt {
__u32   code;
__u32   field;
__u32   colorspace;
-   __u16   ycbcr_enc;
+   union {
+   /* enum v4l2_ycbcr_encoding */
+   __u16   ycbcr_enc;
+   /* enum v4l2_hsv_encoding */
+   __u16   hsv_enc;
+   };
__u16   quantization;
__u16   xfer_func;
__u16   reserved[11];
-- 
2.15.1

[PATCHv2 7/9] media-ioc-g-topology.rst: document new 'index' field

[Hans Verkuil]

From: Hans Verkuil 

Document the new struct media_v2_pad 'index' field.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/mediactl/media-ioc-g-topology.rst | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst 
b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
index c4055ddf070a..459818c3490c 100644
--- a/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
+++ b/Documentation/media/uapi/mediactl/media-ioc-g-topology.rst
@@ -334,7 +334,17 @@ desired arrays with the media graph elements.
 
-  __u32
 
-   -  ``reserved``\ [5]
+   -  ``index``
+
+   -  0-based pad index. Only valid if 
``MEDIA_V2_PAD_HAS_INDEX(media_version)``
+  returns true. The ``media_version`` is defined in struct
+ :c:type:`media_device_info`.
+
+-  .. row 5
+
+   -  __u32
+
+   -  ``reserved``\ [4]
 
-  Reserved for future extensions. Drivers and applications must set
  this array to zero.
-- 
2.15.1

[PATCHv2 2/9] subdev-formats.rst: fix incorrect types

[Hans Verkuil]

From: Hans Verkuil 

The ycbcr_enc, quantization and xfer_func fields are __u16 and not enums.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/v4l/subdev-formats.rst | 27 +++--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index 9fcabe7f9367..a3f30853f8a8 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -37,19 +37,34 @@ Media Bus Formats
   - Image colorspace, from enum
:c:type:`v4l2_colorspace`. See
:ref:`colorspaces` for details.
-* - enum :c:type:`v4l2_ycbcr_encoding`
+* - union {
+  - (anonymous)
+  -
+* - __u16
   - ``ycbcr_enc``
-  - This information supplements the ``colorspace`` and must be set by
+  - Y'CbCr encoding, from enum :c:type:`v4l2_ycbcr_encoding`.
+This information supplements the ``colorspace`` and must be set by
+   the driver for capture streams and by the application for output
+   streams, see :ref:`colorspaces`.
+* - __u16
+  - ``hsv_enc``
+  - HSV encoding, from enum :c:type:`v4l2_hsv_encoding`.
+This information supplements the ``colorspace`` and must be set by
the driver for capture streams and by the application for output
streams, see :ref:`colorspaces`.
-* - enum :c:type:`v4l2_quantization`
+* - }
+  -
+  -
+* - __u16
   - ``quantization``
-  - This information supplements the ``colorspace`` and must be set by
+  - Quantization range, from enum :c:type:`v4l2_quantization`.
+This information supplements the ``colorspace`` and must be set by
the driver for capture streams and by the application for output
streams, see :ref:`colorspaces`.
-* - enum :c:type:`v4l2_xfer_func`
+* - __u16
   - ``xfer_func``
-  - This information supplements the ``colorspace`` and must be set by
+  - Transfer function, from enum :c:type:`v4l2_xfer_func`.
+This information supplements the ``colorspace`` and must be set by
the driver for capture streams and by the application for output
streams, see :ref:`colorspaces`.
 * - __u16
-- 
2.15.1

[PATCHv2 0/9] media/mc: fix inconsistencies

[Hans Verkuil]

From: Hans Verkuil 

This patch series is a follow-up to these two v1 series:

https://www.mail-archive.com/linux-media@vger.kernel.org/msg127943.html
https://www.mail-archive.com/linux-media@vger.kernel.org/msg127963.html

Some of those patches have been merged for 4.17, so this v2 contains
the remainder and has been updated/rebased for 4.18.

The first two patches add the missing hsv_enc to struct v4l2_mbus_framefmt.
The next patch removes the ugly and IMHO dangerous __NEED_MEDIA_LEGACY_API
define from media.h.

The remaining 6 patches add missing features to the 'old' and 'new' media
controller API. Afterwards the two APIs are the same, except that the new
API exposes interfaces (but that's reasonable since it is a superset of
the 'old' API).

While I am calling it 'old' and 'new' API, there is no reason why applications
can't just pick which API to use, just like applications can choose whether
to use QUERYCTRL or QUERY_EXT_CTRL. The latter ioctl is only required if you
need the new functionality that it gives you.

The one thing I did not add to the 'old' API is to expose the pad/link IDs.
While there is room for it in the structs, there is no API that uses those
IDs at the moment, and I think it would be confusing.

Link IDs would most likely be used with a future S_TOPOLOGY ioctl and not
with the old SETUP_LINK ioctl.

Regards,

Hans

Hans Verkuil (9):
  v4l2-mediabus.h: add hsv_enc
  subdev-formats.rst: fix incorrect types
  media.h: remove __NEED_MEDIA_LEGACY_API
  media: add function field to struct media_entity_desc
  media-ioc-enum-entities.rst: document new 'function' field
  media: add 'index' to struct media_v2_pad
  media-ioc-g-topology.rst: document new 'index' field
  media: add flags field to struct media_v2_entity
  media-ioc-g-topology.rst: document new 'flags' field

 .../uapi/mediactl/media-ioc-enum-entities.rst  | 31 +-
 .../media/uapi/mediactl/media-ioc-g-topology.rst   | 25 +++--
 Documentation/media/uapi/v4l/subdev-formats.rst| 27 ++-
 drivers/media/media-device.c   | 16 ---
 include/uapi/linux/media.h | 23 +---
 include/uapi/linux/v4l2-mediabus.h |  8 +-
 6 files changed, 108 insertions(+), 22 deletions(-)

-- 
2.15.1

Re: [PATCH v3 1/2] media: imx-media-csi: Fix inconsistent IS_ERR and PTR_ERR

[Philipp Zabel]

Hi,

On Sat, 2018-03-03 at 09:56 -0300, Fabio Estevam wrote:
> From: Gustavo A. R. Silva 
> 
> Fix inconsistent IS_ERR and PTR_ERR in imx_csi_probe.
> The proper pointer to be passed as argument is pinctrl
> instead of priv->vdev.
> 
> This issue was detected with the help of Coccinelle.
> 
> Fixes: 52e17089d185 ("media: imx: Don't initialize vars that won't be used")
> Signed-off-by: Gustavo A. R. Silva 
> Signed-off-by: Fabio Estevam 
> Acked-by: Philipp Zabel 
> ---
> Changes since v2:
> - None
> Changes since v1:
> - None
> 
>  drivers/staging/media/imx/imx-media-csi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/imx/imx-media-csi.c 
> b/drivers/staging/media/imx/imx-media-csi.c
> index 5a195f8..4f290a0 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -1798,7 +1798,7 @@ static int imx_csi_probe(struct platform_device *pdev)
>   priv->dev->of_node = pdata->of_node;
>   pinctrl = devm_pinctrl_get_select_default(priv->dev);
>   if (IS_ERR(pinctrl)) {
> - ret = PTR_ERR(priv->vdev);
> + ret = PTR_ERR(pinctrl);

The second patch is applied now, but this part is still missing in
v4.17-rc1, causing the CSI subdev probe to fail:

  imx-ipuv3-csi: probe of imx-ipuv3-csi.0 failed with error -1369528304
  imx-ipuv3-csi: probe of imx-ipuv3-csi.1 failed with error -1369528304
  imx-ipuv3-csi: probe of imx-ipuv3-csi.5 failed with error -1369528304
  imx-ipuv3-csi: probe of imx-ipuv3-csi.6 failed with error -1369528304

regards
Philipp

Re: OV5640 with 12MHz xclk

[Philipp Zabel]

On Sun, 2018-04-15 at 18:39 -0700, Samuel Bobrowicz wrote:
> Can anyone verify if the OV5640 driver works with input clocks other
> than the typical 24MHz? The driver suggests anything from 6MHz-24MHz
> is acceptable, but I am running into issues while bringing up a module
> that uses a 12MHz oscillator. I'd expect that different xclk's would
> necessitate different register settings for the various resolutions
> (PLL settings, PCLK width, etc.), however the driver does not seem to
> modify nearly enough based on the frequency of xclk.
> 
> Sam
> 

Have you seen Maxime's recent "media: ov5640: Misc cleanup and
improvements" series, especially patch 08/12 ("media: ov5640: Adjust the
clock based on the expected rate")? That seems to be something you'd
need.

regards
Philipp

Re: [PATCH v13 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[jacopo mondi]

Hi Niklas,

On Mon, Apr 16, 2018 at 01:16:35AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your feedback.
>
> Comments I have snipped out from this reply are addressed, thanks for
> bringing them to my attention!
>
> On 2018-04-05 11:10:01 +0200, Jacopo Mondi wrote:
>
> [snip]
>
> > > +static int rcar_csi2_wait_phy_start(struct rcar_csi2 *priv)
> > > +{
> > > + int timeout;
> > > +
> > > + /* Wait for the clock and data lanes to enter LP-11 state. */
> > > + for (timeout = 100; timeout > 0; timeout--) {
> > > + const u32 lane_mask = (1 << priv->lanes) - 1;
> > > +
> > > + if ((rcar_csi2_read(priv, PHCLM_REG) & 1) == 1 &&
> >
> > Nitpicking:
> > if ((rcar_csi2_read(priv, PHCLM_REG) & 0x01) &&
> >
> > Don't you prefer to provide defines also for bit fields instead of
> > using magic values? In this case something like
> > PHCLM_REG_STOPSTATE_CLK would do.
>
> Thanks addressed per your and Kieran's suggestion.
>
> >
> > Also, from tables 25.[17-20] it seems to me that for H3 and V3 you
> > have to set INSTATE to an hardcoded value after having validated PHDLM.
> > Maybe it is not necessary, just pointing it out.
>
> I assume you mean Figures 25.[17-20] and not Tables as the last table in
> chapter 25 is Table 25.15 and the register in question is INTSTATE :-)
> And to clarify this is documented for H3 which this driver supports and
> V3H and M3-N which this driver dose not yet support. And the constant
> you are to set it to is ULPS_START | UPLS_END.

Yes, Figures, not Tables, sorry about this.

>
> This is a good catch as this was introduced in a later version of the
> datasheet and the current code where the ULPS_START | UPLS_END is set
> before confirming LP-11 have kept on working. Check the
> priv->info->clear_ulps usage in rcar_csi2_start(). I do think it's
> better to follow the flow-chart in the new datasheet so I will move this
> to the end of rcar_csi2_start() to reflect that (provided that the end
> result still works :-) Thanks for pointing this out!
>

I see...

Actually, I don't see M3-N in the manual version I'm looking at.
Anyway, I just hope this per-soc specificities are limited.

> [snip]
>
> > > +static int rcar_csi2_start(struct rcar_csi2 *priv)
> > > +{
> > > + const struct rcar_csi2_format *format;
> > > + u32 phycnt, phypll, vcdt = 0, vcdt2 = 0;
> > > + unsigned int i;
> > > + int ret;
> > > +
> > > + dev_dbg(priv->dev, "Input size (%ux%u%c)\n",
> > > + priv->mf.width, priv->mf.height,
> > > + priv->mf.field == V4L2_FIELD_NONE ? 'p' : 'i');
> > > +
> > > + /* Code is validated in set_fmt */
> > > + format = rcar_csi2_code_to_fmt(priv->mf.code);
> > > +
> > > + /*
> > > +  * Enable all Virtual Channels
> > > +  *
> > > +  * NOTE: It's not possible to get individual datatype for each
> > > +  *   source virtual channel. Once this is possible in V4L2
> > > +  *   it should be used here.
> > > +  */
> > > + for (i = 0; i < 4; i++) {
> > > + u32 vcdt_part;
> > > +
> > > + vcdt_part = VCDT_SEL_VC(i) | VCDT_VCDTN_EN | VCDT_SEL_DTN_ON |
> > > + VCDT_SEL_DT(format->datatype);
> > > +
> > > + /* Store in correct reg and offset */
> > > + if (i < 2)
> > > + vcdt |= vcdt_part << ((i % 2) * 16);
> > > + else
> > > + vcdt2 |= vcdt_part << ((i % 2) * 16);
> > > + }
> > > +
> > > + switch (priv->lanes) {
> > > + case 1:
> > > + phycnt = PHYCNT_ENABLECLK | PHYCNT_ENABLE_0;
> > > + break;
> > > + case 2:
> > > + phycnt = PHYCNT_ENABLECLK | PHYCNT_ENABLE_1 | PHYCNT_ENABLE_0;
> > > + break;
> > > + case 4:
> > > + phycnt = PHYCNT_ENABLECLK | PHYCNT_ENABLE_3 | PHYCNT_ENABLE_2 |
> > > + PHYCNT_ENABLE_1 | PHYCNT_ENABLE_0;
> > > + break;
> >
> > Even simpler this could be written as
> >
> > phycnt = PHYCNT_ENABLECLK | (1 << priv->lanes) - 1;
>
> Fixed per your and Geert's suggestion.
>
> >
> > > + default:
> > > + return -EINVAL;
> >
> > Can this happen? You have validated priv->lanes already when parsing
> > DT
>
> This can't happen but I like to have a catch all in any case, but since
> I took yours and Geert's suggestion above this issue goes away :-)
>

Does gcc complains about the missing default case?

> >
> > > + }
> > > +
> > > + ret = rcar_csi2_calc_phypll(priv, format->bpp, );
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /* Clear Ultra Low Power interrupt */
> > > + if (priv->info->clear_ulps)
> > > + rcar_csi2_write(priv, INTSTATE_REG,
> > > + INTSTATE_INT_ULPS_START |
> > > + INTSTATE_INT_ULPS_END);
> > > +
> > > + /* Init */
> > > + rcar_csi2_write(priv, TREF_REG, TREF_TREF);
> > > + rcar_csi2_reset(priv);
> > > + rcar_csi2_write(priv, PHTC_REG, 0);
> > > +
> > > + /* Configure */
> > > + rcar_csi2_write(priv, FLD_REG, FLD_FLD_NUM(2) | FLD_FLD_EN4 |
> > > + FLD_FLD_EN3 | 

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Tue, Apr 03, 2018 at 08:08:32PM +0200, Daniel Vetter wrote:
> I did not mean you should dma_map_sg/page. I just meant that using
> dma_map_resource to fill only the dma address part of the sg table seems
> perfectly sufficient.

But that is not how the interface work, especially facing sg_dma_len.

> Assuming you get an sg table that's been mapping by calling dma_map_sg was
> always a bit a case of bending the abstraction to avoid typing code. The
> only thing an importer ever should have done is look at the dma addresses
> in that sg table, nothing else.

The scatterlist is not a very good abstraction unfortunately, but it
it is spread all over the kernel.  And we do expect that anyone who
gets passed a scatterlist can use sg_page() or sg_virt() (which calls
sg_page()) on it.  Your changes would break that, and will cause major
trouble because of that.

If you want to expose p2p memory returned from dma_map_resource in
dmabuf do not use scatterlists for this please, but with a new interface
that explicitly passes a virtual address, a dma address and a length
and make it very clear that virt_to_page will not work on the virtual
address.

[PATCH v2 09/12] media: ov5640: Compute the clock rate at runtime

[Maxime Ripard]

The clock rate, while hardcoded until now, is actually a function of the
resolution, framerate and bytes per pixel. Now that we have an algorithm to
adjust our clock rate, we can select it dynamically when we change the
mode.

This changes a bit the clock rate being used, with the following effect:

+--+--+--+--+-+-++---+
| Hact | Vact | Htot | Vtot | FPS | Hardcoded clock | Computed clock | 
Deviation |
+--+--+--+--+-+-++---+
|  640 |  480 | 1896 | 1080 |  15 |5600 |   61430400 | 8.84 %   
 |
|  640 |  480 | 1896 | 1080 |  30 |   11200 |  122860800 | 8.84 %   
 |
| 1024 |  768 | 1896 | 1080 |  15 |5600 |   61430400 | 8.84 %   
 |
| 1024 |  768 | 1896 | 1080 |  30 |   11200 |  122860800 | 8.84 %   
 |
|  320 |  240 | 1896 |  984 |  15 |5600 |   55969920 | 0.05 %   
 |
|  320 |  240 | 1896 |  984 |  30 |   11200 |  111939840 | 0.05 %   
 |
|  176 |  144 | 1896 |  984 |  15 |5600 |   55969920 | 0.05 %   
 |
|  176 |  144 | 1896 |  984 |  30 |   11200 |  111939840 | 0.05 %   
 |
|  720 |  480 | 1896 |  984 |  15 |5600 |   55969920 | 0.05 %   
 |
|  720 |  480 | 1896 |  984 |  30 |   11200 |  111939840 | 0.05 %   
 |
|  720 |  576 | 1896 |  984 |  15 |5600 |   55969920 | 0.05 %   
 |
|  720 |  576 | 1896 |  984 |  30 |   11200 |  111939840 | 0.05 %   
 |
| 1280 |  720 | 1892 |  740 |  15 |4200 |   42002400 | 0.01 %   
 |
| 1280 |  720 | 1892 |  740 |  30 |8400 |   84004800 | 0.01 %   
 |
| 1920 | 1080 | 2500 | 1120 |  15 |8400 |   8400 | 0.00 %   
 |
| 1920 | 1080 | 2500 | 1120 |  30 |   16800 |  16800 | 0.00 %   
 |
| 2592 | 1944 | 2844 | 1944 |  15 |8400 |  165862080 | 49.36 %  
 |
+--+--+--+--+-+-++---+

Only the 640x480, 1024x768 and 2592x1944 modes are significantly affected
by the new formula.

In this case, 640x480 and 1024x768 are actually fixed by this driver.
Indeed, the sensor was sending data at, for example, 27.33fps instead of
30fps. This is -9%, which is roughly what we're seeing in the array.
Testing these modes with the new clock setup actually fix that error, and
data are now sent at around 30fps.

2592x1944, on the other hand, is probably due to the fact that this mode
can only be used using MIPI-CSI2, in a two lane mode. This would have to be
tested though.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 41 --
 1 file changed, 17 insertions(+), 24 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 8db4fc0f031c..62938e9dabc5 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -174,7 +174,6 @@ struct ov5640_mode_info {
u32 htot;
u32 vact;
u32 vtot;
-   u32 clock;
const struct reg_value *reg_data;
u32 reg_data_size;
 };
@@ -696,7 +695,6 @@ static const struct reg_value 
ov5640_setting_15fps_QSXGA_2592_1944[] = {
 /* power-on sensor init reg table */
 static const struct ov5640_mode_info ov5640_mode_init_data = {
0, SUBSAMPLING, 640, 1896, 480, 984,
-   11200,
ov5640_init_setting_30fps_VGA,
ARRAY_SIZE(ov5640_init_setting_30fps_VGA),
 };
@@ -706,91 +704,74 @@ ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] 
= {
{
{OV5640_MODE_QCIF_176_144, SUBSAMPLING,
 176, 1896, 144, 984,
-5600,
 ov5640_setting_15fps_QCIF_176_144,
 ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144)},
{OV5640_MODE_QVGA_320_240, SUBSAMPLING,
 320, 1896, 240, 984,
-5600,
 ov5640_setting_15fps_QVGA_320_240,
 ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240)},
{OV5640_MODE_VGA_640_480, SUBSAMPLING,
 640, 1896, 480, 1080,
-5600,
 ov5640_setting_15fps_VGA_640_480,
 ARRAY_SIZE(ov5640_setting_15fps_VGA_640_480)},
{OV5640_MODE_NTSC_720_480, SUBSAMPLING,
 720, 1896, 480, 984,
-5600,
 ov5640_setting_15fps_NTSC_720_480,
 ARRAY_SIZE(ov5640_setting_15fps_NTSC_720_480)},
{OV5640_MODE_PAL_720_576, SUBSAMPLING,
 720, 1896, 576, 984,
-5600,
 ov5640_setting_15fps_PAL_720_576,
 ARRAY_SIZE(ov5640_setting_15fps_PAL_720_576)},
{OV5640_MODE_XGA_1024_768, SUBSAMPLING,
 1024, 1896, 768, 1080,
-5600,
 

[PATCH v2 11/12] media: ov5640: Add 60 fps support

[Maxime Ripard]

Now that we have everything in place to compute the clock rate at runtime,
we can enable the 60fps framerate for the mode we tested it with.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 33 +
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 690ed0238763..c01bbc5f9f34 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -112,6 +112,7 @@ enum ov5640_mode_id {
 enum ov5640_frame_rate {
OV5640_15_FPS = 0,
OV5640_30_FPS,
+   OV5640_60_FPS,
OV5640_NUM_FRAMERATES,
 };
 
@@ -140,6 +141,7 @@ MODULE_PARM_DESC(virtual_channel,
 static const int ov5640_framerates[] = {
[OV5640_15_FPS] = 15,
[OV5640_30_FPS] = 30,
+   [OV5640_60_FPS] = 60,
 };
 
 /* regulator supplies */
@@ -1398,12 +1400,19 @@ ov5640_find_mode(struct ov5640_dev *sensor, enum 
ov5640_frame_rate fr,
/* try to find another mode */
continue;
 
+   /* Only 640x480 can operate at 60fps (for now) */
+   if (fr == OV5640_60_FPS &&
+   width != 640 && height != 480)
+   /* try to find another mode */
+   continue;
+
break;
}
}
 
+   /* VGA is the only mode that supports all the framerates */
if (nearest && i < 0)
-   mode = _mode_data[0];
+   mode = _mode_data[OV5640_MODE_VGA_640_480];
 
return mode;
 }
@@ -1848,12 +1857,13 @@ static int ov5640_try_frame_interval(struct ov5640_dev 
*sensor,
int ret;
 
minfps = ov5640_framerates[OV5640_15_FPS];
-   maxfps = ov5640_framerates[OV5640_30_FPS];
+   maxfps = ov5640_framerates[OV5640_60_FPS];
 
if (fi->numerator == 0) {
fi->denominator = maxfps;
fi->numerator = 1;
-   return OV5640_30_FPS;
+   ret = OV5640_60_FPS;
+   goto find_mode;
}
 
fps = DIV_ROUND_CLOSEST(fi->denominator, fi->numerator);
@@ -1865,11 +1875,15 @@ static int ov5640_try_frame_interval(struct ov5640_dev 
*sensor,
fi->denominator = minfps;
else if (2 * fps >= 2 * minfps + (maxfps - minfps))
fi->denominator = maxfps;
+
+   if (fi->denominator == minfps)
+   ret = OV5640_15_FPS;
+   else if (fi->denominator == maxfps)
+   ret = OV5640_60_FPS;
else
-   fi->denominator = minfps;
-
-   ret = (fi->denominator == minfps) ? OV5640_15_FPS : OV5640_30_FPS;
+   ret = OV5640_30_FPS;
 
+find_mode:
mode = ov5640_find_mode(sensor, ret, width, height, false);
return mode ? ret : -EINVAL;
 }
@@ -2458,8 +2472,11 @@ static int ov5640_s_frame_interval(struct v4l2_subdev 
*sd,
 
frame_rate = ov5640_try_frame_interval(sensor, >interval,
   mode->hact, mode->vact);
-   if (frame_rate < 0)
-   frame_rate = OV5640_15_FPS;
+   if (frame_rate < 0) {
+   /* Always return a valid frame interval value */
+   fi->interval = sensor->frame_interval;
+   goto out;
+   }
 
sensor->current_fr = frame_rate;
sensor->frame_interval = fi->interval;
-- 
2.17.0

[PATCH v2 07/12] media: ov5640: Program the visible resolution

[Maxime Ripard]

The active frame size is set in the initialization arrays, but the value
itself is also available in the struct ov5640_mode_info.

Let's move these values out of the big bytes arrays, and program it with
the value of the mode that we are given.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 58 +-
 1 file changed, 14 insertions(+), 44 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index c90d5fd06563..4608b8dc6495 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -60,6 +60,8 @@
 #define OV5640_REG_AEC_PK_MANUAL   0x3503
 #define OV5640_REG_AEC_PK_REAL_GAIN0x350a
 #define OV5640_REG_AEC_PK_VTS  0x350c
+#define OV5640_REG_TIMING_DVPHO0x3808
+#define OV5640_REG_TIMING_DVPVO0x380a
 #define OV5640_REG_TIMING_HTS  0x380c
 #define OV5640_REG_TIMING_VTS  0x380e
 #define OV5640_REG_TIMING_TC_REG21 0x3821
@@ -273,8 +275,6 @@ static const struct reg_value 
ov5640_init_setting_30fps_VGA[] = {
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
-   {0x3808, 0x02, 0, 0}, {0x3809, 0x80, 0, 0}, {0x380a, 0x01, 0, 0},
-   {0x380b, 0xe0, 0, 0},
{0x3810, 0x00, 0, 0},
{0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
{0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
@@ -347,8 +347,6 @@ static const struct reg_value 
ov5640_setting_30fps_VGA_640_480[] = {
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
-   {0x3808, 0x02, 0, 0}, {0x3809, 0x80, 0, 0}, {0x380a, 0x01, 0, 0},
-   {0x380b, 0xe0, 0, 0},
{0x3810, 0x00, 0, 0},
{0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
{0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
@@ -368,8 +366,6 @@ static const struct reg_value 
ov5640_setting_15fps_VGA_640_480[] = {
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
-   {0x3808, 0x02, 0, 0}, {0x3809, 0x80, 0, 0}, {0x380a, 0x01, 0, 0},
-   {0x380b, 0xe0, 0, 0},
{0x3810, 0x00, 0, 0},
{0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
{0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
@@ -389,8 +385,6 @@ static const struct reg_value 
ov5640_setting_30fps_XGA_1024_768[] = {
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
-   {0x3808, 0x02, 0, 0}, {0x3809, 0x80, 0, 0}, {0x380a, 0x01, 0, 0},
-   {0x380b, 0xe0, 0, 0},
{0x3810, 0x00, 0, 0},
{0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
{0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
@@ -401,8 +395,7 @@ static const struct reg_value 
ov5640_setting_30fps_XGA_1024_768[] = {
{0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
{0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
{0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x3503, 0x00, 0, 0},
-   {0x3808, 0x04, 0, 0}, {0x3809, 0x00, 0, 0}, {0x380a, 0x03, 0, 0},
-   {0x380b, 0x00, 0, 0}, {0x3035, 0x12, 0, 0},
+   {0x3035, 0x12, 0, 0},
 };
 
 static const struct reg_value ov5640_setting_15fps_XGA_1024_768[] = {
@@ -412,8 +405,6 @@ static const struct reg_value 
ov5640_setting_15fps_XGA_1024_768[] = {
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
-   {0x3808, 0x02, 0, 0}, {0x3809, 0x80, 0, 0}, {0x380a, 0x01, 0, 0},
-   {0x380b, 0xe0, 0, 0},
{0x3810, 0x00, 0, 0},
{0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
{0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
@@ -423,8 +414,7 @@ static const struct reg_value 
ov5640_setting_15fps_XGA_1024_768[] = {
{0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
{0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
{0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
-   {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x3808, 0x04, 0, 0},
-   {0x3809, 0x00, 0, 0}, {0x380a, 0x03, 0, 0}, {0x380b, 0x00, 0, 0},
+  

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

[Maxime Ripard]

The clock structure for the PCLK is quite obscure in the documentation, and
was hardcoded through the bytes array of each and every mode.

This is troublesome, since we cannot adjust it at runtime based on other
parameters (such as the number of bytes per pixel), and we can't support
either framerates that have not been used by the various vendors, since we
don't have the needed initialization sequence.

We can however understand how the clock tree works, and then implement some
functions to derive the various parameters from a given rate. And now that
those parameters are calculated at runtime, we can remove them from the
initialization sequence.

The modes also gained a new parameter which is the clock that they are
running at, from the register writes they were doing, so for now the switch
to the new algorithm should be transparent.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 272 +
 1 file changed, 245 insertions(+), 27 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 4608b8dc6495..8db4fc0f031c 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -95,7 +95,6 @@
 #define OV5640_REG_AVG_READOUT 0x56a1
 
 #define OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT 1
-#define OV5640_SCLK_ROOT_DIVIDER_DEFAULT   2
 
 enum ov5640_mode_id {
OV5640_MODE_QCIF_176_144 = 0,
@@ -175,6 +174,7 @@ struct ov5640_mode_info {
u32 htot;
u32 vact;
u32 vtot;
+   u32 clock;
const struct reg_value *reg_data;
u32 reg_data_size;
 };
@@ -257,8 +257,8 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct 
v4l2_ctrl *ctrl)
 static const struct reg_value ov5640_init_setting_30fps_VGA[] = {
{0x3103, 0x11, 0, 0}, {0x3008, 0x82, 0, 5}, {0x3008, 0x42, 0, 0},
{0x3103, 0x03, 0, 0}, {0x3017, 0x00, 0, 0}, {0x3018, 0x00, 0, 0},
-   {0x3034, 0x18, 0, 0}, {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0},
-   {0x3037, 0x13, 0, 0}, {0x3630, 0x36, 0, 0},
+   {0x3034, 0x18, 0, 0},
+   {0x3630, 0x36, 0, 0},
{0x3631, 0x0e, 0, 0}, {0x3632, 0xe2, 0, 0}, {0x3633, 0x12, 0, 0},
{0x3621, 0xe0, 0, 0}, {0x3704, 0xa0, 0, 0}, {0x3703, 0x5a, 0, 0},
{0x3715, 0x78, 0, 0}, {0x3717, 0x01, 0, 0}, {0x370b, 0x60, 0, 0},
@@ -341,7 +341,7 @@ static const struct reg_value 
ov5640_init_setting_30fps_VGA[] = {
 };
 
 static const struct reg_value ov5640_setting_30fps_VGA_640_480[] = {
-   {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -360,7 +360,7 @@ static const struct reg_value 
ov5640_setting_30fps_VGA_640_480[] = {
 };
 
 static const struct reg_value ov5640_setting_15fps_VGA_640_480[] = {
-   {0x3035, 0x22, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -379,7 +379,7 @@ static const struct reg_value 
ov5640_setting_15fps_VGA_640_480[] = {
 };
 
 static const struct reg_value ov5640_setting_30fps_XGA_1024_768[] = {
-   {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -395,11 +395,10 @@ static const struct reg_value 
ov5640_setting_30fps_XGA_1024_768[] = {
{0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
{0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
{0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x3503, 0x00, 0, 0},
-   {0x3035, 0x12, 0, 0},
 };
 
 static const struct reg_value ov5640_setting_15fps_XGA_1024_768[] = {
-   {0x3035, 0x22, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -418,7 +417,7 @@ static const struct reg_value 
ov5640_setting_15fps_XGA_1024_768[] = {
 };
 
 static const struct reg_value ov5640_setting_30fps_QVGA_320_240[] = {
-   {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+   {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},

[PATCH v2 04/12] media: ov5640: Init properly the SCLK dividers

[Maxime Ripard]

The SCLK and SCLK2X dividers are fixed in stone in the initialization
array. Let's make explicit what we're doing and move that away from the
huge array to the initialization code.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index a41e4cd5fd17..5b7995abc0e6 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -92,6 +92,9 @@
 #define OV5640_REG_SDE_CTRL5   0x5585
 #define OV5640_REG_AVG_READOUT 0x56a1
 
+#define OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT 1
+#define OV5640_SCLK_ROOT_DIVIDER_DEFAULT   2
+
 enum ov5640_mode_id {
OV5640_MODE_QCIF_176_144 = 0,
OV5640_MODE_QVGA_320_240,
@@ -251,7 +254,7 @@ static const struct reg_value 
ov5640_init_setting_30fps_VGA[] = {
{0x3103, 0x11, 0, 0}, {0x3008, 0x82, 0, 5}, {0x3008, 0x42, 0, 0},
{0x3103, 0x03, 0, 0}, {0x3017, 0x00, 0, 0}, {0x3018, 0x00, 0, 0},
{0x3034, 0x18, 0, 0}, {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0},
-   {0x3037, 0x13, 0, 0}, {0x3108, 0x01, 0, 0}, {0x3630, 0x36, 0, 0},
+   {0x3037, 0x13, 0, 0}, {0x3630, 0x36, 0, 0},
{0x3631, 0x0e, 0, 0}, {0x3632, 0xe2, 0, 0}, {0x3633, 0x12, 0, 0},
{0x3621, 0xe0, 0, 0}, {0x3704, 0xa0, 0, 0}, {0x3703, 0x5a, 0, 0},
{0x3715, 0x78, 0, 0}, {0x3717, 0x01, 0, 0}, {0x370b, 0x60, 0, 0},
@@ -1662,6 +1665,12 @@ static int ov5640_restore_mode(struct ov5640_dev *sensor)
if (ret < 0)
return ret;
 
+   ret = ov5640_mod_reg(sensor, OV5640_REG_SYS_ROOT_DIVIDER, 0x3f,
+(ilog2(OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT) << 2) |
+ilog2(OV5640_SCLK_ROOT_DIVIDER_DEFAULT));
+   if (ret)
+   return ret;
+
/* now restore the last capture mode */
ret = ov5640_set_mode(sensor, _mode_init_data);
if (ret < 0)
-- 
2.17.0

[PATCH v2 12/12] media: ov5640: Remove duplicate auto-exposure setup

[Maxime Ripard]

The autoexposure setup in the 1080p init array is redundant with the
default value of the sensor.

Remove it.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index c01bbc5f9f34..e7e167a515f2 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -503,7 +503,7 @@ static const struct reg_value 
ov5640_setting_1080P_1920_1080[] = {
{0x3a0e, 0x03, 0, 0}, {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x04, 0, 0},
{0x3a15, 0x60, 0, 0}, {0x4713, 0x02, 0, 0}, {0x4407, 0x04, 0, 0},
{0x460b, 0x37, 0, 0}, {0x460c, 0x20, 0, 0}, {0x3824, 0x04, 0, 0},
-   {0x4005, 0x1a, 0, 0}, {0x3008, 0x02, 0, 0}, {0x3503, 0, 0, 0},
+   {0x4005, 0x1a, 0, 0}, {0x3008, 0x02, 0, 0},
 };
 
 static const struct reg_value ov5640_setting_QSXGA_2592_1944[] = {
-- 
2.17.0

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

[Maxime Ripard]

Hi,

Here is a "small" series that mostly cleans up the ov5640 driver code,
slowly getting rid of the big data array for more understandable code
(hopefully).

The biggest addition would be the clock rate computation at runtime,
instead of relying on those arrays to setup the clock tree
properly. As a side effect, it fixes the framerate that was off by
around 10% on the smaller resolutions, and we now support 60fps.

This also introduces a bunch of new features.

Let me know what you think,
Maxime

Changes from v1:
  - Integrated Hugues' suggestions to fix v4l2-compliance
  - Fixed the bus width with JPEG
  - Dropped the clock rate calculation loops for something simpler as
suggested by Sakari
  - Cache the exposure value instead of using the control value
  - Rebased on top of 4.17

Maxime Ripard (10):
  media: ov5640: Don't force the auto exposure state at start time
  media: ov5640: Init properly the SCLK dividers
  media: ov5640: Change horizontal and vertical resolutions name
  media: ov5640: Add horizontal and vertical totals
  media: ov5640: Program the visible resolution
  media: ov5640: Adjust the clock based on the expected rate
  media: ov5640: Compute the clock rate at runtime
  media: ov5640: Enhance FPS handling
  media: ov5640: Add 60 fps support
  media: ov5640: Remove duplicate auto-exposure setup

Mylène Josserand (2):
  media: ov5640: Add auto-focus feature
  media: ov5640: Add light frequency control

 drivers/media/i2c/ov5640.c | 752 +
 1 file changed, 422 insertions(+), 330 deletions(-)

-- 
2.17.0

[PATCH v2 05/12] media: ov5640: Change horizontal and vertical resolutions name

[Maxime Ripard]

The current width and height parameters in the struct ov5640_mode_info are
actually the active horizontal and vertical resolutions.

Since we're going to add a few other parameters, let's pick a better, more
precise name for these values.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 5b7995abc0e6..a8158ea9da67 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -169,8 +169,8 @@ struct reg_value {
 struct ov5640_mode_info {
enum ov5640_mode_id id;
enum ov5640_downsize_mode dn_mode;
-   u32 width;
-   u32 height;
+   u32 hact;
+   u32 vact;
const struct reg_value *reg_data;
u32 reg_data_size;
 };
@@ -1396,10 +1396,10 @@ ov5640_find_mode(struct ov5640_dev *sensor, enum 
ov5640_frame_rate fr,
if (!mode->reg_data)
continue;
 
-   if ((nearest && mode->width <= width &&
-mode->height <= height) ||
-   (!nearest && mode->width == width &&
-mode->height == height))
+   if ((nearest && mode->hact <= width &&
+mode->vact <= height) ||
+   (!nearest && mode->hact == width &&
+mode->vact == height))
break;
}
 
@@ -1888,8 +1888,8 @@ static int ov5640_try_fmt_internal(struct v4l2_subdev *sd,
mode = ov5640_find_mode(sensor, fr, fmt->width, fmt->height, true);
if (!mode)
return -EINVAL;
-   fmt->width = mode->width;
-   fmt->height = mode->height;
+   fmt->width = mode->hact;
+   fmt->height = mode->vact;
 
if (new_mode)
*new_mode = mode;
@@ -2367,10 +2367,10 @@ static int ov5640_enum_frame_size(struct v4l2_subdev 
*sd,
return -EINVAL;
 
fse->min_width =
-   ov5640_mode_data[0][fse->index].width;
+   ov5640_mode_data[0][fse->index].hact;
fse->max_width = fse->min_width;
fse->min_height =
-   ov5640_mode_data[0][fse->index].height;
+   ov5640_mode_data[0][fse->index].vact;
fse->max_height = fse->min_height;
 
return 0;
@@ -2434,14 +2434,14 @@ static int ov5640_s_frame_interval(struct v4l2_subdev 
*sd,
mode = sensor->current_mode;
 
frame_rate = ov5640_try_frame_interval(sensor, >interval,
-  mode->width, mode->height);
+  mode->hact, mode->vact);
if (frame_rate < 0)
frame_rate = OV5640_15_FPS;
 
sensor->current_fr = frame_rate;
sensor->frame_interval = fi->interval;
-   sensor->current_mode = ov5640_find_mode(sensor, frame_rate, mode->width,
-   mode->height, true);
+   sensor->current_mode = ov5640_find_mode(sensor, frame_rate, mode->hact,
+   mode->vact, true);
sensor->pending_mode_change = true;
 out:
mutex_unlock(>lock);
-- 
2.17.0

[PATCH v2 02/12] media: ov5640: Add light frequency control

[Maxime Ripard]

From: Mylène Josserand 

Add the light frequency control to be able to set the frequency
to manual (50Hz or 60Hz) or auto.

Signed-off-by: Mylène Josserand 
Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index a33e45f8e2b0..28122341fc35 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -189,6 +189,7 @@ struct ov5640_ctrls {
};
struct v4l2_ctrl *auto_focus;
struct v4l2_ctrl *brightness;
+   struct v4l2_ctrl *light_freq;
struct v4l2_ctrl *saturation;
struct v4l2_ctrl *contrast;
struct v4l2_ctrl *hue;
@@ -2163,6 +2164,21 @@ static int ov5640_set_ctrl_focus(struct ov5640_dev 
*sensor, int value)
  BIT(1), value ? BIT(1) : 0);
 }
 
+static int ov5640_set_ctl_light_freq(struct ov5640_dev *sensor, int value)
+{
+   int ret;
+
+   ret = ov5640_mod_reg(sensor, OV5640_REG_HZ5060_CTRL01, BIT(7),
+(value == V4L2_CID_POWER_LINE_FREQUENCY_AUTO) ?
+0: BIT(7));
+   if (ret)
+   return ret;
+
+   return ov5640_mod_reg(sensor, OV5640_REG_HZ5060_CTRL00, BIT(2),
+ (value == V4L2_CID_POWER_LINE_FREQUENCY_50HZ) ?
+ BIT(2): 0);
+}
+
 static int ov5640_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
 {
struct v4l2_subdev *sd = ctrl_to_sd(ctrl);
@@ -2234,6 +2250,9 @@ static int ov5640_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_FOCUS_AUTO:
ret = ov5640_set_ctrl_focus(sensor, ctrl->val);
break;
+   case V4L2_CID_POWER_LINE_FREQUENCY:
+   ret = ov5640_set_ctl_light_freq(sensor, ctrl->val);
+   break;
default:
ret = -EINVAL;
break;
@@ -2298,6 +2317,11 @@ static int ov5640_init_controls(struct ov5640_dev 
*sensor)
 
ctrls->auto_focus = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_AUTO,
  0, 1, 1, 0);
+   ctrls->light_freq =
+   v4l2_ctrl_new_std_menu(hdl, ops,
+  V4L2_CID_POWER_LINE_FREQUENCY,
+  V4L2_CID_POWER_LINE_FREQUENCY_AUTO, 0,
+  V4L2_CID_POWER_LINE_FREQUENCY_50HZ);
 
if (hdl->error) {
ret = hdl->error;
-- 
2.17.0

[PATCH v2 01/12] media: ov5640: Add auto-focus feature

[Maxime Ripard]

From: Mylène Josserand 

Add the auto-focus ENABLE/DISABLE feature as V4L2 control.
Disabled by default.

Signed-off-by: Mylène Josserand 
Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 852026baa2e7..a33e45f8e2b0 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -82,8 +82,9 @@
 #define OV5640_REG_POLARITY_CTRL00 0x4740
 #define OV5640_REG_MIPI_CTRL00 0x4800
 #define OV5640_REG_DEBUG_MODE  0x4814
-#define OV5640_REG_ISP_FORMAT_MUX_CTRL 0x501f
+#define OV5640_REG_ISP_CTRL03  0x5003
 #define OV5640_REG_PRE_ISP_TEST_SET1   0x503d
+#define OV5640_REG_ISP_FORMAT_MUX_CTRL 0x501f
 #define OV5640_REG_SDE_CTRL0   0x5580
 #define OV5640_REG_SDE_CTRL1   0x5581
 #define OV5640_REG_SDE_CTRL3   0x5583
@@ -186,6 +187,7 @@ struct ov5640_ctrls {
struct v4l2_ctrl *auto_gain;
struct v4l2_ctrl *gain;
};
+   struct v4l2_ctrl *auto_focus;
struct v4l2_ctrl *brightness;
struct v4l2_ctrl *saturation;
struct v4l2_ctrl *contrast;
@@ -2155,6 +2157,12 @@ static int ov5640_set_ctrl_test_pattern(struct 
ov5640_dev *sensor, int value)
  0xa4, value ? 0xa4 : 0);
 }
 
+static int ov5640_set_ctrl_focus(struct ov5640_dev *sensor, int value)
+{
+   return ov5640_mod_reg(sensor, OV5640_REG_ISP_CTRL03,
+ BIT(1), value ? BIT(1) : 0);
+}
+
 static int ov5640_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
 {
struct v4l2_subdev *sd = ctrl_to_sd(ctrl);
@@ -2223,6 +2231,9 @@ static int ov5640_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_TEST_PATTERN:
ret = ov5640_set_ctrl_test_pattern(sensor, ctrl->val);
break;
+   case V4L2_CID_FOCUS_AUTO:
+   ret = ov5640_set_ctrl_focus(sensor, ctrl->val);
+   break;
default:
ret = -EINVAL;
break;
@@ -2285,6 +2296,9 @@ static int ov5640_init_controls(struct ov5640_dev *sensor)
 ARRAY_SIZE(test_pattern_menu) - 1,
 0, 0, test_pattern_menu);
 
+   ctrls->auto_focus = v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_AUTO,
+ 0, 1, 1, 0);
+
if (hdl->error) {
ret = hdl->error;
goto free_ctrls;
-- 
2.17.0

[PATCH v2 10/12] media: ov5640: Enhance FPS handling

[Maxime Ripard]

Now that we have moved the clock generation logic out of the bytes array,
these arrays are identical between the 15fps and 30fps variants.

Remove the duplicate entries, and convert the code accordingly.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 316 +++--
 1 file changed, 60 insertions(+), 256 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 62938e9dabc5..690ed0238763 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -339,64 +339,7 @@ static const struct reg_value 
ov5640_init_setting_30fps_VGA[] = {
{0x3a1f, 0x14, 0, 0}, {0x3008, 0x02, 0, 0}, {0x3c00, 0x04, 0, 300},
 };
 
-static const struct reg_value ov5640_setting_30fps_VGA_640_480[] = {
-   {0x3c07, 0x08, 0, 0},
-   {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
-   {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
-   {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
-   {0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
-   {0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
-   {0x3810, 0x00, 0, 0},
-   {0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
-   {0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
-   {0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
-   {0x3a03, 0xd8, 0, 0}, {0x3a08, 0x01, 0, 0}, {0x3a09, 0x0e, 0, 0},
-   {0x3a0a, 0x00, 0, 0}, {0x3a0b, 0xf6, 0, 0}, {0x3a0e, 0x03, 0, 0},
-   {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
-   {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
-   {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
-   {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x3503, 0x00, 0, 0},
-};
-
-static const struct reg_value ov5640_setting_15fps_VGA_640_480[] = {
-   {0x3c07, 0x08, 0, 0},
-   {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
-   {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
-   {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
-   {0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
-   {0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
-   {0x3810, 0x00, 0, 0},
-   {0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
-   {0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
-   {0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
-   {0x3a03, 0xd8, 0, 0}, {0x3a08, 0x01, 0, 0}, {0x3a09, 0x27, 0, 0},
-   {0x3a0a, 0x00, 0, 0}, {0x3a0b, 0xf6, 0, 0}, {0x3a0e, 0x03, 0, 0},
-   {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
-   {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
-   {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
-   {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0},
-};
-
-static const struct reg_value ov5640_setting_30fps_XGA_1024_768[] = {
-   {0x3c07, 0x08, 0, 0},
-   {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
-   {0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
-   {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
-   {0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
-   {0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
-   {0x3810, 0x00, 0, 0},
-   {0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
-   {0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
-   {0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
-   {0x3a03, 0xd8, 0, 0}, {0x3a08, 0x01, 0, 0}, {0x3a09, 0x0e, 0, 0},
-   {0x3a0a, 0x00, 0, 0}, {0x3a0b, 0xf6, 0, 0}, {0x3a0e, 0x03, 0, 0},
-   {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
-   {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
-   {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
-   {0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x3503, 0x00, 0, 0},
-};
-
-static const struct reg_value ov5640_setting_15fps_XGA_1024_768[] = {
+static const struct reg_value ov5640_setting_VGA_640_480[] = {
{0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 0x31, 0, 0},
@@ -415,7 +358,7 @@ static const struct reg_value 
ov5640_setting_15fps_XGA_1024_768[] = {
{0x3824, 0x02, 0, 0}, {0x5001, 0xa3, 0, 0},
 };
 
-static const struct reg_value ov5640_setting_30fps_QVGA_320_240[] = {
+static const struct reg_value ov5640_setting_XGA_1024_768[] = {
{0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3820, 0x41, 0, 0}, {0x3821, 0x07, 0, 0}, {0x3814, 

[PATCH v2 03/12] media: ov5640: Don't force the auto exposure state at start time

[Maxime Ripard]

The sensor needs to have the auto exposure stopped while changing mode.
However, when the new mode is set, the driver will force the auto exposure
on, disregarding whether the control has been changed or not.

Bypass the controls code entirely to do that, and only use the control
value cached when restoring the auto exposure mode.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 28122341fc35..a41e4cd5fd17 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1571,7 +1571,8 @@ static int ov5640_set_mode_exposure_calc(struct 
ov5640_dev *sensor,
  * change mode directly
  */
 static int ov5640_set_mode_direct(struct ov5640_dev *sensor,
- const struct ov5640_mode_info *mode)
+ const struct ov5640_mode_info *mode,
+ s32 exposure)
 {
int ret;
 
@@ -1587,7 +1588,8 @@ static int ov5640_set_mode_direct(struct ov5640_dev 
*sensor,
ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_gain, 1);
if (ret)
return ret;
-   return __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_exp, V4L2_EXPOSURE_AUTO);
+
+   return __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_exp, exposure);
 }
 
 static int ov5640_set_mode(struct ov5640_dev *sensor,
@@ -1595,6 +1597,7 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
 {
const struct ov5640_mode_info *mode = sensor->current_mode;
enum ov5640_downsize_mode dn_mode, orig_dn_mode;
+   s32 exposure;
int ret;
 
dn_mode = mode->dn_mode;
@@ -1604,7 +1607,9 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_gain, 0);
if (ret)
return ret;
-   ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_exp, V4L2_EXPOSURE_MANUAL);
+
+   exposure = sensor->ctrls.auto_exp->val;
+   ret = ov5640_set_exposure(sensor, V4L2_EXPOSURE_MANUAL);
if (ret)
return ret;
 
@@ -1620,7 +1625,7 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
 * change inside subsampling or scaling
 * download firmware directly
 */
-   ret = ov5640_set_mode_direct(sensor, mode);
+   ret = ov5640_set_mode_direct(sensor, mode, exposure);
}
 
if (ret < 0)
-- 
2.17.0

[PATCH v2 06/12] media: ov5640: Add horizontal and vertical totals

[Maxime Ripard]

All the initialization arrays are changing the horizontal and vertical
totals for some value.

In order to clean up the driver, and since we're going to need that value
later on, let's introduce in the ov5640_mode_info structure the horizontal
and vertical total sizes, and move these out of the bytes array.

Signed-off-by: Maxime Ripard 
---
 drivers/media/i2c/ov5640.c | 156 +++--
 1 file changed, 97 insertions(+), 59 deletions(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index a8158ea9da67..c90d5fd06563 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -170,7 +170,9 @@ struct ov5640_mode_info {
enum ov5640_mode_id id;
enum ov5640_downsize_mode dn_mode;
u32 hact;
+   u32 htot;
u32 vact;
+   u32 vtot;
const struct reg_value *reg_data;
u32 reg_data_size;
 };
@@ -272,8 +274,8 @@ static const struct reg_value 
ov5640_init_setting_30fps_VGA[] = {
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
{0x3808, 0x02, 0, 0}, {0x3809, 0x80, 0, 0}, {0x380a, 0x01, 0, 0},
-   {0x380b, 0xe0, 0, 0}, {0x380c, 0x07, 0, 0}, {0x380d, 0x68, 0, 0},
-   {0x380e, 0x03, 0, 0}, {0x380f, 0xd8, 0, 0}, {0x3810, 0x00, 0, 0},
+   {0x380b, 0xe0, 0, 0},
+   {0x3810, 0x00, 0, 0},
{0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
{0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
{0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
@@ -346,8 +348,8 @@ static const struct reg_value 
ov5640_setting_30fps_VGA_640_480[] = {
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
{0x3808, 0x02, 0, 0}, {0x3809, 0x80, 0, 0}, {0x380a, 0x01, 0, 0},
-   {0x380b, 0xe0, 0, 0}, {0x380c, 0x07, 0, 0}, {0x380d, 0x68, 0, 0},
-   {0x380e, 0x04, 0, 0}, {0x380f, 0x38, 0, 0}, {0x3810, 0x00, 0, 0},
+   {0x380b, 0xe0, 0, 0},
+   {0x3810, 0x00, 0, 0},
{0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
{0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
{0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
@@ -367,8 +369,8 @@ static const struct reg_value 
ov5640_setting_15fps_VGA_640_480[] = {
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
{0x3808, 0x02, 0, 0}, {0x3809, 0x80, 0, 0}, {0x380a, 0x01, 0, 0},
-   {0x380b, 0xe0, 0, 0}, {0x380c, 0x07, 0, 0}, {0x380d, 0x68, 0, 0},
-   {0x380e, 0x03, 0, 0}, {0x380f, 0xd8, 0, 0}, {0x3810, 0x00, 0, 0},
+   {0x380b, 0xe0, 0, 0},
+   {0x3810, 0x00, 0, 0},
{0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
{0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
{0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
@@ -388,8 +390,8 @@ static const struct reg_value 
ov5640_setting_30fps_XGA_1024_768[] = {
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
{0x3808, 0x02, 0, 0}, {0x3809, 0x80, 0, 0}, {0x380a, 0x01, 0, 0},
-   {0x380b, 0xe0, 0, 0}, {0x380c, 0x07, 0, 0}, {0x380d, 0x68, 0, 0},
-   {0x380e, 0x04, 0, 0}, {0x380f, 0x38, 0, 0}, {0x3810, 0x00, 0, 0},
+   {0x380b, 0xe0, 0, 0},
+   {0x3810, 0x00, 0, 0},
{0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
{0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
{0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
@@ -411,8 +413,8 @@ static const struct reg_value 
ov5640_setting_15fps_XGA_1024_768[] = {
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
{0x3808, 0x02, 0, 0}, {0x3809, 0x80, 0, 0}, {0x380a, 0x01, 0, 0},
-   {0x380b, 0xe0, 0, 0}, {0x380c, 0x07, 0, 0}, {0x380d, 0x68, 0, 0},
-   {0x380e, 0x03, 0, 0}, {0x380f, 0xd8, 0, 0}, {0x3810, 0x00, 0, 0},
+   {0x380b, 0xe0, 0, 0},
+   {0x3810, 0x00, 0, 0},
{0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
{0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
{0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
@@ -433,8 +435,8 @@ static const struct reg_value 
ov5640_setting_30fps_QVGA_320_240[] = {
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
{0x3808, 0x01, 0, 0}, {0x3809, 0x40, 0, 0}, {0x380a, 0x00, 0, 0},
-   {0x380b, 0xf0, 0, 0}, {0x380c, 

Re: OV5640 with 12MHz xclk

[Hans Verkuil]

On 04/16/2018 03:39 AM, Samuel Bobrowicz wrote:
> Can anyone verify if the OV5640 driver works with input clocks other
> than the typical 24MHz? The driver suggests anything from 6MHz-24MHz
> is acceptable, but I am running into issues while bringing up a module
> that uses a 12MHz oscillator. I'd expect that different xclk's would
> necessitate different register settings for the various resolutions
> (PLL settings, PCLK width, etc.), however the driver does not seem to
> modify nearly enough based on the frequency of xclk.
> 
> Sam
> 

I'm pretty sure it has never been tested with 12 MHz. The i.MX SabreLite
seems to use 22 MHz, and I can't tell from the code what the SabreSD uses
(probably 22 or 24 MHz). Steve will probably know.

Regards,

Hans

Re: Smatch and sparse errors

[Hans Verkuil]

On 04/14/2018 03:18 AM, Jasmin J. wrote:
> Hello Mauro/Hans!
> 
>> There is already an upstream patch for hidding it:
> The patch from https://patchwork.kernel.org/patch/10334353 will not
> apply at the smatch tree.
> 
> Attached is an updated version for smatch.
> 
> Even with the patched tools, sparse still complains:
>  CC  drivers/media/cec/cec-core.o
> /opt/media_test/media-git/include/linux/mm.h:533:24: warning: constant 
> 0xc900 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/mm.h:533:48: warning: constant 
> 0xc900 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/mm.h:624:29: warning: constant 
> 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/mm.h:1098:16: warning: constant 
> 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/mm.h:1795:27: warning: constant 
> 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/mm.h:1887:16: warning: constant 
> 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/scatterlist.h:151:25: warning: 
> constant 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/scatterlist.h:236:16: warning: 
> constant 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/scatterlist.h:387:16: warning: 
> constant 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/scatterlist.h:387:16: warning: 
> constant 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/dma-mapping.h:235:35: warning: 
> constant 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/dma-mapping.h:238:33: warning: 
> constant 0xea00 is so big it is unsigned long
> 
>  CC  drivers/media/usb/gspca/gl860/gl860-mi2020.o
> /opt/media_test/media-git/include/linux/mm.h:533:24: warning: constant 
> 0xc900 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/mm.h:533:48: warning: constant 
> 0xc900 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/mm.h:624:29: warning: constant 
> 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/mm.h:1098:16: warning: constant 
> 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/mm.h:1795:27: warning: constant 
> 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/mm.h:1887:16: warning: constant 
> 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/scatterlist.h:151:25: warning: 
> constant 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/scatterlist.h:236:16: warning: 
> constant 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/scatterlist.h:387:16: warning: 
> constant 0xea00 is so big it is unsigned long
> /opt/media_test/media-git/include/linux/scatterlist.h:387:16: warning: 
> constant 0xea00 is so big it is unsigned long
> 
> But other warnings are gone with the patch.
> 
> The daily build is running on a machine of Hans. He need to update the
> tools there.
> 
> @Hans:
> Until this patches are in upstream, we need to patch smatch/sparse on the fly
> in build.sh after pulling the last tools version.

I've switched my sparse/smatch to Mauro's repositories for those utilities.

Let's see what happens tonight.

Regards,

Hans

Re: [RfC PATCH] Add udmabuf misc device

[Daniel Vetter]

Ok, confusion around backend is I think cleared up. The other
confusion seems to be around dma-buf:

dma-buf is the cross subsystem zerocopy abstraction. PRIME is the
drm-specific support for it, 100% based on top of the generic struct
dma_buf.

You need a dma_buf exporter to convert a xen grant references list
into a dma_buf, which you can then import in your drm driver (using
prime), v4l, or anything else that supports dma-buf. You do _not_ need
a prime implementation, that's only the marketing name we've given to
dma-buf import/export for drm drivers.
-Daniel


On Mon, Apr 16, 2018 at 12:14 PM, Oleksandr Andrushchenko
 wrote:
> On 04/16/2018 12:32 PM, Daniel Vetter wrote:
>>
>> On Mon, Apr 16, 2018 at 10:22 AM, Oleksandr Andrushchenko
>>  wrote:
>>>
>>> On 04/16/2018 10:43 AM, Daniel Vetter wrote:

 On Mon, Apr 16, 2018 at 10:16:31AM +0300, Oleksandr Andrushchenko wrote:
>
> On 04/13/2018 06:37 PM, Daniel Vetter wrote:
>>
>> On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko
>> wrote:
>>>
>>> On 04/10/2018 08:26 PM, Dongwon Kim wrote:

 On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko
 wrote:
>
> On 04/06/2018 09:57 PM, Dongwon Kim wrote:
>>
>> On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko
>> wrote:
>>>
>>> On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:

   Hi,

>> I fail to see any common ground for xen-zcopy and udmabuf ...
>
> Does the above mean you can assume that xen-zcopy and udmabuf
> can co-exist as two different solutions?

 Well, udmabuf route isn't fully clear yet, but yes.

 See also gvt (intel vgpu), where the hypervisor interface is
 abstracted
 away into a separate kernel modules even though most of the
 actual
 vgpu
 emulation code is common.
>>>
>>> Thank you for your input, I'm just trying to figure out
>>> which of the three z-copy solutions intersect and how much
>
> And what about hyper-dmabuf?
>>
>> xen z-copy solution is pretty similar fundamentally to
>> hyper_dmabuf
>> in terms of these core sharing feature:
>>
>> 1. the sharing process - import prime/dmabuf from the producer ->
>> extract
>> underlying pages and get those shared -> return references for
>> shared pages

 Another thing is danvet was kind of against to the idea of importing
 existing
 dmabuf/prime buffer and forward it to the other domain due to
 synchronization
 issues. He proposed to make hyper_dmabuf only work as an exporter so
 that it
 can have a full control over the buffer. I think we need to talk
 about
 this
 further as well.
>>>
>>> Yes, I saw this. But this limits the use-cases so much.
>>> For instance, running Android as a Guest (which uses ION to allocate
>>> buffers) means that finally HW composer will import dma-buf into
>>> the DRM driver. Then, in case of xen-front for example, it needs to
>>> be
>>> shared with the backend (Host side). Of course, we can change
>>> user-space
>>> to make xen-front allocate the buffers (make it exporter), but what
>>> we
>>> try
>>> to avoid is to change user-space which in normal world would have
>>> remain
>>> unchanged otherwise.
>>> So, I do think we have to support this use-case and just have to
>>> understand
>>> the complexity.
>>
>> Erm, why do you need importer capability for this use-case?
>>
>> guest1 -> ION -> xen-front -> hypervisor -> guest 2 -> xen-zcopy
>> exposes
>> that dma-buf -> import to the real display hw
>>
>> No where in this chain do you need xen-zcopy to be able to import a
>> dma-buf (within linux, it needs to import a bunch of pages from the
>> hypervisor).
>>
>> Now if your plan is to use xen-zcopy in the guest1 instead of
>> xen-front,
>> then you indeed need to import.
>
> This is the exact use-case I was referring to while saying
> we need to import on Guest1 side. If hyper-dmabuf is so
> generic that there is no xen-front in the picture, then
> it needs to import a dma-buf, so it can be exported at Guest2 side.
>>
>> But that imo doesn't make sense:
>> - xen-front gives you clearly defined flip events you can forward to
>> the
>>  hypervisor. xen-zcopy would need to add that again.
>
> xen-zcopy is a helper driver which doesn't handle page flips
> and is not a KMS driver as one might think of: the DRM UAPI it uses is
> just to export a dma-buf 

Re: [PATCHv2 17/17] media: v4l2-compat-ioctl32: fix several __user annotations

[Hans Verkuil]

On 04/13/2018 08:07 PM, Mauro Carvalho Chehab wrote:
> Smatch report several issues with bad __user annotations:
> 
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:expected void 
> [noderef] *uptr
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:447:21:got void *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:expected void 
> const volatile [noderef] *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:621:21:got struct 
> v4l2_plane [noderef] **
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:expected void 
> [noderef] *uptr
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:693:13:got void 
> *[assigned] base
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13: warning: incorrect 
> type in assignment (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:expected struct 
> v4l2_ext_control [noderef] *kcontrols
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:871:13:got struct 
> v4l2_ext_control *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13: warning: incorrect 
> type in assignment (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:expected unsigned 
> char [usertype] *__pu_val
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:957:13:got void [noderef] 
> *
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13: warning: incorrect 
> type in argument 1 (different address spaces)
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:expected void 
> [noderef] *uptr
>   drivers/media/v4l2-core/v4l2-compat-ioctl32.c:973:13:got void 
> *[assigned] edid
> 
> Fix them.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 32 
> ++-
>  1 file changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index d03a44d89649..0b9dfe7dbfe7 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -443,8 +443,8 @@ static int put_v4l2_plane32(struct v4l2_plane __user *up,
>   return -EFAULT;
>   break;
>   case V4L2_MEMORY_USERPTR:
> - if (get_user(p, >m.userptr) ||
> - put_user((compat_ulong_t)ptr_to_compat((__force void *)p),
> + if (get_user(p, >m.userptr)||
> + put_user((compat_ulong_t)ptr_to_compat((void __user *)p),
>>m.userptr))
>   return -EFAULT;
>   break;
> @@ -587,7 +587,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
> *kp,
>   u32 length;
>   enum v4l2_memory memory;
>   struct v4l2_plane32 __user *uplane32;
> - struct v4l2_plane __user *uplane;
> + struct v4l2_plane *uplane;

This needs a comment (either here or before the get_user below). It really is a
pointer to userspace, but since videodev2.h has it without __user (since it is
copied to kernel space in v4l2-ioctl.c) we need to define it as a regular 
pointer
here and cast it to a __user pointer in the put_v4l2_plane32() call.

This is not trivially obvious, so a comment would help a lot.

>   compat_caddr_t p;
>   int ret;
>  
> @@ -617,15 +617,14 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
> *kp,
>  
>   if (num_planes == 0)
>   return 0;
> -
> - if (get_user(uplane, ((__force struct v4l2_plane __user 
> **)>m.planes)))
> + if (get_user(uplane, >m.planes))
>   return -EFAULT;
>   if (get_user(p, >m.planes))
>   return -EFAULT;
>   uplane32 = compat_ptr(p);
>  
>   while (num_planes--) {
> - ret = put_v4l2_plane32(uplane, uplane32, memory);
> + ret = put_v4l2_plane32((void __user *)uplane, uplane32, 
> memory);
>   if (ret)
>   return ret;
>   ++uplane;
> @@ -675,7 +674,7 @@ static int get_v4l2_framebuffer32(struct v4l2_framebuffer 
> __user *kp,
>  
>   if (!access_ok(VERIFY_READ, up, sizeof(*up)) ||
>   get_user(tmp, >base) ||
> - put_user((__force void *)compat_ptr(tmp), >base) ||
> + put_user((void __force *)compat_ptr(tmp), >base) ||
>   assign_in_user(>capability, >capability) ||
>   assign_in_user(>flags, >flags) ||
>   copy_in_user(>fmt, >fmt, sizeof(kp->fmt)))
> @@ 

Re: [PATCH v2 03/10] media: ov772x: create subdevice device node

[Sakari Ailus]

Hi Akinobu,

On Mon, Apr 16, 2018 at 11:51:44AM +0900, Akinobu Mita wrote:
> Set the V4L2_SUBDEV_FL_HAS_DEVNODE flag for the subdevice so that the
> subdevice device node is created.
> 
> Cc: Jacopo Mondi 
> Cc: Laurent Pinchart 
> Cc: Hans Verkuil 
> Cc: Sakari Ailus 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Akinobu Mita 
> ---
> * v2
> - No changes
> 
>  drivers/media/i2c/ov772x.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> index 8badd6f..188f2f1 100644
> --- a/drivers/media/i2c/ov772x.c
> +++ b/drivers/media/i2c/ov772x.c
> @@ -1287,6 +1287,7 @@ static int ov772x_probe(struct i2c_client *client,
>   priv->info = client->dev.platform_data;
>  
>   v4l2_i2c_subdev_init(>subdev, client, _subdev_ops);
> + priv->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;

Could you move this patch as the last in the set, so that you're enabling
the sub-device interface only when all the changes to support it are
actually there?

>   v4l2_ctrl_handler_init(>hdl, 3);
>   v4l2_ctrl_new_std(>hdl, _ctrl_ops,
> V4L2_CID_VFLIP, 0, 1, 1, 0);

-- 
Kind regards,

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

Re: [PATCH v2 10/10] media: ov772x: avoid accessing registers under power saving mode

[Sakari Ailus]

Hi Akinobu,

As the driver now offers a V4L2 sub-device uAPI, it needs to serialise
access to its internal data structures. This appears to be fine, but there
are additional requirements; for instance ov772x_select_params() should
likely fail if you're streaming.

On Mon, Apr 16, 2018 at 11:51:51AM +0900, Akinobu Mita wrote:
> The set_fmt() in subdev pad ops, the s_ctrl() for subdev control handler,
> and the s_frame_interval() in subdev video ops could be called when the
> device is under power saving mode.  These callbacks for ov772x driver
> cause updating H/W registers that will fail under power saving mode.
> 
> This avoids it by not apply any changes to H/W if the device is not powered
> up.  Instead the changes will be restored right after power-up.
> 
> Cc: Jacopo Mondi 
> Cc: Laurent Pinchart 
> Cc: Hans Verkuil 
> Cc: Sakari Ailus 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Akinobu Mita 
> ---
> * v2
> - New patch
> 
>  drivers/media/i2c/ov772x.c | 77 
> +-
>  1 file changed, 62 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> index 1297a21..c44728f 100644
> --- a/drivers/media/i2c/ov772x.c
> +++ b/drivers/media/i2c/ov772x.c
> @@ -741,19 +741,29 @@ static int ov772x_s_frame_interval(struct v4l2_subdev 
> *sd,
>   struct ov772x_priv *priv = to_ov772x(sd);
>   struct v4l2_fract *tpf = >interval;
>   unsigned int fps;
> - int ret;
> + int ret = 0;
>  
>   fps = ov772x_select_fps(priv, tpf);
>  
> - ret = ov772x_set_frame_rate(priv, fps, priv->cfmt, priv->win);
> - if (ret)
> - return ret;
> + mutex_lock(>power_lock);
> + /*
> +  * If the device is not powered up by the host driver do
> +  * not apply any changes to H/W at this time. Instead
> +  * the frame rate will be restored right after power-up.
> +  */
> + if (priv->power_count > 0) {
> + ret = ov772x_set_frame_rate(priv, fps, priv->cfmt, priv->win);
> + if (ret)
> + goto error;
> + }
>  
>   tpf->numerator = 1;
>   tpf->denominator = fps;
>   priv->fps = fps;

Newline before a label would be nice.

> +error:
> + mutex_unlock(>power_lock);
>  
> - return 0;
> + return ret;
>  }
>  
>  static int ov772x_s_ctrl(struct v4l2_ctrl *ctrl)
> @@ -765,6 +775,16 @@ static int ov772x_s_ctrl(struct v4l2_ctrl *ctrl)
>   int ret = 0;
>   u8 val;
>  
> + /* v4l2_ctrl_lock() locks our own mutex */
> +
> + /*
> +  * If the device is not powered up by the host driver do
> +  * not apply any controls to H/W at this time. Instead
> +  * the controls will be restored right after power-up.
> +  */
> + if (priv->power_count == 0)
> + return 0;
> +
>   switch (ctrl->id) {
>   case V4L2_CID_VFLIP:
>   val = ctrl->val ? VFLIP_IMG : 0x00;
> @@ -888,6 +908,10 @@ static int ov772x_power_off(struct ov772x_priv *priv)
>   return 0;
>  }
>  
> +static int ov772x_set_params(struct ov772x_priv *priv,
> +  const struct ov772x_color_format *cfmt,
> +  const struct ov772x_win_size *win);
> +
>  static int ov772x_s_power(struct v4l2_subdev *sd, int on)
>  {
>   struct ov772x_priv *priv = to_ov772x(sd);
> @@ -898,8 +922,20 @@ static int ov772x_s_power(struct v4l2_subdev *sd, int on)
>   /* If the power count is modified from 0 to != 0 or from != 0 to 0,
>* update the power state.
>*/
> - if (priv->power_count == !on)
> - ret = on ? ov772x_power_on(priv) : ov772x_power_off(priv);
> + if (priv->power_count == !on) {
> + if (on) {
> + ret = ov772x_power_on(priv);
> + /* Restore the controls */
> + if (!ret)
> + ret = ov772x_set_params(priv, priv->cfmt,
> + priv->win);
> + /* Restore the format and the frame rate */
> + if (!ret)
> + ret = __v4l2_ctrl_handler_setup(>hdl);
> + } else {
> + ret = ov772x_power_off(priv);
> + }
> + }
>  
>   if (!ret) {
>   /* Update the power count. */
> @@ -1163,7 +1199,7 @@ static int ov772x_set_fmt(struct v4l2_subdev *sd,
>   struct v4l2_mbus_framefmt *mf = >format;
>   const struct ov772x_color_format *cfmt;
>   const struct ov772x_win_size *win;
> - int ret;
> + int ret = 0;
>  
>   if (format->pad)
>   return -EINVAL;
> @@ -1184,14 +1220,23 @@ static int ov772x_set_fmt(struct v4l2_subdev *sd,
>   return 0;
>   }
>  
> - ret = 

[PATCHv2 02/17] media: staging: atomisp: don't declare the same vars as both private and public

[Mauro Carvalho Chehab]

The mmu_private.h header is included at mmu.c, with duplicates the
already existing definitions at mmu_public.h.

Fix this by removing the erroneous header file.

Solve those issues:


drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:24:26:
 warning: function 'mmu_reg_store' with external linkage has definition

drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:35:30:
 warning: function 'mmu_reg_load' with external linkage has definition

drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:24:26:
 warning: function 'mmu_reg_store' with external linkage has definition

drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h:35:30:
 warning: function 'mmu_reg_load' with external linkage has definition

Signed-off-by: Mauro Carvalho Chehab 
---

v2: re-added two function definitions that were at the mmu_private.h

 .../css2400/hive_isp_css_common/host/mmu.c |  4 --
 .../css2400/hive_isp_css_common/host/mmu_private.h | 44 --
 .../css2400/hive_isp_css_include/host/mmu_public.h | 22 +--
 .../css2400/hive_isp_css_include/mmu_device.h  |  8 
 4 files changed, 18 insertions(+), 60 deletions(-)
 delete mode 100644 
drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu.c
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu.c
index a28b67eb66ea..1a1719d3e745 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu.c
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu.c
@@ -15,10 +15,6 @@
 /* The name "mmu.h is already taken" */
 #include "mmu_device.h"
 
-#ifndef __INLINE_MMU__
-#include "mmu_private.h"
-#endif /* __INLINE_MMU__ */
-
 void mmu_set_page_table_base_index(
const mmu_ID_t  ID,
const hrt_data  base_index)
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h
deleted file mode 100644
index 7377666f6eb7..
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/mmu_private.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Support for Intel Camera Imaging ISP subsystem.
- * Copyright (c) 2010-2015, Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.
- */
-
-#ifndef __MMU_PRIVATE_H_INCLUDED__
-#define __MMU_PRIVATE_H_INCLUDED__
-
-#include "mmu_public.h"
-
-#include "device_access.h"
-
-#include "assert_support.h"
-
-STORAGE_CLASS_MMU_H void mmu_reg_store(
-   const mmu_ID_t  ID,
-   const unsigned int  reg,
-   const hrt_data  value)
-{
-   assert(ID < N_MMU_ID);
-   assert(MMU_BASE[ID] != (hrt_address)-1);
-   ia_css_device_store_uint32(MMU_BASE[ID] + reg*sizeof(hrt_data), value);
-   return;
-}
-
-STORAGE_CLASS_MMU_H hrt_data mmu_reg_load(
-   const mmu_ID_t  ID,
-   const unsigned int  reg)
-{
-   assert(ID < N_MMU_ID);
-   assert(MMU_BASE[ID] != (hrt_address)-1);
-   return ia_css_device_load_uint32(MMU_BASE[ID] + reg*sizeof(hrt_data));
-}
-
-#endif /* __MMU_PRIVATE_H_INCLUDED__ */
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/host/mmu_public.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/host/mmu_public.h
index 0a13eda73607..bbff4128603b 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/host/mmu_public.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_include/host/mmu_public.h
@@ -16,6 +16,8 @@
 #define __MMU_PUBLIC_H_INCLUDED__
 
 #include "system_types.h"
+#include "device_access.h"
+#include "assert_support.h"
 
 /*! Set the page table base index of MMU[ID]
 
@@ -62,10 +64,17 @@ extern void mmu_invalidate_cache_all(void);
 
  \return none, MMU[ID].ctrl[reg] = value
  */
-STORAGE_CLASS_MMU_H void mmu_reg_store(
+static inline void mmu_reg_store(
const mmu_ID_t  ID,
const unsigned int  reg,
-   const hrt_data  value);
+   const hrt_data  value)
+{
+   assert(ID < N_MMU_ID);
+   assert(MMU_BASE[ID] != (hrt_address)-1);
+   

Re: [RfC PATCH] Add udmabuf misc device

[Oleksandr Andrushchenko]

On 04/16/2018 12:32 PM, Daniel Vetter wrote:

On Mon, Apr 16, 2018 at 10:22 AM, Oleksandr Andrushchenko
 wrote:

On 04/16/2018 10:43 AM, Daniel Vetter wrote:

On Mon, Apr 16, 2018 at 10:16:31AM +0300, Oleksandr Andrushchenko wrote:

On 04/13/2018 06:37 PM, Daniel Vetter wrote:

On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko wrote:

On 04/10/2018 08:26 PM, Dongwon Kim wrote:

On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko
wrote:

On 04/06/2018 09:57 PM, Dongwon Kim wrote:

On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko
wrote:

On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:

  Hi,


I fail to see any common ground for xen-zcopy and udmabuf ...

Does the above mean you can assume that xen-zcopy and udmabuf
can co-exist as two different solutions?

Well, udmabuf route isn't fully clear yet, but yes.

See also gvt (intel vgpu), where the hypervisor interface is
abstracted
away into a separate kernel modules even though most of the actual
vgpu
emulation code is common.

Thank you for your input, I'm just trying to figure out
which of the three z-copy solutions intersect and how much

And what about hyper-dmabuf?

xen z-copy solution is pretty similar fundamentally to hyper_dmabuf
in terms of these core sharing feature:

1. the sharing process - import prime/dmabuf from the producer ->
extract
underlying pages and get those shared -> return references for
shared pages

Another thing is danvet was kind of against to the idea of importing
existing
dmabuf/prime buffer and forward it to the other domain due to
synchronization
issues. He proposed to make hyper_dmabuf only work as an exporter so
that it
can have a full control over the buffer. I think we need to talk about
this
further as well.

Yes, I saw this. But this limits the use-cases so much.
For instance, running Android as a Guest (which uses ION to allocate
buffers) means that finally HW composer will import dma-buf into
the DRM driver. Then, in case of xen-front for example, it needs to be
shared with the backend (Host side). Of course, we can change
user-space
to make xen-front allocate the buffers (make it exporter), but what we
try
to avoid is to change user-space which in normal world would have
remain
unchanged otherwise.
So, I do think we have to support this use-case and just have to
understand
the complexity.

Erm, why do you need importer capability for this use-case?

guest1 -> ION -> xen-front -> hypervisor -> guest 2 -> xen-zcopy exposes
that dma-buf -> import to the real display hw

No where in this chain do you need xen-zcopy to be able to import a
dma-buf (within linux, it needs to import a bunch of pages from the
hypervisor).

Now if your plan is to use xen-zcopy in the guest1 instead of xen-front,
then you indeed need to import.

This is the exact use-case I was referring to while saying
we need to import on Guest1 side. If hyper-dmabuf is so
generic that there is no xen-front in the picture, then
it needs to import a dma-buf, so it can be exported at Guest2 side.

But that imo doesn't make sense:
- xen-front gives you clearly defined flip events you can forward to the
 hypervisor. xen-zcopy would need to add that again.

xen-zcopy is a helper driver which doesn't handle page flips
and is not a KMS driver as one might think of: the DRM UAPI it uses is
just to export a dma-buf as a PRIME buffer, but that's it.
Flipping etc. is done by the backend [1], not xen-zcopy.

Same for
 hyperdmabuf (and really we're not going to shuffle struct dma_fence
over
 the wire in a generic fashion between hypervisor guests).

- xen-front already has the idea of pixel format for the buffer (and any
 other metadata). Again, xen-zcopy and hyperdmabuf lack that, would
need
 to add it shoehorned in somehow.

Again, here you are talking of something which is implemented in
Xen display backend, not xen-zcopy, e.g. display backend can
implement para-virtual display w/o xen-zcopy at all, but in this case
there is a memory copying for each frame. With the help of xen-zcopy
the backend feeds xen-front's buffers directly into Guest2 DRM/KMS or
Weston or whatever as xen-zcopy exports remote buffers as PRIME buffers,
thus no buffer copying is required.

Why do you need to copy on every frame for xen-front? In the above
pipeline, using xen-front I see 0 architectural reasons to have a copy
anywhere.

This seems to be the core of the confusion we're having here.

Ok, so I'll try to explain:
1. xen-front - produces a display buffer to be shown at Guest2
by the backend, shares its grant references with the backend
2. xen-front sends page flip event to the backend specifying the
buffer in question
3. Backend takes the shared buffer (which is only a buffer mapped into
backend's memory, it is not a dma-buf/PRIME one) and makes memcpy from
it to a local dumb/surface

Why do you even do that? The copying here I mean - why don't you just
directly scan out from the grant 

[GIT PULL FOR v4.18] rcar-vin: Add Gen3 with media controller

[Hans Verkuil]

Pull request of the 'rcar-vin: Add Gen3 with media controller' v14 patch series.

Regards,

Hans

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the Git repository at:

  git://linuxtv.org/hverkuil/media_tree.git rcar

for you to fetch changes up to abe8957b91296d6ecf94ff2fd4d970d60ea9167a:

  rcar-vin: enable support for r8a77970 (2018-04-16 11:48:29 +0200)


Fabrizio Castro (2):
  dt-bindings: media: rcar_vin: Reverse SoC part number list
  dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

Niklas Söderlund (31):
  rcar-vin: add Gen3 devicetree bindings documentation
  rcar-vin: rename poorly named initialize and cleanup functions
  rcar-vin: unregister video device on driver removal
  rcar-vin: move subdevice handling to async callbacks
  rcar-vin: move model information to own struct
  rcar-vin: move max width and height information to chip information
  rcar-vin: move functions regarding scaling
  rcar-vin: all Gen2 boards can scale simplify logic
  rcar-vin: set a default field to fallback on
  rcar-vin: fix handling of single field frames (top, bottom and alternate 
fields)
  rcar-vin: update bytesperline and sizeimage calculation
  rcar-vin: align pixelformat check
  rcar-vin: break out format alignment and checking
  rcar-vin: simplify how formats are set and reset
  rcar-vin: cache video standard
  rcar-vin: move media bus configuration to struct rvin_dev
  rcar-vin: enable Gen3 hardware configuration
  rcar-vin: add function to manipulate Gen3 chsel value
  rcar-vin: add flag to switch to media controller mode
  rcar-vin: use different v4l2 operations in media controller mode
  rcar-vin: force default colorspace for media centric mode
  rcar-vin: prepare for media controller mode initialization
  rcar-vin: add group allocator functions
  rcar-vin: change name of video device
  rcar-vin: add chsel information to rvin_info
  rcar-vin: parse Gen3 OF and setup media graph
  rcar-vin: add link notify for Gen3
  rcar-vin: extend {start, stop}_streaming to work with media controller
  rcar-vin: enable support for r8a7795
  rcar-vin: enable support for r8a7796
  rcar-vin: enable support for r8a77970

 Documentation/devicetree/bindings/media/rcar_vin.txt | 137 +++--
 drivers/media/platform/rcar-vin/Kconfig  |   2 +-
 drivers/media/platform/rcar-vin/rcar-core.c  | 956 
++
 drivers/media/platform/rcar-vin/rcar-dma.c   | 907 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c  | 480 
+
 drivers/media/platform/rcar-vin/rcar-vin.h   | 146 +++--
 6 files changed, 1964 insertions(+), 664 deletions(-)

Re: [PATCH] media: Revert cleanup ktime_set() usage

[Mauro Carvalho Chehab]

Em Sat, 14 Apr 2018 01:31:34 +0200
"Jasmin J."  escreveu:

> From: Jasmin Jessich 
> 
> This reverts 8b0e195314fa, because this will not compile for Kernels
> older than 4.10.

This patch looks fine, but not for the above-mentioned.

The thing is that it is not consistent to have some places with
things like:
timeout = ktime_set(1, ir->polling * 100);

and others with:
timeout = ir->polling * 100;

We should either use ktime_set() everywhere or remove it as a whole.
My preference is to keep using it, as it makes it better documented.
In any case, gcc should be smart enough to discard multiply by a
zero constant when evaluating ktime_set() macro (if not, it is a gcc
issue).

The fact that it makes maintainership of the media_build backport
tree easier is just a plus, but it makes no sense upstream.

> 
> Cc: Thomas Gleixner 
> Signed-off-by: Jasmin Jessich 
> ---
>  drivers/media/dvb-core/dmxdev.c | 2 +-
>  drivers/media/pci/cx88/cx88-input.c | 6 --
>  drivers/media/pci/pt3/pt3.c | 2 +-
>  3 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
> index 61a750f..cb078d6 100644
> --- a/drivers/media/dvb-core/dmxdev.c
> +++ b/drivers/media/dvb-core/dmxdev.c
> @@ -622,7 +622,7 @@ static int dvb_dmxdev_start_feed(struct dmxdev *dmxdev,
>struct dmxdev_filter *filter,
>struct dmxdev_feed *feed)
>  {
> - ktime_t timeout = 0;
> + ktime_t timeout = ktime_set(0, 0);
>   struct dmx_pes_filter_params *para = >params.pes;
>   enum dmx_output otype;
>   int ret;
> diff --git a/drivers/media/pci/cx88/cx88-input.c 
> b/drivers/media/pci/cx88/cx88-input.c
> index 6f4e692..b13243d 100644
> --- a/drivers/media/pci/cx88/cx88-input.c
> +++ b/drivers/media/pci/cx88/cx88-input.c
> @@ -180,7 +180,8 @@ static enum hrtimer_restart cx88_ir_work(struct hrtimer 
> *timer)
>   struct cx88_IR *ir = container_of(timer, struct cx88_IR, timer);
>  
>   cx88_ir_handle_key(ir);
> - missed = hrtimer_forward_now(>timer, ir->polling * 100LL);
> + missed = hrtimer_forward_now(>timer,
> +  ktime_set(0, ir->polling * 100));
>   if (missed > 1)
>   ir_dprintk("Missed ticks %ld\n", missed - 1);
>  
> @@ -200,7 +201,8 @@ static int __cx88_ir_start(void *priv)
>   if (ir->polling) {
>   hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
>   ir->timer.function = cx88_ir_work;
> - hrtimer_start(>timer, ir->polling * 100LL,
> + hrtimer_start(>timer,
> +   ktime_set(0, ir->polling * 100),
> HRTIMER_MODE_REL);
>   }
>   if (ir->sampling) {
> diff --git a/drivers/media/pci/pt3/pt3.c b/drivers/media/pci/pt3/pt3.c
> index da74828..8ced807 100644
> --- a/drivers/media/pci/pt3/pt3.c
> +++ b/drivers/media/pci/pt3/pt3.c
> @@ -464,7 +464,7 @@ static int pt3_fetch_thread(void *data)
>  
>   pt3_proc_dma(adap);
>  
> - delay = PT3_FETCH_DELAY * NSEC_PER_MSEC;
> + delay = ktime_set(0, PT3_FETCH_DELAY * NSEC_PER_MSEC);
>   set_current_state(TASK_UNINTERRUPTIBLE);
>   freezable_schedule_hrtimeout_range(,
>   PT3_FETCH_DELAY_DELTA * NSEC_PER_MSEC,



Thanks,
Mauro

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

[Sakari Ailus]

On Mon, Apr 16, 2018 at 04:30:46AM +, Tomasz Figa wrote:
> On Thu, Apr 12, 2018 at 6:57 PM Sakari Ailus 
> wrote:
> 
> > Hi Jacopo,
> 
> > On Thu, Apr 12, 2018 at 10:57:01AM +0200, jacopo mondi wrote:
> > ...
> > > > +   if (MAX_RETRY == ++retry) {
> > > > +   dev_err(>dev,
> > > > +   "Cannot do the write operation because
> VCM is busy\n");
> > >
> > > Nit: this is over 80 cols, it's fine, but I think you can really
> > > shorten the error messag without losing context.
> 
> > dev_warn() or dev_info() might be more appropriate actually. Or even
> > dev_dbg(). This isn't a grave problem; just a sign the user space is
> trying
> > to move the lens before it has reached its previous target position.
> 
> On the other hand, we print this only if we reach MAX_RETRY, which probably
> means that the lens is stuck or some other unexpected failure.

MAX_RETRY is only ten, so I'd expect you could hit this if you're tring to
move the lens again very quickly. It usually takes several ms (but could
well be more than 10 ms) to reach the target position. This depends on the
lens and the driver, too, and I don't know the properties of this driver
(nor the lens).

> 
> 
> > >
> > > > +   return -EIO;
> > > > +   }
> > > > +   usleep_range(DW9807_CTRL_DELAY_US, DW9807_CTRL_DELAY_US +
> 10);
> > >
> > > mmm, I wonder if a sleep range of 10usecs is really a strict
> > > requirement. Have a look at Documentation/timers/timers-howto.txt.
> > > With such a small range you're likely fire some unrequired interrupt.
> 
> > If the user is trying to tell where to move the lens next, no time should
> > be wasted on waiting. It'd perhaps rather make sense to return an error
> > (-EBUSY): the user application (as well as the application developer)
> would
> > know about the attempt to move the lens too fast and could take an
> informed
> > decision on what to do next. This could include changing the target
> > position, waiting more or changing the program to adjust the 3A loop
> > behaviour.
> 
> Actually, shouldn't we wait for the lens to finish moving after we set the
> position? If we don't do it, we risk the userspace requesting a capture
> with the lens still moving.

For that purpose I'd add a new control. The user process shouldn't wait in
the kernel for just the sake of this. In order to meaningfully control the
focussing process, the user space would have to know some properties of the
lens anyway, so this information would primarily be useful for checking
things are working out as expected.

> 
> If "time wasted on waiting" is a concern here, userspace could as well just
> have a separate thread for controlling the lens (as something that is
> expected to take time due to physical limitations).

That's up to the user space implementation.

-- 
Regards,

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

Re: [RfC PATCH] Add udmabuf misc device

[Daniel Vetter]

On Mon, Apr 16, 2018 at 10:22 AM, Oleksandr Andrushchenko
 wrote:
> On 04/16/2018 10:43 AM, Daniel Vetter wrote:
>>
>> On Mon, Apr 16, 2018 at 10:16:31AM +0300, Oleksandr Andrushchenko wrote:
>>>
>>> On 04/13/2018 06:37 PM, Daniel Vetter wrote:

 On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko wrote:
>
> On 04/10/2018 08:26 PM, Dongwon Kim wrote:
>>
>> On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko
>> wrote:
>>>
>>> On 04/06/2018 09:57 PM, Dongwon Kim wrote:

 On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko
 wrote:
>
> On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:
>>
>>  Hi,
>>
 I fail to see any common ground for xen-zcopy and udmabuf ...
>>>
>>> Does the above mean you can assume that xen-zcopy and udmabuf
>>> can co-exist as two different solutions?
>>
>> Well, udmabuf route isn't fully clear yet, but yes.
>>
>> See also gvt (intel vgpu), where the hypervisor interface is
>> abstracted
>> away into a separate kernel modules even though most of the actual
>> vgpu
>> emulation code is common.
>
> Thank you for your input, I'm just trying to figure out
> which of the three z-copy solutions intersect and how much
>>>
>>> And what about hyper-dmabuf?

 xen z-copy solution is pretty similar fundamentally to hyper_dmabuf
 in terms of these core sharing feature:

 1. the sharing process - import prime/dmabuf from the producer ->
 extract
 underlying pages and get those shared -> return references for
 shared pages
>>
>> Another thing is danvet was kind of against to the idea of importing
>> existing
>> dmabuf/prime buffer and forward it to the other domain due to
>> synchronization
>> issues. He proposed to make hyper_dmabuf only work as an exporter so
>> that it
>> can have a full control over the buffer. I think we need to talk about
>> this
>> further as well.
>
> Yes, I saw this. But this limits the use-cases so much.
> For instance, running Android as a Guest (which uses ION to allocate
> buffers) means that finally HW composer will import dma-buf into
> the DRM driver. Then, in case of xen-front for example, it needs to be
> shared with the backend (Host side). Of course, we can change
> user-space
> to make xen-front allocate the buffers (make it exporter), but what we
> try
> to avoid is to change user-space which in normal world would have
> remain
> unchanged otherwise.
> So, I do think we have to support this use-case and just have to
> understand
> the complexity.

 Erm, why do you need importer capability for this use-case?

 guest1 -> ION -> xen-front -> hypervisor -> guest 2 -> xen-zcopy exposes
 that dma-buf -> import to the real display hw

 No where in this chain do you need xen-zcopy to be able to import a
 dma-buf (within linux, it needs to import a bunch of pages from the
 hypervisor).

 Now if your plan is to use xen-zcopy in the guest1 instead of xen-front,
 then you indeed need to import.
>>>
>>> This is the exact use-case I was referring to while saying
>>> we need to import on Guest1 side. If hyper-dmabuf is so
>>> generic that there is no xen-front in the picture, then
>>> it needs to import a dma-buf, so it can be exported at Guest2 side.

But that imo doesn't make sense:
 - xen-front gives you clearly defined flip events you can forward to the
 hypervisor. xen-zcopy would need to add that again.
>>>
>>> xen-zcopy is a helper driver which doesn't handle page flips
>>> and is not a KMS driver as one might think of: the DRM UAPI it uses is
>>> just to export a dma-buf as a PRIME buffer, but that's it.
>>> Flipping etc. is done by the backend [1], not xen-zcopy.

Same for
 hyperdmabuf (and really we're not going to shuffle struct dma_fence
 over
 the wire in a generic fashion between hypervisor guests).

 - xen-front already has the idea of pixel format for the buffer (and any
 other metadata). Again, xen-zcopy and hyperdmabuf lack that, would
 need
 to add it shoehorned in somehow.
>>>
>>> Again, here you are talking of something which is implemented in
>>> Xen display backend, not xen-zcopy, e.g. display backend can
>>> implement para-virtual display w/o xen-zcopy at all, but in this case
>>> there is a memory copying for each frame. With the help of xen-zcopy
>>> the backend feeds xen-front's buffers directly into Guest2 DRM/KMS or
>>> Weston or whatever as xen-zcopy exports remote buffers as PRIME buffers,
>>> thus no buffer copying is required.
>>
>> Why do you need to copy on 

RPI 3 64bit (aarch64) image cropped

[david bensoussan]

Hello,
I'm currently working with a RPI 3 in 64 bit os.

I have the issue that the image captured is cropped. I don't know
where it comes from but I'm exploring all possibilities. Note that it
works perfectly on a 32 bits os with same versions of v4l, kernel,
libc and everything. The system is generated with Yocto so I'm 100%
sure the versions don't change.

I don't think the kernel plays a big role here and my knowledge about
it is not significant enough to dig into the image capture calls
easily.
I tried using musl instead of libc but results are similar. I don't
need to enable quirks to fetch the image when using it but the cropped
image is exactly the same.

Here is the system configuration:

* Kernel 4.9.52
* v4l 1.14.2
* XHV57-NBL60 usb camera with uvcvideo driver

Would you know how I could know V4l is not causing such issue?

Best regards,
David Bensoussan

Re: imx-media: MT9P031 Capture issues on IMX6

[Philipp Zabel]

On Mon, 2018-04-16 at 09:54 +0200, Ibtsam Ul-Haq wrote:
[...]
> This indeed looks the case. But then, is 'GR16' the FourCC for 'SGRBG16'?

Yes, see Documentation/media/uapi/v4l/pixfmt-srggb16.rst:
https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-srggb16.html

> To be honest, I had not seen GR16 as FourCC before.
> And the Gstreamer debug logs (I used GST_DEBUG=5) also say that they
> do not know this FourCC:
> v4l2 gstv4l2object.c:1541:gst_v4l2_object_v4l2fourcc_to_bare_struct: [00m
> Unsupported fourcc 0x36315247 GR16

The GStreamer V4L2 elements currently only support 8-bit per component
Bayer formats.

> Is there a way we can get by this?

There's two ways to handle this correctly, IMHO. One would be adding
SGRBG8_1X8 support to the mt9p031 driver. This is the correct way if the
device tree is configured for 8-bit parallel and there are only 8 data
lines connected between camera and SoC. As a quick hack, I think you
could just:

  sed "s/MEDIA_BUS_FMT_SGRBG12_1X12/MEDIA_BUS_FMT_SGRBG8_1X8/" -i 
drivers/media/i2c/mt9p031.c

The other would be to connect all 12 data lines, configure the device
tree with 12 bit data width, and extend the imx-media CSI subdevice
driver to allow setting SGRBG12_1X12 on the sink pad and SGRBG8_1X8 on
the source pad at the same time (and then just internally configuring
the hardware to 8-bit, ignoring the 4 LSB). That would be a bit more
involved.

Another possiblity would be to replace v4l2_subdev_link_validate() in
drivers/media/v4l2-core/v4l2-subdev.c with a variant that allows
source_fmt->format.code != sink_fmt->format.code in case the source
format can be turned into the sink format by just dropping LSB for one
of the links.

regards
Philipp

Re: [PATCH v13 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

Hi Niklas,

On Sun, Apr 15, 2018 at 10:47:37PM +0200, Niklas Söderlund wrote:
> Hi Sakari,
> 
> Thanks for your feedback.
> 
> On 2018-04-04 23:13:57 +0300, Sakari Ailus wrote:
> 
> [snip]
> 
> > > > +   pm_runtime_enable(>dev);
> > > 
> > > Is CONFIG_PM mandatory on Renesas SoCs? If not, you end up with the
> > > device uninitialised at probe, and pm_runtime_get_sync will not
> > > initialise it either if CONFIG_PM is not enabled. I guess you could
> > > call your runtime_resume function unconditionally, and mark the device
> > > as active in runtime_pm using pm_runtime_set_active.
> > 
> > There doesn't seem to be any runtime_resume function. Was there supposed
> > to be one?
> 
> No there is not suppose to be one.

Ok.

> 
> > 
> > Assuming runtime PM would actually do something here, you might add
> > pm_runtime_idle() to power the device off after probing.
> > 
> > I guess pm_runtime_set_active() should precede pm_runtime_enable().
> 
> The CSI-2 is in the always on power domain so the calls to 
> pm_runtime_get_sync() and pm_runtime_put() are there in the s_stream() 
> callback to enable and disable the module clock. I'm no expert on PM but 
> in my testing the pm_ calls in this driver seems to be correct.
> 
> 1. In probe I call pm_runtime_enable(). And rudimentary tests shows the 
>clock is off (but I might miss something) as I wish it to be until 
>stream on time.
> 2. In s_stream() I call pm_runtime_get_sync() before writing any 
>register when starting a stream. And likewise I call pm_runtime_put() 
>when stopping and I no longer need to write to a register.
> 3. In remove() I call pm_runtime_disable().
> 
> Am I missing something obvious here?

Looking at the code again, it seems fine in this respect.

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

Re: [PATCH stable v4.15 1/3] media: staging: lirc_zilog: broken reference counting

[Sean Young]

On Mon, Apr 16, 2018 at 10:50:15AM +0200, Greg KH wrote:
> On Mon, Apr 16, 2018 at 09:43:45AM +0100, Sean Young wrote:
> > On Mon, Apr 16, 2018 at 09:52:28AM +0200, Greg KH wrote:
> > > What is the git commit id of this patch, and the other patches in this
> > > series and the 4.14 patch series that you sent out?
> > 
> > lirc_zilog was dropped in v4.16, so this can't be patched upstream.
> 
> Ah you are right, should we just ditch them here as well as they
> obviously do not work? :)
> 
> > > Please read:
> > > 
> > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > > for how to do this in a way that I can pick them up.
> > 
> > These patches have been tested with different types of hardware. Is there
> > anything else I can do to get these patches included?
> 
> When submitting patches to stable, you need to be explicit as to why
> they are needed, and if they are not upstream, why not.
> 
> In this case, for obviously broken code that is not used anymore (as
> it is gone in 4.16), why don't we just take the patch that removed the
> driver to the stable trees as well?

Well in v4.16 the ir-kbd-i2c.c driver can do what the lirc_zilog does in
v4.15 (and earlier), so it wasn't ditched as such. It's a case of replaced
by mainline.

Since I was getting bug reports on it, there must be users of the lirc_zilog
driver.

That being said, the old lirc_dev and lirc_zilog is pretty awful code.


Sean

Re: [PATCH stable v4.15 1/3] media: staging: lirc_zilog: broken reference counting

[Greg KH]

On Mon, Apr 16, 2018 at 09:43:45AM +0100, Sean Young wrote:
> On Mon, Apr 16, 2018 at 09:52:28AM +0200, Greg KH wrote:
> > On Sun, Apr 15, 2018 at 10:54:20AM +0100, Sean Young wrote:
> > > commit 615cd3fe6ccc ("[media] media: lirc_dev: make better use of
> > > file->private_data") removed the reference get from open, so on the first
> > > close the reference count hits zero and the lirc device is freed.
> > > 
> > > BUG: unable to handle kernel NULL pointer dereference at 0040
> > > IP: lirc_thread+0x94/0x520 [lirc_zilog]
> > > PGD 22d69c067 P4D 22d69c067 PUD 22d69d067 PMD 0
> > > Oops:  [#1] SMP NOPTI
> > > CPU: 2 PID: 701 Comm: zilog-rx-i2c-7 Tainted: P C OE
> > > 4.15.14-300.fc27.x86_64 #1
> > > Hardware name: Gigabyte Technology Co., Ltd. 
> > > GA-MA790FXT-UD5P/GA-MA790FXT-UD5P, BIOS F6 08/06/2009
> > > RIP: 0010:lirc_thread+0x94/0x520 [lirc_zilog]
> > > RSP: 0018:b482c131be98 EFLAGS: 00010246
> > > RAX:  RBX: 8fdabf056000 RCX: 
> > > RDX:  RSI: 0246 RDI: 0246
> > > RBP: 8fdab740af00 R08: 8fdacfd214a0 R09: 
> > > R10:  R11: 0040 R12: b482c10dba48
> > > R13: 8fdabea89e00 R14: 8fdab740af00 R15: c0b5e500
> > > FS:  () GS:8fdacfd0() 
> > > knlGS:
> > > CS:  0010 DS:  ES:  CR0: 80050033
> > > CR2: 0040 CR3: 0002124c CR4: 06e0
> > > Call Trace:
> > >  ? __schedule+0x247/0x880
> > >  ? get_ir_tx+0x40/0x40 [lirc_zilog]
> > >  kthread+0x113/0x130
> > >  ? kthread_create_worker_on_cpu+0x70/0x70
> > >  ? do_syscall_64+0x74/0x180
> > >  ? SyS_exit_group+0x10/0x10
> > >  ret_from_fork+0x22/0x40
> > > Code: 20 8b 85 80 00 00 00 85 c0 0f 84 a6 00 00 00 bf 04 01 00 00 e8 ee 
> > > 34 d4 d7 e8 69 88 56 d7 84 c0 75 69 48 8b 45 18 c6 44 24 37 00 <48> 8b 58 
> > > 40 4c 8d 6b 18 4c 89 ef e8 fc 4d d4 d7 4c 89 ef 48 89
> > > RIP: lirc_thread+0x94/0x520 [lirc_zilog] RSP: b482c131be98
> > > CR2: 0040
> > > This code has been replaced completely in kernel v4.16 by a new driver,
> > > see commit acaa34bf06e9 ("media: rc: implement zilog transmitter"), and
> > > commit f95367a7b758 ("media: staging: remove lirc_zilog driver").
> > > 
> > > Fixes: 615cd3fe6ccc ("[media] media: lirc_dev: make better use of 
> > > file->private_data")
> > > 
> > > Cc: sta...@vger.kernel.org # v4.15
> > > Reported-by: Warren Sturm 
> > > Tested-by: Warren Sturm 
> > > Signed-off-by: Sean Young 
> > > ---
> > >  drivers/staging/media/lirc/lirc_zilog.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
> > > b/drivers/staging/media/lirc/lirc_zilog.c
> > > index 6bd0717bf76e..bf6869e48a0f 100644
> > > --- a/drivers/staging/media/lirc/lirc_zilog.c
> > > +++ b/drivers/staging/media/lirc/lirc_zilog.c
> > > @@ -1291,6 +1291,7 @@ static int open(struct inode *node, struct file 
> > > *filep)
> > >  
> > >   lirc_init_pdata(node, filep);
> > >   ir = lirc_get_pdata(filep);
> > > + get_ir_device(ir, false);
> > >  
> > >   atomic_inc(>open_count);
> > >  
> > > -- 
> > > 2.14.3
> > 
> > What is the git commit id of this patch, and the other patches in this
> > series and the 4.14 patch series that you sent out?
> 
> lirc_zilog was dropped in v4.16, so this can't be patched upstream.

Ah you are right, should we just ditch them here as well as they
obviously do not work? :)

> > Please read:
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > for how to do this in a way that I can pick them up.
> 
> These patches have been tested with different types of hardware. Is there
> anything else I can do to get these patches included?

When submitting patches to stable, you need to be explicit as to why
they are needed, and if they are not upstream, why not.

In this case, for obviously broken code that is not used anymore (as
it is gone in 4.16), why don't we just take the patch that removed the
driver to the stable trees as well?

thanks,

greg k-h