Re: [PATCH v9 07/11] media: i2c: ov772x: Support frame interval handling

2018-02-19 Thread kbuild test robot
Hi Jacopo,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.16-rc2 next-20180220]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jacopo-Mondi/Renesas-Capture-Engine-Unit-CEU-V4L2-driver/20180220-101027
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/media/i2c/ov772x.c: In function 'ov772x_set_frame_rate.isra.2':
>> drivers/media/i2c/ov772x.c:643:7: warning: 'fsize' may be used uninitialized 
>> in this function [-Wmaybe-uninitialized]
 pclk = fps * fsize;
 ~^

vim +/fsize +643 drivers/media/i2c/ov772x.c

   604  
   605  static int ov772x_set_frame_rate(struct ov772x_priv *priv,
   606   struct v4l2_fract *tpf,
   607   const struct ov772x_color_format *cfmt,
   608   const struct ov772x_win_size *win)
   609  {
   610  struct i2c_client *client = v4l2_get_subdevdata(>subdev);
   611  unsigned long fin = clk_get_rate(priv->clk);
   612  unsigned int fps = tpf->numerator ?
   613 tpf->denominator / tpf->numerator :
   614 tpf->denominator;
   615  unsigned int best_diff;
   616  unsigned int fsize;
   617  unsigned int pclk;
   618  unsigned int diff;
   619  unsigned int idx;
   620  unsigned int i;
   621  u8 clkrc = 0;
   622  u8 com4 = 0;
   623  int ret;
   624  
   625  /* Approximate to the closest supported frame interval. */
   626  best_diff = ~0L;
   627  for (i = 0, idx = 0; i < OV772X_N_FRAME_INTERVALS; i++) {
   628  diff = abs(fps - ov772x_frame_intervals[i]);
   629  if (diff < best_diff) {
   630  idx = i;
   631  best_diff = diff;
   632  }
   633  }
   634  fps = ov772x_frame_intervals[idx];
   635  
   636  /* Use image size (with blankings) to calculate desired pixel 
clock. */
   637  if ((cfmt->com7 & OFMT_MASK) == OFMT_RGB ||
   638  (cfmt->com7 & OFMT_MASK) == OFMT_YUV)
   639  fsize = win->sizeimage * 2;
   640  else if ((cfmt->com7 & OFMT_MASK) == OFMT_BRAW)
   641  fsize = win->sizeimage;
   642  
 > 643  pclk = fps * fsize;
   644  
   645  /*
   646   * Pixel clock generation circuit is pretty simple:
   647   *
   648   * Fin -> [ / CLKRC_div] -> [ * PLL_mult] -> pclk
   649   *
   650   * Try to approximate the desired pixel clock testing all 
available
   651   * PLL multipliers (1x, 4x, 6x, 8x) and calculate corresponding
   652   * divisor with:
   653   *
   654   * div = PLL_mult * Fin / pclk
   655   *
   656   * and re-calculate the pixel clock using it:
   657   *
   658   * pclk = Fin * PLL_mult / CLKRC_div
   659   *
   660   * Choose the PLL_mult and CLKRC_div pair that gives a pixel 
clock
   661   * closer to the desired one.
   662   *
   663   * The desired pixel clock is calculated using a known frame 
size
   664   * (blanking included) and FPS.
   665   */
   666  best_diff = ~0L;
   667  for (i = 0; i < ARRAY_SIZE(ov772x_pll); i++) {
   668  unsigned int pll_mult = ov772x_pll[i].mult;
   669  unsigned int pll_out = pll_mult * fin;
   670  unsigned int t_pclk;
   671  unsigned int div;
   672  
   673  if (pll_out < pclk)
   674  continue;
   675  
   676  div = DIV_ROUND_CLOSEST(pll_out, pclk);
   677  t_pclk = DIV_ROUND_CLOSEST(fin * pll_mult, div);
   678  diff = abs(pclk - t_pclk);
   679  if (diff < best_diff) {
   680  best_diff = diff;
   681  clkrc = CLKRC_DIV(div);
   682  com4 = ov772x_pll[i].com4;
   683  }
   684  }
   685  
   686  ret = ov772x_write(client, COM4, com4 | COM4_RESERVED);
   687  if (ret < 0)
   688  return ret;
   689  
   690  ret = ov772x_write(client, CLKRC, clkrc | CLKRC_RESERVED);
   691  if (ret < 0)
   692   

Re: [PATCH v3 03/12] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

2018-02-19 Thread Rob Herring
On Wed, Feb 14, 2018 at 6:04 PM, Laurent Pinchart
 wrote:
> The internal LVDS encoders now have their own DT bindings. Before
> switching the driver infrastructure to those new bindings, implement
> backward-compatibility through live DT patching.
>
> Patching is disabled and will be enabled along with support for the new
> DT bindings in the DU driver.
>
> Signed-off-by: Laurent Pinchart 
> ---
> Changes since v2:
>
> - Update the SPDX headers to use C-style comments in header files
> - Removed the manually created __local_fixups__ node
> - Perform manual fixups on live DT instead of overlay

Generally looks fine to me. A few things below.
>
> Changes since v1:
>
> - Select OF_FLATTREE
> - Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
> - Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
> - Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
> - Pass void begin and end pointers to rcar_du_of_get_overlay()
> - Use of_get_parent() instead of accessing the parent pointer directly
> - Find the LVDS endpoints nodes based on the LVDS node instead of the
>   root of the overlay
> - Update to the -lvds compatible string format
> ---
>  drivers/gpu/drm/rcar-du/Kconfig|   2 +
>  drivers/gpu/drm/rcar-du/Makefile   |   7 +-
>  drivers/gpu/drm/rcar-du/rcar_du_of.c   | 374 
> +
>  drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 ++
>  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  81 +
>  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  55 +++
>  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  55 +++
>  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  55 +++
>  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  55 +++
>  9 files changed, 703 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts
>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts
>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts
>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts
>
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 5d0b4b7119af..3f83352a7313 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -22,6 +22,8 @@ config DRM_RCAR_LVDS
> bool "R-Car DU LVDS Encoder Support"
> depends on DRM_RCAR_DU
> select DRM_PANEL
> +   select OF_FLATTREE
> +   select OF_OVERLAY
> help
>   Enable support for the R-Car Display Unit embedded LVDS encoders.
>
> diff --git a/drivers/gpu/drm/rcar-du/Makefile 
> b/drivers/gpu/drm/rcar-du/Makefile
> index 0cf5c11030e8..86b337b4be5d 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -8,7 +8,12 @@ rcar-du-drm-y := rcar_du_crtc.o \
>  rcar_du_plane.o
>
>  rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
> -
> +rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
> +  rcar_du_of_lvds_r8a7790.dtb.o \
> +  rcar_du_of_lvds_r8a7791.dtb.o \
> +  rcar_du_of_lvds_r8a7793.dtb.o \
> +  rcar_du_of_lvds_r8a7795.dtb.o \
> +  rcar_du_of_lvds_r8a7796.dtb.o
>  rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
>
>  obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> new file mode 100644
> index ..141f6eda6e98
> --- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> @@ -0,0 +1,374 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * rcar_du_of.c - Legacy DT bindings compatibility
> + *
> + * Copyright (C) 2018 Laurent Pinchart 
> + *
> + * Based on work from Jyri Sarha 
> + * Copyright (C) 2015 Texas Instruments
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "rcar_du_crtc.h"
> +#include "rcar_du_drv.h"
> +
> +/* 
> -
> + * Generic Overlay Handling
> + */
> +
> +struct rcar_du_of_overlay {
> +   const char *compatible;
> +   void *begin;
> +   void *end;
> +};
> +
> +#define RCAR_DU_OF_DTB(type, soc)  \
> +   extern char __dtb_rcar_du_of_##type##_##soc##_begin[];  \
> +   extern char __dtb_rcar_du_of_##type##_##soc##_end[]
> +
> 

Re: [PATCH v9 03/11] media: platform: Add Renesas CEU driver

2018-02-19 Thread kbuild test robot
Hi Jacopo,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.16-rc2 next-20180220]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jacopo-Mondi/Renesas-Capture-Engine-Unit-CEU-V4L2-driver/20180220-101027
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/media/platform/renesas-ceu.c: In function 'ceu_g_parm':
>> drivers/media/platform/renesas-ceu.c:1177:9: error: implicit declaration of 
>> function 'v4l2_g_parm_cap'; did you mean 'v4l2_g_ctrl'? 
>> [-Werror=implicit-function-declaration]
 return v4l2_g_parm_cap(video_devdata(file), ceudev->sd->v4l2_sd, a);
^~~
v4l2_g_ctrl
   drivers/media/platform/renesas-ceu.c: In function 'ceu_s_parm':
>> drivers/media/platform/renesas-ceu.c:1184:9: error: implicit declaration of 
>> function 'v4l2_s_parm_cap'; did you mean 'v4l2_s_ctrl'? 
>> [-Werror=implicit-function-declaration]
 return v4l2_s_parm_cap(video_devdata(file), ceudev->sd->v4l2_sd, a);
^~~
v4l2_s_ctrl
   drivers/media/platform/renesas-ceu.c: In function 'ceu_start_streaming':
   drivers/media/platform/renesas-ceu.c:290:2: warning: 'cdwdr' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 iowrite32(data, priv->base + reg_offs);
 ^~
   drivers/media/platform/renesas-ceu.c:338:27: note: 'cdwdr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
  ^
   drivers/media/platform/renesas-ceu.c:290:2: warning: 'cfzsr' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 iowrite32(data, priv->base + reg_offs);
 ^~
   drivers/media/platform/renesas-ceu.c:338:20: note: 'cfzsr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
   ^
   drivers/media/platform/renesas-ceu.c:418:8: warning: 'camcr' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 camcr |= mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW ? 1 << 0 : 0;
 ~~^~~
   drivers/media/platform/renesas-ceu.c:338:6: note: 'camcr' was declared here
 u32 camcr, cdocr, cfzsr, cdwdr, capwr;
 ^
   drivers/media/platform/renesas-ceu.c: In function 'ceu_probe':
   drivers/media/platform/renesas-ceu.c:1623:9: warning: 'ret' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
 return ret;
^~~
   cc1: some warnings being treated as errors

vim +1177 drivers/media/platform/renesas-ceu.c

  1172  
  1173  static int ceu_g_parm(struct file *file, void *fh, struct 
v4l2_streamparm *a)
  1174  {
  1175  struct ceu_device *ceudev = video_drvdata(file);
  1176  
> 1177  return v4l2_g_parm_cap(video_devdata(file), 
> ceudev->sd->v4l2_sd, a);
  1178  }
  1179  
  1180  static int ceu_s_parm(struct file *file, void *fh, struct 
v4l2_streamparm *a)
  1181  {
  1182  struct ceu_device *ceudev = video_drvdata(file);
  1183  
> 1184  return v4l2_s_parm_cap(video_devdata(file), 
> ceudev->sd->v4l2_sd, a);
  1185  }
  1186  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH v9 07/11] media: i2c: ov772x: Support frame interval handling

2018-02-19 Thread kbuild test robot
Hi Jacopo,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.16-rc2 next-20180220]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jacopo-Mondi/Renesas-Capture-Engine-Unit-CEU-V4L2-driver/20180220-101027
base:   git://linuxtv.org/media_tree.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/media/i2c/ov772x.c:386:3: sparse: symbol 'ov772x_pll' was not 
>> declared. Should it be
>> drivers/media/i2c/ov772x.c:535:14: sparse: symbol 'ov772x_frame_intervals' 
>> was not declared. Should it be
   drivers/media/i2c/ov772x.c: In function 'ov772x_set_frame_rate.isra.2':
   drivers/media/i2c/ov772x.c:643:7: warning: 'fsize' may be used uninitialized 
in this function
pclk = fps COPYING CREDITS Documentation Kbuild Kconfig LICENSES 
MAINTAINERS Makefile README arch block certs crypto drivers firmware fs include 
init ipc kernel lib mm net samples scripts security sound tools usr virt fsize;
~^

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


[RFC PATCH] media: i2c: ov772x: ov772x_frame_intervals[] can be static

2018-02-19 Thread kbuild test robot

