[PATCH 0/2] arm64: renesas: add 12288000 for sound ADG

[Kuninori Morimoto]

Hi Simon

These adds missing audio clock settings to salvator / ulcb

Kuninori Morimoto (2):
  arm64: renesas: salvator-x: add 12288000 for sound ADG
  arm64: renesas: ulcb: add 12288000 for sound ADG

 arch/arm64/boot/dts/renesas/salvator-x.dtsi | 2 +-
 arch/arm64/boot/dts/renesas/ulcb.dtsi   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
1.9.1



Best regards
---
Kuninori Morimoto

[PATCH] ASoC: rsnd: SSI PIO adjust to 24bit mode

[Kuninori Morimoto]

From: Kuninori Morimoto 

commit 90431eb49bff ("ASoC: rsnd: don't use PDTA bit for 24bit on SSI")
fixups 24bit mode data alignment, but PIO was not cared.
This patch fixes PIO mode 24bit data alignment

Signed-off-by: Kuninori Morimoto 
---
> Mark, this is for mark/fix/rcar branch, not mark/topic/rcar

 sound/soc/sh/rcar/ssi.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 57daac0..0822ae0b 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -567,6 +567,13 @@ static void __rsnd_ssi_interrupt(struct rsnd_mod *mod,
struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
u32 *buf = (u32 *)(runtime->dma_area +
   rsnd_dai_pointer_offset(io, 0));
+   int shift = 0;
+
+   switch (runtime->sample_bits) {
+   case 32:
+   shift = 8;
+   break;
+   }
 
/*
 * 8/16/32 data can be assesse to TDR/RDR register
@@ -574,9 +581,9 @@ static void __rsnd_ssi_interrupt(struct rsnd_mod *mod,
 * see rsnd_ssi_init()
 */
if (rsnd_io_is_play(io))
-   rsnd_mod_write(mod, SSITDR, *buf);
+   rsnd_mod_write(mod, SSITDR, (*buf) << shift);
else
-   *buf = rsnd_mod_read(mod, SSIRDR);
+   *buf = (rsnd_mod_read(mod, SSIRDR) >> shift);
 
elapsed = rsnd_dai_pointer_update(io, sizeof(*buf));
}
-- 
1.9.1

[PATCH v2 03/17] rcar-vin: fix how pads are handled for v4l2 subdevice operations

[Niklas Söderlund]

From: Niklas Söderlund 

The rcar-vin driver only uses one pad, pad number 0.

- All v4l2 operations that did not check that the requested operation
  was for pad 0 have been updated with a check to enforce this.

- All v4l2 operations that stored (and later restored) the requested pad
  before substituting it for the subdevice pad number have been updated
  to not store the incoming pad and simply restore it to 0 after the
  subdevice operation is complete.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 7ca27599b9982ffc..610f59e2a9142622 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -550,14 +550,16 @@ static int rvin_enum_dv_timings(struct file *file, void 
*priv_fh,
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int pad, ret;
+   int ret;
+
+   if (timings->pad)
+   return -EINVAL;
 
-   pad = timings->pad;
timings->pad = vin->sink_pad_idx;
 
ret = v4l2_subdev_call(sd, pad, enum_dv_timings, timings);
 
-   timings->pad = pad;
+   timings->pad = 0;
 
return ret;
 }
@@ -600,14 +602,16 @@ static int rvin_dv_timings_cap(struct file *file, void 
*priv_fh,
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int pad, ret;
+   int ret;
+
+   if (cap->pad)
+   return -EINVAL;
 
-   pad = cap->pad;
cap->pad = vin->sink_pad_idx;
 
ret = v4l2_subdev_call(sd, pad, dv_timings_cap, cap);
 
-   cap->pad = pad;
+   cap->pad = 0;
 
return ret;
 }
@@ -616,17 +620,16 @@ static int rvin_g_edid(struct file *file, void *fh, 
struct v4l2_edid *edid)
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int input, ret;
+   int ret;
 
if (edid->pad)
return -EINVAL;
 
-   input = edid->pad;
edid->pad = vin->sink_pad_idx;
 
ret = v4l2_subdev_call(sd, pad, get_edid, edid);
 
-   edid->pad = input;
+   edid->pad = 0;
 
return ret;
 }
@@ -635,17 +638,16 @@ static int rvin_s_edid(struct file *file, void *fh, 
struct v4l2_edid *edid)
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int input, ret;
+   int ret;
 
if (edid->pad)
return -EINVAL;
 
-   input = edid->pad;
edid->pad = vin->sink_pad_idx;
 
ret = v4l2_subdev_call(sd, pad, set_edid, edid);
 
-   edid->pad = input;
+   edid->pad = 0;
 
return ret;
 }
-- 
2.13.0

[PATCH v2 06/17] rcar-vin: refactor pad lookup code

[Niklas Söderlund]

From: Niklas Söderlund 

The pad lookup code can be broken out to increase readability and to
reduce code duplication.

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

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 1a75191539b0e7d7..90ea582fb48e3cb5 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -870,11 +870,25 @@ static void rvin_notify(struct v4l2_subdev *sd,
}
 }
 
+static int rvin_find_pad(struct v4l2_subdev *sd, int direction)
+{
+   unsigned int pad;
+
+   if (sd->entity.num_pads <= 1)
+   return 0;
+
+   for (pad = 0; pad < sd->entity.num_pads; pad++)
+   if (sd->entity.pads[pad].flags & direction)
+   return pad;
+
+   return -EINVAL;
+}
+
 int rvin_v4l2_probe(struct rvin_dev *vin)
 {
struct video_device *vdev = >vdev;
struct v4l2_subdev *sd = vin_to_source(vin);
-   int pad_idx, ret;
+   int ret;
 
v4l2_set_subdev_hostdata(sd, vin);
 
@@ -920,21 +934,13 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
V4L2_CAP_READWRITE;
 
-   vin->digital.source_pad = 0;
-   for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++)
-   if (sd->entity.pads[pad_idx].flags == MEDIA_PAD_FL_SOURCE)
-   break;
-   if (pad_idx >= sd->entity.num_pads)
-   return -EINVAL;
-
-   vin->digital.source_pad = pad_idx;
+   ret = rvin_find_pad(sd, MEDIA_PAD_FL_SOURCE);
+   if (ret < 0)
+   return ret;
+   vin->digital.source_pad = ret;
 
-   vin->digital.sink_pad = 0;
-   for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++)
-   if (sd->entity.pads[pad_idx].flags == MEDIA_PAD_FL_SINK) {
-   vin->digital.sink_pad = pad_idx;
-   break;
-   }
+   ret = rvin_find_pad(sd, MEDIA_PAD_FL_SINK);
+   vin->digital.sink_pad = ret < 0 ? 0 : ret;
 
vin->format.pixelformat = RVIN_DEFAULT_FORMAT;
rvin_reset_format(vin);
-- 
2.13.0

[PATCH v2 13/17] rcar-vin: refactor and fold in function after stall handling rework

[Niklas Söderlund]

From: Niklas Söderlund 

With the driver stopping and starting the stream each time the driver is
stalled rvin_capture_off() can be folded in to the only caller.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index ae4febede5f79f28..b136844499f677cf 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -397,12 +397,6 @@ static void rvin_capture_on(struct rvin_dev *vin)
rvin_write(vin, VNFC_S_FRAME, VNFC_REG);
 }
 
