[PATCH 3/5] media: i2c: mt9t112: Fix code style issues

[Jacopo Mondi]

Fix code style issues reported by checkpatch run with --strict
options. Also fix other non reported style issues manually.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/mt9t112.c | 256 
 1 file changed, 118 insertions(+), 138 deletions(-)

diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
index 6b77dff..6eaf3c6 100644
--- a/drivers/media/i2c/mt9t112.c
+++ b/drivers/media/i2c/mt9t112.c
@@ -35,8 +35,8 @@
 /* #define EXT_CLOCK 2400 */
 
 /
-   macro
-/
+ * macro
+ ***/
 /*
  * frame size
  */
@@ -74,8 +74,8 @@
 #define VAR8(id, offset) _VAR(id, offset, 0x8000)
 
 /
-   struct
-/
+ * struct
+ ***/
 struct mt9t112_format {
u32 code;
enum v4l2_colorspace colorspace;
@@ -96,8 +96,8 @@ struct mt9t112_priv {
 };
 
 /
-   supported format
-/
+ * supported format
+ ***/
 
 static const struct mt9t112_format mt9t112_cfmts[] = {
{
@@ -134,8 +134,8 @@ static const struct mt9t112_format mt9t112_cfmts[] = {
 };
 
 /
-   general function
-/
+ * general function
+ ***/
 static struct mt9t112_priv *to_mt9t112(const struct i2c_client *client)
 {
return container_of(i2c_get_clientdata(client),
@@ -162,15 +162,15 @@ static int __mt9t112_reg_read(const struct i2c_client 
*client, u16 command)
msg[1].buf   = buf;
 
/*
-* if return value of this function is < 0,
-* it mean error.
-* else, under 16bit is valid data.
+* If return value of this function is < 0, it means error, else,
+* below 16bit is valid data.
 */
ret = i2c_transfer(client->adapter, msg, 2);
if (ret < 0)
return ret;
 
memcpy(, buf, 2);
+
return swab16(ret);
 }
 
@@ -193,22 +193,19 @@ static int __mt9t112_reg_write(const struct i2c_client 
*client,
msg.buf   = buf;
 
/*
-* i2c_transfer return message length,
-* but this function should return 0 if correct case
+* i2c_transfer return message length, but this function should
+* return 0 if correct case.
 */
ret = i2c_transfer(client->adapter, , 1);
-   if (ret >= 0)
-   ret = 0;
 
-   return ret;
+   return ret >= 0 ? 0 : ret;
 }
 
 static int __mt9t112_reg_mask_set(const struct i2c_client *client,
- u16  command,
- u16  mask,
- u16  set)
+ u16  command, u16  mask, u16  set)
 {
int val = __mt9t112_reg_read(client, command);
+
if (val < 0)
return val;
 
@@ -243,11 +240,10 @@ static int __mt9t112_mcu_write(const struct i2c_client 
*client,
 }
 
 static int __mt9t112_mcu_mask_set(const struct i2c_client *client,
- u16  command,
- u16  mask,
- u16  set)
+ u16  command, u16  mask, u16  set)
 {
int val = __mt9t112_mcu_read(client, command);
+
if (val < 0)
return val;
 
@@ -262,7 +258,7 @@ static int mt9t112_reset(const struct i2c_client *client)
int ret;
 
mt9t112_reg_mask_set(ret, client, 0x001a, 0x0001, 0x0001);
-   msleep(1);
+   usleep_range(1000, 5000);
mt9t112_reg_mask_set(ret, client, 0x001a, 0x0001, 0x);
 
return ret;
@@ -301,38 +297,38 @@ static int mt9t112_clock_info(const struct i2c_client 
*client, u32 ext)
m = n & 0x00ff;
n = (n >> 8) & 0x003f;
 
-   enable = ((6000 > ext) || (54000 < ext)) ? "X" : "";
+   enable = ((ext < 6000) || (ext > 54000)) ? "X" : "";
dev_dbg(>dev, "EXTCLK  : %10u K %s\n", ext, enable);
 
-   vco = 2 * m * ext / (n+1);
-   enable = ((384000 > vco) || (768000 < vco)) ? "X" : "";
+   vco = 2 * m * ext / (n + 1);
+   enable = ((vco < 384000) || (vco > 768000)) 

[PATCH 1/5] media: i2c: Copy mt9t112 soc_camera sensor driver

[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 
---
 drivers/media/i2c/mt9t112.c | 1163 +++
 1 file changed, 1163 insertions(+)
 create mode 100644 drivers/media/i2c/mt9t112.c

diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
new file mode 100644
index 000..297d22e
--- /dev/null
+++ b/drivers/media/i2c/mt9t112.c
@@ -0,0 +1,1163 @@
+/*
+ * mt9t112 Camera Driver
+ *
+ * Copyright (C) 2009 Renesas Solutions Corp.
+ * Kuninori Morimoto 
+ *
+ * Based on ov772x driver, mt9m111 driver,
+ *
+ * Copyright (C) 2008 Kuninori Morimoto 
+ * Copyright (C) 2008, Robert Jarzmik 
+ * 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 
+
+/* you can check PLL/clock info */
+/* #define EXT_CLOCK 2400 */
+
+/
+   macro
+/
+/*
+ * frame size
+ */
+#define MAX_WIDTH   2048
+#define MAX_HEIGHT  1536
+
+/*
+ * macro of read/write
+ */
+#define ECHECKER(ret, x)   \
+   do {\
+   (ret) = (x);\
+   if ((ret) < 0)  \
+   return (ret);   \
+   } while (0)
+
+#define mt9t112_reg_write(ret, client, a, b) \
+   ECHECKER(ret, __mt9t112_reg_write(client, a, b))
+#define mt9t112_mcu_write(ret, client, a, b) \
+   ECHECKER(ret, __mt9t112_mcu_write(client, a, b))
+
+#define mt9t112_reg_mask_set(ret, client, a, b, c) \
+   ECHECKER(ret, __mt9t112_reg_mask_set(client, a, b, c))
+#define mt9t112_mcu_mask_set(ret, client, a, b, c) \
+   ECHECKER(ret, __mt9t112_mcu_mask_set(client, a, b, c))
+
+#define mt9t112_reg_read(ret, client, a) \
+   ECHECKER(ret, __mt9t112_reg_read(client, a))
+
+/*
+ * Logical address
+ */
+#define _VAR(id, offset, base) (base | (id & 0x1f) << 10 | (offset & 0x3ff))
+#define VAR(id, offset)  _VAR(id, offset, 0x)
+#define VAR8(id, offset) _VAR(id, offset, 0x8000)
+
+/
+   struct
+/
+struct mt9t112_format {
+   u32 code;
+   enum v4l2_colorspace colorspace;
+   u16 fmt;
+   u16 order;
+};
+
+struct mt9t112_priv {
+   struct v4l2_subdev   subdev;
+   struct mt9t112_camera_info  *info;
+   struct i2c_client   *client;
+   struct v4l2_rect frame;
+   struct v4l2_clk *clk;
+   const struct mt9t112_format *format;
+   int  num_formats;
+   u32  flags;
+/* for flags */
+#define INIT_DONE  (1 << 0)
+#define PCLK_RISING(1 << 1)
+};
+
+/
+   supported format
+/
+
+static const struct mt9t112_format mt9t112_cfmts[] = {
+   {
+   .code   = MEDIA_BUS_FMT_UYVY8_2X8,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .fmt= 1,
+   .order  = 0,
+   }, {
+   .code   = MEDIA_BUS_FMT_VYUY8_2X8,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .fmt= 1,
+   .order  = 1,
+   }, {
+   .code   = MEDIA_BUS_FMT_YUYV8_2X8,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .fmt= 1,
+   .order  = 2,
+   }, {
+   .code   = MEDIA_BUS_FMT_YVYU8_2X8,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .fmt= 1,
+   .order  = 3,
+   }, {
+   .code   = MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .fmt= 8,
+   .order  = 2,
+   }, {
+   .code   = MEDIA_BUS_FMT_RGB565_2X8_LE,
+   

[PATCH 0/5] Renesas CEU: SH7724 ECOVEC + Aptina mt9t112

[Jacopo Mondi]

Hello,
   now that CEU has been picked up for inclusion in v4.17, we can start moving
users of old sh_mobile_ceu_camera driver to use the newly introduced one.

Migo-R has been first, now it's SH7724 ECOVEC board turn.

ECOVEC has a camera board with two MT9T112 image sensor and one TW9910 video
decoder input. This series moves the mt9t112 driver away from soc_camera
framework and remove dependencies on it in mach-ecovec board code.

As per Migo-R, memory for CEU is reserved using memblocks APIs and declared
as DMA-capable in board code, power up/down routines have been removed from
board code, and GPIOs lookup table registered for sensor drivers.

As in the previous series, still no code has been removed or changed in
drivers/media/i2c/soc_camera/ until we do not remove all dependencies on it
in all board files.

Hans, since you asked me to add frame rate interval support for ov772x I expect
to receive the same request for mt9t112. Unfortunately I do not have access to
register level documentation, nor can perform any testing as I don't have the
camera modules. For the same reason I cannot run any v4l2-compliance test on
that driver, but just make sure the ECOVEC boots cleanly with the new board
file. I'm in favour of moving the driver to staging if you think that's the 
case.

Series based on media-tree master, and as per Migo-R I would ask SH arch/
changes to go through media tree as SH maintainers are un-responsive.

Thanks
  j

Jacopo Mondi (5):
  media: i2c: Copy mt9t112 soc_camera sensor driver
  media: i2c: mt9t112: Remove soc_camera dependencies
  media: i2c: mt9t112: Fix code style issues
  arch: sh: ecovec: Use new renesas-ceu camera driver
  media: MAINTAINERS: Add entry for Aptina MT9T112

 MAINTAINERS|7 +
 arch/sh/boards/mach-ecovec24/setup.c   |  338 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7724.c |4 +-
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/mt9t112.c| 1136 
 include/media/i2c/mt9t112.h|   17 +-
 7 files changed, 1333 insertions(+), 181 deletions(-)
 create mode 100644 drivers/media/i2c/mt9t112.c

--
2.7.4

[PATCH 4/5] arch: sh: ecovec: Use new renesas-ceu camera driver

[Jacopo Mondi]

SH4 7724 Ecovec platform uses sh_mobile_ceu camera driver, which is now
being replaced by a proper V4L2 camera driver named 'renesas-ceu'.

Get rid of soc_camera defined components used to register sensor drivers
and of platform specific enable/disable routines.

Register GPIOs for sensor drivers and declare memory reserved with
memblock APIs as dma capable to be used for CEU buffers.

While at there re-order include directives to respect alphabetical
ordering.

Signed-off-by: Jacopo Mondi 
---
 arch/sh/boards/mach-ecovec24/setup.c   | 338 -
 arch/sh/kernel/cpu/sh4a/clock-sh7724.c |   4 +-
 2 files changed, 171 insertions(+), 171 deletions(-)

diff --git a/arch/sh/boards/mach-ecovec24/setup.c 
b/arch/sh/boards/mach-ecovec24/setup.c
index 6f929ab..adc61d1 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -7,44 +7,47 @@
  * 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 
+#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 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
-#include 
+
+#include 
+#include 
+#include 
+
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+
+#include 
 
 /*
  *  Address  InterfaceBusWidth
@@ -81,6 +84,10 @@
  * amixer set 'Out Mixer Right DAC Right' on
  */
 
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu0_dma_membase;
+static phys_addr_t ceu1_dma_membase;
+
 /* Heartbeat */
 static unsigned char led_pos[] = { 0, 1, 2, 3 };
 
@@ -382,8 +389,24 @@ static struct platform_device gpio_backlight_device = {
 };
 
 /* CEU0 */
-static struct sh_mobile_ceu_info sh_mobile_ceu0_info = {
-   .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_platform_data ceu0_pdata = {
+   .num_subdevs= 2,
+   .subdevs = {
+   { /* [0] = mt9t112  */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x3c,
+   },
+   { /* [1] = tw9910  */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 0,
+   .i2c_address= 0x45,
+   },
+   },
 };
 
 static struct resource ceu0_resources[] = {
@@ -397,24 +420,30 @@ static struct resource ceu0_resources[] = {
.start  = evt2irq(0x880),
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   /* place holder for contiguous memory */
-   },
 };
 
 static struct platform_device ceu0_device = {
-   .name   = "sh_mobile_ceu",
-   .id = 0, /* "ceu0" clock */
+   .name   = "renesas-ceu",
+   .id = 0, /* ceu.0 */
.num_resources  = ARRAY_SIZE(ceu0_resources),
.resource   = ceu0_resources,
.dev= {
-   .platform_data  = _mobile_ceu0_info,
+   .platform_data  = _pdata,
},
 };
 
 /* CEU1 */
-static struct sh_mobile_ceu_info sh_mobile_ceu1_info = {
-   .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_platform_data ceu1_pdata = {
+   .num_subdevs= 1,
+   .subdevs = {
+   { /* [0] = mt9t112  */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 1,
+   .i2c_address= 0x3c,
+   },
+   },
 };
 
 static struct resource ceu1_resources[] = {
@@ -428,26 +457,71 @@ static struct resource ceu1_resources[] = {
.start  = evt2irq(0x9e0),
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   /* place holder for contiguous memory */
-   },
 };
 
 static struct platform_device ceu1_device = {
-   .name   = "sh_mobile_ceu",
-   .id = 1, /* "ceu1" clock */
+   .name   = "renesas-ceu",
+   .id = 1, /* ceu.1 */
.num_resources  = ARRAY_SIZE(ceu1_resources),
.resource   = ceu1_resources,
.dev= {
-   .platform_data  = _mobile_ceu1_info,
+   .platform_data  = _pdata,
+   },
+};
+
+/* Power up/down GPIOs 

[PATCH 2/5] media: i2c: mt9t112: Remove soc_camera dependencies

[Jacopo Mondi]

Remove soc_camera framework dependencies from mt9t112 sensor driver.
- Handle clk, gpios and power routines
- Register async subdev
- Remove deprecated g/s_mbus_config operations
- Remove driver flags
- Change driver interface and add kernel doc
- Adjust build system

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

As I don't have access to a working camera module, this change has only
been compile tested.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/Kconfig   |  11 
 drivers/media/i2c/Makefile  |   1 +
 drivers/media/i2c/mt9t112.c | 147 +---
 include/media/i2c/mt9t112.h |  17 +++--
 4 files changed, 89 insertions(+), 87 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index d7bba0e..541f0d28 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -788,6 +788,17 @@ config VIDEO_MT9T001
  This is a Video4Linux2 sensor-level driver for the Aptina
  (Micron) mt0t001 3 Mpixel camera.

+config VIDEO_MT9T112
+   tristate "Aptina MT9T111/MT9T112 support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the Aptina
+ (Micron) MT9T111 and MT9T112 3 Mpixel camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mt9t112.
+
 config VIDEO_MT9V011
tristate "Micron mt9v011 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index cc30178..ea34aee 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
 obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
+obj-$(CONFIG_VIDEO_MT9T112) += mt9t112.o
 obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
 obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
 obj-$(CONFIG_VIDEO_SR030PC30)  += sr030pc30.o
diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
index 297d22e..6b77dff 100644
--- a/drivers/media/i2c/mt9t112.c
+++ b/drivers/media/i2c/mt9t112.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * mt9t112 Camera Driver
  *
+ * Copyright (C) 2017 Jacopo Mondi 
+ *
  * Copyright (C) 2009 Renesas Solutions Corp.
  * Kuninori Morimoto 
  *
@@ -11,13 +14,11 @@
  * 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 
@@ -26,10 +27,9 @@
 #include 

 #include 
-#include 
-#include 
 #include 
 #include 
+#include 

 /* you can check PLL/clock info */
 /* #define EXT_CLOCK 2400 */
@@ -85,16 +85,14 @@ struct mt9t112_format {

 struct mt9t112_priv {
struct v4l2_subdev   subdev;
-   struct mt9t112_camera_info  *info;
+   struct mt9t112_platform_data*info;
struct i2c_client   *client;
struct v4l2_rect frame;
-   struct v4l2_clk *clk;
+   struct clk  *clk;
+   struct gpio_desc*standby_gpio;
const struct mt9t112_format *format;
int  num_formats;
-   u32  flags;
-/* for flags */
-#define INIT_DONE  (1 << 0)
-#define PCLK_RISING(1 << 1)
+   bool init_done;
 };

 /
@@ -341,12 +339,6 @@ static int mt9t112_clock_info(const struct i2c_client 
*client, u32 ext)
 }
 #endif

-static void mt9t112_frame_check(u32 *width, u32 *height, u32 *left, u32 *top)
-{
-   soc_camera_limit_side(left, width, 0, 0, MAX_WIDTH);
-   soc_camera_limit_side(top, height, 0, 0, MAX_HEIGHT);
-}
-
 static int mt9t112_set_a_frame_size(const struct i2c_client *client,
   u16 width,
   u16 height)
@@ -764,13 +756,40 @@ static int mt9t112_s_register(struct v4l2_subdev *sd,
 }
 #endif

+static int mt9t112_power_on(struct mt9t112_priv *priv)
+{
+   int ret;
+
+   ret = clk_prepare_enable(priv->clk);
+   if (ret)
+   return ret;
+
+   if (priv->standby_gpio) {
+   gpiod_set_value(priv->standby_gpio, 0);
+   msleep(100);
+   }
+
+   return 0;
+}
+
+static int mt9t112_power_off(struct mt9t112_priv *priv)
+{
+   

[PATCH 5/5] media: MAINTAINERS: Add entry for Aptina MT9T112

[Jacopo Mondi]

Add entry for Aptina/Micron MT9T112 camera sensor. The driver is
currently orphaned.

Signed-off-by: Jacopo Mondi 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 91ed6ad..1d8be25 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9385,6 +9385,13 @@ S:   Maintained
 F: drivers/media/i2c/mt9t001.c
 F: include/media/i2c/mt9t001.h
 
+MT9T112 APTINA CAMERA SENSOR
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Orphan
+F: drivers/media/i2c/mt9t112.c
+F: include/media/i2c/mt9t112.h
+
 MT9V032 APTINA CAMERA SENSOR
 M: Laurent Pinchart 
 L: linux-me...@vger.kernel.org
-- 
2.7.4

Re: [PATCH 2/2] pinctrl: sh-pfc: add R8A77980 PFC support

[Geert Uytterhoeven]

Hi Sergei,

On Mon, Feb 26, 2018 at 5:53 PM, Sergei Shtylyov
 wrote:
> On 02/26/2018 03:42 PM, Geert Uytterhoeven wrote:
>>> Add the PFC support for the R8A77980 SoC including pin groups for some
>>> on-chip devices such as AVB, CAN-FD, GETHER, [H]SCIF, I2C, INTC-EX, MMC,
>>> MSIOF, PWM, and VIN...
>>>
>>> Based on the original (and large) patch by Vladimir Barinov.
>>>
>>> Signed-off-by: Vladimir Barinov 
>>> Signed-off-by: Sergei Shtylyov 
>>
>> Thanks for your patch!
>>
>> To avoid scaring off potential reviewers, it may be better to not include 
>> that
>> many pin groups and functions in future initial submissions.
>> This also helps if issues are detected during review in some of them (like
>> below), delaying queuing of basic functionality and other correct parts.
>>
>> I only looked at CPU_ALL_PORT(), pins, groups, and functions.
>> Comments below.
>>
>>> --- /dev/null
>>> +++ renesas-drivers/drivers/pinctrl/sh-pfc/pfc-r8a77980.c
>>
>>> +/* - AVB 
>>>  */
>>> +static const unsigned int avb_link_pins[] = {
>>> +   /* AVB_LINK */
>>> +   RCAR_GP_PIN(1, 18),
>>> +};
>>> +static const unsigned int avb_link_mux[] = {
>>> +   AVB_LINK_MARK,
>>> +};
>>> +static const unsigned int avb_magic_pins[] = {
>>> +   /* AVB_MAGIC */
>>> +   RCAR_GP_PIN(1, 16),
>>> +};
>>> +static const unsigned int avb_magic_mux[] = {
>>> +   AVB_MAGIC_MARK,
>>> +};
>>> +static const unsigned int avb_phy_int_pins[] = {
>>> +   /* AVB_PHY_INT */
>>> +   RCAR_GP_PIN(1, 17),
>>> +};
>>> +static const unsigned int avb_phy_int_mux[] = {
>>> +   AVB_PHY_INT_MARK,
>>> +};
>>> +static const unsigned int avb_mdio_pins[] = {
>>> +   /* AVB_MDC, AVB_MDIO */
>>> +   RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 14),
>>> +};
>>> +static const unsigned int avb_mdio_mux[] = {
>>> +   AVB_MDC_MARK, AVB_MDIO_MARK,
>>> +};
>>
>> The grouping is different from other R-Car Gen3 SoCs.
>
>Not true AFAICS -- only the group naming is different.

Oh, so we can have both groups names, and be compatible?

>>> +/* - CANFD0 
>>> - */
>>> +static const unsigned int canfd0_data_a_pins[] = {
>>> +   /* CANFD0_TX, CANFD0_RX */
>>> +   RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
>>> +};
>>> +static const unsigned int canfd0_data_a_mux[] = {
>>> +   CANFD0_TX_A_MARK, CANFD0_RX_A_MARK,
>>> +};
>>> +static const unsigned int canfd_clk_a_pins[] = {
>>> +   /* CANFD_CLK */
>>> +   RCAR_GP_PIN(1, 25),
>>> +};
>>> +static const unsigned int canfd_clk_a_mux[] = {
>>> +   CANFD_CLK_A_MARK,
>>> +};
>>> +static const unsigned int canfd0_data_b_pins[] = {
>>> +   /* CANFD0_TX, CANFD0_RX */
>>> +   RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
>>> +};
>>> +static const unsigned int canfd0_data_b_mux[] = {
>>> +   CANFD0_TX_B_MARK, CANFD0_RX_B_MARK,
>>> +};
>>> +static const unsigned int canfd_clk_b_pins[] = {
>>> +   /* CANFD_CLK */
>>> +   RCAR_GP_PIN(3, 8),
>>> +};
>>> +static const unsigned int canfd_clk_b_mux[] = {
>>> +   CANFD_CLK_B_MARK,
>>> +};
>>
>> Please move the canfd_clk pins to their own section.
>
>Are you aware the CANFD_CLK is controlled by MOD_SEL0.SEL_CANFD0? If it's 
> allowed
> to have the pins controlled by a single MOD_SEL field in the diff groups, 
> I'll place
> CANFD_CLK into a separate group...

SEL_CANFD0 switches between the A and B groups for CANFD0_TX, CANFD0_RX,
and CANFD0_CLK together.
So all three pins must use either group A, or group B. That's something the
user must do correctly anyway.

However, the CANFD_CLK pin is shared between the CANFD0 and CANFD1
modules.  So a user who uses CANFD1, and not CANFD0, still has to configure
pinmuxing for CANFD_CLK.

>>> +/* - HSCIF0 
>>> - */
>>
>>> +static const unsigned int scif_clk_a_pins[] = {
>>> +   /* SCIF_CLK */
>>> +   RCAR_GP_PIN(0, 10),
>>> +};
>>> +static const unsigned int scif_clk_a_mux[] = {
>>> +   SCIF_CLK_A_MARK,
>>> +};
>>
>>
>> [...]
>>
>>> +static const unsigned int scif_clk_b_pins[] = {
>>> +   /* SCIF_CLK */
>>> +   RCAR_GP_PIN(1, 25),
>>> +};
>>> +static const unsigned int scif_clk_b_mux[] = {
>>> +   SCIF_CLK_B_MARK,
>>> +};
>>
>> Please move the scif_clk pins to their own section, as they are shared by
>> HSCIF and SCIF.
>
>Again, the same bit in MOD_SEL0...

Same story: SCIF_CLK is shared by the HSCIFx and SCIFx modules.
Still puts the responsability in the hands of the board designer: he must
know not to select SCIF_CLK_A and HSCIF0_B, or SCIF_CLK_B and HSCIF0_A.

On this SoC, the limitations seem to be worse than on other members of
the same family.

However, on other SoCs you have similar limitations. E.g. on H3/M3-W/M3-N
you cannot select scif5_data_a and 

Re: [PATCH 2/2] pinctrl: sh-pfc: add R8A77980 PFC support

[Rob Herring]

On Sun, Feb 25, 2018 at 09:14:21PM +0300, Sergei Shtylyov wrote:
> Add the PFC support for the R8A77980 SoC including pin groups for some
> on-chip devices such as AVB, CAN-FD, GETHER, [H]SCIF, I2C, INTC-EX, MMC,
> MSIOF, PWM, and VIN...
> 
> Based on the original (and large) patch by Vladimir Barinov.
> 
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt |1 

Reviewed-by: Rob Herring 

>  drivers/pinctrl/sh-pfc/Kconfig|5 
>  drivers/pinctrl/sh-pfc/Makefile   |1 
>  drivers/pinctrl/sh-pfc/core.c |6 
>  drivers/pinctrl/sh-pfc/pfc-r8a77980.c | 2738 
> ++
>  drivers/pinctrl/sh-pfc/sh_pfc.h   |1 
>  6 files changed, 2752 insertions(+)

Re: [PATCH 1/2] arm: add basic support for Renesas RZ/N1 boards

[Rob Herring]

On Mon, Feb 26, 2018 at 12:18:19PM +, Michel Pollet wrote:
> This adds the Renesas RZ/N1 CPU and bare bone support.
> 
> This currently only handles generic parts (gic, architected timer)
> and a UART.
> This also relies on the bootloader to set the pinctrl and clocks.
> 
> Signed-off-by: Michel Pollet 
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt |   3 +-
>  arch/arm/boot/dts/rzn1.dtsi|  94 +++
>  arch/arm/mach-shmobile/Kconfig |   5 +
>  arch/arm/mach-shmobile/Makefile|   1 +
>  arch/arm/mach-shmobile/setup-r9a06g032.c   |  60 ++
>  .../dt-bindings/interrupt-controller/rzn1-irq.h| 137 
>  include/dt-bindings/soc/renesas,rzn1-map.h | 173 +
>  include/soc/rzn1/sysctrl.h | 736 
> +
>  8 files changed, 1208 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/rzn1.dtsi
>  create mode 100644 arch/arm/mach-shmobile/setup-r9a06g032.c
>  create mode 100644 include/dt-bindings/interrupt-controller/rzn1-irq.h
>  create mode 100644 include/dt-bindings/soc/renesas,rzn1-map.h
>  create mode 100644 include/soc/rzn1/sysctrl.h
> 
> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
> b/Documentation/devicetree/bindings/arm/shmobile.txt
> index 63edc11..153f69bb 100644
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -47,7 +47,8 @@ SoCs:
>  compatible = "renesas,r8a77980"
>- R-Car D3 (R8A77995)
>  compatible = "renesas,r8a77995"
> -
> +  - RZ/N1D (R9A06G032)
> +compatible = "renesas,r9a06g032"
>  
>  Boards:
>  
> diff --git a/arch/arm/boot/dts/rzn1.dtsi b/arch/arm/boot/dts/rzn1.dtsi
> new file mode 100644
> index 000..bc134b0
> --- /dev/null
> +++ b/arch/arm/boot/dts/rzn1.dtsi
> @@ -0,0 +1,94 @@
> +/*
> + * Base Device Tree Source for the Renesas RZ/N1 SoC
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + * SPDX-License-Identifier: GPL-2.0

Goes on the first line now.

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "skeleton.dtsi"

Don't use skeleton.dtsi. We're trying to remove it.

> +
> +/ {
> + compatible = "renesas,r9a06g032";
> + interrupt-parent = <>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0>;
> + };
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <1>;
> + };
> + };
> + aliases {
> + serial0 = 
> + };
> + arm_timer: timer {
> + compatible = "arm,armv7-timer";
> + arm,cpu-registers-not-fw-configured;
> + interrupts =
> +  + IRQ_TYPE_LEVEL_LOW)>,
> +  + IRQ_TYPE_LEVEL_LOW)>,
> +  + IRQ_TYPE_LEVEL_LOW)>,
> +  + IRQ_TYPE_LEVEL_LOW)>;
> + };
> + gic: interrupt-controller@RZN1_GIC_BASE {

Don't use macros for unit-addresses.

> + compatible = "arm,cortex-a7-gic";
> + reg = <0x44101000 0x1000>,  /* Distributer */
> +   <0x44102000 0x1000>,  /* CPU interface */
> +   <0x44104000 0x2000>,  /* Virt interface control */
> +   <0x44106000 0x2000>;  /* Virt CPU interface */
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + interrupts =
> +  + IRQ_TYPE_LEVEL_HIGH)>;
> + };
> + clocks: clocks@0 {

Build with W=1 and W=12 and fix those warnings.

> + /*
> +  * this is fixed clock for now,
> +  * until the clock driver is merged
> +  */
> + clk_uarts: clk_uarts@0 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <47619047>;
> + };
> + };
> + bus {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + uart0: serial@RZN1_UART0_BASE {
> + compatible = "snps,dw-apb-uart";
> + reg = ;
> + interrupts =  + IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <_uarts>;
> +   

Re: [PATCH v11 02/32] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:21 EET Niklas Söderlund wrote:
> From: Fabrizio Castro 
> 
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> Reviewed-by: Simon Horman 
> Acked-by: Rob Herring 
> Reviewed-by: Geert Uytterhoeven 
> Acked-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
> b/Documentation/devicetree/bindings/media/rcar_vin.txt index
> 0ac715a5c331bc26..c60e6b0a89b67a8c 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -6,6 +6,8 @@ family of devices. The current blocks are always slaves and
> suppot one input channel which can be either RGB, YUYV or BT656.
> 
>   - compatible: Must be one or more of the following
> +   - "renesas,vin-r8a7743" for the R8A7743 device
> +   - "renesas,vin-r8a7745" for the R8A7745 device
> - "renesas,vin-r8a7778" for the R8A7778 device
> - "renesas,vin-r8a7779" for the R8A7779 device
> - "renesas,vin-r8a7790" for the R8A7790 device
> @@ -14,7 +16,8 @@ channel which can be either RGB, YUYV or BT656.
> - "renesas,vin-r8a7793" for the R8A7793 device
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> -   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
> +   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> + device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
> 
> When compatible with the generic version nodes must list the

-- 
Regards,

Laurent Pinchart

Re: [PATCH v11 11/32] rcar-vin: set a default field to fallback on

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:30 EET Niklas Söderlund wrote:
> If the field is not supported by the driver it should not try to keep
> the current field. Instead it should set it to a default fallback. Since
> trying a format should always result in the same state regardless of the
> current state of the device.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> c2265324c7c96308..ebcd78b1bb6e8cb6 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -23,6 +23,7 @@
>  #include "rcar-vin.h"
> 
>  #define RVIN_DEFAULT_FORMAT  V4L2_PIX_FMT_YUYV
> +#define RVIN_DEFAULT_FIELD   V4L2_FIELD_NONE
> 
>  /*
> ---
> -- * Format Conversions
> @@ -143,7 +144,7 @@ static int rvin_reset_format(struct rvin_dev *vin)
>   case V4L2_FIELD_INTERLACED:
>   break;
>   default:
> - vin->format.field = V4L2_FIELD_NONE;
> + vin->format.field = RVIN_DEFAULT_FIELD;
>   break;
>   }
> 
> @@ -213,10 +214,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
>   u32 walign;
>   int ret;
> 
> - /* Keep current field if no specific one is asked for */
> - if (pix->field == V4L2_FIELD_ANY)
> - pix->field = vin->format.field;
> -
>   /* If requested format is not supported fallback to the default */
>   if (!rvin_format_from_pixel(pix->pixelformat)) {
>   vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",
> @@ -246,7 +243,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
>   case V4L2_FIELD_INTERLACED:
>   break;
>   default:
> - pix->field = V4L2_FIELD_NONE;
> + pix->field = RVIN_DEFAULT_FIELD;
>   break;
>   }


-- 
Regards,

Laurent Pinchart

Re: [PATCH v11 13/32] rcar-vin: update bytesperline and sizeimage calculation

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:32 EET Niklas Söderlund wrote:
> Remove over complicated logic to calculate the value for bytesperline
> and sizeimage that was carried over from the soc_camera port. There is
> no need to find the max value of bytesperline and sizeimage from
> user-space as they are set to 0 before the max_t() operation.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> cef9070884d93ba6..652b85300b4ef9db 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -194,10 +194,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
>   pix->pixelformat = RVIN_DEFAULT_FORMAT;
>   }
> 
> - /* Always recalculate */
> - pix->bytesperline = 0;
> - pix->sizeimage = 0;
> -
>   /* Limit to source capabilities */
>   ret = __rvin_try_format_source(vin, which, pix, source);
>   if (ret)
> @@ -232,10 +228,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
>   v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
> >height, 4, vin->info->max_height, 2, 0);
> 
> - pix->bytesperline = max_t(u32, pix->bytesperline,
> -   rvin_format_bytesperline(pix));
> - pix->sizeimage = max_t(u32, pix->sizeimage,
> -rvin_format_sizeimage(pix));
> + pix->bytesperline = rvin_format_bytesperline(pix);
> + pix->sizeimage = rvin_format_sizeimage(pix);
> 
>   if (vin->info->model == RCAR_M1 &&
>   pix->pixelformat == V4L2_PIX_FMT_XBGR32) {


-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:34 EET Niklas Söderlund wrote:
> Part of the format alignment and checking can be shared with the Gen3
> format handling. Break that part out to a separate function.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 96 +++---
>  1 file changed, 54 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> b94ca9ffb1d3b323..3290e603b44cdf3a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -87,6 +87,59 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format
> *pix) return pix->bytesperline * pix->height;
>  }
> 
> +static int rvin_format_align(struct rvin_dev *vin, struct v4l2_pix_format
> *pix)
> +{
> + u32 walign;
> +
> + if (!rvin_format_from_pixel(pix->pixelformat) ||
> + (vin->info->model == RCAR_M1 &&
> +  pix->pixelformat == V4L2_PIX_FMT_XBGR32))
> + pix->pixelformat = RVIN_DEFAULT_FORMAT;
> +
> + switch (pix->field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + break;
> + case V4L2_FIELD_ALTERNATE:
> + /*
> +  * Driver do not (yet) support outputting ALTERNATE to a
> +  * userspace. It does support outputting INTERLACED so use
> +  * the VIN hardware to combine the two fields.
> +  */
> + pix->field = V4L2_FIELD_INTERLACED;
> + pix->height *= 2;
> + break;
> + default:
> + pix->field = RVIN_DEFAULT_FIELD;
> + break;
> + }
> +
> + /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
> + walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
> +
> + /* Limit to VIN capabilities */
> + v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
> +   >height, 4, vin->info->max_height, 2, 0);
> +
> + pix->bytesperline = rvin_format_bytesperline(pix);
> + pix->sizeimage = rvin_format_sizeimage(pix);
> +
> + if (vin->info->model == RCAR_M1 &&
> + pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
> + vin_err(vin, "pixel format XBGR32 not supported on M1\n");
> + return -EINVAL;
> + }

This can't happen as you set the pixel format to the default earlier in the 
same case.

> + vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
> + pix->width, pix->height, pix->bytesperline, pix->sizeimage);

While at it you could use %u for bpl and size.

> +
> + return 0;
> +}
> +
>  /* 
>   * V4L2
>   */
> @@ -184,55 +237,14 @@ static int __rvin_try_format(struct rvin_dev *vin,
>struct v4l2_pix_format *pix,
>struct rvin_source_fmt *source)
>  {
> - u32 walign;
>   int ret;
> 
> - if (!rvin_format_from_pixel(pix->pixelformat) ||
> - (vin->info->model == RCAR_M1 &&
> -  pix->pixelformat == V4L2_PIX_FMT_XBGR32))
> - pix->pixelformat = RVIN_DEFAULT_FORMAT;
> -
>   /* Limit to source capabilities */
>   ret = __rvin_try_format_source(vin, which, pix, source);

This functions uses the pixel format. Isn't it a problem that you don't first 
set it to the default if the requested pixel format isn't supported ?

>   if (ret)
>   return ret;
> 
> - switch (pix->field) {
> - case V4L2_FIELD_TOP:
> - case V4L2_FIELD_BOTTOM:
> - case V4L2_FIELD_NONE:
> - case V4L2_FIELD_INTERLACED_TB:
> - case V4L2_FIELD_INTERLACED_BT:
> - case V4L2_FIELD_INTERLACED:
> - break;
> - case V4L2_FIELD_ALTERNATE:
> - /*
> -  * Driver do not (yet) support outputting ALTERNATE to a
> -  * userspace. It does support outputting INTERLACED so use
> -  * the VIN hardware to combine the two fields.
> -  */
> - pix->field = V4L2_FIELD_INTERLACED;
> - pix->height *= 2;
> - break;
> - default:
> - pix->field = RVIN_DEFAULT_FIELD;
> - break;
> - }
> -
> - /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
> - walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
> -
> - /* Limit to VIN capabilities */
> - v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
> -   >height, 4, vin->info->max_height, 2, 0);
> -
> - pix->bytesperline = rvin_format_bytesperline(pix);
> - pix->sizeimage = rvin_format_sizeimage(pix);
> -
> - vin_dbg(vin, 

Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

[Linus Walleij]

On Tue, Feb 27, 2018 at 1:56 PM, Ville Syrjala
 wrote:

> From: Ville Syrjälä 
>
> Currently we have a mix of static and dynamic information stored in
> the display info structure. That makes it rather difficult to repopulate
> the dynamic parts when a new EDID appears. Let's make life easier by
> splitting the structure up into static and dynamic parts.
>
> The static part will consist of subpixel_order, panel_orientation,
> and bus_formats.
>
> Actually I'm not sure where bus_formats & co. fit in all this. For some
> drivers those seem to be static, even though they might fill them out
> from .get_modes(). For other drivers this stuff even gets frobbed at
> runtime, making it more some kind of a bastard encoder/connector state.
> I'll just stick it into the static side so that the behaviour doesn't
> change when I start clear out the entire dynamic state with memset().
>
> Cc: Keith Packard 
> Cc: Daniel Vetter 
> Cc: Hans de Goede 
> Cc: Shashank Sharma 
> Cc: Stefan Agner 
> Cc: Thierry Reding 
> Cc: Boris Brezillon 
> Cc: Philipp Zabel 
> Cc: Laurent Pinchart 
> Cc: Manfred Schlaegl 
> Cc: Marek Vasut 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Alison Wang 
> Cc: Eric Anholt 
> Cc: Linus Walleij 
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: Maxime Ripard 
> Signed-off-by: Ville Syrjälä 

Acked-by: Linus Walleij 

Yours,
Linus Walleij

Re: [PATCH v11 22/32] rcar-vin: force default colorspace for media centric mode

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:41 EET Niklas Söderlund wrote:
> When the VIN driver is running in media centric mode (on Gen3) the
> colorspace is not retrieved from the video source instead the user is
> expected to set it as part of the format. There is no way for the VIN
> driver to validated the colorspace requested by user-space, this creates
> a problem where validation tools fail. Until the user requested
> colorspace can be validated lets force it to the driver default.

The problem here is that the V4L2 specification clearly documents the 
colorspace fields as being set by drivers for capture devices. Using the 
values supplied by userspace thus wouldn't comply with the API. The API has to 
be updated to allow us to implement this feature, but until then Hans wants 
the userspace to be set by the driver to a fixed value. Could you update the 
commit message accordingly, as well as the comment below ?

> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> 8d92710efffa7276..02f3100ed30db63c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -675,12 +675,24 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>   * V4L2 Media Controller
>   */
> 
> +static int rvin_mc_try_format(struct rvin_dev *vin, struct v4l2_pix_format
> *pix) +{
> + /*
> +  * There is no way to validate the colorspace provided by the
> +  * user. Until it can be validated force colorspace to the
> +  * driver default.
> +  */
> + pix->colorspace = RVIN_DEFAULT_COLORSPACE;

Should you also set the xfer_func, quantization and ycbcr_enc ?

Apart from that,

Reviewed-by: Laurent Pinchart 

> +
> + return rvin_format_align(vin, pix);
> +}
> +
>  static int rvin_mc_try_fmt_vid_cap(struct file *file, void *priv,
>  struct v4l2_format *f)
>  {
>   struct rvin_dev *vin = video_drvdata(file);
> 
> - return rvin_format_align(vin, >fmt.pix);
> + return rvin_mc_try_format(vin, >fmt.pix);
>  }
> 
>  static int rvin_mc_s_fmt_vid_cap(struct file *file, void *priv,
> @@ -692,7 +704,7 @@ static int rvin_mc_s_fmt_vid_cap(struct file *file, void
> *priv, if (vb2_is_busy(>queue))
>   return -EBUSY;
> 
> - ret = rvin_format_align(vin, >fmt.pix);
> + ret = rvin_mc_try_format(vin, >fmt.pix);
>   if (ret)
>   return ret;


-- 
Regards,

Laurent Pinchart

Re: [PATCH v7 1/3] watchdog: renesas_wdt: Add suspend/resume support

[Sergei Shtylyov]

Hello!

On 3/1/2018 9:17 PM, Fabrizio Castro wrote:


On R-Car Gen2 and RZ/G1 the watchdog IP clock needs to be always ON,
on R-Car Gen3 we power the IP down during suspend.

This commit adds suspend/resume support, so that the watchdog counting
"pauses" during suspend on all of the SoCs compatible with this driver
and on those we are now adding support for (R-Car Gen2 and RZ/G1).


   Why these parens here?


Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 

[...]

MBR, Sergei

Re: [PATCH v3 3/3] gpio: rcar: Use wakeup_path i.s.o. explicit clock handling

[Linus Walleij]

On Fri, Mar 2, 2018 at 9:20 AM, Geert Uytterhoeven  wrote:
>
> On Thu, Mar 1, 2018 at 5:06 PM, Linus Walleij  
> wrote:
>> On Mon, Feb 12, 2018 at 2:55 PM, Geert Uytterhoeven
>>  wrote:
>>
>>> Since commit ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable
>>> when wake-up is enabled"), when a GPIO is used for wakeup, the GPIO
>>> block's module clock (if exists) is manually kept running during system
>>> suspend, to make sure the device stays active.
>>>
>>> However, this explicit clock handling is merely a workaround for a
>>> failure to properly communicate wakeup information to the device core.
>>>
>>> Instead, set the device's power.wakeup_path field, to indicate this
>>> device is part of the wakeup path.  Depending on the PM Domain's
>>> active_wakeup configuration, the genpd core code will keep the device
>>> enabled (and the clock running) during system suspend when needed.
>>> This allows for the removal of all explicit clock handling code from the
>>> driver.
>>>
>>> Signed-off-by: Geert Uytterhoeven 
>>> ---
>>> v3:
>>
>> Patch applied for v4.16 fixes.
>
> Are you aware this conflicts with commit 51750fb167a05468 ("gpio: gpio-rcar:
> Support S2RAM") in gpio/for-next?

No but I guess I will become aware.

I have not yet mixed the fixes and devel branches for next.

> You can find the resolution in
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/drivers/gpio/gpio-rcar.c?h=renesas-drivers-2018-02-28-v4.16-rc3

Thanks!

Yours,
Linus Walleij

Re: [PATCH v11 01/32] dt-bindings: media: rcar_vin: Reverse SoC part number list

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:20 EET Niklas Söderlund wrote:
> From: Fabrizio Castro 
> 
> Change the sorting of the part numbers from descending to ascending to
> match with other documentation.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> Reviewed-by: Simon Horman 
> Acked-by: Rob Herring 
> Reviewed-by: Geert Uytterhoeven 
> Acked-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
> b/Documentation/devicetree/bindings/media/rcar_vin.txt index
> 19357d0bbe6539b3..0ac715a5c331bc26 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -6,14 +6,14 @@ family of devices. The current blocks are always slaves
> and suppot one input channel which can be either RGB, YUYV or BT656.
> 
>   - compatible: Must be one or more of the following
> -   - "renesas,vin-r8a7795" for the R8A7795 device
> -   - "renesas,vin-r8a7794" for the R8A7794 device
> -   - "renesas,vin-r8a7793" for the R8A7793 device
> -   - "renesas,vin-r8a7792" for the R8A7792 device
> -   - "renesas,vin-r8a7791" for the R8A7791 device
> -   - "renesas,vin-r8a7790" for the R8A7790 device
> -   - "renesas,vin-r8a7779" for the R8A7779 device
> - "renesas,vin-r8a7778" for the R8A7778 device
> +   - "renesas,vin-r8a7779" for the R8A7779 device
> +   - "renesas,vin-r8a7790" for the R8A7790 device
> +   - "renesas,vin-r8a7791" for the R8A7791 device
> +   - "renesas,vin-r8a7792" for the R8A7792 device
> +   - "renesas,vin-r8a7793" for the R8A7793 device
> +   - "renesas,vin-r8a7794" for the R8A7794 device
> +   - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.


-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/2] phy: rcar-gen3-usb3: Add binding for r8a77965

[Kishon Vijay Abraham I]

On Tuesday 27 February 2018 11:22 AM, Yoshihiro Shimoda wrote:
> This patch adds binding for r8a77965 (R-Car M3-N).

$subject should be  dt-bindings: rcar-gen3-phy-usb3: Add binding for r8a77965

Thanks
Kishon
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt 
> b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt
> index f94cea4..47dd296 100644
> --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb3.txt
> @@ -11,6 +11,8 @@ Required properties:
> SoC.
> "renesas,r8a7796-usb3-phy" if the device is a part of an R8A7796
> SoC.
> +   "renesas,r8a77965-usb3-phy" if the device is a part of an
> +   R8A77965 SoC.
> "renesas,rcar-gen3-usb3-phy" for a generic R-Car Gen3 compatible
> device.
>  
> 

Re: [PATCH v3 3/3] gpio: rcar: Use wakeup_path i.s.o. explicit clock handling

[Geert Uytterhoeven]

Hi Linus,

On Thu, Mar 1, 2018 at 5:06 PM, Linus Walleij  wrote:
> On Mon, Feb 12, 2018 at 2:55 PM, Geert Uytterhoeven
>  wrote:
>
>> Since commit ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable
>> when wake-up is enabled"), when a GPIO is used for wakeup, the GPIO
>> block's module clock (if exists) is manually kept running during system
>> suspend, to make sure the device stays active.
>>
>> However, this explicit clock handling is merely a workaround for a
>> failure to properly communicate wakeup information to the device core.
>>
>> Instead, set the device's power.wakeup_path field, to indicate this
>> device is part of the wakeup path.  Depending on the PM Domain's
>> active_wakeup configuration, the genpd core code will keep the device
>> enabled (and the clock running) during system suspend when needed.
>> This allows for the removal of all explicit clock handling code from the
>> driver.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>> v3:
>
> Patch applied for v4.16 fixes.

Are you aware this conflicts with commit 51750fb167a05468 ("gpio: gpio-rcar:
Support S2RAM") in gpio/for-next?

You can find the resolution in
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/drivers/gpio/gpio-rcar.c?h=renesas-drivers-2018-02-28-v4.16-rc3

If there's anything else I can do, just ask!

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 1/2] phy: rcar-gen3-usb2: Add support for r8a77965

[Kishon Vijay Abraham I]

On Tuesday 27 February 2018 11:22 AM, Yoshihiro Shimoda wrote:
> This patch adds support for r8a77965 (R-Car M3-N). This SoC has
> dedicated pins.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 ++
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 4 
>  2 files changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
> b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> index 99b651b..dbd137c 100644
> --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> @@ -8,6 +8,8 @@ Required properties:
> SoC.
> "renesas,usb2-phy-r8a7796" if the device is a part of an R8A7796
> SoC.
> +   "renesas,usb2-phy-r8a77965" if the device is a part of an
> +   R8A77965 SoC.

have dt-binding Documentation as a separate patch.

Thanks
Kishon

[PATCH v2 2/2] dt-bindings: pwm: renesas-tpu: Correct SoC part numbers and family names

[Geert Uytterhoeven]

R8A73A4 (not R8A77A4) is R-Mobile APE6,
R8A7740 is R-Mobile (not R-Car) A1.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Simon Horman 
Reviewed-by: Rob Herring 
---
v2:
  - Add Acked-by, Reviewed-by.
---
 Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt 
b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
index 641b5b4c648340ee..fb633129d845a893 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
@@ -3,7 +3,7 @@
 Required Properties:
 
   - compatible: should be one of the following.
-- "renesas,tpu-r8a73a4": for R8A77A4 (R-Mobile APE6) compatible PWM 
controller.
+- "renesas,tpu-r8a73a4": for R8A73A4 (R-Mobile APE6) compatible PWM 
controller.
 - "renesas,tpu-r8a7740": for R8A7740 (R-Mobile A1) compatible PWM 
controller.
 - "renesas,tpu-r8a7790": for R8A7790 (R-Car H2) compatible PWM controller.
 - "renesas,tpu": for generic R-Car TPU PWM controller.
@@ -18,7 +18,7 @@ Required Properties:
 Please refer to pwm.txt in this directory for details of the common PWM 
bindings
 used by client devices.
 
-Example: R8A7740 (R-Car A1) TPU controller node
+Example: R8A7740 (R-Mobile A1) TPU controller node
 
tpu: pwm@e660 {
compatible = "renesas,tpu-r8a7740", "renesas,tpu";
-- 
2.7.4

[PATCH v2 1/2] dt-bindings: pwm: renesas-tpu: Correct example TPU register block size

[Geert Uytterhoeven]

The Timer Pulse Unit on R-Mobile A1 has registers that lie outside the
declared register block.  Enlarge the register block size to fix this.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
Reviewed-by: Rob Herring 
---
v2:
  - Add Reviewed-by.
---
 Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt 
b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
index 1aadc804dae4e30b..641b5b4c648340ee 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
@@ -22,6 +22,6 @@ Example: R8A7740 (R-Car A1) TPU controller node
 
tpu: pwm@e660 {
compatible = "renesas,tpu-r8a7740", "renesas,tpu";
-   reg = <0xe660 0x100>;
+   reg = <0xe660 0x148>;
#pwm-cells = <3>;
};
-- 
2.7.4

[PATCH v2 0/2] dt-bindings: pwm: renesas-tpu: Misc Fixes

[Geert Uytterhoeven]

Hi Thierry,

Here are two small fixes for the DT bindings of the Renesas Timer Pulse
Unit.

Changes compared to v1:
  - Dropped DTS counterpart (applied),
  - Add Acked-by, Reviewed-by.

Thanks for applying!

Geert Uytterhoeven (2):
  dt-bindings: pwm: renesas-tpu: Correct example TPU register block size
  dt-bindings: pwm: renesas-tpu: Correct SoC part numbers and family
names

 Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.7.4

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 v7 1/3] watchdog: renesas_wdt: Add suspend/resume support

[Fabrizio Castro]

Hi Guenter,

thank you for your feedback!

> Subject: Re: [PATCH v7 1/3] watchdog: renesas_wdt: Add suspend/resume support
>
> On 03/02/2018 02:45 AM, Fabrizio Castro wrote:
> > Dear All,
> >
> > perhaps someone from this email thread could explain to me what's the actual
> > (general) expectation from a system perspective (at resume) from the 
> > watchdog,
> > because I can see pitfalls whether 1) we simply start the watchdog at 
> > resume or
> > 2) we pick up from where we left.
> >
> > If we have a system that goes to sleep quite a bit, option 1) may cause the 
> > watchdog
> > to never fire, even though user space is not explicitly pinging the 
> > watchdog. As Geert
> > has pointed out, going to sleep and waking up adds a delay, therefore with 
> > option 2)
> > you may miss the opportunity to ping the watchdog and therefore the system 
> > may
> > restart even when it shouldn't. However, with option 2) user space can make
> > arrangements to compensate for the delay, and when user space compensates 
> > for
> > that it means the system is probably sane. With option 1) instead we are 
> > basically
> > pinging the watchdog without explicitly doing so from user space, which I 
> > don't think
> > is what we want here, but I may be wrong.
> >
> > Could someone please shed some light here?
> >
> If the system goes to sleep so often that the watchdog never triggers just 
> because of
> that, it must either be in pretty good shape, in which case the watchdog 
> doesn't need
> to fire, or it is in bad shape, and the repeated stopping/restarting of the 
> watchdog
> would ultimately cause the system to die with the watchdog stopped anyway.

yeah, in some cases if the system isn't restarted user space may do something 
it isn't supposed
to do , that's why I don't particularly like the idea of implicitly pinging the 
watchdog on resume,
it should be left to user space alone as this is policy related, but that is my 
personal opinion.

>
> Overall, just the fact that the watchdog has to be stopped during suspend is 
> a weak spot.
> Bad luck if the system hangs after the watchdog was stopped. Since suspend is 
> a critical
> operation )in the sense that if anything goes wrong, that is the time for 
> it), that is
> a _real_ weak spot. If anything, we should be concerned about that, not about 
> the exact
> timing of watchdog pings.