Fixes: 42b7d5be5f1f ("media: i2c: ov772x: Support frame interval handling")
Signed-off-by: Fengguang Wu 
---
 ov772x.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index eba71d97..0d8ce2a 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -532,7 +532,7 @@ static const struct ov772x_win_size ov772x_win_sizes[] = {
 /*
  * frame rate settings lists
  */
-unsigned int ov772x_frame_intervals[] = { 5, 10, 15, 20, 30, 60 };
+static unsigned int ov772x_frame_intervals[] = { 5, 10, 15, 20, 30, 60 };
 #define OV772X_N_FRAME_INTERVALS ARRAY_SIZE(ov772x_frame_intervals)
 
 /*


Re: [PATCH] serial: sh-sci: prevent lockup on full TTY buffers

2018-02-19 Thread Geert Uytterhoeven
Hi Uli,

On Fri, Feb 16, 2018 at 3:27 PM, Ulrich Hecht
 wrote:
> On Thu, Feb 15, 2018 at 2:12 PM, Wolfram Sang  wrote:
>>> This can be prevented by doing a dummy read of the RX data register.
>>
>> Just so I understand the issue correctly: We are reading the register to
>> throw the content away to prevent it being used in the TTY buffers?
>
> Not quite. The problem was that if the buffers are full,
> sci_receive_chars() returned immediately without reading anything from
> the data register, and that led to a lockup. I am not fully sure why
> that is so (I arrived at the fix by examining how the different code
> paths look from the serial controller's perspective), but dropping
> data here fixes it. At this point buffers are full, so any data
> received will have to be discarded anyway.

Do you get an interrupt storm, from the receive or overrun interrupt?

Anyway, the patch makes sense to me, so
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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


Re: [PATCH] serial: sh-sci: prevent lockup on full TTY buffers

2018-02-19 Thread Geert Uytterhoeven
Hi Greg,

On Fri, Feb 16, 2018 at 7:44 PM, Greg KH  wrote:
> On Thu, Feb 15, 2018 at 01:02:27PM +0100, Ulrich Hecht wrote:
>> When the TTY buffers fill up to the configured maximum, a system lockup
>> occurs:
>>
>> [  598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
>> [  598.825796]  0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
>> [  598.832577]  (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
>> [  598.838755] Task dump for CPU 0:
>> [  598.841977] swapper/0   R  running task0 0  0 
>> 0x0022
>> [  598.849023] Call trace:
>> [  598.851476]  __switch_to+0x98/0xb0
>> [  598.854870](null)
>>
>> This can be prevented by doing a dummy read of the RX data register.
>>
>> This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
>> reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
>> as well.
>>
>> Reported-by: Yoshihiro Shimoda 
>> Signed-off-by: Ulrich Hecht 
>
> Should this go to older kernel versions as well?
> If so, how far back?

This code path dates back to full-history-linux commit 2898a0e08c6ffb63
("[PATCH] SH Merge") in 2.6.2, back in 2004.

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] serial: sh-sci: prevent lockup on full TTY buffers

2018-02-19 Thread Yoshihiro Shimoda
Hi,

> From: Ulrich Hecht, Sent: Thursday, February 15, 2018 9:02 PM
> 
> When the TTY buffers fill up to the configured maximum, a system lockup
> occurs:
> 
> [  598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [  598.825796]  0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1
> [  598.832577]  (detected by 3, t=62517 jiffies, g=296, c=295, q=126)
> [  598.838755] Task dump for CPU 0:
> [  598.841977] swapper/0   R  running task0 0  0 
> 0x0022
> [  598.849023] Call trace:
> [  598.851476]  __switch_to+0x98/0xb0
> [  598.854870](null)
> 
> This can be prevented by doing a dummy read of the RX data register.
> 
> This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0;
> reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms
> as well.
> 
> Reported-by: Yoshihiro Shimoda 
> Signed-off-by: Ulrich Hecht 
> ---

Thank you for the patch. Our team tested this patch and the issue disappeared.
So,

Tested-by: Nguyen Viet Dung 

Best regards,
Yoshihiro Shimoda



Re: [PATCH 1/2] ARM: shmobile: Factor out complex condition

2018-02-19 Thread Geert Uytterhoeven
Hi Marek,

On Sat, Feb 17, 2018 at 12:46 PM, Marek Vasut  wrote:
> On 02/17/2018 09:18 AM, Wolfram Sang wrote:
>>> -if ((client->addr == 0x58 && !strcmp(client->name, "da9063")) ||
>>> -(client->addr == 0x68 && !strcmp(client->name, "da9210")) ||
>>> -(client->addr == 0x70 && !strcmp(client->name, "da9210"))) {
>>> +if (regulator_quirk_check(client, 0, "da9063") ||
>>> +regulator_quirk_check(client, 1, "da9210") ||
>>> +regulator_quirk_check(client, 2, "da9210")) {
>>
>> I am afraid I don't think this makes the code better, just different.
>> The index is as magic as the client address IMO. I was not super happy
>> with the array size depending on the detected board from a previous
>> patch already. But given the next patch which modifies the msg array
>> depending on the board, I think we really need to switch to seperate
>> message arrays per board. Everything else is too error prone and
>> unnecessarily cumbersome to understand.
>>
>> Other opinions?
>
> The code is awful, yes.
>
> I wonder if we could rather find all DA0063 and DA9210 PMICs in the DT,
> check if their IRQ lines are tied together and then generate the table
> above dynamically for whatever PMICs are present in the system. Then all
> that special-casing would go away as we'd extract the information from DT.

Yes, like I suggested 4 days ago ;-)

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 4/5] arm64: dts: renesas: initial Condor board device tree

2018-02-19 Thread Geert Uytterhoeven
Hi Sergei,

On Fri, Feb 16, 2018 at 7:35 PM, Sergei Shtylyov
 wrote:
> Add the initial device  tree for  the R8A77980 SoC based Condor board.
> The board has 1 debug serial port (SCIF0); include support for it, so
> that the serial console can work.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 
> Reviewed-by: Geert Uytterhoeven 
>
> ---
> Changes in version 2:
> - removed the useless "status" property from the SCIF_CLK node;
> - fixed the memory size;
> - added Geert's tag.

> --- /dev/null
> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for the Condor board
> + *
> + * Copyright (C) 2018 Renesas Electronics Corp.
> + * Copyright (C) 2018 Cogent Embedded, Inc.
> + */
> +
> +/dts-v1/;
> +#include "r8a77980.dtsi"
> +
> +/ {
> +   model = "Renesas Condor board based on r8a77980";
> +   compatible = "renesas,condor", "renesas,r8a77980";
> +
> +   aliases {
> +   serial0 = 
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";
> +   };
> +
> +   memory@4800 {
> +   device_type = "memory";
> +   /* first 128MB is reserved for secure area. */
> +   reg = <0 0x4800 0 0xb800>;

Shouldn't the size be 0x7800, or is there really 3 GiB of RAM?

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] sh_eth: simplify sh_eth_check_reset()

2018-02-19 Thread Geert Uytterhoeven
On Sun, Feb 18, 2018 at 4:21 PM, Sergei Shtylyov
 wrote:
> The *while* loop in this function  can be turned into a normal *for* loop.
> And getting rid  of the  single return point saves us a few more LoCs...
>
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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


Re: [PATCH v2 4/5] arm64: dts: renesas: initial Condor board device tree

2018-02-19 Thread Simon Horman
On Mon, Feb 19, 2018 at 11:34:41AM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 2/19/2018 11:30 AM, Geert Uytterhoeven wrote:
> 
> > > Add the initial device  tree for  the R8A77980 SoC based Condor board.
> > > The board has 1 debug serial port (SCIF0); include support for it, so
> > > that the serial console can work.
> > > 
> > > Based on the original (and large) patch by Vladimir Barinov.
> > > 
> > > Signed-off-by: Vladimir Barinov 
> > > Signed-off-by: Sergei Shtylyov 
> > > Reviewed-by: Geert Uytterhoeven 
> > > 
> > > ---
> > > Changes in version 2:
> > > - removed the useless "status" property from the SCIF_CLK node;
> > > - fixed the memory size;
> > > - added Geert's tag.
> > 
> > > --- /dev/null
> > > +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> > > @@ -0,0 +1,45 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Device Tree Source for the Condor board
> > > + *
> > > + * Copyright (C) 2018 Renesas Electronics Corp.
> > > + * Copyright (C) 2018 Cogent Embedded, Inc.
> > > + */
> > > +
> > > +/dts-v1/;
> > > +#include "r8a77980.dtsi"
> > > +
> > > +/ {
> > > +   model = "Renesas Condor board based on r8a77980";
> > > +   compatible = "renesas,condor", "renesas,r8a77980";
> > > +
> > > +   aliases {
> > > +   serial0 = 
> > > +   };
> > > +
> > > +   chosen {
> > > +   stdout-path = "serial0:115200n8";
> > > +   };
> > > +
> > > +   memory@4800 {
> > > +   device_type = "memory";
> > > +   /* first 128MB is reserved for secure area. */
> > > +   reg = <0 0x4800 0 0xb800>;
> > 
> > Shouldn't the size be 0x7800, or is there really 3 GiB of RAM?
> 
>Ugh, so I finally mixed up limit and size... :-/

Thanks, I will apply the following, with the memory corrected to 2 GiB.

From: Sergei Shtylyov 
Subject: [PATCH] arm64: dts: renesas: initial Condor board device tree

Add the initial device  tree for  the R8A77980 SoC based Condor board.
The board has 1 debug serial port (SCIF0); include support for it, so
that the serial console can work.

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

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Geert Uytterhoeven 
[simon: correct memory size to 0x7800 (2GiB)]
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/Makefile|  1 +
 arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 45 +
 2 files changed, 46 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a77980-condor.dts

diff --git a/arch/arm64/boot/dts/renesas/Makefile 
b/arch/arm64/boot/dts/renesas/Makefile
index 2186d0193b73..c885eef4e660 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -8,4 +8,5 @@ dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb 
r8a7796-m3ulcb.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-m3ulcb-kf.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
+dtb-$(CONFIG_ARCH_R8A77980) += r8a77980-condor.dtb
 dtb-$(CONFIG_ARCH_R8A77995) += r8a77995-draak.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a77980-condor.dts 
b/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
new file mode 100644
index ..daf2957d3504
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Condor board
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ * Copyright (C) 2018 Cogent Embedded, Inc.
+ */
+
+/dts-v1/;
+#include "r8a77980.dtsi"
+
+/ {
+   model = "Renesas Condor board based on r8a77980";
+   compatible = "renesas,condor", "renesas,r8a77980";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@4800 {
+   device_type = "memory";
+   /* first 128MB is reserved for secure area. */
+   reg = <0 0x4800 0 0x7800>;
+   };
+};
+
+_clk {
+   clock-frequency = <1666>;
+};
+
+_clk {
+   clock-frequency = <32768>;
+};
+
+ {
+   status = "okay";
+};
+
+_clk {
+   clock-frequency = <14745600>;
+};
-- 
2.11.0



Re: [PATCH 2/2] ARM: shmobile: porter: enable R-Car Gen2 regulator quirk

2018-02-19 Thread Geert Uytterhoeven
On Sat, Feb 17, 2018 at 3:06 AM, Marek Vasut  wrote:
> Porter needs the regulator quirk, just like the other boards,
> the DA9063 and DA9210 IRQ line is connected to CPU IRQ2 . But
> unlike the other boards, the DA9063 is at 0x5a on Porter.
>
> Signed-off-by: Marek Vasut 
> Cc: Geert Uytterhoeven 
> Cc: Kuninori Morimoto 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> ---
>  arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c 
> b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
> index 862f7757ef5d..7963f0eea9e1 100644
> --- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
> @@ -132,11 +132,16 @@ static int __init rcar_gen2_regulator_quirk(void)
> u32 mon;
>
> if (!of_machine_is_compatible("renesas,koelsch") &&
> +   !of_machine_is_compatible("renesas,porter") &&
> !of_machine_is_compatible("renesas,lager") &&
> !of_machine_is_compatible("renesas,stout") &&
> !of_machine_is_compatible("renesas,gose"))
> return -ENODEV;
>
> +   /* DA9063 on M2W Porter is at 0x5a */
> +   if (of_machine_is_compatible("renesas,porter"))
> +   da9xxx_msgs[0].addr = 0x5a;
> +
> irqc = ioremap(IRQC_BASE, PAGE_SIZE);
> if (!irqc)
> return -ENOMEM;

Doing the same of_machine_is_compatible() check again is an indicator that
you should switch to an of_device_id-based match interface...

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 0/3] pinctrl: sh-pfc: r8a7795,6: Fix pin assignment definitions

2018-02-19 Thread Simon Horman
On Fri, Feb 16, 2018 at 03:25:01PM +0100, Ulrich Hecht wrote:
> Hi!
> 
> This series contains fixes to the PFC register definitions for r8a7795 and
> r8a7796 from the BSP that are not upstream yet.
> As far as I could tell, these changes check out with the Gen3 datasheet
> revision 0.80.

Agreed.

Reviewed-by: Simon Horman 



Re: [PATCH] clk: fix false-positive Wmaybe-uninitialized warning

2018-02-19 Thread Geert Uytterhoeven
Hi Arnd,

On Fri, Feb 16, 2018 at 4:27 PM, Arnd Bergmann  wrote:
> When we build this driver with on x86-32, gcc produces a false-positive 
> warning:
>
> drivers/clk/renesas/clk-sh73a0.c: In function 'sh73a0_cpg_clocks_init':
> drivers/clk/renesas/clk-sh73a0.c:155:10: error: 'parent_name' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
>return clk_register_fixed_factor(NULL, name, parent_name, 0,
>
> We can work around that warning by adding a fake initialization, I tried
> and failed to come up with any better workaround. This is currently one
> of few remaining warnings for a 4.14.y randconfig build, so it would be
> good to also have it backported at least to that version. Older versions
> have more randconfig warnings, so we might not care.
>
> I had not noticed this earlier, because one patch in my randconfig test
> tree removes the '-ffreestanding' option on x86-32, and that avoids
> the warning. The -ffreestanding flag was originally global but moved
> into arch/i386 by Andi Kleen in commit 6edfba1b33c7 ("[PATCH] x86_64:
> Don't define string functions to builtin") as a 'temporary workaround'.
>
> Like many temporary hacks, this turned out to be rather long-lived, from
> all I can tell we still need a simple fix to asm/string_32.h before it
> can be removed, but I'm not sure about how to best do that.
>
> Cc: sta...@vger.kernel.org
> Cc: Andi Kleen 
> Signed-off-by: Arnd Bergmann 

Thanks, this is a known false positive.

Acked-by: Geert Uytterhoeven 

> ---
>  drivers/clk/renesas/clk-sh73a0.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/renesas/clk-sh73a0.c 
> b/drivers/clk/renesas/clk-sh73a0.c
> index eea38f6ea77e..3892346c4fcc 100644
> --- a/drivers/clk/renesas/clk-sh73a0.c
> +++ b/drivers/clk/renesas/clk-sh73a0.c
> @@ -46,7 +46,7 @@ struct div4_clk {
> unsigned int shift;
>  };
>
> -static struct div4_clk div4_clks[] = {
> +static const struct div4_clk div4_clks[] = {

This change is not part of the fix...

> { "zg", "pll0", CPG_FRQCRA, 16 },
> { "m3", "pll1", CPG_FRQCRA, 12 },
> { "b",  "pll1", CPG_FRQCRA,  8 },
> @@ -79,7 +79,7 @@ sh73a0_cpg_register_clock(struct device_node *np, struct 
> sh73a0_cpg *cpg,
>  {
> const struct clk_div_table *table = NULL;
> unsigned int shift, reg, width;
> -   const char *parent_name;
> +   const char *parent_name = NULL;
> unsigned int mult = 1;
> unsigned int div = 1;
>
> @@ -135,7 +135,7 @@ sh73a0_cpg_register_clock(struct device_node *np, struct 
> sh73a0_cpg *cpg,
> shift = 24;
> width = 5;
> } else {
> -   struct div4_clk *c;
> +   const struct div4_clk *c;

... and neither is this one.

>
> for (c = div4_clks; c->name; c++) {
> if (!strcmp(name, c->name)) {

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/5] arm64: dts: renesas: r8a77980: add EtherAVB support

2018-02-19 Thread Geert Uytterhoeven
On Fri, Feb 16, 2018 at 7:32 PM, Sergei Shtylyov
 wrote:
> Define the generic R8A77980 part of the EtherAVB device node.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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


Re: [PATCH 0/3] pinctrl: sh-pfc: add HDMI pins

2018-02-19 Thread Simon Horman
On Fri, Feb 16, 2018 at 03:25:39PM +0100, Ulrich Hecht wrote:
> Hi!
> 
> Straight from the BSP, HDMI pins for r8a7795{,-es1} and r8a7796. Magic
> numbers verified according to "pinfunction" document revisions 0.54 (M3-W)
> and 0.553 (H3).

Reviewed-by: Simon Horman 



Re: [PATCH 2/2] ARM: shmobile: porter: enable R-Car Gen2 regulator quirk

2018-02-19 Thread Marek Vasut
On 02/19/2018 09:42 AM, Geert Uytterhoeven wrote:
> On Sat, Feb 17, 2018 at 3:06 AM, Marek Vasut  wrote:
>> Porter needs the regulator quirk, just like the other boards,
>> the DA9063 and DA9210 IRQ line is connected to CPU IRQ2 . But
>> unlike the other boards, the DA9063 is at 0x5a on Porter.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Geert Uytterhoeven 
>> Cc: Kuninori Morimoto 
>> Cc: Simon Horman 
>> Cc: Wolfram Sang 
>> ---
>>  arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c 
>> b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>> index 862f7757ef5d..7963f0eea9e1 100644
>> --- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>> +++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>> @@ -132,11 +132,16 @@ static int __init rcar_gen2_regulator_quirk(void)
>> u32 mon;
>>
>> if (!of_machine_is_compatible("renesas,koelsch") &&
>> +   !of_machine_is_compatible("renesas,porter") &&
>> !of_machine_is_compatible("renesas,lager") &&
>> !of_machine_is_compatible("renesas,stout") &&
>> !of_machine_is_compatible("renesas,gose"))
>> return -ENODEV;
>>
>> +   /* DA9063 on M2W Porter is at 0x5a */
>> +   if (of_machine_is_compatible("renesas,porter"))
>> +   da9xxx_msgs[0].addr = 0x5a;
>> +
>> irqc = ioremap(IRQC_BASE, PAGE_SIZE);
>> if (!irqc)
>> return -ENOMEM;
> 
> Doing the same of_machine_is_compatible() check again is an indicator that
> you should switch to an of_device_id-based match interface...

Indeed. Also cfr my other suggestion in reply to WSA in this thread.
Thoughts on that welcome.

-- 
Best regards,
Marek Vasut


Re: [PATCH] soc: renesas: r8a77970-sysc: fix power area parents

2018-02-19 Thread Simon Horman
On Mon, Feb 19, 2018 at 09:38:15AM +0100, Geert Uytterhoeven wrote:
> On Fri, Feb 16, 2018 at 9:09 PM, Sergei Shtylyov
>  wrote:
> > According to the figure 9.2(b) of the R-Car Series, 3rd Generation User’s
> > Manual: Hardware Rev. 0.80 the A2IRn and A2SCn power areas in R8A77970 have
> > the A3IR area as a parent, thus the SYSC driver has those parents wrong...
> >
> > Fixes: bab9b2a74fe9 ("soc: renesas: rcar-sysc: add R8A77970 support")
> > Signed-off-by: Sergei Shtylyov 
> 
> Reviewed-by: Geert Uytterhoeven 
> 
> Sorry for missing this in my original review.

Thanks, applied.


Re: [PATCH v2 4/5] arm64: dts: renesas: initial Condor board device tree

2018-02-19 Thread Sergei Shtylyov

Hello!

On 2/19/2018 11:30 AM, Geert Uytterhoeven wrote:


Add the initial device  tree for  the R8A77980 SoC based Condor board.
The board has 1 debug serial port (SCIF0); include support for it, so
that the serial console can work.

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

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Geert Uytterhoeven 

---
Changes in version 2:
- removed the useless "status" property from the SCIF_CLK node;
- fixed the memory size;
- added Geert's tag.



--- /dev/null
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Condor board
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ * Copyright (C) 2018 Cogent Embedded, Inc.
+ */
+
+/dts-v1/;
+#include "r8a77980.dtsi"
+
+/ {
+   model = "Renesas Condor board based on r8a77980";
+   compatible = "renesas,condor", "renesas,r8a77980";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@4800 {
+   device_type = "memory";
+   /* first 128MB is reserved for secure area. */
+   reg = <0 0x4800 0 0xb800>;


Shouldn't the size be 0x7800, or is there really 3 GiB of RAM?


   Ugh, so I finally mixed up limit and size... :-/


oetje,eeting}s,

 Geert


MBR, Sergei


Re: [PATCH v2 0/5] Add R8A77980/Condor board support

2018-02-19 Thread Simon Horman
On Fri, Feb 16, 2018 at 09:25:30PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> Here's the set of 11 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20180216-v4.16-rc1' tag. I'm adding the device tree support
> for the R8A77980-based Condor board (note that NFS root would only work on
> the Condor boards [re]wired for booting from EtherAVB -- we haven't been
> able to get the 'sh_eth' driver working in either U-Boot or Linux so far).
> The necessary SYS-DMAC, [H]SCIF, and EtherAVB bindings updates have been
> posted, the clock driver has been reposted yesterday, and the merged patches
> have been dropped from this respin of the series...
> 
> [1/5] soc: renesas: rcar-sysc: add R8A77980 support
> [2/5] arm64: dts: renesas: r8a77980: add [H]SCIF support
> [3/5] arm64: dts: renesas: r8a77980: add EtherAVB support
> [4/5] arm64: dts: renesas: initial Condor board device tree
> [5/5] arm64: dts: renesas: condor: add EtherAVB support

Thanks, applied.


Re: [PATCH] soc: renesas: r8a77970-sysc: fix power area parents

2018-02-19 Thread Geert Uytterhoeven
On Fri, Feb 16, 2018 at 9:09 PM, Sergei Shtylyov
 wrote:
> According to the figure 9.2(b) of the R-Car Series, 3rd Generation User’s
> Manual: Hardware Rev. 0.80 the A2IRn and A2SCn power areas in R8A77970 have
> the A3IR area as a parent, thus the SYSC driver has those parents wrong...
>
> Fixes: bab9b2a74fe9 ("soc: renesas: rcar-sysc: add R8A77970 support")
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Geert Uytterhoeven 

Sorry for missing this in my original review.

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 0/3] pinctrl: sh-pfc: add TMU pins

2018-02-19 Thread Simon Horman
On Fri, Feb 16, 2018 at 03:26:08PM +0100, Ulrich Hecht wrote:
> Hi!
> 
> Straight from the BSP, TMU pins for r8a7795{,-es1} and r8a7796. Magic
> numbers verified according to "pinfunction" document revisions 0.54 (M3-W)
> and 0.553 (H3).

Reviewed-by: Simon Horman 



Re: [PATCH 1/2] ARM: shmobile: Factor out complex condition

2018-02-19 Thread Simon Horman
On Sat, Feb 17, 2018 at 03:06:41AM +0100, Marek Vasut wrote:
> Pull the complex condition in regulator_quirk_notify() into
> regulator_quirk_check(). Moreover, do not hard-code the I2C
> address, but rather use the one in da9xxx_msgs[].
> 
> Signed-off-by: Marek Vasut 
> Cc: Geert Uytterhoeven 
> Cc: Kuninori Morimoto 
> Cc: Simon Horman 
> Cc: Wolfram Sang 

There appears to be some review of this series that needs addressing,
I have marked it as "Changes Requested".


Re: [PATCH 01/15] Documentation: devicetree: R-Car M3-N SoC DT bindings

2018-02-19 Thread Simon Horman
On Sun, Feb 18, 2018 at 08:52:13PM -0600, Rob Herring wrote:
> On Wed, Feb 14, 2018 at 11:01:53AM +0100, Simon Horman wrote:
> > On Tue, Feb 13, 2018 at 10:45:48AM +0100, Jacopo Mondi wrote:
> > > Add device tree bindings documentation for Renesas R-Car M3-N (r8a77965)
> > > SoC.
> > > 
> > > Signed-off-by: Jacopo Mondi 
> > 
> > Thanks, this looks fine to me but I think the subject should be updated to
> > 
> > dt-bindings: arm: document R8A77965 SoC bindings
> > 
> > I'll let this sit for a few days to see if any other review is forthcoming.
> > 
> > > ---
> > >  Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
> > >  1 file changed, 2 insertions(+)
> 
> Reviewed-by: Rob Herring 

Thanks, applied as

dt-bindings: arm: Document R-Car M3-N SoC DT bindings


[PATCH 00/02] ARM: dts: silk: Add EEPROM and GPIO keys

2018-02-19 Thread Magnus Damm
ARM: dts: silk: Add EEPROM and GPIO keys

[PATCH 01/02] ARM: dts: silk: Add r1ex24002 EEPROM to DT
[PATCH 02/02] ARM: dts: silk: Add GPIO keys to DT

This series updates the DTS for the R-Car E2-based Silk board to support an
EEPROM connected via I2C and GPIO based tactile switches. Based on the Gose
board support and adjusted to fit the board schematics.

Signed-off-by: Magnus Damm 
---

 Developed on top of renesas-devel-20180215-v4.16-rc1

 arch/arm/boot/dts/r8a7794-silk.dts |   61 
 1 file changed, 61 insertions(+)



[PATCH 02/02] ARM: dts: silk: Add GPIO keys to DT

2018-02-19 Thread Magnus Damm
From: Magnus Damm 

Extend the Silk board support to include SW3, SW4, SW6 and SW12. They
are all connected via GPIO lines and handled by the gpio-keys driver.

Signed-off-by: Magnus Damm 
---

 arch/arm/boot/dts/r8a7794-silk.dts |   55 
 1 file changed, 55 insertions(+)

--- 0002/arch/arm/boot/dts/r8a7794-silk.dts
+++ work/arch/arm/boot/dts/r8a7794-silk.dts 2018-02-19 20:24:48.960607110 
+0900
@@ -24,6 +24,7 @@
 /dts-v1/;
 #include "r8a7794.dtsi"
 #include 
+#include 
 
 / {
model = "SILK";
@@ -45,6 +46,60 @@
reg = <0 0x4000 0 0x4000>;
};
 
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   key-3 {
+   gpios = < 10 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW3";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-4 {
+   gpios = < 11 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW4";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-6 {
+   gpios = < 12 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW6";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-a {
+   gpios = < 9 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW12-1";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-b {
+   gpios = < 10 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW12-2";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-c {
+   gpios = < 11 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW12-3";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   key-d {
+   gpios = < 12 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   label = "SW12-4";
+   wakeup-source;
+   debounce-interval = <20>;
+   };
+   };
+
d3_3v: regulator-d3-3v {
compatible = "regulator-fixed";
regulator-name = "D3.3V";


[PATCH 01/02] ARM: dts: silk: Add r1ex24002 EEPROM to DT

2018-02-19 Thread Magnus Damm
From: Magnus Damm 

Extend the Silk board support to include U14 which is an I2C based EEPROM
hooked up to the I2C1 bus.

Signed-off-by: Magnus Damm 
---

 arch/arm/boot/dts/r8a7794-silk.dts |6 ++
 1 file changed, 6 insertions(+)

--- 0001/arch/arm/boot/dts/r8a7794-silk.dts
+++ work/arch/arm/boot/dts/r8a7794-silk.dts 2018-02-19 20:03:54.730607110 
+0900
@@ -226,6 +226,12 @@
};
};
};
+
+   eeprom@50 {
+   compatible = "renesas,r1ex24002", "atmel,24c02";
+   reg = <0x50>;
+   pagesize = <16>;
+   };
};
 };
 


[PATCH/RFC v3] arm64: r8a77965 Salvator-X SoC/board support prototype

2018-02-19 Thread Magnus Damm
Here's V3 of prototype support for the r8a77965 Salvator-X.

This version is based on "renesas-drivers-2018-02-13-v4.16-rc1".

By up-porting this patch I am able to track which part of M3-N support
that yet to be merged in mainline. If all goes well then new versions of
this patch will reduce in size over time.

The following patches are picked from renesas-bsp @ kernel.org and
in particular the recent "rcar-3.5.9.rc2" release:

dca5c4d1adc6 arm64: renesas: Add Renesas R8A77965 Kconfig support
6f3c0086b8b2 soc: renesas: identify R-Car M3N
711dec8fc1df soc: renesas: rcar-rst: Add R8A77965 support (*)
c8418d81dd26 clk: renesas: Add r8a77965 CPG Core Clock Definitions
d642ad7d1a40 clk: renesas: cpg-mssr: Add support for R-Car M3N (*)
4cec6dcde2f5 arm64: dts: r8a77965: Add Renesas R8A77965 SoC support (*)
92be4952a4d5 arm64: dts: r8a77965-salvator-x: Add Salvator-X board on R8A77965 
SoC support (*)
1c69363cc1eb arm64: dts: r8a77965-salvator-x: Add reserved memory regions

Commits above original author is Kihara-san:
Signed-off-by: Takeshi Kihara 

Commits marked with (*) above have been updated to fit on upstream

Since this is prototype code and not suitable for mainline merge as-is:
Not-Yet-Signed-off-by: Magnus Damm 
---

 Documentation/devicetree/bindings/arm/shmobile.txt   |4 
 Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt |5 
 arch/arm64/Kconfig.platforms |6 
 arch/arm64/boot/dts/renesas/Makefile |1 
 arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts  |   79 
 arch/arm64/boot/dts/renesas/r8a77965.dtsi|  141 +++
 drivers/clk/renesas/Kconfig  |5 
 drivers/clk/renesas/Makefile |1 
 drivers/clk/renesas/r8a77965-cpg-mssr.c  |  195 ++
 drivers/clk/renesas/renesas-cpg-mssr.c   |6 
 drivers/clk/renesas/renesas-cpg-mssr.h   |1 
 drivers/soc/renesas/Kconfig  |4 
 drivers/soc/renesas/rcar-rst.c   |1 
 drivers/soc/renesas/renesas-soc.c|8 
 include/dt-bindings/clock/r8a77965-cpg-mssr.h|   66 +++
 15 files changed, 519 insertions(+), 4 deletions(-)

--- 0001/Documentation/devicetree/bindings/arm/shmobile.txt
+++ work/Documentation/devicetree/bindings/arm/shmobile.txt 2018-02-19 
20:29:52.330607110 +0900
@@ -39,6 +39,8 @@ SoCs:
 compatible = "renesas,r8a7795"
   - R-Car M3-W (R8A77960)
 compatible = "renesas,r8a7796"
+  - R-Car M3-N (R8A77965)
+compatible = "renesas,r8a77965"
   - R-Car V3M (R8A77970)
 compatible = "renesas,r8a77970"
   - R-Car V3H (R8A77980)
@@ -106,6 +108,8 @@ Boards:
 compatible = "renesas,salvator-x", "renesas,r8a7795"
   - Salvator-X (RTP0RC7796SIPB0011S)
 compatible = "renesas,salvator-x", "renesas,r8a7796"
+  - Salvator-X (RTP0RC7796SIPB0011S (M3-N))
+compatible = "renesas,salvator-x", "renesas,r8a77965"
   - Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S)
 compatible = "renesas,salvator-xs", "renesas,r8a7795"
   - Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S)
--- 0001/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
+++ work/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt   
2018-02-19 20:29:52.330607110 +0900
@@ -22,6 +22,7 @@ Required Properties:
   - "renesas,r8a7794-cpg-mssr" for the r8a7794 SoC (R-Car E2)
   - "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3)
   - "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W)
+  - "renesas,r8a77965-cpg-mssr" for the r8a77965 SoC (R-Car M3-N)
   - "renesas,r8a77970-cpg-mssr" for the r8a77970 SoC (R-Car V3M)
   - "renesas,r8a77995-cpg-mssr" for the r8a77995 SoC (R-Car D3)
 
@@ -32,8 +33,8 @@ Required Properties:
 clock-names
   - clock-names: List of external parent clock names. Valid names are:
   - "extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7792, r8a7793, r8a7794,
-r8a7795, r8a7796, r8a77970, r8a77995)
-  - "extalr" (r8a7795, r8a7796, r8a77970)
+r8a7795, r8a7796, r8a77965, r8a77970, r8a77995)
+  - "extalr" (r8a7795, r8a7796, r8a77965, r8a77970)
   - "usb_extal" (r8a7743, r8a7745, r8a7790, r8a7791, r8a7793, r8a7794)
 
   - #clock-cells: Must be 2
--- 0001/arch/arm64/Kconfig.platforms
+++ work/arch/arm64/Kconfig.platforms   2018-02-19 20:29:52.330607110 +0900
@@ -208,6 +208,12 @@ config ARCH_R8A77995
help
  This enables support for the Renesas R-Car D3 SoC.
 
+config ARCH_R8A77965
+   bool "Renesas R-Car M3N SoC Platform"
+   depends on ARCH_RENESAS
+   help
+ This enables support for the Renesas R-Car M3N SoC.
+
 config ARCH_STRATIX10
bool "Altera's Stratix 10 SoCFPGA Family"
   

[PATCH] ARM: dts: marzen: Add SDHI0 VCCQ Regulator

2018-02-19 Thread Magnus Damm
From: Magnus Damm 

Add support for the on-board voltage regulator hooked up to GPIO3_20
on r8a7779 Marzen. The board schematics describes the regulator as U4
TPS2110A. Input wise, U4 has D0 fixed to ground, D1 tied to GPIO3_20
while IN1 is fixed to 3.3V and IN2 is fixed to 1.8V. OUT goes to the
pull-ups for the data pins of SDHI0.

Signed-off-by: Magnus Damm 
---

 arch/arm/boot/dts/r8a7779-marzen.dts |   14 ++
 1 file changed, 14 insertions(+)

--- 0001/arch/arm/boot/dts/r8a7779-marzen.dts
+++ work/arch/arm/boot/dts/r8a7779-marzen.dts   2018-02-19 21:21:14.400607110 
+0900
@@ -42,6 +42,19 @@
regulator-always-on;
};
 
+   vccq_sdhi0: regulator-vccq-sdhi0 {
+   compatible = "regulator-gpio";
+
+   regulator-name = "SDHI0 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+
+   gpios = < 20 GPIO_ACTIVE_HIGH>;
+   gpios-states = <1>;
+   states = <330 1
+ 180 0>;
+   };
+
ethernet@1800 {
compatible = "smsc,lan9220", "smsc,lan9115";
reg = <0x1800 0x100>;
@@ -243,6 +256,7 @@
pinctrl-names = "default";
 
vmmc-supply = <>;
+   vqmmc-supply = <_sdhi0>;
bus-width = <4>;
status = "okay";
 };


Re: [PATCH v2 4/5] arm64: dts: renesas: r8a77970: add the LVDS instance

2018-02-19 Thread Simon Horman
On Thu, Feb 08, 2018 at 07:05:53PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 02/08/2018 06:47 PM, Niklas Söderlund wrote:
> 
> > Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect
> > the it to the LVDS output of the DU. While at it align the endpoint name
> > of the du to du_out_lvds0 which is used in other Renesas DTS files to
> > describe this link.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  arch/arm64/boot/dts/renesas/r8a77970.dtsi | 29 
> > -
> >  1 file changed, 28 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
> > b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > index c6056635bd372ce3..9c65884cc384952d 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
> > @@ -653,7 +653,34 @@
> >  
> > port@1 {
> > reg = <1>;
> > -   du_out_lvds: endpoint {
> > +   du_out_lvds0: endpoint {
> > +   remote-endpoint = <_in>;
> > +   };
> > +   };
> > +   };
> > +   };
> > +
> > +   lvds0: lvds@feb9 {
> > +   compatible = "renesas,r8a77970-lvds";
> > +   reg = <0 0xfeb9 0 0x14>;
> > +   clocks = < CPG_MOD 727>;
> > +   power-domains = < R8A77970_PD_ALWAYS_ON>;
> > +   resets = < 727>;
> > +   status = "disabled";
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +   lvds0_in: endpoint {
> > +   remote-endpoint = 
> > <_out_lvds0>;
> > +   };
> > +   };
> > +   port@1 {
> > +   reg = <1>;
> > +   lvds0_out: endpoint {
> > };
> > };
> > };
> 
> 
>That's basically my patch modulo the added "power-domains" and "resets" 
> props, and the node/endpoint rename (of a dubious value, if you ask me ;-)).