-static void rvin_capture_off(struct rvin_dev *vin)
-{
-   /* Set continuous & single transfer off */
-   rvin_write(vin, 0, VNFC_REG);
-}
-
 static int rvin_capture_start(struct rvin_dev *vin)
 {
struct rvin_buffer *buf, *node;
@@ -436,7 +430,8 @@ static int rvin_capture_start(struct rvin_dev *vin)
 
 static void rvin_capture_stop(struct rvin_dev *vin)
 {
-   rvin_capture_off(vin);
+   /* Set continuous & single transfer off */
+   rvin_write(vin, 0, VNFC_REG);
 
/* Disable module */
rvin_write(vin, rvin_read(vin, VNMC_REG) & ~VNMC_ME, VNMC_REG);
-- 
2.13.0

[PATCH v2 11/17] rcar-vin: select capture mode based on free buffers

[Niklas Söderlund]

From: Niklas Söderlund 

Instead of selecting single or continuous capture mode based on how many
buffers userspace intends to give us select capture mode based on number
of free buffers we can allocate to hardware when the stream is started.

This change is a prerequisite to enable the driver to switch from
continuous to single capture mode (or the other way around) when the
driver is stalled by userspace not feeding it buffers as fast as it
consumes it.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 31 +++---
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 11e9799564299fca..47d78f68d715d945 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -405,7 +405,21 @@ static void rvin_capture_off(struct rvin_dev *vin)
 
 static int rvin_capture_start(struct rvin_dev *vin)
 {
-   int ret;
+   struct rvin_buffer *buf, *node;
+   int bufs, ret;
+
+   /* Count number of free buffers */
+   bufs = 0;
+   list_for_each_entry_safe(buf, node, >buf_list, list)
+   bufs++;
+
+   /* Continuous capture requires more buffers then there are HW slots */
+   vin->continuous = bufs > HW_BUFFER_NUM;
+
+   if (!rvin_fill_hw(vin)) {
+   vin_err(vin, "HW not ready to start, not enough buffers 
available\n");
+   return -EINVAL;
+   }
 
rvin_crop_scale_comp(vin);
 
@@ -1062,22 +1076,7 @@ static int rvin_start_streaming(struct vb2_queue *vq, 
unsigned int count)
vin->state = RUNNING;
vin->sequence = 0;
 
-   /* Continuous capture requires more buffers then there are HW slots */
-   vin->continuous = count > HW_BUFFER_NUM;
-
-   /*
-* This should never happen but if we don't have enough
-* buffers for HW bail out
-*/
-   if (!rvin_fill_hw(vin)) {
-   vin_err(vin, "HW not ready to start, not enough buffers 
available\n");
-   ret = -EINVAL;
-   goto out;
-   }
-
ret = rvin_capture_start(vin);
-out:
-   /* Return all buffers if something went wrong */
if (ret) {
return_all_buffers(vin, VB2_BUF_STATE_QUEUED);
v4l2_subdev_call(sd, video, s_stream, 0);
-- 
2.13.0

[PATCH v2 07/17] rcar-vin: move pad lookup to async bound handler

[Niklas Söderlund]

From: Niklas Söderlund 

Information about pads will be needed when enumerating the media bus
codes in the async complete handler which is run before
rvin_v4l2_probe(). Move the pad lookup to the async bound handler so
they are available when needed.

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

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 264604a9bcf86110..58fd04a7e9f1151b 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -31,6 +31,20 @@
 
 #define notifier_to_vin(n) container_of(n, struct rvin_dev, notifier)
 
+static int rvin_find_pad(struct v4l2_subdev *sd, int direction)
+{
+   unsigned int pad;
+
+   if (sd->entity.num_pads <= 1)
+   return 0;
+
+   for (pad = 0; pad < sd->entity.num_pads; pad++)
+   if (sd->entity.pads[pad].flags & direction)
+   return pad;
+
+   return -EINVAL;
+}
+
 static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
 {
struct v4l2_subdev *sd = entity->subdev;
@@ -101,13 +115,27 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
 struct v4l2_async_subdev *asd)
 {
struct rvin_dev *vin = notifier_to_vin(notifier);
+   int ret;
 
v4l2_set_subdev_hostdata(subdev, vin);
 
if (vin->digital.asd.match.fwnode.fwnode ==
of_fwnode_handle(subdev->dev->of_node)) {
-   vin_dbg(vin, "bound digital subdev %s\n", subdev->name);
+   /* Find surce and sink pad of remote subdevice */
+
+   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
+   if (ret < 0)
+   return ret;
+   vin->digital.source_pad = ret;
+
+   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
+   vin->digital.sink_pad = ret < 0 ? 0 : ret;
+
vin->digital.subdev = subdev;
+
+   vin_dbg(vin, "bound subdev %s source pad: %u sink pad: %u\n",
+   subdev->name, vin->digital.source_pad,
+   vin->digital.sink_pad);
return 0;
}
 
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 90ea582fb48e3cb5..be6f41bf82ac3bc5 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -870,20 +870,6 @@ static void rvin_notify(struct v4l2_subdev *sd,
}
 }
 
-static int rvin_find_pad(struct v4l2_subdev *sd, int direction)
-{
-   unsigned int pad;
-
-   if (sd->entity.num_pads <= 1)
-   return 0;
-
-   for (pad = 0; pad < sd->entity.num_pads; pad++)
-   if (sd->entity.pads[pad].flags & direction)
-   return pad;
-
-   return -EINVAL;
-}
-
 int rvin_v4l2_probe(struct rvin_dev *vin)
 {
struct video_device *vdev = >vdev;
@@ -934,14 +920,6 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
V4L2_CAP_READWRITE;
 
-   ret = rvin_find_pad(sd, MEDIA_PAD_FL_SOURCE);
-   if (ret < 0)
-   return ret;
-   vin->digital.source_pad = ret;
-
-   ret = rvin_find_pad(sd, MEDIA_PAD_FL_SINK);
-   vin->digital.sink_pad = ret < 0 ? 0 : ret;
-
vin->format.pixelformat = RVIN_DEFAULT_FORMAT;
rvin_reset_format(vin);
 
-- 
2.13.0

[PATCH v2 08/17] rcar-vin: use pad information when verifying media bus format

[Niklas Söderlund]

From: Niklas Söderlund 

Use information about pad index when enumerating mbus codes.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 58fd04a7e9f1151b..e67e4a57baadc3fb 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -53,6 +53,7 @@ static bool rvin_mbus_supported(struct rvin_graph_entity 
*entity)
};
 
code.index = 0;
+   code.pad = entity->source_pad;
while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, )) {
code.index++;
switch (code.code) {
-- 
2.13.0

[PATCH v2 02/17] rcar-vin: use rvin_reset_format() in S_DV_TIMINGS

[Niklas Söderlund]

From: Niklas Söderlund 

Use rvin_reset_format() in rvin_s_dv_timings() instead of just resetting
a few fields. This fixes an issue where the field format was not
properly set after S_DV_TIMINGS.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 69bc4cfea6a8aeb5..7ca27599b9982ffc 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -573,12 +573,8 @@ static int rvin_s_dv_timings(struct file *file, void 
*priv_fh,
if (ret)
return ret;
 
-   vin->source.width = timings->bt.width;
-   vin->source.height = timings->bt.height;
-   vin->format.width = timings->bt.width;
-   vin->format.height = timings->bt.height;
-
-   return 0;
+   /* Changing the timings will change the width/height */
+   return rvin_reset_format(vin);
 }
 
 static int rvin_g_dv_timings(struct file *file, void *priv_fh,
-- 
2.13.0

[PATCH v2 16/17] rcar-vin: add missing error check to propagate error

[Niklas Söderlund]

From: Niklas Söderlund 

The return value of __rvin_try_format_source is not checked, add a check
and propagate the error.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 6f1c27fc828fe57e..de71e5fa8b10cb5e 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -208,6 +208,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
 {
const struct rvin_video_format *info;
u32 rwidth, rheight, walign;
+   int ret;
 
/* Requested */
rwidth = pix->width;
@@ -235,7 +236,9 @@ static int __rvin_try_format(struct rvin_dev *vin,
pix->sizeimage = 0;
 
/* Limit to source capabilities */
-   __rvin_try_format_source(vin, which, pix, source);
+   ret = __rvin_try_format_source(vin, which, pix, source);
+   if (ret)
+   return ret;
 
switch (pix->field) {
case V4L2_FIELD_TOP:
-- 
2.13.0

[PATCH v2 12/17] rcar-vin: allow switch between capturing modes when stalling

[Niklas Söderlund]

From: Niklas Söderlund 

If userspace can't feed the driver with buffers as fast as the driver
consumes them the driver will stop video capturing and wait for more
buffers from userspace, the driver is stalled. Once it have been feed
one or more free buffers it will recover from the stall and resume
capturing.

Instead of continue to capture using the same capture mode as before the
stall allow the driver to choose between single and continuous mode
based on free buffer availability. Do this by stopping capturing when
the driver becomes stalled and restart capturing once it continues. By
doing
this the capture mode will be evaluated each time the driver is
recovering from a stall.

This behavior is needed to fix a bug where continuous capturing mode is
used, userspace is about to stop the stream and is waiting for the last
buffers to be returned from the driver and is not queuing any new
buffers. In this case the driver becomes stalled when there are only 3
buffers remaining streaming will never resume since the driver is
waiting for userspace to feed it more buffers before it can continue
streaming.  With this fix the driver will then switch to single capture
mode for the last 3 buffers and a deadlock is avoided. The issue can be
demonstrated using yavta.

$ yavta -f RGB565 -s 640x480 -n 4 --capture=10  /dev/video22
Device /dev/video22 opened.
Device `R_Car_VIN' on `platform:e6ef1000.video' (driver 'rcar_vin') supports 
video, capture, without mplanes.
Video format set: RGB565 (50424752) 640x480 (stride 1280) field interlaced 
buffer size 614400
Video format: RGB565 (50424752) 640x480 (stride 1280) field interlaced buffer 
size 614400
4 buffers requested.
length: 614400 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0xb6cc7000.
length: 614400 offset: 614400 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0xb6c31000.
length: 614400 offset: 1228800 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0xb6b9b000.
length: 614400 offset: 1843200 timestamp type/source: mono/EoF
Buffer 3/0 mapped at address 0xb6b05000.
0 (0) [-] interlaced 0 614400 B 38.240285 38.240303 12.421 fps ts mono/EoF
1 (1) [-] interlaced 1 614400 B 38.282329 38.282346 23.785 fps ts mono/EoF
2 (2) [-] interlaced 2 614400 B 38.322324 38.322338 25.003 fps ts mono/EoF
3 (3) [-] interlaced 3 614400 B 38.362318 38.362333 25.004 fps ts mono/EoF
4 (0) [-] interlaced 4 614400 B 38.402313 38.402328 25.003 fps ts mono/EoF
5 (1) [-] interlaced 5 614400 B 38.442307 38.442321 25.004 fps ts mono/EoF
6 (2) [-] interlaced 6 614400 B 38.482301 38.482316 25.004 fps ts mono/EoF
7 (3) [-] interlaced 7 614400 B 38.522295 38.522312 25.004 fps ts mono/EoF
8 (0) [-] interlaced 8 614400 B 38.562290 38.562306 25.003 fps ts mono/EoF


This fix also allow the driver to switch to single capture mode if
userspace doesn't feed it buffers fast enough. Or the other way around,
if userspace suddenly feeds the driver buffers faster it can switch to
continues capturing mode.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 47d78f68d715d945..ae4febede5f79f28 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -429,6 +429,8 @@ static int rvin_capture_start(struct rvin_dev *vin)
 
rvin_capture_on(vin);
 
+   vin->state = RUNNING;
+
return 0;
 }
 
@@ -907,7 +909,7 @@ static irqreturn_t rvin_irq(int irq, void *data)
struct rvin_dev *vin = data;
u32 int_status, vnms;
int slot;
-   unsigned int sequence, handled = 0;
+   unsigned int i, sequence, handled = 0;
unsigned long flags;
 
spin_lock_irqsave(>qlock, flags);
@@ -969,8 +971,20 @@ static irqreturn_t rvin_irq(int irq, void *data)
 * the VnMBm registers.
 */
if (vin->continuous) {
-   rvin_capture_off(vin);
+   rvin_capture_stop(vin);
vin_dbg(vin, "IRQ %02d: hw not ready stop\n", sequence);
+
+   /* Maybe we can continue in single capture mode */
+   for (i = 0; i < HW_BUFFER_NUM; i++) {
+   if (vin->queue_buf[i]) {
+   list_add(to_buf_list(vin->queue_buf[i]),
+>buf_list);
+   vin->queue_buf[i] = NULL;
+   }
+   }
+
+   if (!list_empty(>buf_list))
+   rvin_capture_start(vin);
}
} else {
 

[PATCH v2 10/17] rcar-vin: move functions which acts on hardware

[Niklas Söderlund]

From: Niklas Söderlund 

This only moves whole structs, defines and functions around, no code is
changed inside any function. The reason for moving this code around is
to prepare for refactoring and fixing of a start/stop stream bug without
having to use forward declarations.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 182 ++---
 1 file changed, 91 insertions(+), 91 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index c37f7a2993fb5565..11e9799564299fca 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -119,6 +119,15 @@
 #define VNDMR2_FTEV(1 << 17)
 #define VNDMR2_VLV(n)  ((n & 0xf) << 12)
 
+struct rvin_buffer {
+   struct vb2_v4l2_buffer vb;
+   struct list_head list;
+};
+
+#define to_buf_list(vb2_buffer) (_of(vb2_buffer, \
+  struct rvin_buffer, \
+  vb)->list)
+
 static void rvin_write(struct rvin_dev *vin, u32 value, u32 offset)
 {
iowrite32(value, vin->base + offset);
@@ -269,48 +278,6 @@ static int rvin_setup(struct rvin_dev *vin)
return 0;
 }
 
-static void rvin_capture_on(struct rvin_dev *vin)
-{
-   vin_dbg(vin, "Capture on in %s mode\n",
-   vin->continuous ? "continuous" : "single");
-
-   if (vin->continuous)
-   /* Continuous Frame Capture Mode */
-   rvin_write(vin, VNFC_C_FRAME, VNFC_REG);
-   else
-   /* Single Frame Capture Mode */
-   rvin_write(vin, VNFC_S_FRAME, VNFC_REG);
-}
-
-static void rvin_capture_off(struct rvin_dev *vin)
-{
-   /* Set continuous & single transfer off */
-   rvin_write(vin, 0, VNFC_REG);
-}
-
-static int rvin_capture_start(struct rvin_dev *vin)
-{
-   int ret;
-
-   rvin_crop_scale_comp(vin);
-
-   ret = rvin_setup(vin);
-   if (ret)
-   return ret;
-
-   rvin_capture_on(vin);
-
-   return 0;
-}
-
-static void rvin_capture_stop(struct rvin_dev *vin)
-{
-   rvin_capture_off(vin);
-
-   /* Disable module */
-   rvin_write(vin, rvin_read(vin, VNMC_REG) & ~VNMC_ME, VNMC_REG);
-}
-
 static void rvin_disable_interrupts(struct rvin_dev *vin)
 {
rvin_write(vin, 0, VNIE_REG);
@@ -377,6 +344,88 @@ static void rvin_set_slot_addr(struct rvin_dev *vin, int 
slot, dma_addr_t addr)
rvin_write(vin, offset, VNMB_REG(slot));
 }
 
+/* Moves a buffer from the queue to the HW slots */
+static bool rvin_fill_hw_slot(struct rvin_dev *vin, int slot)
+{
+   struct rvin_buffer *buf;
+   struct vb2_v4l2_buffer *vbuf;
+   dma_addr_t phys_addr_top;
+
+   if (vin->queue_buf[slot] != NULL)
+   return true;
+
+   if (list_empty(>buf_list))
+   return false;
+
+   vin_dbg(vin, "Filling HW slot: %d\n", slot);
+
+   /* Keep track of buffer we give to HW */
+   buf = list_entry(vin->buf_list.next, struct rvin_buffer, list);
+   vbuf = >vb;
+   list_del_init(to_buf_list(vbuf));
+   vin->queue_buf[slot] = vbuf;
+
+   /* Setup DMA */
+   phys_addr_top = vb2_dma_contig_plane_dma_addr(>vb2_buf, 0);
+   rvin_set_slot_addr(vin, slot, phys_addr_top);
+
+   return true;
+}
+
+static bool rvin_fill_hw(struct rvin_dev *vin)
+{
+   int slot, limit;
+
+   limit = vin->continuous ? HW_BUFFER_NUM : 1;
+
+   for (slot = 0; slot < limit; slot++)
+   if (!rvin_fill_hw_slot(vin, slot))
+   return false;
+   return true;
+}
+
+static void rvin_capture_on(struct rvin_dev *vin)
+{
+   vin_dbg(vin, "Capture on in %s mode\n",
+   vin->continuous ? "continuous" : "single");
+
+   if (vin->continuous)
+   /* Continuous Frame Capture Mode */
+   rvin_write(vin, VNFC_C_FRAME, VNFC_REG);
+   else
+   /* Single Frame Capture Mode */
+   rvin_write(vin, VNFC_S_FRAME, VNFC_REG);
+}
+
+static void rvin_capture_off(struct rvin_dev *vin)
+{
+   /* Set continuous & single transfer off */
+   rvin_write(vin, 0, VNFC_REG);
+}
+
+static int rvin_capture_start(struct rvin_dev *vin)
+{
+   int ret;
+
+   rvin_crop_scale_comp(vin);
+
+   ret = rvin_setup(vin);
+   if (ret)
+   return ret;
+
+   rvin_capture_on(vin);
+
+   return 0;
+}
+
+static void rvin_capture_stop(struct rvin_dev *vin)
+{
+   rvin_capture_off(vin);
+
+   /* Disable module */
+   rvin_write(vin, rvin_read(vin, VNMC_REG) & ~VNMC_ME, VNMC_REG);
+}
+
 /* 
-
  * Crop and Scaling Gen2
  */
@@ -839,55 +888,6 @@ void rvin_scale_try(struct 

[PATCH v2 04/17] rcar-vin: fix standard in input enumeration

[Niklas Söderlund]

From: Niklas Söderlund 

The driver supports a single input only, which can be either analog or
digital. If the subdevice supports dv_timings_cap the input is digital
and the driver should not fill in the standard.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 610f59e2a9142622..7be52c2036bb35fc 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -483,10 +483,14 @@ static int rvin_enum_input(struct file *file, void *priv,
return ret;
 
i->type = V4L2_INPUT_TYPE_CAMERA;
-   i->std = vin->vdev.tvnorms;
 
-   if (v4l2_subdev_has_op(sd, pad, dv_timings_cap))
+   if (v4l2_subdev_has_op(sd, pad, dv_timings_cap)) {
i->capabilities = V4L2_IN_CAP_DV_TIMINGS;
+   i->std = 0;
+   } else {
+   i->capabilities = V4L2_IN_CAP_STD;
+   i->std = vin->vdev.tvnorms;
+   }
 
strlcpy(i->name, "Camera", sizeof(i->name));
 
-- 
2.13.0

[PATCH v2 17/17] rcar-vin: fix bug in pixelformat selection

[Niklas Söderlund]

From: Niklas Söderlund 

If the requested pixelformat is not supported fallback to the default
format, do not revert the entire format.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index de71e5fa8b10cb5e..81ff59c3b4744075 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -206,7 +206,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
 struct v4l2_pix_format *pix,
 struct rvin_source_fmt *source)
 {
-   const struct rvin_video_format *info;
u32 rwidth, rheight, walign;
int ret;
 
@@ -218,17 +217,11 @@ static int __rvin_try_format(struct rvin_dev *vin,
if (pix->field == V4L2_FIELD_ANY)
pix->field = vin->format.field;
 
-   /*
-* Retrieve format information and select the current format if the
-* requested format isn't supported.
-*/
-   info = rvin_format_from_pixel(pix->pixelformat);
-   if (!info) {
-   vin_dbg(vin, "Format %x not found, keeping %x\n",
-   pix->pixelformat, vin->format.pixelformat);
-   *pix = vin->format;
-   pix->width = rwidth;
-   pix->height = rheight;
+   /* 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 */
-- 
2.13.0

[PATCH v2 14/17] rcar-vin: remove subdevice matching from bind and unbind callbacks

[Niklas Söderlund]

From: Niklas Söderlund 

There is only one subdevice registered with the async framework so there
is no need for the driver to check which subdevice is bound or unbound.
Remove these checks since the async framework preforms this.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 40 +++--
 1 file changed, 15 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index e67e4a57baadc3fb..dcca906ba58435f5 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -101,14 +101,9 @@ static void rvin_digital_notify_unbind(struct 
v4l2_async_notifier *notifier,
 {
struct rvin_dev *vin = notifier_to_vin(notifier);
 
-   if (vin->digital.subdev == subdev) {
-   vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
-   rvin_v4l2_remove(vin);
-   vin->digital.subdev = NULL;
-   return;
-   }
-
-   vin_err(vin, "no entity for subdev %s to unbind\n", subdev->name);
+   vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
+   rvin_v4l2_remove(vin);
+   vin->digital.subdev = NULL;
 }
 
 static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
@@ -120,28 +115,23 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
 
v4l2_set_subdev_hostdata(subdev, vin);
 
-   if (vin->digital.asd.match.fwnode.fwnode ==
-   of_fwnode_handle(subdev->dev->of_node)) {
-   /* Find surce and sink pad of remote subdevice */
+   /* Find surce and sink pad of remote subdevice */
 
-   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
-   if (ret < 0)
-   return ret;
-   vin->digital.source_pad = ret;
+   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
+   if (ret < 0)
+   return ret;
+   vin->digital.source_pad = ret;
 
-   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
-   vin->digital.sink_pad = ret < 0 ? 0 : ret;
+   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
+   vin->digital.sink_pad = ret < 0 ? 0 : ret;
 
-   vin->digital.subdev = subdev;
+   vin->digital.subdev = subdev;
 
-   vin_dbg(vin, "bound subdev %s source pad: %u sink pad: %u\n",
-   subdev->name, vin->digital.source_pad,
-   vin->digital.sink_pad);
-   return 0;
-   }
+   vin_dbg(vin, "bound subdev %s source pad: %u sink pad: %u\n",
+   subdev->name, vin->digital.source_pad,
+   vin->digital.sink_pad);
 
-   vin_err(vin, "no entity for subdev %s to bind\n", subdev->name);
-   return -EINVAL;
+   return 0;
 }
 
 static int rvin_digitial_parse_v4l2(struct rvin_dev *vin,
-- 
2.13.0

[PATCH v2 15/17] rcar-vin: register the video device at probe time

[Niklas Söderlund]

From: Niklas Söderlund 

The driver registers the video device from the async complete callback
and unregistered in the async unbind callback. This creates problems if
if the subdevice is bound, unbound and later rebound. The second time
video_register_device() is called it fails:

   kobject (eb3be918): tried to init an initialized object, something is 
seriously wrong.

To prevent this register the video device at prob time and don't allow
user-space to open the video device if the subdevice have not yet been
bound.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 47 ++---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 42 --
 drivers/media/platform/rcar-vin/rcar-vin.h  |  1 +
 3 files changed, 50 insertions(+), 40 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index dcca906ba58435f5..0e1757301a0bca1e 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -74,6 +74,7 @@ static bool rvin_mbus_supported(struct rvin_graph_entity 
*entity)
 static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
 {
struct rvin_dev *vin = notifier_to_vin(notifier);
+   struct v4l2_subdev *sd = vin_to_source(vin);
int ret;
 
/* Verify subdevices mbus format */
@@ -92,7 +93,35 @@ static int rvin_digital_notify_complete(struct 
v4l2_async_notifier *notifier)
return ret;
}
 
-   return rvin_v4l2_probe(vin);
+   /* Add the controls */
+   /*
+* Currently the subdev with the largest number of controls (13) is
+* ov6550. So let's pick 16 as a hint for the control handler. Note
+* that this is a hint only: too large and you waste some memory, too
+* small and there is a (very) small performance hit when looking up
+* controls in the internal hash.
+*/
+   ret = v4l2_ctrl_handler_init(>ctrl_handler, 16);
+   if (ret < 0)
+   return ret;
+
+   ret = v4l2_ctrl_add_handler(>ctrl_handler, sd->ctrl_handler, NULL);
+   if (ret < 0)
+   return ret;
+
+   ret = v4l2_subdev_call(sd, video, g_tvnorms, >vdev.tvnorms);
+   if (ret < 0 && ret != -ENOIOCTLCMD && ret != -ENODEV)
+   return ret;
+
+   if (vin->vdev.tvnorms == 0) {
+   /* Disable the STD API if there are no tvnorms defined */
+   v4l2_disable_ioctl(>vdev, VIDIOC_G_STD);
+   v4l2_disable_ioctl(>vdev, VIDIOC_S_STD);
+   v4l2_disable_ioctl(>vdev, VIDIOC_QUERYSTD);
+   v4l2_disable_ioctl(>vdev, VIDIOC_ENUMSTD);
+   }
+
+   return rvin_reset_format(vin);
 }
 
 static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
@@ -102,7 +131,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);
+   v4l2_ctrl_handler_free(>ctrl_handler);
vin->digital.subdev = NULL;
 }
 
@@ -290,9 +319,13 @@ static int rcar_vin_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   ret = rvin_v4l2_probe(vin);
+   if (ret)
+   goto error_dma;
+
ret = rvin_digital_graph_init(vin);
if (ret < 0)
-   goto error;
+   goto error_v4l2;
 
pm_suspend_ignore_children(>dev, true);
pm_runtime_enable(>dev);
@@ -300,7 +333,9 @@ static int rcar_vin_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, vin);
 
return 0;
-error:
+error_v4l2:
+   rvin_v4l2_remove(vin);
+error_dma:
rvin_dma_remove(vin);
 
return ret;
@@ -314,6 +349,10 @@ static int rcar_vin_remove(struct platform_device *pdev)
 
v4l2_async_notifier_unregister(>notifier);
 
+   /* Checks internaly if handlers have been init or not */
+   v4l2_ctrl_handler_free(>ctrl_handler);
+
+   rvin_v4l2_remove(vin);
rvin_dma_remove(vin);
 
return 0;
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index be6f41bf82ac3bc5..6f1c27fc828fe57e 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -103,7 +103,7 @@ static void rvin_reset_crop_compose(struct rvin_dev *vin)
vin->compose.height = vin->format.height;
 }
 
-static int rvin_reset_format(struct rvin_dev *vin)
+int rvin_reset_format(struct rvin_dev *vin)
 {
struct v4l2_subdev_format fmt = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
@@ -785,6 +785,11 @@ static int rvin_open(struct file *file)
 
mutex_lock(>lock);
 
+   if (!vin->digital.subdev) {

[PATCH v2 05/17] rcar-vin: move subdev source and sink pad index to rvin_graph_entity

[Niklas Söderlund]

From: Niklas Söderlund 

It makes more sense to store the sink and source pads in struct
rvin_graph_entity since that contains other subdevice related
information.

The data type to store pad information in is unsigned int and not int,
change this. While we are at it drop the _idx suffix from the names,
this never made sense.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 20 ++--
 drivers/media/platform/rcar-vin/rcar-vin.h  |  9 +
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 7be52c2036bb35fc..1a75191539b0e7d7 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -111,7 +111,7 @@ static int rvin_reset_format(struct rvin_dev *vin)
struct v4l2_mbus_framefmt *mf = 
int ret;
 
-   fmt.pad = vin->src_pad_idx;
+   fmt.pad = vin->digital.source_pad;
 
ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
if (ret)
@@ -178,7 +178,7 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
if (pad_cfg == NULL)
return -ENOMEM;
 
-   format.pad = vin->src_pad_idx;
+   format.pad = vin->digital.source_pad;
 
field = pix->field;
 
@@ -559,7 +559,7 @@ static int rvin_enum_dv_timings(struct file *file, void 
*priv_fh,
if (timings->pad)
return -EINVAL;
 
-   timings->pad = vin->sink_pad_idx;
+   timings->pad = vin->digital.sink_pad;
 
ret = v4l2_subdev_call(sd, pad, enum_dv_timings, timings);
 
@@ -611,7 +611,7 @@ static int rvin_dv_timings_cap(struct file *file, void 
*priv_fh,
if (cap->pad)
return -EINVAL;
 
-   cap->pad = vin->sink_pad_idx;
+   cap->pad = vin->digital.sink_pad;
 
ret = v4l2_subdev_call(sd, pad, dv_timings_cap, cap);
 
@@ -629,7 +629,7 @@ static int rvin_g_edid(struct file *file, void *fh, struct 
v4l2_edid *edid)
if (edid->pad)
return -EINVAL;
 
-   edid->pad = vin->sink_pad_idx;
+   edid->pad = vin->digital.sink_pad;
 
ret = v4l2_subdev_call(sd, pad, get_edid, edid);
 
@@ -647,7 +647,7 @@ static int rvin_s_edid(struct file *file, void *fh, struct 
v4l2_edid *edid)
if (edid->pad)
return -EINVAL;
 
-   edid->pad = vin->sink_pad_idx;
+   edid->pad = vin->digital.sink_pad;
 
ret = v4l2_subdev_call(sd, pad, set_edid, edid);
 
@@ -920,19 +920,19 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
V4L2_CAP_READWRITE;
 
-   vin->src_pad_idx = 0;
+   vin->digital.source_pad = 0;
for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++)
if (sd->entity.pads[pad_idx].flags == MEDIA_PAD_FL_SOURCE)
break;
if (pad_idx >= sd->entity.num_pads)
return -EINVAL;
 
-   vin->src_pad_idx = pad_idx;
+   vin->digital.source_pad = pad_idx;
 
-   vin->sink_pad_idx = 0;
+   vin->digital.sink_pad = 0;
for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++)
if (sd->entity.pads[pad_idx].flags == MEDIA_PAD_FL_SINK) {
-   vin->sink_pad_idx = pad_idx;
+   vin->digital.sink_pad = pad_idx;
break;
}
 
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 727e215c08718eb9..9bfb5a7c4dc4f215 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -74,6 +74,8 @@ struct rvin_video_format {
  * @subdev:subdevice matched using async framework
  * @code:  Media bus format from source
  * @mbus_cfg:  Media bus format from DT
+ * @source_pad:source pad of remote subdevice
+ * @sink_pad:  sink pad of remote subdevice
  */
 struct rvin_graph_entity {
struct v4l2_async_subdev asd;
@@ -81,6 +83,9 @@ struct rvin_graph_entity {
 
u32 code;
struct v4l2_mbus_config mbus_cfg;
+
+   unsigned int source_pad;
+   unsigned int sink_pad;
 };
 
 /**
@@ -91,8 +96,6 @@ struct rvin_graph_entity {
  *
  * @vdev:  V4L2 video device associated with VIN
  * @v4l2_dev:  V4L2 device
- * @src_pad_idx:   source pad index for media controller drivers
- * @sink_pad_idx:  sink pad index for media controller drivers
  * @ctrl_handler:  V4L2 control handler
  * @notifier:  V4L2 asynchronous subdevs notifier
  * @digital:   entity in the DT for local digital subdevice
@@ -121,8 +124,6 @@ struct rvin_dev {
 
struct video_device vdev;
struct v4l2_device 

[PATCH v2 00/17] rcar-vin: fix issues with format and capturing

[Niklas Söderlund]

From: Niklas Söderlund 

Hi,

This series fix a number of issues for the rcar-vin driver regarding
format and capturing. It is based on top of '[GIT PULL FOR v4.13] V4L2 
fwnode support' and tested on Koelsch.

Parts of this series where previously part of '[PATCH 00/11] media:
rcar-vin: fix OPS and format/pad index issues'. But after good reviews
a large part of that series where dropped.

* Changes since v1
- Do not consider the lack of a subdevice sink pad an error instead
  default to use pad 0 in such case. This keeps the behavior of the
  driver which previous versions of this series changed.
- When printing pad numbers print using %u not %d as they are unsigned.
- Keep comment in code which was lost when moving code around.
- If trying to set an unsupported pixel format do not switch the current
  format, instead switch to the first supported format of the driver to
  achieve a more deterministic behaviour.
- Add new patch to remove redundant checks in the async bind/unbind
  callbacks.
- Clarify some commit messages, thanks Laurent!
- Fix typos in commit messages, thanks Sergei and Laurent!
- Add Reviewed-by tags from Lauren

Niklas Söderlund (17):
  rcar-vin: reset bytesperline and sizeimage when resetting format
  rcar-vin: use rvin_reset_format() in S_DV_TIMINGS
  rcar-vin: fix how pads are handled for v4l2 subdevice operations
  rcar-vin: fix standard in input enumeration
  rcar-vin: move subdev source and sink pad index to rvin_graph_entity
  rcar-vin: refactor pad lookup code
  rcar-vin: move pad lookup to async bound handler
  rcar-vin: use pad information when verifying media bus format
  rcar-vin: decrease buffers needed to capture
  rcar-vin: move functions which acts on hardware
  rcar-vin: select capture mode based on free buffers
  rcar-vin: allow switch between capturing modes when stalling
  rcar-vin: refactor and fold in function after stall handling rework
  rcar-vin: remove subdevice matching from bind and unbind callbacks
  rcar-vin: register the video device at probe time
  rcar-vin: add missing error check to propagate error
  rcar-vin: fix bug in pixelformat selection

 drivers/media/platform/rcar-vin/rcar-core.c |  96 +---
 drivers/media/platform/rcar-vin/rcar-dma.c  | 230 ++--
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 139 ++---
 drivers/media/platform/rcar-vin/rcar-vin.h  |  10 +-
 4 files changed, 248 insertions(+), 227 deletions(-)

-- 
2.13.0

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

[Niklas Söderlund]

From: 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 
---
 .../devicetree/bindings/media/rcar-csi2.txt| 116 +
 1 file changed, 116 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt

diff --git a/Documentation/devicetree/bindings/media/rcar-csi2.txt 
b/Documentation/devicetree/bindings/media/rcar-csi2.txt
new file mode 100644
index ..f6e2027ee92b171a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rcar-csi2.txt
@@ -0,0 +1,116 @@
+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.
+
+ - compatible: Must be one or more of the following
+   - "renesas,r8a7795-csi2" for the R8A7795 device.
+   - "renesas,r8a7796-csi2" for the R8A7796 device.
+   - "renesas,rcar-gen3-csi2" for a generic R-Car Gen3 compatible device.
+
+   When compatible with a generic version nodes must list the
+   SoC-specific version corresponding to the platform first
+   followed by the generic version.
+
+ - 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 should contain two 'port' child nodes according to the
+bindings defined in Documentation/devicetree/bindings/media/
+video-interfaces.txt. Port 0 should connect the node that is the video
+source for to the CSI-2. Port 1 should connect all the R-Car VIN
+modules, which can make use of the CSI-2 module.
+
+- Port 0 - Video source
+   - Reg 0 - sub-node describing the endpoint that is the video source
+
+- Port 1 - VIN instances
+   - Reg 0 - sub-node describing the endpoint that is VIN0
+   - Reg 1 - sub-node describing the endpoint that is VIN1
+   - Reg 2 - sub-node describing the endpoint that is VIN2
+   - Reg 3 - sub-node describing the endpoint that is VIN3
+   - Reg 4 - sub-node describing the endpoint that is VIN4
+   - Reg 5 - sub-node describing the endpoint that is VIN5
+   - Reg 6 - sub-node describing the endpoint that is VIN6
+   - Reg 7 - sub-node describing the endpoint that is VIN7
+
+Example:
+
+/* SoC properties */
+
+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>;
+status = "disabled";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+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 {
+reg = <2>;
+remote-endpoint = <>;
+};
+csi20vin3: endpoint@3 {
+reg = <3>;
+remote-endpoint = <>;
+};
+csi20vin4: endpoint@4 {
+reg = 

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

[Niklas Söderlund]

From: 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 
---
 drivers/media/platform/rcar-vin/Kconfig |  12 +
 drivers/media/platform/rcar-vin/Makefile|   1 +
 drivers/media/platform/rcar-vin/rcar-csi2.c | 867 
 3 files changed, 880 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 ..1175f1fe4b139a13
--- /dev/null
+++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
@@ -0,0 +1,867 @@
+/*
+ * 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 
+
+/* Register offsets and bits */
+
+/* Control Timing Select */
+#define TREF_REG   0x00
+#define TREF_TREF  (1 << 0)
+
+/* Software Reset */
+#define SRST_REG   0x04
+#define SRST_SRST  (1 << 0)
+
+/* PHY Operation Control */
+#define PHYCNT_REG 0x08
+#define PHYCNT_SHUTDOWNZ   (1 << 17)
+#define PHYCNT_RSTZ(1 << 16)
+#define PHYCNT_ENABLECLK   (1 << 4)
+#define PHYCNT_ENABLE_3(1 << 3)
+#define PHYCNT_ENABLE_2(1 << 2)
+#define PHYCNT_ENABLE_1(1 << 1)
+#define PHYCNT_ENABLE_0(1 << 0)
+
+/* Checksum Control */
+#define CHKSUM_REG 0x0c
+#define CHKSUM_ECC_EN  (1 << 1)
+#define CHKSUM_CRC_EN  (1 << 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  (1 << 15)
+#define VCDT_SEL_VC(n) (((n) & 0x3) << 8)
+#define VCDT_SEL_DTN_ON(1 << 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_EN4(1 << 3)
+#define FLD_FLD_EN3(1 << 2)
+#define FLD_FLD_EN2(1 << 1)
+#define FLD_FLD_EN (1 << 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
+
+/* 

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

[Niklas Söderlund]

From: Niklas Söderlund 

Hi,

This is the latest incarnation of R-Car MIPI CSI-2 receiver driver. It's
based on top of v4.12-rc1 and are tested on Renesas Salvator-X together
with the out of tree patches for rcar-vin to add support for Gen3 VIN
and a prototype driver for ADV7482. If anyone is interested to test
video grabbing using these out of tree patches please see [1].

It depends on the patches:

- [GIT PULL FOR v4.13] V4L2 fwnode support
- [PATCH v2 0/2] v4l2-async: add subnotifier registration for subdevices
- [PATCH v2 0/2] media: entity: add operation to help map DT node to media pad

Changes since v6:
- Rebased on top of Sakaris fwnode patches.
- Changed of RCAR_CSI2_PAD_MAX to NR_OF_RCAR_CSI2_PAD.
- Remove assumtion about unkown medis 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 from MEDIA_ENT_F_ATV_DECODER to 
  MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER as entity function. I can't
  find a more suitable function, and what the hardware do is to fetch
  video from an external chip and passes it on to a another SoC internal
  IP it's sort of a formatter.
- Break out DT documentation and code in two patches.

Changes since v3:
- Update DT binding documentation with input from Geert Uytterhoeven,
  thanks!

Changes since v2:
- Added media control pads as this is needed by the new rcar-vin driver.
- Update DT bindings after review comments and to add r8a7796 support.
- Add get_fmt handler.
- Fix media bus format error s/YUYV8/UYVY8/

Changes since v1:
- Drop dependency on a pad aware s_stream operation.
- Use the DT bindings format "renesas,-", thanks Geert
  for pointing this out.

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

Niklas Söderlund (2):
  media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation
  media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

 .../devicetree/bindings/media/rcar-csi2.txt| 116 +++
 drivers/media/platform/rcar-vin/Kconfig|  12 +
 drivers/media/platform/rcar-vin/Makefile   |   1 +
 drivers/media/platform/rcar-vin/rcar-csi2.c| 867 +
 4 files changed, 996 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt
 create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c

-- 
2.13.0

[PATCH v2 1/2] media: entity: Add pad_from_fwnode entity operation

[Niklas Söderlund]

From: Niklas Söderlund 

The optional operation can be used by entities to report how it maps its
fwnode endpoints to media pad numbers. This is useful for devices which
require advanced mappings of pads.

Signed-off-by: Niklas Söderlund 
---
 include/media/media-entity.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index c7c254c5bca1761b..2aea22b0409d1070 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -171,6 +172,9 @@ struct media_pad {
 
 /**
  * struct media_entity_operations - Media entity operations
+ * @pad_from_fwnode:   Return the pad number based on a fwnode endpoint.
+ * This operation can be used to map a fwnode to a
+ * media pad number. Optional.
  * @link_setup:Notify the entity of link changes. The 
operation can
  * return an error, in which case link setup will be
  * cancelled. Optional.
@@ -184,6 +188,8 @@ struct media_pad {
  *mutex held.
  */
 struct media_entity_operations {
+   int (*pad_from_fwnode)(struct fwnode_endpoint *endpoint,
+  unsigned int *pad);
int (*link_setup)(struct media_entity *entity,
  const struct media_pad *local,
  const struct media_pad *remote, u32 flags);
-- 
2.13.0

[PATCH v2 2/2] media: entity: Add media_entity_pad_from_fwnode() function

[Niklas Söderlund]

From: Niklas Söderlund 

This is a wrapper around the media entity pad_from_fwnode operation.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/media-entity.c | 39 +++
 include/media/media-entity.h | 22 ++
 2 files changed, 61 insertions(+)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index bc44193efa4798b4..c124754f739a8b94 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -386,6 +387,44 @@ struct media_entity *media_graph_walk_next(struct 
media_graph *graph)
 }
 EXPORT_SYMBOL_GPL(media_graph_walk_next);
 
+int media_entity_pad_from_fwnode(struct media_entity *entity,
+struct fwnode_handle *fwnode,
+int direction, unsigned int *pad)
+{
+   struct fwnode_endpoint endpoint;
+   int i, tmp, ret;
+
+   if (!entity->ops || !entity->ops->pad_from_fwnode) {
+   for (i = 0; i < entity->num_pads; i++) {
+   if (entity->pads[i].flags & direction) {
+   *pad = i;
+   return 0;
+   }
+   }
+
+   return -ENXIO;
+   }
+
+   ret = fwnode_graph_parse_endpoint(fwnode, );
+   if (ret)
+   return ret;
+
+   ret = entity->ops->pad_from_fwnode(, );
+   if (ret)
+   return ret;
+
+   if (tmp >= entity->num_pads)
+   return -ENXIO;
+
+   if (!(entity->pads[tmp].flags & direction))
+   return -ENXIO;
+
+   *pad = tmp;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(media_entity_pad_from_fwnode);
+
 /* 
-
  * Pipeline management
  */
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 2aea22b0409d1070..7507181609bec43c 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -822,6 +822,28 @@ struct media_pad *media_entity_remote_pad(struct media_pad 
*pad);
 struct media_entity *media_entity_get(struct media_entity *entity);
 
 /**
+ * media_entity_pad_from_fwnode - Get pad number from fwnode
+ *
+ * @entity: The entity
+ * @fwnode: Pointer to fwnode_handle which should be used to find pad
+ * @direction: Expected direction of the pad
+ * @pad: Pointer to pad which will should be filled in
+ *
+ * This function can be used to resolve the media pad number from
+ * a fwnode. This is useful for devices which uses more complex
+ * mappings of media pads.
+ *
+ * If the entity do not implement the pad_from_fwnode() operation
+ * this function searches the entity for the first pad that matches
+ * the @direction.
+ *
+ * Return: return 0 on success.
+ */
+int media_entity_pad_from_fwnode(struct media_entity *entity,
+struct fwnode_handle *fwnode,
+int direction, unsigned int *pad);
+
+/**
  * media_graph_walk_init - Allocate resources used by graph walk.
  *
  * @graph: Media graph structure that will be used to walk the graph
-- 
2.13.0

[PATCH v2 0/2] media: entity: add operation to help map DT node to media pad

[Niklas Söderlund]

From: Niklas Söderlund 

Hi,

This series add a new entity operation which will aid capture
drivers to map a port/endpoint in DT to a media graph pad.

This series is implemented support for the ongoing ADV748x work by 
Kieran Bingham. In his work he have a driver which registers more then 
one subdevice. So when a driver finds this subdevice it must be able to 
ask the subdevice itself which pad number correspond to the DT endpoint 
the driver used to bind subdevice in the first place.

This is tested on Renesas H3 and M3-W together with the Renesas CSI-2 
and VIN Gen3 driver (posted separately). It is based on top of Sakaris 
pull request '[GIT PULL FOR v4.13] V4L2 fwnode support'.

* Changes since v1
- Rebased work ontop of Sakaris fwnode branch and make use of the fwnode 
  instead of the raw DT port/reg numbers.
- Do not assume DT port is equal to pad number if the driver do not 
  implement the lookup function. Instead search for the first pad with 
  the correct direction and use that. Thanks Sakari for the suggestion!
- Use ENXIO instead of EINVAL to signal lookup error.

Niklas Söderlund (2):
  media: entity: Add pad_from_fwnode entity operation
  media: entity: Add media_entity_pad_from_fwnode() function

 drivers/media/media-entity.c | 39 +++
 include/media/media-entity.h | 28 
 2 files changed, 67 insertions(+)

-- 
2.13.0

[PATCH v2 2/2] v4l: async: add subnotifier registration for subdevices

[Niklas Söderlund]

From: Niklas Söderlund 

When registered() of v4l2_subdev_internal_ops is called the subdevice
have access to the master devices v4l2_dev and it's called with the
async frameworks list_lock held. In this context the subdevice can
register its own notifiers to allow for incremental discovery of
subdevices.

The master device registers the subdevices closest to itself in its
notifier while the subdevice(s) themself register notifiers for there
closest neighboring devices when they are registered. Using this
incremental approach two problems can be solved.

1. The master device no longer have to care how many devices exist in
   the pipeline. It only needs to care about its closest subdevice and
   arbitrary long pipelines can be created without having to adapt the
   master device for each case.

2. Subdevices which are represented as a single DT node but register
   more then one subdevice can use this to further the pipeline
   discovery. Since the subdevice driver is the only one who knows which
   of its subdevices is linked with which subdevice of a neighboring DT
   node.

To enable subdevices to register/unregister notifiers from the
registered()/unregistered() callback v4l2_async_subnotifier_register()
and v4l2_async_subnotifier_unregister() are added. These new notifier
register functions are similar to the master device equivalent functions
but run without taking the v4l2-async list_lock which already are held
when he registered()/unregistered() callbacks are called.

Signed-off-by: Niklas Söderlund 
---
 Documentation/media/kapi/v4l2-subdev.rst | 20 
 drivers/media/v4l2-core/v4l2-async.c | 88 ++--
 include/media/v4l2-async.h   | 22 
 3 files changed, 113 insertions(+), 17 deletions(-)

diff --git a/Documentation/media/kapi/v4l2-subdev.rst 
b/Documentation/media/kapi/v4l2-subdev.rst
index e1f0b726e438f963..28ae681c63ff1330 100644
--- a/Documentation/media/kapi/v4l2-subdev.rst
+++ b/Documentation/media/kapi/v4l2-subdev.rst
@@ -262,6 +262,26 @@ is called. After all subdevices have been located the 
.complete() callback is
 called. When a subdevice is removed from the system the .unbind() method is
 called. All three callbacks are optional.
 
+Subdevice drivers might in turn register subnotifier objects with an
+array of other subdevice descriptors that the subdevice needs for its
+own operation. Subnotifiers are an extension of the bridge drivers
+notifier to allow for a incremental registering and matching of
+subdevices. This is useful when a driver only have information about
+which subdevice is closet it self and would require knowledge from the
+driver of that subdevice to know which other subdevice(s) lies beyond.
+By registering subnotifiers drivers can incrementally move the subdevice
+matching down the chain of drivers. This is performed using the
+:c:func:`v4l2_async_subnotifier_register` call. To unregister the
+subnotifier the driver has to call
+:c:func:`v4l2_async_subnotifier_unregister`. These functions and its
+arguments behave almost the same as the bridge driver notifiers
+described above and are treated equally by the V4L2 core when matching
+asynchronously registered subdevices. The differences are that the
+subnotifier functions act on :c:type:`v4l2_subdev` instead of
+:c:type:`v4l2_device` and that they should be called from the subdevices
+``.registered()`` and ``.unregistered()``
+:c:type:`v4l2_subdev_internal_ops` callbacks instead of at probe time.
+
 V4L2 sub-device userspace API
 -
 
diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index c16200c88417b151..e1e181db90f789c0 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -141,11 +141,13 @@ static void v4l2_async_cleanup(struct v4l2_subdev *sd)
sd->dev = NULL;
 }
 
-int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
-struct v4l2_async_notifier *notifier)
+static int v4l2_async_do_notifier_register(struct v4l2_device *v4l2_dev,
+  struct v4l2_async_notifier *notifier,
+  bool subnotifier)
 {
struct v4l2_subdev *sd, *tmp;
struct v4l2_async_subdev *asd;
+   bool found;
int i;
 
if (!v4l2_dev || !notifier->num_subdevs ||
@@ -174,32 +176,65 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
list_add_tail(>list, >waiting);
}
 
-   mutex_lock(_lock);
+   if (subnotifier)
+   lockdep_assert_held(_lock);
+   else
+   mutex_lock(_lock);
+
+   /*
+* This function can be called recursively so the list
+* might be modified in a recursive call. Start from the
+* top of the list each iteration.
+*/
+   found = 

[PATCH v2 1/2] v4l: async: check for v4l2_dev in v4l2_async_notifier_register()

[Niklas Söderlund]

From: Niklas Söderlund 

Add a check for v4l2_dev to v4l2_async_notifier_register() as to fail as
early as possible since this will fail later in v4l2_async_test_notify().

Signed-off-by: Niklas Söderlund 
---
 drivers/media/v4l2-core/v4l2-async.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index cbd919d4edd27e17..c16200c88417b151 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -148,7 +148,8 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
struct v4l2_async_subdev *asd;
int i;
 
-   if (!notifier->num_subdevs || notifier->num_subdevs > V4L2_MAX_SUBDEVS)
+   if (!v4l2_dev || !notifier->num_subdevs ||
+   notifier->num_subdevs > V4L2_MAX_SUBDEVS)
return -EINVAL;
 
notifier->v4l2_dev = v4l2_dev;
-- 
2.13.0

[PATCH v2 0/2] v4l2-async: add subnotifier registration for subdevices

[Niklas Söderlund]

From: Niklas Söderlund 

Hi,

This series enables incremental async find and bind of subdevices, 
please se patch 2/2 for a more detailed description.

This is tested on Renesas H3 and M3-W together with the Renesas CSI-2 
and VIN Gen3 driver (posted separately). It is based on top of Sakaris 
pull request '[GIT PULL FOR v4.13] V4L2 fwnode support'. While this 
series do not require the fwnode support the code that makes us of this 
feature do.

Changes since v1:
- Added a pre-patch which adds an error check which was previously in 
  the new incremental async code but is more useful on its own.
- Added documentation to Documentation/media/kapi/v4l2-subdev.rst.
- Fixed data type of bool variable.
- Added call to lockdep_assert_held(), thanks Sakari.
- Fixed commit messages typo, thanks Sakari.

Niklas Söderlund (2):
  v4l: async: check for v4l2_dev in v4l2_async_notifier_register()
  v4l: async: add subnotifier registration for subdevices

 Documentation/media/kapi/v4l2-subdev.rst | 20 +++
 drivers/media/v4l2-core/v4l2-async.c | 91 +---
 include/media/v4l2-async.h   | 22 
 3 files changed, 115 insertions(+), 18 deletions(-)

-- 
2.13.0

[PATCH v4] v4l: async: Match parent devices

[Kieran Bingham]

From: Kieran Bingham 

Devices supporting multiple endpoints on a single device node must set
their subdevice fwnode to the endpoint to allow distinct comparisons.

Adapt the match_fwnode call to compare against the provided fwnodes
first, but to also perform a cross reference comparison against the
parent fwnodes of each other.

This allows notifiers to pass the endpoint for comparison and still
support existing subdevices which store their default parent device
node.

Signed-off-by: Kieran Bingham 
---
Hi Sakari,

I've respun, rebased, and retested this patch.
Hopefully it's good for moving forwards now.

If you have any concerns about the comments as I've changed them, feel free to
adjust as you see fit if you are planning to take this patch on one of your
existing series

v2:
 - Added documentation comments
 - simplified the OF match by adding match_fwnode_of()

v3:
 - Fix comments
 - Fix sd_parent, and asd_parent usage

v4:
 - Clean up and simplify match_fwnode and comparisons

 drivers/media/v4l2-core/v4l2-async.c | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index cbd919d4edd2..dbc6adb1347d 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -41,14 +41,34 @@ static bool match_devname(struct v4l2_subdev *sd,
return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
 }
 
+/*
+ * As a measure to support drivers which have not been converted to use
+ * endpoint matching, we also find the parent devices for cross-matching.
+ *
+ * This also allows continued support for matching subdevices which will not
+ * have an endpoint themselves.
+ */
+
+static bool __match_fwnode(struct fwnode_handle *a, struct fwnode_handle *b)
+{
+   if (is_of_node(a) && is_of_node(b))
+   return !of_node_cmp(of_node_full_name(to_of_node(a)),
+   of_node_full_name(to_of_node(b)));
+   else
+   return a == b;
+}
+
 static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
 {
-   if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
-   return sd->fwnode == asd->match.fwnode.fwnode;
+   struct fwnode_handle *asd_fwnode = asd->match.fwnode.fwnode;
+   struct fwnode_handle *sd_parent, *asd_parent;
+
+   sd_parent = fwnode_graph_get_port_parent(sd->fwnode);
+   asd_parent = fwnode_graph_get_port_parent(asd_fwnode);
 
-   return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
-   of_node_full_name(
-   to_of_node(asd->match.fwnode.fwnode)));
+   return __match_fwnode(sd->fwnode, asd_fwnode) ||
+  __match_fwnode(sd->fwnode, asd_parent) ||
+  __match_fwnode(sd_parent, asd_fwnode);
 }
 
 static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
-- 
2.7.4

Re: [PATCH v3 2/2] v4l: async: Match parent devices

[Sakari Ailus]

On Tue, May 23, 2017 at 10:47:58PM +0100, Kieran Bingham wrote:
> On 23/05/17 22:43, Sakari Ailus wrote:
> > On Wed, May 24, 2017 at 12:40:19AM +0300, Sakari Ailus wrote:
> >>>  * When all devices use endpoint matching, this code can be simplified, 
> >>> and the
> >>>  * parent comparisons can be removed.
> > 
> > Oh, and this I'm not so sure about --- we'll need to match lens controllers
> > and flash drivers. There are no endpoints in those devices. Let's see how it
> > goes when we get there...
> > 
> 
> Sure, would you like me to post a v4 of just this patch?

Please.

> 
> The parent checks should always be safe, so this feels like less of a 
> workaround
> now, and if it provides support for other use cases perhaps it could survive
> longer term.

Indeed. If you end up getting the second parent of a device node, the end
result will be that you simply won't have a match.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 1/2] device property: Add fwnode_graph_get_port_parent

[Kieran Bingham]

Hi Sakari,

On 23/05/17 22:37, Sakari Ailus wrote:
> Hi Kieran,
> 
> On Tue, May 23, 2017 at 06:15:42PM +0100, Kieran Bingham wrote:
>>
>>
>> On 23/05/17 13:58, Sakari Ailus wrote:
>>> Hi Kieran,
>>>
>>> On Mon, May 22, 2017 at 06:36:37PM +0100, Kieran Bingham wrote:
 From: Kieran Bingham 

 Provide a helper to obtain the parent device fwnode without first
 parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.

 Signed-off-by: Kieran Bingham 

 ---
 v2:
  - Rebase on top of Sakari's acpi-graph-clean branch and simplify

 v3:
  - Fix up kerneldoc
  - Get the 'port' of the endpoint to find the parent of the port

  drivers/base/property.c  | 15 +++
  include/linux/property.h |  2 ++
  2 files changed, 17 insertions(+)

 diff --git a/drivers/base/property.c b/drivers/base/property.c
 index b311a6fa7d0c..fdbc644fd743 100644
 --- a/drivers/base/property.c
 +++ b/drivers/base/property.c
 @@ -1169,6 +1169,21 @@ fwnode_graph_get_next_endpoint(struct fwnode_handle 
 *fwnode,
  EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint);
  
  /**
 + * fwnode_graph_get_port_parent - Return the device fwnode of a port 
 endpoint
 + * @endpoint: Endpoint firmware node of the port
 + *
 + * Return: the firmware node of the device the @endpoint belongs to.
 + */
 +struct fwnode_handle *
 +fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
 +{
 +  struct fwnode_handle *port = fwnode_get_next_parent(endpoint);
 +
 +  return fwnode_call_ptr_op(port, graph_get_port_parent);
>>>
>>> I missed one thing: the reference to port obtained in
>>> fwnode_get_next_parent() needs to be released.
>>>
>>> I can do the change while applying the patch on top of the set if you're ok
>>> with that.
>>
>> Yes, that would be great thanks.
> 
> Thanks! The patch actually came out in this form:
> 
> 
> 
> I'll post it to list once I've rebased the set again, I hope you're ok with
> that. :-)

That looks great.

Thanks
--
Kieran

Re: [PATCH v3 2/2] v4l: async: Match parent devices

[Kieran Bingham]

On 23/05/17 22:43, Sakari Ailus wrote:
> On Wed, May 24, 2017 at 12:40:19AM +0300, Sakari Ailus wrote:
>>>  * When all devices use endpoint matching, this code can be simplified, and 
>>> the
>>>  * parent comparisons can be removed.
> 
> Oh, and this I'm not so sure about --- we'll need to match lens controllers
> and flash drivers. There are no endpoints in those devices. Let's see how it
> goes when we get there...
> 

Sure, would you like me to post a v4 of just this patch?

The parent checks should always be safe, so this feels like less of a workaround
now, and if it provides support for other use cases perhaps it could survive
longer term.
--
Kieran

Re: [PATCH v3 2/2] v4l: async: Match parent devices

[Sakari Ailus]

On Wed, May 24, 2017 at 12:40:19AM +0300, Sakari Ailus wrote:
> >  * When all devices use endpoint matching, this code can be simplified, and 
> > the
> >  * parent comparisons can be removed.

Oh, and this I'm not so sure about --- we'll need to match lens controllers
and flash drivers. There are no endpoints in those devices. Let's see how it
goes when we get there...

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 2/2] v4l: async: Match parent devices

[Sakari Ailus]

Hi Kieran,

On Tue, May 23, 2017 at 06:40:08PM +0100, Kieran Bingham wrote:
> On 23/05/17 14:02, Sakari Ailus wrote:
> > Hi Kieran,
> > 
> > On Mon, May 22, 2017 at 06:36:38PM +0100, Kieran Bingham wrote:
> >> From: Kieran Bingham 
> >>
> >> Devices supporting multiple endpoints on a single device node must set
> >> their subdevice fwnode to the endpoint to allow distinct comparisons.
> >>
> >> Adapt the match_fwnode call to compare against the provided fwnodes
> >> first, but also to search for a comparison against the parent fwnode.
> >>
> >> This allows notifiers to pass the endpoint for comparison and still
> >> support existing subdevices which store their default parent device
> >> node.
> >>
> >> Signed-off-by: Kieran Bingham 
> >>
> >> ---
> >> v2:
> >>  - Added documentation comments
> >>  - simplified the OF match by adding match_fwnode_of()
> >>
> >> v3:
> >>  - Fix comments
> >>  - Fix sd_parent, and asd_parent usage
> >>
> >>  drivers/media/v4l2-core/v4l2-async.c | 36 -
> >>  1 file changed, 31 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> >> b/drivers/media/v4l2-core/v4l2-async.c
> >> index cbd919d4edd2..12c0707851fd 100644
> >> --- a/drivers/media/v4l2-core/v4l2-async.c
> >> +++ b/drivers/media/v4l2-core/v4l2-async.c
> >> @@ -41,14 +41,40 @@ static bool match_devname(struct v4l2_subdev *sd,
> >>return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
> >>  }
> >>  
> >> +/*
> >> + * Check whether the two device_node pointers refer to the same OF node. 
> >> We
> >> + * can't compare pointers directly as they can differ if overlays have 
> >> been
> >> + * applied.
> >> + */
> >> +static bool match_fwnode_of(struct fwnode_handle *a, struct fwnode_handle 
> >> *b)
> >> +{
> >> +  return !of_node_cmp(of_node_full_name(to_of_node(a)),
> >> +  of_node_full_name(to_of_node(b)));
> >> +}
> >> +
> >> +/*
> >> + * As a measure to support drivers which have not been converted to use
> >> + * endpoint matching, we also find the parent devices for cross-matching.
> >> + *
> >> + * When all devices use endpoint matching, this code can be simplified, 
> >> and the
> >> + * parent comparisons can be removed.
> >> + */
> >>  static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev 
> >> *asd)
> >>  {
> >> -  if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
> >> -  return sd->fwnode == asd->match.fwnode.fwnode;
> >> +  struct fwnode_handle *asd_fwnode = asd->match.fwnode.fwnode;
> >> +  struct fwnode_handle *sd_parent, *asd_parent;
> >> +
> >> +  sd_parent = fwnode_graph_get_port_parent(sd->fwnode);
> >> +  asd_parent = fwnode_graph_get_port_parent(asd_fwnode);
> >> +
> >> +  if (!is_of_node(sd->fwnode) || !is_of_node(asd_fwnode))
> >> +  return sd->fwnode == asd_fwnode ||
> >> + sd_parent == asd_fwnode ||
> >> + sd->fwnode == asd_parent;
> >>  
> >> -  return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
> >> -  of_node_full_name(
> >> -  to_of_node(asd->match.fwnode.fwnode)));
> >> +  return match_fwnode_of(sd->fwnode, asd_fwnode) ||
> >> + match_fwnode_of(sd_parent, asd_fwnode) ||
> >> + match_fwnode_of(sd->fwnode, asd_parent);
> >>  }
> >>  
> >>  static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev 
> >> *asd)
> > 
> > Would this become easier to read if you handled all matching in what is
> > called match_fwnode_of() above, also for non-OF fwnodes? Essentially you'd
> > have what used to be match_fwnode() there, and new match_fwnode() would call
> > that function with all the three combinations.
> > 
> 
> 
> > I'd call the other function __match_fwnode() for instance.
> > 
> 
> 
> Yes - Took me a moment to understand what you meant here - but yes it's 
> leaner +
> cleaner:

Looks quite nice! Thanks! :)

> 
> 
> /*
>  * As a measure to support drivers which have not been converted to use
>  * endpoint matching, we also find the parent devices for cross-matching.
>  *
>  * When all devices use endpoint matching, this code can be simplified, and 
> the
>  * parent comparisons can be removed.
>  */
> 
> static bool __match_fwnode(struct fwnode_handle *a, struct fwnode_handle *b)
> {
>   if (is_of_node(a) || is_of_node(b))

I think you need && (not ||) although in practice I don't think it'd have
made any difference.

>   return !of_node_cmp(of_node_full_name(to_of_node(a)),
>   of_node_full_name(to_of_node(b)));
>   else
>   return a == b;
> }
> 
> static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev 
> *asd)
> {
>   struct fwnode_handle *asd_fwnode = asd->match.fwnode.fwnode;
>   struct fwnode_handle *sd_parent, *asd_parent;
> 
>   sd_parent = 

Re: [PATCH v3 1/2] device property: Add fwnode_graph_get_port_parent

[Sakari Ailus]

Hi Kieran,

On Tue, May 23, 2017 at 06:15:42PM +0100, Kieran Bingham wrote:
> 
> 
> On 23/05/17 13:58, Sakari Ailus wrote:
> > Hi Kieran,
> > 
> > On Mon, May 22, 2017 at 06:36:37PM +0100, Kieran Bingham wrote:
> >> From: Kieran Bingham 
> >>
> >> Provide a helper to obtain the parent device fwnode without first
> >> parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.
> >>
> >> Signed-off-by: Kieran Bingham 
> >>
> >> ---
> >> v2:
> >>  - Rebase on top of Sakari's acpi-graph-clean branch and simplify
> >>
> >> v3:
> >>  - Fix up kerneldoc
> >>  - Get the 'port' of the endpoint to find the parent of the port
> >>
> >>  drivers/base/property.c  | 15 +++
> >>  include/linux/property.h |  2 ++
> >>  2 files changed, 17 insertions(+)
> >>
> >> diff --git a/drivers/base/property.c b/drivers/base/property.c
> >> index b311a6fa7d0c..fdbc644fd743 100644
> >> --- a/drivers/base/property.c
> >> +++ b/drivers/base/property.c
> >> @@ -1169,6 +1169,21 @@ fwnode_graph_get_next_endpoint(struct fwnode_handle 
> >> *fwnode,
> >>  EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint);
> >>  
> >>  /**
> >> + * fwnode_graph_get_port_parent - Return the device fwnode of a port 
> >> endpoint
> >> + * @endpoint: Endpoint firmware node of the port
> >> + *
> >> + * Return: the firmware node of the device the @endpoint belongs to.
> >> + */
> >> +struct fwnode_handle *
> >> +fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
> >> +{
> >> +  struct fwnode_handle *port = fwnode_get_next_parent(endpoint);
> >> +
> >> +  return fwnode_call_ptr_op(port, graph_get_port_parent);
> > 
> > I missed one thing: the reference to port obtained in
> > fwnode_get_next_parent() needs to be released.
> > 
> > I can do the change while applying the patch on top of the set if you're ok
> > with that.
> 
> Yes, that would be great thanks.

Thanks! The patch actually came out in this form:



I'll post it to list once I've rebased the set again, I hope you're ok with
that. :-)

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH] arm: dts: r7s72100: Add support for GR-Peach

[Geert Uytterhoeven]

On Tue, May 23, 2017 at 9:20 PM, Jacopo Mondi  wrote:
> Add device tree source for Renesas GR-Peach board.
> GR-Peach is an RZ/A1H based board with 10MB of on-chip SRAM and 8MB
> QSPI flash storage.
> Add support for the board, and create a 2MB partition to use as rootfs.
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 

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

[PATCH] arm: dts: r7s72100: Add support for GR-Peach

[Jacopo Mondi]

Add device tree source for Renesas GR-Peach board.
GR-Peach is an RZ/A1H based board with 10MB of on-chip SRAM and 8MB
QSPI flash storage.
Add support for the board, and create a 2MB partition to use as rootfs.

Signed-off-by: Jacopo Mondi 
---

v1->v2
- s/grpeach/gr-peach/g
- Use correct part number in bindings documentation (X28A-M01-E/F)
- Geert's comment on v1 addressed

 Documentation/devicetree/bindings/arm/shmobile.txt |  2 +
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/r7s72100-gr-peach.dts| 66 ++
 3 files changed, 69 insertions(+)
 create mode 100644 arch/arm/boot/dts/r7s72100-gr-peach.dts

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index c950263..b7ab3bd 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -51,6 +51,8 @@ Boards:
 compatible = "renesas,bockw", "renesas,r8a7778"
   - Genmai (RTK772100BC0BR)
 compatible = "renesas,genmai", "renesas,r7s72100"
+  - GR-Peach (X28A-M01-E/F)
+compatible = "renesas,gr-peach", "renesas,r7s72100"
   - Gose (RTP0RC7793SEB00010S)
 compatible = "renesas,gose", "renesas,r8a7793"
   - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKB00010S)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0118084..10cd690 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -716,6 +716,7 @@ dtb-$(CONFIG_ARCH_S5PV210) += \
 dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
emev2-kzm9d.dtb \
r7s72100-genmai.dtb \
+   r7s72100-gr-peach.dtb \
r7s72100-rskrza1.dtb \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts 
b/arch/arm/boot/dts/r7s72100-gr-peach.dts
new file mode 100644
index 000..a1b2aef9
--- /dev/null
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -0,0 +1,66 @@
+/*
+ * Device Tree Source for the GR-Peach board
+ *
+ * Copyright (C) 2017 Jacopo Mondi 
+ * Copyright (C) 2016 Renesas Electronics
+ *
+ * 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 "r7s72100.dtsi"
+
+/ {
+   model = "GR-Peach";
+   compatible = "renesas,gr-peach", "renesas,r7s72100";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   bootargs = "ignore_loglevel rw root=/dev/mtdblock0";
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@2000 {
+   device_type = "memory";
+   reg = <0x2000 0x00a0>;
+
+   };
+
+   lbsc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+
+   flash@1800 {
+   compatible = "mtd-rom";
+   probe-type = "map_rom";
+   reg = <0x1800 0x0080>;
+   bank-width = <4>;
+   device-width = <1>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   rootfs@60 {
+   label = "rootfs";
+   reg = <0x0060 0x0020>;
+   };
+   };
+};
+
+_clk {
+   clock-frequency = <1000>;
+};
+
+_x1_clk {
+   clock-frequency = <4800>;
+};
+
+ {
+   status = "okay";
+};
--
2.7.4

Re: [PATCH] arm: dts: r7s72100: Add support for GR-Peach

[jmondi]

Hi Geert,

On Tue, May 23, 2017 at 12:08:30PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Tue, May 23, 2017 at 11:47 AM, Jacopo Mondi
>  wrote:
> > Add device tree source for Renesas GR-Peach board.
> > GR-Peach is an RZ/A1H based board with 10MB of on-chip SRAM and 8MB
> > QSPI flash storage.
> > Add support for the board, and create a 2MB partition to use as rootfs.
> >
> > Signed-off-by: Jacopo Mondi 
>
> Thanks for your patch!
>
> > --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> > @@ -51,6 +51,8 @@ Boards:
> >  compatible = "renesas,bockw", "renesas,r8a7778"
> >- Genmai (RTK772100BC0BR)
> >  compatible = "renesas,genmai", "renesas,r7s72100"
> > +  - GR-Peach (RTK772100BC0BR)
>
> That part number is Genmai?

Oh, I thought that was the SoC part number, and being both based on
RZ/A1H, I used the same.

Where can I find the correct part number?

>
> > +compatible = "renesas,grpeach", "renesas,r7s72100"
>
> "renesas,gr-peach"?

Let's use gr-peach in place of grpeach everywhere then.

>
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -716,6 +716,7 @@ dtb-$(CONFIG_ARCH_S5PV210) += \
> >  dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
> > emev2-kzm9d.dtb \
> > r7s72100-genmai.dtb \
> > +   r7s72100-grpeach.dtb \
>
> r7s72100-gr-peach.dtb?
>
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/r7s72100-grpeach.dts
>
> r7s72100-gr-peach.dts
>
> > @@ -0,0 +1,65 @@
> > +/*
> > + * Device Tree Source for the GRPEACH board
>
> GR-PEACH
>
> > +/ {
> > +   model = "GRPEACH";
>
> GR-PEACH
>
> > +   compatible = "renesas,grpeach", "renesas,r7s72100";
>
> renesas,gr-peach
>
> > +
> > +   aliases {
> > +   serial2 = 
>
> The first serial port is supposed to be called serial0, unless labeled
> otherwise.

I assumed it had to match the SCIF number. Will change.

>
> > +   };
> > +
> > +   chosen {
> > +   bootargs = "console=ttySC2,115200 ignore_loglevel rw 
> > root=/dev/mtdblock0";
>
> bootargs = "ignore_loglevel rw root=/dev/mtdblock0";
> stdout-path = "serial0:115200n8";
>
> > +   memory {
>
> memory@2000
>
> (please run "make dtbs W=1")
>
> > +   device_type = "memory";
> > +   reg = <0x2000 0x00A0>;  /* 10Mb @ 0x2000 */
>
> reg = <0x2000 0x00a0>;
>
> No need for the comment, esp. since it says 10 megabits instead of
> 10 mebibyte ;-)

Was I the only one that had to go on Wikipedia to find out what a
mebibyte is :p ?

I'll drop comments here and in the rest of the patch.

>
> > +   qspi@1800 {
>
> flash@1800?
>
> > +   compatible = "mtd-rom";
> > +   probe-type = "map_rom";
> > +   reg = <0x1800 0x0080>;   /* 8 MB*/
>
> No need for the comment (megabyte vs. mebibyte)
>
> > +   bank-width = <4>;
> > +   device-width = <1>;
> > +
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   rootfs@1860 {
>
> rootfs@60?
>
> > +   label = "rootfs";
> > +   reg = <0x0060 0x0020>; /* 2MB @ 0x1860 
> > */
>
> Do we need the comment?
>
> > +_clk {
> > +   clock-frequency = <1333>;
>
> My schematics have one more digit of precision: <1000>

Thanks, I'll change this.

Do we need to change that on Genmai as well while at there?
Some parts of its documentation report a frequency of 13.33Mhz, but X1
is listed in the BOM as

X1 XIN oscillator (socket mounted) SG-8002DC-13.MHz (Epson)

Thanks
   j
>
> 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 v5 01/10] pinctrl: generic: Add bi-directional and output-enable

[jmondi]

Hi Linus,

On Tue, May 23, 2017 at 06:08:31PM +0800, Dong Aisheng wrote:
> On Tue, May 9, 2017 at 5:19 AM, Linus Walleij  
> wrote:
> > On Mon, May 8, 2017 at 7:25 PM, jmondi  wrote:
> >
> >> From my perspective these flags are configurations internal to the pin
> >> controller hardware used to enable/disable input buffers when a pin needs 
> >> to
> >> perform in both direction.
> >> The level of detail I can provide on this is the logical diagram we have 
> >> pointed
> >> you to already.
> >>
> >> As I assume you are trying to get this answer from us in order to
> >> avoid duplicating things in pin controller sub-system, and I
> >> understand this, but my question here was "can we have those flags as part
> >> of the pinmux property argument list, as that property description
> >> seems to allow us to do that, instead of making them generic pin
> >> configuration properties and upset other developers?"
> >
> > Pinmux with all it's magic flags baked into one is not any better
> > or any more readable. The solution is already very pretty except
> > for these two flags which I am sure we can agree on a way forward
> > for.
> >
> > What we choose between is not this or another less transparent
> > pin configuration mechanism, the mechanism (whether magic bits
> > to pinmux or reasonable properties) does not matter.
> >
> > There is a strong preference to use the generic bindings.
> >
> > So the discussion is whether to use:
> >
> > bi-directional;
> > output-enable;
> >
> > Or some already defined config flags.
> >
> > If these are too idiomatic to be used by others, they should anyways
> > look similar, like:
> >
> > renesas,bi-directional;
> > renesas,output-enable;
> >
> > Like the Qualcomm weirdness found in 
> > drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> >
> > qcom,pull-up-strength = <..>;
> >
> > Check how they use
> > #define PMIC_GPIO_CONF_PULL_UP (PIN_CONFIG_END + 1)
> >
> > Etc.
> >
> >> Anyway, I still fail to see why those configuration flags, only
> >> affecting the way the pin controller hardware enables/disables
> >> its internal buffers and its internal operations have to be
> >> described in term of their externally visible electrically characteristics.
> >
> > To me internal vs external is not what matters. What matters is
> > if this is likely to pop up in more platforms, and then the property
> > should be generic.
> >
> > The generic pin config definitions are likely to be picked up by other
> > standards and even be inspiration to hardware engineers so that
> > is why it matters so much.
> >
> >> To me, what already exists are pin configuration properties generic to
> >> the whole pin controller subsystem, and I understand you don't want to
> >> see duplication there.
> >>
> >> At the same time, to me, those flags are settings the pin controller
> >> wants to have specified by software to overcome its hw design flaws,
> >> and are intended to configure its internal buffers in a way it cannot
> >> do by itself for some very specific operation modes (they are listed
> >> in the hw reference manual, it's not something you can chose to
> >> configure or not, if you want a pin working in i2c mode, you HAVE to
> >> pass those flags to pin controller).
> >
> > Sounds like a case for
> >
> > renesas,bi-directional;
> > renesas,output-enable;
> >
> > following the Qualcomm pattern in that case.
> >
> > But let's see if something else comes out of this discussion.
> >
>
> I did not follow too much.
> But it seems IMX7ULP/Vybrid to be also a fan of generic
> output-enable/input-enable
> property.
>
> See:
> Figure 5-2. GPIO PAD in Page 241
> http://www.nxp.com/assets/documents/data/en/reference-manuals/VFXXXRM.pdf
>
> It has separate register bits to control input buffer enable and
> output buffer enable
> and we need set it property for GPIO function.

As it seems we have another user for 'output-enable' here, what if we just
add that one to the generic bindings properties list, and we keep
'bi-directional' (which seems to be the most debated property we have
added) out of generic properties?

We can handle 'bi-directional' pins with static tables in our pin
controller driver and not have it anywhere in DT.

I see commit 42d5a11200d0[1] has not been reverted yet as Andy asked
in some previous email. I can send another version of that patch with
only 'output-enable' if you wish.

Once we reach consesus, I can then send v6 of our pin controller driver
based on that.

Thanks
   j

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c58f1a7a4b6d1d723bf25fef9d842d5a11200d0
>
> Regards
> Dong Aisheng

Re: [PATCH v3 2/2] v4l: async: Match parent devices

[Kieran Bingham]

On 23/05/17 14:02, Sakari Ailus wrote:
> Hi Kieran,
> 
> On Mon, May 22, 2017 at 06:36:38PM +0100, Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> Devices supporting multiple endpoints on a single device node must set
>> their subdevice fwnode to the endpoint to allow distinct comparisons.
>>
>> Adapt the match_fwnode call to compare against the provided fwnodes
>> first, but also to search for a comparison against the parent fwnode.
>>
>> This allows notifiers to pass the endpoint for comparison and still
>> support existing subdevices which store their default parent device
>> node.
>>
>> Signed-off-by: Kieran Bingham 
>>
>> ---
>> v2:
>>  - Added documentation comments
>>  - simplified the OF match by adding match_fwnode_of()
>>
>> v3:
>>  - Fix comments
>>  - Fix sd_parent, and asd_parent usage
>>
>>  drivers/media/v4l2-core/v4l2-async.c | 36 -
>>  1 file changed, 31 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
>> b/drivers/media/v4l2-core/v4l2-async.c
>> index cbd919d4edd2..12c0707851fd 100644
>> --- a/drivers/media/v4l2-core/v4l2-async.c
>> +++ b/drivers/media/v4l2-core/v4l2-async.c
>> @@ -41,14 +41,40 @@ static bool match_devname(struct v4l2_subdev *sd,
>>  return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
>>  }
>>  
>> +/*
>> + * Check whether the two device_node pointers refer to the same OF node. We
>> + * can't compare pointers directly as they can differ if overlays have been
>> + * applied.
>> + */
>> +static bool match_fwnode_of(struct fwnode_handle *a, struct fwnode_handle 
>> *b)
>> +{
>> +return !of_node_cmp(of_node_full_name(to_of_node(a)),
>> +of_node_full_name(to_of_node(b)));
>> +}
>> +
>> +/*
>> + * As a measure to support drivers which have not been converted to use
>> + * endpoint matching, we also find the parent devices for cross-matching.
>> + *
>> + * When all devices use endpoint matching, this code can be simplified, and 
>> the
>> + * parent comparisons can be removed.
>> + */
>>  static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev 
>> *asd)
>>  {
>> -if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
>> -return sd->fwnode == asd->match.fwnode.fwnode;
>> +struct fwnode_handle *asd_fwnode = asd->match.fwnode.fwnode;
>> +struct fwnode_handle *sd_parent, *asd_parent;
>> +
>> +sd_parent = fwnode_graph_get_port_parent(sd->fwnode);
>> +asd_parent = fwnode_graph_get_port_parent(asd_fwnode);
>> +
>> +if (!is_of_node(sd->fwnode) || !is_of_node(asd_fwnode))
>> +return sd->fwnode == asd_fwnode ||
>> +   sd_parent == asd_fwnode ||
>> +   sd->fwnode == asd_parent;
>>  
>> -return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
>> -of_node_full_name(
>> -to_of_node(asd->match.fwnode.fwnode)));
>> +return match_fwnode_of(sd->fwnode, asd_fwnode) ||
>> +   match_fwnode_of(sd_parent, asd_fwnode) ||
>> +   match_fwnode_of(sd->fwnode, asd_parent);
>>  }
>>  
>>  static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev 
>> *asd)
> 
> Would this become easier to read if you handled all matching in what is
> called match_fwnode_of() above, also for non-OF fwnodes? Essentially you'd
> have what used to be match_fwnode() there, and new match_fwnode() would call
> that function with all the three combinations.
> 


> I'd call the other function __match_fwnode() for instance.
> 


Yes - Took me a moment to understand what you meant here - but yes it's leaner +
cleaner:


/*
 * As a measure to support drivers which have not been converted to use
 * endpoint matching, we also find the parent devices for cross-matching.
 *
 * When all devices use endpoint matching, this code can be simplified, and the
 * parent comparisons can be removed.
 */

static bool __match_fwnode(struct fwnode_handle *a, struct fwnode_handle *b)
{
if (is_of_node(a) || is_of_node(b))
return !of_node_cmp(of_node_full_name(to_of_node(a)),
of_node_full_name(to_of_node(b)));
else
return a == b;
}

static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
struct fwnode_handle *asd_fwnode = asd->match.fwnode.fwnode;
struct fwnode_handle *sd_parent, *asd_parent;

sd_parent = fwnode_graph_get_port_parent(sd->fwnode);
asd_parent = fwnode_graph_get_port_parent(asd_fwnode);

return __match_fwnode(sd->fwnode, asd_fwnode) ||
   __match_fwnode(sd_parent, asd_fwnode) ||
   __match_fwnode(sd->fwnode, asd_parent);
}

Re: [PATCH v3 2/2] media: i2c: adv748x: add adv748x driver

[Kieran Bingham]

On 18/05/17 22:48, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.

Thanks for the review,

I've worked through these, and changes that were straightforward have already
been done locally.

Those that were more complicated or will take more thought are now on my todo
list and being worked through...

There are a sprinkling of questions below so I'll send this now :)


> 
> On Wednesday 17 May 2017 15:13:18 Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> Provide basic support for the ADV7481 and ADV7482.
>>
>> The driver is modelled with 2 subdevices to allow simultaneous streaming
>> from the AFE (Analog front end) and HDMI inputs.
> 
> Isn't that now four subdevices ?

Of course :)

> 
>> Presently the HDMI is hardcoded to link to the TXA CSI bus, whilst the
>> AFE is linked to the TXB CSI bus.
>>
>> The driver is based on a prototype by Koji Matsuoka in the Renesas BSP,
>> and an earlier rework by Niklas Söderlund.
>>
>> Signed-off-by: Kieran Bingham 
> 
> [snip]
> 
>> diff --git a/Documentation/devicetree/bindings/media/i2c/adv748x.txt
>> b/Documentation/devicetree/bindings/media/i2c/adv748x.txt new file mode
>> 100644
>> index ..98d4600b7d26
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/adv748x.txt
>> @@ -0,0 +1,72 @@
>> +* Analog Devices ADV748X video decoder with HDMI receiver
>> +
>> +The ADV7481, and ADV7482 are multi format video decoders with an integrated
>> +HDMI receiver. It can output CSI-2 on two independent outputs TXA and TXB
> 
> s/It/They/ ?
> 

Ack

>> from +three input sources HDMI, analog and TTL.
>> +
>> +Required Properties:
>> +
>> +  - compatible: Must contain one of the following
>> +- "adi,adv7481" for the ADV7481
>> +- "adi,adv7482" for the ADV7482
>> +
>> +  - reg: I2C slave address
>> +
>> +  - interrupt-names: Should specify the interrupts as "intrq1" and/or
>> "intrq2"
>> + "intrq3" is only available on the adv7480 and adv7481
> 
> The bindings don't cover the ADV7480 yet, I wouldn't mention it here.
>

Ok, removed.

> Which interrupt(s) are mandatory and which are optional ? If they're all 
> mandatory (which I doubt) I would phrase it as 
> 
>   - interrupt-names: Should specify the "intrq1", "intrq2" and "intrq3" 
> interrupts. The "intrq3" interrupt is only available on the adv7481.
> 
> If they're all optional, I would move it to the Optional Properties section 
> and phrase it as
> 
>   - interrupt-names: Should specify the "intrq1", "intrq2" and/or "intrq3" 
> interrupts. All interrupts are optional. The "intrq3" interrupt is only 
> available on the adv7481.
> 

I believe they can be optional.
Added an optional section.


> If some of them only are mandatory,
> 
>   - interrupt-names: Should specify the "intrq1", "intrq2" and/or "intrq3" 
> interrupts. The ... interrupts are mandatory, while the ... interrupts are 
> optional. The "intrq3" interrupt is only available on the adv7481.
> 
>> +  - interrupts: Specify the interrupt lines for the ADV748x
>> +
>> +The device node must contain one 'port' child node per device input and
>> output +port, in accordance with the video interface bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt. The port
>> nodes +are numbered as follows.
>> +
>> +  Name  TypePort
>> +
>> +  HDMI  sink0
>> +  AIN1  sink1
>> +  AIN2  sink2
>> +  AIN3  sink3
>> +  AIN4  sink4
>> +  AIN5  sink5
>> +  AIN6  sink6
>> +  AIN7  sink7
>> +  AIN8  sink8
>> +  TTL   sink9
>> +  TXA   source  10
>> +  TXB   source  11
>> +
>> +The digital output port node must contain at least one source endpoint.
> 
> s/node/nodes/ ?
> s/source //
> 

Fixed

>> +Example:
>> +
>> +video_receiver@70 {
>> +compatible = "adi,adv7482";
>> +reg = <0x70>;
>> +
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +interrupt-parent = <>;
>> +interrupt-names = "intrq1", "intrq2";
>> +interrupts = <30 IRQ_TYPE_LEVEL_LOW>,
>> + <31 IRQ_TYPE_LEVEL_LOW>;
>> +
>> +port@10 {
>> +reg = <10>;
>> +adv7482_txa: endpoint@1 {
> 
> There's no need to number endpoints when there's a single one. Otherwise 
> you'd 
> need a reg property in the endpoint.
> 

Ok - that's Good IMO; Can multiple (more than 2) devices be connected to a
single CSI2 bus?

Even if they can -  I don't think we would support that yet so either way, 

[PATCH v5 09/20] ARM: dts: r7s72100: Add generic compatible string for I2C EEPROM

[Javier Martinez Canillas]

The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Geert Uytterhoeven 

---

Changes in v5:
- Only replace atmel variant but keep other EEPROM vendors (Geert Uytterhoeven).

Changes in v4:
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).

Changes in v3:
- Add Geert Uytterhoeven reviewed-by tag.

Changes in v2: None

 arch/arm/boot/dts/r7s72100-genmai.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts 
b/arch/arm/boot/dts/r7s72100-genmai.dts
index 52a7b586bac7..b0db621ff176 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -57,7 +57,7 @@
clock-frequency = <40>;
 
eeprom@50 {
-   compatible = "renesas,24c128";
+   compatible = "renesas,24c128", "atmel,24c128";
reg = <0x50>;
pagesize = <64>;
};
-- 
2.9.3

[PATCH v5 10/20] ARM: dts: koelsch: Add generic compatible string for I2C EEPROM

[Javier Martinez Canillas]

The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.

But when matching using an OF table, both the vendor and device has to be
taken into account so the driver defines only a set of compatible strings
using the "atmel" vendor as a generic fallback for compatible I2C devices.

So add this generic fallback to the device node compatible string to make
the device to match the driver using the OF device ID table.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Geert Uytterhoeven 

---

Changes in v5:
- Only replace atmel variant but keep other EEPROM vendors (Geert Uytterhoeven).

Changes in v4:
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).

Changes in v3:
- Add Geert Uytterhoeven reviewed-by tag.

Changes in v2: None

 arch/arm/boot/dts/r8a7791-koelsch.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 001e6116c47c..dc8ed02de707 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -702,7 +702,7 @@
};
 
eeprom@50 {
-   compatible = "renesas,24c02";
+   compatible = "renesas,24c02", "atmel,24c02";
reg = <0x50>;
pagesize = <16>;
};
-- 
2.9.3

[PATCH] mmc: tmio: make sure SDIO gets reinitialized after resume

[Wolfram Sang]

To achieve that, we set the registers in the generic HW reset routine
which gets called at both, init and resume. We also make sure to move
SDIO initialization before reset gets called in probe().

Signed-off-by: Wolfram Sang 
Tested-by: Masaharu Hayakawa 
---

Changes since RFT:
* added tag from Hayakawa-san (thanks!)
* rebased to mmc/next (on top of the DMA refactor series)

 drivers/mmc/host/tmio_mmc_core.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index e1ad461c4b8c8f..ed40681253497a 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -265,6 +265,12 @@ static void tmio_mmc_reset(struct tmio_mmc_host *host)
if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0001);
msleep(10);
+
+   if (host->pdata->flags & TMIO_MMC_SDIO_IRQ) {
+   sd_ctrl_write16(host, CTL_SDIO_IRQ_MASK, host->sdio_irq_mask);
+   sd_ctrl_write16(host, CTL_TRANSACTION_CTL, 0x0001);
+   }
+
 }
 
 static void tmio_mmc_reset_work(struct work_struct *work)
