[PATCH v8 14/28] rcar-vin: move media bus configuration to struct rvin_info

2017-11-29 Thread Niklas Söderlund
Bus configuration will once the driver is extended to support Gen3
contain information not specific to only the directly connected parallel
subdevice. Move it to struct rvin_info to show it's not always coupled
to the parallel subdevice.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 18 +-
 drivers/media/platform/rcar-vin/rcar-dma.c  | 11 ++-
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  2 +-
 drivers/media/platform/rcar-vin/rcar-vin.h  |  9 -
 4 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 03d3cd63e38bee11..7d49904cab9cb2d9 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -101,10 +101,10 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
vin->digital->sink_pad = ret < 0 ? 0 : ret;
 
/* Find compatible subdevices mbus format */
-   vin->digital->code = 0;
+   vin->code = 0;
code.index = 0;
code.pad = vin->digital->source_pad;
-   while (!vin->digital->code &&
+   while (!vin->code &&
   !v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
code.index++;
switch (code.code) {
@@ -112,16 +112,16 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
case MEDIA_BUS_FMT_UYVY8_2X8:
case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
-   vin->digital->code = code.code;
+   vin->code = code.code;
vin_dbg(vin, "Found media bus format for %s: %d\n",
-   subdev->name, vin->digital->code);
+   subdev->name, vin->code);
break;
default:
break;
}
}
 