Hi Sergei,

after speaking with yourself and Niklas - who I think also spoke with you -
I'd be most grateful if you could repost this series at your convenience,
with the author and other outstanding review addressed.

Thanks.


Re: [PATCH 0/2] arm64: dts: renesas: Update OPPs to support CA53 dfs

2018-02-19 Thread Simon Horman
On Mon, Jan 29, 2018 at 07:21:19PM +0100, Simon Horman wrote:
> Describe frequencies, other than the default for CA53 cores.  This is a
> pre-requisite for using providing alternative frequencies for use with
> CPUFreq with these cores.
> 
> CPUFreq requires Z and Z2 clock support to function.
> That this patchset and that dependency can be found at:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> topic/rcar-gen3-cpufreq-v5
> 
> Dien Pham (2):
>   arm64: dts: r8a7796: Update OPPs to support CA53 dfs
>   arm64: dts: r8a7795: Update OPPs to support CA53 dfs

Applied for v4.17.


[PATCH v9 00/11] Renesas Capture Engine Unit (CEU) V4L2 driver

2018-02-19 Thread Jacopo Mondi
Hello,
   finally I addressed Laurent's comment on ov772x frame rate handling, which
I almost forgot about :)

Also, Sergei reported that the ceu node name should be generic, so I changed it
to "ceu: camera@e821".