@@ -1280,6 +1286,10 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
if (_host->native_hotplug)
pm_runtime_get_noresume(>dev);
 
+   _host->sdio_irq_enabled = false;
+   if (pdata->flags & TMIO_MMC_SDIO_IRQ)
+   _host->sdio_irq_mask = TMIO_SDIO_MASK_ALL;
+
tmio_mmc_clk_stop(_host);
tmio_mmc_reset(_host);
 
@@ -1296,13 +1306,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
 
_host->sdcard_irq_mask &= ~irq_mask;
 
-   _host->sdio_irq_enabled = false;
-   if (pdata->flags & TMIO_MMC_SDIO_IRQ) {
-   _host->sdio_irq_mask = TMIO_SDIO_MASK_ALL;
-   sd_ctrl_write16(_host, CTL_SDIO_IRQ_MASK, _host->sdio_irq_mask);
-   sd_ctrl_write16(_host, CTL_TRANSACTION_CTL, 0x0001);
-   }
-
spin_lock_init(&_host->lock);
mutex_init(&_host->ios_lock);
 
-- 
2.11.0

Re: [PATCH v3 2/2] v4l: async: Match parent devices

[Sakari Ailus]

Hi Kieran,

On Mon, May 22, 2017 at 06:36:38PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Devices supporting multiple endpoints on a single device node must set
> their subdevice fwnode to the endpoint to allow distinct comparisons.
> 
> Adapt the match_fwnode call to compare against the provided fwnodes
> first, but also to search for a comparison against the parent fwnode.
> 
> This allows notifiers to pass the endpoint for comparison and still
> support existing subdevices which store their default parent device
> node.
> 
> Signed-off-by: Kieran Bingham 
> 
> ---
> v2:
>  - Added documentation comments
>  - simplified the OF match by adding match_fwnode_of()
> 
> v3:
>  - Fix comments
>  - Fix sd_parent, and asd_parent usage
> 
>  drivers/media/v4l2-core/v4l2-async.c | 36 -
>  1 file changed, 31 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index cbd919d4edd2..12c0707851fd 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -41,14 +41,40 @@ static bool match_devname(struct v4l2_subdev *sd,
>   return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
>  }
>  
> +/*
> + * Check whether the two device_node pointers refer to the same OF node. We
> + * can't compare pointers directly as they can differ if overlays have been
> + * applied.
> + */
> +static bool match_fwnode_of(struct fwnode_handle *a, struct fwnode_handle *b)
> +{
> + return !of_node_cmp(of_node_full_name(to_of_node(a)),
> + of_node_full_name(to_of_node(b)));
> +}
> +
> +/*
> + * As a measure to support drivers which have not been converted to use
> + * endpoint matching, we also find the parent devices for cross-matching.
> + *
> + * When all devices use endpoint matching, this code can be simplified, and 
> the
> + * parent comparisons can be removed.
> + */
>  static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev 
> *asd)
>  {
> - if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
> - return sd->fwnode == asd->match.fwnode.fwnode;
> + struct fwnode_handle *asd_fwnode = asd->match.fwnode.fwnode;
> + struct fwnode_handle *sd_parent, *asd_parent;
> +
> + sd_parent = fwnode_graph_get_port_parent(sd->fwnode);
> + asd_parent = fwnode_graph_get_port_parent(asd_fwnode);
> +
> + if (!is_of_node(sd->fwnode) || !is_of_node(asd_fwnode))
> + return sd->fwnode == asd_fwnode ||
> +sd_parent == asd_fwnode ||
> +sd->fwnode == asd_parent;
>  
> - return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
> - of_node_full_name(
> - to_of_node(asd->match.fwnode.fwnode)));
> + return match_fwnode_of(sd->fwnode, asd_fwnode) ||
> +match_fwnode_of(sd_parent, asd_fwnode) ||
> +match_fwnode_of(sd->fwnode, asd_parent);
>  }
>  
>  static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev 
> *asd)

