Re: [PATCH] dt-bindings: rcar-dmac: Document r8a77470 support

[Vinod Koul]

On Thu, Mar 29, 2018 at 11:11:06AM +0100, Biju Das wrote:
> Renesas  RZ/G SoC also have the R-Car gen2/3 compatible DMA controllers.
> Document RZ/G1C (also known as R8A77470) SoC bindings.

Applied, thanks

-- 
~Vinod

Re: [PATCH] dmaengine: rcar-dmac: Fix too early/late system suspend/resume callbacks

[Vinod Koul]

On Thu, Mar 29, 2018 at 06:53:32PM +0200, Geert Uytterhoeven wrote:
> If serial console wake-up is enabled ("echo enabled >
> /sys/.../ttySC0/power/wakeup"), and any serial input is received while
> the system is suspended, serial port input no longer works after system
> resume.
> 
> Note that:
>   1) The system can still be woken up using the serial console,
>   2) Serial port input keeps working if the system is woken up in some
>  other way (e.g. Wake-on-LAN or gpio-keys), and no serial input was
>  received while suspended.
> 
> To fix this, replace SET_LATE_SYSTEM_SLEEP_PM_OPS() by
> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(), as the callbacks installed by the
> former happen too early resp. late in the suspend resp. resume process.

Applied, thanks

-- 
~Vinod