All patches but the trivial [11/11] one are now reviewed/acked. Hope this is
last iteration for CEU!

Series based on top of Hans':
[PATCHv2 0/9] media: replace g/s_parm by g/s_frame_interval
and makes use of newly introduced v4l2_g/s_parm_cap() functions from v4l2-common
in CEU's g/s_parm() callbacks.

A branch for testing is available at:
git://jmondi.org/linux ceu/media-tree-parm/v9
with few patches for Migo-R and GR-Peach applied on top of Hans' media-tree/parm
branch.

--
Copying from v7 cover letter:

The 2 new patches in the series:
[11/11] has been added to silence a v4l2-compliance error, and modifies
ov7670 driver to set all fields of 'struct v4l2_mbus_format' during set_format
operation, including ycbcr_enc, quantization and xfer_func. As the patch commit
reports, this suppresses the following v4l2-compliance error:
fail: v4l2-test-formats.cpp(335): ycbcr_enc >= 0xff
v8/v9: Did the same for ov772x

[7/11] has been required by Hans to add frame interval handling to ov772x
driver. As this is quite a big change I kept it in a separate patch to ease
review, it can eventually be squashed on [6/11] if accepted.
v8: Calculate PLL divider/multiplier in place of using static tables.
v9: Address Laurent's comment on frame rate handling patch

If for TW9910 video decoder the same is required (frame interval handling) I'm
in favour of moving that driver to staging as it was proposed for ov772x before
this series.

--
v4l2-compliance:

v4l2-compliance requires a fix to relax buffer type check on s/g_parm
(see Hans' "[PATCHv2 9/9] vidioc-g-parm.rst: also allow _MPLANE buffer types")
Issue is addressed by patch
"[PATCH] v4l2-compliance: Relax g/s_parm type check"
just sent to linux-media mailing list.

With that fixed, I have v4l2-compliance exhausting my tiny GR-Peach 6MB of
available system, and thus failing when allocating buffers to test "Buffer
IOCTLs":

renesas-ceu e821.camera: dma_alloc_coherent of size 307200 failed
Unable to request buffers: Cannot allocate memory (12).

Also, Hans, you asked me to run v4l2-compliance with the -f option, I cannot do
that on my tiny GR-Peach as with its limited available system memory it cannot
allocate the number of requested buffers for that test.
I won't stress here why I cannot do that on Migo-R, long story short: I need a
special compiler with DSP support to run anything but the little
initramfs I have received for SH7722. I've been able to tweak yavta to work and
test capture and frame rate handling with it, but v4l2-compliance is much more
complex and I don't think I'll be able run it on that platform.

I have verified capture still works properly in all supported image formats.
Below v4l2-compliance output, with 2 errors due to memory constraints on my
test platform. Hope this won't cause issues with ceu driver acceptance now
that we're so close to have it finalized :)

--
v4l2-compliance SHA   : 372109e86a4de045c642a808fc97b2e7ca5e6c93

Driver Info:
Driver name   : renesas-ceu
Card type : Renesas CEU
Bus info  : platform:renesas-ceu-e821.c
Driver version: 4.15.0
Capabilities  : 0x84201000
Video Capture Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04201000
Video Capture Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test 

[PATCH v9 02/11] include: media: Add Renesas CEU driver interface

2018-02-19 Thread Jacopo Mondi
Add renesas-ceu header file.

Do not remove the existing sh_mobile_ceu.h one as long as the original
driver does not go away.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
---
 include/media/drv-intf/renesas-ceu.h | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 include/media/drv-intf/renesas-ceu.h

diff --git a/include/media/drv-intf/renesas-ceu.h 
b/include/media/drv-intf/renesas-ceu.h
new file mode 100644
index 000..52841d1
--- /dev/null
+++ b/include/media/drv-intf/renesas-ceu.h
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * renesas-ceu.h - Renesas CEU driver interface
+ *
+ * Copyright 2017-2018 Jacopo Mondi 
+ */
+
+#ifndef __MEDIA_DRV_INTF_RENESAS_CEU_H__
+#define __MEDIA_DRV_INTF_RENESAS_CEU_H__
+
+#define CEU_MAX_SUBDEVS2
+
+struct ceu_async_subdev {
+   unsigned long flags;
+   unsigned char bus_width;
+   unsigned char bus_shift;
+   unsigned int i2c_adapter_id;
+   unsigned int i2c_address;
+};
+
+struct ceu_platform_data {
+   unsigned int num_subdevs;
+   struct ceu_async_subdev subdevs[CEU_MAX_SUBDEVS];
+};
+
+#endif /* ___MEDIA_DRV_INTF_RENESAS_CEU_H__ */
-- 
2.7.4



[PATCH v9 01/11] dt-bindings: media: Add Renesas CEU bindings

2018-02-19 Thread Jacopo Mondi
Add bindings documentation for Renesas Capture Engine Unit (CEU).

Signed-off-by: Jacopo Mondi 
Reviewed-by: Rob Herring 
Reviewed-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
---
 .../devicetree/bindings/media/renesas,ceu.txt  | 81 ++
 1 file changed, 81 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt

diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
b/Documentation/devicetree/bindings/media/renesas,ceu.txt
new file mode 100644
index 000..3fc66df
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
@@ -0,0 +1,81 @@
+Renesas Capture Engine Unit (CEU)
+--
+
+The Capture Engine Unit is the image capture interface found in the Renesas
+SH Mobile and RZ SoCs.
+
+The interface supports a single parallel input with data bus width of 8 or 16
+bits.
+
+Required properties:
+- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1H
+  and RZ/A1M SoCs.
+- reg: Registers address base and size.
+- interrupts: The interrupt specifier.
+
+The CEU supports a single parallel input and should contain a single 'port'
+subnode with a single 'endpoint'. Connection to input devices are modeled
+according to the video interfaces OF bindings specified in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Optional endpoint properties applicable to parallel input bus described in
+the above mentioned "video-interfaces.txt" file are supported.
+
+- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH 
respectively.
+  If property is not present, default is active high.
+- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH 
respectively.
+  If property is not present, default is active high.
+
+Example:
+
+The example describes the connection between the Capture Engine Unit and an
+OV7670 image sensor connected to i2c1 interface.
+
+ceu: ceu@e821 {
+   reg = <0xe821 0x209c>;
+   compatible = "renesas,r7s72100-ceu";
+   interrupts = ;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+
+   port {
+   ceu_in: endpoint {
+   remote-endpoint = <_out>;
+
+   hsync-active = <1>;
+   vsync-active = <0>;
+   };
+   };
+};
+
+i2c1: i2c@fcfee400 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   status = "okay";
+
+   clock-frequency = <10>;
+
+   ov7670: camera@21 {
+   compatible = "ovti,ov7670";
+   reg = <0x21>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   reset-gpios = < 11 GPIO_ACTIVE_LOW>;
+   powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
+
+   port {
+   ov7670_out: endpoint {
+   remote-endpoint = <_in>;
+
+   hsync-active = <1>;
+   vsync-active = <0>;
+   };
+   };
+   };
+};
-- 
2.7.4



Re: [PATCH] sh_eth: simplify sh_eth_check_reset()

2018-02-19 Thread David Miller
From: Sergei Shtylyov 
Date: Sun, 18 Feb 2018 18:21:05 +0300

> The *while* loop in this function  can be turned into a normal *for* loop.
> And getting rid  of the  single return point saves us a few more LoCs...
> 
> Signed-off-by: Sergei Shtylyov 

Applied to net-next, thanks Sergei.

> The patch is against DaveM's 'net-next.git' repo.

It is actually easier for you (and me) if you just indicate this in
your Subject like "[PATCH net-next]" in the future.

Thank you.


[PATCH v9 06/11] media: i2c: ov772x: Remove soc_camera dependencies

2018-02-19 Thread Jacopo Mondi
Remove soc_camera framework dependencies from ov772x sensor driver.
- Handle clock and gpios
- Register async subdevice
- Remove soc_camera specific g/s_mbus_config operations
- Change image format colorspace from JPEG to SRGB as the two use the
  same colorspace information but JPEG makes assumptions on color
  components quantization that do not apply to the sensor
- Remove sizes crop from get_selection as driver can't scale
- Add kernel doc to driver interface header file
- Adjust build system

This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera-based CEU driver.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/i2c/Kconfig  |  11 +++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/ov772x.c | 172 ++---
 include/media/i2c/ov772x.h |   6 +-
 4 files changed, 133 insertions(+), 57 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9f18cd2..e71e968 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -645,6 +645,17 @@ config VIDEO_OV5670
  To compile this driver as a module, choose M here: the
  module will be called ov5670.
 
+config VIDEO_OV772X
+   tristate "OmniVision OV772x sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV772x camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov772x.
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index c0f94cd..b0489a1 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
 obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
 obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 8063835..23106d7 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * ov772x Camera Driver
  *
+ * Copyright (C) 2017 Jacopo Mondi 
+ *
  * Copyright (C) 2008 Renesas Solutions Corp.
  * Kuninori Morimoto 
  *
@@ -9,27 +12,25 @@
  * Copyright 2006-7 Jonathan Corbet 
  * Copyright (C) 2008 Magnus Damm
  * Copyright (C) 2008, Guennadi Liakhovetski 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 
 #include 
-#include 
-#include 
+
 #include 
-#include 
+#include 
 #include 
+#include 
 
 /*
  * register offset
@@ -393,8 +394,10 @@ struct ov772x_win_size {
 struct ov772x_priv {
struct v4l2_subdevsubdev;
struct v4l2_ctrl_handler  hdl;
-   struct v4l2_clk  *clk;
+   struct clk   *clk;
struct ov772x_camera_info*info;
+   struct gpio_desc *pwdn_gpio;
+   struct gpio_desc *rstb_gpio;
const struct ov772x_color_format *cfmt;
const struct ov772x_win_size *win;
unsigned shortflag_vflip:1;
@@ -409,7 +412,7 @@ struct ov772x_priv {
 static const struct ov772x_color_format ov772x_cfmts[] = {
{
.code   = MEDIA_BUS_FMT_YUYV8_2X8,
-   .colorspace = V4L2_COLORSPACE_JPEG,
+   .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3   = 0x0,
.dsp4   = DSP_OFMT_YUV,
.com3   = SWAP_YUV,
@@ -417,7 +420,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
},
{
.code   = MEDIA_BUS_FMT_YVYU8_2X8,
-   .colorspace = V4L2_COLORSPACE_JPEG,
+   .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3   = UV_ON,
.dsp4   = DSP_OFMT_YUV,
.com3   = SWAP_YUV,
@@ -425,7 +428,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
},
{
.code   = MEDIA_BUS_FMT_UYVY8_2X8,
-   .colorspace = V4L2_COLORSPACE_JPEG,
+   .colorspace = 

[PATCH v9 05/11] media: i2c: Copy ov772x soc_camera sensor driver

2018-02-19 Thread Jacopo Mondi
Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.
No modification to KConfig and Makefile as soc_camera framework
dependencies need to be removed first in next commit.

Signed-off-by: Jacopo Mondi 
Acked-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
---
 drivers/media/i2c/ov772x.c | 1124 
 1 file changed, 1124 insertions(+)
 create mode 100644 drivers/media/i2c/ov772x.c

diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
new file mode 100644
index 000..8063835
--- /dev/null
+++ b/drivers/media/i2c/ov772x.c
@@ -0,0 +1,1124 @@
+/*
+ * ov772x Camera Driver
+ *
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov7670 and soc_camera_platform driver,
+ *
+ * Copyright 2006-7 Jonathan Corbet 
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * register offset
+ */
+#define GAIN0x00 /* AGC - Gain control gain setting */
+#define BLUE0x01 /* AWB - Blue channel gain setting */
+#define RED 0x02 /* AWB - Red   channel gain setting */
+#define GREEN   0x03 /* AWB - Green channel gain setting */
+#define COM10x04 /* Common control 1 */
+#define BAVG0x05 /* U/B Average Level */
+#define GAVG0x06 /* Y/Gb Average Level */
+#define RAVG0x07 /* V/R Average Level */
+#define AECH0x08 /* Exposure Value - AEC MSBs */
+#define COM20x09 /* Common control 2 */
+#define PID 0x0A /* Product ID Number MSB */
+#define VER 0x0B /* Product ID Number LSB */
+#define COM30x0C /* Common control 3 */
+#define COM40x0D /* Common control 4 */
+#define COM50x0E /* Common control 5 */
+#define COM60x0F /* Common control 6 */
+#define AEC 0x10 /* Exposure Value */
+#define CLKRC   0x11 /* Internal clock */
+#define COM70x12 /* Common control 7 */
+#define COM80x13 /* Common control 8 */
+#define COM90x14 /* Common control 9 */
+#define COM10   0x15 /* Common control 10 */
+#define REG16   0x16 /* Register 16 */
+#define HSTART  0x17 /* Horizontal sensor size */
+#define HSIZE   0x18 /* Horizontal frame (HREF column) end high 8-bit */
+#define VSTART  0x19 /* Vertical frame (row) start high 8-bit */
+#define VSIZE   0x1A /* Vertical sensor size */
+#define PSHFT   0x1B /* Data format - pixel delay select */
+#define MIDH0x1C /* Manufacturer ID byte - high */
+#define MIDL0x1D /* Manufacturer ID byte - low  */
+#define LAEC0x1F /* Fine AEC value */
+#define COM11   0x20 /* Common control 11 */
+#define BDBASE  0x22 /* Banding filter Minimum AEC value */
+#define DBSTEP  0x23 /* Banding filter Maximum Setp */
+#define AEW 0x24 /* AGC/AEC - Stable operating region (upper limit) */
+#define AEB 0x25 /* AGC/AEC - Stable operating region (lower limit) */
+#define VPT 0x26 /* AGC/AEC Fast mode operating region */
+#define REG28   0x28 /* Register 28 */
+#define HOUTSIZE0x29 /* Horizontal data output size MSBs */
+#define EXHCH   0x2A /* Dummy pixel insert MSB */
+#define EXHCL   0x2B /* Dummy pixel insert LSB */
+#define VOUTSIZE0x2C /* Vertical data output size MSBs */
+#define ADVFL   0x2D /* LSB of insert dummy lines in Vertical direction */
+#define ADVFH   0x2E /* MSG of insert dummy lines in Vertical direction */
+#define YAVE0x2F /* Y/G Channel Average value */
+#define LUMHTH  0x30 /* Histogram AEC/AGC Luminance high level threshold */
+#define LUMLTH  0x31 /* Histogram AEC/AGC Luminance low  level threshold */
+#define HREF0x32 /* Image start and size control */
+#define DM_LNL  0x33 /* Dummy line low  8 bits */
+#define DM_LNH  0x34 /* Dummy line high 8 bits */
+#define ADOFF_B 0x35 /* AD offset compensation value for B  channel */
+#define ADOFF_R 0x36 /* AD offset compensation value for R  channel */
+#define ADOFF_GB0x37 /* AD offset compensation value for Gb channel */
+#define ADOFF_GR0x38 /* AD offset compensation value for Gr channel */
+#define OFF_B   0x39 /* Analog process B  channel offset value */
+#define OFF_R   0x3A /* Analog process R  channel offset value */
+#define OFF_GB  0x3B /* Analog process Gb channel offset value */
+#define OFF_GR  0x3C /* Analog process Gr 

[PATCH v9 09/11] media: i2c: tw9910: Remove soc_camera dependencies

2018-02-19 Thread Jacopo Mondi
Remove soc_camera framework dependencies from tw9910 sensor driver.
- Handle clock and gpios
- Register async subdevice
- Remove soc_camera specific g/s_mbus_config operations
- Add kernel doc to driver interface header file
- Adjust build system

This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera-based CEU driver.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
---
 drivers/media/i2c/Kconfig  |   9 +++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/tw9910.c | 162 -
 include/media/i2c/tw9910.h |   9 +++
 4 files changed, 120 insertions(+), 61 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index e71e968..0460613 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -423,6 +423,15 @@ config VIDEO_TW9906
  To compile this driver as a module, choose M here: the
  module will be called tw9906.
 
+config VIDEO_TW9910
+   tristate "Techwell TW9910 video decoder"
+   depends on VIDEO_V4L2 && I2C
+   ---help---
+ Support for Techwell TW9910 NTSC/PAL/SECAM video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9910.
+
 config VIDEO_VPX3220
tristate "vpx3220a, vpx3216b & vpx3214c video decoders"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index b0489a1..23c3ac6 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
 obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
 obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
 obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
+obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
 obj-$(CONFIG_VIDEO_CS3308) += cs3308.o
 obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
 obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