Would this become easier to read if you handled all matching in what is
called match_fwnode_of() above, also for non-OF fwnodes? Essentially you'd
have what used to be match_fwnode() there, and new match_fwnode() would call
that function with all the three combinations.

I'd call the other function __match_fwnode() for instance.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 1/2] device property: Add fwnode_graph_get_port_parent

[Sakari Ailus]

Hi Kieran,

On Mon, May 22, 2017 at 06:36:37PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Provide a helper to obtain the parent device fwnode without first
> parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.
> 
> Signed-off-by: Kieran Bingham 
> 
> ---
> v2:
>  - Rebase on top of Sakari's acpi-graph-clean branch and simplify
> 
> v3:
>  - Fix up kerneldoc
>  - Get the 'port' of the endpoint to find the parent of the port
> 
>  drivers/base/property.c  | 15 +++
>  include/linux/property.h |  2 ++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index b311a6fa7d0c..fdbc644fd743 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -1169,6 +1169,21 @@ fwnode_graph_get_next_endpoint(struct fwnode_handle 
> *fwnode,
>  EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint);
>  
>  /**
> + * fwnode_graph_get_port_parent - Return the device fwnode of a port endpoint
> + * @endpoint: Endpoint firmware node of the port
> + *
> + * Return: the firmware node of the device the @endpoint belongs to.
> + */
> +struct fwnode_handle *
> +fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
> +{
> + struct fwnode_handle *port = fwnode_get_next_parent(endpoint);
> +
> + return fwnode_call_ptr_op(port, graph_get_port_parent);

I missed one thing: the reference to port obtained in
fwnode_get_next_parent() needs to be released.

I can do the change while applying the patch on top of the set if you're ok
with that.

> +}
> +EXPORT_SYMBOL_GPL(fwnode_graph_get_port_parent);
> +
> +/**
>   * fwnode_graph_get_remote_port_parent - Return fwnode of a remote device
>   * @fwnode: Endpoint firmware node pointing to the remote endpoint
>   *
> diff --git a/include/linux/property.h b/include/linux/property.h
> index b9f4838d9882..af95d5d84192 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -275,6 +275,8 @@ void *device_get_mac_address(struct device *dev, char 
> *addr, int alen);
>  
>  struct fwnode_handle *fwnode_graph_get_next_endpoint(
>   struct fwnode_handle *fwnode, struct fwnode_handle *prev);
> +struct fwnode_handle *fwnode_graph_get_port_parent(
> + struct fwnode_handle *fwnode);
>  struct fwnode_handle *fwnode_graph_get_remote_port_parent(
>   struct fwnode_handle *fwnode);
>  struct fwnode_handle *fwnode_graph_get_remote_port(

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [RFT PATCH] mmc: tmio: make sure SDIO gets reinitialized after resume

[Wolfram Sang]

Shimoda-san,

> > This patch addresses a report I got from Shimoda-san. I can't really test it
> > because the SDIO cards I have all require MMC_PM_KEEP_POWER to suspend and
> > that we don't support. So, I send this out to ask for testing. At least it
> > didn't cause regressions for the setup I used. To make testing easier, this
> > is *not* put on top of Simon's SDHI DMA rework patches, so it should apply
> > on current upstream and development branches.
> 
> Thank you for the patch!
> Hayakawa-san tested this patch on both H3/Salvator-X and E2/ALT.
> 
> So,
> Tested-by: Masaharu Hayakawa 

Very good, thanks, also to Hayakawa-san! I'll rebase this patch and
resubmit with the tag added!

Regards,

   Wolfram



signature.asc
Description: PGP signature

RE: [RFT PATCH] mmc: tmio: make sure SDIO gets reinitialized after resume

[Yoshihiro Shimoda]

Hi Wolfram-san,

> From: Wolfram Sang
> Sent: Friday, May 19, 2017 9:31 PM
> 
> To achieve that, we set the registers in the generic HW reset routine
> which gets called at both, init and resume. We also make sure to move
> SDIO initialization before reset gets called in probe().
> 
> Signed-off-by: Wolfram Sang 
> ---
> 
> This patch addresses a report I got from Shimoda-san. I can't really test it
> because the SDIO cards I have all require MMC_PM_KEEP_POWER to suspend and
> that we don't support. So, I send this out to ask for testing. At least it
> didn't cause regressions for the setup I used. To make testing easier, this
> is *not* put on top of Simon's SDHI DMA rework patches, so it should apply
> on current upstream and development branches.

Thank you for the patch!
Hayakawa-san tested this patch on both H3/Salvator-X and E2/ALT.

So,
Tested-by: Masaharu Hayakawa 

Best regards,
Yoshihiro Shimoda

>  drivers/mmc/host/tmio_mmc_pio.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
> index a2d92f10501bdd..5e87fcaa99d430 100644
> --- a/drivers/mmc/host/tmio_mmc_pio.c
> +++ b/drivers/mmc/host/tmio_mmc_pio.c
> @@ -229,6 +229,12 @@ static void tmio_mmc_reset(struct tmio_mmc_host *host)
>   if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
>   sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0001);
>   msleep(10);
> +
> + if (host->pdata->flags & TMIO_MMC_SDIO_IRQ) {
> + sd_ctrl_write16(host, CTL_SDIO_IRQ_MASK, host->sdio_irq_mask);
> + sd_ctrl_write16(host, CTL_TRANSACTION_CTL, 0x0001);
> + }
> +
>  }
> 
>  static void tmio_mmc_reset_work(struct work_struct *work)
> @@ -1221,6 +1227,10 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
>   if (_host->native_hotplug)
>   pm_runtime_get_noresume(>dev);
> 
> + _host->sdio_irq_enabled = false;
> + if (pdata->flags & TMIO_MMC_SDIO_IRQ)
> + _host->sdio_irq_mask = TMIO_SDIO_MASK_ALL;
> +
>   tmio_mmc_clk_stop(_host);
>   tmio_mmc_reset(_host);
> 
> @@ -1237,13 +1247,6 @@ int tmio_mmc_host_probe(struct tmio_mmc_host *_host,
> 
>   _host->sdcard_irq_mask &= ~irq_mask;
> 
> - _host->sdio_irq_enabled = false;
> - if (pdata->flags & TMIO_MMC_SDIO_IRQ) {
> - _host->sdio_irq_mask = TMIO_SDIO_MASK_ALL;
> - sd_ctrl_write16(_host, CTL_SDIO_IRQ_MASK, _host->sdio_irq_mask);
> - sd_ctrl_write16(_host, CTL_TRANSACTION_CTL, 0x0001);
> - }
> -
>   spin_lock_init(&_host->lock);
>   mutex_init(&_host->ios_lock);
> 
> --
> 2.11.0

RE: [PATCH] phy: rcar-gen3-usb3: Initial support for xhci phy

[Yoshihiro Shimoda]

Hi Petre-san,

> From: Petre Pircalabu
> Sent: Friday, May 19, 2017 8:55 AM
> 
> Hi Shimoda-san,
> 
> I just saw that you patch predates mine. I will drop my version and
> integrate yours.

I got it!

Best regards,
Yoshihiro Shimoda

> Many thanks for for your support,
> Petre

RE: [PATCH] phy: rcar-gen3-usb3: Initial support for xhci phy

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven
> Sent: Thursday, May 18, 2017 9:43 PM
> 
> Hi Shimoda-san,
> 
> On Thu, May 18, 2017 at 2:19 PM, Yoshihiro Shimoda
>  wrote:
> >> From: Geert Uytterhoeven
> >> Sent: Thursday, May 18, 2017 8:41 PM
> >> On Thu, May 18, 2017 at 1:13 PM, Yoshihiro Shimoda
> >>  wrote:
> >> >> >> +- reg: offset and length of the partial USB 3.0 Host PHY register 
> >> >> >> block.
> >> >> >> +- #phy-cells: see phy-bindings.txt in the same directory, must be 
> >> >> >> <0>.
> >> >> >
> >> >> > I think we should add "clocks" property as required.
> >> >> >
> >> >> >> +Optional properties:
> >> >> >
> >> >> > You should add "renesas,use-on-chip-clk" here.
> >> >> > And, the name of "use-on-chip-clk" is not good to me.
> >> >> > FYI, my developing patch names "renesas,usb-extal".
> >
> > I'm sorry for this. I missed description "on-chip clock source is supplied 
> > though
> > USB_EXTAL/USB_XTAL" in the manual. So, this "renesas,use-on-chip-clk" is 
> > reasonable.
> >
> >> >> Can this be decided at runtime, e.g. by looking at the rates of the 
> >> >> clocks
> >> >> to see which one is available/best suited?
> >> >
> >> > According to the HW manual, this module cannot see which one is 
> >> > available/best suited.
> >> > So, I don't think this can be decided at runtime.
> >>
> >> I mean, can't Linux look at the rates of the two clocks, and if one is 
> >> zero,
> >> use the other?
> >
> > I still misunderstand your question though, but software cannot look at the 
> > rates
> > of USB3S0_CLK_P/USB3S0_CLK_M and USB_EXTAL/XTAL because the HW doesn't have 
> > registers
> > for indicating the rates.
> 
> If we have "clocks" properties, as you suggested, both clocks will have to
> be described in DT.  Hence Linux will create clock objects for them, and the
> USB PHY driver can call clk_get_rate() on those objects.
> 
> If no clock is connected to USB3S0_CLK_P/USB3S0_CLK_M, a dummy clock
> with zero rate should be described in DT.
> 
> Cfr. the existing clocks with "clock-frequency = <0>" in r8a7795.dtsi.

Thank you for the detailed explanation!
I understood it. I will try to use such properties.

Best regards,
Yoshihiro Shimoda

> 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 v5 01/10] pinctrl: generic: Add bi-directional and output-enable

[Dong Aisheng]

On Tue, May 9, 2017 at 5:19 AM, Linus Walleij  wrote:
> On Mon, May 8, 2017 at 7:25 PM, jmondi  wrote:
>
>> From my perspective these flags are configurations internal to the pin
>> controller hardware used to enable/disable input buffers when a pin needs to
>> perform in both direction.
>> The level of detail I can provide on this is the logical diagram we have 
>> pointed
>> you to already.
>>
>> As I assume you are trying to get this answer from us in order to
>> avoid duplicating things in pin controller sub-system, and I
>> understand this, but my question here was "can we have those flags as part
>> of the pinmux property argument list, as that property description
>> seems to allow us to do that, instead of making them generic pin
>> configuration properties and upset other developers?"
>
> Pinmux with all it's magic flags baked into one is not any better
> or any more readable. The solution is already very pretty except
> for these two flags which I am sure we can agree on a way forward
> for.
>
> What we choose between is not this or another less transparent
> pin configuration mechanism, the mechanism (whether magic bits
> to pinmux or reasonable properties) does not matter.
>
> There is a strong preference to use the generic bindings.
>
> So the discussion is whether to use:
>
> bi-directional;
> output-enable;
>
> Or some already defined config flags.
>
> If these are too idiomatic to be used by others, they should anyways
> look similar, like:
>
> renesas,bi-directional;
> renesas,output-enable;
>
> Like the Qualcomm weirdness found in drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
>
> qcom,pull-up-strength = <..>;
>
> Check how they use
> #define PMIC_GPIO_CONF_PULL_UP (PIN_CONFIG_END + 1)
>
> Etc.
>
>> Anyway, I still fail to see why those configuration flags, only
>> affecting the way the pin controller hardware enables/disables
>> its internal buffers and its internal operations have to be
>> described in term of their externally visible electrically characteristics.
>
> To me internal vs external is not what matters. What matters is
> if this is likely to pop up in more platforms, and then the property
> should be generic.
>
> The generic pin config definitions are likely to be picked up by other
> standards and even be inspiration to hardware engineers so that
> is why it matters so much.
>
>> To me, what already exists are pin configuration properties generic to
>> the whole pin controller subsystem, and I understand you don't want to
>> see duplication there.
>>
>> At the same time, to me, those flags are settings the pin controller
>> wants to have specified by software to overcome its hw design flaws,
>> and are intended to configure its internal buffers in a way it cannot
>> do by itself for some very specific operation modes (they are listed
>> in the hw reference manual, it's not something you can chose to
>> configure or not, if you want a pin working in i2c mode, you HAVE to
>> pass those flags to pin controller).
>
> Sounds like a case for
>
> renesas,bi-directional;
> renesas,output-enable;
>
> following the Qualcomm pattern in that case.
>
> But let's see if something else comes out of this discussion.
>

I did not follow too much.
But it seems IMX7ULP/Vybrid to be also a fan of generic
output-enable/input-enable
property.

See:
Figure 5-2. GPIO PAD in Page 241
http://www.nxp.com/assets/documents/data/en/reference-manuals/VFXXXRM.pdf

It has separate register bits to control input buffer enable and
output buffer enable
and we need set it property for GPIO function.

Regards
Dong Aisheng

Re: [PATCH] arm: dts: r7s72100: Add support for GR-Peach

[Geert Uytterhoeven]

Hi Jacopo,

On Tue, May 23, 2017 at 11:47 AM, Jacopo Mondi
 wrote:
> Add device tree source for Renesas GR-Peach board.
> GR-Peach is an RZ/A1H based board with 10MB of on-chip SRAM and 8MB
> QSPI flash storage.
> Add support for the board, and create a 2MB partition to use as rootfs.
>
> Signed-off-by: Jacopo Mondi 

Thanks for your patch!

> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -51,6 +51,8 @@ Boards:
>  compatible = "renesas,bockw", "renesas,r8a7778"
>- Genmai (RTK772100BC0BR)
>  compatible = "renesas,genmai", "renesas,r7s72100"
> +  - GR-Peach (RTK772100BC0BR)

That part number is Genmai?

> +compatible = "renesas,grpeach", "renesas,r7s72100"

"renesas,gr-peach"?

> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -716,6 +716,7 @@ dtb-$(CONFIG_ARCH_S5PV210) += \
>  dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
> emev2-kzm9d.dtb \
> r7s72100-genmai.dtb \
> +   r7s72100-grpeach.dtb \

r7s72100-gr-peach.dtb?

> --- /dev/null
> +++ b/arch/arm/boot/dts/r7s72100-grpeach.dts

r7s72100-gr-peach.dts

> @@ -0,0 +1,65 @@
> +/*
> + * Device Tree Source for the GRPEACH board

GR-PEACH

> +/ {
> +   model = "GRPEACH";

GR-PEACH

> +   compatible = "renesas,grpeach", "renesas,r7s72100";

renesas,gr-peach

> +
> +   aliases {
> +   serial2 = 

The first serial port is supposed to be called serial0, unless labeled
otherwise.

> +   };
> +
> +   chosen {
> +   bootargs = "console=ttySC2,115200 ignore_loglevel rw 
> root=/dev/mtdblock0";

bootargs = "ignore_loglevel rw root=/dev/mtdblock0";
stdout-path = "serial0:115200n8";

> +   memory {

memory@2000

(please run "make dtbs W=1")

> +   device_type = "memory";
> +   reg = <0x2000 0x00A0>;  /* 10Mb @ 0x2000 */