Re: [PATCH v13 17/33] rcar-vin: cache video standard

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Tuesday, 27 March 2018 00:44:40 EEST Niklas Söderlund wrote:
> At stream on time the driver should not query the subdevice for which
> standard are used. Instead it should be cached when userspace sets the
> standard and used at stream on time.
> 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c |  6 ++
>  drivers/media/platform/rcar-vin/rcar-dma.c  |  7 ++-
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 10 --
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  2 ++
>  4 files changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> be49d8968f0a0cef..8c251687e81b345b 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -96,6 +96,12 @@ static int rvin_digital_subdevice_attach(struct rvin_dev
> *vin, if (ret < 0 && ret != -ENOIOCTLCMD && ret != -ENODEV)
>   return ret;
> 
> + /* Read standard */
> + vin->std = V4L2_STD_UNKNOWN;
> + ret = v4l2_subdev_call(subdev, video, g_std, >std);
> + if (ret < 0 && ret != -ENOIOCTLCMD)
> + return ret;
> +
>   /* Add the controls */
>   ret = v4l2_ctrl_handler_init(>ctrl_handler, 16);
>   if (ret < 0)
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> 9233924e5b52de5f..79f4074b931b5aeb 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -592,7 +592,6 @@ void rvin_crop_scale_comp(struct rvin_dev *vin)
>  static int rvin_setup(struct rvin_dev *vin)
>  {
>   u32 vnmc, dmr, dmr2, interrupts;
> - v4l2_std_id std;
>   bool progressive = false, output_is_yuv = false, input_is_yuv = false;
> 
>   switch (vin->format.field) {
> @@ -606,10 +605,8 @@ static int rvin_setup(struct rvin_dev *vin)
>   /* Default to TB */
>   vnmc = VNMC_IM_FULL;
>   /* Use BT if video standard can be read and is 60 Hz format */
> - if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
> - if (std & V4L2_STD_525_60)
> - vnmc = VNMC_IM_FULL | VNMC_FOC;
> - }
> + if (vin->std & V4L2_STD_525_60)
> + vnmc = VNMC_IM_FULL | VNMC_FOC;
>   break;
>   case V4L2_FIELD_INTERLACED_TB:
>   vnmc = VNMC_IM_FULL;
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> c4be0bcb8b16f941..43370c57d4b6239a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -477,6 +477,8 @@ static int rvin_s_std(struct file *file, void *priv,
> v4l2_std_id a) if (ret < 0)
>   return ret;
> 
> + vin->std = a;
> +
>   /* Changing the standard will change the width/height */
>   return rvin_reset_format(vin);
>  }
> @@ -484,9 +486,13 @@ static int rvin_s_std(struct file *file, void *priv,
> v4l2_std_id a) static int rvin_g_std(struct file *file, void *priv,
> v4l2_std_id *a) {
>   struct rvin_dev *vin = video_drvdata(file);
> - struct v4l2_subdev *sd = vin_to_source(vin);
> 
> - return v4l2_subdev_call(sd, video, g_std, a);
> + if (v4l2_subdev_has_op(vin_to_source(vin), pad, dv_timings_cap))
> + return -ENOIOCTLCMD;
> +
> + *a = vin->std;
> +
> + return 0;
>  }
> 
>  static int rvin_subscribe_event(struct v4l2_fh *fh,
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h index
> e940366d7e8d0e76..06cec4f8e5ffaf2b 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -118,6 +118,7 @@ struct rvin_info {
>   * @crop:active cropping
>   * @compose: active composing
>   * @source:  active size of the video source
> + * @std: active video standard of the video source
>   */
>  struct rvin_dev {
>   struct device *dev;
> @@ -146,6 +147,7 @@ struct rvin_dev {
>   struct v4l2_rect crop;
>   struct v4l2_rect compose;
>   struct v4l2_rect source;
> + v4l2_std_id std;
>  };
> 
>  #define vin_to_source(vin)   ((vin)->digital->subdev)


-- 
Regards,

Laurent Pinchart

Re: [PATCH v13 16/33] rcar-vin: simplify how formats are set and reset

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Tuesday, 27 March 2018 00:44:39 EEST Niklas Söderlund wrote:
> With the recent cleanup of the format code to prepare for Gen3 it's
> possible to simplify the Gen2 format code path as well. Clean up the
> process by defining two functions to handle the set format and reset of
> format when the standard is changed.
> 
> While at it replace the driver local struct rvin_source_fmt with a
> struct v4l2_rect as all it's used for is keep track of the source
> dimensions.

I wonder whether we should introduce v4l2_size (or ) when all we need is width and height, as v4l2_rect stores the top and 
left offsets too. This doesn't have to be fixed here though.

> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 
> 
> ---
> 
> * Changes since v11
> - This patch where 'rcar-vin: read subdevice format for crop only when
> needed'
> - Keep caching the source dimensions and drop all changes to
> rvin_g_selection() and rvin_s_selection().
> - Inline rvin_get_vin_format_from_source() into rvin_reset_format()
> which now is the only user left.
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 116 +++--
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  14 +---
>  2 files changed, 52 insertions(+), 78 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> c39891386576afb8..c4be0bcb8b16f941 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -138,67 +138,60 @@ static int rvin_format_align(struct rvin_dev *vin,
> struct v4l2_pix_format *pix) * V4L2
>   */
> 
> -static void rvin_reset_crop_compose(struct rvin_dev *vin)
> -{
> - vin->crop.top = vin->crop.left = 0;
> - vin->crop.width = vin->source.width;
> - vin->crop.height = vin->source.height;
> -
> - vin->compose.top = vin->compose.left = 0;
> - vin->compose.width = vin->format.width;
> - vin->compose.height = vin->format.height;
> -}
> -
>  static int rvin_reset_format(struct rvin_dev *vin)
>  {
>   struct v4l2_subdev_format fmt = {
>   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + .pad = vin->digital->source_pad,
>   };
> - struct v4l2_mbus_framefmt *mf = 
>   int ret;
> 
> - fmt.pad = vin->digital->source_pad;
> -
>   ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
>   if (ret)
>   return ret;
> 
> - vin->format.width   = mf->width;
> - vin->format.height  = mf->height;
> - vin->format.colorspace  = mf->colorspace;
> - vin->format.field   = mf->field;
> + v4l2_fill_pix_format(>format, );
> 
> - rvin_reset_crop_compose(vin);
> + ret = rvin_format_align(vin, >format);
> + if (ret)
> + return ret;

rvin_format_align() always returns 0 so you can remove the error check. You 
can actually turn the function into a void function.

> - vin->format.bytesperline = rvin_format_bytesperline(>format);
> - vin->format.sizeimage = rvin_format_sizeimage(>format);
> + vin->source.top = vin->crop.top = 0;
> + vin->source.left = vin->crop.left = 0;
> + vin->source.width = vin->crop.width = vin->format.width;
> + vin->source.height = vin->crop.height = vin->format.height;

I find multiple assignations on the same line hard to read. How about

vin->source.top = 0;
vin->source.left = 0;
vin->source.width = vin->format.width;
vin->source.height = vin->format.height;

vin->crop = vin->source;
vin->compose = vin->source;

> + vin->compose.top = vin->compose.left = 0;
> + vin->compose.width = vin->format.width;
> + vin->compose.height = vin->format.height;
> 
>   return 0;
>  }

I like the new rvin_reset_format(), it's much simpler.

> -static int __rvin_try_format_source(struct rvin_dev *vin,
> - u32 which,
> - struct v4l2_pix_format *pix,
> - struct rvin_source_fmt *source)
> +static int rvin_try_format(struct rvin_dev *vin, u32 which,
> +struct v4l2_pix_format *pix,
> +struct v4l2_rect *crop, struct v4l2_rect *compose)
>  {
> - struct v4l2_subdev *sd;
> + struct v4l2_subdev *sd = vin_to_source(vin);
>   struct v4l2_subdev_pad_config *pad_cfg;
>   struct v4l2_subdev_format format = {
>   .which = which,
> + .pad = vin->digital->source_pad,
>   };
>   enum v4l2_field field;
>   u32 width, height;
>   int ret;
> 
> - sd = vin_to_source(vin);
> -
> - v4l2_fill_mbus_format(, pix, vin->digital->code);
> -
>   pad_cfg = v4l2_subdev_alloc_pad_config(sd);
>   if (pad_cfg == NULL)
>   return -ENOMEM;
> 
> - format.pad = vin->digital->source_pad;
> + if 

[PATCH] mmc: tmio: Fix error handling when issuing CMD23

[Wolfram Sang]

From: Masaharu Hayakawa 

If an error was detected when CMD23 was issued, command sequence should
be terminated with errors and CMD23 should be issued after retuning.

Fixes: 8b22c3c18be5 ("mmc: tmio: add CMD23 support")
Signed-off-by: Masaharu Hayakawa 
Signed-off-by: Wolfram Sang 
---

Ulf: I'd think this is suitable for stable...

 drivers/mmc/host/tmio_mmc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index e30df9ad8197..308029930304 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -913,7 +913,7 @@ static void tmio_mmc_finish_request(struct tmio_mmc_host 
*host)
host->check_scc_error(host);
 
/* If SET_BLOCK_COUNT, continue with main command */
-   if (host->mrq) {
+   if (host->mrq && !mrq->cmd->error) {
tmio_process_mrq(host, mrq);
return;
}
-- 
2.11.0

Re: [PATCH v13 12/33] rcar-vin: fix handling of single field frames (top, bottom and alternate fields)

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Tuesday, 27 March 2018 00:44:35 EEST Niklas Söderlund wrote:
> There was never proper support in the VIN driver to deliver ALTERNATING
> field format to user-space, remove this field option. The problem is
> that ALTERNATING field order requires the sequence numbers of buffers
> returned to userspace to reflect if fields were dropped or not,
> something which is not possible with the VIN drivers capture logic.
> 
> The VIN driver can still capture from a video source which delivers
> frames in ALTERNATING field order, but needs to combine them using the
> VIN hardware into INTERLACED field order. Before this change if a source
> was delivering fields using ALTERNATE the driver would default to
> combining them using this hardware feature. Only if the user explicitly
> requested ALTERNATE field order would incorrect frames be delivered.
> 
> The height should not be cut in half for the format for TOP or BOTTOM
> fields settings. This was a mistake and it was made visible by the
> scaling refactoring. Correct behavior is that the user should request a
> frame size that fits the half height frame reflected in the field
> setting. If not the VIN will do its best to scale the top or bottom to
> the requested format and cropping and scaling do not work as expected.
> 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 
> 
> ---
> 
> * Changes since v12
> - Spelling where -> were.
> - Add review tag from Hans.
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c  | 15 +--
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 40 +++---
>  2 files changed, 10 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> 4f48575f2008fe34..9233924e5b52de5f 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -617,7 +617,6 @@ static int rvin_setup(struct rvin_dev *vin)
>   case V4L2_FIELD_INTERLACED_BT:
>   vnmc = VNMC_IM_FULL | VNMC_FOC;
>   break;
> - case V4L2_FIELD_ALTERNATE:
>   case V4L2_FIELD_NONE:
>   vnmc = VNMC_IM_ODD_EVEN;
>   progressive = true;
> @@ -745,18 +744,6 @@ static bool rvin_capture_active(struct rvin_dev *vin)
>   return rvin_read(vin, VNMS_REG) & VNMS_CA;
>  }
> 
> -static enum v4l2_field rvin_get_active_field(struct rvin_dev *vin, u32
> vnms)
> -{
> - if (vin->format.field == V4L2_FIELD_ALTERNATE) {
> - /* If FS is set it's a Even field */
> - if (vnms & VNMS_FS)
> - return V4L2_FIELD_BOTTOM;
> - return V4L2_FIELD_TOP;
> - }
> -
> - return vin->format.field;
> -}
> -
>  static void rvin_set_slot_addr(struct rvin_dev *vin, int slot, dma_addr_t
> addr) {
>   const struct rvin_video_format *fmt;
> @@ -892,7 +879,7 @@ static irqreturn_t rvin_irq(int irq, void *data)
> 
>   /* Capture frame */
>   if (vin->queue_buf[slot]) {
> - vin->queue_buf[slot]->field = rvin_get_active_field(vin, vnms);
> + vin->queue_buf[slot]->field = vin->format.field;
>   vin->queue_buf[slot]->sequence = vin->sequence;
>   vin->queue_buf[slot]->vb2_buf.timestamp = ktime_get_ns();
>   vb2_buffer_done(>queue_buf[slot]->vb2_buf,
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> 16e895657c3f51c5..e956a385cc13f5f3 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -121,33 +121,6 @@ static int rvin_reset_format(struct rvin_dev *vin)
>   vin->format.colorspace  = mf->colorspace;
>   vin->format.field   = mf->field;
> 
> - /*
> -  * If the subdevice uses ALTERNATE field mode and G_STD is
> -  * implemented use the VIN HW to combine the two fields to
> -  * one INTERLACED frame. The ALTERNATE field mode can still
> -  * be requested in S_FMT and be respected, this is just the
> -  * default which is applied at probing or when S_STD is called.
> -  */
> - if (vin->format.field == V4L2_FIELD_ALTERNATE &&
> - v4l2_subdev_has_op(vin_to_source(vin), video, g_std))
> - vin->format.field = V4L2_FIELD_INTERLACED;
> -
> - switch (vin->format.field) {
> - case V4L2_FIELD_TOP:
> - case V4L2_FIELD_BOTTOM:
> - case V4L2_FIELD_ALTERNATE:
> - vin->format.height /= 2;
> - break;
> - case V4L2_FIELD_NONE:
> - case V4L2_FIELD_INTERLACED_TB:
> - case V4L2_FIELD_INTERLACED_BT:
> - case V4L2_FIELD_INTERLACED:
> - break;
> - default:
> - vin->format.field = RVIN_DEFAULT_FIELD;
> - break;
> - }
> -
>   rvin_reset_crop_compose(vin);
> 
>   vin->format.bytesperline = 

Re: [PATCH v13 15/33] rcar-vin: break out format alignment and checking

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Tuesday, 27 March 2018 00:44:38 EEST Niklas Söderlund wrote:
> Part of the format alignment and checking can be shared with the Gen3
> format handling. Break that part out to a separate function.
> 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 85 +++--
>  1 file changed, 48 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> 8dbd764883976ad1..c39891386576afb8 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -87,6 +87,53 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format
> *pix) return pix->bytesperline * pix->height;
>  }
> 
> +static int rvin_format_align(struct rvin_dev *vin, struct v4l2_pix_format
> *pix)
> +{
> + u32 walign;
> +
> + if (!rvin_format_from_pixel(pix->pixelformat) ||
> + (vin->info->model == RCAR_M1 &&
> +  pix->pixelformat == V4L2_PIX_FMT_XBGR32))
> + pix->pixelformat = RVIN_DEFAULT_FORMAT;
> +
> + switch (pix->field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + break;
> + case V4L2_FIELD_ALTERNATE:
> + /*
> +  * Driver dose not (yet) support outputting ALTERNATE to a

s/dose/does/

Apart from that,

Reviewed-by: Laurent Pinchart 

> +  * userspace. It does support outputting INTERLACED so use
> +  * the VIN hardware to combine the two fields.
> +  */
> + pix->field = V4L2_FIELD_INTERLACED;
> + pix->height *= 2;
> + break;
> + default:
> + pix->field = RVIN_DEFAULT_FIELD;
> + break;
> + }
> +
> + /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
> + walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
> +
> + /* Limit to VIN capabilities */
> + v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
> +   >height, 4, vin->info->max_height, 2, 0);
> +
> + pix->bytesperline = rvin_format_bytesperline(pix);
> + pix->sizeimage = rvin_format_sizeimage(pix);
> +
> + vin_dbg(vin, "Format %ux%u bpl: %u size: %u\n",
> + pix->width, pix->height, pix->bytesperline, pix->sizeimage);
> +
> + return 0;
> +}
> +
>  /*
> ---
> -- * V4L2
>   */
> @@ -186,7 +233,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
>struct v4l2_pix_format *pix,
>struct rvin_source_fmt *source)
>  {
> - u32 walign;
>   int ret;
> 
>   if (!rvin_format_from_pixel(pix->pixelformat) ||
> @@ -199,42 +245,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
>   if (ret)
>   return ret;
> 
> - switch (pix->field) {
> - case V4L2_FIELD_TOP:
> - case V4L2_FIELD_BOTTOM:
> - case V4L2_FIELD_NONE:
> - case V4L2_FIELD_INTERLACED_TB:
> - case V4L2_FIELD_INTERLACED_BT:
> - case V4L2_FIELD_INTERLACED:
> - break;
> - case V4L2_FIELD_ALTERNATE:
> - /*
> -  * Driver dose not (yet) support outputting ALTERNATE to a
> -  * userspace. It does support outputting INTERLACED so use
> -  * the VIN hardware to combine the two fields.
> -  */
> - pix->field = V4L2_FIELD_INTERLACED;
> - pix->height *= 2;
> - break;
> - default:
> - pix->field = RVIN_DEFAULT_FIELD;
> - break;
> - }
> -
> - /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
> - walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
> -
> - /* Limit to VIN capabilities */
> - v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
> -   >height, 4, vin->info->max_height, 2, 0);
> -
> - pix->bytesperline = rvin_format_bytesperline(pix);
> - pix->sizeimage = rvin_format_sizeimage(pix);
> -
> - vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
> - pix->width, pix->height, pix->bytesperline, pix->sizeimage);
> -
> - return 0;
> + return rvin_format_align(vin, pix);
>  }
> 
>  static int rvin_querycap(struct file *file, void *priv,


-- 
Regards,

Laurent Pinchart

Re: [PATCH v13 22/33] rcar-vin: use different v4l2 operations in media controller mode

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Tuesday, 27 March 2018 00:44:45 EEST Niklas Söderlund wrote:
> When the driver runs in media controller mode it should not directly
> control the subdevice instead userspace will be responsible for
> configuring the pipeline. To be able to run in this mode a different set
> of v4l2 operations needs to be used.
> 
> Add a new set of v4l2 operations to support operation without directly
> interacting with the source subdevice.
> 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 

Reviewed-by: Laurent Pinchart 

> 
> ---
> 
> * Changes since v11
> - Fixed error labels name in rvin_mc_open().
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c  |   2 +-
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 161
> +++- 2 files changed, 159 insertions(+), 4
> deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> 1809f5c0190eafb6..a93772c10baaa003 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -627,7 +627,7 @@ static int rvin_setup(struct rvin_dev *vin)
>   /* Default to TB */
>   vnmc = VNMC_IM_FULL;
>   /* Use BT if video standard can be read and is 60 Hz format */
> - if (vin->std & V4L2_STD_525_60)
> + if (!vin->info->use_mc && vin->std & V4L2_STD_525_60)
>   vnmc = VNMC_IM_FULL | VNMC_FOC;
>   break;
>   case V4L2_FIELD_INTERLACED_TB:
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> dd835be0f9cbcc05..2280535ca981993f 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -18,12 +18,16 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include "rcar-vin.h"
> 
>  #define RVIN_DEFAULT_FORMAT  V4L2_PIX_FMT_YUYV
> +#define RVIN_DEFAULT_WIDTH   800
> +#define RVIN_DEFAULT_HEIGHT  600
>  #define RVIN_DEFAULT_FIELD   V4L2_FIELD_NONE
> +#define RVIN_DEFAULT_COLORSPACE  V4L2_COLORSPACE_SRGB
> 
>  /*
> ---
> -- * Format Conversions
> @@ -656,6 +660,74 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>   .vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
>  };
> 
> +/*
> ---
> -- + * V4L2 Media Controller
> + */
> +
> +static int rvin_mc_try_fmt_vid_cap(struct file *file, void *priv,
> +struct v4l2_format *f)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> +
> + return rvin_format_align(vin, >fmt.pix);
> +}
> +
> +static int rvin_mc_s_fmt_vid_cap(struct file *file, void *priv,
> +  struct v4l2_format *f)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + int ret;
> +
> + if (vb2_is_busy(>queue))
> + return -EBUSY;
> +
> + ret = rvin_format_align(vin, >fmt.pix);
> + if (ret)
> + return ret;
> +
> + vin->format = f->fmt.pix;
> +
> + return 0;
> +}
> +
> +static int rvin_mc_enum_input(struct file *file, void *priv,
> +   struct v4l2_input *i)
> +{
> + if (i->index != 0)
> + return -EINVAL;
> +
> + i->type = V4L2_INPUT_TYPE_CAMERA;
> + strlcpy(i->name, "Camera", sizeof(i->name));
> +
> + return 0;
> +}
> +
> +static const struct v4l2_ioctl_ops rvin_mc_ioctl_ops = {
> + .vidioc_querycap= rvin_querycap,
> + .vidioc_try_fmt_vid_cap = rvin_mc_try_fmt_vid_cap,
> + .vidioc_g_fmt_vid_cap   = rvin_g_fmt_vid_cap,
> + .vidioc_s_fmt_vid_cap   = rvin_mc_s_fmt_vid_cap,
> + .vidioc_enum_fmt_vid_cap= rvin_enum_fmt_vid_cap,
> +
> + .vidioc_enum_input  = rvin_mc_enum_input,
> + .vidioc_g_input = rvin_g_input,
> + .vidioc_s_input = rvin_s_input,
> +
> + .vidioc_reqbufs = vb2_ioctl_reqbufs,
> + .vidioc_create_bufs = vb2_ioctl_create_bufs,
> + .vidioc_querybuf= vb2_ioctl_querybuf,
> + .vidioc_qbuf= vb2_ioctl_qbuf,
> + .vidioc_dqbuf   = vb2_ioctl_dqbuf,
> + .vidioc_expbuf  = vb2_ioctl_expbuf,
> + .vidioc_prepare_buf = vb2_ioctl_prepare_buf,
> + .vidioc_streamon= vb2_ioctl_streamon,
> + .vidioc_streamoff   = vb2_ioctl_streamoff,
> +
> + .vidioc_log_status  = v4l2_ctrl_log_status,
> + .vidioc_subscribe_event = rvin_subscribe_event,
> + .vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
> +};
> +
>  /*
> 

Re: [PATCH v13 23/33] rcar-vin: force default colorspace for media centric mode

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Tuesday, 27 March 2018 00:44:46 EEST Niklas Söderlund wrote:
> The V4L2 specification clearly documents the colorspace fields as being
> set by drivers for capture devices. Using the values supplied by
> userspace thus wouldn't comply with the API. Until the API is updated to
> allow for userspace to set these Hans wants the fields to be set by the
> driver to fixed values.
> 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> 2280535ca981993f..ea0759a645e49490 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -664,12 +664,29 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>   * V4L2 Media Controller
>   */
> 
> +static int rvin_mc_try_format(struct rvin_dev *vin, struct v4l2_pix_format
> *pix) +{
> + /*
> +  * The V4L2 specification clearly documents the colorspace fields
> +  * as being set by drivers for capture devices. Using the values
> +  * supplied by userspace thus wouldn't comply with the API. Until
> +  * the API is updated force fixed vaules.
> +  */
> + pix->colorspace = RVIN_DEFAULT_COLORSPACE;
> + pix->xfer_func = V4L2_MAP_XFER_FUNC_DEFAULT(pix->colorspace);
> + pix->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(pix->colorspace);
> + pix->quantization = V4L2_MAP_QUANTIZATION_DEFAULT(true, pix->colorspace,
> +   pix->ycbcr_enc);
> +
> + return rvin_format_align(vin, pix);
> +}
> +
>  static int rvin_mc_try_fmt_vid_cap(struct file *file, void *priv,
>  struct v4l2_format *f)
>  {
>   struct rvin_dev *vin = video_drvdata(file);
> 
> - return rvin_format_align(vin, >fmt.pix);
> + return rvin_mc_try_format(vin, >fmt.pix);
>  }
> 
>  static int rvin_mc_s_fmt_vid_cap(struct file *file, void *priv,
> @@ -681,7 +698,7 @@ static int rvin_mc_s_fmt_vid_cap(struct file *file, void
> *priv, if (vb2_is_busy(>queue))
>   return -EBUSY;
> 
> - ret = rvin_format_align(vin, >fmt.pix);
> + ret = rvin_mc_try_format(vin, >fmt.pix);
>   if (ret)
>   return ret;


-- 
Regards,

Laurent Pinchart

Re: [PATCH v13 29/33] rcar-vin: add link notify for Gen3

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Tuesday, 27 March 2018 00:44:52 EEST Niklas Söderlund wrote:
> Add the ability to process media device link change requests. Link
> enabling is a bit complicated on Gen3, whether or not it's possible to
> enable a link depends on what other links already are enabled. On Gen3
> the 8 VINs are split into two subgroup's (VIN0-3 and VIN4-7) and from a
> routing perspective these two groups are independent of each other.
> Each subgroup's routing is controlled by the subgroup VIN master
> instance (VIN0 and VIN4).
> 
> There are a limited number of possible route setups available for each
> subgroup and the configuration of each setup is dictated by the
> hardware. On H3 for example there are 6 possible route setups for each
> subgroup to choose from.
> 
> This leads to the media device link notification code being rather large
> since it will find the best routing configuration to try and accommodate
> as many links as possible. When it's not possible to enable a new link
> due to hardware constrains the link_notifier callback will return
> -EMLINK.
> 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 

Reviewed-by: Laurent Pinchart 

> 
> ---
> 
> * Changes since v11
> - Fixed spelling
> - Updated comment to clarify the intent that no link can be enabled if
> any video node is open.
> - Use container_of() instead of a loop to find struct vin_dev from the
> video device.
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 147
>  1 file changed, 147 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> 99f6301a778046df..0cc76d73115e9277 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -24,6 +24,7 @@
> 
>  #include 
>  #include 
> +#include 
> 
>  #include "rcar-vin.h"
> 
> @@ -44,6 +45,151 @@
>   */
>  #define rvin_group_id_to_master(vin) ((vin) < 4 ? 0 : 4)
> 
> +/*
> ---
> -- + * Media Controller link notification
> + */
> +
> +/* group lock should be held when calling this function. */
> +static int rvin_group_entity_to_csi_id(struct rvin_group *group,
> +struct media_entity *entity)
> +{
> + struct v4l2_subdev *sd;
> + unsigned int i;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + for (i = 0; i < RVIN_CSI_MAX; i++)
> + if (group->csi[i].subdev == sd)
> + return i;
> +
> + return -ENODEV;
> +}
> +
> +static unsigned int rvin_group_get_mask(struct rvin_dev *vin,
> + enum rvin_csi_id csi_id,
> + unsigned char channel)
> +{
> + const struct rvin_group_route *route;
> + unsigned int mask = 0;
> +
> + for (route = vin->info->routes; route->mask; route++) {
> + if (route->vin == vin->id &&
> + route->csi == csi_id &&
> + route->channel == channel) {
> + vin_dbg(vin,
> + "Adding route: vin: %d csi: %d channel: %d\n",
> + route->vin, route->csi, route->channel);
> + mask |= route->mask;
> + }
> + }
> +
> + return mask;
> +}
> +
> +/*
> + * Link setup for the links between a VIN and a CSI-2 receiver is a bit
> + * complex. The reason for this is that the register controlling routing
> + * is not present in each VIN instance. There are special VINs which
> + * control routing for themselves and other VINs. There are not many
> + * different possible links combinations that can be enabled at the same
> + * time, therefor all already enabled links which are controlled by a
> + * master VIN need to be taken into account when making the decision
> + * if a new link can be enabled or not.
> + *
> + * 1. Find out which VIN the link the user tries to enable is connected to.
> + * 2. Lookup which master VIN controls the links for this VIN.
> + * 3. Start with a bitmask with all bits set.
> + * 4. For each previously enabled link from the master VIN bitwise AND its
> + *route mask (see documentation for mask in struct rvin_group_route)
> + *with the bitmask.
> + * 5. Bitwise AND the mask for the link the user tries to enable to the
> bitmask. + * 6. If the bitmask is not empty at this point the new link can
> be enabled + *while keeping all previous links enabled. Update the
> CHSEL value of the + *master VIN and inform the user that the link
> could be enabled. + *
> + * Please note that no link can be enabled if any VIN in the group is
> + * currently open.
> + */
> +static int rvin_group_link_notify(struct media_link *link, u32 flags,
> +   unsigned 

Re: [PATCH] i2c: rcar: initialize earlier using subsys_initcall()

[Wolfram Sang]

> Thus putting an I2C master controller device driver to the same late
> init level means that due to the concurrency there will be lots of
> probe defers of endpoint device drivers, and making "heavy" device
> drivers like rcar-vin to be run in asyncronous probe increases boot
> time dispersion (rcar-vin is already probed, it's time to probe a
> sensor, but I2C controller is not yet ready to operate, defer).

I do understand the problem. Yet, the root casue is that deferred
probing is only an interim solution not well suited for such cases.

> I don't suppose that the proposed change has any single negative
> side effect, well, right, probe/remove code becomes more awkward,
> but in general the expected effect to boot time improvement should
> cover it, I hope.

We once had a discussion where one guy needed subsys_initcall and the
other one needed module_init because of different use cases. That was
not great.

I am fully aware some probe ordering solution in Linux is much desired.
But fine-tuning init levels is a workaround. Even worse, it will
reduce the pressure for a proper solution. And if we ever get that
solution, different init levels will likely make the conversion harder.

So, I do understand your customers want such a patch for their use case.
But I don't think it is a good idea for the upstream kernel.

I'd think this is an out-of-tree patch for now. I'll talk with some
other people about their view, but I remain very sceptic.

> >> Another effect seems to be improving the init time of rcar_i2c_driver
> >> itself from ~7ms to ~1ms (assuming CONFIG_I2C_RCAR=y).
> > 
> > That doesn't help the patch much ;), but still interesting because I didn't
> > expect that. Do you have an idea why?

Still interested.



signature.asc
Description: PGP signature

Re: [PATCH] i2c: rcar: initialize earlier using subsys_initcall()

[Vladimir Zapolskiy]

Hi Wolfram,

On 04/03/2018 06:55 PM, Wolfram Sang wrote:
> Hi Vladimir and Eugeniu,
> 
>> The purpose of this patch looks pretty similar to:
>> 104522806a7d ("i2c: designware: dw_i2c_init_driver as subsys initcall")
>> 74f56c4ad4e4 ("i2c-bfin-twi: move setup to the earlier subsys initcall")
>> b8680784875b ("i2c-gpio: Move initialization code to subsys_initcall()")
>> 5d3f33318a6c ("[PATCH] i2c-imx: make bus available early")
>> ccb3bc16b489 ("i2c-sh_mobile: change module_init() to subsys_initcall()")
>> 18dc83a6ea48 ("i2c: i2c-s3c2410: Initialise Samsung I2C controller early")
>> 2514cca06be9 ("[ARM] 5394/1: Add static bus numbering support to 
>> i2c-versatile")
>> 47a9b1379a5e ("i2c-pxa: Initialize early")
>>
>> However, the story behind it might be a bit different.
> 
> It definately is. The above drivers are very old, from the days where
> -EPROBE_DEFER was non-existant. They needed subsys_initcall to be able
> to boot. The reason they still have it is simple: reverting to
> module_initcall could cause regressions.
> 
> This patch is about boot-time. Very different.
> 
>> Experimenting with async probing in various rcar-specific drivers (e.g.
>> rcar-du, vsp1, rcar-fcp, rcar-vin), it was noticed that in most of
>> the cases enabling async probing in one driver introduced some degree of
>> inconsistency in the initialization of other builtin drivers.
> 
> I have to admit I never played with async probing...
> 
>> To give an example, with pure sequential driver initialization, based
>> on 5 dmesg logs, the builtin kernel initialization deviation is
>> around +/- 5ms, whereas after enabling async probing in e.g. vsp1
>> driver, the variance is increased to sometimes +/- 80ms or more.
> 
> ... so I can't tell if there is something which can be fixed on the
> async probe side. I would naively think so.
> 
>> This patch fixes it and keeps the startup time consistent after
>> switching certain i2c-dependent drivers to asynchronous probing on
>> H3-es20-Salvator-X target.
> 
> I am not convinced "fix" is the right word here. Why is it not just a
> workaround? Are there no other possibilities? I know other solutions are
> usually complicated, but playing with init levels is fragile and caused
> circular dependencies in the past, so I really don't like them.

in summary (and according to my understanding, Eugeniu please feel free
to correct me) the actual product boards have multitude of I2C devices
connected to the master controller. It requires to read EDID to enable
video output or init sensors to get video input and so on, and normally
device drivers of endpoint devices are executed on module_init() level.

Thus putting an I2C master controller device driver to the same late
init level means that due to the concurrency there will be lots of
probe defers of endpoint device drivers, and making "heavy" device
drivers like rcar-vin to be run in asyncronous probe increases boot
time dispersion (rcar-vin is already probed, it's time to probe a
sensor, but I2C controller is not yet ready to operate, defer).

I don't suppose that the proposed change has any single negative
side effect, well, right, probe/remove code becomes more awkward,
but in general the expected effect to boot time improvement should
cover it, I hope.

>> Another effect seems to be improving the init time of rcar_i2c_driver
>> itself from ~7ms to ~1ms (assuming CONFIG_I2C_RCAR=y).
> 
> That doesn't help the patch much ;), but still interesting because I didn't
> expect that. Do you have an idea why?
> 

--
With best wishes,
Vladimir

Re: [PATCH] i2c: rcar: initialize earlier using subsys_initcall()

[Wolfram Sang]

Hi Vladimir and Eugeniu,

> The purpose of this patch looks pretty similar to:
> 104522806a7d ("i2c: designware: dw_i2c_init_driver as subsys initcall")
> 74f56c4ad4e4 ("i2c-bfin-twi: move setup to the earlier subsys initcall")
> b8680784875b ("i2c-gpio: Move initialization code to subsys_initcall()")
> 5d3f33318a6c ("[PATCH] i2c-imx: make bus available early")
> ccb3bc16b489 ("i2c-sh_mobile: change module_init() to subsys_initcall()")
> 18dc83a6ea48 ("i2c: i2c-s3c2410: Initialise Samsung I2C controller early")
> 2514cca06be9 ("[ARM] 5394/1: Add static bus numbering support to 
> i2c-versatile")
> 47a9b1379a5e ("i2c-pxa: Initialize early")
> 
> However, the story behind it might be a bit different.

It definately is. The above drivers are very old, from the days where
-EPROBE_DEFER was non-existant. They needed subsys_initcall to be able
to boot. The reason they still have it is simple: reverting to
module_initcall could cause regressions.

This patch is about boot-time. Very different.

> Experimenting with async probing in various rcar-specific drivers (e.g.
> rcar-du, vsp1, rcar-fcp, rcar-vin), it was noticed that in most of
> the cases enabling async probing in one driver introduced some degree of
> inconsistency in the initialization of other builtin drivers.

I have to admit I never played with async probing...

> To give an example, with pure sequential driver initialization, based
> on 5 dmesg logs, the builtin kernel initialization deviation is
> around +/- 5ms, whereas after enabling async probing in e.g. vsp1
> driver, the variance is increased to sometimes +/- 80ms or more.

... so I can't tell if there is something which can be fixed on the
async probe side. I would naively think so.

> This patch fixes it and keeps the startup time consistent after
> switching certain i2c-dependent drivers to asynchronous probing on
> H3-es20-Salvator-X target.

I am not convinced "fix" is the right word here. Why is it not just a
workaround? Are there no other possibilities? I know other solutions are
usually complicated, but playing with init levels is fragile and caused
circular dependencies in the past, so I really don't like them.

> Another effect seems to be improving the init time of rcar_i2c_driver
> itself from ~7ms to ~1ms (assuming CONFIG_I2C_RCAR=y).

That doesn't help the patch much ;), but still interesting because I didn't
expect that. Do you have an idea why?

Regards,

   Wolfram



signature.asc
Description: PGP signature

RE:Siemens touch panel linux-renesas-soc xzzhzwytzjenp7nsfssx

[SIMATIC]

Dear Sir/Madam： 
 
How are you today? This is Chris from Kernal Automation company, sending the 
best wish to you and wishing you all the best. 
We are a professional industry controller related company from Huizhou China, 
reselling well known brand original PLC, HMI, Inverter, Servo, Sensor and etc, 
such asSiemens,Mitsubishi,Omron,Koyo,Allen-Bradley,Proface,Weinview and etc.
Here are some hot-sale items for your reference:
Series  Model   Description New Price($)
SIMATIC HMI Basic Panels
(2nd Generation)6AV2123-2DB03-0AX0  KTP400 BASIC, KEY AND TOUCH 
OPERATION, 4"   $169.35
6AV2123-2GA03-0AX0  KTP700 BASIC DP, KEY AND TOUCH OPERATION, 7"
$360.16
6AV2123-2GB03-0AX0  KTP700 BASIC, KEY AND TOUCH OPERATION, 7"   
$360.16
6AV2123-2JB03-0AX0  KTP900 BASIC, KEY AND TOUCH OPERATION, 9"   
$558.87
6AV2123-2MA03-0AX0  KTP1200 BASIC DP, KEY AND TOUCH OPERATION, 12"  
$718.55
6AV2123-2MB03-0AX0  KTP1200 BASIC, KEY AND TOUCH OPERATION, 12" 
$718.55
Siemens Comfort Panel   6AV2124-2DC01-0AX0  KTP400 COMFORT,TOUCH AND KEY 
OPERATION,4"   $390.32
6AV2124-1DC01-0AX0  KP400 COMFORT,KEY OPERATION,4"  $390.32
6AV2124-0GC01-0AX0  TP700 COMFORT,TOUCH OPERATION,7"$631.61
6AV2124-1GC01-0AX0  KP700 COMFORT,KEY OPERATION,7"  $745.16
6AV2124-0JC01-0AX0  TP900 COMFORT,TOUCH OPERATION,9"
$1,348.39
6AV2124-1JC01-0AX0  KP900 COMFORT,KEY OPERATION,9"  $1,508.06
6AV2124-0MC01-0AX0  TP1200 COMFORT,TOUCH OPERATION,12"  
$1,579.03
6AV2124-1MC01-0AX0  KP1200 COMFORT,KEY OPERATION,12"
$1,650.00
6AV2124-0QC02-0AX0  TP1500 COMFORT,TOUCH OPERATION,15"  
$2,661.29

Thanks for viewing! 

Re: [PATCH v13 00/33] rcar-vin: Add Gen3 with media controller

[Laurent Pinchart]

Hi Hans,

On Tuesday, 3 April 2018 15:30:40 EEST Hans Verkuil wrote:
> On 26/03/18 23:44, Niklas Söderlund wrote:
> > Hi,
> > 
> > This series adds Gen3 VIN support to rcar-vin driver for Renesas r8a7795,
> > r8a7796 and r8a77970. It is based on the media-tree and depends on
> > Fabrizio Castro patches as they touches the order of the compatible
> > strings in the documentation to reduce merge conflicts. The dependencies
> > are included in this series.
> 
> Laurent, Kieran,
> 
> Unless there are any objections I want to make a pull request for this
> series once 4.17-rc1 has been merged back into our master tree. It all
> looks good to me, and it will be nice to get this in (finally!).
> 
> I don't want to postpone the pull request for small improvements, they
> can be applied later. But if there are more serious concerns, then let
> us know.

There's just a handful of patchs I haven't acked (but I have reviewed previous 
version) and I don't think there's any blocker there, small problems can 
always be fixed later. I'll still try to review them, and if I notice any 
issue I'll ask Niklas to submit follow-up patches. v13 can be merged upstream 
from my point of view. Thank you for handling this.

> > The driver is tested on Renesas H3 (r8a7795, ES2.0),
> > M3-W (r8a7796) together with the rcar-csi2 driver (posted separately and
> > not yet upstream) and the Salvator-X onboard ADV7482. It is also tested
> > on the V3M (r8a77970) on the Eagle board together with its expansion
> > board with a ADV7482 and out of tree patches for GMSL capture using the
> > max9286 and rdacm20 drivers.
> > 
> > It is possible to capture both CVBS and HDMI video streams,
> > v4l2-compliance passes with no errors and media-ctl can be used to
> > change the routing and formats for the different entities in the media
> > graph.
> > 
> > Gen2 compatibility is verified on Koelsch and no problems where found,
> > video can be captured just like before and v4l2-compliance passes
> > without errors or warnings just like before this series.
> > 
> > For convenience the series can be fetched from:
> >   git://git.ragnatech.se/linux rcar/vin/mc-v13
> > 
> > I have started on a very basic test suite for the VIN driver at:
> >   https://git.ragnatech.se/vin-tests
> > 
> > And as before the state of the driver and information about how to test
> > 
> > it can be found on the elinux wiki:
> >   http://elinux.org/R-Car/Tests:rcar-vin
> > 
> > * Changes from v12
> > - Rebase to latest media-tree/master changed a 'return ret' to a 'goto
> > 
> >   out' in rvin_start_streaming() to take recent changes to the VIN
> >   driver into account.
> > 
> > - Moved field != V4L2_FIELD_ANY in 'rcar-vin: set a default field to
> > 
> >   fallback on' check from a later commit 'rcar-vin: simplify how formats
> >   are set and reset' in the series. This is to avoid ignoring the field
> >   returned from the sensor if FIELD_ANY was requested by the user. This
> >   was only a problem between this change and a few patches later, but
> >   better to fix it now. Reported by Hans, thanks for spotting this.
> > 
> > - Fix spelling.
> > - Add review tags from Hans.
> > 
> > * Changes since v11
> > - Rewrote commit message for '[PATCH v11 22/32] rcar-vin: force default
> > 
> >   colorspace for media centric mode'. Also set fixed values for
> >   xfer_func, quantization and ycbcr_enc.
> > 
> > - Reorderd filed order in struct rvin_group_route.
> > - Renamed chan to channel in struct rvin_group_route.
> > - Rework 'rcar-vin: read subdevice format for crop only when
> > 
> >   needed' into 'rcar-vin: simplify how formats are set and reset'.
> > 
> > - Keep caching the source dimensions and drop all changes to
> > 
> >   rvin_g_selection() and rvin_s_selection().
> > 
> > - Inline rvin_get_vin_format_from_source() into rvin_reset_format()
> > 
> >   which now is the only user left.
> > 
> > - Add patch to cache the video standard instead of reading it at stream
> > 
> >   on.
> > 
> > - Fix error labels in rvin_mc_open().
> > - Fixed spelling in commit messages and comment, thanks Laurent!
> > - Added reviewed tags from Laurent, Thanks!
> > 
> > * Changes since v10
> > - Corrected spelling in comments and commit messages.
> > - Reworked 'rcar-vin: read subdevice format for crop only when needed'
> > 
> >   to only get the source format once per operation.
> > 
> > - Moved some patches around to make it easier to review, moved:
> > - rcar-vin: set a default field to fallback on
> > - rcar-vin: fix handling of single field frames (top, bottom and
> > alternate fields) - rcar-vin: update bytesperline and sizeimage
> > calculation
> > - rcar-vin: break out format alignment and checking
> > - rcar-vin: update pixelformat check for M1
> >   
> >   Before:
> > - rcar-vin: read subdevice format for crop only when needed
> > 
> > - Rename variable 'code' to 'mbus_code' in struct rvin_dev.
> > - Add comment describing no locking is needed in
> > 
> >  

Re: [PATCH v13 00/33] rcar-vin: Add Gen3 with media controller

[Kieran Bingham]

Hi Hans,

On 03/04/18 13:30, Hans Verkuil wrote:
> On 26/03/18 23:44, Niklas Söderlund wrote:
>> Hi,
>>
>> This series adds Gen3 VIN support to rcar-vin driver for Renesas r8a7795,
>> r8a7796 and r8a77970. It is based on the media-tree and depends on
>> Fabrizio Castro patches as they touches the order of the compatible
>> strings in the documentation to reduce merge conflicts. The dependencies
>> are included in this series.
> 
> Laurent, Kieran,
> 
> Unless there are any objections I want to make a pull request for this
> series once 4.17-rc1 has been merged back into our master tree. It all
> looks good to me, and it will be nice to get this in (finally!).
> 
> I don't want to postpone the pull request for small improvements, they
> can be applied later. But if there are more serious concerns, then let
> us know.

Certainly sounds good, and no objections from me.
Looking forward to getting this series in.

Thanks

Kieran


> Regards,
> 
>   Hans
> 
>>
>> The driver is tested on Renesas H3 (r8a7795, ES2.0),
>> M3-W (r8a7796) together with the rcar-csi2 driver (posted separately and
>> not yet upstream) and the Salvator-X onboard ADV7482. It is also tested
>> on the V3M (r8a77970) on the Eagle board together with its expansion
>> board with a ADV7482 and out of tree patches for GMSL capture using the
>> max9286 and rdacm20 drivers.
>>
>> It is possible to capture both CVBS and HDMI video streams,
>> v4l2-compliance passes with no errors and media-ctl can be used to
>> change the routing and formats for the different entities in the media
>> graph.
>>
>> Gen2 compatibility is verified on Koelsch and no problems where found,
>> video can be captured just like before and v4l2-compliance passes
>> without errors or warnings just like before this series.
>>
>> For convenience the series can be fetched from:
>>
>>   git://git.ragnatech.se/linux rcar/vin/mc-v13
>>
>> I have started on a very basic test suite for the VIN driver at:
>>
>>   https://git.ragnatech.se/vin-tests
>>
>> And as before the state of the driver and information about how to test
>> it can be found on the elinux wiki:
>>
>>   http://elinux.org/R-Car/Tests:rcar-vin
>>
>> * Changes from v12
>> - Rebase to latest media-tree/master changed a 'return ret' to a 'goto
>>   out' in rvin_start_streaming() to take recent changes to the VIN 
>>   driver into account.
>> - Moved field != V4L2_FIELD_ANY in 'rcar-vin: set a default field to  
>>   fallback on' check from a later commit 'rcar-vin: simplify how formats 
>>   are set and reset' in the series. This is to avoid ignoring the field 
>>   returned from the sensor if FIELD_ANY was requested by the user. This 
>>   was only a problem between this change and a few patches later, but 
>>   better to fix it now. Reported by Hans, thanks for spotting this.
>> - Fix spelling.
>> - Add review tags from Hans.
>>
>> * Changes since v11
>> - Rewrote commit message for '[PATCH v11 22/32] rcar-vin: force default
>>   colorspace for media centric mode'. Also set fixed values for
>>   xfer_func, quantization and ycbcr_enc.
>> - Reorderd filed order in struct rvin_group_route.
>> - Renamed chan to channel in struct rvin_group_route.
>> - Rework 'rcar-vin: read subdevice format for crop only when
>>   needed' into 'rcar-vin: simplify how formats are set and reset'.
>> - Keep caching the source dimensions and drop all changes to
>>   rvin_g_selection() and rvin_s_selection().
>> - Inline rvin_get_vin_format_from_source() into rvin_reset_format()
>>   which now is the only user left.
>> - Add patch to cache the video standard instead of reading it at stream
>>   on.
>> - Fix error labels in rvin_mc_open().
>> - Fixed spelling in commit messages and comment, thanks Laurent!
>> - Added reviewed tags from Laurent, Thanks!
>>
>> * Changes since v10
>> - Corrected spelling in comments and commit messages.
>> - Reworked 'rcar-vin: read subdevice format for crop only when needed'
>>   to only get the source format once per operation.
>> - Moved some patches around to make it easier to review, moved:
>> - rcar-vin: set a default field to fallback on
>> - rcar-vin: fix handling of single field frames (top, bottom and 
>> alternate fields)
>> - rcar-vin: update bytesperline and sizeimage calculation
>> - rcar-vin: break out format alignment and checking
>> - rcar-vin: update pixelformat check for M1
>>   Before:
>> - rcar-vin: read subdevice format for crop only when needed
>> - Rename variable 'code' to 'mbus_code' in struct rvin_dev.
>> - Add comment describing no locking is needed in
>>   rvin_set_channel_routing().
>> - Check return value of pm_runtime_get_sync() in
>>   rvin_set_channel_routing().
>> - Rework 'rcar-vin: add check for colorspace' to not try to check the
>>   format, instead force a default format. This should be revisited once
>>   either v4l2-compliance or v4l2 framework changes are worked out to
>>   allow for MC centric drivers to validate user supplied colorspace.
>> - Add 

renesas-drivers-2018-04-03-v4.16

[Geert Uytterhoeven]

I have pushed renesas-drivers-2018-04-03-v4.16 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.

Today's version is based on renesas-devel-20180330-v4.16-rc7.

Included branches with driver code:
  - clk-renesas
  - sh-pfc
  - topic/rcar-genpd-wakeup-v4
  - topic/rcar-gen2-wdt-v6
  - topic/bd9571-ddr-backup-mode-driver-v2
  - topic/bd9571-ddr-backup-mode-dt-v2
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/cpufreq-automatic
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/ipmmu-driver-v6
  - git://linuxtv.org/pinchartl/media.git#drm-du-iommu-v1-20171115
  - git://linuxtv.org/pinchartl/media.git#tags/vsp1-discom-v1-20171215
  - git://linuxtv.org/pinchartl/media.git#tags/drm-next-colorkey-v1-20171215
  - git://git.ragnatech.se/linux#for-renesas-drivers
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/vsp1/tlb-optimise/v7
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#d3/i2c-conflict/drm
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#d3/i2c-conflict/media
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/vsp1/du/interlaced/v2

Included fixes:
  - dmaengine: rcar-dmac: Fix too early/late system suspend/resume callbacks
  - [LOCAL] arm64: defconfig: Update renesas_defconfig

Included subsystem trees:
  - git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
  - git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
  - git://people.freedesktop.org/~airlied/linux#drm-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
  - git://linuxtv.org/mchehab/media-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
  - git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
  - git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
  - git://git.infradead.org/users/vkoul/slave-dma.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
  - git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
  - git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
  - git://github.com/bzolnier/linux.git#fbdev-for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
  - git://www.linux-watchdog.org/linux-watchdog-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
  - git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git#for-next

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/RFT v3 2/3] dt-bindings: thermal: rcar-thermal: add R8A77995 support

[Yoshihiro Kaneko]

Signed-off-by: Yoshihiro Kaneko 
Reviewed-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
index 349e635..5ab5fcd 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
@@ -3,7 +3,8 @@
 Required properties:
 - compatible   : "renesas,thermal-",
   "renesas,rcar-gen2-thermal" (with thermal-zone) or
-  "renesas,rcar-thermal" (without thermal-zone) as 
fallback.
+  "renesas,rcar-thermal" (without thermal-zone) as
+   fallback except R-Car D3.
  Examples with soctypes are:
- "renesas,thermal-r8a73a4" (R-Mobile APE6)
- "renesas,thermal-r8a7743" (RZ/G1M)
@@ -12,13 +13,15 @@ Required properties:
- "renesas,thermal-r8a7791" (R-Car M2-W)
- "renesas,thermal-r8a7792" (R-Car V2H)
- "renesas,thermal-r8a7793" (R-Car M2-N)
+   - "renesas,thermal-r8a77995" (R-Car D3)
 - reg  : Address range of the thermal registers.
  The 1st reg will be recognized as common register
  if it has "interrupts".
 
 Option properties:
 
-- interrupts   : use interrupt
+- interrupts   : use interrupt.
+  Should contain 3 interrupts for R-Car D3.
 
 Example (non interrupt support):
 
-- 
1.9.1

[PATCH/RFT v3 3/3] arm64: dts: renesas: r8a77995: add thermal device support

[Yoshihiro Kaneko]

Signed-off-by: Yoshihiro Kaneko 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index cff42cd..9a52b41 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -636,5 +636,35 @@
#phy-cells = <0>;
status = "disabled";
};
+
+   thermal: thermal@e619 {
+   compatible = "renesas,thermal-r8a77995";
+   reg = <0 0xe619 0 0x10>, <0 0xe6190100 0 0x38>;
+   interrupts = ,
+,
+;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 522>;
+   #thermal-sensor-cells = <0>;
+   };
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+   thermal-sensors = <>;
+
+   trips {
+   cpu-crit {
+   temperature = <12>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   cooling-maps {
+   };
+   };
};
 };
-- 
1.9.1

[PATCH/RFT v3 0/3] thermal: add support for r8a77995

[Yoshihiro Kaneko]

This series adds thermal support for r8a77995.
R-Car D3 (r8a77995) have a thermal sensor module which is similar to Gen2.
Therefore this series adds r8a77995 support to rcar_thermal driver not
rcar_gen3_thermal driver.

This series is based on the next branch of Zhang Rui's linux tree.

v3 [Yoshihiro Kaneko]
* As suggested by Geert Uytterhoeven
rcar_thermal.c:
- make use_of_thermal in structure rcar_thermal_chip a single bit
- add feature bits to rcar_thermal_chip
- add the number of interrupts to rcar_thermal_chip
- remove rcar_thermal_type in rcar_thermal_cip
- make variable chip in rcar_thermal_probe() a const

rcar-thermal.txt:
* No change

r8a77995.dtsi:
* No change


v2 [Yoshihiro Kaneko]
* As suggested by Geert Uytterhoeven
rcar_thermal.c:
- remove rcar_of_data macro
- store a pointer to rcar_thermal_chip in rcar_thermal_priv
- remove unnecessary cast in rcar_thermal_dt_ids

rcar-thermal.txt:
- drop the fallback for D3
- update the paragraph about interrupts

r8a77995.dtsi:
- fix the base address and the register addresses
- drop the fallback

Yoshihiro Kaneko (3):
  thermal: rcar_thermal: add r8a77995 support
  dt-bindings: thermal: rcar-thermal: add R8A77995 support
  arm64: dts: renesas: r8a77995: add thermal device support

 .../devicetree/bindings/thermal/rcar-thermal.txt   |   7 +-
 arch/arm64/boot/dts/renesas/r8a77995.dtsi  |  30 
 drivers/thermal/rcar_thermal.c | 154 -
 3 files changed, 157 insertions(+), 34 deletions(-)

-- 
1.9.1

[PATCH/RFT v3 1/3] thermal: rcar_thermal: add r8a77995 support

[Yoshihiro Kaneko]

Add support for R-Car D3 (r8a77995) thermal sensor.

Signed-off-by: Yoshihiro Kaneko 
---
 drivers/thermal/rcar_thermal.c | 154 -
 1 file changed, 122 insertions(+), 32 deletions(-)

diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 73e5fee..5ec47a9 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -58,10 +58,43 @@ struct rcar_thermal_common {
spinlock_t lock;
 };
 
+struct rcar_thermal_chip {
+   unsigned int use_of_thermal : 1;
+   unsigned int has_filonoff : 1;
+   unsigned int irq_per_ch : 1;
+   unsigned int needs_suspend_resume : 1;
+   unsigned int nirqs;
+};
+
+static const struct rcar_thermal_chip rcar_thermal = {
+   .use_of_thermal = 0,
+   .has_filonoff = 1,
+   .irq_per_ch = 0,
+   .needs_suspend_resume = 0,
+   .nirqs = 1,
+};
+
+static const struct rcar_thermal_chip rcar_gen2_thermal = {
+   .use_of_thermal = 1,
+   .has_filonoff = 1,
+   .irq_per_ch = 0,
+   .needs_suspend_resume = 0,
+   .nirqs = 1,
+};
+
+static const struct rcar_thermal_chip rcar_gen3_thermal = {
+   .use_of_thermal = 1,
+   .has_filonoff = 0,
+   .irq_per_ch = 1,
+   .needs_suspend_resume = 1,
+   .nirqs = 2,
+};
+
 struct rcar_thermal_priv {
void __iomem *base;
struct rcar_thermal_common *common;
struct thermal_zone_device *zone;
+   const struct rcar_thermal_chip *chip;
struct delayed_work work;
struct mutex lock;
struct list_head list;
@@ -77,13 +110,20 @@ struct rcar_thermal_priv {
 #define rcar_priv_to_dev(priv) ((priv)->common->dev)
 #define rcar_has_irq_support(priv) ((priv)->common->base)
 #define rcar_id_to_shift(priv) ((priv)->id * 8)
-#define rcar_of_data(dev)  ((unsigned 
long)of_device_get_match_data(dev))
-#define rcar_use_of_thermal(dev)   (rcar_of_data(dev) == USE_OF_THERMAL)
 
-#define USE_OF_THERMAL 1
 static const struct of_device_id rcar_thermal_dt_ids[] = {
-   { .compatible = "renesas,rcar-thermal", },
-   { .compatible = "renesas,rcar-gen2-thermal", .data = (void 
*)USE_OF_THERMAL },
+   {
+   .compatible = "renesas,rcar-thermal",
+   .data = _thermal,
+   },
+   {
+   .compatible = "renesas,rcar-gen2-thermal",
+.data = _gen2_thermal,
+   },
+   {
+   .compatible = "renesas,thermal-r8a77995",
+   .data = _gen3_thermal,
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
@@ -190,7 +230,8 @@ static int rcar_thermal_update_temp(struct 
rcar_thermal_priv *priv)
 * enable IRQ
 */
if (rcar_has_irq_support(priv)) {
-   rcar_thermal_write(priv, FILONOFF, 0);
+   if (priv->chip->has_filonoff)
+   rcar_thermal_write(priv, FILONOFF, 0);
 
/* enable Rising/Falling edge interrupt */
rcar_thermal_write(priv, POSNEG,  0x1);
@@ -420,7 +461,7 @@ static int rcar_thermal_remove(struct platform_device *pdev)
 
rcar_thermal_for_each_priv(priv, common) {
rcar_thermal_irq_disable(priv);
-   if (rcar_use_of_thermal(dev))
+   if (priv->chip->use_of_thermal)
thermal_remove_hwmon_sysfs(priv->zone);
else
thermal_zone_device_unregister(priv->zone);
@@ -438,6 +479,7 @@ static int rcar_thermal_probe(struct platform_device *pdev)
struct rcar_thermal_priv *priv;
struct device *dev = >dev;
struct resource *res, *irq;
+   const struct rcar_thermal_chip *chip = of_device_get_match_data(dev);
int mres = 0;
int i;
int ret = -ENODEV;
@@ -457,19 +499,35 @@ static int rcar_thermal_probe(struct platform_device 
*pdev)
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
 
-   irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-   if (irq) {
-   /*
-* platform has IRQ support.
-* Then, driver uses common registers
-* rcar_has_irq_support() will be enabled
-*/
-   res = platform_get_resource(pdev, IORESOURCE_MEM, mres++);
-   common->base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(common->base))
-   return PTR_ERR(common->base);
+   for (i = 0; i < chip->nirqs; i++) {
+   irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+   if (!irq)
+   continue;
+   if (!common->base) {
+   /*
+* platform has IRQ support.
+* Then, driver uses common registers
+* rcar_has_irq_support() will be enabled
+*/
+   res = 

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Rob,
sorry for pointing to you directly :)

On Mon, Apr 02, 2018 at 04:36:55PM +0300, Laurent Pinchart wrote:
> Hi Vladimir,
>
> On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote:
> > On 03/27/2018 01:10 PM, jacopo mondi wrote:
> > > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> > >> On 03/27/2018 11:57 AM, jacopo mondi wrote:
> > >>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:

[snip]

> > >>
> > >>> +- pdwn-gpios: Power down GPIO signal. Active low
> > >
> > > powerdown-gpios is the semi-standard name.
> > 
> >  right, I've also noticed it. If possible please avoid shortenings
> >  in property names.
> > >>>
> > >>> It is not shortening, it just follow pin name from decoder's
> > >>> datasheet.
> > >>>
> > >>> +- oe-gpios: Output enable GPIO signal. Active high
> > >>> +
> > 
> >  And this one is also a not ever met property name, please consider
> >  to rename it to 'enable-gpios', for instance display panels define
> >  it.
> > >>>
> > >>> Again, it follows datasheet naming scheme. Has something changed in
> > >>> DT conventions?
> > >>
> > >> Seconded. My understanding is that the property name should reflect
> > >> what reported in the the chip manual. For THC63LVD1024 the enable and
> > >> power down pins are named 'OE' and 'PDWN' respectively.
> > >>
> > > But don't we need the vendor prefix in the prop names then, like
> > > "renesas,oe-gpios" then?
> > 
> >  Seconded, with a correction to "thine,oe-gpios".
> > >>>
> > >>> mmm, okay then...
> > >>>
> > >>> A grep for that semi-standard properties names in Documentation/
> > >>> returns only usage examples and no actual definitions, so I assume this
> > >>> is why they are semi-standard.
> > >>
> > >> Here we have to be specific about a particular property, let it be
> > >> 'oe-gpios' vs. 'enable-gpios' and let's collect some statistics:
> > >>
> > >> % grep -Hr oe-gpios Documentation/devicetree/bindings/* | wc -l
> > >> 0
> > >>
> > >> $ grep -Hr enable-gpios Documentation/devicetree/bindings/* | wc -l
> > >> 86
> > >>
> > >> While 'thine,oe-gpios' would be correct, I see no reason to introduce a
> > >> vendor specific property to define a pin with a common and well
> > >> understood purpose.
> > >>
> > >> If you go forward with the vendor specific prefix, apparently you can set
> > >> the name to 'thine,oe-gpio' (single) or even to 'thine,oe', or does the
> > >> datasheet names the pin as "OE GPIO" or "OE connected to a GPIO"? I
> > >> guess no.
> > >
> > > Let me clarify I don't want to push for a vendor specific name or
> > > similar, I'm fine with using 'semi-standard' names, I'm just confused
> > > by the 'semi-standard' definition. I guess from your examples, the
> > > usage count makes a difference here.
> >
> > yes, in gneneral you can read "semi-standard" as "widely used", thus
> > collecting statistics is a good enough method to make a reasoning.
> >
> > Hopefully the next evolutionary step of "widely used" is "described in
> > standard".
> >
> > >> Standards do not define '-gpios' suffix, but partially the description is
> > >> found in Documentation/bindings/gpio/gpio.txt, still it is not a section
> > >> in any standard as far as I know.
> > >>
> > >>> Seems like there is some tribal knowledge involved in defining what
> > >>> is semi-standard and what's not, or are those properties documented
> > >>> somewhere?
> > >>
> > >> The point is that there is no formal standard which describes every IP,
> > >> every IC and every single their property, some device node names and
> > >> property names are recommended in ePAPR and Devicetree Specification
> > >> though.
> > >>
> > >> Think of a confusion if 'rst-gpios' (have you seen any ICs with an RST
> > >> pin?) and 'reset-gpios' are different. Same applies to 'pdwn-gpios' vs.
> > >> 'powerdown-gpios'.
> > >
> > > I see all your points and I agree with most of them. Anyway, if the
> > > chip manual describes a pin as 'RST' I would not find it confusing to
> > > have a 'rst-gpio' defined in bindings :)
> > >
> > > Let me be a bit pesky here: what if a chip defines a reset GPIO, which
> > > is definitely a reset, but names it, say "XYZ" ? Would you prefer to
> > > see it defined as "reset-gpios" for consistency with other bindings,
> > > or "xyz-gpios" for consistency with documentation?
> >
> > If a pin is definitely an IC reset as you said, then my preference is to see
> > it described under 'reset-gpios' property name, plus a comment in the IC
> > device tree documentation document about it. I can provide two reasons to
> > advocate my position:
> >
> > 1) developers spend significantly more time reading and editing the actual
> >DTSI/DTS board files rather than reading and editing documentation,
> >it makes sense to use common property names to 

Re: [PATCH v13 00/33] rcar-vin: Add Gen3 with media controller

[Hans Verkuil]

On 26/03/18 23:44, Niklas Söderlund wrote:
> Hi,
> 
> This series adds Gen3 VIN support to rcar-vin driver for Renesas r8a7795,
> r8a7796 and r8a77970. It is based on the media-tree and depends on
> Fabrizio Castro patches as they touches the order of the compatible
> strings in the documentation to reduce merge conflicts. The dependencies
> are included in this series.

Laurent, Kieran,

Unless there are any objections I want to make a pull request for this
series once 4.17-rc1 has been merged back into our master tree. It all
looks good to me, and it will be nice to get this in (finally!).

I don't want to postpone the pull request for small improvements, they
can be applied later. But if there are more serious concerns, then let
us know.

Regards,

Hans

> 
> The driver is tested on Renesas H3 (r8a7795, ES2.0),
> M3-W (r8a7796) together with the rcar-csi2 driver (posted separately and
> not yet upstream) and the Salvator-X onboard ADV7482. It is also tested
> on the V3M (r8a77970) on the Eagle board together with its expansion
> board with a ADV7482 and out of tree patches for GMSL capture using the
> max9286 and rdacm20 drivers.
> 
> It is possible to capture both CVBS and HDMI video streams,
> v4l2-compliance passes with no errors and media-ctl can be used to
> change the routing and formats for the different entities in the media
> graph.
> 
> Gen2 compatibility is verified on Koelsch and no problems where found,
> video can be captured just like before and v4l2-compliance passes
> without errors or warnings just like before this series.
> 
> For convenience the series can be fetched from:
> 
>   git://git.ragnatech.se/linux rcar/vin/mc-v13
> 
> I have started on a very basic test suite for the VIN driver at:
> 
>   https://git.ragnatech.se/vin-tests
> 
> And as before the state of the driver and information about how to test
> it can be found on the elinux wiki:
> 
>   http://elinux.org/R-Car/Tests:rcar-vin
> 
> * Changes from v12
> - Rebase to latest media-tree/master changed a 'return ret' to a 'goto
>   out' in rvin_start_streaming() to take recent changes to the VIN 
>   driver into account.
> - Moved field != V4L2_FIELD_ANY in 'rcar-vin: set a default field to  
>   fallback on' check from a later commit 'rcar-vin: simplify how formats 
>   are set and reset' in the series. This is to avoid ignoring the field 
>   returned from the sensor if FIELD_ANY was requested by the user. This 
>   was only a problem between this change and a few patches later, but 
>   better to fix it now. Reported by Hans, thanks for spotting this.
> - Fix spelling.
> - Add review tags from Hans.
> 
> * Changes since v11
> - Rewrote commit message for '[PATCH v11 22/32] rcar-vin: force default
>   colorspace for media centric mode'. Also set fixed values for
>   xfer_func, quantization and ycbcr_enc.
> - Reorderd filed order in struct rvin_group_route.
> - Renamed chan to channel in struct rvin_group_route.
> - Rework 'rcar-vin: read subdevice format for crop only when
>   needed' into 'rcar-vin: simplify how formats are set and reset'.
> - Keep caching the source dimensions and drop all changes to
>   rvin_g_selection() and rvin_s_selection().
> - Inline rvin_get_vin_format_from_source() into rvin_reset_format()
>   which now is the only user left.
> - Add patch to cache the video standard instead of reading it at stream
>   on.
> - Fix error labels in rvin_mc_open().
> - Fixed spelling in commit messages and comment, thanks Laurent!
> - Added reviewed tags from Laurent, Thanks!
> 
> * Changes since v10
> - Corrected spelling in comments and commit messages.
> - Reworked 'rcar-vin: read subdevice format for crop only when needed'
>   to only get the source format once per operation.
> - Moved some patches around to make it easier to review, moved:
> - rcar-vin: set a default field to fallback on
> - rcar-vin: fix handling of single field frames (top, bottom and 
> alternate fields)
> - rcar-vin: update bytesperline and sizeimage calculation
> - rcar-vin: break out format alignment and checking
> - rcar-vin: update pixelformat check for M1
>   Before:
> - rcar-vin: read subdevice format for crop only when needed
> - Rename variable 'code' to 'mbus_code' in struct rvin_dev.
> - Add comment describing no locking is needed in
>   rvin_set_channel_routing().
> - Check return value of pm_runtime_get_sync() in
>   rvin_set_channel_routing().
> - Rework 'rcar-vin: add check for colorspace' to not try to check the
>   format, instead force a default format. This should be revisited once
>   either v4l2-compliance or v4l2 framework changes are worked out to
>   allow for MC centric drivers to validate user supplied colorspace.
> - Add error checking for pm_runtime_get_sync() and
>   v4l2_pipeline_pm_use().
> - Change mutex_lock() to mutex_lock_interruptible() in rvin_mc_open().
> - Rewrote documentation for struct rvin_group_route.
> - Rename rvin_mc_parse_v4l2() to rvin_mc_parse_of_endpoint().

Re: [PATCH 4/5] clk: renesas: r8a7792: Fix LB clock divider

[Geert Uytterhoeven]

Hi Fabrizio,

On Tue, Apr 3, 2018 at 12:17 PM, Fabrizio Castro
 wrote:
>> Subject: [PATCH 4/5] clk: renesas: r8a7792: Fix LB clock divider
>>
>> The CLK_TYPE_GEN2_LB clock type is meant for SoCs like R-Car H2, where
>> the LB clock divider depends on the value of the MD18 pin.
>>
>> On R-Car V2H, the LB clock divider is fixed to 24.  Hence model the
>> clock as a fixed factor clock instead.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>>  drivers/clk/renesas/r8a7792-cpg-mssr.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/renesas/r8a7792-cpg-mssr.c 
>> b/drivers/clk/renesas/r8a7792-cpg-mssr.c
>> index 609a540804965c40..8b66e6f4b4584de1 100644
>> --- a/drivers/clk/renesas/r8a7792-cpg-mssr.c
>> +++ b/drivers/clk/renesas/r8a7792-cpg-mssr.c
>> @@ -53,7 +53,6 @@ static const struct cpg_core_clk r8a7792_core_clks[] 
>> __initconst = {
>>  DEF_FIXED(".pll1_div2", CLK_PLL1_DIV2, CLK_PLL1, 2, 1),
>>
>>  /* Core Clock Outputs */
>> -DEF_BASE("lb",   R8A7792_CLK_LB,   CLK_TYPE_GEN2_LB,   CLK_PLL1),
>>  DEF_BASE("qspi", R8A7792_CLK_QSPI, CLK_TYPE_GEN2_QSPI, CLK_PLL1_DIV2),
>>
>>  DEF_FIXED("z",  R8A7792_CLK_Z, CLK_PLL0,  1, 1),
>> @@ -63,6 +62,7 @@ static const struct cpg_core_clk r8a7792_core_clks[] 
>> __initconst = {
>>  DEF_FIXED("hp", R8A7792_CLK_HP,CLK_PLL1, 12, 1),
>>  DEF_FIXED("i",  R8A7792_CLK_I, CLK_PLL1,  3, 1),
>>  DEF_FIXED("b",  R8A7792_CLK_B, CLK_PLL1, 12, 1),
>> +DEF_FIXED("lb", R8A7792_CLK_B, CLK_PLL1, 24, 1),
>
> s/ R8A7792_CLK_B/ R8A7792_CLK_LB/
>
> With that fixed:
> Reviewed-by: Fabrizio Castro 

Thanks, nice catch. Fixing up (also for r8a7794).

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v2 3/8] clk: renesas: Add r8a77470 CPG Core Clock Definitions

[Geert Uytterhoeven]

Hi Biju,

On Wed, Mar 28, 2018 at 9:26 PM, Biju Das  wrote:
> Add all RZ/G1C Clock Pulse Generator Core Clock Outputs, as listed in
> Table 7.2 ("List of Clocks [RZ/G1C]") of the RZ/G1C Hardware User's
> Manual.
>
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 
> Reviewed-by: Geert Uytterhoeven 
> ---
> V1->V2:
> * incorporated geert's review comment
>
>  include/dt-bindings/clock/r8a77470-cpg-mssr.h | 36 
> +++
>  1 file changed, 36 insertions(+)
>  create mode 100644 include/dt-bindings/clock/r8a77470-cpg-mssr.h
>
> diff --git a/include/dt-bindings/clock/r8a77470-cpg-mssr.h 
> b/include/dt-bindings/clock/r8a77470-cpg-mssr.h
> new file mode 100644
> index 000..ffc123c
> --- /dev/null
> +++ b/include/dt-bindings/clock/r8a77470-cpg-mssr.h
> @@ -0,0 +1,36 @@
> +/* SPDX-License-Identifier: GPL-2.0
> + *
> + * Copyright (C) 2018 Renesas Electronics Corp.
> + */
> +#ifndef __DT_BINDINGS_CLOCK_R8A77470_CPG_MSSR_H__
> +#define __DT_BINDINGS_CLOCK_R8A77470_CPG_MSSR_H__
> +
> +#include 
> +
> +/* r8a77470 CPG Core Clocks */
> +#define R8A77470_CLK_Z20
> +#define R8A77470_CLK_ZTR   2

These should be numbered consecutively, unless there is a good reason not
to do so.

Sorry for not noticing before, fixing up while applying...

> +#define R8A77470_CLK_ZTRD2 3
> +#define R8A77470_CLK_ZT4
> +#define R8A77470_CLK_ZX5
> +#define R8A77470_CLK_ZS6
> +#define R8A77470_CLK_HP7
> +#define R8A77470_CLK_B 9
> +#define R8A77470_CLK_LB10
> +#define R8A77470_CLK_P 11
> +#define R8A77470_CLK_CL12
> +#define R8A77470_CLK_CP13
> +#define R8A77470_CLK_M214
> +#define R8A77470_CLK_ZB3   16
> +#define R8A77470_CLK_SDH   19
> +#define R8A77470_CLK_SD0   20
> +#define R8A77470_CLK_SD1   21
> +#define R8A77470_CLK_SD2   22
> +#define R8A77470_CLK_MP24
> +#define R8A77470_CLK_QSPI  25
> +#define R8A77470_CLK_CPEX  26
> +#define R8A77470_CLK_RCAN  27
> +#define R8A77470_CLK_R 28
> +#define R8A77470_CLK_OSC   29

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 v3 3/3] ARM: dts: iwg23s-sbc: Add support for iWave G23S-SBC based on RZ/G1C

[Biju Das]

Add support for iWave iW-RainboW-G23S single board computer based on
 RZ/G1C.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
Reviewed-by: Geert Uytterhoeven 
---
V1->V2:
* Incorporated review comments
V2->V3:
* No Change

 arch/arm/boot/dts/Makefile|  1 +
 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 35 +++
 2 files changed, 36 insertions(+)
 create mode 100644 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 2b6dfee..4291638 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -781,6 +781,7 @@ dtb-$(CONFIG_ARCH_RENESAS) += \
r8a7745-iwg22d-sodimm.dtb \
r8a7745-iwg22d-sodimm-dbhd-ca.dtb \
r8a7745-sk-rzg1e.dtb \
+   r8a77470-iwg23s-sbc.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts 
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
new file mode 100644
index 000..d21baad
--- /dev/null
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the iWave-RZ/G1C single board computer
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+#include "r8a77470.dtsi"
+/ {
+   model = "iWave iW-RainboW-G23S single board computer based on RZ/G1C";
+   compatible = "iwave,g23s", "renesas,r8a77470";
+
+   aliases {
+   serial1 = 
+   };
+
+   chosen {
+   bootargs = "ignore_loglevel";
+   stdout-path = "serial1:115200n8";
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x2000>;
+   };
+};
+
+_clk {
+   clock-frequency = <2000>;
+};
+
+ {
+   status = "okay";
+};
-- 
2.7.4

[PATCH v3 0/3] Add r8a77470/iW-RainboW-G23S single board computer support

[Biju Das]

Hello, 

This series adds support for Rensas RZ/G1C (r8a77470) SoC and
RZ/G1C based iW-RainboW-G23S single board computer.

The series introduces a cpg-mssr clock/power gating module, a power/reset
controller for the SoC.

power areas for RZ/G1C are similar to RZ/G1E.

Few functionalities have currently been enabled in DTS and tested: serial
boot console.

This patch series tested against renesas-dev branch 
tag "renesas-dev-20180328-v4.16-rc7

V1-->V2
Incorporated geert's review comments.
V2-->V3
Incorporated simon and geert's review comments.

Biju Das (3):
  serial: sh-sci: Document r8a77470 bindings
  ARM: dts: r8a77470: Initial SoC device tree
  ARM: dts: iwg23s-sbc: Add support for iWave G23S-SBC based on RZ/G1C

 .../bindings/serial/renesas,sci-serial.txt |   2 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts  |  35 +
 arch/arm/boot/dts/r8a77470.dtsi| 154 +
 4 files changed, 192 insertions(+)
 create mode 100644 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
 create mode 100644 arch/arm/boot/dts/r8a77470.dtsi

-- 
2.7.4

[PATCH v3 1/3] serial: sh-sci: Document r8a77470 bindings

[Biju Das]

RZ/G1C (R8A77470) SoC also has the R-Car gen2 compatible SCIF and HSCIF
ports, so document the SoC specific bindings.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
---
V1->V2:
* No Change
V2->V3:
* No Change

 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt 
b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index cf504d0..1c90d2c 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -17,6 +17,8 @@ Required properties:
 - "renesas,scifa-r8a7745" for R8A7745 (RZ/G1E) SCIFA compatible UART.
 - "renesas,scifb-r8a7745" for R8A7745 (RZ/G1E) SCIFB compatible UART.
 - "renesas,hscif-r8a7745" for R8A7745 (RZ/G1E) HSCIF compatible UART.
+- "renesas,scif-r8a77470" for R8A77470 (RZ/G1C) SCIF compatible UART.
+- "renesas,hscif-r8a77470" for R8A77470 (RZ/G1C) HSCIF compatible UART.
 - "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART.
 - "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART.
 - "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART.
-- 
2.7.4

[PATCH v3 2/3] ARM: dts: r8a77470: Initial SoC device tree

[Biju Das]

The initial R8A77470 SoC device tree including CPU0, GIC, timer, SYSC, RST,
CPG, and the required clock descriptions.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
Reviewed-by: Geert Uytterhoeven 
---
V1->V2:
* Incorporated geert's review comment
* Moved prr node inside soc node.
V2->V3:
* Incorporated simon and geert's review comment

 arch/arm/boot/dts/r8a77470.dtsi | 154 
 1 file changed, 154 insertions(+)
 create mode 100644 arch/arm/boot/dts/r8a77470.dtsi

diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
new file mode 100644
index 000..4578582
--- /dev/null
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the r8a77470 SoC
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+
+#include 
+#include 
+#include 
+/ {
+   compatible = "renesas,r8a77470";
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0>;
+   clock-frequency = <10>;
+   clocks = < CPG_CORE 0>;
+   power-domains = < 5>;
+   next-level-cache = <_CA7>;
+   };
+
+
+   L2_CA7: cache-controller-0 {
+   compatible = "cache";
+   cache-unified;
+   cache-level = <2>;
+   power-domains = < 21>;
+   };
+   };
+
+   /* External root clock */
+   extal_clk: extal {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   /* This value must be overridden by the board. */
+   clock-frequency = <0>;
+   };
+
+   /* External SCIF clock */
+   scif_clk: scif {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   /* This value must be overridden by the board. */
+   clock-frequency = <0>;
+   };
+
+   soc {
+   compatible = "simple-bus";
+   interrupt-parent = <>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   cpg: clock-controller@e615 {
+   compatible = "renesas,r8a77470-cpg-mssr";
+   reg = <0 0xe615 0 0x1000>;
+   clocks = <_clk>, <_extal_clk>;
+   clock-names = "extal", "usb_extal";
+   #clock-cells = <2>;
+   #power-domain-cells = <0>;
+   #reset-cells = <1>;
+   };
+
+   rst: reset-controller@e616 {
+   compatible = "renesas,r8a77470-rst";
+   reg = <0 0xe616 0 0x100>;
+   };
+
+   sysc: system-controller@e618 {
+   compatible = "renesas,r8a77470-sysc";
+   reg = <0 0xe618 0 0x200>;
+   #power-domain-cells = <1>;
+   };
+
+   icram0: sram@e63a {
+   compatible = "mmio-sram";
+   reg = <0 0xe63a 0 0x12000>;
+   };
+
+   icram1: sram@e63c {
+   compatible = "mmio-sram";
+   reg = <0 0xe63c 0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0 0xe63c 0x1000>;
+
+   smp-sram@0 {
+   compatible = "renesas,smp-sram";
+   reg = <0 0x100>;
+   };
+   };
+
+   icram2: sram@e630 {
+   compatible = "mmio-sram";
+   reg = <0 0xe630 0 0x2>;
+   };
+
+   scif1: serial@e6e68000 {
+   compatible = "renesas,scif-r8a77470",
+"renesas,rcar-gen2-scif", "renesas,scif";
+   reg = <0 0xe6e68000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 720>,
+< CPG_CORE 6>, <_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   power-domains = < 32>;
+   resets = < 720>;
+   status = "disabled";
+   };
+
+   gic: interrupt-controller@f1001000 {
+   compatible = "arm,gic-400";
+   #interrupt-cells = <3>;
+   

Re: [PATCH/RFT v2 1/3] thermal: rcar_thermal: add r8a77995 support

[Yoshihiro Kaneko]

Hi Geert-san,

2018-03-30 18:25 GMT+09:00 Geert Uytterhoeven :
> Hi Kaneko-san,
>
> On Fri, Mar 30, 2018 at 5:13 AM, Yoshihiro Kaneko  
> wrote:
>> Add support for R-Car D3 (r8a77995) thermal sensor.
>>
>> Signed-off-by: Yoshihiro Kaneko 
>
> Thanks for your patch!
>
>> --- a/drivers/thermal/rcar_thermal.c
>> +++ b/drivers/thermal/rcar_thermal.c
>> @@ -58,10 +58,35 @@ struct rcar_thermal_common {
>> spinlock_t lock;
>>  };
>>
>> +enum rcar_thermal_type {
>> +   RCAR_THERMAL,
>> +   RCAR_GEN2_THERMAL,
>> +   RCAR_GEN3_THERMAL,
>> +};
>> +
>> +struct rcar_thermal_chip {
>> +   int use_of_thermal;
>
> This can be a single bit:
>
> unsigned int use_of_thermal : 1;
>
>> +   enum rcar_thermal_type type;
>
> If you would add feature bits, you can get rid of rcar_thermal_type:
>
> unsigned int has_filonoff : 1;
> unsigned int has_enr : 1;
> unsigned int needs_suspend_resume : 1;
>
> The number of interrupts can be stored here, too.

It's nice!

>
>> +};
>> +
>> +static const struct rcar_thermal_chip rcar_thermal = {
>> +   .use_of_thermal = 0,
>> +   .type = RCAR_THERMAL,
>
> .has_filonoff = 1,
> .has_enr = 0,
> ...
> .nirqs = 1,
>
>> @@ -190,7 +222,8 @@ static int rcar_thermal_update_temp(struct 
>> rcar_thermal_priv *priv)
>>  * enable IRQ
>>  */
>> if (rcar_has_irq_support(priv)) {
>> -   rcar_thermal_write(priv, FILONOFF, 0);
>> +   if (priv->chip->type != RCAR_GEN3_THERMAL)
>
> if (priv->chip->has_filonoff)
>
>> @@ -438,6 +471,9 @@ static int rcar_thermal_probe(struct platform_device 
>> *pdev)
>> struct rcar_thermal_priv *priv;
>> struct device *dev = >dev;
>> struct resource *res, *irq;
>> +   struct rcar_thermal_chip *chip = ((struct rcar_thermal_chip *)
>
> I don't think the cast is needed.

I will make 'chip' a const variable.

>
>> @@ -457,19 +493,35 @@ static int rcar_thermal_probe(struct platform_device 
>> *pdev)
>> pm_runtime_enable(dev);
>> pm_runtime_get_sync(dev);
>>
>> -   irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> -   if (irq) {
>> -   /*
>> -* platform has IRQ support.
>> -* Then, driver uses common registers
>> -* rcar_has_irq_support() will be enabled
>> -*/
>> -   res = platform_get_resource(pdev, IORESOURCE_MEM, mres++);
>> -   common->base = devm_ioremap_resource(dev, res);
>> -   if (IS_ERR(common->base))
>> -   return PTR_ERR(common->base);
>> +   for (i = 0; i < nirq; i++) {
>
> for (i = 0; i < priv->nirqs; i++) {


Best regards,
Kaneko

>
> 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/RFT v2 0/3] thermal: add support for r8a77995

[Yoshihiro Kaneko]

Hi Simon-san,

2018-03-30 22:49 GMT+09:00 Simon Horman :
> On Fri, Mar 30, 2018 at 12:13:00PM +0900, Yoshihiro Kaneko wrote:
>> This series adds thermal support for r8a77995.
>> R-Car D3 (r8a77995) have a thermal sensor module which is similar to Gen2.
>> Therefore this series adds r8a77995 support to rcar_thermal driver not
>> rcar_gen3_thermal driver.
>>
>> This series is based on the next branch of Zhang Rui's linux tree.
>
> I have very lightly tested this as follows after enabling
> CONFIG_RCAR_THERMAL in the kernel .config.
>
> # cat /sys/devices/virtual/thermal/thermal_zone0/temp
> 4

Thanks for the testing.
Probably 40C is reasonable, is not?


Best regards,
Kaneko

RE: [PATCH 5/5] clk: renesas: r8a7794: Fix LB clock divider

[Fabrizio Castro]

Hello Geert,

> Subject: [PATCH 5/5] clk: renesas: r8a7794: Fix LB clock divider
>
> The CLK_TYPE_GEN2_LB clock type is meant for SoCs like R-Car H2, where
> the LB clock divider depends on the value of the MD18 pin.
>
> On R-Car E2, the LB clock divider is fixed to 24.  Hence model the clock
> as a fixed factor clock instead.
>
> Signed-off-by: Geert Uytterhoeven 
> ---
>  drivers/clk/renesas/r8a7794-cpg-mssr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/renesas/r8a7794-cpg-mssr.c 
> b/drivers/clk/renesas/r8a7794-cpg-mssr.c
> index 2a40bbeaeeafc2a4..3ce74f063fa86b19 100644
> --- a/drivers/clk/renesas/r8a7794-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a7794-cpg-mssr.c
> @@ -55,7 +55,6 @@ static const struct cpg_core_clk r8a7794_core_clks[] 
> __initconst = {
>  DEF_FIXED(".pll1_div2", CLK_PLL1_DIV2, CLK_PLL1, 2, 1),
>
>  /* Core Clock Outputs */
> -DEF_BASE("lb",   R8A7794_CLK_LB,   CLK_TYPE_GEN2_LB,   CLK_PLL1),
>  DEF_BASE("adsp", R8A7794_CLK_ADSP, CLK_TYPE_GEN2_ADSP, CLK_PLL1),
>  DEF_BASE("sdh",  R8A7794_CLK_SDH,  CLK_TYPE_GEN2_SDH,  CLK_PLL1),
>  DEF_BASE("sd0",  R8A7794_CLK_SD0,  CLK_TYPE_GEN2_SD0,  CLK_PLL1),
> @@ -69,6 +68,7 @@ static const struct cpg_core_clk r8a7794_core_clks[] 
> __initconst = {
>  DEF_FIXED("hp", R8A7794_CLK_HP,CLK_PLL1, 12, 1),
>  DEF_FIXED("i",  R8A7794_CLK_I, CLK_PLL1,  2, 1),
>  DEF_FIXED("b",  R8A7794_CLK_B, CLK_PLL1, 12, 1),
> +DEF_FIXED("lb", R8A7794_CLK_B, CLK_PLL1, 24, 1),

s/R8A7794_CLK_B/R8A7794_CLK_LB/

With that fixed:
Reviewed-by: Fabrizio Castro 

>  DEF_FIXED("p",  R8A7794_CLK_P, CLK_PLL1, 24, 1),
>  DEF_FIXED("cl", R8A7794_CLK_CL,CLK_PLL1, 48, 1),
>  DEF_FIXED("cp", R8A7794_CLK_CP,CLK_PLL1, 48, 1),
> --
> 2.7.4




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

RE: [PATCH 3/5] clk: renesas: r8a7791/r8a7793: Fix LB clock divider

[Fabrizio Castro]

> Subject: [PATCH 3/5] clk: renesas: r8a7791/r8a7793: Fix LB clock divider
>
> The CLK_TYPE_GEN2_LB clock type is meant for SoCs like R-Car H2, where
> the LB clock divider depends on the value of the MD18 pin.
>
> On R-Car M2-W and M2-N, the LB clock divider is fixed to 24.  Hence
> model the clock as a fixed factor clock instead.
>
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Fabrizio Castro 

> ---
>  drivers/clk/renesas/r8a7791-cpg-mssr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/renesas/r8a7791-cpg-mssr.c 
> b/drivers/clk/renesas/r8a7791-cpg-mssr.c
> index 820b220b09cc6bdb..1b91f03b75980766 100644
> --- a/drivers/clk/renesas/r8a7791-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a7791-cpg-mssr.c
> @@ -57,7 +57,6 @@ static struct cpg_core_clk r8a7791_core_clks[] __initdata = 
> {
>
>  /* Core Clock Outputs */
>  DEF_BASE("z",R8A7791_CLK_Z,CLK_TYPE_GEN2_Z,CLK_PLL0),
> -DEF_BASE("lb",   R8A7791_CLK_LB,   CLK_TYPE_GEN2_LB,   CLK_PLL1),
>  DEF_BASE("adsp", R8A7791_CLK_ADSP, CLK_TYPE_GEN2_ADSP, CLK_PLL1),
>  DEF_BASE("sdh",  R8A7791_CLK_SDH,  CLK_TYPE_GEN2_SDH,  CLK_PLL1),
>  DEF_BASE("sd0",  R8A7791_CLK_SD0,  CLK_TYPE_GEN2_SD0,  CLK_PLL1),
> @@ -70,6 +69,7 @@ static struct cpg_core_clk r8a7791_core_clks[] __initdata = 
> {
>  DEF_FIXED("hp", R8A7791_CLK_HP,CLK_PLL1, 12, 1),
>  DEF_FIXED("i",  R8A7791_CLK_I, CLK_PLL1,  2, 1),
>  DEF_FIXED("b",  R8A7791_CLK_B, CLK_PLL1, 12, 1),
> +DEF_FIXED("lb", R8A7791_CLK_LB,CLK_PLL1, 24, 1),
>  DEF_FIXED("p",  R8A7791_CLK_P, CLK_PLL1, 24, 1),
>  DEF_FIXED("cl", R8A7791_CLK_CL,CLK_PLL1, 48, 1),
>  DEF_FIXED("m2", R8A7791_CLK_M2,CLK_PLL1,  8, 1),
> --
> 2.7.4




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

RE: [PATCH 4/5] clk: renesas: r8a7792: Fix LB clock divider

[Fabrizio Castro]

Hello Geert

> Subject: [PATCH 4/5] clk: renesas: r8a7792: Fix LB clock divider
>
> The CLK_TYPE_GEN2_LB clock type is meant for SoCs like R-Car H2, where
> the LB clock divider depends on the value of the MD18 pin.
>
> On R-Car V2H, the LB clock divider is fixed to 24.  Hence model the
> clock as a fixed factor clock instead.
>
> Signed-off-by: Geert Uytterhoeven 
> ---
>  drivers/clk/renesas/r8a7792-cpg-mssr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/renesas/r8a7792-cpg-mssr.c 
> b/drivers/clk/renesas/r8a7792-cpg-mssr.c
> index 609a540804965c40..8b66e6f4b4584de1 100644
> --- a/drivers/clk/renesas/r8a7792-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a7792-cpg-mssr.c
> @@ -53,7 +53,6 @@ static const struct cpg_core_clk r8a7792_core_clks[] 
> __initconst = {
>  DEF_FIXED(".pll1_div2", CLK_PLL1_DIV2, CLK_PLL1, 2, 1),
>
>  /* Core Clock Outputs */
> -DEF_BASE("lb",   R8A7792_CLK_LB,   CLK_TYPE_GEN2_LB,   CLK_PLL1),
>  DEF_BASE("qspi", R8A7792_CLK_QSPI, CLK_TYPE_GEN2_QSPI, CLK_PLL1_DIV2),
>
>  DEF_FIXED("z",  R8A7792_CLK_Z, CLK_PLL0,  1, 1),
> @@ -63,6 +62,7 @@ static const struct cpg_core_clk r8a7792_core_clks[] 
> __initconst = {
>  DEF_FIXED("hp", R8A7792_CLK_HP,CLK_PLL1, 12, 1),
>  DEF_FIXED("i",  R8A7792_CLK_I, CLK_PLL1,  3, 1),
>  DEF_FIXED("b",  R8A7792_CLK_B, CLK_PLL1, 12, 1),
> +DEF_FIXED("lb", R8A7792_CLK_B, CLK_PLL1, 24, 1),

s/ R8A7792_CLK_B/ R8A7792_CLK_LB/

With that fixed:
Reviewed-by: Fabrizio Castro 

>  DEF_FIXED("p",  R8A7792_CLK_P, CLK_PLL1, 24, 1),
>  DEF_FIXED("cl", R8A7792_CLK_CL,CLK_PLL1, 48, 1),
>  DEF_FIXED("m2", R8A7792_CLK_M2,CLK_PLL1,  8, 1),
> --
> 2.7.4




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

RE: [PATCH 2/5] clk: renesas: r8a7745: Fix LB clock divider

[Fabrizio Castro]

> Subject: [PATCH 2/5] clk: renesas: r8a7745: Fix LB clock divider
>
> The CLK_TYPE_GEN2_LB clock type is meant for SoCs like R-Car H2, where
> the LB clock divider depends on the value of the MD18 pin.
>
> On RZ/G1E, the LB clock divider is fixed to 24.  Hence model the clock
> as a fixed factor clock instead.
>
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Fabrizio Castro 

> ---
>  drivers/clk/renesas/r8a7745-cpg-mssr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/renesas/r8a7745-cpg-mssr.c 
> b/drivers/clk/renesas/r8a7745-cpg-mssr.c
> index 87f5a3619e4f9d60..4b0a9243b7481176 100644
> --- a/drivers/clk/renesas/r8a7745-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a7745-cpg-mssr.c
> @@ -51,7 +51,6 @@ static const struct cpg_core_clk r8a7745_core_clks[] 
> __initconst = {
>  DEF_FIXED(".pll1_div2",CLK_PLL1_DIV2, CLK_PLL1, 2, 1),
>
>  /* Core Clock Outputs */
> -DEF_BASE("lb",   R8A7745_CLK_LB,   CLK_TYPE_GEN2_LB,CLK_PLL1),
>  DEF_BASE("sdh",  R8A7745_CLK_SDH,  CLK_TYPE_GEN2_SDH,CLK_PLL1),
>  DEF_BASE("sd0",  R8A7745_CLK_SD0,  CLK_TYPE_GEN2_SD0,CLK_PLL1),
>  DEF_BASE("qspi", R8A7745_CLK_QSPI, CLK_TYPE_GEN2_QSPI,CLK_PLL1_DIV2),
> @@ -63,6 +62,7 @@ static const struct cpg_core_clk r8a7745_core_clks[] 
> __initconst = {
>  DEF_FIXED("zs",R8A7745_CLK_ZS,CLK_PLL1,6, 1),
>  DEF_FIXED("hp",R8A7745_CLK_HP,CLK_PLL1,   12, 1),
>  DEF_FIXED("b", R8A7745_CLK_B,CLK_PLL1,   12, 1),
> +DEF_FIXED("lb",R8A7745_CLK_LB,CLK_PLL1,   24, 1),
>  DEF_FIXED("p", R8A7745_CLK_P,CLK_PLL1,   24, 1),
>  DEF_FIXED("cl",R8A7745_CLK_CL,CLK_PLL1,   48, 1),
>  DEF_FIXED("cp",R8A7745_CLK_CP,CLK_PLL1,   48, 1),
> --
> 2.7.4




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

RE: [PATCH 1/5] clk: renesas: r8a7743: Fix LB clock divider

[Fabrizio Castro]

> Subject: [PATCH 1/5] clk: renesas: r8a7743: Fix LB clock divider
>
> The CLK_TYPE_GEN2_LB clock type is meant for SoCs like R-Car H2, where
> the LB clock divider depends on the value of the MD18 pin.
>
> On RZ/G1M, the LB clock divider is fixed to 24.  Hence model the clock
> as a fixed factor clock instead.
>
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Fabrizio Castro 

> ---
>  drivers/clk/renesas/r8a7743-cpg-mssr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/renesas/r8a7743-cpg-mssr.c 
> b/drivers/clk/renesas/r8a7743-cpg-mssr.c
> index d3c8b1e2969fd305..011c170ec3f95d65 100644
> --- a/drivers/clk/renesas/r8a7743-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a7743-cpg-mssr.c
> @@ -52,7 +52,6 @@ static const struct cpg_core_clk r8a7743_core_clks[] 
> __initconst = {
>
>  /* Core Clock Outputs */
>  DEF_BASE("z",R8A7743_CLK_Z,CLK_TYPE_GEN2_Z,CLK_PLL0),
> -DEF_BASE("lb",   R8A7743_CLK_LB,   CLK_TYPE_GEN2_LB,CLK_PLL1),
>  DEF_BASE("sdh",  R8A7743_CLK_SDH,  CLK_TYPE_GEN2_SDH,CLK_PLL1),
>  DEF_BASE("sd0",  R8A7743_CLK_SD0,  CLK_TYPE_GEN2_SD0,CLK_PLL1),
>  DEF_BASE("qspi", R8A7743_CLK_QSPI, CLK_TYPE_GEN2_QSPI,CLK_PLL1_DIV2),
> @@ -63,6 +62,7 @@ static const struct cpg_core_clk r8a7743_core_clks[] 
> __initconst = {
>  DEF_FIXED("zs",R8A7743_CLK_ZS,CLK_PLL1,6, 1),
>  DEF_FIXED("hp",R8A7743_CLK_HP,CLK_PLL1,   12, 1),
>  DEF_FIXED("b", R8A7743_CLK_B,CLK_PLL1,   12, 1),
> +DEF_FIXED("lb",R8A7743_CLK_LB,CLK_PLL1,   24, 1),
>  DEF_FIXED("p", R8A7743_CLK_P,CLK_PLL1,   24, 1),
>  DEF_FIXED("cl",R8A7743_CLK_CL,CLK_PLL1,   48, 1),
>  DEF_FIXED("m2",R8A7743_CLK_M2,CLK_PLL1,8, 1),
> --
> 2.7.4




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

RE: [PATCH v2 6/8] ARM: dts: r8a77470: Initial SoC device tree

[Biju Das]

Hi Simon & Geert,

Thanks for feedback.

> On Wed, Mar 28, 2018 at 08:26:14PM +0100, Biju Das wrote:
> > The initial R8A77470 SoC device tree including CPU0, GIC, timer, SYSC,
> > RST, CPG, and the required clock descriptions.
> >
> > Signed-off-by: Biju Das 
> > Reviewed-by: Fabrizio Castro 
> > Reviewed-by: Geert Uytterhoeven 
> > ---
> > V1->V2:
> > * Incorporated geert's review comment
> > * Moved prr node inside soc node.
> >
> >  arch/arm/boot/dts/r8a77470.dtsi | 155
> > 
> >  1 file changed, 155 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/r8a77470.dtsi
> >
> > diff --git a/arch/arm/boot/dts/r8a77470.dtsi
> > b/arch/arm/boot/dts/r8a77470.dtsi new file mode 100644 index
> > 000..f096419
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/r8a77470.dtsi
> > @@ -0,0 +1,155 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Device Tree Source for the r8a77470 SoC
> > + *
> > + * Copyright (C) 2018 Renesas Electronics Corp.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>
> As requested by Geert in his review of v1, please use numerical values for the
> initial submission as the dt-bindings headers and the DTS files go upstream
> through different maintainer paths.
>
> In other words, please do not include r8a77470-cpg-mssr.h or r8a77470-sysc.h
> in the initial submission of this file as those header files will not be 
> present and
> there will be a build failure.
> Rather, please use numeric values for now and, as a follow-up in the v4.19
> development cycle, provide a patch to use the headers.
>

I got your point now. Will send V3 for this patch with numerical values.





Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.