-   if (!vin->digital->code) {
+   if (!vin->code) {
vin_err(vin, "Unsupported media bus format for %s\n",
subdev->name);
return -EINVAL;
@@ -179,16 +179,16 @@ static int rvin_digital_parse_v4l2(struct device *dev,
if (vep->base.port || vep->base.id)
return -ENOTCONN;
 
-   rvge->mbus_cfg.type = vep->bus_type;
+   vin->mbus_cfg.type = vep->bus_type;
 
-   switch (rvge->mbus_cfg.type) {
+   switch (vin->mbus_cfg.type) {
case V4L2_MBUS_PARALLEL:
vin_dbg(vin, "Found PARALLEL media bus\n");
-   rvge->mbus_cfg.flags = vep->bus.parallel.flags;
+   vin->mbus_cfg.flags = vep->bus.parallel.flags;
break;
case V4L2_MBUS_BT656:
vin_dbg(vin, "Found BT656 media bus\n");
-   rvge->mbus_cfg.flags = 0;
+   vin->mbus_cfg.flags = 0;
break;
default:
vin_err(vin, "Unknown media bus type\n");
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index e6478088d9464221..d7660f485a2df9e4 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -633,7 +633,7 @@ static int rvin_setup(struct rvin_dev *vin)
/*
 * Input interface
 */
-   switch (vin->digital->code) {
+   switch (vin->code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
/* BT.601/BT.1358 16bit YCbCr422 */
vnmc |= VNMC_INF_YUV16;
@@ -641,7 +641,7 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
-   vnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?
+   vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
input_is_yuv = true;
break;
@@ -650,7 +650,7 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY10_2X10:
/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
-   vnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?
+   vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
input_is_yuv = true;
break;
@@ -662,11 +662,11 @@ static int rvin_setup(struct rvin_dev *vin)
dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
 
/* Hsync Signal Polarity Select */
-   if (!(vin->digital->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
+   if (!(vin->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
dmr2 |= VNDMR2_HPS;
 
/* Vsync Signal Polarity 

[PATCH v8 02/28] rcar-vin: rename poorly named initialize and cleanup functions

2017-11-29 Thread Niklas Söderlund
The functions to initialize and cleanup the hardware and video device
where poorly named from the start. Rename them to better describe there
intended function.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 10 +-
 drivers/media/platform/rcar-vin/rcar-dma.c  |  6 +++---
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  4 ++--
 drivers/media/platform/rcar-vin/rcar-vin.h  |  8 
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 108d776f32651b27..f7a4c21909da6923 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -93,7 +93,7 @@ static int rvin_digital_notify_complete(struct 
v4l2_async_notifier *notifier)
return ret;
}
 
-   return rvin_v4l2_probe(vin);
+   return rvin_v4l2_register(vin);
 }
 
 static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
@@ -103,7 +103,7 @@ static void rvin_digital_notify_unbind(struct 
v4l2_async_notifier *notifier,
struct rvin_dev *vin = notifier_to_vin(notifier);
 
vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
-   rvin_v4l2_remove(vin);
+   rvin_v4l2_unregister(vin);
vin->digital->subdev = NULL;
 }
 
@@ -245,7 +245,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
if (irq < 0)
return irq;
 
-   ret = rvin_dma_probe(vin, irq);
+   ret = rvin_dma_register(vin, irq);
if (ret)
return ret;
 
@@ -260,7 +260,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
 
return 0;
 error:
-   rvin_dma_remove(vin);
+   rvin_dma_unregister(vin);
v4l2_async_notifier_cleanup(>notifier);
 
return ret;
@@ -275,7 +275,7 @@ static int rcar_vin_remove(struct platform_device *pdev)
v4l2_async_notifier_unregister(>notifier);
v4l2_async_notifier_cleanup(>notifier);
 
-   rvin_dma_remove(vin);
+   rvin_dma_unregister(vin);
 
return 0;
 }
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 23fdff7a7370842e..d701b52d198243b5 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -1153,14 +1153,14 @@ static const struct vb2_ops rvin_qops = {
.wait_finish= vb2_ops_wait_finish,
 };
 
-void rvin_dma_remove(struct rvin_dev *vin)
+void rvin_dma_unregister(struct rvin_dev *vin)
 {
mutex_destroy(>lock);
 
v4l2_device_unregister(>v4l2_dev);
 }
 
-int rvin_dma_probe(struct rvin_dev *vin, int irq)
+int rvin_dma_register(struct rvin_dev *vin, int irq)
 {
struct vb2_queue *q = >queue;
int i, ret;
@@ -1208,7 +1208,7 @@ int rvin_dma_probe(struct rvin_dev *vin, int irq)
 
return 0;
 error:
-   rvin_dma_remove(vin);
+   rvin_dma_unregister(vin);
 
return ret;
 }
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index b479b882da12f62d..178aecc94962abe2 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -839,7 +839,7 @@ static const struct v4l2_file_operations rvin_fops = {
.read   = vb2_fop_read,
 };
 
-void rvin_v4l2_remove(struct rvin_dev *vin)
+void rvin_v4l2_unregister(struct rvin_dev *vin)
 {
v4l2_info(>v4l2_dev, "Removing %s\n",
  video_device_node_name(>vdev));
@@ -866,7 +866,7 @@ static void rvin_notify(struct v4l2_subdev *sd,
}
 }
 
-int rvin_v4l2_probe(struct rvin_dev *vin)
+int rvin_v4l2_register(struct rvin_dev *vin)
 {
struct video_device *vdev = >vdev;
struct v4l2_subdev *sd = vin_to_source(vin);
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 5382078143fb3869..85cb7ec53d2b08b5 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -153,11 +153,11 @@ struct rvin_dev {
 #define vin_warn(d, fmt, arg...)   dev_warn(d->dev, fmt, ##arg)
 #define vin_err(d, fmt, arg...)dev_err(d->dev, fmt, ##arg)
 
-int rvin_dma_probe(struct rvin_dev *vin, int irq);
-void rvin_dma_remove(struct rvin_dev *vin);
+int rvin_dma_register(struct rvin_dev *vin, int irq);
+void rvin_dma_unregister(struct rvin_dev *vin);
 
-int rvin_v4l2_probe(struct rvin_dev *vin);
-void rvin_v4l2_remove(struct rvin_dev *vin);
+int rvin_v4l2_register(struct rvin_dev *vin);
+void rvin_v4l2_unregister(struct rvin_dev *vin);
 
 const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
 
-- 
2.15.0



[PATCH v8 11/28] rcar-vin: do not allow changing scaling and composing while streaming

2017-11-29 Thread Niklas Söderlund
It is possible on Gen2 to change the registers controlling composing and
scaling while the stream is running. It is however not a good idea to do
so and could result in trouble. There are also no good reasons to allow
this, remove immediate reflection in hardware registers from
vidioc_s_selection and only configure scaling and composing when the
stream starts.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-dma.c  | 2 +-
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 ---
 drivers/media/platform/rcar-vin/rcar-vin.h  | 3 ---
 3 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index fd14be20a6604d7a..7be5080f742825fb 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -514,7 +514,7 @@ static void rvin_set_coeff(struct rvin_dev *vin, unsigned 
short xs)
rvin_write(vin, p_set->coeff_set[23], VNC8C_REG);
 }
 
-void rvin_crop_scale_comp(struct rvin_dev *vin)
+static void rvin_crop_scale_comp(struct rvin_dev *vin)
 {
u32 xs, ys;
 
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 254fa1c8770275a5..d6298c684ab2d731 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -436,9 +436,6 @@ static int rvin_s_selection(struct file *file, void *fh,
return -EINVAL;
}
 
-   /* HW supports modifying configuration while running */
-   rvin_crop_scale_comp(vin);
-
return 0;
 }
 
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 36d0f0cc4ce01a6e..67541b483ee43c52 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -175,7 +175,4 @@ void rvin_v4l2_unregister(struct rvin_dev *vin);
 
 const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
 
-/* Cropping, composing and scaling */
-void rvin_crop_scale_comp(struct rvin_dev *vin);
-
 #endif
-- 
2.15.0



[PATCH v8 13/28] rcar-vin: fix handling of single field frames (top, bottom and alternate fields)

2017-11-29 Thread Niklas Söderlund
There was never proper support in the VIN driver to deliver ALTERNATING
field format to user-space, remove this field option. For sources using
this field format instead use the VIN hardware feature of combining the
fields to an interlaced format. This mode of operation was previously
the default behavior and ALTERNATING was only delivered to user-space if
explicitly requested. Allowing this to be explicitly requested was a
mistake and was never properly tested and never worked due to the
constraints put on the field format when it comes to sequence numbers and
timestamps etc.

The height should not be cut in half for the format for TOP or BOTTOM
fields settings. This was a mistake and it was made visible by the
scaling refactoring. Correct behavior is that the user should request a
frame size that fits the half height frame reflected in the field
setting. If not the VIN will do its best to scale the top or bottom to
the requested format and cropping and scaling do not work as expected.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-dma.c  | 15 +
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 48 +++--
 2 files changed, 19 insertions(+), 44 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 7be5080f742825fb..e6478088d9464221 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -617,7 +617,6 @@ static int rvin_setup(struct rvin_dev *vin)
case V4L2_FIELD_INTERLACED_BT:
vnmc = VNMC_IM_FULL | VNMC_FOC;
break;
-   case V4L2_FIELD_ALTERNATE:
case V4L2_FIELD_NONE:
if (vin->continuous) {
vnmc = VNMC_IM_ODD_EVEN;
@@ -757,18 +756,6 @@ static int rvin_get_active_slot(struct rvin_dev *vin, u32 
vnms)
return 0;
 }
 
-static enum v4l2_field rvin_get_active_field(struct rvin_dev *vin, u32 vnms)
-{
-   if (vin->format.field == V4L2_FIELD_ALTERNATE) {
-   /* If FS is set it's a Even field */
-   if (vnms & VNMS_FS)
-   return V4L2_FIELD_BOTTOM;
-   return V4L2_FIELD_TOP;
-   }
-
-   return vin->format.field;
-}
-
 static void rvin_set_slot_addr(struct rvin_dev *vin, int slot, dma_addr_t addr)
 {
const struct rvin_video_format *fmt;
@@ -941,7 +928,7 @@ static irqreturn_t rvin_irq(int irq, void *data)
goto done;
 
/* Capture frame */
-   vin->queue_buf[slot]->field = rvin_get_active_field(vin, vnms);
+   vin->queue_buf[slot]->field = vin->format.field;
vin->queue_buf[slot]->sequence = sequence;
vin->queue_buf[slot]->vb2_buf.timestamp = ktime_get_ns();
vb2_buffer_done(>queue_buf[slot]->vb2_buf, VB2_BUF_STATE_DONE);
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 9cf9ff48ac1e2f4f..37fe1f6c646b0ea3 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -102,6 +102,24 @@ static int rvin_get_sd_format(struct rvin_dev *vin, struct 
v4l2_pix_format *pix)
if (ret)
return ret;
 
+   switch (fmt.format.field) {
+   case V4L2_FIELD_TOP:
+   case V4L2_FIELD_BOTTOM:
+   case V4L2_FIELD_NONE:
+   case V4L2_FIELD_INTERLACED_TB:
+   case V4L2_FIELD_INTERLACED_BT:
+   case V4L2_FIELD_INTERLACED:
+   break;
+   case V4L2_FIELD_ALTERNATE:
+   /* Use VIN hardware to combine the two fields */
+   fmt.format.field = V4L2_FIELD_INTERLACED;
+   fmt.format.height *= 2;
+   break;
+   default:
+   vin->format.field = V4L2_FIELD_NONE;
+   break;
+   }
+
v4l2_fill_pix_format(pix, );
 
return 0;
@@ -115,33 +133,6 @@ static int rvin_reset_format(struct rvin_dev *vin)
if (ret)
return ret;
 
-   /*
-* If the subdevice uses ALTERNATE field mode and G_STD is
-* implemented use the VIN HW to combine the two fields to
-* one INTERLACED frame. The ALTERNATE field mode can still
-* be requested in S_FMT and be respected, this is just the
-* default which is applied at probing or when S_STD is called.
-*/
-   if (vin->format.field == V4L2_FIELD_ALTERNATE &&
-   v4l2_subdev_has_op(vin_to_source(vin), video, g_std))
-   vin->format.field = V4L2_FIELD_INTERLACED;
-
-   switch (vin->format.field) {
-   case V4L2_FIELD_TOP:
-   case V4L2_FIELD_BOTTOM:
-   case V4L2_FIELD_ALTERNATE:
-   vin->format.height /= 2;
-   break;
-   case V4L2_FIELD_NONE:
-   case V4L2_FIELD_INTERLACED_TB:
-   case V4L2_FIELD_INTERLACED_BT:
-   case 

[PATCH v8 04/28] rcar-vin: move subdevice handling to async callbacks

2017-11-29 Thread Niklas Söderlund
In preparation for Gen3 support move the subdevice initialization and
clean up from rvin_v4l2_{register,unregister}() directly to the async
callbacks. This simplifies the addition of Gen3 support as the
rvin_v4l2_register() can be shared for both Gen2 and Gen3 while direct
subdevice control are only used on Gen2.

While moving this code drop a large comment which is copied from the
framework documentation and fold rvin_mbus_supported() into its only
caller.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 105 ++--
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  35 --
 2 files changed, 67 insertions(+), 73 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 6d99542ec74b49a7..6ab51acd676641ec 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -46,47 +46,11 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int 
direction)
return -EINVAL;
 }
 
-static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
-{
-   struct v4l2_subdev *sd = entity->subdev;
-   struct v4l2_subdev_mbus_code_enum code = {
-   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
-   };
-
-   code.index = 0;
-   code.pad = entity->source_pad;
-   while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, )) {
-   code.index++;
-   switch (code.code) {
-   case MEDIA_BUS_FMT_YUYV8_1X16:
-   case MEDIA_BUS_FMT_UYVY8_2X8:
-   case MEDIA_BUS_FMT_UYVY10_2X10:
-   case MEDIA_BUS_FMT_RGB888_1X24:
-   entity->code = code.code;
-   return true;
-   default:
-   break;
-   }
-   }
-
-   return false;
-}
-
 static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
 {
struct rvin_dev *vin = notifier_to_vin(notifier);
int ret;
 
-   /* Verify subdevices mbus format */
-   if (!rvin_mbus_supported(vin->digital)) {
-   vin_err(vin, "Unsupported media bus format for %s\n",
-   vin->digital->subdev->name);
-   return -EINVAL;
-   }
-
-   vin_dbg(vin, "Found media bus format for %s: %d\n",
-   vin->digital->subdev->name, vin->digital->code);
-
ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
if (ret < 0) {
vin_err(vin, "Failed to register subdev nodes\n");
@@ -103,8 +67,16 @@ static void rvin_digital_notify_unbind(struct 
v4l2_async_notifier *notifier,
struct rvin_dev *vin = notifier_to_vin(notifier);
 
vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
+
+   mutex_lock(>lock);
+
rvin_v4l2_unregister(vin);
+   v4l2_ctrl_handler_free(>ctrl_handler);
+
+   vin->vdev.ctrl_handler = NULL;
vin->digital->subdev = NULL;
+
+   mutex_unlock(>lock);
 }
 
 static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
@@ -112,12 +84,14 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
 struct v4l2_async_subdev *asd)
 {
struct rvin_dev *vin = notifier_to_vin(notifier);
+   struct v4l2_subdev_mbus_code_enum code = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
int ret;
 
v4l2_set_subdev_hostdata(subdev, vin);
 
/* Find source and sink pad of remote subdevice */
-
ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
if (ret < 0)
return ret;
@@ -126,21 +100,74 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
vin->digital->sink_pad = ret < 0 ? 0 : ret;
 
+   /* Find compatible subdevices mbus format */
+   vin->digital->code = 0;
+   code.index = 0;
+   code.pad = vin->digital->source_pad;
+   while (!vin->digital->code &&
+  !v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
+   code.index++;
+   switch (code.code) {
+   case MEDIA_BUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_UYVY10_2X10:
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   vin->digital->code = code.code;
+   vin_dbg(vin, "Found media bus format for %s: %d\n",
+   subdev->name, vin->digital->code);
+   break;
+   default:
+   break;
+   }
+   }
+
+   if (!vin->digital->code) {
+   vin_err(vin, "Unsupported media bus format for %s\n",
+   subdev->name);
+   return -EINVAL;
+   }
+
+   /* Read tvnorms */
+   ret = 

[PATCH v8 03/28] rcar-vin: unregister video device on driver removal

2017-11-29 Thread Niklas Söderlund
If the video device was registered by the complete() callback it should
be unregistered when the driver is removed. Protect from printing a
uninitialized video device node name by adding a checking in
rvin_v4l2_unregister() by checking that the video device is registered.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 2 ++
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index f7a4c21909da6923..6d99542ec74b49a7 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -272,6 +272,8 @@ static int rcar_vin_remove(struct platform_device *pdev)
 
pm_runtime_disable(>dev);
 
+   rvin_v4l2_unregister(vin);
+
v4l2_async_notifier_unregister(>notifier);
v4l2_async_notifier_cleanup(>notifier);
 
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 178aecc94962abe2..32a658214f48fa49 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -841,6 +841,9 @@ static const struct v4l2_file_operations rvin_fops = {
 
 void rvin_v4l2_unregister(struct rvin_dev *vin)
 {
+   if (!video_is_registered(>vdev))
+   return;
+
v4l2_info(>v4l2_dev, "Removing %s\n",
  video_device_node_name(>vdev));
 
-- 
2.15.0



[PATCH v8 00/28] rcar-vin: Add Gen3 with media controller

2017-11-29 Thread Niklas Söderlund
Hi,

This series adds Gen3 VIN support to rcar-vin driver for Renesas r8a7795,
r8a7796 and r8a77970. It is based on the media-tree and depends on some 
of Fabrizio Castro patches as they touches the order of the compatible 
strings in the documentation to reduce merge conflicts. The dependencies 
are:

[PATCH v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list
[PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support for 
r8a774[35]

The driver is tested on Renesas H3 (r8a7795, ES2.0),
M3-W (r8a7796) together with the rcar-csi2 driver (posted separately and
not yet upstream) and the Salvator-X onboard ADV7482. It is also tested 
on the V3M (r8a77970) on the Eagle board together with its expansion 
board with a ADV7482.

It is possible to capture both CVBS and HDMI video streams,
v4l2-compliance passes with no errors and media-ctl can be used to
change the routing and formats for the different entities in the media
graph.

Gen2 compatibility is verified on Koelsch and no problems where found,
video can be captured just like before and v4l2-compliance passes
without errors or warnings just like before this series.

I have started on a very basic test suite for the VIN driver at:

  https://git.ragnatech.se/vin-tests

And as before the state of the driver and information about how to test
it can be found on the elinux wiki:

  http://elinux.org/R-Car/Tests:rcar-vin

* Changes since v7
- Dropped '[PATCH v7 02/25] rcar-vin: register the video device at probe time'
- Add patch which renames four badly name functions. Some of the 
  renaming was in v7 part of the dropped patch 02/25. Make it a own 
  patch and rename all badly named functions in one patch.
- Add patch to replace part of the functionality of the dropped patch v7 
  02/25. The new patch keeps the subdevice (un)registration calls in the 
  async callbacks bind() and unbind() but moves the direct subdevice 
  initialization which only is used on Gen2 from the Gen2 and Gen3 
  shared rvin_v4l2_register().
- Add patch to enable Renesas V3M (r8a77970)
- Patch 'rcar-vin: parse Gen3 OF and setup media graph' have had code 
  additions since v7 since it now registers the video devices in the 
  async complete() callback instead of at probe time as an effect of 
  dropping v7 02/25.
  - The complete() callback now register all video devices.
  - The unbind() callback now unregister all video devices.
  - A new member '*notifier' is added to struct rvin_group which keeps 
track of which rcar-vin instance have registered its notifier on the 
groups behalf.
  For the reason above all Reviewed-by tags have been dropped for this 
  patch.
- Replaced all kernel messages which used of_node_full_name() as now 
  only returns the basename and not till full path, thanks Geert.

printk("%s", of_node_full_name(ep)); -> printk("%pOF", ep);

- Added Reviewed-by tags from Hans, big thanks!

* Changes since v6
- Rebase ontop of latest media-tree which brings in the use of the
  fwnode async helpers for Gen2.
- Updated DT binding documentation, thanks Laurent for very helpful
  input!
- Removed help text which where copied in from v4l2_ctrl_handler_init()
  documentation when moving that code block, this was a residue from the
  soc_camera conversion and should have been removed at that time.
- Removed bad check of tvnorms which disables IOCTLs if it's not set,
  this was a residue from soc_camera conversion and have use in the
  current driver.
- Moved all subdevice initialization from complete to bound handler
  while improving the unbind handler. With this move all operations of
  the ctrl_handler from the subdevice is handled in either bound or
  unbind removing races pointed out by Laurent.
- Renamed rvin_v4l2_probe() -> rvin_v4l2_register() and
  rvin_v4l2_remove() -> rvin_v4l2_unregister().
- Fold rvin_mbus_supported() into its only caller.
- Sort compatible string entries in ascending order.
- Improved documentation for struct rvin_group_chsel.
- Clarify comment in rvin_group_csi_pad_to_chan().
- Make use of of_device_get_match_data() as suggested by Geert.
- Fixed spelling mistakes.
- Added review tags from Hans.

* Changes since v5
- Extract and make use of common format checking for both Gen2 and Gen3.
- Assign pad at declaration time in rvin_get_sd_format()
- Always call pm_runtime_{get_sync,put}() and v4l2_pipeline_pm_use()
  when opening/closing a video device, remove the check of
  v4l2_fh_is_singular_file().
- Make rvin_set_chsel() return void instead of int since it always
  return 0.
- Simplify the VIN group allocator functions.
- Make the group notifier callbacks and setup more robust.
- Moved the video device registration back to probe time.
- Add H3 ES2.0 support.
- Fix handling of single field formats (top, bottom, alternate) as this
  was obviously wrong before but hidden by the Gen2 scaler support.
- Added review tags from Kieran.

* Changes since v4 (Not posted to ML)
- Updated to the new fwnode functions.
- 

[PATCH v8 12/28] rcar-vin: read subdevice format for crop only when needed

2017-11-29 Thread Niklas Söderlund
Instead of caching the subdevice format each time the video device
format is set read it directly when it's needed. As it turns out the
format is only needed when figuring out the max rectangle for cropping.

This simplifies the code and makes it clearer what the source format is
used for.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 88 ++---
 drivers/media/platform/rcar-vin/rcar-vin.h  | 12 
 2 files changed, 42 insertions(+), 58 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index d6298c684ab2d731..9cf9ff48ac1e2f4f 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -90,24 +90,30 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format 
*pix)
  * V4L2
  */
 
-static int rvin_reset_format(struct rvin_dev *vin)
+static int rvin_get_sd_format(struct rvin_dev *vin, struct v4l2_pix_format 
*pix)
 {
struct v4l2_subdev_format fmt = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   .pad = vin->digital->source_pad,
};
-   struct v4l2_mbus_framefmt *mf = 
int ret;
 
-   fmt.pad = vin->digital->source_pad;
-
ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
if (ret)
return ret;
 
-   vin->format.width   = mf->width;
-   vin->format.height  = mf->height;
-   vin->format.colorspace  = mf->colorspace;
-   vin->format.field   = mf->field;
+   v4l2_fill_pix_format(pix, );
+
+   return 0;
+}
+
+static int rvin_reset_format(struct rvin_dev *vin)
+{
+   int ret;
+
+   ret = rvin_get_sd_format(vin, >format);
+   if (ret)
+   return ret;
 
/*
 * If the subdevice uses ALTERNATE field mode and G_STD is
@@ -137,12 +143,12 @@ static int rvin_reset_format(struct rvin_dev *vin)
}
 
vin->crop.top = vin->crop.left = 0;
-   vin->crop.width = mf->width;
-   vin->crop.height = mf->height;
+   vin->crop.width = vin->format.width;
+   vin->crop.height = vin->format.height;
 
vin->compose.top = vin->compose.left = 0;
-   vin->compose.width = mf->width;
-   vin->compose.height = mf->height;
+   vin->compose.width = vin->format.width;
+   vin->compose.height = vin->format.height;
 
vin->format.bytesperline = rvin_format_bytesperline(>format);
vin->format.sizeimage = rvin_format_sizeimage(>format);
@@ -151,9 +157,7 @@ static int rvin_reset_format(struct rvin_dev *vin)
 }
 
 static int __rvin_try_format_source(struct rvin_dev *vin,
-   u32 which,
-   struct v4l2_pix_format *pix,
-   struct rvin_source_fmt *source)
+   u32 which, struct v4l2_pix_format *pix)
 {
struct v4l2_subdev *sd;
struct v4l2_subdev_pad_config *pad_cfg;
@@ -186,25 +190,15 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
v4l2_fill_pix_format(pix, );
 
pix->field = field;
-
-   source->width = pix->width;
-   source->height = pix->height;
-
pix->width = width;
pix->height = height;
-
-   vin_dbg(vin, "Source resolution: %ux%u\n", source->width,
-   source->height);
-
 done:
v4l2_subdev_free_pad_config(pad_cfg);
return ret;
 }
 
 static int __rvin_try_format(struct rvin_dev *vin,
-u32 which,
-struct v4l2_pix_format *pix,
-struct rvin_source_fmt *source)
+u32 which, struct v4l2_pix_format *pix)
 {
u32 walign;
int ret;
@@ -225,7 +219,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
pix->sizeimage = 0;
 
/* Limit to source capabilities */
-   ret = __rvin_try_format_source(vin, which, pix, source);
+   ret = __rvin_try_format_source(vin, which, pix);
if (ret)
return ret;
 
@@ -234,7 +228,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
case V4L2_FIELD_BOTTOM:
case V4L2_FIELD_ALTERNATE:
pix->height /= 2;
-   source->height /= 2;
break;
case V4L2_FIELD_NONE:
case V4L2_FIELD_INTERLACED_TB:
@@ -286,30 +279,23 @@ static int rvin_try_fmt_vid_cap(struct file *file, void 
*priv,
struct v4l2_format *f)
 {
struct rvin_dev *vin = video_drvdata(file);
-   struct rvin_source_fmt source;
 
-   return __rvin_try_format(vin, V4L2_SUBDEV_FORMAT_TRY, >fmt.pix,
-);
+   return __rvin_try_format(vin, V4L2_SUBDEV_FORMAT_TRY, >fmt.pix);
 }
 
 static int rvin_s_fmt_vid_cap(struct file *file, void *priv,
 

[PATCH v8 07/28] rcar-vin: change name of video device

2017-11-29 Thread Niklas Söderlund
The rcar-vin driver needs to be part of a media controller to support
Gen3. Give each VIN instance a unique name so it can be referenced from
userspace.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Kieran Bingham 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 59ec6d3d119590aa..19de99133f048960 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -876,7 +876,8 @@ int rvin_v4l2_register(struct rvin_dev *vin)
vdev->fops = _fops;
vdev->v4l2_dev = >v4l2_dev;
vdev->queue = >queue;
-   strlcpy(vdev->name, KBUILD_MODNAME, sizeof(vdev->name));
+   snprintf(vdev->name, sizeof(vdev->name), "%s %s", KBUILD_MODNAME,
+dev_name(vin->dev));
vdev->release = video_device_release_empty;
vdev->ioctl_ops = _ioctl_ops;
vdev->lock = >lock;
-- 
2.15.0



[PATCH v8 10/28] rcar-vin: do not reset crop and compose when setting format

2017-11-29 Thread Niklas Söderlund
It was a bad idea to reset the crop and compose settings when a new
format is set. This would overwrite any crop/compose set by s_select and
cause unexpected behaviors, remove it. Also fold the reset helper in to
the only remaining caller.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 1c5e7f6d5b963740..254fa1c8770275a5 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -90,17 +90,6 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format *pix)
  * V4L2
  */
 
-static void rvin_reset_crop_compose(struct rvin_dev *vin)
-{
-   vin->crop.top = vin->crop.left = 0;
-   vin->crop.width = vin->source.width;
-   vin->crop.height = vin->source.height;
-
-   vin->compose.top = vin->compose.left = 0;
-   vin->compose.width = vin->format.width;
-   vin->compose.height = vin->format.height;
-}
-
 static int rvin_reset_format(struct rvin_dev *vin)
 {
struct v4l2_subdev_format fmt = {
@@ -147,7 +136,13 @@ static int rvin_reset_format(struct rvin_dev *vin)
break;
}
 
-   rvin_reset_crop_compose(vin);
+   vin->crop.top = vin->crop.left = 0;
+   vin->crop.width = mf->width;
+   vin->crop.height = mf->height;
+
+   vin->compose.top = vin->compose.left = 0;
+   vin->compose.width = mf->width;
+   vin->compose.height = mf->height;
 
vin->format.bytesperline = rvin_format_bytesperline(>format);
vin->format.sizeimage = rvin_format_sizeimage(>format);
@@ -317,8 +312,6 @@ static int rvin_s_fmt_vid_cap(struct file *file, void *priv,
 
vin->format = f->fmt.pix;
 
-   rvin_reset_crop_compose(vin);
-
return 0;
 }
 
-- 
2.15.0



[PATCH v8 16/28] rcar-vin: add function to manipulate Gen3 chsel value

2017-11-29 Thread Niklas Söderlund
On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
feature of this register is that it's only present in the VIN0 and VIN4
instances. The register in VIN0 controls the routing for VIN0-3 and the
register in VIN4 controls routing for VIN4-7.

To be able to control routing from a media device this function is need
to control runtime PM for the subgroup master (VIN0 and VIN4). The
subgroup master must be switched on before the register is manipulated,
once the operation is complete it's safe to switch the master off and
the new routing will still be in effect.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 25 +
 drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
 2 files changed, 27 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index ace95d5b543a17e3..d2788d8bb9565aaa 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -1228,3 +1229,27 @@ int rvin_dma_register(struct rvin_dev *vin, int irq)
 
return ret;
 }
+
+/* 
-
+ * Gen3 CHSEL manipulation
+ */
+
+void rvin_set_chsel(struct rvin_dev *vin, u8 chsel)
+{
+   u32 ifmd, vnmc;
+
+   pm_runtime_get_sync(vin->dev);
+
+   /* Make register writes take effect immediately */
+   vnmc = rvin_read(vin, VNMC_REG) & ~VNMC_VUP;
+   rvin_write(vin, vnmc, VNMC_REG);
+
+   ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
+   VNCSI_IFMD_CSI_CHSEL(chsel);
+
+   rvin_write(vin, ifmd, VNCSI_IFMD_REG);
+
+   vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
+
+   pm_runtime_put(vin->dev);
+}
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index a440effe4b86af31..7819c760c2c13422 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -163,4 +163,6 @@ void rvin_v4l2_unregister(struct rvin_dev *vin);
 
 const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
 
+void rvin_set_chsel(struct rvin_dev *vin, u8 chsel);
+
 #endif
-- 
2.15.0



[PATCH v8 15/28] rcar-vin: enable Gen3 hardware configuration

2017-11-29 Thread Niklas Söderlund
Add the register needed to work with Gen3 hardware. This patch adds
the logic for how to work with the Gen3 hardware. More work is required
to enable the subdevice structure needed to configure capturing.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 94 --
 drivers/media/platform/rcar-vin/rcar-vin.h |  1 +
 2 files changed, 64 insertions(+), 31 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index d7660f485a2df9e4..ace95d5b543a17e3 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -33,21 +33,23 @@
 #define VNELPRC_REG0x10/* Video n End Line Pre-Clip Register */
 #define VNSPPRC_REG0x14/* Video n Start Pixel Pre-Clip Register */
 #define VNEPPRC_REG0x18/* Video n End Pixel Pre-Clip Register */
-#define VNSLPOC_REG0x1C/* Video n Start Line Post-Clip Register */
-#define VNELPOC_REG0x20/* Video n End Line Post-Clip Register */
-#define VNSPPOC_REG0x24/* Video n Start Pixel Post-Clip Register */
-#define VNEPPOC_REG0x28/* Video n End Pixel Post-Clip Register */
 #define VNIS_REG   0x2C/* Video n Image Stride Register */
 #define VNMB_REG(m)(0x30 + ((m) << 2)) /* Video n Memory Base m Register */
 #define VNIE_REG   0x40/* Video n Interrupt Enable Register */
 #define VNINTS_REG 0x44/* Video n Interrupt Status Register */
 #define VNSI_REG   0x48/* Video n Scanline Interrupt Register */
 #define VNMTC_REG  0x4C/* Video n Memory Transfer Control Register */
-#define VNYS_REG   0x50/* Video n Y Scale Register */
-#define VNXS_REG   0x54/* Video n X Scale Register */
 #define VNDMR_REG  0x58/* Video n Data Mode Register */
 #define VNDMR2_REG 0x5C/* Video n Data Mode Register 2 */
 #define VNUVAOF_REG0x60/* Video n UV Address Offset Register */
+
+/* Register offsets specific for Gen2 */
+#define VNSLPOC_REG0x1C/* Video n Start Line Post-Clip Register */
+#define VNELPOC_REG0x20/* Video n End Line Post-Clip Register */
+#define VNSPPOC_REG0x24/* Video n Start Pixel Post-Clip Register */
+#define VNEPPOC_REG0x28/* Video n End Pixel Post-Clip Register */
+#define VNYS_REG   0x50/* Video n Y Scale Register */
+#define VNXS_REG   0x54/* Video n X Scale Register */
 #define VNC1A_REG  0x80/* Video n Coefficient Set C1A Register */
 #define VNC1B_REG  0x84/* Video n Coefficient Set C1B Register */
 #define VNC1C_REG  0x88/* Video n Coefficient Set C1C Register */
@@ -73,9 +75,13 @@
 #define VNC8B_REG  0xF4/* Video n Coefficient Set C8B Register */
 #define VNC8C_REG  0xF8/* Video n Coefficient Set C8C Register */
 
+/* Register offsets specific for Gen3 */
+#define VNCSI_IFMD_REG 0x20 /* Video n CSI2 Interface Mode Register */
 
 /* Register bit fields for R-Car VIN */
 /* Video n Main Control Register bits */
+#define VNMC_DPINE (1 << 27) /* Gen3 specific */
+#define VNMC_SCLE  (1 << 26) /* Gen3 specific */
 #define VNMC_FOC   (1 << 21)
 #define VNMC_YCAL  (1 << 19)
 #define VNMC_INF_YUV8_BT656(0 << 16)
@@ -119,6 +125,13 @@
 #define VNDMR2_FTEV(1 << 17)
 #define VNDMR2_VLV(n)  ((n & 0xf) << 12)
 
+/* Video n CSI2 Interface Mode Register (Gen3) */
+#define VNCSI_IFMD_DES2(1 << 27)
+#define VNCSI_IFMD_DES1(1 << 26)
+#define VNCSI_IFMD_DES0(1 << 25)
+#define VNCSI_IFMD_CSI_CHSEL(n) ((n & 0xf) << 0)
+#define VNCSI_IFMD_CSI_CHSEL_MASK 0xf
+
 struct rvin_buffer {
struct vb2_v4l2_buffer vb;
struct list_head list;
@@ -514,28 +527,10 @@ static void rvin_set_coeff(struct rvin_dev *vin, unsigned 
short xs)
rvin_write(vin, p_set->coeff_set[23], VNC8C_REG);
 }
 
-static void rvin_crop_scale_comp(struct rvin_dev *vin)
+static void rvin_crop_scale_comp_gen2(struct rvin_dev *vin)
 {
u32 xs, ys;
 
-   /* Set Start/End Pixel/Line Pre-Clip */
-   rvin_write(vin, vin->crop.left, VNSPPRC_REG);
-   rvin_write(vin, vin->crop.left + vin->crop.width - 1, VNEPPRC_REG);
-   switch (vin->format.field) {
-   case V4L2_FIELD_INTERLACED:
-   case V4L2_FIELD_INTERLACED_TB:
-   case V4L2_FIELD_INTERLACED_BT:
-   rvin_write(vin, vin->crop.top / 2, VNSLPRC_REG);
-   rvin_write(vin, (vin->crop.top + vin->crop.height) / 2 - 1,
-  VNELPRC_REG);
-   break;
-   default:
-   rvin_write(vin, vin->crop.top, VNSLPRC_REG);
-   rvin_write(vin, vin->crop.top + vin->crop.height - 1,
-  VNELPRC_REG);
-   break;
-   }
-
/* Set scaling coefficient */

[PATCH v8 05/28] rcar-vin: move chip information to own struct

2017-11-29 Thread Niklas Söderlund
When Gen3 support is added to the driver more than chip ID will be
different for the different SoCs. To avoid a lot of if statements in the
code create a struct chip_info to store this information.

And while we are at it sort the compatible string entries and make use
of of_device_get_match_data() which will always work as the driver is DT
only, so there's always a valid match.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Kieran Bingham 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 54 ++---
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  3 +-
 drivers/media/platform/rcar-vin/rcar-vin.h  | 12 +--
 3 files changed, 53 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 6ab51acd676641ec..73c1700a409bfd35 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -230,21 +230,53 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
  * Platform Device Driver
  */
 
+static const struct rvin_info rcar_info_h1 = {
+   .chip = RCAR_H1,
+};
+
+static const struct rvin_info rcar_info_m1 = {
+   .chip = RCAR_M1,
+};
+
+static const struct rvin_info rcar_info_gen2 = {
+   .chip = RCAR_GEN2,
+};
+
 static const struct of_device_id rvin_of_id_table[] = {
-   { .compatible = "renesas,vin-r8a7794", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7793", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7791", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7790", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7779", .data = (void *)RCAR_H1 },
-   { .compatible = "renesas,vin-r8a7778", .data = (void *)RCAR_M1 },
-   { .compatible = "renesas,rcar-gen2-vin", .data = (void *)RCAR_GEN2 },
+   {
+   .compatible = "renesas,vin-r8a7778",
+   .data = _info_m1,
+   },
+   {
+   .compatible = "renesas,vin-r8a7779",
+   .data = _info_h1,
+   },
+   {
+   .compatible = "renesas,vin-r8a7790",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,vin-r8a7791",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,vin-r8a7793",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,vin-r8a7794",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,rcar-gen2-vin",
+   .data = _info_gen2,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, rvin_of_id_table);
 
 static int rcar_vin_probe(struct platform_device *pdev)
 {
-   const struct of_device_id *match;
struct rvin_dev *vin;
struct resource *mem;
int irq, ret;
@@ -253,12 +285,8 @@ static int rcar_vin_probe(struct platform_device *pdev)
if (!vin)
return -ENOMEM;
 
-   match = of_match_device(of_match_ptr(rvin_of_id_table), >dev);
-   if (!match)
-   return -ENODEV;
-
vin->dev = >dev;
-   vin->chip = (enum chip_id)match->data;
+   vin->info = of_device_get_match_data(>dev);
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (mem == NULL)
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 4a0610a6b4503501..b1caa04921aa23bb 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -266,7 +266,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
pix->sizeimage = max_t(u32, pix->sizeimage,
   rvin_format_sizeimage(pix));
 
-   if (vin->chip == RCAR_M1 && pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
+   if (vin->info->chip == RCAR_M1 &&
+   pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
vin_err(vin, "pixel format XBGR32 not supported on M1\n");
return -EINVAL;
}
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 85cb7ec53d2b08b5..0d3949c8c08c8f63 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -88,11 +88,19 @@ struct rvin_graph_entity {
unsigned int sink_pad;
 };
 
+/**
+ * struct rvin_info - Information about the particular VIN implementation
+ * @chip:  type of VIN chip
+ */
+struct rvin_info {
+   enum chip_id chip;
+};
+
 /**
  * struct rvin_dev - Renesas VIN device structure
  * @dev:   (OF) device
  * @base:  device I/O register space remapped to virtual memory
- * @chip:  type of VIN chip
+ * @info:  info about VIN instance
 

[PATCH v8 09/28] rcar-vin: all Gen2 boards can scale simplify logic

2017-11-29 Thread Niklas Söderlund
The logic to preserve the requested format width and height are too
complex and come from a premature optimization for Gen3. All Gen2 SoC
can scale and the Gen3 implementation will not use these functions at
all so simply preserve the width and height when interacting with the
subdevice much like the field is preserved simplifies the logic quite a
bit.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-dma.c  |  8 
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 22 ++
 drivers/media/platform/rcar-vin/rcar-vin.h  |  2 --
 3 files changed, 10 insertions(+), 22 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index a7cda3922cb74baa..fd14be20a6604d7a 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -585,14 +585,6 @@ void rvin_crop_scale_comp(struct rvin_dev *vin)
0, 0);
 }
 
-void rvin_scale_try(struct rvin_dev *vin, struct v4l2_pix_format *pix,
-   u32 width, u32 height)
-{
-   /* All VIN channels on Gen2 have scalers */
-   pix->width = width;
-   pix->height = height;
-}
-
 /* 
-
  * Hardware setup
  */
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 19de99133f048960..1c5e7f6d5b963740 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -166,6 +166,7 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
.which = which,
};
enum v4l2_field field;
+   u32 width, height;
int ret;
 
sd = vin_to_source(vin);
@@ -178,7 +179,10 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
 
format.pad = vin->digital->source_pad;
 
+   /* Allow the video device to override field and to scale */
field = pix->field;
+   width = pix->width;
+   height = pix->height;
 
ret = v4l2_subdev_call(sd, pad, set_fmt, pad_cfg, );
if (ret < 0 && ret != -ENOIOCTLCMD)
@@ -191,6 +195,9 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
source->width = pix->width;
source->height = pix->height;
 
+   pix->width = width;
+   pix->height = height;
+
vin_dbg(vin, "Source resolution: %ux%u\n", source->width,
source->height);
 
@@ -204,13 +211,9 @@ static int __rvin_try_format(struct rvin_dev *vin,
 struct v4l2_pix_format *pix,
 struct rvin_source_fmt *source)
 {
-   u32 rwidth, rheight, walign;
+   u32 walign;
int ret;
 
-   /* Requested */
-   rwidth = pix->width;
-   rheight = pix->height;
-
/* Keep current field if no specific one is asked for */
if (pix->field == V4L2_FIELD_ANY)
pix->field = vin->format.field;
@@ -248,10 +251,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
break;
}
 
-   /* If source can't match format try if VIN can scale */
-   if (source->width != rwidth || source->height != rheight)
-   rvin_scale_try(vin, pix, rwidth, rheight);
-
/* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
 
@@ -270,9 +269,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
return -EINVAL;
}
 
-   vin_dbg(vin, "Requested %ux%u Got %ux%u bpl: %d size: %d\n",
-   rwidth, rheight, pix->width, pix->height,
-   pix->bytesperline, pix->sizeimage);
+   vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
+   pix->width, pix->height, pix->bytesperline, pix->sizeimage);
 
return 0;
 }
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 646f897f5c05ec4e..36d0f0cc4ce01a6e 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -176,8 +176,6 @@ void rvin_v4l2_unregister(struct rvin_dev *vin);
 const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
 
 /* Cropping, composing and scaling */
-void rvin_scale_try(struct rvin_dev *vin, struct v4l2_pix_format *pix,
-   u32 width, u32 height);
 void rvin_crop_scale_comp(struct rvin_dev *vin);
 
 #endif
-- 
2.15.0



[PATCH v8 27/28] rcar-vin: enable support for r8a7796

2017-11-29 Thread Niklas Söderlund
Add the SoC specific information for Renesas r8a7796.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 .../devicetree/bindings/media/rcar_vin.txt |  1 +
 drivers/media/platform/rcar-vin/rcar-core.c| 64 ++
 2 files changed, 65 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 5a95d9668d2c7dfd..314743532bbb4523 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -20,6 +20,7 @@ on Gen3 to a CSI-2 receiver.
- "renesas,vin-r8a7793" for the R8A7793 device
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7795" for the R8A7795 device
+   - "renesas,vin-r8a7796" for the R8A7796 device
- "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
  device.
- "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 9da5aff33fd224f2..62eb89b36fbb2ee1 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1085,6 +1085,66 @@ static const struct rvin_info rcar_info_r8a7795es1 = {
},
 };
 
+static const struct rvin_info rcar_info_r8a7796 = {
+   .chip = RCAR_GEN3,
+   .use_mc = true,
+   .max_width = 4096,
+   .max_height = 4096,
+
+   .num_chsels = 5,
+   .chsels = {
+   {
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   }, {
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   }, {
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 2 },
+   { .csi = RVIN_CSI20, .chan = 2 },
+   }, {
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_NC, .chan = 1 },
+   { .csi = RVIN_CSI40, .chan = 3 },
+   { .csi = RVIN_CSI20, .chan = 3 },
+   }, {
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   }, {
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   }, {
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 2 },
+   { .csi = RVIN_CSI20, .chan = 2 },
+   }, {
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_NC, .chan = 1 },
+   { .csi = RVIN_CSI40, .chan = 3 },
+   { .csi = RVIN_CSI20, .chan = 3 },
+   },
+   },
+};
+
 static const struct of_device_id rvin_of_id_table[] = {
{
.compatible = "renesas,vin-r8a7778",
@@ -1118,6 +1178,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.compatible = "renesas,vin-r8a7795",
.data = _info_r8a7795,
},
+   {
+   .compatible = "renesas,vin-r8a7796",
+   .data = _info_r8a7796,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, rvin_of_id_table);
-- 
2.15.0



[PATCH v8 22/28] rcar-vin: add chsel information to rvin_info

2017-11-29 Thread Niklas Söderlund
Each Gen3 SoC has a limited set of predefined routing possibilities for
which CSI-2 device and virtual channel can be routed to which VIN
instance. Prepare to store this information in the struct rvin_info.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-vin.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 5f736a3500b6e10f..41bf24aa8a1a0aed 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -35,6 +35,9 @@
 /* Max number on VIN instances that can be in a system */
 #define RCAR_VIN_NUM 8
 
+/* Max number of CHSEL values for any Gen3 SoC */
+#define RCAR_CHSEL_MAX 6
+
 enum chip_id {
RCAR_H1,
RCAR_M1,
@@ -91,6 +94,22 @@ struct rvin_graph_entity {
 
 struct rvin_group;
 
+/** struct rvin_group_chsel - Map a CSI-2 receiver and channel to a CHSEL value
+ * @csi:   VIN internal number for CSI-2 device
+ * @chan:  Output channel of the CSI-2 receiver. Each R-Car CSI-2
+ * receiver has four output channels facing the VIN
+ * devices, each channel can carry one CSI-2 Virtual
+ * Channel (VC) and there are no correlation between
+ * output channel number and CSI-2 VC. It's up to the
+ * CSI-2 receiver driver to configure which VC is
+ * outputted on which channel, the VIN devices only
+ * cares about output channels.
+ */
+struct rvin_group_chsel {
+   enum rvin_csi_id csi;
+   unsigned int chan;
+};
+
 /**
  * struct rvin_info - Information about the particular VIN implementation
  * @chip:  type of VIN chip
@@ -98,6 +117,9 @@ struct rvin_group;
  *
  * max_width:  max input width the VIN supports
  * max_height: max input height the VIN supports
+ *
+ * num_chsels: number of possible chsel values for this VIN
+ * chsels: routing table VIN <-> CSI-2 for the chsel values
  */
 struct rvin_info {
enum chip_id chip;
@@ -105,6 +127,9 @@ struct rvin_info {
 
unsigned int max_width;
unsigned int max_height;
+
+   unsigned int num_chsels;
+   struct rvin_group_chsel chsels[RCAR_VIN_NUM][RCAR_CHSEL_MAX];
 };
 
 /**
-- 
2.15.0



[PATCH v8 18/28] rcar-vin: break out format alignment and checking

2017-11-29 Thread Niklas Söderlund
Part of the format alignment and checking can be shared with the Gen3
format handling. Break that part out to its own function. While doing
this clean up the checking and add more checks.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 98 +++--
 1 file changed, 51 insertions(+), 47 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 56c5183f55922e1d..0ffbf0c16fb7b00e 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -86,6 +86,56 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format *pix)
return pix->bytesperline * pix->height;
 }
 
+static int rvin_format_align(struct rvin_dev *vin, struct v4l2_pix_format *pix)
+{
+   u32 walign;
+
+   /* If requested format is not supported fallback to the default */
+   if (!rvin_format_from_pixel(pix->pixelformat)) {
+   vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",
+   pix->pixelformat, RVIN_DEFAULT_FORMAT);
+   pix->pixelformat = RVIN_DEFAULT_FORMAT;
+   }
+
+   switch (pix->field) {
+   case V4L2_FIELD_TOP:
+   case V4L2_FIELD_BOTTOM:
+   case V4L2_FIELD_NONE:
+   case V4L2_FIELD_INTERLACED_TB:
+   case V4L2_FIELD_INTERLACED_BT:
+   case V4L2_FIELD_INTERLACED:
+   break;
+   default:
+   pix->field = V4L2_FIELD_NONE;
+   break;
+   }
+
+   /* Check that colorspace is reasonable, if not keep current */
+   if (!pix->colorspace || pix->colorspace >= 0xff)
+   pix->colorspace = vin->format.colorspace;
+
+   /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
+   walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
+
+   /* Limit to VIN capabilities */
+   v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
+ >height, 4, vin->info->max_height, 2, 0);
+
+   pix->bytesperline = rvin_format_bytesperline(pix);
+   pix->sizeimage = rvin_format_sizeimage(pix);
+
+   if (vin->info->chip == RCAR_M1 &&
+   pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
+   vin_err(vin, "pixel format XBGR32 not supported on M1\n");
+   return -EINVAL;
+   }
+
+   vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
+   pix->width, pix->height, pix->bytesperline, pix->sizeimage);
+
+   return 0;
+}
+
 /* 
-
  * V4L2
  */
@@ -191,64 +241,18 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
 static int __rvin_try_format(struct rvin_dev *vin,
 u32 which, struct v4l2_pix_format *pix)
 {
-   u32 walign;
int ret;
 
/* Keep current field if no specific one is asked for */
if (pix->field == V4L2_FIELD_ANY)
pix->field = vin->format.field;
 
-   /* If requested format is not supported fallback to the default */
-   if (!rvin_format_from_pixel(pix->pixelformat)) {
-   vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",
-   pix->pixelformat, RVIN_DEFAULT_FORMAT);
-   pix->pixelformat = RVIN_DEFAULT_FORMAT;
-   }
-
-   /* Always recalculate */
-   pix->bytesperline = 0;
-   pix->sizeimage = 0;
-
/* Limit to source capabilities */
ret = __rvin_try_format_source(vin, which, pix);
if (ret)
return ret;
 
-   switch (pix->field) {
-   case V4L2_FIELD_TOP:
-   case V4L2_FIELD_BOTTOM:
-   case V4L2_FIELD_NONE:
-   case V4L2_FIELD_INTERLACED_TB:
-   case V4L2_FIELD_INTERLACED_BT:
-   case V4L2_FIELD_INTERLACED:
-   break;
-   default:
-   pix->field = V4L2_FIELD_NONE;
-   break;
-   }
-
-   /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
-   walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
-
-   /* Limit to VIN capabilities */
-   v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
- >height, 4, vin->info->max_height, 2, 0);
-
-   pix->bytesperline = max_t(u32, pix->bytesperline,
- rvin_format_bytesperline(pix));
-   pix->sizeimage = max_t(u32, pix->sizeimage,
-  rvin_format_sizeimage(pix));
-
-   if (vin->info->chip == RCAR_M1 &&
-   pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
-   vin_err(vin, "pixel format XBGR32 not supported on M1\n");
-   return -EINVAL;
-   }
-
-   vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
-   pix->width, pix->height, pix->bytesperline, 

[PATCH v8 26/28] rcar-vin: enable support for r8a7795

2017-11-29 Thread Niklas Söderlund
Add the SoC specific information for Renesas r8a7795 ES1.x and ES2.0.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/Kconfig |   2 +-
 drivers/media/platform/rcar-vin/rcar-core.c | 150 
 2 files changed, 151 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/Kconfig 
b/drivers/media/platform/rcar-vin/Kconfig
index af4c98b44d2e22cb..8fa7ee468c63afb9 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -6,7 +6,7 @@ config VIDEO_RCAR_VIN
select V4L2_FWNODE
---help---
  Support for Renesas R-Car Video Input (VIN) driver.
- Supports R-Car Gen2 SoCs.
+ Supports R-Car Gen2 and Gen3 SoCs.
 
  To compile this driver as a module, choose M here: the
  module will be called rcar-vin.
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 456f93d60b40fb80..9da5aff33fd224f2 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -956,6 +957,134 @@ static const struct rvin_info rcar_info_gen2 = {
.max_height = 2048,
 };
 
+static const struct rvin_info rcar_info_r8a7795 = {
+   .chip = RCAR_GEN3,
+   .use_mc = true,
+   .max_width = 4096,
+   .max_height = 4096,
+
+   .num_chsels = 5,
+   .chsels = {
+   {
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   }, {
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   }, {
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 2 },
+   { .csi = RVIN_CSI20, .chan = 2 },
+   }, {
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_CSI40, .chan = 3 },
+   { .csi = RVIN_CSI20, .chan = 3 },
+   }, {
+   { .csi = RVIN_CSI41, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI41, .chan = 1 },
+   { .csi = RVIN_CSI41, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   }, {
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI41, .chan = 1 },
+   { .csi = RVIN_CSI41, .chan = 0 },
+   { .csi = RVIN_CSI41, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   }, {
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_CSI41, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI41, .chan = 2 },
+   { .csi = RVIN_CSI20, .chan = 2 },
+   }, {
+   { .csi = RVIN_CSI41, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_CSI41, .chan = 3 },
+   { .csi = RVIN_CSI20, .chan = 3 },
+   },
+   },
+};
+
+static const struct rvin_info rcar_info_r8a7795es1 = {
+   .chip = RCAR_GEN3,
+   .use_mc = true,
+   .max_width = 4096,
+   .max_height = 4096,
+
+   .num_chsels = 6,
+   .chsels = {
+   {
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI21, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI21, .chan = 0 },
+   }, {
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI21, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, 

[PATCH v8 17/28] rcar-vin: add flag to switch to media controller mode

2017-11-29 Thread Niklas Söderlund
On Gen3 a media controller API needs to be used to allow userspace to
configure the subdevices in the pipeline instead of directly controlling
a single source subdevice, which is and will continue to be the mode of
operation on Gen2.

Prepare for these two modes of operation by adding a flag to struct
rvin_info which will control which mode to use.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 6 +-
 drivers/media/platform/rcar-vin/rcar-vin.h  | 2 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 7d49904cab9cb2d9..61f48ecc1ab815ec 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -232,18 +232,21 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
 
 static const struct rvin_info rcar_info_h1 = {
.chip = RCAR_H1,
+   .use_mc = false,
.max_width = 2048,
.max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_m1 = {
.chip = RCAR_M1,
+   .use_mc = false,
.max_width = 2048,
.max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_gen2 = {
.chip = RCAR_GEN2,
+   .use_mc = false,
.max_width = 2048,
.max_height = 2048,
 };
@@ -338,7 +341,8 @@ static int rcar_vin_remove(struct platform_device *pdev)
v4l2_async_notifier_unregister(>notifier);
v4l2_async_notifier_cleanup(>notifier);
 
-   v4l2_ctrl_handler_free(>ctrl_handler);
+   if (!vin->info->use_mc)
+   v4l2_ctrl_handler_free(>ctrl_handler);
 
rvin_dma_unregister(vin);
 
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 7819c760c2c13422..0747873c2b9cb74c 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -77,12 +77,14 @@ struct rvin_graph_entity {
 /**
  * struct rvin_info - Information about the particular VIN implementation
  * @chip:  type of VIN chip
+ * @use_mc:use media controller instead of controlling subdevice
  *
  * max_width:  max input width the VIN supports
  * max_height: max input height the VIN supports
  */
 struct rvin_info {
enum chip_id chip;
+   bool use_mc;
 
unsigned int max_width;
unsigned int max_height;
-- 
2.15.0



[PATCH v8 08/28] rcar-vin: move functions regarding scaling

2017-11-29 Thread Niklas Söderlund
In preparation of refactoring the scaling code move the code regarding
scaling to to the top of the file to avoid the need to add forward
declarations. No code is changed in this commit only whole functions
moved inside the same file.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 806 +++--
 1 file changed, 405 insertions(+), 401 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index d701b52d198243b5..a7cda3922cb74baa 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -138,305 +138,6 @@ static u32 rvin_read(struct rvin_dev *vin, u32 offset)
return ioread32(vin->base + offset);
 }
 
-static int rvin_setup(struct rvin_dev *vin)
-{
-   u32 vnmc, dmr, dmr2, interrupts;
-   v4l2_std_id std;
-   bool progressive = false, output_is_yuv = false, input_is_yuv = false;
-
-   switch (vin->format.field) {
-   case V4L2_FIELD_TOP:
-   vnmc = VNMC_IM_ODD;
-   break;
-   case V4L2_FIELD_BOTTOM:
-   vnmc = VNMC_IM_EVEN;
-   break;
-   case V4L2_FIELD_INTERLACED:
-   /* Default to TB */
-   vnmc = VNMC_IM_FULL;
-   /* Use BT if video standard can be read and is 60 Hz format */
-   if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
-   if (std & V4L2_STD_525_60)
-   vnmc = VNMC_IM_FULL | VNMC_FOC;
-   }
-   break;
-   case V4L2_FIELD_INTERLACED_TB:
-   vnmc = VNMC_IM_FULL;
-   break;
-   case V4L2_FIELD_INTERLACED_BT:
-   vnmc = VNMC_IM_FULL | VNMC_FOC;
-   break;
-   case V4L2_FIELD_ALTERNATE:
-   case V4L2_FIELD_NONE:
-   if (vin->continuous) {
-   vnmc = VNMC_IM_ODD_EVEN;
-   progressive = true;
-   } else {
-   vnmc = VNMC_IM_ODD;
-   }
-   break;
-   default:
-   vnmc = VNMC_IM_ODD;
-   break;
-   }
-
-   /*
-* Input interface
-*/
-   switch (vin->digital->code) {
-   case MEDIA_BUS_FMT_YUYV8_1X16:
-   /* BT.601/BT.1358 16bit YCbCr422 */
-   vnmc |= VNMC_INF_YUV16;
-   input_is_yuv = true;
-   break;
-   case MEDIA_BUS_FMT_UYVY8_2X8:
-   /* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
-   vnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?
-   VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
-   input_is_yuv = true;
-   break;
-   case MEDIA_BUS_FMT_RGB888_1X24:
-   vnmc |= VNMC_INF_RGB888;
-   break;
-   case MEDIA_BUS_FMT_UYVY10_2X10:
-   /* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
-   vnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?
-   VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
-   input_is_yuv = true;
-   break;
-   default:
-   break;
-   }
-
-   /* Enable VSYNC Field Toogle mode after one VSYNC input */
-   dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
-
-   /* Hsync Signal Polarity Select */
-   if (!(vin->digital->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
-   dmr2 |= VNDMR2_HPS;
-
-   /* Vsync Signal Polarity Select */
-   if (!(vin->digital->mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
-   dmr2 |= VNDMR2_VPS;
-
-   /*
-* Output format
-*/
-   switch (vin->format.pixelformat) {
-   case V4L2_PIX_FMT_NV16:
-   rvin_write(vin,
-  ALIGN(vin->format.width * vin->format.height, 0x80),
-  VNUVAOF_REG);
-   dmr = VNDMR_DTMD_YCSEP;
-   output_is_yuv = true;
-   break;
-   case V4L2_PIX_FMT_YUYV:
-   dmr = VNDMR_BPSM;
-   output_is_yuv = true;
-   break;
-   case V4L2_PIX_FMT_UYVY:
-   dmr = 0;
-   output_is_yuv = true;
-   break;
-   case V4L2_PIX_FMT_XRGB555:
-   dmr = VNDMR_DTMD_ARGB1555;
-   break;
-   case V4L2_PIX_FMT_RGB565:
-   dmr = 0;
-   break;
-   case V4L2_PIX_FMT_XBGR32:
-   /* Note: not supported on M1 */
-   dmr = VNDMR_EXRGB;
-   break;
-   default:
-   vin_err(vin, "Invalid pixelformat (0x%x)\n",
-   vin->format.pixelformat);
-   return -EINVAL;
-   }
-
-   /* Always update on field change */
-   vnmc |= VNMC_VUP;
-
-   /* If input and 

[PATCH v8 21/28] rcar-vin: add group allocator functions

2017-11-29 Thread Niklas Söderlund
In media controller mode all VIN instances needs to be part of the same
media graph. There is also a need to each VIN instance to know and in
some cases be able to communicate with other VIN instances.

Add an allocator framework where the first VIN instance to be probed
creates a shared data structure and creates a media device.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 179 +++-
 drivers/media/platform/rcar-vin/rcar-vin.h  |  38 ++
 2 files changed, 215 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 45de4079fd835759..a6713fd61dd87a88 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -20,12 +20,170 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 
 #include "rcar-vin.h"
 
+/* 
-
+ * Gen3 CSI2 Group Allocator
+ */
+
+static int rvin_group_read_id(struct rvin_dev *vin, struct device_node *np)
+{
+   u32 val;
+   int ret;
+
+   ret = of_property_read_u32(np, "renesas,id", );
+   if (ret) {
+   vin_err(vin, "%pOF: No renesas,id property found\n", np);
+   return -EINVAL;
+   }
+
+   if (val >= RCAR_VIN_NUM) {
+   vin_err(vin, "%pOF: Invalid renesas,id '%u'\n", np, val);
+   return -EINVAL;
+   }
+
+   return val;
+}
+
+static DEFINE_MUTEX(rvin_group_lock);
+static struct rvin_group *rvin_group_data;
+
+static void rvin_group_release(struct kref *kref)
+{
+   struct rvin_group *group =
+   container_of(kref, struct rvin_group, refcount);
+
+   mutex_lock(_group_lock);
+
+   media_device_unregister(>mdev);
+   media_device_cleanup(>mdev);
+
+   rvin_group_data = NULL;
+
+   mutex_unlock(_group_lock);
+
+   kfree(group);
+}
+
+static struct rvin_group *__rvin_group_allocate(struct rvin_dev *vin)
+{
+   struct rvin_group *group;
+
+   if (rvin_group_data) {
+   group = rvin_group_data;
+   kref_get(>refcount);
+   vin_dbg(vin, "%s: get group=%p\n", __func__, group);
+   return group;
+   }
+
+   group = kzalloc(sizeof(*group), GFP_KERNEL);
+   if (!group)
+   return NULL;
+
+   kref_init(>refcount);
+   rvin_group_data = group;
+
+   vin_dbg(vin, "%s: alloc group=%p\n", __func__, group);
+   return group;
+}
+
+static int rvin_group_add_vin(struct rvin_dev *vin)
+{
+   int ret;
+
+   ret = rvin_group_read_id(vin, vin->dev->of_node);
+   if (ret < 0)
+   return ret;
+
+   mutex_lock(>group->lock);
+
+   if (vin->group->vin[ret]) {
+   mutex_unlock(>group->lock);
+   vin_err(vin, "VIN number %d already occupied\n", ret);
+   return -EINVAL;
+   }
+
+   vin->group->vin[ret] = vin;
+
+   mutex_unlock(>group->lock);
+
+   vin_dbg(vin, "I'm VIN number %d", ret);
+
+   return 0;
+}
+
+static int rvin_group_allocate(struct rvin_dev *vin)
+{
+   struct rvin_group *group;
+   struct media_device *mdev;
+   int ret;
+
+   mutex_lock(_group_lock);
+
+   group = __rvin_group_allocate(vin);
+   if (!group) {
+   mutex_unlock(_group_lock);
+   return -ENOMEM;
+   }
+
+   /* Init group data if it is not already initialized */
+   mdev = >mdev;
+   if (!mdev->dev) {
+   mutex_init(>lock);
+   mdev->dev = vin->dev;
+
+   strlcpy(mdev->driver_name, "Renesas VIN",
+   sizeof(mdev->driver_name));
+   strlcpy(mdev->model, vin->dev->of_node->name,
+   sizeof(mdev->model));
+
+   snprintf(mdev->bus_info, sizeof(mdev->bus_info), "platform:%s",
+dev_name(mdev->dev));
+   media_device_init(mdev);
+
+   ret = media_device_register(mdev);
+   if (ret) {
+   vin_err(vin, "Failed to register media device\n");
+   kref_put(>refcount, rvin_group_release);
+   mutex_unlock(_group_lock);
+   return ret;
+   }
+   }
+
+   vin->group = group;
+   vin->v4l2_dev.mdev = mdev;
+
+   ret = rvin_group_add_vin(vin);
+   if (ret) {
+   kref_put(>refcount, rvin_group_release);
+   mutex_unlock(_group_lock);
+   return ret;
+   }
+
+   mutex_unlock(_group_lock);
+
+   return 0;
+}
+
+static void rvin_group_delete(struct rvin_dev *vin)
+{
+   unsigned int i;
+
+   mutex_lock(>group->lock);
+   for (i = 0; i < RCAR_VIN_NUM; i++)
+   if (vin->group->vin[i] 

[PATCH v8 25/28] rcar-vin: extend {start,stop}_streaming to work with media controller

2017-11-29 Thread Niklas Söderlund
The procedure to start or stop streaming using the non-MC single
subdevice and the MC graph and multiple subdevices are quite different.
Create a new function to abstract which method is used based on which
mode the driver is running in and add logic to start the MC graph.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 112 +++--
 1 file changed, 105 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 6c5df13b30d6dd14..8a6674a891aab357 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -1087,15 +1087,115 @@ static void rvin_buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(>qlock, flags);
 }
 
+static int rvin_set_stream(struct rvin_dev *vin, int on)
+{
+   struct v4l2_subdev_format fmt = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
+   struct media_pipeline *pipe;
+   struct  v4l2_subdev *sd;
+   struct media_pad *pad;
+   int ret;
+
+   /* No media controller used, simply pass operation to subdevice */
+   if (!vin->info->use_mc) {
+   ret = v4l2_subdev_call(vin->digital->subdev, video, s_stream,
+  on);
+
+   return ret == -ENOIOCTLCMD ? 0 : ret;
+   }
+
+   pad = media_entity_remote_pad(>pad);
+   if (!pad)
+   return -EPIPE;
+
+   sd = media_entity_to_v4l2_subdev(pad->entity);
+   if (!sd)
+   return -EPIPE;
+
+   if (!on) {
+   media_pipeline_stop(>vdev.entity);
+   return v4l2_subdev_call(sd, video, s_stream, 0);
+   }
+
+   fmt.pad = pad->index;
+   if (v4l2_subdev_call(sd, pad, get_fmt, NULL, ))
+   return -EPIPE;
+
+   switch (fmt.format.code) {
+   case MEDIA_BUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_UYVY10_2X10:
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   vin->code = fmt.format.code;
+   break;
+   default:
+   return -EPIPE;
+   }
+
+   switch (fmt.format.field) {
+   case V4L2_FIELD_TOP:
+   case V4L2_FIELD_BOTTOM:
+   case V4L2_FIELD_NONE:
+   case V4L2_FIELD_INTERLACED_TB:
+   case V4L2_FIELD_INTERLACED_BT:
+   case V4L2_FIELD_INTERLACED:
+   case V4L2_FIELD_SEQ_TB:
+   case V4L2_FIELD_SEQ_BT:
+   /* Supported natively */
+   break;
+   case V4L2_FIELD_ALTERNATE:
+   switch (vin->format.field) {
+   case V4L2_FIELD_TOP:
+   case V4L2_FIELD_BOTTOM:
+   case V4L2_FIELD_NONE:
+   break;
+   case V4L2_FIELD_INTERLACED_TB:
+   case V4L2_FIELD_INTERLACED_BT:
+   case V4L2_FIELD_INTERLACED:
+   case V4L2_FIELD_SEQ_TB:
+   case V4L2_FIELD_SEQ_BT:
+   /* Use VIN hardware to combine the two fields */
+   fmt.format.height *= 2;
+   break;
+   default:
+   return -EPIPE;
+   }
+   break;
+   default:
+   return -EPIPE;
+   }
+
+   if (fmt.format.width != vin->format.width ||
+   fmt.format.height != vin->format.height)
+   return -EPIPE;
+
+   pipe = sd->entity.pipe ? sd->entity.pipe : >vdev.pipe;
+   if (media_pipeline_start(>vdev.entity, pipe))
+   return -EPIPE;
+
+   ret = v4l2_subdev_call(sd, video, s_stream, 1);
+   if (ret == -ENOIOCTLCMD)
+   ret = 0;
+   if (ret)
+   media_pipeline_stop(>vdev.entity);
+
+   return ret;
+}
+
 static int rvin_start_streaming(struct vb2_queue *vq, unsigned int count)
 {
struct rvin_dev *vin = vb2_get_drv_priv(vq);
-   struct v4l2_subdev *sd;
unsigned long flags;
int ret;
 
-   sd = vin_to_source(vin);
-   v4l2_subdev_call(sd, video, s_stream, 1);
+   ret = rvin_set_stream(vin, 1);
+   if (ret) {
+   spin_lock_irqsave(>qlock, flags);
+   return_all_buffers(vin, VB2_BUF_STATE_QUEUED);
+   spin_unlock_irqrestore(>qlock, flags);
+   return ret;
+   }
 
spin_lock_irqsave(>qlock, flags);
 
@@ -1104,7 +1204,7 @@ static int rvin_start_streaming(struct vb2_queue *vq, 
unsigned int count)
ret = rvin_capture_start(vin);
if (ret) {
return_all_buffers(vin, VB2_BUF_STATE_QUEUED);
-   v4l2_subdev_call(sd, video, s_stream, 0);
+   rvin_set_stream(vin, 0);
}
 
spin_unlock_irqrestore(>qlock, flags);
@@ -1115,7 +1215,6 @@ static int rvin_start_streaming(struct vb2_queue *vq, 
unsigned int count)
 static 

[PATCH v8 24/28] rcar-vin: add link notify for Gen3

2017-11-29 Thread Niklas Söderlund
Add the ability to process media device link change request. Link
enabling is a bit complicated on Gen3, whether or not it's possible to
enable a link depends on what other links already are enabled. On Gen3
the 8 VINs are split into two subgroup's (VIN0-3 and VIN4-7) and from a
routing perspective these two groups are independent of each other.
Each subgroup's routing is controlled by the subgroup VIN master
instance (VIN0 and VIN4).

There are a limited number of possible route setups available for each
subgroup and the configuration of each setup is dictated by the
hardware. On H3 for example there are 6 possible route setups for each
subgroup to choose from.

This leads to the media device link notification code being rather large
since it will find the best routing configuration to try and accommodate
as many links as possible. When it's not possible to enable a new link
due to hardware constrains the link_notifier callback will return
-EMLINK.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 205 
 1 file changed, 205 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 2081637e493e1941..456f93d60b40fb80 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -27,6 +27,209 @@
 
 #include "rcar-vin.h"
 
+/* 
-
+ * Media Controller link notification
+ */
+
+static unsigned int rvin_group_csi_pad_to_chan(unsigned int pad)
+{
+   /*
+* The companion CSI-2 receiver driver (rcar-csi2) is known
+* and we know it have one source pad (pad 0) and four sink
+* pads (pad 1-4). So to translate a pad on the remote
+* CSI-2 receiver to the VIN internal channel number simply
+* subtract one from the pad number.
+*/
+   return pad - 1;
+}
+
+/* group lock should be held when calling this function */
+static int rvin_group_entity_to_vin_num(struct rvin_group *group,
+   struct media_entity *entity)
+{
+   struct video_device *vdev;
+   int i;
+
+   if (!is_media_entity_v4l2_video_device(entity))
+   return -ENODEV;
+
+   vdev = media_entity_to_video_device(entity);
+
+   for (i = 0; i < RCAR_VIN_NUM; i++) {
+   if (!group->vin[i])
+   continue;
+
+   if (>vin[i]->vdev == vdev)
+   return i;
+   }
+
+   return -ENODEV;
+}
+
+/* group lock should be held when calling this function */
+static int rvin_group_entity_to_csi_num(struct rvin_group *group,
+   struct media_entity *entity)
+{
+   struct v4l2_subdev *sd;
+   int i;
+
+   if (!is_media_entity_v4l2_subdev(entity))
+   return -ENODEV;
+
+   sd = media_entity_to_v4l2_subdev(entity);
+
+   for (i = 0; i < RVIN_CSI_MAX; i++)
+   if (group->csi[i].subdev == sd)
+   return i;
+
+   return -ENODEV;
+}
+
+/* group lock should be held when calling this function */
+static void __rvin_group_build_link_list(struct rvin_group *group,
+struct rvin_group_chsel *map,
+int start, int len)
+{
+   struct media_pad *vin_pad, *remote_pad;
+   unsigned int n;
+
+   for (n = 0; n < len; n++) {
+   map[n].csi = -1;
+   map[n].chan = -1;
+
+   if (!group->vin[start + n])
+   continue;
+
+   vin_pad = >vin[start + n]->vdev.entity.pads[0];
+
+   remote_pad = media_entity_remote_pad(vin_pad);
+   if (!remote_pad)
+   continue;
+
+   map[n].csi =
+   rvin_group_entity_to_csi_num(group, remote_pad->entity);
+   map[n].chan = rvin_group_csi_pad_to_chan(remote_pad->index);
+   }
+}
+
+/* group lock should be held when calling this function */
+static int __rvin_group_try_get_chsel(struct rvin_group *group,
+ struct rvin_group_chsel *map,
+ int start, int len)
+{
+   const struct rvin_group_chsel *sel;
+   unsigned int i, n;
+   int chsel;
+
+   for (i = 0; i < group->vin[start]->info->num_chsels; i++) {
+   chsel = i;
+   for (n = 0; n < len; n++) {
+
+   /* If the link is not active it's OK */
+   if (map[n].csi == -1)
+   continue;
+
+   /* Check if chsel matches requested link */
+   sel = >vin[start]->info->chsels[start + n][i];
+   if (map[n].csi != sel->csi ||
+  

[PATCH v8 23/28] rcar-vin: parse Gen3 OF and setup media graph

2017-11-29 Thread Niklas Söderlund
Parse the VIN Gen3 OF graph and register all CSI-2 devices in the VIN
group common media device. Once all CSI-2 subdevices are added to the
common media device create links between them.

The parsing and registering CSI-2 subdevices with the v4l2 async
framework is a collaborative effort shared between the VIN instances
which are part of the group. The first rcar-vin instance parses OF and
finds all other VIN and CSI-2 nodes which are part of the graph. It
stores a bit mask of all VIN instances found and handles to all CSI-2
nodes.

The bit mask is used to figure out when all VIN instances have been
probed. Once the last VIN instance is probed this is detected and this
instance registers all CSI-2 subdevices in its private async notifier.
Once the .complete() callback of this notifier is called it register all
video devices and creates the media controller links between all
entities.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 322 +++-
 drivers/media/platform/rcar-vin/rcar-vin.h  |  10 +-
 2 files changed, 327 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index a6713fd61dd87a88..2081637e493e1941 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -86,6 +86,7 @@ static struct rvin_group *__rvin_group_allocate(struct 
rvin_dev *vin)
return NULL;
 
kref_init(>refcount);
+   group->notifier = NULL;
rvin_group_data = group;
 
vin_dbg(vin, "%s: alloc group=%p\n", __func__, group);
@@ -392,10 +393,281 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
  * Group async notifier
  */
 
-static int rvin_group_init(struct rvin_dev *vin)
+/* group lock should be held when calling this function */
+static int rvin_group_add_link(struct rvin_dev *vin,
+  struct media_entity *source,
+  unsigned int source_idx,
+  struct media_entity *sink,
+  unsigned int sink_idx,
+  u32 flags)
+{
+   struct media_pad *source_pad, *sink_pad;
+   int ret = 0;
+
+   source_pad = >pads[source_idx];
+   sink_pad = >pads[sink_idx];
+
+   if (!media_entity_find_link(source_pad, sink_pad))
+   ret = media_create_pad_link(source, source_idx,
+   sink, sink_idx, flags);
+
+   if (ret)
+   vin_err(vin, "Error adding link from %s to %s\n",
+   source->name, sink->name);
+
+   return ret;
+}
+
+static int rvin_group_update_links(struct rvin_dev *vin)
+{
+   struct media_entity *source, *sink;
+   struct rvin_dev *master;
+   unsigned int i, n, idx, csi;
+   int ret = 0;
+
+   mutex_lock(>group->lock);
+
+   for (n = 0; n < RCAR_VIN_NUM; n++) {
+
+   /* Check that VIN is part of the group */
+   if (!vin->group->vin[n])
+   continue;
+
+   /* Check that subgroup master is part of the group */
+   master = vin->group->vin[n < 4 ? 0 : 4];
+   if (!master)
+   continue;
+
+   for (i = 0; i < vin->info->num_chsels; i++) {
+   csi = vin->info->chsels[n][i].csi;
+
+   /* If the CSI-2 is out of bounds it's a noop, skip */
+   if (csi >= RVIN_CSI_MAX)
+   continue;
+
+   /* Check that CSI-2 are part of the group */
+   if (!vin->group->csi[csi].subdev)
+   continue;
+
+   source = >group->csi[csi].subdev->entity;
+   sink = >group->vin[n]->vdev.entity;
+   idx = vin->info->chsels[n][i].chan + 1;
+
+   ret = rvin_group_add_link(vin, source, idx, sink, 0,
+ 0);
+   if (ret)
+   goto out;
+   }
+   }
+out:
+   mutex_unlock(>group->lock);
+
+   return ret;
+}
+
+static int rvin_group_notify_complete(struct v4l2_async_notifier *notifier)
 {
+   struct rvin_dev *vin = notifier_to_vin(notifier);
+   unsigned int i;
int ret;
 
+   ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
+   if (ret) {
+   vin_err(vin, "Failed to register subdev nodes\n");
+   return ret;
+   }
+
+   for (i = 0; i < RCAR_VIN_NUM; i++) {
+   if (vin->group->vin[i]) {
+   ret = rvin_v4l2_register(vin->group->vin[i]);
+   if (ret)
+   return ret;
+   }
+   }
+
+   return rvin_group_update_links(vin);
+}
+

[PATCH v8 28/28] rcar-vin: enable support for r8a77970

2017-11-29 Thread Niklas Söderlund
Add the SoC specific information for Renesas r8a77970.

Signed-off-by: Niklas Söderlund 
---
 .../devicetree/bindings/media/rcar_vin.txt |  1 +
 drivers/media/platform/rcar-vin/rcar-core.c| 40 ++
 2 files changed, 41 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 314743532bbb4523..6b98f8a3398fa493 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -21,6 +21,7 @@ on Gen3 to a CSI-2 receiver.
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7796" for the R8A7796 device
+   - "renesas,vin-r8a77970" for the R8A77970 device
- "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
  device.
- "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 62eb89b36fbb2ee1..bbdf36b5c3c8178d 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1145,6 +1145,42 @@ static const struct rvin_info rcar_info_r8a7796 = {
},
 };
 
+static const struct rvin_info rcar_info_r8a77970 = {
+   .chip = RCAR_GEN3,
+   .use_mc = true,
+   .max_width = 4096,
+   .max_height = 4096,
+
+   .num_chsels = 5,
+   .chsels = {
+   {
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   }, {
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_NC, .chan = 0 },
+   }, {
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 2 },
+   { .csi = RVIN_NC, .chan = 0 },
+   }, {
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 3 },
+   { .csi = RVIN_NC, .chan = 0 },
+   },
+   },
+};
+
 static const struct of_device_id rvin_of_id_table[] = {
{
.compatible = "renesas,vin-r8a7778",
@@ -1182,6 +1218,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.compatible = "renesas,vin-r8a7796",
.data = _info_r8a7796,
},
+   {
+   .compatible = "renesas,vin-r8a77970",
+   .data = _info_r8a77970,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, rvin_of_id_table);
-- 
2.15.0



[PATCH v8 06/28] rcar-vin: move max width and height information to chip information

2017-11-29 Thread Niklas Söderlund
On Gen3 the max supported width and height will be different from Gen2.
Move the limits to the struct rvin_info to prepare for Gen3 support.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Kieran Bingham 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 6 ++
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 6 ++
 drivers/media/platform/rcar-vin/rcar-vin.h  | 6 ++
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 73c1700a409bfd35..03d3cd63e38bee11 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -232,14 +232,20 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
 
 static const struct rvin_info rcar_info_h1 = {
.chip = RCAR_H1,
+   .max_width = 2048,
+   .max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_m1 = {
.chip = RCAR_M1,
+   .max_width = 2048,
+   .max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_gen2 = {
.chip = RCAR_GEN2,
+   .max_width = 2048,
+   .max_height = 2048,
 };
 
 static const struct of_device_id rvin_of_id_table[] = {
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index b1caa04921aa23bb..59ec6d3d119590aa 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -23,8 +23,6 @@
 #include "rcar-vin.h"
 
 #define RVIN_DEFAULT_FORMATV4L2_PIX_FMT_YUYV
-#define RVIN_MAX_WIDTH 2048
-#define RVIN_MAX_HEIGHT2048
 
 /* 
-
  * Format Conversions
@@ -258,8 +256,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
 
/* Limit to VIN capabilities */
-   v4l_bound_align_image(>width, 2, RVIN_MAX_WIDTH, walign,
- >height, 4, RVIN_MAX_HEIGHT, 2, 0);
+   v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
+ >height, 4, vin->info->max_height, 2, 0);
 
pix->bytesperline = max_t(u32, pix->bytesperline,
  rvin_format_bytesperline(pix));
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 0d3949c8c08c8f63..646f897f5c05ec4e 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -91,9 +91,15 @@ struct rvin_graph_entity {
 /**
  * struct rvin_info - Information about the particular VIN implementation
  * @chip:  type of VIN chip
+ *
+ * max_width:  max input width the VIN supports
+ * max_height: max input height the VIN supports
  */
 struct rvin_info {
enum chip_id chip;
+
+   unsigned int max_width;
+   unsigned int max_height;
 };
 
 /**
-- 
2.15.0



[PATCH v12 1/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

2017-11-29 Thread Niklas Söderlund
Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
are located between the video sources (CSI-2 transmitters) and the video
grabbers (VIN) on Gen3 of Renesas R-Car SoC.

Each CSI-2 device is connected to more then one VIN device which
simultaneously can receive video from the same CSI-2 device. Each VIN
device can also be connected to more then one CSI-2 device. The routing
of which link are used are controlled by the VIN devices. There are only
a few possible routes which are set by hardware limitations, which are
different for each SoC in the Gen3 family.

To work with the limitations of routing possibilities it is necessary
for the DT bindings to describe which VIN device is connected to which
CSI-2 device. This is why port 1 needs to to assign reg numbers for each
VIN device that be connected to it. To setup and to know which links are
valid for each SoC is the responsibility of the VIN driver since the
register to configure it belongs to the VIN hardware.

Signed-off-by: Niklas Söderlund 
Acked-by: Rob Herring 
---
 .../bindings/media/renesas,rcar-csi2.txt   | 105 +
 MAINTAINERS|   1 +
 2 files changed, 106 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt

diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt 
b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
new file mode 100644
index ..688afd83bf66f8cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
@@ -0,0 +1,105 @@
+Renesas R-Car MIPI CSI-2
+
+
+The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
+family of devices. It is to be used in conjunction with the R-Car VIN module,
+which provides the video capture capabilities.
+
+Mandatory properties
+
+ - compatible: Must be one or more of the following
+   - "renesas,r8a7795-csi2" for the R8A7795 device.
+   - "renesas,r8a7796-csi2" for the R8A7796 device.
+
+ - reg: the register base and size for the device registers
+ - interrupts: the interrupt for the device
+ - clocks: Reference to the parent clock
+
+The device node shall contain two 'port' child nodes according to the
+bindings defined in Documentation/devicetree/bindings/media/
+video-interfaces.txt. Port 0 shall connect the node that is the video
+source for to the CSI-2. Port 1 shall connect all the R-Car VIN
+modules, which can make use of the CSI-2 module.
+
+- Port 0 - Video source (Mandatory)
+   - Endpoint 0 - sub-node describing the endpoint that is the video source
+
+- Port 1 - VIN instances (Mandatory for all VIN present in the SoC)
+   - Endpoint 0 - sub-node describing the endpoint that is VIN0
+   - Endpoint 1 - sub-node describing the endpoint that is VIN1
+   - Endpoint 2 - sub-node describing the endpoint that is VIN2
+   - Endpoint 3 - sub-node describing the endpoint that is VIN3
+   - Endpoint 4 - sub-node describing the endpoint that is VIN4
+   - Endpoint 5 - sub-node describing the endpoint that is VIN5
+   - Endpoint 6 - sub-node describing the endpoint that is VIN6
+   - Endpoint 7 - sub-node describing the endpoint that is VIN7
+
+Example:
+
+   csi20: csi2@fea8 {
+   compatible = "renesas,r8a7796-csi2";
+   reg = <0 0xfea8 0 0x1>;
+   interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < CPG_MOD 714>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   resets = < 714>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <0>;
+
+   csi20_in: endpoint@0 {
+   reg = <0>;
+   clock-lanes = <0>;
+   data-lanes = <1>;
+   remote-endpoint = <_txb>;
+   };
+   };
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg = <1>;
+
+   csi20vin0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <>;
+   };
+   csi20vin1: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <>;
+   };
+   csi20vin2: endpoint@2 {
+  

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

2017-11-29 Thread Niklas Söderlund
A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
hardware blocks are connected between the video sources and the video
grabbers (VIN).

Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/Kconfig |  12 +
 drivers/media/platform/rcar-vin/Makefile|   1 +
 drivers/media/platform/rcar-vin/rcar-csi2.c | 898 
 3 files changed, 911 insertions(+)
 create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c

diff --git a/drivers/media/platform/rcar-vin/Kconfig 
b/drivers/media/platform/rcar-vin/Kconfig
index af4c98b44d2e22cb..6875f30c1ae42631 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -1,3 +1,15 @@
+config VIDEO_RCAR_CSI2
+   tristate "R-Car MIPI CSI-2 Receiver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
+   depends on ARCH_RENESAS || COMPILE_TEST
+   select V4L2_FWNODE
+   ---help---
+ Support for Renesas R-Car MIPI CSI-2 receiver.
+ Supports R-Car Gen3 SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called rcar-csi2.
+
 config VIDEO_RCAR_VIN
tristate "R-Car Video Input (VIN) Driver"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
MEDIA_CONTROLLER
diff --git a/drivers/media/platform/rcar-vin/Makefile 
b/drivers/media/platform/rcar-vin/Makefile
index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
--- a/drivers/media/platform/rcar-vin/Makefile
+++ b/drivers/media/platform/rcar-vin/Makefile
@@ -1,3 +1,4 @@
 rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
 
+obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
 obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
b/drivers/media/platform/rcar-vin/rcar-csi2.c
new file mode 100644
index ..30aafcbb7a3642c6
--- /dev/null
+++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
@@ -0,0 +1,898 @@
+/*
+ * Driver for Renesas R-Car MIPI CSI-2 Receiver
+ *
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register offsets and bits */
+
+/* Control Timing Select */
+#define TREF_REG   0x00
+#define TREF_TREF  BIT(0)
+
+/* Software Reset */
+#define SRST_REG   0x04
+#define SRST_SRST  BIT(0)
+
+/* PHY Operation Control */
+#define PHYCNT_REG 0x08
+#define PHYCNT_SHUTDOWNZ   BIT(17)
+#define PHYCNT_RSTZBIT(16)
+#define PHYCNT_ENABLECLK   BIT(4)
+#define PHYCNT_ENABLE_3BIT(3)
+#define PHYCNT_ENABLE_2BIT(2)
+#define PHYCNT_ENABLE_1BIT(1)
+#define PHYCNT_ENABLE_0BIT(0)
+
+/* Checksum Control */
+#define CHKSUM_REG 0x0c
+#define CHKSUM_ECC_EN  BIT(1)
+#define CHKSUM_CRC_EN  BIT(0)
+
+/*
+ * Channel Data Type Select
+ * VCDT[0-15]:  Channel 1 VCDT[16-31]:  Channel 2
+ * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4
+ */
+#define VCDT_REG   0x10
+#define VCDT2_REG  0x14
+#define VCDT_VCDTN_EN  BIT(15)
+#define VCDT_SEL_VC(n) (((n) & 0x3) << 8)
+#define VCDT_SEL_DTN_ONBIT(6)
+#define VCDT_SEL_DT(n) (((n) & 0x3f) << 0)
+
+/* Frame Data Type Select */
+#define FRDT_REG   0x18
+
+/* Field Detection Control */
+#define FLD_REG0x1c
+#define FLD_FLD_NUM(n) (((n) & 0xff) << 16)
+#define FLD_FLD_EN4BIT(3)
+#define FLD_FLD_EN3BIT(2)
+#define FLD_FLD_EN2BIT(1)
+#define FLD_FLD_EN BIT(0)
+
+/* Automatic Standby Control */
+#define ASTBY_REG  0x20
+
+/* Long Data Type Setting 0 */
+#define LNGDT0_REG 0x28
+
+/* Long Data Type Setting 1 */
+#define LNGDT1_REG 0x2c
+
+/* Interrupt Enable */
+#define INTEN_REG  0x30
+
+/* Interrupt Source Mask */
+#define INTCLOSE_REG   0x34
+
+/* Interrupt Status Monitor */
+#define INTSTATE_REG   0x38
+#define INTSTATE_INT_ULPS_START  

[PATCH v12 0/2] rcar-csi2: add Renesas R-Car MIPI CSI-2

2017-11-29 Thread Niklas Söderlund
Hi,

This is the latest incarnation of R-Car MIPI CSI-2 receiver driver. It's
based on top of the media-tree and are tested on Renesas Salvator-X
together with the out-of-tree patches for rcar-vin to add support for
Gen3 VIN.

I hope this is the last incarnation of this patch-set, I do think it is 
ready for upstream consumption :-)

* Changes since v11
- Added missing call to v4l2_async_notifier_unregister().
- Fixed missing reg popery in bindings documentation.
- Add Rob's ack to 01/02.
- Dropped 'media:' prefix from patch subjects as it seems they are added 
  first when a patch is picked up by the maintainer.
- Fixed typo in comment enpoint -> endpoint, thanks Hans.
- Added Hans Reviewed-by to driver.

* Changes since v10
- Renamed Documentation/devicetree/bindings/media/rcar-csi2.txt to
  Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
- Add extra newline in rcar_csi2_code_to_fmt()
- Use locally stored format information instead of reading it from the
  remote subdevice, Sakari pointed out that the pipeline is validated
  before .s_stream() is called so this is safe.
- Do not check return from media_entity_to_v4l2_subdev() in
  rcar_csi2_start(), Sakari pointed out it can't fail. Also move logic
  to find the remote subdevice is moved to the only user of it,
  rcar_csi2_calc_phypll().
- Move pm_runtime_get_sync() and pm_runtime_put() to
  rcar_csi2_s_stream() and remove rcar_csi2_s_power().
- Add validation of pixel code to rcar_csi2_set_pad_format().
- Remove static rcar_csi2_notify_unbind() as it only printed a debug
  message.

* Changes since v9
- Add reset property to device tree example
- Use BIT(x) instead of (1 << x)
- Use u16 in struct phypll_hsfreqrange to pack struct better.
- Use unsigned int type for loop variable in rcar_csi2_code_to_fmt
- Move fields inside struct struct rcar_csi2_info and struct rcar_csi2
  to pack struct's tighter.
- Use %u instead of %d when printing __u32.
- Don't check return of platform_get_resource(), let
  devm_ioremap_resource() handle it.
- Store quirk workaround for r8a7795 ES1.0 in the data field of struct
  soc_device_attribute.

Changes since v8:
- Updated bindings documentation, thanks Rob!
- Make use of the now in media-tree sub-notifier V4L2 API
- Add delay when resetting the IP to allow for a proper reset
- Fix bug in s_stream error path where the usage count was off if an
  error was hit.
- Add support for H3 ES2.0

Changes since v7:
- Rebase on top of the latest incremental async patches.
- Fix comments on DT documentation.
- Use v4l2_ctrl_g_ctrl_int64() instead of v4l2_g_ext_ctrls().
- Handle try formats in .set_fmt() and .get_fmt().
- Don't call v4l2_device_register_subdev_nodes() as this is not needed
  with the complete() callbacks synchronized.
- Fix line over 80 chars.
- Fix varies spelling mistakes.

Changes since v6:
- Rebased on top of Sakaris fwnode patches.
- Changed of RCAR_CSI2_PAD_MAX to NR_OF_RCAR_CSI2_PAD.
- Remove assumption about unknown media bus type, thanks Sakari for
  pointing this out.
- Created table for supported format information instead of scattering
  this information around the driver, thanks Sakari!
- Small newline fixes and reduce some indentation levels

Changes since v5:
- Make use of the incremental async subnotifer and helper to map DT
  endpoint to media pad number. This moves functionality which
  previously in the Gen3 patches for R-Car VIN driver to this R-Car
  CSI-2 driver. This is done in preparation to support the ADV7482
  driver in development by Kieran which will register more then one
  subdevice and the CSI-2 driver needs to cope wit this. Further more it
  prepares the driver for another use-case where more then one subdevice
  is present upstream for the CSI-2.
- Small cleanups.
- Add explicit include for linux/io.h, thanks Kieran.

Changes since v4:
- Match SoC part numbers and drop trailing space in documentation,
  thanks Geert for pointing this out.
- Clarify that the driver is a CSI-2 receiver by supervised
  s/interface/receiver/, thanks Laurent.
- Add entries in Kconfig and Makefile alphabetically instead of append.
- Rename struct rcar_csi2 member swap to lane_swap.
- Remove macros to wrap calls to dev_{dbg,info,warn,err}.
- Add wrappers for ioread32 and iowrite32.
- Remove unused interrupt handler, but keep checking in probe that there
  are a interrupt define in DT.
- Rework how to wait for LP-11 state, thanks Laurent for the great idea!
- Remove unneeded delay in rcar_csi2_reset()
- Remove check for duplicated lane id:s from DT parsing. Broken out to a
  separate patch adding this check directly to v4l2_of_parse_endpoint().
- Fixed rcar_csi2_start() to ask it's source subdevice for information
  about pixel rate and frame format. With this change having
  {set,get}_fmt operations became redundant, it was only used for
  figuring out this out so dropped them.
- Tabulated frequency settings map.
- Dropped V4L2_SUBDEV_FL_HAS_DEVNODE it should never have been set.
- Switched 

[PATCH 19/22] media: drivers: remove "/**" from non-kernel-doc comments

2017-11-29 Thread Mauro Carvalho Chehab
Several comments are wrongly tagged as kernel-doc, causing
those warnings:

  drivers/media/rc/st_rc.c:98: warning: No description found for parameter 'irq'
  drivers/media/rc/st_rc.c:98: warning: No description found for parameter 
'data'
  drivers/media/pci/solo6x10/solo6x10-enc.c:183: warning: No description found 
for parameter 'solo_dev'
  drivers/media/pci/solo6x10/solo6x10-enc.c:183: warning: No description found 
for parameter 'ch'
  drivers/media/pci/solo6x10/solo6x10-enc.c:183: warning: No description found 
for parameter 'qp'
  drivers/media/usb/pwc/pwc-dec23.c:652: warning: Cannot understand  *
   on line 652 - I thought it was a doc line
  drivers/media/usb/dvb-usb/cinergyT2-fe.c:40: warning: No description found 
for parameter 'op'
  drivers/media/usb/dvb-usb/friio-fe.c:301: warning: Cannot understand  * (reg, 
val) commad list to initialize this module.
   on line 301 - I thought it was a doc line
  drivers/media/rc/streamzap.c:201: warning: No description found for parameter 
'urb'
  drivers/media/rc/streamzap.c:333: warning: No description found for parameter 
'intf'
  drivers/media/rc/streamzap.c:333: warning: No description found for parameter 
'id'
  drivers/media/rc/streamzap.c:464: warning: No description found for parameter 
'interface'
  drivers/media/i2c/ov5647.c:432: warning: Cannot understand  * @short Subdev 
core operations registration
   on line 432 - I thought it was a doc line
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
parameter 'd'
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
parameter 'addr'
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
parameter 'wbuf'
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
parameter 'wlen'
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
parameter 'rbuf'
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for 
parameter 'rlen'
  drivers/media/platform/vim2m.c:350: warning: No description found for 
parameter 'priv'
  drivers/media/dvb-frontends/tua6100.c:34: warning: cannot understand function 
prototype: 'struct tua6100_priv '
  drivers/media/platform/sti/hva/hva-h264.c:140: warning: cannot understand 
function prototype: 'struct hva_h264_stereo_video_sei '
  drivers/media/platform/sti/hva/hva-h264.c:150: warning: Cannot understand  * 
@frame_width: width in pixels of the buffer containing the input frame
   on line 150 - I thought it was a doc line
  drivers/media/platform/sti/hva/hva-h264.c:356: warning: Cannot understand  * 
@ slice_size: slice size
   on line 356 - I thought it was a doc line
  drivers/media/platform/sti/hva/hva-h264.c:369: warning: Cannot understand  * 
@ bitstream_size: bitstream size
   on line 369 - I thought it was a doc line
  drivers/media/platform/sti/hva/hva-h264.c:395: warning: Cannot understand  * 
@seq_info:  sequence information buffer
   on line 395 - I thought it was a doc line
  drivers/media/dvb-frontends/sp887x.c:137: warning: No description found for 
parameter 'fe'
  drivers/media/dvb-frontends/sp887x.c:137: warning: No description found for 
parameter 'fw'
  drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for 
parameter 'n'
  drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for 
parameter 'd'
  drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for 
parameter 'quotient_i'
  drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for 
parameter 'quotient_f'
  drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:83: warning: cannot 
understand function prototype: 'struct ttusb '
  drivers/media/platform/sh_veu.c:277: warning: No description found for 
parameter 'priv'
  drivers/media/dvb-frontends/zl10036.c:33: warning: cannot understand function 
prototype: 'int zl10036_debug; '
  drivers/media/dvb-frontends/zl10036.c:179: warning: No description found for 
parameter 'state'
  drivers/media/dvb-frontends/zl10036.c:179: warning: No description found for 
parameter 'frequency'
  drivers/media/platform/rcar_fdp1.c:1139: warning: No description found for 
parameter 'priv'
  drivers/media/platform/ti-vpe/vpe.c:933: warning: No description found for 
parameter 'priv'
  drivers/media/usb/gspca/ov519.c:36: warning: No description found for 
parameter 'fmt'
  drivers/media/usb/dvb-usb/dib0700_devices.c:3367: warning: No description 
found for parameter 'adap'

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/sp887x.c  |  6 +++---
 drivers/media/dvb-frontends/tua6100.c |  2 +-
 drivers/media/dvb-frontends/zl10036.c |  8 
 drivers/media/i2c/ov5647.c|  4 ++--
 drivers/media/pci/solo6x10/solo6x10-enc.c |  2 +-
 drivers/media/platform/rcar_fdp1.c|  2 +-
 drivers/media/platform/sh_veu.c   |  2 +-
 

[PATCH 16/22] media: vsp1: add a missing kernel-doc parameter

2017-11-29 Thread Mauro Carvalho Chehab
Fix this warning:
drivers/media/platform/vsp1/vsp1_dl.c:87: warning: No description found 
for parameter 'has_chain'

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 8b5cbb6b7a70..4257451f1bd8 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -70,6 +70,7 @@ struct vsp1_dl_body {
  * @dma: DMA address for the header
  * @body0: first display list body
  * @fragments: list of extra display list bodies
+ * @has_chain: if true, indicates that there's a partition chain
  * @chain: entry in the display list partition chain
  */
 struct vsp1_dl_list {
-- 
2.14.3



Re: [PATCH 1/2] arm64: dts: renesas: r8a77970: use CPG core clock macros

2017-11-29 Thread Sergei Shtylyov

On 11/29/2017 12:55 PM, Simon Horman wrote:


Now that the commit ecadea00f588 ("dt-bindings: clock: Add R8A77970 CPG
core clock definitions") has hit Linus' tree, we  can replace the bare
numbers (we had to use to avoid a cross tree dependency) with these macro
definitions...

Signed-off-by: Sergei Shtylyov 


Thanks, applied.


   Not seeing these 2 patches in the today's devel branch tho...

MBR, Sergei


[PATCH v2 0/2] R-Car D3 (r8a77995) SDHI (eMMC) integration

2017-11-29 Thread Ulrich Hecht
Hi!

This integrates the SDHI hardware on R-Car D3 and enables the Draak board's
eMMC drive.

This revision dumps the two patches that have been applied already, fixes
the sdhi2_pins voltage, removes the redundant SDHI compatible string and
makes the internal DMAC whitelisting pattern more conservative.

CU
Uli


Ulrich Hecht (2):
  mmc: renesas_sdhi: enable R-Car D3 (r8a77995) support
  arm64: dts: r8a77995: draak: enable SDHI2

 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 44 ++
 drivers/mmc/host/renesas_sdhi_internal_dmac.c  |  1 +
 2 files changed, 45 insertions(+)

-- 
2.7.4



[PATCH v2 2/2] arm64: dts: r8a77995: draak: enable SDHI2

2017-11-29 Thread Ulrich Hecht
The single SDHI controller is connected to eMMC.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 44 ++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts 
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 91f247f..e690cf8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -32,6 +32,24 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x1800>;
};
+
+   reg_1p8v: regulator0 {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   reg_3p3v: regulator1 {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
 };
 
 _clk {
@@ -71,6 +89,18 @@
function = "scif2";
};
 
+   sdhi2_pins: sd2 {
+   groups = "mmc_data8", "mmc_ctrl";
+   function = "mmc";
+   power-source = <1800>;
+   };
+
+   sdhi2_pins_uhs: sd2_uhs {
+   groups = "mmc_data8", "mmc_ctrl";
+   function = "mmc";
+   power-source = <1800>;
+   };
+
usb0_pins: usb0 {
groups = "usb0";
function = "usb0";
@@ -125,6 +155,20 @@
status = "okay";
 };
 
+ {
+   /* used for on-board eMMC */
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
+
+   vmmc-supply = <_3p3v>;
+   vqmmc-supply = <_1p8v>;
+   bus-width = <8>;
+   mmc-hs200-1_8v;
+   non-removable;
+   status = "okay";
+};
+
 _phy0 {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
2.7.4



[PATCH v2 1/2] mmc: renesas_sdhi: enable R-Car D3 (r8a77995) support

2017-11-29 Thread Ulrich Hecht
Whitelists for internal DMAC implementation.

Signed-off-by: Ulrich Hecht 
Reviewed-by: Geert Uytterhoeven 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 41cbe84..396ae8a 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -255,6 +255,7 @@ static const struct soc_device_attribute 
gen3_soc_whitelist[] = {
 { .soc_id = "r8a7795", .revision = "ES1.*" },
 { .soc_id = "r8a7795", .revision = "ES2.0" },
 { .soc_id = "r8a7796", .revision = "ES1.0" },
+{ .soc_id = "r8a77995", .revision = "ES1.0" },
 { /* sentinel */ }
 };
 
-- 
2.7.4



Re: [PATCH v2] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus

2017-11-29 Thread Rob Herring
On Wed, Nov 29, 2017 at 7:58 AM, Geert Uytterhoeven
 wrote:
> Hi Rob,
>
> On Wed, Nov 29, 2017 at 2:35 PM, Rob Herring  wrote:
>> On Tue, Nov 28, 2017 at 3:04 AM, Geert Uytterhoeven
>>  wrote:
>>> On Tue, Nov 28, 2017 at 9:56 AM, Simon Horman  wrote:
 On Mon, Nov 27, 2017 at 12:15:39PM +0100, Geert Uytterhoeven wrote:
> On Mon, Nov 27, 2017 at 12:04 PM, Simon Horman  wrote:
> > I just noticed that with this patch applied I now see:
> >
> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
> > (interrupts_property): Missing interrupt-parent for /pmu_a57
> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
> > (interrupts_property): Missing interrupt-parent for /pmu_a53
> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
> > (interrupts_property): Missing interrupt-parent for /pmu_a57
> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
> > (interrupts_property): Missing interrupt-parent for 
> > /pmu_a53arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
> > (interrupts_property): Missing interrupt-parent for /timer
> >
> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
> > (interrupts_property): Missing interrupt-parent for /timer
>
> Right, the "interrupt-parent = <>;" inside the /soc node applies to 
> child
> nodes of the /soc node only.
>
> You can find this in two ways:
>>>
>>> s/find/fix/
>>>
>
>   1. Add "interrupt-parent = <>;" to the /pmu_a57 and /pmu_a53 nodes.
>   2. Switch those nodes from "interrupt" to "interrupts-extended", e.g. 
> turn
>
> interrupts = ,
>
>  into
>
> interrupts-extended = < GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
>
> The latter is what e.g. arch/arm/boot/dts/armada-375.dtsi does.

 Thanks, I took option 1 as it seems consistent with the rest of the
 Renesas DT files. I also added it to the /timer node.
>>>
>>> Actually we recently had a discussion about this on IRC, triggered by a
>>> similar issue in board files (see e.g, Ethernet PHY interrupts).
>>>
>>> Given the following comment:
>>>
>>> drivers/of/irq.c:   /* Try the new-style interrupts-extended first */
>>> drivers/of/irq.c:   res = of_parse_phandle_with_args(device,
>>> "interrupts-extended",
>>>
>>> I think it would be better to use interrupts-extended for 
>>> individual/isolated
>>> use outside the /soc node.
>>
>> I disagree. There's no point to use interrupts-extended unless you
>> have 2 or more interrupt parents. Just set interrupt-parent in the
>> root node.
>
> The on-SoC devices (all under the /soc node, except for the weird ones without
> reg properties that are now being moved out) all have "" as their 
> interrupt
> parents.
>
> Off-SoC devices use one of the on-SoC interrupt controllers for external
> interrupts ("", "", "", ""), or one of the on-SoC
> GPIO controllers that can also serve external interrupts ("").
>
> For the latter, I think interrupts-extended definitely makes sense.
>
> For the former (incl. the "pmu_aN" nodes discussed here), it is debatable.
> But using interrupts-extended makes it easier to catch mistakes in board 
> files,
> as they will be flagged by dtc ("Missing interrupt-parent").
> With interrupt-parent in the root node, they may go undetected.

They would still likely get flagged since the GIC #interrupt-cells is
3 and it is likely you don't have a multiple of 3.

But I guess interrupts-extended does make sense in this case.

Rob


Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

2017-11-29 Thread Geert Uytterhoeven
Hi Ulf,

On Wed, Nov 29, 2017 at 10:59 AM, Ulf Hansson  wrote:
> On 29 November 2017 at 10:43, Geert Uytterhoeven  wrote:
>> On Wed, Nov 29, 2017 at 10:24 AM, Ulf Hansson  wrote:
>>> On 29 November 2017 at 09:21, Yoshihiro Shimoda
>>>  wrote:
> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 2:23 AM
> On 28 November 2017 at 13:48, Yoshihiro Shimoda
>  wrote:
> >> From: Geert Uytterhoeven, Sent: Tuesday, November 28, 2017 7:58 PM
> >> On Sun, Nov 12, 2017 at 1:27 AM, Rafael J. Wysocki 
> >>  wrote:
> >> > From: Rafael J. Wysocki 
 
> >> JFTR, this triggered before during system resume on e.g. Salvator-XS 
> >> with
> >> R-Car H3:
> >>
> >> ohci-platform ee08.usb: runtime PM trying to suspend device
> >> but active child
> >> phy_rcar_gen3_usb2 ee080200.usb-phy: runtime PM trying to suspend
> >> device but active child
> >> ohci-platform ee0c.usb: runtime PM trying to suspend device
> >> but active child
> >> ohci-platform ee0a.usb: runtime PM trying to suspend device
> >> but active child
> >> phy_rcar_gen3_usb2 ee0c0200.usb-phy: runtime PM trying to suspend
> >> device but active child
> >> phy_rcar_gen3_usb2 ee0a0200.usb-phy: runtime PM trying to suspend
> >> device but active child
> >>
> >> so this was an existing issue with USB before.
> >
> > Thank you for the report!
> > I know that, but since this didn't cause any trouble until now,
> > I postponed to investigate the issue... But, I investigate it today.
> > I don't find the root cause yet. However, it seems related to usb host 
> > and/or usb core.
> > --> USB host related devices' child_count will be 1 in suspend timing.
> >  --> I guess remote wakeup feature is enabled? But, I don't find the 
> > point yet.
>
> I am guessing the issue is triggered by genpd in the suspend noirq
> phase (genpd_suspend_noirq()). In there,  there is a call to
> pm_runtime_force_suspend() (which calls pm_runtime_set_suspended() and
> which triggered the earlier error messages being printed).
>
> The reason why genpd calls pm_runtime_force_suspend(), is because when
> validating wakeup configurations for the device "if
> (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))", it's
> thinks wakeup isn't configured while it probably should be.
>
> An additional note, only when genpd has the GENPD_FLAG_PM_CLK set,
> which makes the genpd->dev_ops.stop|start() being assigned, genpd
> calls pm_runtime_force_suspend() - else it doesn't.
>
> Perhaps try out the series I recently posted improving the code
> dealing with wakeups in genpd and the PM core:
> https://www.spinics.net/lists/linux-renesas-soc/msg20122.html
> To that, you need to set the new flag (invented in the above series)
> DPM_FLAG_IN_BAND_WAKEUP in the driver that configures wakeup of its
> device.
>
> Hope this helps!

 Thank you for the comments!
 I tried DPM_FLAG_IN_BAND_WAKEUP, but the issue still exists.
 I added the flag in the [eo]hci-platform driver and usb/core/driver.c.
 I also added the flag in the phy_rcar_gen3_usb2 driver except usb host 
 drivers.
>>>
>>> First, did you confirm that genpd was used? Then for what device?
>>
>> All 6 devices are part of the SYSC PM Domain.
>
> Okay!
>
> Can you perhaps clarify which 6 devices/drivers that are involved, and
> perhaps also point out if their child devices?

/sys/devices/platform/soc/ee08.usb
/sys/devices/platform/soc/ee0c.usb
/sys/devices/platform/soc/ee0a.usb

Driver: ohci-platform

The children are usb6/6-0:1.0, usb3/3-0:1.0, resp. usb4/4-0:1.0, all using
the usb "hub" driver

/sys/devices/platform/soc/ee080200.usb-phy
/sys/devices/platform/soc/ee0a0200.usb-phy
/sys/devices/platform/soc/ee0c0200.usb-phy

Driver: phy_rcar_gen3_usb2

The children are:

phy/phy-ee080200.usb-phy.2
phy/phy-ee0a0200.usb-phy.0
phy/phy-ee0c0200.usb-phy.1

all without a driver, according to sysfs.

Note that at first I had missed them, as printing the children using
device_for_each_child() does not print them, unlike the hub devices that
are children of the usb hosts.

With some debug code added, logging inc/dec of child_count:

USB driver init:

 ehci-pci: EHCI PCI platform driver
 ehci-platform: EHCI generic platform driver
+phy_rcar_gen3_usb2 ee0a0200.usb-phy: rpm_resume:830: inc child_count
of parent soc
+phy phy-ee0a0200.usb-phy.0: rpm_resume:830: inc child_count of parent
ee0a0200.usb-phy
+phy phy-ee0a0200.usb-phy.0: rpm_suspend:606: dec child_count of
parent ee0a0200.usb-phy
+phy phy-ee0a0200.usb-phy.0: rpm_resume:759: inc child_count of parent
ee0a0200.usb-phy


Re: [PATCH v2] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus

2017-11-29 Thread Geert Uytterhoeven
Hi Rob,

On Wed, Nov 29, 2017 at 2:35 PM, Rob Herring  wrote:
> On Tue, Nov 28, 2017 at 3:04 AM, Geert Uytterhoeven
>  wrote:
>> On Tue, Nov 28, 2017 at 9:56 AM, Simon Horman  wrote:
>>> On Mon, Nov 27, 2017 at 12:15:39PM +0100, Geert Uytterhoeven wrote:
 On Mon, Nov 27, 2017 at 12:04 PM, Simon Horman  wrote:
 > I just noticed that with this patch applied I now see:
 >
 > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
 > (interrupts_property): Missing interrupt-parent for /pmu_a57
 > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
 > (interrupts_property): Missing interrupt-parent for /pmu_a53
 > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
 > (interrupts_property): Missing interrupt-parent for /pmu_a57
 > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
 > (interrupts_property): Missing interrupt-parent for 
 > /pmu_a53arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
 > (interrupts_property): Missing interrupt-parent for /timer
 >
 > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
 > (interrupts_property): Missing interrupt-parent for /timer

 Right, the "interrupt-parent = <>;" inside the /soc node applies to 
 child
 nodes of the /soc node only.

 You can find this in two ways:
>>
>> s/find/fix/
>>

   1. Add "interrupt-parent = <>;" to the /pmu_a57 and /pmu_a53 nodes.
   2. Switch those nodes from "interrupt" to "interrupts-extended", e.g. 
 turn

 interrupts = ,

  into

 interrupts-extended = < GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,

 The latter is what e.g. arch/arm/boot/dts/armada-375.dtsi does.
>>>
>>> Thanks, I took option 1 as it seems consistent with the rest of the
>>> Renesas DT files. I also added it to the /timer node.
>>
>> Actually we recently had a discussion about this on IRC, triggered by a
>> similar issue in board files (see e.g, Ethernet PHY interrupts).
>>
>> Given the following comment:
>>
>> drivers/of/irq.c:   /* Try the new-style interrupts-extended first */
>> drivers/of/irq.c:   res = of_parse_phandle_with_args(device,
>> "interrupts-extended",
>>
>> I think it would be better to use interrupts-extended for individual/isolated
>> use outside the /soc node.
>
> I disagree. There's no point to use interrupts-extended unless you
> have 2 or more interrupt parents. Just set interrupt-parent in the
> root node.

The on-SoC devices (all under the /soc node, except for the weird ones without
reg properties that are now being moved out) all have "" as their interrupt
parents.

Off-SoC devices use one of the on-SoC interrupt controllers for external
interrupts ("", "", "", ""), or one of the on-SoC
GPIO controllers that can also serve external interrupts ("").

For the latter, I think interrupts-extended definitely makes sense.

For the former (incl. the "pmu_aN" nodes discussed here), it is debatable.
But using interrupts-extended makes it easier to catch mistakes in board files,
as they will be flagged by dtc ("Missing interrupt-parent").
With interrupt-parent in the root node, they may go undetected.

If the tools can help us, I prefer to use them.

Do you agree?

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


Re: [PATCH v2] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus

2017-11-29 Thread Rob Herring
On Tue, Nov 28, 2017 at 3:04 AM, Geert Uytterhoeven
 wrote:
> Hi Simon,
>
> On Tue, Nov 28, 2017 at 9:56 AM, Simon Horman  wrote:
>> On Mon, Nov 27, 2017 at 12:15:39PM +0100, Geert Uytterhoeven wrote:
>>> On Mon, Nov 27, 2017 at 12:04 PM, Simon Horman  wrote:
>>> > I just noticed that with this patch applied I now see:
>>> >
>>> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
>>> > (interrupts_property): Missing interrupt-parent for /pmu_a57
>>> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
>>> > (interrupts_property): Missing interrupt-parent for /pmu_a53
>>> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
>>> > (interrupts_property): Missing interrupt-parent for /pmu_a57
>>> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
>>> > (interrupts_property): Missing interrupt-parent for 
>>> > /pmu_a53arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
>>> > (interrupts_property): Missing interrupt-parent for /timer
>>> >
>>> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
>>> > (interrupts_property): Missing interrupt-parent for /timer
>>>
>>> Right, the "interrupt-parent = <>;" inside the /soc node applies to 
>>> child
>>> nodes of the /soc node only.
>>>
>>> You can find this in two ways:
>
> s/find/fix/
>
>>>
>>>   1. Add "interrupt-parent = <>;" to the /pmu_a57 and /pmu_a53 nodes.
>>>   2. Switch those nodes from "interrupt" to "interrupts-extended", e.g. turn
>>>
>>> interrupts = ,
>>>
>>>  into
>>>
>>> interrupts-extended = < GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
>>>
>>> The latter is what e.g. arch/arm/boot/dts/armada-375.dtsi does.
>>
>> Thanks, I took option 1 as it seems consistent with the rest of the
>> Renesas DT files. I also added it to the /timer node.
>
> Actually we recently had a discussion about this on IRC, triggered by a
> similar issue in board files (see e.g, Ethernet PHY interrupts).
>
> Given the following comment:
>
> drivers/of/irq.c:   /* Try the new-style interrupts-extended first */
> drivers/of/irq.c:   res = of_parse_phandle_with_args(device,
> "interrupts-extended",
>
> I think it would be better to use interrupts-extended for individual/isolated
> use outside the /soc node.

I disagree. There's no point to use interrupts-extended unless you
have 2 or more interrupt parents. Just set interrupt-parent in the
root node.

Rob


Re: [PATCH 0/3] arm64: dts: renesas: r8a77970: connect VIN to CSI40

2017-11-29 Thread Niklas Söderlund
Hi Simon,

On 2017-11-29 10:53:17 +0100, Simon Horman wrote:
> On Sun, Nov 26, 2017 at 01:50:09AM +0100, Niklas Söderlund wrote:
> > Hi,
> > 
> > This series describes how to connect VIN0-3 to CSI40 and the HDMI input 
> > of the adv7482 on the expansion board. It is tested on V3M together with 
> > V3M enablement for VIN and CSI-2 drivers on-top of Kieran's 
> > renesas-drivers-next-v3m branch [1].
> > 
> > It works and it's possible to program the EDID and capture frame frames.  
> > Remember to switch SW18 to the off position to route the CSI-2 bus to 
> > the expansion board instead of the MAX9286 for GMSL input.
> > 
> > 1. git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git
> 
> Hi Niklas,
> 
> how do you view the path to upstream of this patch-set?

I think there are a few things that needs to go upstream before this 
set.

- The VIN and CSI-2 Gen3 driver support.
- All or some of the V3M DT patches from renesas-drivers-next-v3m.

I would mark this as deferred as I expect some of the patches in 
renesas-drivers-next-v3m needs more work and therefor this set also 
needs to be updated before it's ready to go upstream.

-- 
Regards,
Niklas Söderlund


Re: [RFC] v4l: i2c: ov7670: Implement mbus configuration

2017-11-29 Thread jacopo mondi
Hi Sakari,
   thanks for the reply

On Wed, Nov 29, 2017 at 01:06:49PM +0200, Sakari Ailus wrote:
> On Wed, Nov 29, 2017 at 01:04:30PM +0200, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Mon, Nov 27, 2017 at 11:26:53AM +0100, Jacopo Mondi wrote:
> > > ov7670 currently supports configuration of a few parameters only through
> > > platform data. Implement media bus configuration by parsing DT properties
> > > at probe() time and opportunely configure REG_COM10 during s_format().
> > >
> > > Signed-off-by: Jacopo Mondi 
> > >
> > > ---
> > >
> > > Hi linux-media,
> > >I'm using this sensor to test the CEU driver I have submitted some 
> > > time ago
> > > and I would like to change synchronization signal polarities to test them 
> > > in
> > > combination with that driver.
> > >
> > > So I added support for retrieving some properties listed in the device 
> > > tree
> > > bindings documentation from sensor's DT node and made a patch, BUT I'm
> > > slightly confused about this (and that's why this is an RFC).
> > >
> > > I did a grep for "sync-active" in drivers/media/i2c/ and no sensor driver
> > > implements any property parsing, so I guess I'm doing something wrong 
> > > here.
> >
> > :-)
> >
> > The standard properties are parsed in the V4L2 fwnode framework, and
> > gathered to v4l2_fwnode_endpoint struct for drivers to use. Please see e.g.
> > the smiapp driver how to do this.
> >
> > You'll still need to parse device specific properties in the driver.

I totally misinterpreted this!

My understanding was that v4l2_fwnode_endpoint_parse() was supposed to
be used to parse the -remote- endpoint configuration, so that a
platform driver would know how the sensor is configured and adjust its
settings accordingly (and eventually configure the remote endpoint with
s_mbus_confi()).

Instead, if I got this right, -both- sensor and platform parse
their own endpoints, and they don't care how the remote is configured
because of, as you said, wirings..

I'm going to re-submit this using the v4l2_fwnode framework utilities
in the sensor driver!

Thanks for the clarification
   j

> >
> > >
> > > I thought that maybe sensor media bus configuration should come from the
> > > platform driver, through the s_mbus_config() operation in 
> > > v4l2_subdev_video_ops,
>
> It's specified in the sensor's local endpoint. The corresponding
> configuration needs to be present in the remote endpoint. These are not
> necessarily always the same due to e.g. wiring.
>
> > > but that's said to be deprecated. So maybe is the framework providing 
> > > support
> > > for parsing those properties? Another grep there and I found only 
> > > v4l2-fwnode.c
> > > has support for parsing serial/parallel bus properties, but my 
> > > understanding is
> > > that those functions are meant to be used by the platform driver when
> > > parsing the remote fw node.
> > >
> > > So please help me out here: where should I implement media bus 
> > > configuration
> > > for sensor drivers?
> > >
> > > Thanks
> > >j
> > >
> > > PS: being this just an RFC I have not updated dt bindings, and only
> > > compile-tested the patch
> > >
> > > ---
> > >  drivers/media/i2c/ov7670.c | 108 
> > > ++---
> > >  1 file changed, 101 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
> > > index e88549f..7e2de7e 100644
> > > --- a/drivers/media/i2c/ov7670.c
> > > +++ b/drivers/media/i2c/ov7670.c
> > > @@ -88,6 +88,7 @@ MODULE_PARM_DESC(debug, "Debug level (0-1)");
> > >  #define REG_COM100x15/* Control 10 */
> > >  #define   COM10_HSYNC  0x40/* HSYNC instead of HREF */
> > >  #define   COM10_PCLK_HB0x20/* Suppress PCLK on horiz blank */
> > > +#define   COM10_PCLK_REV  0x10 /* Latch data on PCLK rising edge */
> > >  #define   COM10_HREF_REV  0x08 /* Reverse HREF */
> > >  #define   COM10_VS_LEAD0x04/* VSYNC on clock leading edge */
> > >  #define   COM10_VS_NEG 0x02/* VSYNC negative */
> > > @@ -233,6 +234,7 @@ struct ov7670_info {
> > >   struct clk *clk;
> > >   struct gpio_desc *resetb_gpio;
> > >   struct gpio_desc *pwdn_gpio;
> > > + unsigned int mbus_config;   /* Media bus configuration flags */
> > >   int min_width;  /* Filter out smaller sizes */
> > >   int min_height; /* Filter out smaller sizes */
> > >   int clock_speed;/* External clock speed (MHz) */
> > > @@ -985,7 +987,7 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
> > >   struct ov7670_format_struct *ovfmt;
> > >   struct ov7670_win_size *wsize;
> > >   struct ov7670_info *info = to_state(sd);
> > > - unsigned char com7;
> > > + unsigned char com7, com10;
> > >   int ret;
> > >
> > >   if (format->pad)
> > > @@ -1021,6 +1023,9 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
> > >   ret = 0;
> > >   if (wsize->regs)
> > >   ret = 

Re: [PATCH 1/2] arm64: dts: renesas: initial V3MSK board device tree

2017-11-29 Thread Simon Horman
On Wed, Nov 29, 2017 at 01:14:21PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 11/29/2017 12:51 PM, Simon Horman wrote:
> 
> > > Add the initial device  tree for the V3M Starter Kit board.
> > > The board has 1 debug serial port (SCIF0); include support for it,
> > > so that the serial console can work.
> > > 
> > > Based on the original (and large) patch by Vladimir Barinov.
> > > 
> > > Signed-off-by: Vladimir Barinov 
> > > Signed-off-by: Sergei Shtylyov 
> > > 
> > > ---
> > >   arch/arm64/boot/dts/renesas/Makefile   |2 -
> [...]
> > > Index: renesas/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> > > ===
> > > --- /dev/null
> > > +++ renesas/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> > > @@ -0,0 +1,44 @@
> > > +/*
> > > + * Device Tree Source for the V3M Starter Kit board
> > > + *
> > > + * Copyright (C) 2017 Renesas Electronics Corp.
> > > + * Copyright (C) 2017 Cogent Embedded, Inc.
> > > + *
> > > + * This file is licensed under the terms of the GNU General Public 
> > > License
> > > + * version 2.  This program is licensed "as is" without any warranty of 
> > > any
> > > + * kind, whether express or implied.
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include "r8a77970.dtsi"
> > > +
> > > +/ {
> > > + model = "Renesas V3M Starter Kit board";
> > > + compatible = "renesas,v3msk", "renesas,r8a77970";
> > > +
> > > + aliases {
> > > + serial0 = 
> > > + };
> > > +
> > > + chosen {
> > 
> > For consistency with other Renesas boards I would like to request the
> > following be added here:
> > 
> > bootargs = "ignore_loglevel rw";
> 
>There's currently no consistency as ulcb.dtsi doesn't seem to specify
> "bootargs" prop at all. Moreover, this prop seems to be ignored by ARM64
> kernel -- I can only specify "bootargs" in U-Boot

I had assumed that ulcb.dtsi should be updated in this regards but
I now see that bootargs does not seem to have any effect (on
r8a7796/salvator-x) as you suggest.

I have applied this and the following patch.




Re: [RFC] v4l: i2c: ov7670: Implement mbus configuration

2017-11-29 Thread Sakari Ailus
On Wed, Nov 29, 2017 at 01:04:30PM +0200, Sakari Ailus wrote:
> Hi Jacopo,
> 
> On Mon, Nov 27, 2017 at 11:26:53AM +0100, Jacopo Mondi wrote:
> > ov7670 currently supports configuration of a few parameters only through
> > platform data. Implement media bus configuration by parsing DT properties
> > at probe() time and opportunely configure REG_COM10 during s_format().
> > 
> > Signed-off-by: Jacopo Mondi 
> > 
> > ---
> > 
> > Hi linux-media,
> >I'm using this sensor to test the CEU driver I have submitted some time 
> > ago
> > and I would like to change synchronization signal polarities to test them in
> > combination with that driver.
> > 
> > So I added support for retrieving some properties listed in the device tree
> > bindings documentation from sensor's DT node and made a patch, BUT I'm
> > slightly confused about this (and that's why this is an RFC).
> > 
> > I did a grep for "sync-active" in drivers/media/i2c/ and no sensor driver
> > implements any property parsing, so I guess I'm doing something wrong here.
> 
> :-)
> 
> The standard properties are parsed in the V4L2 fwnode framework, and
> gathered to v4l2_fwnode_endpoint struct for drivers to use. Please see e.g.
> the smiapp driver how to do this.
> 
> You'll still need to parse device specific properties in the driver.
> 
> > 
> > I thought that maybe sensor media bus configuration should come from the
> > platform driver, through the s_mbus_config() operation in 
> > v4l2_subdev_video_ops,

It's specified in the sensor's local endpoint. The corresponding
configuration needs to be present in the remote endpoint. These are not
necessarily always the same due to e.g. wiring.

> > but that's said to be deprecated. So maybe is the framework providing 
> > support
> > for parsing those properties? Another grep there and I found only 
> > v4l2-fwnode.c
> > has support for parsing serial/parallel bus properties, but my 
> > understanding is
> > that those functions are meant to be used by the platform driver when
> > parsing the remote fw node.
> > 
> > So please help me out here: where should I implement media bus configuration
> > for sensor drivers?
> > 
> > Thanks
> >j
> > 
> > PS: being this just an RFC I have not updated dt bindings, and only
> > compile-tested the patch
> > 
> > ---
> >  drivers/media/i2c/ov7670.c | 108 
> > ++---
> >  1 file changed, 101 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
> > index e88549f..7e2de7e 100644
> > --- a/drivers/media/i2c/ov7670.c
> > +++ b/drivers/media/i2c/ov7670.c
> > @@ -88,6 +88,7 @@ MODULE_PARM_DESC(debug, "Debug level (0-1)");
> >  #define REG_COM10  0x15/* Control 10 */
> >  #define   COM10_HSYNC0x40/* HSYNC instead of HREF */
> >  #define   COM10_PCLK_HB  0x20/* Suppress PCLK on horiz blank */
> > +#define   COM10_PCLK_REV  0x10   /* Latch data on PCLK rising edge */
> >  #define   COM10_HREF_REV  0x08   /* Reverse HREF */
> >  #define   COM10_VS_LEAD  0x04/* VSYNC on clock leading edge */
> >  #define   COM10_VS_NEG   0x02/* VSYNC negative */
> > @@ -233,6 +234,7 @@ struct ov7670_info {
> > struct clk *clk;
> > struct gpio_desc *resetb_gpio;
> > struct gpio_desc *pwdn_gpio;
> > +   unsigned int mbus_config;   /* Media bus configuration flags */
> > int min_width;  /* Filter out smaller sizes */
> > int min_height; /* Filter out smaller sizes */
> > int clock_speed;/* External clock speed (MHz) */
> > @@ -985,7 +987,7 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
> > struct ov7670_format_struct *ovfmt;
> > struct ov7670_win_size *wsize;
> > struct ov7670_info *info = to_state(sd);
> > -   unsigned char com7;
> > +   unsigned char com7, com10;
> > int ret;
> > 
> > if (format->pad)
> > @@ -1021,6 +1023,9 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
> > ret = 0;
> > if (wsize->regs)
> > ret = ov7670_write_array(sd, wsize->regs);
> > +   if (ret)
> > +   return ret;
> > +
> > info->fmt = ovfmt;
> > 
> > /*
> > @@ -1033,8 +1038,26 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
> >  * to write it unconditionally, and that will make the frame
> >  * rate persistent too.
> >  */
> > -   if (ret == 0)
> > -   ret = ov7670_write(sd, REG_CLKRC, info->clkrc);
> > +   ret = ov7670_write(sd, REG_CLKRC, info->clkrc);
> > +   if (ret)
> > +   return ret;
> > +
> > +   /* Configure the media bus after the image format */
> > +   com10 = 0;
> > +   if (info->mbus_config & V4L2_MBUS_VSYNC_ACTIVE_LOW)
> > +   com10 |= COM10_VS_NEG;
> > +   if (info->mbus_config & V4L2_MBUS_HSYNC_ACTIVE_LOW)
> > +   com10 |= COM10_HS_NEG;
> > +   if (info->mbus_config & V4L2_MBUS_PCLK_SAMPLE_RISING)
> > +   com10 |= COM10_PCLK_REV;
> > +   if 

Re: [RFC] v4l: i2c: ov7670: Implement mbus configuration

2017-11-29 Thread Sakari Ailus
Hi Jacopo,

On Mon, Nov 27, 2017 at 11:26:53AM +0100, Jacopo Mondi wrote:
> ov7670 currently supports configuration of a few parameters only through
> platform data. Implement media bus configuration by parsing DT properties
> at probe() time and opportunely configure REG_COM10 during s_format().
> 
> Signed-off-by: Jacopo Mondi 
> 
> ---
> 
> Hi linux-media,
>I'm using this sensor to test the CEU driver I have submitted some time ago
> and I would like to change synchronization signal polarities to test them in
> combination with that driver.
> 
> So I added support for retrieving some properties listed in the device tree
> bindings documentation from sensor's DT node and made a patch, BUT I'm
> slightly confused about this (and that's why this is an RFC).
> 
> I did a grep for "sync-active" in drivers/media/i2c/ and no sensor driver
> implements any property parsing, so I guess I'm doing something wrong here.

:-)

The standard properties are parsed in the V4L2 fwnode framework, and
gathered to v4l2_fwnode_endpoint struct for drivers to use. Please see e.g.
the smiapp driver how to do this.

You'll still need to parse device specific properties in the driver.

> 
> I thought that maybe sensor media bus configuration should come from the
> platform driver, through the s_mbus_config() operation in 
> v4l2_subdev_video_ops,
> but that's said to be deprecated. So maybe is the framework providing support
> for parsing those properties? Another grep there and I found only 
> v4l2-fwnode.c
> has support for parsing serial/parallel bus properties, but my understanding 
> is
> that those functions are meant to be used by the platform driver when
> parsing the remote fw node.
> 
> So please help me out here: where should I implement media bus configuration
> for sensor drivers?
> 
> Thanks
>j
> 
> PS: being this just an RFC I have not updated dt bindings, and only
> compile-tested the patch
> 
> ---
>  drivers/media/i2c/ov7670.c | 108 
> ++---
>  1 file changed, 101 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
> index e88549f..7e2de7e 100644
> --- a/drivers/media/i2c/ov7670.c
> +++ b/drivers/media/i2c/ov7670.c
> @@ -88,6 +88,7 @@ MODULE_PARM_DESC(debug, "Debug level (0-1)");
>  #define REG_COM100x15/* Control 10 */
>  #define   COM10_HSYNC  0x40/* HSYNC instead of HREF */
>  #define   COM10_PCLK_HB0x20/* Suppress PCLK on horiz blank */
> +#define   COM10_PCLK_REV  0x10 /* Latch data on PCLK rising edge */
>  #define   COM10_HREF_REV  0x08 /* Reverse HREF */
>  #define   COM10_VS_LEAD0x04/* VSYNC on clock leading edge */
>  #define   COM10_VS_NEG 0x02/* VSYNC negative */
> @@ -233,6 +234,7 @@ struct ov7670_info {
>   struct clk *clk;
>   struct gpio_desc *resetb_gpio;
>   struct gpio_desc *pwdn_gpio;
> + unsigned int mbus_config;   /* Media bus configuration flags */
>   int min_width;  /* Filter out smaller sizes */
>   int min_height; /* Filter out smaller sizes */
>   int clock_speed;/* External clock speed (MHz) */
> @@ -985,7 +987,7 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
>   struct ov7670_format_struct *ovfmt;
>   struct ov7670_win_size *wsize;
>   struct ov7670_info *info = to_state(sd);
> - unsigned char com7;
> + unsigned char com7, com10;
>   int ret;
> 
>   if (format->pad)
> @@ -1021,6 +1023,9 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
>   ret = 0;
>   if (wsize->regs)
>   ret = ov7670_write_array(sd, wsize->regs);
> + if (ret)
> + return ret;
> +
>   info->fmt = ovfmt;
> 
>   /*
> @@ -1033,8 +1038,26 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
>* to write it unconditionally, and that will make the frame
>* rate persistent too.
>*/
> - if (ret == 0)
> - ret = ov7670_write(sd, REG_CLKRC, info->clkrc);
> + ret = ov7670_write(sd, REG_CLKRC, info->clkrc);
> + if (ret)
> + return ret;
> +
> + /* Configure the media bus after the image format */
> + com10 = 0;
> + if (info->mbus_config & V4L2_MBUS_VSYNC_ACTIVE_LOW)
> + com10 |= COM10_VS_NEG;
> + if (info->mbus_config & V4L2_MBUS_HSYNC_ACTIVE_LOW)
> + com10 |= COM10_HS_NEG;
> + if (info->mbus_config & V4L2_MBUS_PCLK_SAMPLE_RISING)
> + com10 |= COM10_PCLK_REV;
> + if (info->pclk_hb_disable)
> + com10 |= COM10_PCLK_HB;
> +
> + if (com10)
> + ret = ov7670_write(sd, REG_COM10, com10);
> + if (ret)
> + return ret;
> +
>   return 0;
>  }
> 
> @@ -1572,6 +1595,29 @@ static int ov7670_init_gpio(struct i2c_client *client, 
> struct ov7670_info *info)
>   return 0;
>  }
> 
> +/**
> + * ov7670_parse_dt_prop() - parse 

Re: [PATCH] arm64: renesas: document V3MSK board bindings

2017-11-29 Thread Simon Horman
On Sun, Nov 26, 2017 at 04:29:05PM -0600, Rob Herring wrote:
> On Fri, Nov 24, 2017 at 11:47:39PM +0300, Sergei Shtylyov wrote:
> > Document the V3M Starter Kit device tree bindings, listing it as
> > a supported board.
> > 
> > This allows to use checkpatch.pl to validate .dts files referring to
> > the V3MSK board.
> > 
> > Signed-off-by: Sergei Shtylyov 
> > 
> > ---
> >  Documentation/devicetree/bindings/arm/shmobile.txt |2 ++
> >  1 file changed, 2 insertions(+)
> 
> Acked-by: Rob Herring 

Thanks, applied.


Re: [PATCH v4 00/12] ARM: dts: renesas: Update DTS for CMT DT binding rework

2017-11-29 Thread Simon Horman
On Tue, Nov 28, 2017 at 02:47:24PM +0100, Geert Uytterhoeven wrote:
>   Hi Simon, Magnus,
> 
> This patch series updates the CMT device nodes in the various Renesas DTS
> files sh_cmt clocksource driver for the recent DT binding rework that was
> merged in v4.14-rc1 and v4.15-rc1.
> 
> This series is an evolutionary improvement of Magnus Damm's series "[PATCH
> v2 00/11] clocksource: sh_cmt: DT binding rework V2":
> 
>   - Patches 1-5 update the compatible values for the CMT0 and CMT1 device
> nodes on R-Mobile APE6 and R-Car Gen2,
>   - Patches 6-12 remove the now obsolete "renesas,channels-mask" properties
> from the CMT device nodes on all affected SoCs.
> 
> Changes compared to v3:
>   - Rebase against renesas-devel-20171127-v4.15-rc1,
> 
> Changes compared to v2:
>   - Take over from Magnus,
>   - Update compatible values,
>   - Split in per-SoC patches,
> 
> Dependencies:
>   - "[PATCH v3 0/7] clocksource: sh_cmt: Update driver for DT binding
> rework" was merged in v4.15-rc1.
> 
> This has been part of renesas-drivers for more than two months, and part
> of my local development tree for more than two years.
> 
> Thanks for applying!

Thanks, applied.


Re: [PATCH v4] ARM: dts: r8a7794: Add SMP support

2017-11-29 Thread Simon Horman
On Wed, Nov 29, 2017 at 09:30:03AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Wed, Nov 29, 2017 at 9:26 AM, Simon Horman  wrote:
> > On Tue, Nov 28, 2017 at 02:39:01PM +0100, Geert Uytterhoeven wrote:
> >> From: Sergei Shtylyov 
> >>
> >> Add the device tree node for the Advanced Power Management Unit (APMU).
> >> Use the "enable-method" prop to  point out that the APMU should be used
> >> for the SMP support.
> >>
> >> Signed-off-by: Sergei Shtylyov 
> >> Signed-off-by: Geert Uytterhoeven 
> >> ---
> >> Dependency 3fd45a136ff61bb5 ("ARM: shmobile: rcar-gen2: Make sure
> >> CNTVOFF is initialized on CA7/15") is part of v4.15-rc1.
> >
> > sorry if this is a bit of a sore topic but I'd like to ask what sort of
> > testing this patch has seen. Are there any regressions in the area of
> > CPU hotplug, suspend to RAM and so on...
> 
> Last time I tried, CPU hotplug worked fine (on Alt).
> I cannot test suspend to RAM due to remote access.
> 
> Sergei?

Thanks for your help testing this. Both CPU hotplug and suspend-to-RAM
seem to work fine on Alt.o

I have applied this with:

Tested-by: Simon Horman 



Re: [PATCH 1/2] arm64: dts: renesas: initial V3MSK board device tree

2017-11-29 Thread Sergei Shtylyov

Hello!

On 11/29/2017 12:51 PM, Simon Horman wrote:


Add the initial device  tree for the V3M Starter Kit board.
The board has 1 debug serial port (SCIF0); include support for it,
so that the serial console can work.

Based on the original (and large) patch by Vladimir Barinov.

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 

---
  arch/arm64/boot/dts/renesas/Makefile   |2 -

[...]

Index: renesas/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
===
--- /dev/null
+++ renesas/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for the V3M Starter Kit board
+ *
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ * Copyright (C) 2017 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a77970.dtsi"
+
+/ {
+   model = "Renesas V3M Starter Kit board";
+   compatible = "renesas,v3msk", "renesas,r8a77970";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {


For consistency with other Renesas boards I would like to request the
following be added here:

bootargs = "ignore_loglevel rw";


   There's currently no consistency as ulcb.dtsi doesn't seem to specify 
"bootargs" prop at all. Moreover, this prop seems to be ignored by ARM64 
kernel -- I can only specify "bootargs" in U-Boot


MBR, Sergei


Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

2017-11-29 Thread Ulf Hansson
On 29 November 2017 at 10:43, Geert Uytterhoeven  wrote:
> Hi Ulf,
>
> On Wed, Nov 29, 2017 at 10:24 AM, Ulf Hansson  wrote:
>> On 29 November 2017 at 09:21, Yoshihiro Shimoda
>>  wrote:
 From: Ulf Hansson, Sent: Wednesday, November 29, 2017 2:23 AM
 On 28 November 2017 at 13:48, Yoshihiro Shimoda
  wrote:
 >> From: Geert Uytterhoeven, Sent: Tuesday, November 28, 2017 7:58 PM
 >> On Sun, Nov 12, 2017 at 1:27 AM, Rafael J. Wysocki  
 >> wrote:
 >> > From: Rafael J. Wysocki 
>>> 
 >> JFTR, this triggered before during system resume on e.g. Salvator-XS 
 >> with
 >> R-Car H3:
 >>
 >> ohci-platform ee08.usb: runtime PM trying to suspend device
 >> but active child
 >> phy_rcar_gen3_usb2 ee080200.usb-phy: runtime PM trying to suspend
 >> device but active child
 >> ohci-platform ee0c.usb: runtime PM trying to suspend device
 >> but active child
 >> ohci-platform ee0a.usb: runtime PM trying to suspend device
 >> but active child
 >> phy_rcar_gen3_usb2 ee0c0200.usb-phy: runtime PM trying to suspend
 >> device but active child
 >> phy_rcar_gen3_usb2 ee0a0200.usb-phy: runtime PM trying to suspend
 >> device but active child
 >>
 >> so this was an existing issue with USB before.
 >
 > Thank you for the report!
 > I know that, but since this didn't cause any trouble until now,
 > I postponed to investigate the issue... But, I investigate it today.
 > I don't find the root cause yet. However, it seems related to usb host 
 > and/or usb core.
 > --> USB host related devices' child_count will be 1 in suspend timing.
 >  --> I guess remote wakeup feature is enabled? But, I don't find the 
 > point yet.

 I am guessing the issue is triggered by genpd in the suspend noirq
 phase (genpd_suspend_noirq()). In there,  there is a call to
 pm_runtime_force_suspend() (which calls pm_runtime_set_suspended() and
 which triggered the earlier error messages being printed).

 The reason why genpd calls pm_runtime_force_suspend(), is because when
 validating wakeup configurations for the device "if
 (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))", it's
 thinks wakeup isn't configured while it probably should be.

 An additional note, only when genpd has the GENPD_FLAG_PM_CLK set,
 which makes the genpd->dev_ops.stop|start() being assigned, genpd
 calls pm_runtime_force_suspend() - else it doesn't.

 Perhaps try out the series I recently posted improving the code
 dealing with wakeups in genpd and the PM core:
 https://www.spinics.net/lists/linux-renesas-soc/msg20122.html
 To that, you need to set the new flag (invented in the above series)
 DPM_FLAG_IN_BAND_WAKEUP in the driver that configures wakeup of its
 device.

 Hope this helps!
>>>
>>> Thank you for the comments!
>>> I tried DPM_FLAG_IN_BAND_WAKEUP, but the issue still exists.
>>> I added the flag in the [eo]hci-platform driver and usb/core/driver.c.
>>> I also added the flag in the phy_rcar_gen3_usb2 driver except usb host 
>>> drivers.
>>
>> First, did you confirm that genpd was used? Then for what device?
>
> All 6 devices are part of the SYSC PM Domain.

Okay!

Can you perhaps clarify which 6 devices/drivers that are involved, and
perhaps also point out if their child devices?

>
>> Second, did you check the call to pm_runtime_force_suspend() called by
>> genpd, is the reason to the error messages?
>>
>> Third, it should be sufficient to add DPM_FLAG_IN_BAND_WAKEUP for the
>> driver that is actually dealing with the wakeup. Although, does this
>> driver's system ->suspend() callback check device_may_wakeup(), before
>> it decides to enable wakeup?
>> If not, the PM core and genpd don't notice that wakeup is enabled for
>> the device.
>
> Actually I saw this with my patches setting GENPD_FLAG_ACTIVE_WAKEUP
> for the SYSC PM Domain, which should trigger the same behavior.

Okay, so the problem remains no matter which solution for wakeup you
pick in genpd.

Then this seems to point to that the driver may be misbehaving in some
way. I can help to check what is going on.

Kind regards
Uffe


Re: [PATCH 2/2] arm64: dts: renesas: r8a77970: use SYSC power domain macros

2017-11-29 Thread Simon Horman
On Tue, Nov 28, 2017 at 11:15:45PM +0300, Sergei Shtylyov wrote:
> Now that the commit 833bdb47c826 ("dt-bindings: power: add R8A77970 SYSC
> power domain definitions") has hit Linus' tree, we can replace the  bare
> numbers  (we had to use to avoid a cross tree dependency) with these macro
> definitions...

Thanks, applied.


Re: [PATCH 1/2] arm64: dts: renesas: r8a77970: use CPG core clock macros

2017-11-29 Thread Simon Horman
On Tue, Nov 28, 2017 at 11:15:44PM +0300, Sergei Shtylyov wrote:
> Now that the commit ecadea00f588 ("dt-bindings: clock: Add R8A77970 CPG
> core clock definitions") has hit Linus' tree, we  can replace the bare
> numbers (we had to use to avoid a cross tree dependency) with these macro
> definitions...
> 
> Signed-off-by: Sergei Shtylyov 

Thanks, applied.


Re: [PATCH 0/3] arm64: dts: renesas: r8a77970: connect VIN to CSI40

2017-11-29 Thread Simon Horman
On Sun, Nov 26, 2017 at 01:50:09AM +0100, Niklas Söderlund wrote:
> Hi,
> 
> This series describes how to connect VIN0-3 to CSI40 and the HDMI input 
> of the adv7482 on the expansion board. It is tested on V3M together with 
> V3M enablement for VIN and CSI-2 drivers on-top of Kieran's 
> renesas-drivers-next-v3m branch [1].
> 
> It works and it's possible to program the EDID and capture frame frames.  
> Remember to switch SW18 to the off position to route the CSI-2 bus to 
> the expansion board instead of the MAX9286 for GMSL input.
> 
> 1. git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git

Hi Niklas,

how do you view the path to upstream of this patch-set?


Re: [PATCH] rcar-vin: enable support for r8a77970

2017-11-29 Thread Simon Horman
On Sun, Nov 26, 2017 at 01:23:48AM +0100, Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a77970.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  .../devicetree/bindings/media/rcar_vin.txt |  1 +
>  drivers/media/platform/rcar-vin/rcar-core.c| 40 
> ++
>  2 files changed, 41 insertions(+)
> 
> Hi,
> 
> I plan to include this patch in the next version of the series for Gen3 
> support. But to enable who wish to start working with VIN on V3M I
> send it out now as a separate patch as the big Gen3 series is waiting 
> for -rc1 to be available before being re-posted.

Thanks. With the above in mind I have marked this as an RFC in patchwork.


Re: [PATCH 1/2] arm64: dts: renesas: initial V3MSK board device tree

2017-11-29 Thread Simon Horman
On Fri, Nov 24, 2017 at 11:59:44PM +0300, Sergei Shtylyov wrote:
> Add the initial device  tree for the V3M Starter Kit board.
> The board has 1 debug serial port (SCIF0); include support for it,
> so that the serial console can work.
> 
> Based on the original (and large) patch by Vladimir Barinov.
> 
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  arch/arm64/boot/dts/renesas/Makefile   |2 -
>  arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts |   44 
> +
>  2 files changed, 45 insertions(+), 1 deletion(-)
> 
> Index: renesas/arch/arm64/boot/dts/renesas/Makefile
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/Makefile
> +++ renesas/arch/arm64/boot/dts/renesas/Makefile
> @@ -7,7 +7,7 @@ dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es
>  dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb
>  dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-m3ulcb-kf.dtb
>  dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
> -dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb
> +dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
>  dtb-$(CONFIG_ARCH_R8A77995) += r8a77995-draak.dtb
>  
>  always   := $(dtb-y)
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> ===
> --- /dev/null
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> @@ -0,0 +1,44 @@
> +/*
> + * Device Tree Source for the V3M Starter Kit board
> + *
> + * Copyright (C) 2017 Renesas Electronics Corp.
> + * Copyright (C) 2017 Cogent Embedded, Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +#include "r8a77970.dtsi"
> +
> +/ {
> + model = "Renesas V3M Starter Kit board";
> + compatible = "renesas,v3msk", "renesas,r8a77970";
> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {

For consistency with other Renesas boards I would like to request the
following be added here:

bootargs = "ignore_loglevel rw";

> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory@4800 {
> + device_type = "memory";
> + /* first 128MB is reserved for secure area. */
> + reg = <0x0 0x4800 0x0 0x3800>;
> + };
> +};
> +
> +_clk {
> + clock-frequency = <1666>;
> +};
> +
> +_clk {
> + clock-frequency = <32768>;
> +};
> +
> + {
> + status = "okay";
> +};
> 


Re: [PATCH 2/2] arm64: dts: renesas: v3msk: add EtherAVB support

2017-11-29 Thread Simon Horman
On Fri, Nov 24, 2017 at 11:59:45PM +0300, Sergei Shtylyov wrote:
> Define the V3M Starter Kit board dependent part of the EtherAVB
> device node.
> 
> Based on the original (and large) patch by Vladimir Barinov.
> 
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts |   11 +++
>  1 file changed, 11 insertions(+)

For consistency with other Renesas boards please consider reposing with the
following added to the chosen node.

bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";

> 
> Index: renesas/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> ===
> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77970-v3msk.dts
> @@ -31,6 +31,17 @@
>   };
>  };
>  
> + {
> + renesas,no-ether-link;
> + phy-handle = <>;
> + status = "okay";
> +
> + phy0: ethernet-phy@0 {
> + rxc-skew-ps = <1500>;
> + reg = <0>;
> + };
> +};
> +
>  _clk {
>   clock-frequency = <1666>;
>  };
> 


Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

2017-11-29 Thread Geert Uytterhoeven
Hi Ulf,

On Wed, Nov 29, 2017 at 10:24 AM, Ulf Hansson  wrote:
> On 29 November 2017 at 09:21, Yoshihiro Shimoda
>  wrote:
>>> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 2:23 AM
>>> On 28 November 2017 at 13:48, Yoshihiro Shimoda
>>>  wrote:
>>> >> From: Geert Uytterhoeven, Sent: Tuesday, November 28, 2017 7:58 PM
>>> >> On Sun, Nov 12, 2017 at 1:27 AM, Rafael J. Wysocki  
>>> >> wrote:
>>> >> > From: Rafael J. Wysocki 
>> 
>>> >> JFTR, this triggered before during system resume on e.g. Salvator-XS with
>>> >> R-Car H3:
>>> >>
>>> >> ohci-platform ee08.usb: runtime PM trying to suspend device
>>> >> but active child
>>> >> phy_rcar_gen3_usb2 ee080200.usb-phy: runtime PM trying to suspend
>>> >> device but active child
>>> >> ohci-platform ee0c.usb: runtime PM trying to suspend device
>>> >> but active child
>>> >> ohci-platform ee0a.usb: runtime PM trying to suspend device
>>> >> but active child
>>> >> phy_rcar_gen3_usb2 ee0c0200.usb-phy: runtime PM trying to suspend
>>> >> device but active child
>>> >> phy_rcar_gen3_usb2 ee0a0200.usb-phy: runtime PM trying to suspend
>>> >> device but active child
>>> >>
>>> >> so this was an existing issue with USB before.
>>> >
>>> > Thank you for the report!
>>> > I know that, but since this didn't cause any trouble until now,
>>> > I postponed to investigate the issue... But, I investigate it today.
>>> > I don't find the root cause yet. However, it seems related to usb host 
>>> > and/or usb core.
>>> > --> USB host related devices' child_count will be 1 in suspend timing.
>>> >  --> I guess remote wakeup feature is enabled? But, I don't find the 
>>> > point yet.
>>>
>>> I am guessing the issue is triggered by genpd in the suspend noirq
>>> phase (genpd_suspend_noirq()). In there,  there is a call to
>>> pm_runtime_force_suspend() (which calls pm_runtime_set_suspended() and
>>> which triggered the earlier error messages being printed).
>>>
>>> The reason why genpd calls pm_runtime_force_suspend(), is because when
>>> validating wakeup configurations for the device "if
>>> (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))", it's
>>> thinks wakeup isn't configured while it probably should be.
>>>
>>> An additional note, only when genpd has the GENPD_FLAG_PM_CLK set,
>>> which makes the genpd->dev_ops.stop|start() being assigned, genpd
>>> calls pm_runtime_force_suspend() - else it doesn't.
>>>
>>> Perhaps try out the series I recently posted improving the code
>>> dealing with wakeups in genpd and the PM core:
>>> https://www.spinics.net/lists/linux-renesas-soc/msg20122.html
>>> To that, you need to set the new flag (invented in the above series)
>>> DPM_FLAG_IN_BAND_WAKEUP in the driver that configures wakeup of its
>>> device.
>>>
>>> Hope this helps!
>>
>> Thank you for the comments!
>> I tried DPM_FLAG_IN_BAND_WAKEUP, but the issue still exists.
>> I added the flag in the [eo]hci-platform driver and usb/core/driver.c.
>> I also added the flag in the phy_rcar_gen3_usb2 driver except usb host 
>> drivers.
>
> First, did you confirm that genpd was used? Then for what device?

All 6 devices are part of the SYSC PM Domain.

> Second, did you check the call to pm_runtime_force_suspend() called by
> genpd, is the reason to the error messages?
>
> Third, it should be sufficient to add DPM_FLAG_IN_BAND_WAKEUP for the
> driver that is actually dealing with the wakeup. Although, does this
> driver's system ->suspend() callback check device_may_wakeup(), before
> it decides to enable wakeup?
> If not, the PM core and genpd don't notice that wakeup is enabled for
> the device.

Actually I saw this with my patches setting GENPD_FLAG_ACTIVE_WAKEUP
for the SYSC PM Domain, which should trigger the same behavior.

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


Re: [PATCH 2/3] arm64: dts: r8a7795: add DMA for SCIF2

2017-11-29 Thread Simon Horman
On Thu, Nov 16, 2017 at 09:07:26AM +, Chris Paterson wrote:
> Hello Ulrich,
> 
> > From: linux-renesas-soc-ow...@vger.kernel.org [mailto:linux-renesas-soc-
> > ow...@vger.kernel.org] On Behalf Of Ulrich Hecht
> > Sent: 15 November 2017 15:25
> > 
> > Tested on Draak.
> 
> I guess you meant for the patch title to use r8a77995?

I assumed so too. I fixed it up when applying.


Re: [PATCH 1/2] arm64: dts: renesas: r8a77970: add I2C support

2017-11-29 Thread Simon Horman
On Wed, Nov 22, 2017 at 02:06:59PM +0100, Geert Uytterhoeven wrote:
> Hi Sergei,
> 
> On Thu, Nov 16, 2017 at 10:06 PM, Sergei Shtylyov
>  wrote:
> > Define the generic R8A77970 parts of the I2C[0-4] device node.
> >
> > Based on the original (and large) patch by Daisuke Matsushita
> > .
> >
> > Signed-off-by: Vladimir Barinov 
> > Signed-off-by: Sergei Shtylyov 
> 
> Thanks for your patch!
> 
> > --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > +++ renesas/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> 
> > @@ -483,5 +491,85 @@
> > #address-cells = <1>;
> > #size-cells = <0>;
> > };
> > +
> > +   i2c0: i2c@e650 {
> > +   compatible = "renesas,i2c-r8a77970",
> > +"renesas,rcar-gen3-i2c";
> > +   reg = <0 0xe650 0 0x40>;
> > +   interrupts = ;
> > +   clocks = < CPG_MOD 931>;
> > +   power-domains = < 32>;
> > +   resets = < 931>;
> > +   dmas = < 0x91>, < 0x90>;
> 
> Can't all five i2c interfaces be used with both dmac1 and dmac2?
> 
> With that fixed:
> Reviewed-by: Geert Uytterhoeven 

Hi Sergei,

I have marked this series as "Changes Requested" in light of Geert's review
above. 


Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

2017-11-29 Thread Ulf Hansson
On 29 November 2017 at 09:21, Yoshihiro Shimoda
 wrote:
> Hi,
>
>> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 2:23 AM
>>
>> On 28 November 2017 at 13:48, Yoshihiro Shimoda
>>  wrote:
>> > Hi Geert-san,
>> >
>> >> From: Geert Uytterhoeven, Sent: Tuesday, November 28, 2017 7:58 PM
>> >>
>> >> Hi Rafael, Shimoda-san,
>> >>
>> >> On Sun, Nov 12, 2017 at 1:27 AM, Rafael J. Wysocki  
>> >> wrote:
>> >> > From: Rafael J. Wysocki 
> 
>> >> JFTR, this triggered before during system resume on e.g. Salvator-XS with
>> >> R-Car H3:
>> >>
>> >> ohci-platform ee08.usb: runtime PM trying to suspend device
>> >> but active child
>> >> phy_rcar_gen3_usb2 ee080200.usb-phy: runtime PM trying to suspend
>> >> device but active child
>> >> ohci-platform ee0c.usb: runtime PM trying to suspend device
>> >> but active child
>> >> ohci-platform ee0a.usb: runtime PM trying to suspend device
>> >> but active child
>> >> phy_rcar_gen3_usb2 ee0c0200.usb-phy: runtime PM trying to suspend
>> >> device but active child
>> >> phy_rcar_gen3_usb2 ee0a0200.usb-phy: runtime PM trying to suspend
>> >> device but active child
>> >>
>> >> so this was an existing issue with USB before.
>> >
>> > Thank you for the report!
>> > I know that, but since this didn't cause any trouble until now,
>> > I postponed to investigate the issue... But, I investigate it today.
>> > I don't find the root cause yet. However, it seems related to usb host 
>> > and/or usb core.
>> > --> USB host related devices' child_count will be 1 in suspend timing.
>> >  --> I guess remote wakeup feature is enabled? But, I don't find the point 
>> > yet.
>>
>> I am guessing the issue is triggered by genpd in the suspend noirq
>> phase (genpd_suspend_noirq()). In there,  there is a call to
>> pm_runtime_force_suspend() (which calls pm_runtime_set_suspended() and
>> which triggered the earlier error messages being printed).
>>
>> The reason why genpd calls pm_runtime_force_suspend(), is because when
>> validating wakeup configurations for the device "if
>> (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))", it's
>> thinks wakeup isn't configured while it probably should be.
>>
>> An additional note, only when genpd has the GENPD_FLAG_PM_CLK set,
>> which makes the genpd->dev_ops.stop|start() being assigned, genpd
>> calls pm_runtime_force_suspend() - else it doesn't.
>>
>> Perhaps try out the series I recently posted improving the code
>> dealing with wakeups in genpd and the PM core:
>> https://www.spinics.net/lists/linux-renesas-soc/msg20122.html
>> To that, you need to set the new flag (invented in the above series)
>> DPM_FLAG_IN_BAND_WAKEUP in the driver that configures wakeup of its
>> device.
>>
>> Hope this helps!
>
> Thank you for the comments!
> I tried DPM_FLAG_IN_BAND_WAKEUP, but the issue still exists.
> I added the flag in the [eo]hci-platform driver and usb/core/driver.c.
> I also added the flag in the phy_rcar_gen3_usb2 driver except usb host 
> drivers.

First, did you confirm that genpd was used? Then for what device?

Second, did you check the call to pm_runtime_force_suspend() called by
genpd, is the reason to the error messages?

Third, it should be sufficient to add DPM_FLAG_IN_BAND_WAKEUP for the
driver that is actually dealing with the wakeup. Although, does this
driver's system ->suspend() callback check device_may_wakeup(), before
it decides to enable wakeup?
If not, the PM core and genpd don't notice that wakeup is enabled for
the device.

>
>> > The renesas_usbhs also uses the phy_rcar_gen3_usb2 driver.
>> > --> If I only used the renesas_usbhs driver (in other words, I don't 
>> > install
>> > [eo]hci-{hcd,platform} drivers), the issue disappeared.
>> >  --> So, I think the phy_rcar_gen3_usb2 driver doesn't cause this issue.
>> > (But, it is possible to be related though.)
>> >
>> > I'll continue to investigate this issue tomorrow.
>>
>> Please keep me posted, I am interested about the why the problem exists. :-)
>
> Sure! :)

Great, thanks.

Kind regards
Uffe


Re: [PATCH v4] ARM: dts: r8a7794: Add SMP support

2017-11-29 Thread Geert Uytterhoeven
Hi Simon,

On Wed, Nov 29, 2017 at 9:26 AM, Simon Horman  wrote:
> On Tue, Nov 28, 2017 at 02:39:01PM +0100, Geert Uytterhoeven wrote:
>> From: Sergei Shtylyov 
>>
>> Add the device tree node for the Advanced Power Management Unit (APMU).
>> Use the "enable-method" prop to  point out that the APMU should be used
>> for the SMP support.
>>
>> Signed-off-by: Sergei Shtylyov 
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>> Dependency 3fd45a136ff61bb5 ("ARM: shmobile: rcar-gen2: Make sure
>> CNTVOFF is initialized on CA7/15") is part of v4.15-rc1.
>
> sorry if this is a bit of a sore topic but I'd like to ask what sort of
> testing this patch has seen. Are there any regressions in the area of
> CPU hotplug, suspend to RAM and so on...

Last time I tried, CPU hotplug worked fine (on Alt).
I cannot test suspend to RAM due to remote access.

Sergei?

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


Re: [PATCH v4] ARM: dts: r8a7794: Add SMP support

2017-11-29 Thread Simon Horman
On Tue, Nov 28, 2017 at 02:39:01PM +0100, Geert Uytterhoeven wrote:
> From: Sergei Shtylyov 
> 
> Add the device tree node for the Advanced Power Management Unit (APMU).
> Use the "enable-method" prop to  point out that the APMU should be used
> for the SMP support.
> 
> Signed-off-by: Sergei Shtylyov 
> Signed-off-by: Geert Uytterhoeven 
> ---
> Dependency 3fd45a136ff61bb5 ("ARM: shmobile: rcar-gen2: Make sure
> CNTVOFF is initialized on CA7/15") is part of v4.15-rc1.

Hi Geert,

sorry if this is a bit of a sore topic but I'd like to ask what sort of
testing this patch has seen. Are there any regressions in the area of
CPU hotplug, suspend to RAM and so on...


Re: [PATCH/LOCAL] arm64: defconfig: Refresh renesas_defconfig

2017-11-29 Thread Simon Horman
On Tue, Nov 28, 2017 at 02:35:45PM +0100, Geert Uytterhoeven wrote:
> RC_CORE defaults to n again since commit 5573d124292a01af ("[media]
> media: default for RC_CORE should be n").
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  arch/arm64/configs/renesas_defconfig | 1 -
>  1 file changed, 1 deletion(-)

Thanks, I have rebased the topic/renesas-defconfig branch on v4.15-rc1
and applied this on top.


RE: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

2017-11-29 Thread Yoshihiro Shimoda
Hi,

> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 2:23 AM
> 
> On 28 November 2017 at 13:48, Yoshihiro Shimoda
>  wrote:
> > Hi Geert-san,
> >
> >> From: Geert Uytterhoeven, Sent: Tuesday, November 28, 2017 7:58 PM
> >>
> >> Hi Rafael, Shimoda-san,
> >>
> >> On Sun, Nov 12, 2017 at 1:27 AM, Rafael J. Wysocki  
> >> wrote:
> >> > From: Rafael J. Wysocki 

> >> JFTR, this triggered before during system resume on e.g. Salvator-XS with
> >> R-Car H3:
> >>
> >> ohci-platform ee08.usb: runtime PM trying to suspend device
> >> but active child
> >> phy_rcar_gen3_usb2 ee080200.usb-phy: runtime PM trying to suspend
> >> device but active child
> >> ohci-platform ee0c.usb: runtime PM trying to suspend device
> >> but active child
> >> ohci-platform ee0a.usb: runtime PM trying to suspend device
> >> but active child
> >> phy_rcar_gen3_usb2 ee0c0200.usb-phy: runtime PM trying to suspend
> >> device but active child
> >> phy_rcar_gen3_usb2 ee0a0200.usb-phy: runtime PM trying to suspend
> >> device but active child
> >>
> >> so this was an existing issue with USB before.
> >
> > Thank you for the report!
> > I know that, but since this didn't cause any trouble until now,
> > I postponed to investigate the issue... But, I investigate it today.
> > I don't find the root cause yet. However, it seems related to usb host 
> > and/or usb core.
> > --> USB host related devices' child_count will be 1 in suspend timing.
> >  --> I guess remote wakeup feature is enabled? But, I don't find the point 
> > yet.
> 
> I am guessing the issue is triggered by genpd in the suspend noirq
> phase (genpd_suspend_noirq()). In there,  there is a call to
> pm_runtime_force_suspend() (which calls pm_runtime_set_suspended() and
> which triggered the earlier error messages being printed).
> 
> The reason why genpd calls pm_runtime_force_suspend(), is because when
> validating wakeup configurations for the device "if
> (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))", it's
> thinks wakeup isn't configured while it probably should be.
> 
> An additional note, only when genpd has the GENPD_FLAG_PM_CLK set,
> which makes the genpd->dev_ops.stop|start() being assigned, genpd
> calls pm_runtime_force_suspend() - else it doesn't.
> 
> Perhaps try out the series I recently posted improving the code
> dealing with wakeups in genpd and the PM core:
> https://www.spinics.net/lists/linux-renesas-soc/msg20122.html
> To that, you need to set the new flag (invented in the above series)
> DPM_FLAG_IN_BAND_WAKEUP in the driver that configures wakeup of its
> device.
> 
> Hope this helps!

Thank you for the comments!
I tried DPM_FLAG_IN_BAND_WAKEUP, but the issue still exists.
I added the flag in the [eo]hci-platform driver and usb/core/driver.c.
I also added the flag in the phy_rcar_gen3_usb2 driver except usb host drivers.

> > The renesas_usbhs also uses the phy_rcar_gen3_usb2 driver.
> > --> If I only used the renesas_usbhs driver (in other words, I don't install
> > [eo]hci-{hcd,platform} drivers), the issue disappeared.
> >  --> So, I think the phy_rcar_gen3_usb2 driver doesn't cause this issue.
> > (But, it is possible to be related though.)
> >
> > I'll continue to investigate this issue tomorrow.
> 
> Please keep me posted, I am interested about the why the problem exists. :-)

Sure! :)

Best regards,
Yoshihiro Shimoda

> Kind regards
> Uffe


RE: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

2017-11-29 Thread Yoshihiro Shimoda
Hi,

> From: Alan Stern, Sent: Wednesday, November 29, 2017 12:07 AM
> 
> On Tue, 28 Nov 2017, Yoshihiro Shimoda wrote:
> 
> > Hi Geert-san,
> >
> > > From: Geert Uytterhoeven, Sent: Tuesday, November 28, 2017 7:58 PM
> > >
> > > Hi Rafael, Shimoda-san,
> > >
> > > On Sun, Nov 12, 2017 at 1:27 AM, Rafael J. Wysocki  
> > > wrote:
> > > > From: Rafael J. Wysocki 

> > > JFTR, this triggered before during system resume on e.g. Salvator-XS with
> > > R-Car H3:
> > >
> > > ohci-platform ee08.usb: runtime PM trying to suspend device
> > > but active child
> > > phy_rcar_gen3_usb2 ee080200.usb-phy: runtime PM trying to suspend
> > > device but active child
> > > ohci-platform ee0c.usb: runtime PM trying to suspend device
> > > but active child
> > > ohci-platform ee0a.usb: runtime PM trying to suspend device
> > > but active child
> > > phy_rcar_gen3_usb2 ee0c0200.usb-phy: runtime PM trying to suspend
> > > device but active child
> > > phy_rcar_gen3_usb2 ee0a0200.usb-phy: runtime PM trying to suspend
> > > device but active child
> > >
> > > so this was an existing issue with USB before.
> >
> > Thank you for the report!
> > I know that, but since this didn't cause any trouble until now,
> > I postponed to investigate the issue... But, I investigate it today.
> > I don't find the root cause yet. However, it seems related to usb host 
> > and/or usb core.
> > --> USB host related devices' child_count will be 1 in suspend timing.
> >  --> I guess remote wakeup feature is enabled? But, I don't find the point 
> > yet.
> >
> > The renesas_usbhs also uses the phy_rcar_gen3_usb2 driver.

I'm so sorry, but this is mistake.
The renesas_usbhs doesn't use the phy_rcar_gen3_usb2 driver.
So,

> > --> If I only used the renesas_usbhs driver (in other words, I don't install
> > [eo]hci-{hcd,platform} drivers), the issue disappeared.
> >  --> So, I think the phy_rcar_gen3_usb2 driver doesn't cause this issue.
> > (But, it is possible to be related though.)

They are also mistake.

> > I'll continue to investigate this issue tomorrow.
> 
> Does the phy_rcar_gen3_usb2 driver use runtime PM?

Yes, the phy_rcar_gen3_usb2 uses runtime PM.

>  It looks like the
> phy device somehow gets enabled for runtime PM when it shouldn't be.

I also think that now.
I don't find why for now, but the usage_count of a phy device was not 1 just 
before suspend.
(This "a phy device" means the child of ee0a0200.usb-phy device.)

> (And by the way, what device is the child of ee0a0200.usb-phy?)

It's a phy device:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/phy-core.c?h=v4.15-rc1#n773

Best regards,
Yoshihiro Shimoda

> Alan Stern



Re: [PATCH v2] arm64: dts: renesas: r8a7795: Move nodes which have no reg property out of bus

2017-11-29 Thread Simon Horman
On Tue, Nov 28, 2017 at 10:04:00AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, Nov 28, 2017 at 9:56 AM, Simon Horman  wrote:
> > On Mon, Nov 27, 2017 at 12:15:39PM +0100, Geert Uytterhoeven wrote:
> >> On Mon, Nov 27, 2017 at 12:04 PM, Simon Horman  wrote:
> >> > I just noticed that with this patch applied I now see:
> >> >
> >> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
> >> > (interrupts_property): Missing interrupt-parent for /pmu_a57
> >> > arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
> >> > (interrupts_property): Missing interrupt-parent for /pmu_a53
> >> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
> >> > (interrupts_property): Missing interrupt-parent for /pmu_a57
> >> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
> >> > (interrupts_property): Missing interrupt-parent for 
> >> > /pmu_a53arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning 
> >> > (interrupts_property): Missing interrupt-parent for /timer
> >> >
> >> > arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dtb: Warning 
> >> > (interrupts_property): Missing interrupt-parent for /timer
> >>
> >> Right, the "interrupt-parent = <>;" inside the /soc node applies to 
> >> child
> >> nodes of the /soc node only.
> >>
> >> You can find this in two ways:
> 
> s/find/fix/
> 
> >>
> >>   1. Add "interrupt-parent = <>;" to the /pmu_a57 and /pmu_a53 nodes.
> >>   2. Switch those nodes from "interrupt" to "interrupts-extended", e.g. 
> >> turn
> >>
> >> interrupts = ,
> >>
> >>  into
> >>
> >> interrupts-extended = < GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> >>
> >> The latter is what e.g. arch/arm/boot/dts/armada-375.dtsi does.
> >
> > Thanks, I took option 1 as it seems consistent with the rest of the
> > Renesas DT files. I also added it to the /timer node.
> 
> Actually we recently had a discussion about this on IRC, triggered by a
> similar issue in board files (see e.g, Ethernet PHY interrupts).
> 
> Given the following comment:
> 
> drivers/of/irq.c:   /* Try the new-style interrupts-extended first */
> drivers/of/irq.c:   res = of_parse_phandle_with_args(device,
> "interrupts-extended",
> 
> I think it would be better to use interrupts-extended for individual/isolated
> use outside the /soc node.

Sure, will do.