so true!

>
> Sure, you can leave it to user space to adjust for the resume time. Let's 
> hope that the
> watchdog daemon does that, and that it gets to run fast enough to actually do 
> it.
> I do wonder though how it would know. Are processes informed about a resume 
> event ?

I was thinking more about making adjustments before going to sleep.

>
> Personally I rather play it safe, meaning I rather give the watchdog a bit of 
> additional
> slack during resume. Having said that, as mentioned before, I am willing to 
> accept
> the patch as is, in the assumption that the authors know what they are doing.

Thank you for this.

Cheers,
Fab

>
> Guenter
>
> > Thanks,
> > Fab
> >
> >
> >> Subject: Re: [PATCH v7 1/3] watchdog: renesas_wdt: Add suspend/resume 
> >> support
> >>
> >> Hi Fabrizio,
> >>
> >> On Thu, Mar 1, 2018 at 7:17 PM, Fabrizio Castro
> >>  wrote:
> >>> On R-Car Gen2 and RZ/G1 the watchdog IP clock needs to be always ON,
> >>> on R-Car Gen3 we power the IP down during suspend.
> >>>
> >>> This commit adds suspend/resume support, so that the watchdog counting
> >>> "pauses" during suspend on all of the SoCs compatible with this driver
> >>> and on those we are now adding support for (R-Car Gen2 and RZ/G1).
> >>>
> >>> Signed-off-by: Fabrizio Castro 
> >>> Signed-off-by: Ramesh Shanmugasundaram 
> >>> 
> >>> ---
> >>> v6->v7:
> >>> * backup and restore register RWTCNT instead of using rwdt_get_timeleft 
> >>> and
> >>>rwdt_set_timeleft
> >>
> >> Thanks for the update (v6 and v7)!
> >>
> >>>
> >>>   drivers/watchdog/renesas_wdt.c | 26 ++
> >>>   1 file changed, 26 insertions(+)
> >>>
> >>> diff --git a/drivers/watchdog/renesas_wdt.c 
> >>> b/drivers/watchdog/renesas_wdt.c
> >>> index 831ef83..024d54e 100644
> >>> --- a/drivers/watchdog/renesas_wdt.c
> >>> +++ b/drivers/watchdog/renesas_wdt.c
> >>> @@ -49,6 +49,7 @@ struct rwdt_priv {
> >>>  void __iomem *base;
> >>>  struct watchdog_device wdev;
> >>>  unsigned long clk_rate;
> >>> +   u16 time_left;
> >>>  u8 cks;
> >>>   };
> >>>
> >>> @@ -203,6 +204,30 @@ static int rwdt_remove(struct platform_device *pdev)
> >>>  return 0;
> >>>   }
> >>>
> >>> +static int __maybe_unused rwdt_suspend(struct device *dev)
> >>> +{
> >>> +   struct rwdt_priv *priv = dev_get_drvdata(dev);
> >>> +
> >>> +   if (watchdog_active(>wdev)) {
> >>> +   priv->time_left = readw(priv->base + RWTCNT);
> >>> +   rwdt_stop(>wdev);
> >>> +  

[PATCH v2] dt-bindings: net: renesas-ravb: Make stream buffer optional

[Geert Uytterhoeven]

The Stream Buffer for EtherAVB-IF (STBE) is an optional component, and
is not present on all SoCs.

Document this in the DT bindings, including a list of SoCs that do have
it.

Fixes: 785ec87483d1e24a ("ravb: document R8A77970 bindings")
Fixes: f231c4178a655b09 ("dt-bindings: net: renesas-ravb: Add support for 
R8A77995 RAVB")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
Acked-by: Sergei Shtylyov 
Reviewed-by: Rob Herring 
---
v2:
  - Add Reviewed-by, Acked-by,
  - Add R-Car M3-N.
---
 Documentation/devicetree/bindings/net/renesas,ravb.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt 
b/Documentation/devicetree/bindings/net/renesas,ravb.txt
index bf071a58f2926ad3..2b5cb655b0e93bfd 100644
--- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -27,7 +27,11 @@ Required properties:
SoC-specific version corresponding to the platform first followed by
the generic version.
 
-- reg: offset and length of (1) the register block and (2) the stream buffer.
+- reg: Offset and length of (1) the register block and (2) the stream buffer.
+   The region for the register block is mandatory.
+   The region for the stream buffer is optional, as it is only present on
+   R-Car Gen2 and RZ/G1 SoCs, and on R-Car H3 (R8A7795), M3-W (R8A7796),
+   and M3-N (R8A77965).
 - interrupts: A list of interrupt-specifiers, one for each entry in
  interrupt-names.
  If interrupt-names is not present, an interrupt specifier
-- 
2.7.4

[git pull] clk: renesas: Updates for v4.17

[Geert Uytterhoeven]

Hi Mike, Stephen,

The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

  Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/clk-renesas-for-v4.17-tag1

for you to fetch changes up to 7ce36da900c0a2ff4777d9ba51c4f1cb74205463:

  clk: renesas: cpg-mssr: Add support for R-Car M3-N (2018-02-26 09:13:29 +0100)


clk: renesas: Updates for v4.17

  - Update legacy DT Kconfig default,
  - Add support for CPU (Z/Z2) clocks on R-Car H3 and M3-W,
  - Add support for the watchdog module clocks on R-Car Gen2 and RZ/G1,
  - Add support for the new R-Car M3-N and V3H SoCs.

Thanks for pulling!


Fabrizio Castro (5):
  clk: renesas: r8a7743: Add rwdt clock
  clk: renesas: r8a7745: Add rwdt clock
  clk: renesas: r8a7790: Add rwdt clock
  clk: renesas: r8a7791/r8a7793: Add rwdt clock
  clk: renesas: r8a7794: Add rwdt clock

Geert Uytterhoeven (2):
  clk: renesas: Stop enabling legacy DT clock support by default
  clk: renesas: r8a7792: Add rwdt clock

Jacopo Mondi (1):
  clk: renesas: cpg-mssr: Add support for R-Car M3-N

Sergei Shtylyov (2):
  dt-bindings: clock: add R8A77980 CPG core clock definitions
  clk: renesas: cpg-mssr: add R8A77980 support

Takeshi Kihara (6):
  clk: renesas: rcar-gen3: Add Z clock divider support
  clk: renesas: rcar-gen3: Add Z2 clock divider support
  clk: renesas: r8a7795: Add Z clock
  clk: renesas: r8a7795: Add Z2 clock
  clk: renesas: r8a7796: Add Z clock
  clk: renesas: r8a7796: Add Z2 clock

 .../devicetree/bindings/clock/renesas,cpg-mssr.txt |   6 +-
 drivers/clk/renesas/Kconfig|  13 +-
 drivers/clk/renesas/Makefile   |   2 +
 drivers/clk/renesas/r8a7743-cpg-mssr.c |   2 +
 drivers/clk/renesas/r8a7745-cpg-mssr.c |   2 +
 drivers/clk/renesas/r8a7790-cpg-mssr.c |   2 +
 drivers/clk/renesas/r8a7791-cpg-mssr.c |   2 +
 drivers/clk/renesas/r8a7792-cpg-mssr.c |   2 +
 drivers/clk/renesas/r8a7794-cpg-mssr.c |   2 +
 drivers/clk/renesas/r8a7795-cpg-mssr.c |   2 +
 drivers/clk/renesas/r8a7796-cpg-mssr.c |   2 +
 drivers/clk/renesas/r8a77965-cpg-mssr.c| 334 +
 drivers/clk/renesas/r8a77980-cpg-mssr.c| 227 ++
 drivers/clk/renesas/rcar-gen3-cpg.c| 143 +
 drivers/clk/renesas/rcar-gen3-cpg.h|   2 +
 drivers/clk/renesas/renesas-cpg-mssr.c |  12 +
 drivers/clk/renesas/renesas-cpg-mssr.h |   2 +
 include/dt-bindings/clock/r8a77965-cpg-mssr.h  |  62 
 include/dt-bindings/clock/r8a77980-cpg-mssr.h  |  51 
 19 files changed, 867 insertions(+), 3 deletions(-)
 create mode 100644 drivers/clk/renesas/r8a77965-cpg-mssr.c
 create mode 100644 drivers/clk/renesas/r8a77980-cpg-mssr.c
 create mode 100644 include/dt-bindings/clock/r8a77965-cpg-mssr.h
 create mode 100644 include/dt-bindings/clock/r8a77980-cpg-mssr.h

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 0/5] Add R8A77970/V3MSK LVDS/HDMI support

[Sergei Shtylyov]

On 3/2/2018 1:21 PM, Simon Horman wrote:


Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180227-v4.16-rc3' tag. We're adding the R8A77970 FCPVD/VSPD/
DU/LVDS device nodes and then describing the HDMI encoder connected to the LVDS
output (we're omitting the LVDS decoder for now). These patches depend on
the recent R8A77970 DU/LVDS rework patches by Laurent in order to work...   


Need to mention that the DU driver silently fails to probe now. I do
hope that this is not due to my updates. :-)


Please test that theory.


Yeah, after sucking in the recent versions of the DU/LVDS patches and 
uncommenting
and fixing rejects in a couple patches here, the graphical console works again. 
:-)


Ok, but does this patchset cause a regression? If so it seems


 Sorry, somehow missed that question. No regression is possible as the 
display just
doesn't work before these patches are applied. It's just that it doesn't start 
to work
until the recent DU/LVDS driver updates are applied.


Ok, but my question remains: does the display work before these patches?


   No, there are no FCPVD/VSPD/DU/LVDS device nodes in R8A77970 TDs.

MBR, Sergei

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

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:31 EET Niklas Söderlund wrote:
> There was never proper support in the VIN driver to deliver ALTERNATING
> field format to user-space, remove this field option. The problem is
> that ALTERNATING filed order requires the sequence numbers of buffers

s/filed/field/

> returned to userspace to reflect if fields where dropped or not,
> something which is not possible with the VIN drivers capture logic.
> 
> The VIN driver can still capture from a video source which delivers
> frames in ALTERNATING field order, but needs to combine them using the
> VIN hardware into INTERLACED field order. Before this change if a source
> was delivering fields using ALTERNATE the driver would default to
> combining them using this hardware feature. Only if the user explicitly
> requested ALTERNATE filed order would incorrect frames be delivered.
> 
> The height should not be cut in half for the format for TOP or BOTTOM
> fields settings. This was a mistake and it was made visible by the
> scaling refactoring. Correct behavior is that the user should request a
> frame size that fits the half height frame reflected in the field
> setting. If not the VIN will do its best to scale the top or bottom to
> the requested format and cropping and scaling do not work as expected.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c  | 15 +--
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 40 +++---
>  2 files changed, 10 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> fd14be20a6604d7a..c8831e189d362c8b 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -617,7 +617,6 @@ static int rvin_setup(struct rvin_dev *vin)
>   case V4L2_FIELD_INTERLACED_BT:
>   vnmc = VNMC_IM_FULL | VNMC_FOC;
>   break;
> - case V4L2_FIELD_ALTERNATE:

Just to make sure I understand things correctly, field will never be 
V4L2_FIELD_ALTERNATE after this patch, right ?

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

I might be wrong, but if this function is called from S_STD or S_DV_TIMINGS 
and userspace calls G_FMT immediately after that, won't it get 

Re: [PATCH v11 17/32] rcar-vin: move media bus configuration to struct rvin_info

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:36 EET Niklas Söderlund wrote:
> Bus configuration will once the driver is extended to support Gen3
> contain information not specific to only the directly connected parallel
> subdevice. Move it to struct rvin_dev to show it's not always coupled
> to the parallel subdevice.

The subject line still mentions rvin_info. Are you so emotionally attached to 
it that you have trouble fixing that ? ;-)

> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 18 +-
>  drivers/media/platform/rcar-vin/rcar-dma.c  | 11 ++-
>  drivers/media/platform/rcar-vin/rcar-v4l2.c |  2 +-
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  9 -
>  4 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> cc863e4ec9a4d4b3..449175c3133e42c6 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -65,10 +65,10 @@ static int rvin_digital_subdevice_attach(struct rvin_dev
> *vin, vin->digital->sink_pad = ret < 0 ? 0 : ret;
> 
>   /* Find compatible subdevices mbus format */
> - vin->digital->code = 0;
> + vin->mbus_code = 0;
>   code.index = 0;
>   code.pad = vin->digital->source_pad;
> - while (!vin->digital->code &&
> + while (!vin->mbus_code &&
>  !v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
>   code.index++;
>   switch (code.code) {
> @@ -76,16 +76,16 @@ static int rvin_digital_subdevice_attach(struct rvin_dev
> *vin, case MEDIA_BUS_FMT_UYVY8_2X8:
>   case MEDIA_BUS_FMT_UYVY10_2X10:
>   case MEDIA_BUS_FMT_RGB888_1X24:
> - vin->digital->code = code.code;
> + vin->mbus_code = code.code;
>   vin_dbg(vin, "Found media bus format for %s: %d\n",
> - subdev->name, vin->digital->code);
> + subdev->name, vin->mbus_code);
>   break;
>   default:
>   break;
>   }
>   }
> 
> - if (!vin->digital->code) {
> + if (!vin->mbus_code) {
>   vin_err(vin, "Unsupported media bus format for %s\n",
>   subdev->name);
>   return -EINVAL;
> @@ -190,16 +190,16 @@ static int rvin_digital_parse_v4l2(struct device *dev,
> if (vep->base.port || vep->base.id)
>   return -ENOTCONN;
> 
> - rvge->mbus_cfg.type = vep->bus_type;
> + vin->mbus_cfg.type = vep->bus_type;
> 
> - switch (rvge->mbus_cfg.type) {
> + switch (vin->mbus_cfg.type) {
>   case V4L2_MBUS_PARALLEL:
>   vin_dbg(vin, "Found PARALLEL media bus\n");
> - rvge->mbus_cfg.flags = vep->bus.parallel.flags;
> + vin->mbus_cfg.flags = vep->bus.parallel.flags;
>   break;
>   case V4L2_MBUS_BT656:
>   vin_dbg(vin, "Found BT656 media bus\n");
> - rvge->mbus_cfg.flags = 0;
> + vin->mbus_cfg.flags = 0;
>   break;
>   default:
>   vin_err(vin, "Unknown media bus type\n");
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> c8831e189d362c8b..4ebf76c30a3e9117 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -633,7 +633,7 @@ static int rvin_setup(struct rvin_dev *vin)
>   /*
>* Input interface
>*/
> - switch (vin->digital->code) {
> + switch (vin->mbus_code) {
>   case MEDIA_BUS_FMT_YUYV8_1X16:
>   /* BT.601/BT.1358 16bit YCbCr422 */
>   vnmc |= VNMC_INF_YUV16;
> @@ -641,7 +641,7 @@ static int rvin_setup(struct rvin_dev *vin)
>   break;
>   case MEDIA_BUS_FMT_UYVY8_2X8:
>   /* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
> - vnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?
> + vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
>   VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
>   input_is_yuv = true;
>   break;
> @@ -650,7 +650,7 @@ static int rvin_setup(struct rvin_dev *vin)
>   break;
>   case MEDIA_BUS_FMT_UYVY10_2X10:
>   /* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
> - vnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?
> + vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
>   VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
>   input_is_yuv = true;
>   break;
> @@ -662,11 +662,11 @@ static int rvin_setup(struct rvin_dev *vin)
>   dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
> 

Re: [PATCH v11 19/32] rcar-vin: add function to manipulate Gen3 chsel value

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:38 EET Niklas Söderlund wrote:
> On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
> feature of this register is that it's only present in the VIN0 and VIN4
> instances. The register in VIN0 controls the routing for VIN0-3 and the
> register in VIN4 controls routing for VIN4-7.
> 
> To be able to control routing from a media device this function is need
> to control runtime PM for the subgroup master (VIN0 and VIN4). The
> subgroup master must be switched on before the register is manipulated,
> once the operation is complete it's safe to switch the master off and
> the new routing will still be in effect.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 38 +++
>  drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
>  2 files changed, 40 insertions(+)

By the way it would be useful if you added per-patch changelogs. You can 
capture them in the commit message below a --- line.

> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> 57bb288b3ca67a60..3fb9c325285c5a5a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -16,6 +16,7 @@
> 
>  #include 
>  #include 
> +#include 
> 
>  #include 
> 
> @@ -1228,3 +1229,40 @@ int rvin_dma_register(struct rvin_dev *vin, int irq)
> 
>   return ret;
>  }
> +
> +/* 
> + * Gen3 CHSEL manipulation
> + */
> +
> +/*
> + * There is no need to have locking around changing the routing
> + * as it's only possible to do so when no VIN in the group is
> + * streaming so nothing can race with the VNMC register.
> + */
> +int rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel)
> +{
> + u32 ifmd, vnmc;
> + int ret;
> +
> + ret = pm_runtime_get_sync(vin->dev);
> + if (ret < 0)
> + return ret;
> +
> + /* Make register writes take effect immediately. */
> + vnmc = rvin_read(vin, VNMC_REG);
> + rvin_write(vin, vnmc & ~VNMC_VUP, VNMC_REG);
> +
> + ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
> + VNCSI_IFMD_CSI_CHSEL(chsel);
> +
> + rvin_write(vin, ifmd, VNCSI_IFMD_REG);
> +
> + vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
> +
> + /* Restore VNMC. */
> + rvin_write(vin, vnmc, VNMC_REG);
> +
> + pm_runtime_put(vin->dev);
> +
> + return ret;
> +}
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h index
> b3802651eaa78ea9..666308946eb4994d 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -165,4 +165,6 @@ const struct rvin_video_format
> *rvin_format_from_pixel(u32 pixelformat); /* Cropping, composing and
> scaling */
>  void rvin_crop_scale_comp(struct rvin_dev *vin);
> 
> +int rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel);
> +
>  #endif

-- 
Regards,

Laurent Pinchart

[git pull] pinctrl: sh-pfc: Updates for v4.17

[Geert Uytterhoeven]

Hi Linus,

The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

  Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/sh-pfc-for-v4.17-tag1

for you to fetch changes up to a8ab4f2bd8a5298679dabe16910322625a0df247:

  pinctrl: sh-pfc: r8a77965: Add support for INTC-EX IRQ pins (2018-02-28 
09:17:54 +0100)


pinctrl: sh-pfc: Updates for v4.17

  - Add DU and VIN pin groups on R-Car D3,
  - Add HDMI, TMU, and VIN pin groups on R-Car H3 and M3-W,
  - Add support for the new R-Car M3-N SoC,
  - Small fixes and cleanups.

Thanks for pulling!


Geert Uytterhoeven (1):
  dt-bindings: pinctrl: sh-pfc: Correct SoC family name for R8A7778

Jacopo Mondi (3):
  pinctrl: sh-pfc: Initial R-Car M3-N support
  pinctrl: sh-pfc: r8a77965: Add SCIFs groups/functions
  pinctrl: sh-pfc: r8a77965: Add EtherAVB groups/functions

Markus Elfring (1):
  pinctrl: sh-pfc: Use seq_puts() in sh_pfc_pin_dbg_show()

Takeshi Kihara (10):
  pinctrl: sh-pfc: r8a7795: Fix MOD_SEL register pin assignment for SSI 
pins group
  pinctrl: sh-pfc: r8a7796: Fix MOD_SEL register pin assignment for SSI 
pins group
  pinctrl: sh-pfc: r8a7796: Fix IPSR and MOD_SEL register pin assignment 
for NDFC pins group
  pinctrl: sh-pfc: r8a7795: Add HDMI pins, groups and functions
  pinctrl: sh-pfc: r8a7795-es1: Add HDMI pins, groups and functions
  pinctrl: sh-pfc: r8a7796: Add HDMI pins, groups and functions
  pinctrl: sh-pfc: r8a7795: Add TMU pins, groups and functions
  pinctrl: sh-pfc: r8a7795-es1: Add TMU pins, groups and functions
  pinctrl: sh-pfc: r8a7796: Add TMU pins, groups and functions
  pinctrl: sh-pfc: r8a77965: Add support for INTC-EX IRQ pins

Ulrich Hecht (4):
  pinctrl: sh-pfc: r8a77995: Add DU pins, groups and function
  pinctrl: sh-pfc: r8a7796: Add VIN4, VIN5 pins, groups and functions
  pinctrl: sh-pfc: r8a7795: Add VIN4, VIN5 pins, groups and functions
  pinctrl: sh-pfc: r8a77995: Add VIN4 pins, groups and function

 .../bindings/pinctrl/renesas,pfc-pinctrl.txt   |3 +-
 drivers/pinctrl/sh-pfc/Kconfig |5 +
 drivers/pinctrl/sh-pfc/Makefile|1 +
 drivers/pinctrl/sh-pfc/core.c  |6 +
 drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c   |   72 +-
 drivers/pinctrl/sh-pfc/pfc-r8a7795.c   |  564 +++-
 drivers/pinctrl/sh-pfc/pfc-r8a7796.c   |  569 +++-
 drivers/pinctrl/sh-pfc/pfc-r8a77965.c  | 3193 
 drivers/pinctrl/sh-pfc/pfc-r8a77995.c  |  293 ++
 drivers/pinctrl/sh-pfc/pinctrl.c   |2 +-
 drivers/pinctrl/sh-pfc/sh_pfc.h|1 +
 11 files changed, 4659 insertions(+), 50 deletions(-)
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a77965.c

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 5/5] dt-bindings: at24: add bindings for Rohm BR24T01

[Bartosz Golaszewski]

2018-01-29 16:45 GMT+01:00 Ulrich Hecht :
> Both manufacturer and name variant.
>
> Signed-off-by: Ulrich Hecht 
> ---
>  Documentation/devicetree/bindings/eeprom/at24.txt | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt 
> b/Documentation/devicetree/bindings/eeprom/at24.txt
> index 1812c84..dd29937 100644
> --- a/Documentation/devicetree/bindings/eeprom/at24.txt
> +++ b/Documentation/devicetree/bindings/eeprom/at24.txt
> @@ -40,6 +40,7 @@ Required properties:
>  "microchip",
>  "ramtron",
>  "renesas",
> +"rohm",
>  "nxp",
>  "st",
>
> @@ -47,6 +48,7 @@ Required properties:
>  variants of the above. Known such exceptions are listed 
> below:
>
>  "renesas,r1ex24002" - the fallback is "atmel,24c02"
> +"rohm,br24t01" - the fallback is "atmel,24c01"
>
>- reg: The I2C address of the EEPROM.
>
> --
> 2.7.4
>

Applied to for-next, thanks.

Bart

Re: [PATCH v11 16/32] rcar-vin: read subdevice format for crop only when needed

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:35 EET Niklas Söderlund wrote:
> Instead of caching the subdevice format each time the video device
> format is set read it directly when it's needed. As it turns out the
> format is only needed when figuring out the max rectangle for cropping.
> 
> This simplifies the code and makes it clearer what the source format is
> used for.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 158 +
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  12 ---
>  2 files changed, 80 insertions(+), 90 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> 3290e603b44cdf3a..55640c6b2a1200ca 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -144,67 +144,62 @@ static int rvin_format_align(struct rvin_dev *vin,
> struct v4l2_pix_format *pix) * V4L2
>   */
> 
> -static void rvin_reset_crop_compose(struct rvin_dev *vin)
> +static int rvin_get_vin_format_from_source(struct rvin_dev *vin,
> +struct v4l2_pix_format *pix)
>  {
> + struct v4l2_subdev_format fmt = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + .pad = vin->digital->source_pad,
> + };
> + int ret;
> +
> + ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
> + if (ret)
> + return ret;
> +
> + v4l2_fill_pix_format(pix, );
> +
> + return rvin_format_align(vin, pix);
> +}
> +
> +static int rvin_reset_format(struct rvin_dev *vin)
> +{
> + int ret;
> +
> + ret = rvin_get_vin_format_from_source(vin, >format);
> + if (ret)
> + return ret;
> +
>   vin->crop.top = vin->crop.left = 0;
> - vin->crop.width = vin->source.width;
> - vin->crop.height = vin->source.height;
> + vin->crop.width = vin->format.width;
> + vin->crop.height = vin->format.height;
> 
>   vin->compose.top = vin->compose.left = 0;
>   vin->compose.width = vin->format.width;
>   vin->compose.height = vin->format.height;
> -}
> -
> -static int rvin_reset_format(struct rvin_dev *vin)
> -{
> - struct v4l2_subdev_format fmt = {
> - .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> - };
> - struct v4l2_mbus_framefmt *mf = 
> - int ret;
> -
> - fmt.pad = vin->digital->source_pad;
> -
> - ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
> - if (ret)
> - return ret;
> -
> - vin->format.width   = mf->width;
> - vin->format.height  = mf->height;
> - vin->format.colorspace  = mf->colorspace;
> - vin->format.field   = mf->field;
> -
> - rvin_reset_crop_compose(vin);
> -
> - vin->format.bytesperline = rvin_format_bytesperline(>format);
> - vin->format.sizeimage = rvin_format_sizeimage(>format);
> 
>   return 0;
>  }
> 
> -static int __rvin_try_format_source(struct rvin_dev *vin,
> - u32 which,
> - struct v4l2_pix_format *pix,
> - struct rvin_source_fmt *source)
> +static int rvin_try_format(struct rvin_dev *vin, u32 which,
> +struct v4l2_pix_format *pix,
> +struct v4l2_rect *crop, struct v4l2_rect *compose)
>  {
> - struct v4l2_subdev *sd;
> + struct v4l2_subdev *sd = vin_to_source(vin);
>   struct v4l2_subdev_pad_config *pad_cfg;
>   struct v4l2_subdev_format format = {
>   .which = which,
> + .pad = vin->digital->source_pad,
>   };
>   enum v4l2_field field;
>   u32 width, height;
>   int ret;
> 
> - sd = vin_to_source(vin);
> -
> - v4l2_fill_mbus_format(, pix, vin->digital->code);
> -
>   pad_cfg = v4l2_subdev_alloc_pad_config(sd);
>   if (pad_cfg == NULL)
>   return -ENOMEM;
> 
> - format.pad = vin->digital->source_pad;
> + v4l2_fill_mbus_format(, pix, vin->digital->code);
> 
>   /* Allow the video device to override field and to scale */
>   field = pix->field;
> @@ -217,34 +212,34 @@ static int __rvin_try_format_source(struct rvin_dev
> *vin,
> 
>   v4l2_fill_pix_format(pix, );
> 
> - source->width = pix->width;
> - source->height = pix->height;
> + crop->top = crop->left = 0;
> + crop->width = pix->width;
> + crop->height = pix->height;
> +
> + /*
> +  * If source is ALTERNATE the driver will use the VIN hardware
> +  * to INTERLACE it. The crop height then needs to be doubled.
> +  */
> + if (pix->field == V4L2_FIELD_ALTERNATE)
> + crop->height *= 2;
> +
> + if (field != V4L2_FIELD_ANY)
> + pix->field = field;
> 
> - pix->field = field;
>   pix->width = width;
>   pix->height = height;
> 
> - vin_dbg(vin, "Source 

Re: [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

[Simon Horman]

On Thu, Mar 01, 2018 at 06:28:29PM +0300, Sergei Shtylyov wrote:
> On 03/01/2018 12:54 PM, Simon Horman wrote:
> 
> > Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
> > 'renesas-devel-20180227-v4.16-rc3' tag. We're adding the R8A77970 
> > FCPVD/VSPD/
> > DU/LVDS device nodes and then describing the HDMI encoder connected to 
> > the LVDS
> > output (we're omitting the LVDS decoder for now). These patches depend 
> > on
> > the recent R8A77970 DU/LVDS rework patches by Laurent in order to 
> > work...   
> 
> Need to mention that the DU driver silently fails to probe now. I do
> hope that this is not due to my updates. :-)
> >>>
> >>> Please test that theory.
> >>
> >>Yeah, after sucking in the recent versions of the DU/LVDS patches and 
> >> uncommenting
> >> and fixing rejects in a couple patches here, the graphical console works 
> >> again. :-)
> > 
> > Ok, but does this patchset cause a regression? If so it seems
> 
> Sorry, somehow missed that question. No regression is possible as the 
> display just
> doesn't work before these patches are applied. It's just that it doesn't 
> start to work
> until the recent DU/LVDS driver updates are applied.

Ok, but my question remains: does the display work before these patches?

RE: [PATCH v7 1/3] watchdog: renesas_wdt: Add suspend/resume support

[Fabrizio Castro]

Dear All,

perhaps someone from this email thread could explain to me what's the actual
(general) expectation from a system perspective (at resume) from the watchdog,
because I can see pitfalls whether 1) we simply start the watchdog at resume or
2) we pick up from where we left.

If we have a system that goes to sleep quite a bit, option 1) may cause the 
watchdog
to never fire, even though user space is not explicitly pinging the watchdog. 
As Geert
has pointed out, going to sleep and waking up adds a delay, therefore with 
option 2)
you may miss the opportunity to ping the watchdog and therefore the system may
restart even when it shouldn't. However, with option 2) user space can make
arrangements to compensate for the delay, and when user space compensates for
that it means the system is probably sane. With option 1) instead we are 
basically
pinging the watchdog without explicitly doing so from user space, which I don't 
think
is what we want here, but I may be wrong.

Could someone please shed some light here?

Thanks,
Fab


> Subject: Re: [PATCH v7 1/3] watchdog: renesas_wdt: Add suspend/resume support
>
> Hi Fabrizio,
>
> On Thu, Mar 1, 2018 at 7:17 PM, Fabrizio Castro
>  wrote:
> > On R-Car Gen2 and RZ/G1 the watchdog IP clock needs to be always ON,
> > on R-Car Gen3 we power the IP down during suspend.
> >
> > This commit adds suspend/resume support, so that the watchdog counting
> > "pauses" during suspend on all of the SoCs compatible with this driver
> > and on those we are now adding support for (R-Car Gen2 and RZ/G1).
> >
> > Signed-off-by: Fabrizio Castro 
> > Signed-off-by: Ramesh Shanmugasundaram 
> > 
> > ---
> > v6->v7:
> > * backup and restore register RWTCNT instead of using rwdt_get_timeleft and
> >   rwdt_set_timeleft
>
> Thanks for the update (v6 and v7)!
>
> >
> >  drivers/watchdog/renesas_wdt.c | 26 ++
> >  1 file changed, 26 insertions(+)
> >
> > diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> > index 831ef83..024d54e 100644
> > --- a/drivers/watchdog/renesas_wdt.c
> > +++ b/drivers/watchdog/renesas_wdt.c
> > @@ -49,6 +49,7 @@ struct rwdt_priv {
> > void __iomem *base;
> > struct watchdog_device wdev;
> > unsigned long clk_rate;
> > +   u16 time_left;
> > u8 cks;
> >  };
> >
> > @@ -203,6 +204,30 @@ static int rwdt_remove(struct platform_device *pdev)
> > return 0;
> >  }
> >
> > +static int __maybe_unused rwdt_suspend(struct device *dev)
> > +{
> > +   struct rwdt_priv *priv = dev_get_drvdata(dev);
> > +
> > +   if (watchdog_active(>wdev)) {
> > +   priv->time_left = readw(priv->base + RWTCNT);
> > +   rwdt_stop(>wdev);
> > +   }
> > +   return 0;
> > +}
> > +
> > +static int __maybe_unused rwdt_resume(struct device *dev)
> > +{
> > +   struct rwdt_priv *priv = dev_get_drvdata(dev);
> > +
> > +   if (watchdog_active(>wdev)) {
> > +   rwdt_start(>wdev);
> > +   rwdt_write(priv, priv->time_left, RWTCNT);
>
> Upon given it more thought, I'm a bit worried about restoring the
> original time left.
> In my experiments, it may take a few seconds before userspace fully resumes.
> If time_left was a small value, the system may reboot before userspace has
> a chance to send its next ping.
> This was with NFS root, so heavily impacted by the delays introduced by the
> PHY link getting up again.
>
> So just using rwdt_stop()/rwdt_start() may be the safest option.
>
> 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



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

Re: [PATCH v9 19/28] rcar-vin: use different v4l2 operations in media controller mode

[Laurent Pinchart]

Hi Niklas,

On Friday, 19 January 2018 02:46:03 EET Niklas Söderlund wrote:
> Hi Laurent,
> 
> Thanks for your comments.
> 
> Apart from the issue with the input API Hans pointed which indicates I
> need to keep that around until it's fixed in the framework I agree with
> all your comments but one.
> 
> 
> 
> On 2017-12-08 12:14:05 +0200, Laurent Pinchart wrote:
> >> @@ -628,7 +628,8 @@ static int rvin_setup(struct rvin_dev *vin)
> >>/* Default to TB */
> >>vnmc = VNMC_IM_FULL;
> >>/* Use BT if video standard can be read and is 60 Hz format */
> >> -  if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
> >> +  if (!vin->info->use_mc &&
> >> +  !v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
> >>if (std & V4L2_STD_525_60)
> >>vnmc = VNMC_IM_FULL | VNMC_FOC;
> >>}
> > 
> > I think the subdev should be queried in rcar-v4l2.c and the information
> > cached in the rvin_dev structure instead of queried here. Interactions
> > with the subdev should be minimized in rvin-dma.c. You can fix this in a
> > separate patch if you prefer.
> 
> This can't be a cached value it needs to be read at stream on time. The
> input source could have changed format, e.g. the user may have
> disconnected a NTSC source and plugged in a PAL.

Please note that in that case the source subdev will not have changed its 
format yet, it only does so when the s_std operation is called.

> This is a shame as I otherwise agree with you that interactions with the
> subdevice should be kept at a minimum.
> 
> 

-- 
Regards,

Laurent Pinchart

Re: [PATCH v11 21/32] rcar-vin: use different v4l2 operations in media controller mode

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:40 EET Niklas Söderlund wrote:
> When the driver runs in media controller mode it should not directly
> control the subdevice instead userspace will be responsible for
> configuring the pipeline. To be able to run in this mode a different set
> of v4l2 operations needs to be used.
> 
> Add a new set of v4l2 operations to support operation without directly
> interacting with the source subdevice.
> 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c  |   3 +-
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 161 -
>  2 files changed, 160 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> 3fb9c325285c5a5a..27d0c098f1da40f9 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -628,7 +628,8 @@ static int rvin_setup(struct rvin_dev *vin)
>   /* Default to TB */
>   vnmc = VNMC_IM_FULL;
>   /* Use BT if video standard can be read and is 60 Hz format */
> - if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
> + if (!vin->info->use_mc &&
> + !v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {

To avoid spreading the discussion across several mail threads, I'll repeat my 
comment made today on v9:

> > I think the subdev should be queried in rcar-v4l2.c and the information
> > cached in the rvin_dev structure instead of queried here. Interactions
> > with the subdev should be minimized in rvin-dma.c. You can fix this in a
> > separate patch if you prefer.
>
> This can't be a cached value it needs to be read at stream on time. The
> input source could have changed format, e.g. the user may have
> disconnected a NTSC source and plugged in a PAL.

Please note that in that case the source subdev will not have changed its 
format yet, it only does so when the s_std operation is called.

> This is a shame as I otherwise agree with you that interactions with the
> subdevice should be kept at a minimum.

>   if (std & V4L2_STD_525_60)
>   vnmc = VNMC_IM_FULL | VNMC_FOC;
>   }
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> 20be21cb1cf521e5..8d92710efffa7276 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -18,12 +18,16 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include "rcar-vin.h"
> 
>  #define RVIN_DEFAULT_FORMAT  V4L2_PIX_FMT_YUYV
> +#define RVIN_DEFAULT_WIDTH   800
> +#define RVIN_DEFAULT_HEIGHT  600
>  #define RVIN_DEFAULT_FIELD   V4L2_FIELD_NONE
> +#define RVIN_DEFAULT_COLORSPACE  V4L2_COLORSPACE_SRGB
> 
>  /* 
>   * Format Conversions
> @@ -667,6 +671,74 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>   .vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
>  };
> 
> +/* 
> + * V4L2 Media Controller
> + */
> +
> +static int rvin_mc_try_fmt_vid_cap(struct file *file, void *priv,
> +struct v4l2_format *f)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> +
> + return rvin_format_align(vin, >fmt.pix);
> +}
> +
> +static int rvin_mc_s_fmt_vid_cap(struct file *file, void *priv,
> +  struct v4l2_format *f)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + int ret;
> +
> + if (vb2_is_busy(>queue))
> + return -EBUSY;
> +
> + ret = rvin_format_align(vin, >fmt.pix);
> + if (ret)
> + return ret;
> +
> + vin->format = f->fmt.pix;
> +
> + return 0;
> +}
> +
> +static int rvin_mc_enum_input(struct file *file, void *priv,
> +   struct v4l2_input *i)
> +{
> + if (i->index != 0)
> + return -EINVAL;
> +
> + i->type = V4L2_INPUT_TYPE_CAMERA;
> + strlcpy(i->name, "Camera", sizeof(i->name));
> +
> + return 0;
> +}
> +
> +static const struct v4l2_ioctl_ops rvin_mc_ioctl_ops = {
> + .vidioc_querycap= rvin_querycap,
> + .vidioc_try_fmt_vid_cap = rvin_mc_try_fmt_vid_cap,
> + .vidioc_g_fmt_vid_cap   = rvin_g_fmt_vid_cap,
> + .vidioc_s_fmt_vid_cap   = rvin_mc_s_fmt_vid_cap,
> + .vidioc_enum_fmt_vid_cap= rvin_enum_fmt_vid_cap,
> +
> + .vidioc_enum_input  = rvin_mc_enum_input,
> + .vidioc_g_input = rvin_g_input,
> + .vidioc_s_input = rvin_s_input,
> +
> + .vidioc_reqbufs = 

Re: [PATCH v11 26/32] rcar-vin: add chsel information to rvin_info

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:45 EET Niklas Söderlund wrote:
> Each Gen3 SoC has a limited set of predefined routing possibilities for
> which CSI-2 device and channel can be routed to which VIN instance.
> Prepare to store this information in the struct rvin_info.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-vin.h | 42 +++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h index
> 07cde9e1ab01ca51..6150a883e17f8479 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -43,6 +43,14 @@ enum model_id {
>   RCAR_GEN3,
>  };
> 
> +enum rvin_csi_id {
> + RVIN_CSI20,
> + RVIN_CSI21,
> + RVIN_CSI40,
> + RVIN_CSI41,
> + RVIN_CSI_MAX,
> +};
> +
>  /**
>   * STOPPED  - No operation in progress
>   * RUNNING  - Operation in progress have buffers
> @@ -81,12 +89,45 @@ struct rvin_graph_entity {
>   unsigned int sink_pad;
>  };
> 
> +/**
> + * struct rvin_group_route - describes a route from a channel of a
> + *   CSI-2 receiver to a VIN
> + *
> + * @vin: VIN ID.
> + * @csi: CSI-2 receiver ID.
> + * @chan:Output channel of the CSI-2 receiver.

Do you think channel instead of chan would be too long ?

> + * @mask:Bitmask of the different CHSEL register values that
> + *   allows for a route from @csi + @chan to @vin.

s/allows/allow/

> + *
> + * .. note::
> + *   Each R-Car CSI-2 receiver has four output channels facing the VIN
> + *   devices, each channel can carry one CSI-2 Virtual Channel (VC).
> + *   There are no correlation between channel number and CSI-2 VC. It's

s/are/is/

> + *   up to the CSI-2 receiver driver to configure which VC is output
> + *   on which channel, the VIN devices only care about output channels.
> + *
> + *   There are in some cases multiple CHSEL register settings which would
> + *   allow for the same route from @csi + @chan to @vin. For example
> + *   on R-Car H3 both the CHSEL values 0 and 3 allows for a route from

s/allows/allow/

> + *   CSI40/VC0 to VIN0. All possible CHSEL values for a route need to be
> + *   recorded as a bitmask in @mask, in this example bit 0 and 3 should
> + *   be set.
> + */
> +struct rvin_group_route {
> + unsigned int vin;
> + enum rvin_csi_id csi;
> + unsigned char chan;
> + unsigned int mask;
> +};

Repeating my comments on v10,

You can make chan an unsigned int, the compiler will pad the field anyway.

I think it would be clearer to order the fields in "from -> to: configuration" 
order (csi, channel, vin, mask).

>  /**
>   * struct rvin_info - Information about the particular VIN implementation
>   * @model:   VIN model
>   * @use_mc:  use media controller instead of controlling subdevice
>   * @max_width:   max input width the VIN supports
>   * @max_height:  max input height the VIN supports
> + * @routes:  list of possible routes from the CSI-2 recivers to
> + *   all VINs. The list mush be NULL terminated.
>   */
>  struct rvin_info {
>   enum model_id model;
> @@ -94,6 +135,7 @@ struct rvin_info {
> 
>   unsigned int max_width;
>   unsigned int max_height;
> + const struct rvin_group_route *routes;
>  };
> 
>  /**

-- 
Regards,

Laurent Pinchart

Re: [PATCH v7 1/3] watchdog: renesas_wdt: Add suspend/resume support

[Guenter Roeck]

On 03/02/2018 02:45 AM, Fabrizio Castro wrote:

Dear All,

perhaps someone from this email thread could explain to me what's the actual
(general) expectation from a system perspective (at resume) from the watchdog,
because I can see pitfalls whether 1) we simply start the watchdog at resume or
2) we pick up from where we left.

If we have a system that goes to sleep quite a bit, option 1) may cause the 
watchdog
to never fire, even though user space is not explicitly pinging the watchdog. 
As Geert
has pointed out, going to sleep and waking up adds a delay, therefore with 
option 2)
you may miss the opportunity to ping the watchdog and therefore the system may
restart even when it shouldn't. However, with option 2) user space can make
arrangements to compensate for the delay, and when user space compensates for
that it means the system is probably sane. With option 1) instead we are 
basically
pinging the watchdog without explicitly doing so from user space, which I don't 
think
is what we want here, but I may be wrong.

Could someone please shed some light here?


If the system goes to sleep so often that the watchdog never triggers just 
because of
that, it must either be in pretty good shape, in which case the watchdog 
doesn't need
to fire, or it is in bad shape, and the repeated stopping/restarting of the 
watchdog
would ultimately cause the system to die with the watchdog stopped anyway.

Overall, just the fact that the watchdog has to be stopped during suspend is a 
weak spot.
Bad luck if the system hangs after the watchdog was stopped. Since suspend is a 
critical
operation )in the sense that if anything goes wrong, that is the time for it), 
that is
a _real_ weak spot. If anything, we should be concerned about that, not about 
the exact
timing of watchdog pings.

Sure, you can leave it to user space to adjust for the resume time. Let's hope 
that the
watchdog daemon does that, and that it gets to run fast enough to actually do 
it.
I do wonder though how it would know. Are processes informed about a resume 
event ?

Personally I rather play it safe, meaning I rather give the watchdog a bit of 
additional
slack during resume. Having said that, as mentioned before, I am willing to 
accept
the patch as is, in the assumption that the authors know what they are doing.

Guenter


Thanks,
Fab



Subject: Re: [PATCH v7 1/3] watchdog: renesas_wdt: Add suspend/resume support

Hi Fabrizio,

On Thu, Mar 1, 2018 at 7:17 PM, Fabrizio Castro
 wrote:

On R-Car Gen2 and RZ/G1 the watchdog IP clock needs to be always ON,
on R-Car Gen3 we power the IP down during suspend.

This commit adds suspend/resume support, so that the watchdog counting
"pauses" during suspend on all of the SoCs compatible with this driver
and on those we are now adding support for (R-Car Gen2 and RZ/G1).

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
---
v6->v7:
* backup and restore register RWTCNT instead of using rwdt_get_timeleft and
   rwdt_set_timeleft


Thanks for the update (v6 and v7)!



  drivers/watchdog/renesas_wdt.c | 26 ++
  1 file changed, 26 insertions(+)

diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
index 831ef83..024d54e 100644
--- a/drivers/watchdog/renesas_wdt.c
+++ b/drivers/watchdog/renesas_wdt.c
@@ -49,6 +49,7 @@ struct rwdt_priv {
 void __iomem *base;
 struct watchdog_device wdev;
 unsigned long clk_rate;
+   u16 time_left;
 u8 cks;
  };

@@ -203,6 +204,30 @@ static int rwdt_remove(struct platform_device *pdev)
 return 0;
  }

+static int __maybe_unused rwdt_suspend(struct device *dev)
+{
+   struct rwdt_priv *priv = dev_get_drvdata(dev);
+
+   if (watchdog_active(>wdev)) {
+   priv->time_left = readw(priv->base + RWTCNT);
+   rwdt_stop(>wdev);
+   }
+   return 0;
+}
+
+static int __maybe_unused rwdt_resume(struct device *dev)
+{
+   struct rwdt_priv *priv = dev_get_drvdata(dev);
+
+   if (watchdog_active(>wdev)) {
+   rwdt_start(>wdev);
+   rwdt_write(priv, priv->time_left, RWTCNT);


Upon given it more thought, I'm a bit worried about restoring the
original time left.
In my experiments, it may take a few seconds before userspace fully resumes.
If time_left was a small value, the system may reboot before userspace has
a chance to send its next ping.
This was with NFS root, so heavily impacted by the delays introduced by the
PHY link getting up again.

So just using rwdt_stop()/rwdt_start() may be the safest option.

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.
 

[PATCH] arm64: dts: renesas: r8a77965-salvator-xs: Add SoC name to file header

[Geert Uytterhoeven]

Document clearly which SoC this DTS applies to, to distinguish from
Salvator-XS boards equipped with other SoCs.

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
index 8a45fc43348d9adc..a83a00deed9efc42 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Device Tree Source for the Salvator-X 2nd version board
+ * Device Tree Source for the Salvator-X 2nd version board with R-Car M3-N
  *
  * Copyright (C) 2017 Renesas Electronics Corp.
  */
-- 
2.7.4

Re: [git pull] pinctrl: sh-pfc: Updates for v4.17

[Linus Walleij]

On Fri, Mar 2, 2018 at 11:18 AM, Geert Uytterhoeven
 wrote:

> Hi Linus,
>
> The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:
>
>   Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/sh-pfc-for-v4.17-tag1
>
> for you to fetch changes up to a8ab4f2bd8a5298679dabe16910322625a0df247:
>
>   pinctrl: sh-pfc: r8a77965: Add support for INTC-EX IRQ pins (2018-02-28 
> 09:17:54 +0100)

Pulled into the pinctrl devel branch for v4.17!

Excellent job as usual!

And I'm amazed that Renesas manage to churn out
so many ASICs.

Yours,
Linus Walleij

Re: [PATCH v11 28/32] rcar-vin: add link notify for Gen3

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Friday, 2 March 2018 03:57:47 EET Niklas Söderlund wrote:
> Add the ability to process media device link change request. Link

s/request/requests/

> enabling is a bit complicated on Gen3, whether or not it's possible to
> enable a link depends on what other links already are enabled. On Gen3
> the 8 VINs are split into two subgroup's (VIN0-3 and VIN4-7) and from a
> routing perspective these two groups are independent of each other.
> Each subgroup's routing is controlled by the subgroup VIN master
> instance (VIN0 and VIN4).
> 
> There are a limited number of possible route setups available for each
> subgroup and the configuration of each setup is dictated by the
> hardware. On H3 for example there are 6 possible route setups for each
> subgroup to choose from.
> 
> This leads to the media device link notification code being rather large
> since it will find the best routing configuration to try and accommodate
> as many links as possible. When it's not possible to enable a new link
> due to hardware constrains the link_notifier callback will return
> -EMLINK.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 153 +
>  1 file changed, 153 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> 3ddd7d8fecd52909..c015f3c284439285 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -24,6 +24,7 @@
> 
>  #include 
>  #include 
> +#include 
> 
>  #include "rcar-vin.h"
> 
> @@ -44,6 +45,157 @@
>   */
>  #define rvin_group_id_to_master(vin) ((vin) < 4 ? 0 : 4)
> 
> +/* 
> + * Media Controller link notification
> + */
> +
> +/* group lock should be held when calling this function. */
> +static int rvin_group_entity_to_csi_id(struct rvin_group *group,
> +struct media_entity *entity)
> +{
> + struct v4l2_subdev *sd;
> + unsigned int i;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + for (i = 0; i < RVIN_CSI_MAX; i++)
> + if (group->csi[i].subdev == sd)
> + return i;
> +
> + return -ENODEV;
> +}
> +
> +static unsigned int rvin_group_get_mask(struct rvin_dev *vin,
> + enum rvin_csi_id csi_id,
> + unsigned char chan)
> +{
> + const struct rvin_group_route *route;
> + unsigned int mask = 0;
> +
> + for (route = vin->info->routes; route->mask; route++) {
> + if (route->vin == vin->id &&
> + route->csi == csi_id &&
> + route->chan == chan) {
> + vin_dbg(vin, "Adding route: vin: %d csi: %d chan: %d\n",
> + route->vin, route->csi, route->chan);
> + mask |= route->mask;
> + }
> + }
> +
> + return mask;
> +}
> +
> +/*
> + * Link setup for the links between a VIN and a CSI-2 receiver is a bit
> + * complex. The reason for this is that the register controlling routing
> + * are not present in each VIN instance. There are special VINs which

s/are/is/

> + * control routing for itself and other VINs. There are not many

s/itself/themselves/

> + * different possible links combinations that can be enabled at the same
> + * time, therefor all already enabled links which are controlled by a
> + * master VIN needs to be taken into account when making the decision

s/needs/need/

> + * if a new link can be enabled or not.
> + *
> + * 1. Find out which VIN the link the user tries to enable is connected to.
> + * 2. Lookup which master VIN controls the links for this VIN.
> + * 3. Start with a bitmask with all bits set.
> + * 4. For each previously enabled link from the master VIN bitwise AND its
> + *route mask (see documentation for mask in struct rvin_group_route)
> + *with the bitmask.
> + * 5. Bitwise AND the mask for the link the user tries to enable to the
> bitmask.
> + * 6. If the bitmask is not empty at this point the new link can be enabled
> + *while keeping all previous links enabled. Update the CHSEL value of
> the
> + *master VIN and inform the user that the link could be enabled.
> + *
> + * Please note that no link can be enabled if any VIN in the group is
> + * currently streaming.
> + */
> +static int rvin_group_link_notify(struct media_link *link, u32 flags,
> +   unsigned int notification)
> +{
> + struct rvin_group *group = container_of(link->graph_obj.mdev,
> + struct rvin_group, mdev);
> + unsigned int master_id, chan, mask_new, i;
> + unsigned int mask = ~0;
> + struct media_entity *entity;
> + struct video_device *vdev;
> + struct 

[PATCH v2 2/2] ARM: shmobile: defconfig: Disable CONFIG_EMBEDDED

[Geert Uytterhoeven]

CONFIG_EXPERT exposes too many config options that do not matter for
development.  E.g. it prohibits using the default values for the various
SH_SCI options.  However, CONFIG_EMBEDDED selects CONFIG_EXPERT, so it
cannot be disabled.

Hence disable CONFIG_EMBEDDED, and compensate for the loss of
CONFIG_DEBUG_KERNEL by enabling the latter.

Actual impact, all harmless:
  - CONFIG_NAMESPACES=y (plus a few related CONFIG_*_NS options),
  - CONFIG_SYSCTL_SYSCALL=n,
  - CONFIG_SERIAL_SH_SCI_NR_UARTS changed from 20 to 18,
  - Some HID support became enabled,
  - CONFIG_DEBUG_MEMORY_INIT=y,

Refresh the result.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Enhance patch description,
  - Rebase.
---
 arch/arm/configs/shmobile_defconfig | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index e3658ec04e837f8a..a701601fbd7618f4 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -5,8 +5,6 @@ CONFIG_IKCONFIG_PROC=y
 CONFIG_CGROUPS=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
-CONFIG_SYSCTL_SYSCALL=y
-CONFIG_EMBEDDED=y
 CONFIG_PERF_EVENTS=y
 CONFIG_SLAB=y
 CONFIG_ARCH_RENESAS=y
@@ -103,7 +101,6 @@ CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_EM=y
 CONFIG_SERIAL_SH_SCI=y
-CONFIG_SERIAL_SH_SCI_NR_UARTS=20
 CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_MUX=y
 CONFIG_I2C_DEMUX_PINCTRL=y
@@ -164,7 +161,6 @@ CONFIG_FB_SH_MOBILE_MERAM=y
 # CONFIG_BACKLIGHT_GENERIC is not set
 CONFIG_BACKLIGHT_PWM=y
 CONFIG_BACKLIGHT_AS3711=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_SOUND=y
 CONFIG_SND=y
 CONFIG_SND_SOC=y
@@ -225,4 +221,5 @@ CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 # CONFIG_ENABLE_WARN_DEPRECATED is not set
 # CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_DEBUG_KERNEL=y
 # CONFIG_ARM_UNWIND is not set
-- 
2.7.4

[PATCH v2 0/2] ARM: shmobile: defconfig: Disable CONFIG_EMBEDDED

[Geert Uytterhoeven]

Hi Simon, Magnus,

This patch series disables CONFIG_EMBEDDED in shmobile_defconfig, which
stands in the way of using more sane defaults expressed in Kconfig
logic.

The first patch does a mandatory refresh of shmobile_defconfig as a
preparatory step/
The second patch actually disables CONFIG_EMBEDDED.

Changes compared to v1:
  - Enhance patch description,
  - Rebase.

Thanks!

Geert Uytterhoeven (2):
  ARM: shmobile: defconfig: Refresh
  ARM: shmobile: defconfig: Disable CONFIG_EMBEDDED

 arch/arm/configs/shmobile_defconfig | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

-- 
2.7.4

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 1/2] ARM: shmobile: defconfig: Refresh

[Geert Uytterhoeven]

  - CONFIG_AEABI is enabled since commit 494609701e06a004 ("ARM: always
enable AEABI for ARMv6+"),
  - CONFIG_SERIAL_SH_SCI_CONSOLE is enabled since commit
c5bb576d5e21e91a ("tty: serial: sh-sci: Hide serial console config
question"),
  - CONFIG_SERIAL_SH_SCI_DMA is enabled since commit be7e251d20e6c800
("tty: serial: sh-sci: Hide DMA config question").

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm/configs/shmobile_defconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index 79b2b7c122644033..e3658ec04e837f8a 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -34,7 +34,6 @@ CONFIG_SMP=y
 CONFIG_SCHED_MC=y
 CONFIG_HAVE_ARM_ARCH_TIMER=y
 CONFIG_NR_CPUS=8
-CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
 CONFIG_CMA=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
@@ -105,8 +104,6 @@ CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_EM=y
 CONFIG_SERIAL_SH_SCI=y
 CONFIG_SERIAL_SH_SCI_NR_UARTS=20
-CONFIG_SERIAL_SH_SCI_CONSOLE=y
-CONFIG_SERIAL_SH_SCI_DMA=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_MUX=y
 CONFIG_I2C_DEMUX_PINCTRL=y
-- 
2.7.4

Re: [PATCH v7 3/4 - variant 1] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

Hi Niklas,

On Friday, 2 March 2018 02:42:18 EET Niklas Söderlund wrote:
> Hi Laurent,
> 
> Thanks for your patch,
> 
> All comments in this mail also applies to variant 2 of this patch as the
> difference between them are so small.
> 
> First I got a question about your usage of __init  thru out this driver.
> What would happen if a system is booted without a DU node and then a
> overlay is added using the old DU bindings will things work as expected,
> the old style overlay load but DU/LVDS will be in a none functioning
> state or will it explode? I don't feel this is a concern that you need
> to address as it feels a bit extreme use-case but since this is such a
> new approach (to me at least) to solve backward compatibility problems I
> just had to ask :-)

So, in a nutshell, you want to boot a system with a recent kernel (with this 
series merged) with a device tree that doesn't describe the hardware fully, 
add display support through an overlay using old-style bindings (which are 
deprecated by this series) using an overlay API that currently doesn't exist 
upstream (and thus require out-of-tree modules compiled for the new kernel), 
and expect it to work ? :-)

> I also trust you that all of the register values in the dts files are
> correct.
> 
> On 2018-03-02 00:05:38 +0200, 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 v6:
> > 
> > - Don't free data used by the applied overlay
> > 
> > Changes since v5:
> > 
> > - Use a private copy of rcar_du_of_changeset_add_property()
> > 
> > Changes since v3:
> > 
> > - Use the OF changeset API
> > - Use of_graph_get_endpoint_by_regs()
> > - Replace hardcoded constants by sizeof()
> > 
> > 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
> > 
> > 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   | 334 
> >  drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 ++
> >  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  79 +
> >  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  53 
> >  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  53 
> >  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  53 
> >  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  53 
> >  9 files changed, 653 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

[snip]

> > 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 ..067278b91caa
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > @@ -0,0 +1,334 @@
> > +// 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;
> > +};

Re: [git pull] pinctrl: sh-pfc: Updates for v4.17

[Geert Uytterhoeven]

Hi Linus,

On Fri, Mar 2, 2018 at 1:39 PM, Linus Walleij  wrote:
> On Fri, Mar 2, 2018 at 11:18 AM, Geert Uytterhoeven
>  wrote:
>> The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:
>>
>>   Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
>> tags/sh-pfc-for-v4.17-tag1
>>
>> for you to fetch changes up to a8ab4f2bd8a5298679dabe16910322625a0df247:
>>
>>   pinctrl: sh-pfc: r8a77965: Add support for INTC-EX IRQ pins (2018-02-28 
>> 09:17:54 +0100)
>
> Pulled into the pinctrl devel branch for v4.17!
>
> Excellent job as usual!

Thanks!

> And I'm amazed that Renesas manage to churn out
> so many ASICs.

You can expect support for another new SoC in take two, after review
comments have been addresses

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