index bdb5e0a..96792df 100644
--- a/drivers/media/i2c/tw9910.c
+++ b/drivers/media/i2c/tw9910.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * tw9910 Video Driver
  *
+ * Copyright (C) 2017 Jacopo Mondi 
+ *
  * Copyright (C) 2008 Renesas Solutions Corp.
  * Kuninori Morimoto 
  *
@@ -10,12 +13,10 @@
  * Copyright 2006-7 Jonathan Corbet 
  * Copyright (C) 2008 Magnus Damm
  * Copyright (C) 2008, Guennadi Liakhovetski 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -25,9 +26,7 @@
 #include 
 #include 
 
-#include 
 #include 
-#include 
 #include 
 
 #define GET_ID(val)  ((val & 0xF8) >> 3)
@@ -228,8 +227,10 @@ struct tw9910_scale_ctrl {
 
 struct tw9910_priv {
struct v4l2_subdev  subdev;
-   struct v4l2_clk *clk;
+   struct clk  *clk;
struct tw9910_video_info*info;
+   struct gpio_desc*pdn_gpio;
+   struct gpio_desc*rstb_gpio;
const struct tw9910_scale_ctrl  *scale;
v4l2_std_id norm;
u32 revision;
@@ -582,13 +583,66 @@ static int tw9910_s_register(struct v4l2_subdev *sd,
 }
 #endif
 
+static int tw9910_power_on(struct tw9910_priv *priv)
+{
+   struct i2c_client *client = v4l2_get_subdevdata(>subdev);
+   int ret;
+
+   if (priv->clk) {
+   ret = clk_prepare_enable(priv->clk);
+   if (ret)
+   return ret;
+   }
+
+   if (priv->pdn_gpio) {
+   gpiod_set_value(priv->pdn_gpio, 0);
+   usleep_range(500, 1000);
+   }
+
+   /*
+* FIXME: The reset signal is connected to a shared GPIO on some
+* platforms (namely the SuperH Migo-R). Until a framework becomes
+* available to handle this cleanly, request the GPIO temporarily
+* to avoid conflicts.
+*/
+   priv->rstb_gpio = gpiod_get_optional(>dev, "rstb",
+GPIOD_OUT_LOW);
+   if (IS_ERR(priv->rstb_gpio)) {
+   dev_info(>dev, "Unable to get GPIO \"rstb\"");
+   return PTR_ERR(priv->rstb_gpio);
+   }
+
+   if (priv->rstb_gpio) {
+   gpiod_set_value(priv->rstb_gpio, 1);
+   usleep_range(500, 1000);
+   gpiod_set_value(priv->rstb_gpio, 0);
+   usleep_range(500, 1000);
+
+   gpiod_put(priv->rstb_gpio);
+   }
+
+   return 0;
+}
+
+static int tw9910_power_off(struct tw9910_priv *priv)
+{
+   

[PATCH v9 07/11] media: i2c: ov772x: Support frame interval handling

2018-02-19 Thread Jacopo Mondi
Add support to ov772x driver for frame intervals handling and enumeration.
Tested with 10MHz and 24MHz input clock at VGA and QVGA resolutions for
10, 15 and 30 frame per second rates.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/i2c/ov772x.c | 212 +
 1 file changed, 195 insertions(+), 17 deletions(-)

diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 23106d7..eba71d9 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -250,6 +250,7 @@
 #define AEC_1p2 0x10   /*  01: 1/2  window */
 #define AEC_1p4 0x20   /*  10: 1/4  window */
 #define AEC_2p3 0x30   /*  11: Low 2/3 window */
+#define COM4_RESERVED   0x01   /* Reserved bit */

 /* COM5 */
 #define AFR_ON_OFF  0x80   /* Auto frame rate control ON/OFF selection */
@@ -267,6 +268,10 @@
/* AEC max step control */
 #define AEC_NO_LIMIT0x01   /*   0 : AEC incease step has limit */
/*   1 : No limit to AEC increase step */
+/* CLKRC */
+   /* Input clock divider register */
+#define CLKRC_RESERVED  0x80   /* Reserved bit */
+#define CLKRC_DIV(n)((n) - 1)

 /* COM7 */
/* SCCB Register Reset */
@@ -373,6 +378,19 @@
 #define VERSION(pid, ver) ((pid<<8)|(ver&0xFF))

 /*
+ * PLL multipliers
+ */
+struct {
+   unsigned int mult;
+   u8 com4;
+} ov772x_pll[] = {
+   { 1, PLL_BYPASS, },
+   { 4, PLL_4x, },
+   { 6, PLL_6x, },
+   { 8, PLL_8x, },
+};
+
+/*
  * struct
  */

@@ -388,6 +406,7 @@ struct ov772x_color_format {
 struct ov772x_win_size {
char *name;
unsigned char com7_bit;
+   unsigned int  sizeimage;
struct v4l2_rect  rect;
 };

@@ -404,6 +423,7 @@ struct ov772x_priv {
unsigned shortflag_hflip:1;
/* band_filter = COM8[5] ? 256 - BDBASE : 0 */
unsigned shortband_filter;
+   unsigned int  fps;
 };

 /*
@@ -487,27 +507,35 @@ static const struct ov772x_color_format ov772x_cfmts[] = {

 static const struct ov772x_win_size ov772x_win_sizes[] = {
{
-   .name = "VGA",
-   .com7_bit = SLCT_VGA,
+   .name   = "VGA",
+   .com7_bit   = SLCT_VGA,
+   .sizeimage  = 510 * 748,
.rect = {
-   .left = 140,
-   .top = 14,
-   .width = VGA_WIDTH,
-   .height = VGA_HEIGHT,
+   .left   = 140,
+   .top= 14,
+   .width  = VGA_WIDTH,
+   .height = VGA_HEIGHT,
},
}, {
-   .name = "QVGA",
-   .com7_bit = SLCT_QVGA,
+   .name   = "QVGA",
+   .com7_bit   = SLCT_QVGA,
+   .sizeimage  = 278 * 576,
.rect = {
-   .left = 252,
-   .top = 6,
-   .width = QVGA_WIDTH,
-   .height = QVGA_HEIGHT,
+   .left   = 252,
+   .top= 6,
+   .width  = QVGA_WIDTH,
+   .height = QVGA_HEIGHT,
},
},
 };

 /*
+ * frame rate settings lists
+ */
+unsigned int ov772x_frame_intervals[] = { 5, 10, 15, 20, 30, 60 };
+#define OV772X_N_FRAME_INTERVALS ARRAY_SIZE(ov772x_frame_intervals)
+
+/*
  * general function
  */

@@ -574,6 +602,126 @@ static int ov772x_s_stream(struct v4l2_subdev *sd, int 
enable)
return 0;
 }

+static int ov772x_set_frame_rate(struct ov772x_priv *priv,
+struct v4l2_fract *tpf,
+const struct ov772x_color_format *cfmt,
+const struct ov772x_win_size *win)
+{
+   struct i2c_client *client = v4l2_get_subdevdata(>subdev);
+   unsigned long fin = clk_get_rate(priv->clk);
+   unsigned int fps = tpf->numerator ?
+  tpf->denominator / tpf->numerator :
+  tpf->denominator;
+   unsigned int best_diff;
+   unsigned int fsize;
+   unsigned int pclk;
+   unsigned int diff;
+   unsigned int idx;
+   unsigned int i;
+   u8 clkrc = 0;
+   u8 com4 = 0;
+   int ret;
+
+   /* Approximate to the closest supported frame interval. */
+   best_diff = ~0L;
+   for (i = 0, idx = 0; i < OV772X_N_FRAME_INTERVALS; i++) {
+   diff = abs(fps - ov772x_frame_intervals[i]);
+   if (diff < best_diff) {
+   idx = i;
+   best_diff = diff;
+   }
+   }
+  

[renesas:soc-for-v4.17 6/6] drivers/soc/renesas/r8a77980-sysc.c:12:10: fatal error: dt-bindings/power/r8a77980-sysc.h: No such file or directory

2018-02-19 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
soc-for-v4.17
head:   8b49a80541c565d5d8482f15350ab861f60455a1
commit: 8b49a80541c565d5d8482f15350ab861f60455a1 [6/6] soc: renesas: rcar-sysc: 
add R8A77980 support
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 8b49a80541c565d5d8482f15350ab861f60455a1
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/soc/renesas/r8a77980-sysc.c:12:10: fatal error: 
>> dt-bindings/power/r8a77980-sysc.h: No such file or directory
#include 
 ^~~
   compilation terminated.

vim +12 drivers/soc/renesas/r8a77980-sysc.c

11  
  > 12  #include 
13  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


[PATCH v9 03/11] media: platform: Add Renesas CEU driver

2018-02-19 Thread Jacopo Mondi
Add driver for Renesas Capture Engine Unit (CEU).

The CEU interface supports capturing 'data' (YUV422) and 'images'
(NV[12|21|16|61]).

This driver aims to replace the soc_camera-based sh_mobile_ceu one.

Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
platform GR-Peach.

Tested with ov7725 camera sensor on SH4 platform Migo-R.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
---
 drivers/media/platform/Kconfig   |9 +
 drivers/media/platform/Makefile  |1 +
 drivers/media/platform/renesas-ceu.c | 1661 ++
 3 files changed, 1671 insertions(+)
 create mode 100644 drivers/media/platform/renesas-ceu.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 614fbef..f9cc058 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI
  To compile this driver as a module, choose M here: the module
  will be called stm32-dcmi.
 
+config VIDEO_RENESAS_CEU
+   tristate "Renesas Capture Engine Unit (CEU) driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_FWNODE
+   ---help---
+ This is a v4l2 driver for the Renesas CEU Interface
+
 source "drivers/media/platform/soc_camera/Kconfig"
 source "drivers/media/platform/exynos4-is/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 7f30804..85e1121 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)+= sh_vou.o
 obj-$(CONFIG_SOC_CAMERA)   += soc_camera/
 
 obj-$(CONFIG_VIDEO_RCAR_DRIF)  += rcar_drif.o
+obj-$(CONFIG_VIDEO_RENESAS_CEU)+= renesas-ceu.o
 obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o
 obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
diff --git a/drivers/media/platform/renesas-ceu.c 
b/drivers/media/platform/renesas-ceu.c
new file mode 100644
index 000..d0ac500
--- /dev/null
+++ b/drivers/media/platform/renesas-ceu.c
@@ -0,0 +1,1661 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface
+ * Copyright (C) 2017-2018 Jacopo Mondi 
+ *
+ * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c"
+ * Copyright (C) 2008 Magnus Damm
+ *
+ * Based on V4L2 Driver for PXA camera host - "pxa_camera.c",
+ * Copyright (C) 2006, Sascha Hauer, Pengutronix
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME"renesas-ceu"
+
+/* CEU registers offsets and masks. */
+#define CEU_CAPSR  0x00 /* Capture start register  */
+#define CEU_CAPCR  0x04 /* Capture control register*/
+#define CEU_CAMCR  0x08 /* Capture interface control register  */
+#define CEU_CAMOR  0x10 /* Capture interface offset register   */
+#define CEU_CAPWR  0x14 /* Capture interface width register*/
+#define CEU_CAIFR  0x18 /* Capture interface input format register */
+#define CEU_CRCNTR 0x28 /* CEU register control register   */
+#define CEU_CRCMPR 0x2c /* CEU register forcible control register  */
+#define CEU_CFLCR  0x30 /* Capture filter control register */
+#define CEU_CFSZR  0x34 /* Capture filter size clip register   */
+#define CEU_CDWDR  0x38 /* Capture destination width register  */
+#define CEU_CDAYR  0x3c /* Capture data address Y register */
+#define CEU_CDACR  0x40 /* Capture data address C register */
+#define CEU_CFWCR  0x5c /* Firewall operation control register */
+#define CEU_CDOCR  0x64 /* Capture data output control register*/
+#define CEU_CEIER  0x70 /* Capture event interrupt enable register */
+#define CEU_CETCR  0x74 /* Capture event flag clear register   */
+#define CEU_CSTSR  0x7c /* Capture status register */
+#define CEU_CSRTR  0x80 /* Capture software reset register */
+
+/* Data synchronous fetch mode. */
+#define CEU_CAMCR_JPEG BIT(4)
+
+/* Input components ordering: CEU_CAMCR.DTARY field. */
+#define CEU_CAMCR_DTARY_8_UYVY (0x00 << 8)
+#define CEU_CAMCR_DTARY_8_VYUY (0x01 << 8)
+#define 

[PATCH v9 04/11] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

2018-02-19 Thread Jacopo Mondi
Add Capture Engine Unit (CEU) node to device tree.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
---
 arch/arm/boot/dts/r7s72100.dtsi | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index ab9645a..23e05ce 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -135,9 +135,9 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", 
"renesas,cpg-mstp-clocks";
reg = <0xfcfe042c 4>;
-   clocks = <_clk>;
-   clock-indices = ;
-   clock-output-names = "rtc";
+   clocks = <_clk>, <_clk>;
+   clock-indices = ;
+   clock-output-names = "ceu", "rtc";
};
 
mstp7_clks: mstp7_clks@fcfe0430 {
@@ -667,4 +667,13 @@
power-domains = <_clocks>;
status = "disabled";
};
+
+   ceu: camera@e821 {
+   reg = <0xe821 0x3000>;
+   compatible = "renesas,r7s72100-ceu";
+   interrupts = ;
+   clocks = <_clks R7S72100_CLK_CEU>;
+   power-domains = <_clocks>;
+   status = "disabled";
+   };
 };
-- 
2.7.4



Re: [renesas:soc-for-v4.17 6/6] drivers/soc/renesas/r8a77980-sysc.c:12:10: fatal error: dt-bindings/power/r8a77980-sysc.h: No such file or directory

2018-02-19 Thread Simon Horman
On Tue, Feb 20, 2018 at 12:02:58AM +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> soc-for-v4.17
> head:   8b49a80541c565d5d8482f15350ab861f60455a1
> commit: 8b49a80541c565d5d8482f15350ab861f60455a1 [6/6] soc: renesas: 
> rcar-sysc: add R8A77980 support
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> git checkout 8b49a80541c565d5d8482f15350ab861f60455a1
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
> >> drivers/soc/renesas/r8a77980-sysc.c:12:10: fatal error: 
> >> dt-bindings/power/r8a77980-sysc.h: No such file or directory
> #include 
>  ^~~
>compilation terminated.
> 
> vim +12 drivers/soc/renesas/r8a77980-sysc.c
> 
> 11
>   > 12#include 
> 13

Ooops. I missed that

8b49a80541c5 ("soc: renesas: rcar-sysc: add R8A77980 support")

depends on

eaf8509d3d97 ("dt-bindings: power: add R8A77980 SYSC power domain definitions")

Perhaps I should just squash the latter into the former.

Sergei, Geert, any thoughts?



[PATCH] arm64: dts: r8a77965-salvator-xs: Add support for Salvator-XS with R-Car M3-N

2018-02-19 Thread Geert Uytterhoeven
From: Takeshi Kihara 

Add initial support for the Renesas Salvator-XS (Salvator-X 2nd version)
development board equipped with an R-Car M3-N SiP.

Most features are enabled through the shared salvator-xs.dtsi board
description.  The memory configuration is specific to the M3-N SiP.

Signed-off-by: Takeshi Kihara 
[geert: Switch to SPDX-License-Identifier, update patch description]
Signed-off-by: Geert Uytterhoeven 
---
Against renesas-devel-20180212-v4.16-rc1 with Jacopo Mondi's "[PATCH
00/15] R-Car M3-N initial support"
(https://www.spinics.net/lists/arm-kernel/msg634121.html).
See branches topic/r8a77965-v1 and topic/r8a77965-v1+ in
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.

 arch/arm64/boot/dts/renesas/Makefile|  2 +-
 .../arm64/boot/dts/renesas/r8a77965-salvator-xs.dts | 21 +
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts

diff --git a/arch/arm64/boot/dts/renesas/Makefile 
b/arch/arm64/boot/dts/renesas/Makefile
index 3680ecd638c44482..e9b525123a2e5f9a 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -7,6 +7,6 @@ dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-h3ulcb-kf.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-m3ulcb-kf.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
-dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb
+dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb r8a77965-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
 dtb-$(CONFIG_ARCH_R8A77995) += r8a77995-draak.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
new file mode 100644
index ..8a45fc43348d9adc
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Salvator-X 2nd version board
+ *
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+#include "r8a77965.dtsi"
+#include "salvator-xs.dtsi"
+
+/ {
+   model = "Renesas Salvator-X 2nd version board based on r8a77965";
+   compatible = "renesas,salvator-xs", "renesas,r8a77965";
+
+   memory@4800 {
+   device_type = "memory";
+   /* first 128MB is reserved for secure area. */
+   reg = <0x0 0x4800 0x0 0x7800>;
+   };
+};
-- 
2.7.4



Re: [renesas:soc-for-v4.17 6/6] drivers/soc/renesas/r8a77980-sysc.c:12:10: fatal error: dt-bindings/power/r8a77980-sysc.h: No such file or directory

2018-02-19 Thread Geert Uytterhoeven
Hi Simon,

On Mon, Feb 19, 2018 at 6:47 PM, Simon Horman  wrote:
> On Tue, Feb 20, 2018 at 12:02:58AM +0800, kbuild test robot wrote:
>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
>> soc-for-v4.17
>> head:   8b49a80541c565d5d8482f15350ab861f60455a1
>> commit: 8b49a80541c565d5d8482f15350ab861f60455a1 [6/6] soc: renesas: 
>> rcar-sysc: add R8A77980 support
>> config: i386-allmodconfig (attached as .config)
>> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
>> reproduce:
>> git checkout 8b49a80541c565d5d8482f15350ab861f60455a1
>> # save the attached .config to linux build tree
>> make ARCH=i386
>>
>> All errors (new ones prefixed by >>):
>>
>> >> drivers/soc/renesas/r8a77980-sysc.c:12:10: fatal error: 
>> >> dt-bindings/power/r8a77980-sysc.h: No such file or directory
>> #include 
>>  ^~~
>>compilation terminated.
>>
>> vim +12 drivers/soc/renesas/r8a77980-sysc.c
>>
>> 11
>>   > 12#include 
>> 13
>
> Ooops. I missed that
>
> 8b49a80541c5 ("soc: renesas: rcar-sysc: add R8A77980 support")
>
> depends on
>
> eaf8509d3d97 ("dt-bindings: power: add R8A77980 SYSC power domain 
> definitions")
>
> Perhaps I should just squash the latter into the former.
>
> Sergei, Geert, any thoughts?

Just queue them up in the same branch, like you did before for other SoCs?

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 v2] arm64: dts: renesas: Add support for Salvator-XS with R-Car M3-N

2018-02-19 Thread Geert Uytterhoeven
From: Takeshi Kihara 

Add initial support for the Renesas Salvator-XS (Salvator-X 2nd version)
development board equipped with an R-Car M3-N SiP.

Most features are enabled through the shared salvator-xs.dtsi board
description.  The memory configuration is specific to the M3-N SiP.

Signed-off-by: Takeshi Kihara 
[geert: Switch to SPDX-License-Identifier, update patch description]
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Fix patch prefix.
---
 arch/arm64/boot/dts/renesas/Makefile|  2 +-
 .../arm64/boot/dts/renesas/r8a77965-salvator-xs.dts | 21 +
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts

diff --git a/arch/arm64/boot/dts/renesas/Makefile 
b/arch/arm64/boot/dts/renesas/Makefile
index 3680ecd638c44482..e9b525123a2e5f9a 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -7,6 +7,6 @@ dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-h3ulcb-kf.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-m3ulcb-kf.dtb
 dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
-dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb
+dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb r8a77965-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
 dtb-$(CONFIG_ARCH_R8A77995) += r8a77995-draak.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
new file mode 100644
index ..8a45fc43348d9adc
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Salvator-X 2nd version board
+ *
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+#include "r8a77965.dtsi"
+#include "salvator-xs.dtsi"
+
+/ {
+   model = "Renesas Salvator-X 2nd version board based on r8a77965";
+   compatible = "renesas,salvator-xs", "renesas,r8a77965";
+
+   memory@4800 {
+   device_type = "memory";
+   /* first 128MB is reserved for secure area. */
+   reg = <0x0 0x4800 0x0 0x7800>;
+   };
+};
-- 
2.7.4



[PATCH v9 11/11] media: i2c: ov7670: Fully set mbus frame fmt

2018-02-19 Thread Jacopo Mondi
The sensor driver sets mbus format colorspace information and sizes,
but not ycbcr encoding, quantization and xfer function. When supplied
with an badly initialized mbus frame format structure, those fields
need to be set explicitly not to leave them uninitialized. This is
tested by v4l2-compliance, which supplies a mbus format description
structure and checks for all fields to be properly set.

Without this commit, v4l2-compliance fails when testing formats with:
fail: v4l2-test-formats.cpp(335): ycbcr_enc >= 0xff

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/ov7670.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 25b26d4..61c472e 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -996,6 +996,10 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
fmt->height = wsize->height;
fmt->colorspace = ov7670_formats[index].colorspace;
 
+   fmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
+   fmt->quantization = V4L2_QUANTIZATION_DEFAULT;
+   fmt->xfer_func = V4L2_XFER_FUNC_DEFAULT;
+
info->format = *fmt;
 
return 0;
-- 
2.7.4



[PATCH v9 08/11] media: i2c: Copy tw9910 soc_camera sensor driver

2018-02-19 Thread Jacopo Mondi
Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.
No modification to KConfig and Makefile as soc_camera framework
dependencies need to be removed first in next commit.

Signed-off-by: Jacopo Mondi 
Acked-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
---
 drivers/media/i2c/tw9910.c | 999 +
 1 file changed, 999 insertions(+)
 create mode 100644 drivers/media/i2c/tw9910.c

diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
new file mode 100644
index 000..bdb5e0a
--- /dev/null
+++ b/drivers/media/i2c/tw9910.c
@@ -0,0 +1,999 @@
+/*
+ * tw9910 Video Driver
+ *
+ * Copyright (C) 2008 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov772x driver,
+ *
+ * Copyright (C) 2008 Kuninori Morimoto 
+ * Copyright 2006-7 Jonathan Corbet 
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define GET_ID(val)  ((val & 0xF8) >> 3)
+#define GET_REV(val) (val & 0x07)
+
+/*
+ * register offset
+ */
+#define ID 0x00 /* Product ID Code Register */
+#define STATUS10x01 /* Chip Status Register I */
+#define INFORM 0x02 /* Input Format */
+#define OPFORM 0x03 /* Output Format Control Register */
+#define DLYCTR 0x04 /* Hysteresis and HSYNC Delay Control */
+#define OUTCTR10x05 /* Output Control I */
+#define ACNTL1 0x06 /* Analog Control Register 1 */
+#define CROP_HI0x07 /* Cropping Register, High */
+#define VDELAY_LO  0x08 /* Vertical Delay Register, Low */
+#define VACTIVE_LO 0x09 /* Vertical Active Register, Low */
+#define HDELAY_LO  0x0A /* Horizontal Delay Register, Low */
+#define HACTIVE_LO 0x0B /* Horizontal Active Register, Low */
+#define CNTRL1 0x0C /* Control Register I */
+#define VSCALE_LO  0x0D /* Vertical Scaling Register, Low */
+#define SCALE_HI   0x0E /* Scaling Register, High */
+#define HSCALE_LO  0x0F /* Horizontal Scaling Register, Low */
+#define BRIGHT 0x10 /* BRIGHTNESS Control Register */
+#define CONTRAST   0x11 /* CONTRAST Control Register */
+#define SHARPNESS  0x12 /* SHARPNESS Control Register I */
+#define SAT_U  0x13 /* Chroma (U) Gain Register */
+#define SAT_V  0x14 /* Chroma (V) Gain Register */
+#define HUE0x15 /* Hue Control Register */
+#define CORING10x17
+#define CORING20x18 /* Coring and IF compensation */
+#define VBICNTL0x19 /* VBI Control Register */
+#define ACNTL2 0x1A /* Analog Control 2 */
+#define OUTCTR20x1B /* Output Control 2 */
+#define SDT0x1C /* Standard Selection */
+#define SDTR   0x1D /* Standard Recognition */
+#define TEST   0x1F /* Test Control Register */
+#define CLMPG  0x20 /* Clamping Gain */
+#define IAGC   0x21 /* Individual AGC Gain */
+#define AGCGAIN0x22 /* AGC Gain */
+#define PEAKWT 0x23 /* White Peak Threshold */
+#define CLMPL  0x24 /* Clamp level */
+#define SYNCT  0x25 /* Sync Amplitude */
+#define MISSCNT0x26 /* Sync Miss Count Register */
+#define PCLAMP 0x27 /* Clamp Position Register */
+#define VCNTL1 0x28 /* Vertical Control I */
+#define VCNTL2 0x29 /* Vertical Control II */
+#define CKILL  0x2A /* Color Killer Level Control */
+#define COMB   0x2B /* Comb Filter Control */
+#define LDLY   0x2C /* Luma Delay and H Filter Control */
+#define MISC1  0x2D /* Miscellaneous Control I */
+#define LOOP   0x2E /* LOOP Control Register */
+#define MISC2  0x2F /* Miscellaneous Control II */
+#define MVSN   0x30 /* Macrovision Detection */
+#define STATUS20x31 /* Chip STATUS II */
+#define HFREF  0x32 /* H monitor */
+#define CLMD   0x33 /* CLAMP MODE */
+#define IDCNTL 0x34 /* ID Detection Control */
+#define CLCNTL10x35 /* Clamp Control I */
+#define ANAPLLCTL  0x4C
+#define VBIMIN 0x4D
+#define HSLOWCTL   0x4E
+#define WSS3   0x4F
+#define FILLDATA   0x50
+#define SDID   0x51
+#define DID0x52
+#define WSS1   0x53
+#define WSS2   0x54
+#define VVBI   0x55
+#define LCTL6  0x56
+#define LCTL7  

[PATCH v9 10/11] arch: sh: migor: Use new renesas-ceu camera driver

2018-02-19 Thread Jacopo Mondi
Migo-R platform uses sh_mobile_ceu camera driver, which is now being
replaced by a proper V4L2 camera driver named 'renesas-ceu'.

Move Migo-R platform to use the v4l2 renesas-ceu camera driver
interface and get rid of soc_camera defined components used to register
sensor drivers and of platform specific enable/disable routines.

Register clock source and GPIOs for sensor drivers, so they can use
clock and gpio APIs.

Also, memory for CEU video buffers is now reserved with membocks APIs,
and need to be declared as dma_coherent during machine initialization to
remove that architecture specific part from CEU driver.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
Acked-by: Hans Verkuil 
---
 arch/sh/boards/mach-migor/setup.c  | 225 +++--
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c |   2 +-
 2 files changed, 101 insertions(+), 126 deletions(-)

diff --git a/arch/sh/boards/mach-migor/setup.c 
b/arch/sh/boards/mach-migor/setup.c
index 0bcbe58..271dfc2 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -1,17 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Renesas System Solutions Asia Pte. Ltd - Migo-R
  *
  * Copyright (C) 2008 Magnus Damm
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,10 +22,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -45,6 +45,9 @@
  * 0x1800   8GB8   NAND Flash (K9K8G08U0A)
  */
 
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu_dma_membase;
+
 static struct smc91x_platdata smc91x_info = {
.flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
 };
@@ -301,65 +304,24 @@ static struct platform_device migor_lcdc_device = {
},
 };
 
-static struct clk *camera_clk;
-static DEFINE_MUTEX(camera_lock);
-
-static void camera_power_on(int is_tw)
-{
-   mutex_lock(_lock);
-
-   /* Use 10 MHz VIO_CKO instead of 24 MHz to work
-* around signal quality issues on Panel Board V2.1.
-*/
-   camera_clk = clk_get(NULL, "video_clk");
-   clk_set_rate(camera_clk, 1000);
-   clk_enable(camera_clk); /* start VIO_CKO */
-
-   /* use VIO_RST to take camera out of reset */
-   mdelay(10);
-   if (is_tw) {
-   gpio_set_value(GPIO_PTT2, 0);
-   gpio_set_value(GPIO_PTT0, 0);
-   } else {
-   gpio_set_value(GPIO_PTT0, 1);
-   }
-   gpio_set_value(GPIO_PTT3, 0);
-   mdelay(10);
-   gpio_set_value(GPIO_PTT3, 1);
-   mdelay(10); /* wait to let chip come out of reset */
-}
-
-static void camera_power_off(void)
-{
-   clk_disable(camera_clk); /* stop VIO_CKO */
-   clk_put(camera_clk);
-
-   gpio_set_value(GPIO_PTT3, 0);
-   mutex_unlock(_lock);
-}
-
-static int ov7725_power(struct device *dev, int mode)
-{
-   if (mode)
-   camera_power_on(0);
-   else
-   camera_power_off();
-
-   return 0;
-}
-
-static int tw9910_power(struct device *dev, int mode)
-{
-   if (mode)
-   camera_power_on(1);
-   else
-   camera_power_off();
-
-   return 0;
-}
-
-static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
-   .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_platform_data ceu_pdata = {
+   .num_subdevs= 2,
+   .subdevs = {
+   { /* [0] = ov772x */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x21,
+   },
+   { /* [1] = tw9910 */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x45,
+   },
+   },
 };
 
 static struct resource migor_ceu_resources[] = {
@@ -373,18 +335,32 @@ static struct resource migor_ceu_resources[] = {
.start  = evt2irq(0x880),
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   /* place holder for contiguous memory */
-   },
 };
 
 static struct platform_device migor_ceu_device = {
-   .name   = "sh_mobile_ceu",
-   .id = 0, /* "ceu0" clock */
+   .name   = "renesas-ceu",
+   .id = 0, /* ceu.0 */
.num_resources  = ARRAY_SIZE(migor_ceu_resources),
.resource   = migor_ceu_resources,
.dev= {
-   

Re: [PATCH v2 4/5] arm64: dts: renesas: initial Condor board device tree

2018-02-19 Thread Sergei Shtylyov
On 02/19/2018 12:12 PM, Simon Horman wrote:

 Add the initial device  tree for  the R8A77980 SoC based Condor board.
 The board has 1 debug serial port (SCIF0); include support for it, so
 that the serial console can work.

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

 Signed-off-by: Vladimir Barinov 
 Signed-off-by: Sergei Shtylyov 
 Reviewed-by: Geert Uytterhoeven 

 ---
 Changes in version 2:
 - removed the useless "status" property from the SCIF_CLK node;
 - fixed the memory size;
 - added Geert's tag.
>>>
 --- /dev/null
 +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
 @@ -0,0 +1,45 @@
 +// SPDX-License-Identifier: GPL-2.0
 +/*
 + * Device Tree Source for the Condor board
 + *
 + * Copyright (C) 2018 Renesas Electronics Corp.
 + * Copyright (C) 2018 Cogent Embedded, Inc.
 + */
 +
 +/dts-v1/;
 +#include "r8a77980.dtsi"
 +
 +/ {
 +   model = "Renesas Condor board based on r8a77980";
 +   compatible = "renesas,condor", "renesas,r8a77980";
 +
 +   aliases {
 +   serial0 = 
 +   };
 +
 +   chosen {
 +   stdout-path = "serial0:115200n8";
 +   };
 +
 +   memory@4800 {
 +   device_type = "memory";
 +   /* first 128MB is reserved for secure area. */
 +   reg = <0 0x4800 0 0xb800>;
>>>
>>> Shouldn't the size be 0x7800, or is there really 3 GiB of RAM?
>>
>>Ugh, so I finally mixed up limit and size... :-/
> 
> Thanks, I will apply the following, with the memory corrected to 2 GiB.

   Thank you! Just made sure that whatever is in this node in .dts, the RAM size
ends up being 0x7800. Probably U-Boot is too smart. :-)

MBR, Sergei


Re: [PATCH v9 11/11] media: i2c: ov7670: Fully set mbus frame fmt

2018-02-19 Thread Laurent Pinchart
Hi Jacopo,

Thank you for the patch.

On Monday, 19 February 2018 18:59:44 EET Jacopo Mondi wrote:
> The sensor driver sets mbus format colorspace information and sizes,
> but not ycbcr encoding, quantization and xfer function. When supplied
> with an badly initialized mbus frame format structure, those fields
> need to be set explicitly not to leave them uninitialized. This is
> tested by v4l2-compliance, which supplies a mbus format description
> structure and checks for all fields to be properly set.
> 
> Without this commit, v4l2-compliance fails when testing formats with:
> fail: v4l2-test-formats.cpp(335): ycbcr_enc >= 0xff
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/i2c/ov7670.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
> index 25b26d4..61c472e 100644
> --- a/drivers/media/i2c/ov7670.c
> +++ b/drivers/media/i2c/ov7670.c
> @@ -996,6 +996,10 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev
> *sd, fmt->height = wsize->height;
>   fmt->colorspace = ov7670_formats[index].colorspace;

On a side note, if I'm not mistaken the colorspace field is set to SRGB for 
all entries. Shouldn't you hardcode it here and remove the field ?

> + fmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
> + fmt->quantization = V4L2_QUANTIZATION_DEFAULT;
> + fmt->xfer_func = V4L2_XFER_FUNC_DEFAULT;

How about setting the values explicitly instead of relying on defaults ? That 
would be V4L2_YCBCR_ENC_601, V4L2_QUANTIZATION_LIM_RANGE and 
V4L2_XFER_FUNC_SRGB. And could you then check a captured frame to see if the 
sensor outputs limited or full range ?

>   info->format = *fmt;
> 
>   return 0;

-- 
Regards,

Laurent Pinchart



Re: [renesas:soc-for-v4.17 6/6] drivers/soc/renesas/r8a77980-sysc.c:12:10: fatal error: dt-bindings/power/r8a77980-sysc.h: No such file or directory

2018-02-19 Thread Simon Horman
On Mon, Feb 19, 2018 at 06:49:50PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Mon, Feb 19, 2018 at 6:47 PM, Simon Horman  wrote:
> > On Tue, Feb 20, 2018 at 12:02:58AM +0800, kbuild test robot wrote:
> >> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> >> soc-for-v4.17
> >> head:   8b49a80541c565d5d8482f15350ab861f60455a1
> >> commit: 8b49a80541c565d5d8482f15350ab861f60455a1 [6/6] soc: renesas: 
> >> rcar-sysc: add R8A77980 support
> >> config: i386-allmodconfig (attached as .config)
> >> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> >> reproduce:
> >> git checkout 8b49a80541c565d5d8482f15350ab861f60455a1
> >> # save the attached .config to linux build tree
> >> make ARCH=i386
> >>
> >> All errors (new ones prefixed by >>):
> >>
> >> >> drivers/soc/renesas/r8a77980-sysc.c:12:10: fatal error: 
> >> >> dt-bindings/power/r8a77980-sysc.h: No such file or directory
> >> #include 
> >>  ^~~
> >>compilation terminated.
> >>
> >> vim +12 drivers/soc/renesas/r8a77980-sysc.c
> >>
> >> 11
> >>   > 12#include 
> >> 13
> >
> > Ooops. I missed that
> >
> > 8b49a80541c5 ("soc: renesas: rcar-sysc: add R8A77980 support")
> >
> > depends on
> >
> > eaf8509d3d97 ("dt-bindings: power: add R8A77980 SYSC power domain 
> > definitions")
> >
> > Perhaps I should just squash the latter into the former.
> >
> > Sergei, Geert, any thoughts?
> 
> Just queue them up in the same branch, like you did before for other SoCs?

Sure, that seems like the simplest approach.
I'll make it so.


Re: [PATCH v2] videodev2.h: add helper to validate colorspace

2018-02-19 Thread Niklas Söderlund
Hi Hans,

Thanks for your feedback.

[snip]

> > >>> Can you then fix v4l2-compliance to stop testing colorspace 
> > >>> against 0xff
> > >>> ?
> > >> 
> > >> For now I can simply relax this test for subdevs with sources and sinks.
> > > 
> > > You also need to relax it for video nodes with MC drivers, as the DMA
> > > engines don't care about colorspaces.
> > 
> > Yes, they do. Many DMA engines can at least do RGB <-> YUV conversions, so
> > they should get the colorspace info from their source and pass it on to
> > userspace (after correcting for any conversions done by the DMA engine).
> 
> Not in the MC case. Video nodes there only model the DMA engine, and are thus 
> not aware of colorspaces. What MC drivers do is check at stream on time when 
> validating the pipeline that the colorspace set by userspace on the video 
> node 
> corresponds to the colorspace on the source pad of the connected subdev, but 
> that's only to ensure that userspace gets a coherent view of colorspace 
> across 
> the pipeline, not to program the hardware. There could be exceptions, but in 
> the general case, the video node implementation of an MC driver will accept 
> any colorspace and only validate it at stream on time, similarly to how it 
> does for the frame size format instance (and in the frame size case it will 
> usually enforce min/max limits when the DMA engine limits the frame size).

I'm afraid the issue described above by Laurent is what sparked me to 
write this commit to begin with. In my never ending VIN Gen3 patch-set I 
currency need to carry a patch [1] to implement a hack to make sure 
v4l2-compliance do not fail for the VIN Gen3 MC-centric use-case. This 
patch was an attempt to be able to validate the colorspace using the 
magic value 0xff.

I don't feel strongly for this patch in particular and I'm happy to drop 
it.  But I would like to receive some guidance on how to then properly 
be able to handle this problem for the MC-centric VIN driver use-case.  
One option is as you suggested to relax the test in v4l-compliance to 
not check colorspace, but commit [2] is not enough to resolve the issue 
for my MC use-case.

As Laurent stated above, the use-case is that the video device shall 
accept any colorspace set from user-space. This colorspace is then only 
used as stream on time to validate the MC pipeline. The VIN driver do 
not care about colorspace, but I care about not breaking v4l2-compliance 
as I find it's a very useful tool :-)

I'm basing the following on the latest v4l-utils master 
(4665ab1fbab1ddaa)  which contains commit [2]. The core issue is that if 
I do not have a patch like [1] the v4l2-compliance run fails for format 
ioctls:

Format ioctls (Input 0):
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
fail: v4l2-test-formats.cpp(330): !colorspace
fail: v4l2-test-formats.cpp(439): 
testColorspace(pix.pixelformat, pix.colorspace, pix.ycbcr_enc, pix.quantization)
test VIDIOC_G_FMT: FAIL
test VIDIOC_TRY_FMT: OK (Not Supported)
test VIDIOC_S_FMT: OK (Not Supported)
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK

Well that is OK as that fails when colorspace is V4L2_COLORSPACE_DEFAULT 
and that is not valid. If I instead of reverting [1] only test for 
V4L2_COLORSPACE_DEFAULT which would not require this patch to implement:

-   if (!pix->colorspace || pix->colorspace >= 0xff)
+   if (pix->colorspace == V4L2_COLORSPACE_DEFAULT)

I still fail for the format ioctls:

Format ioctls (Input 0):
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
fail: v4l2-test-formats.cpp(336): colorspace >= 0xff
fail: v4l2-test-formats.cpp(439): 
testColorspace(pix.pixelformat, pix.colorspace, pix.ycbcr_enc, pix.quantization)
fail: v4l2-test-formats.cpp(753): Video Capture is valid, but 
TRY_FMT failed to return a format
test VIDIOC_TRY_FMT: FAIL
fail: v4l2-test-formats.cpp(336): colorspace >= 0xff
fail: v4l2-test-formats.cpp(439): 
testColorspace(pix.pixelformat, pix.colorspace, pix.ycbcr_enc, pix.quantization)
fail: v4l2-test-formats.cpp(1018): Video Capture is valid, but 
no S_FMT was implemented
test VIDIOC_S_FMT: FAIL
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK

But now I fail on that colorspace >= 0xff which was what the patch in my 
VIN Gen3 series tries to address but as Laurent points out and I agree 
is not a good idea as the 0xff is a magic number