reg = <0x2000 0x00a0>;

No need for the comment, esp. since it says 10 megabits instead of
10 mebibyte ;-)

> +   qspi@1800 {

flash@1800?

> +   compatible = "mtd-rom";
> +   probe-type = "map_rom";
> +   reg = <0x1800 0x0080>;   /* 8 MB*/

No need for the comment (megabyte vs. mebibyte)

> +   bank-width = <4>;
> +   device-width = <1>;
> +
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +
> +   rootfs@1860 {

rootfs@60?

> +   label = "rootfs";
> +   reg = <0x0060 0x0020>; /* 2MB @ 0x1860 */

Do we need the comment?

> +_clk {
> +   clock-frequency = <1333>;

My schematics have one more digit of precision: <1000>

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

[PATCH] arm: dts: r7s72100: Add support for GR-Peach

[Jacopo Mondi]

Add device tree source for Renesas GR-Peach board.
GR-Peach is an RZ/A1H based board with 10MB of on-chip SRAM and 8MB
QSPI flash storage.
Add support for the board, and create a 2MB partition to use as rootfs.

Signed-off-by: Jacopo Mondi 
---
 Documentation/devicetree/bindings/arm/shmobile.txt |  2 +
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/r7s72100-grpeach.dts | 65 ++
 3 files changed, 68 insertions(+)
 create mode 100644 arch/arm/boot/dts/r7s72100-grpeach.dts

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index c950263..1199e48 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -51,6 +51,8 @@ Boards:
 compatible = "renesas,bockw", "renesas,r8a7778"
   - Genmai (RTK772100BC0BR)
 compatible = "renesas,genmai", "renesas,r7s72100"
+  - GR-Peach (RTK772100BC0BR)
+compatible = "renesas,grpeach", "renesas,r7s72100"
   - Gose (RTP0RC7793SEB00010S)
 compatible = "renesas,gose", "renesas,r8a7793"
   - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKB00010S)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0118084..b238a3a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -716,6 +716,7 @@ dtb-$(CONFIG_ARCH_S5PV210) += \
 dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
emev2-kzm9d.dtb \
r7s72100-genmai.dtb \
+   r7s72100-grpeach.dtb \
r7s72100-rskrza1.dtb \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
diff --git a/arch/arm/boot/dts/r7s72100-grpeach.dts 
b/arch/arm/boot/dts/r7s72100-grpeach.dts
new file mode 100644
index 000..5edd0a5
--- /dev/null
+++ b/arch/arm/boot/dts/r7s72100-grpeach.dts
@@ -0,0 +1,65 @@
+/*
+ * Device Tree Source for the GRPEACH board
+ *
+ * Copyright (C) 2017 Jacopo Mondi 
+ * Copyright (C) 2016 Renesas Electronics
+ *
+ * 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 "r7s72100.dtsi"
+
+/ {
+   model = "GRPEACH";
+   compatible = "renesas,grpeach", "renesas,r7s72100";
+
+   aliases {
+   serial2 = 
+   };
+
+   chosen {
+   bootargs = "console=ttySC2,115200 ignore_loglevel rw 
root=/dev/mtdblock0";
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x2000 0x00A0>;  /* 10Mb @ 0x2000 */
+
+   };
+
+   lbsc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+
+   qspi@1800 {
+   compatible = "mtd-rom";
+   probe-type = "map_rom";
+   reg = <0x1800 0x0080>;   /* 8 MB*/
+   bank-width = <4>;
+   device-width = <1>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   rootfs@1860 {
+   label = "rootfs";
+   reg = <0x0060 0x0020>; /* 2MB @ 0x1860 */
+   };
+   };
+};
+
+_clk {
+   clock-frequency = <1333>;
+};
+
+_x1_clk {
+   clock-frequency = <4800>;
+};
+
+ {
+   status = "okay";
+};
-- 
2.7.4

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

[Geert Uytterhoeven]

Hi Florian,

On Fri, May 19, 2017 at 12:21 AM, Florian Fainelli  wrote:
> On 05/18/2017 01:36 PM, Geert Uytterhoeven wrote:
>> On Thu, May 18, 2017 at 9:34 PM, Andrew Lunn  wrote:
> This most certainly works fine in the simple case where you have one PHY
> hanging off the MDIO bus, now what happens if you have several?
>
> Presumably, the first PHY that returns EPROBE_DEFER will make the entire
> bus registration return EPROB_DEFER as well, and so on, and so forth,
> but I am not sure if we will be properly unwinding the successful
> registration of PHYs that either don't have an interrupt, or did not
> return EPROBE_DEFER.
>
> It should be possible to mimic this behavior by using the fixed PHY, and
> possibly the dsa_loop.c driver which would create 4 ports, expecting 4
> fixed PHYs to be present.

 mdiobus_unregister(), called from of_mdiobus_register() on failure,
 should do the unwinding, right?

 And when the driver is reprobed, all PHYs are reprobed, until they all
 succeed.
>>>
>>> That is the theory. I looked at that while reviewing the patch. But
>>> this has probably not been tested in anger. It would be good to test
>>> this properly, with not just the first PHY returning -EPROBE_DEFER, to
>>> really test the unwind.
>>
>> Unfortunately I don't have a board with multiple PHYs, so I cannot test
>> that case.

I tried adding a few dummy PHYs in DT, but that didn't work.

So how can we proceed?

I think the only way my patch can cause issues is because some systems
may rely on EPROBE_DEFER errors being ignored.

>> Does unbinding/rebinding a network driver with multiple PHYs currently
>> work? Or module unload/reload?
>
> Usually there is a strict 1:1 mapping between a network device (not
> driver) and a PHY device, switch drivers however, would have multiple
> PHYs (one per port, aka net_deice).
>
> NB: binding and unbinding of PHYs is pretty broken at the moment though,
> because there is a complete disconnect between what the Ethernet MAC
> expects, and the state in which the PHY is. I had some patches to fix
> that, but this turned out to be playing whack-a-mole which I typically
> suck at.

I didn't mean unbinding the PHY, but the network device.
Don't you have the same issue with the state of PHYs as left by the bootloader?

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 21/27] rcar-vin: add group allocator functions

[Niklas Söderlund]

Hi Sakari,

Thanks for your feedback.

On 2017-05-04 18:12:20 +0300, Sakari Ailus wrote:
> Hi Niklas,
> 
> On Fri, Apr 28, 2017 at 12:41:57AM +0200, Niklas Söderlund wrote:
> > 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 a 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 
> > ---
> >  drivers/media/platform/rcar-vin/rcar-core.c | 112 
> > +++-
> >  drivers/media/platform/rcar-vin/rcar-vin.h  |  38 ++
> >  2 files changed, 147 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> > b/drivers/media/platform/rcar-vin/rcar-core.c
> > index f560d27449b84882..c10770d5ec37816c 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > @@ -20,12 +20,110 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  
> >  #include "rcar-vin.h"
> >  
> >  /* 
> > -
> > + * Gen3 CSI2 Group Allocator
> > + */
> > +
> > +static DEFINE_MUTEX(rvin_group_lock);
> > +static struct rvin_group *rvin_group_data;
> 
> Uh-oh.
> 
> It'd be nice to find a way for managing the group of devices without a
> global list for the group.
> 
> Do all the callers operating on a group have some kind of identifying
> information, e.g. OF node or struct device? Could it be used to obtain the
> group?

I agree that a none global list would be better. There is room for 
improvement here in the future. I do believe some key can be found in DT 
as to create the group of all VIN instances who are part of the same OF 
graph or something similar.

There is also one other limiting factor at play here. The VIN instances 
0-3 and 4-7 must be in the same group since there are registers in VIN0 
that controls VIN1-3 and likewise in VIN4 for VIN5-6. And it is these 
shared control registers which is the primary reason this global group 
exists to begin with.

> 
> I'm not sure if this would be a real problem though as long as you have only
> a single group in a system.

No for now all VIN instances should be part of a single group as this is 
the only use-case which is valid (that I know of). So I hope to keep 
this as is for now and at a later time come back and improve it.

> 
> > +
> > +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 struct rvin_group *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 ERR_PTR(-ENOMEM);
> > +   }
> > +
> > +   /* Init group data if its 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));
> > +   strlcpy(mdev->bus_info, of_node_full_name(vin->dev->of_node),
> > +   sizeof(mdev->bus_info));
> > +   mdev->driver_version = LINUX_VERSION_CODE;
> > +   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 

RE: [PATCH 0/5] usb: gadget: udc: renesas_usb3: add DMAC support

[Yoshihiro Shimoda]

Hi Felipe,

> -Original Message-
> From: Yoshihiro Shimoda
> Sent: Wednesday, April 26, 2017 8:50 PM
> 
> This patch set is based on the latest Feribe's usb.git / testing/next branch
> (the commit id = 28ea6be01e2cf244c461a40c8e9593816f894412.)

I'm afraid but, would you review this patch set?
This patch set can be applied on the today's testing/next branch.

Best regards,
Yoshihiro Shimoda

> This patch set has 2 things:
>  - Fixes some minor issues.
>  - Add support for dedicated DMAC.
> 
> If possible, I want the patches [1/5] to [4/5] to be applied to v4.12-rcN.
> I think the patch [5/5] will be applied to v4.13 (or later).
> Should I submit them sepaletely?
> 
> Yoshihiro Shimoda (5):
>   usb: gadget: udc: renesas_usb3: fix pm_runtime functions calling
>   usb: gadget: udc: renesas_usb3: fix deadlock by spinlock
>   usb: gadget: udc: renesas_usb3: lock for PN_ registers access
>   usb: gadget: udc: renesas_usb3: Fix PN_INT_ENA disabling timing
>   usb: gadget: udc: renesas_usb3: add support for dedicated DMAC
> 
>  drivers/usb/gadget/udc/renesas_usb3.c | 438 
> +-
>  1 file changed, 425 insertions(+), 13 deletions(-)
> 
> --
> 1.9.1