RE: [PATCH v2 1/2] arm64: dts: renesas: Add Renesas R8A77990 SoC support

[Yoshihiro Shimoda]

Hi, Simon-san,

> From: Simon Horman, Sent: Tuesday, April 24, 2018 5:37 PM
> 
> On Tue, Apr 24, 2018 at 10:26:37AM +0200, Geert Uytterhoeven wrote:
> > Hi Shimoda-san,
> >
> > On Fri, Apr 20, 2018 at 2:28 PM, Yoshihiro Shimoda
> >  wrote:
> > > This patch adds basic support for the Renesas R-Car E3 (R8A77990) SoC:
> > >   - PSCI
> > >   - CPU (single)
> > >   - Cache controller
> > >   - Main clocks and controller
> > >   - Interrupt controller
> > >   - Timer
> > >   - PMU
> > >   - Reset controller
> > >   - Product register
> > >   - System controller
> > >   - UART for console
> > >
> > > Inspried by a patch by Takeshi Kihara in the BSP.
> > >
> > > Signed-off-by: Yoshihiro Shimoda 
> >
> > Thanks for you patch!
> 
> Thanks for your review.
> 
> As I've already applied this patch I'd like to ask Shimoda-san
> to send incremental patches to address the issues you raise below.

I got it. I'll send incremental patches.

Best regards,
Yoshihiro Shimoda

> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > @@ -0,0 +1,127 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * Device Tree Source for the r8a77990 SoC
> > > + *
> > > + * Copyright (C) 2018 Renesas Electronics Corp.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +/ {
> > > +   compatible = "renesas,r8a77990";
> > > +   #address-cells = <2>;
> > > +   #size-cells = <2>;
> > > +
> > > +   cpus {
> >
> > > +   L2_CA53: cache-controller@0 {
> > > +   compatible = "cache";
> > > +   reg = <0>;
> >
> > Please no unit-addresses and reg properties for cache controllers.
> >
> > > +   power-domains = < 21>;
> > > +   cache-unified;
> > > +   cache-level = <2>;
> > > +   };
> > > +   };
> >
> > > +   psci {
> > > +   compatible = "arm,psci-0.2";
> >
> > "arm,psci-1.0", "arm,psci-0.2"?
> >
> > > +   method = "smc";
> > > +   };
> > > +
> > > +   soc: soc {
> >
> > > +   rst: reset-controller@e616 {
> > > +   compatible = "renesas,r8a77990-rst";
> > > +   reg = <0 0xe616 0 0x0200>;
> > > +   };
> > > +
> > > +   sysc: system-controller@e618 {
> > > +   compatible = "renesas,r8a77990-sysc";
> > > +   reg = <0 0xe618 0 0x0400>;
> > > +   #power-domain-cells = <1>;
> > > +   };
> > > +
> > > +   scif2: serial@e6e88000 {
> > > +   compatible = "renesas,scif-r8a77990",
> > > +"renesas,rcar-gen3-scif", 
> > > "renesas,scif";
> > > +   reg = <0 0xe6e88000 0 64>;
> > > +   interrupts = ;
> > > +   clocks = < CPG_MOD 310>;
> > > +   clock-names = "fck";
> >
> > I assume you plan to add the other clocks later? That's fine for me.
> >
> > > +   power-domains = < 32>;
> > > +   resets = < 310>;
> > > +   status = "disabled";
> > > +   };
> >
> > 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] drm: rcar-du: of: Include header to define prototypes

[kbuild test robot]

Hi Kieran,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Kieran-Bingham/drm-rcar-du-of-Include-header-to-define-prototypes/20180425-062015
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

>> drivers/gpu//drm/rcar-du/rcar_du_of.c:320:13: error: redefinition of 
>> 'rcar_du_of_init'
void __init rcar_du_of_init(const struct of_device_id *of_ids)
^~~
   In file included from drivers/gpu//drm/rcar-du/rcar_du_of.c:21:0:
   drivers/gpu//drm/rcar-du/rcar_du_of.h:17:20: note: previous definition of 
'rcar_du_of_init' was here
static inline void rcar_du_of_init(const struct of_device_id *of_ids) { }
   ^~~

vim +/rcar_du_of_init +320 drivers/gpu//drm/rcar-du/rcar_du_of.c

81c0e3dd Laurent Pinchart 2018-01-10  319  
81c0e3dd Laurent Pinchart 2018-01-10 @320  void __init rcar_du_of_init(const 
struct of_device_id *of_ids)

:: The code at line 320 was first introduced by commit
:: 81c0e3dd82927064a2f56a31a0974a0d110fcdb0 drm: rcar-du: Fix legacy DT to 
create LVDS encoder nodes

:: TO: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
:: CC: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>

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


.config.gz
Description: application/gzip

Re: [PATCH 02/10] arm64: defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD

[Kuninori Morimoto]

Hi Geert

Thank for your review.

> >> > CONFIG_SND_AUDIO_GRAPH_CARD is needed to use HDMI sound with video
> >> >
> >> > Signed-off-by: Kuninori Morimoto 
> >> > Tested-by: Nguyen Viet Dung 
> >>
> >> Thanks for your patch!
> >>
> >> > --- a/arch/arm64/configs/defconfig
> >> > +++ b/arch/arm64/configs/defconfig
> >> > @@ -440,6 +440,7 @@ CONFIG_SND_SOC_SAMSUNG=y
> >> >  CONFIG_SND_SOC_RCAR=m
> >> >  CONFIG_SND_SOC_AK4613=m
> >> >  CONFIG_SND_SIMPLE_CARD=y
> >> > +CONFIG_SND_AUDIO_GRAPH_CARD=y
> >>
> >> Perhaps "m"?
> >
> > Do you suggest the same for renesas_defconfig?
> > That is, patch 2/10?
> 
> No. For {shmobile,renesas}_defconfig we make everything builtin.
> For {multi_v7,arm64}_defconfig, we usually make non-critical devices modular.

Yeah.
CONFIG_SND_AUDIO_GRAPH_CARD is similar driver to CONFIG_SND_SIMPLE_CARD
But it has =y on defconfig, thus, I used same style.
If it should be =m, then, we need +1 patch which modifes 
CONFIG_SND_SIMPLE_CARD, too.


Best regards
---
Kuninori Morimoto

[PATCH] rcar-vin: enable field toggle after a set number of lines for Gen3

[Niklas Söderlund]

The VIN Gen3 hardware don't have Line Post-Clip capabilities as VIN Gen2
hardware have. To protect against writing outside the capture window
enable field toggle after a set number of lines have been captured.

Capturing outside the allocated capture buffer where observed on R-Car
Gen3 Salvator-XS H3 from the CVBS input if the standard is
misconfigured. That is if a PAL source is connected to the system but
the adv748x standard is set to NTSC. In this case the format reported by
the adv748x is 720x480 and that is what is used for the media pipeline.
The PAL source generates frames in the format of 720x576 and the field
is not toggled until the VSYNC is detected and at that time data have
already been written outside the allocated capture buffer.

With this change the capture in the situation described above results in
garbage frames but that is far better then writing outside the capture
buffer.

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

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index ac07f99e3516a620..b41ba9a4a2b3ac90 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -124,7 +124,9 @@
 #define VNDMR2_VPS (1 << 30)
 #define VNDMR2_HPS (1 << 29)
 #define VNDMR2_FTEV(1 << 17)
+#define VNDMR2_FTEH(1 << 16)
 #define VNDMR2_VLV(n)  ((n & 0xf) << 12)
+#define VNDMR2_HLV(n)  ((n) & 0xfff)
 
 /* Video n CSI2 Interface Mode Register (Gen3) */
 #define VNCSI_IFMD_DES1(1 << 26)
@@ -612,8 +614,9 @@ void rvin_crop_scale_comp(struct rvin_dev *vin)
 
 static int rvin_setup(struct rvin_dev *vin)
 {
-   u32 vnmc, dmr, dmr2, interrupts;
+   u32 vnmc, dmr, dmr2, interrupts, lines;
bool progressive = false, output_is_yuv = false, input_is_yuv = false;
+   bool halfsize = false;
 
switch (vin->format.field) {
case V4L2_FIELD_TOP:
@@ -628,12 +631,15 @@ static int rvin_setup(struct rvin_dev *vin)
/* Use BT if video standard can be read and is 60 Hz format */
if (!vin->info->use_mc && vin->std & V4L2_STD_525_60)
vnmc = VNMC_IM_FULL | VNMC_FOC;
+   halfsize = true;
break;
case V4L2_FIELD_INTERLACED_TB:
vnmc = VNMC_IM_FULL;
+   halfsize = true;
break;
case V4L2_FIELD_INTERLACED_BT:
vnmc = VNMC_IM_FULL | VNMC_FOC;
+   halfsize = true;
break;
case V4L2_FIELD_NONE:
vnmc = VNMC_IM_ODD_EVEN;
@@ -676,11 +682,15 @@ static int rvin_setup(struct rvin_dev *vin)
break;
}
 
-   /* Enable VSYNC Field Toogle mode after one VSYNC input */
-   if (vin->info->model == RCAR_GEN3)
-   dmr2 = VNDMR2_FTEV;
-   else
+   if (vin->info->model == RCAR_GEN3) {
+   /* Enable HSYNC Field Toggle mode after height HSYNC inputs. */
+   lines = vin->format.height / (halfsize ? 2 : 1);
+   dmr2 = VNDMR2_FTEH | VNDMR2_HLV(lines);
+   vin_dbg(vin, "Field Toogle after %u lines\n", lines);
+   } else {
+   /* Enable VSYNC Field Toogle mode after one VSYNC input. */
dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
+   }
 
/* Hsync Signal Polarity Select */
if (!(vin->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
-- 
2.17.0

[PATCH] rcar-vin: add support for MEDIA_BUS_FMT_UYVY8_1X16

[Niklas Söderlund]

By setting VNMC_YCAL rcar-vin can support input video in
MEDIA_BUS_FMT_UYVY8_1X16 format.

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

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 55b745ac86a5884d..7bc2774a11232362 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -404,6 +404,7 @@ static int rvin_digital_subdevice_attach(struct rvin_dev 
*vin,
code.index++;
switch (code.code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
case MEDIA_BUS_FMT_UYVY8_2X8:
case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 4a3a195e7f59047c..ac07f99e3516a620 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -653,6 +653,10 @@ static int rvin_setup(struct rvin_dev *vin)
vnmc |= VNMC_INF_YUV16;
input_is_yuv = true;
break;
+   case MEDIA_BUS_FMT_UYVY8_1X16:
+   vnmc |= VNMC_INF_YUV16 | VNMC_YCAL;
+   input_is_yuv = true;
+   break;
case MEDIA_BUS_FMT_UYVY8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
@@ -1009,6 +1013,7 @@ static int rvin_mc_validate_format(struct rvin_dev *vin, 
struct v4l2_subdev *sd,
 
switch (fmt.format.code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_1X16:
case MEDIA_BUS_FMT_UYVY8_2X8:
case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
-- 
2.17.0

[PATCH] rcar-vin: fix null pointer dereference in rvin_group_get()

[Niklas Söderlund]

Store the group pointer before disassociating the VIN from the group.

Fixes: 3bb4c3bc85bf77a7 ("media: rcar-vin: add group allocator functions")
Reported-by: Colin Ian King 
Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 7bc2774a11232362..d3072e166a1ca24f 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -338,19 +338,21 @@ static int rvin_group_get(struct rvin_dev *vin)
 
 static void rvin_group_put(struct rvin_dev *vin)
 {
-   mutex_lock(>group->lock);
+   struct rvin_group *group = vin->group;
+
+   mutex_lock(>lock);
 
vin->group = NULL;
vin->v4l2_dev.mdev = NULL;
 
-   if (WARN_ON(vin->group->vin[vin->id] != vin))
+   if (WARN_ON(group->vin[vin->id] != vin))
goto out;
 
-   vin->group->vin[vin->id] = NULL;
+   group->vin[vin->id] = NULL;
 out:
-   mutex_unlock(>group->lock);
+   mutex_unlock(>lock);
 
-   kref_put(>group->refcount, rvin_group_release);
+   kref_put(>refcount, rvin_group_release);
 }
 
 /* 
-
-- 
2.17.0

[PATCH] rcar-vin: remove generic gen3 compatible string

[Niklas Söderlund]

The compatible string "renesas,rcar-gen3-vin" was added before the
Gen3 driver code was added but it's not possible to use. Each SoC in the
Gen3 series require SoC specific knowledge in the driver to function.
Remove it before it is added to any device tree descriptions.

Signed-off-by: Niklas Söderlund 
---
 Documentation/devicetree/bindings/media/rcar_vin.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index ba31431d4b1fbdbb..a19517e1c669eb35 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -24,7 +24,6 @@ on Gen3 platforms to a CSI-2 receiver.
- "renesas,vin-r8a77970" for the R8A77970 device
- "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
  device.
-   - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
 
When compatible with the generic version nodes must list the
SoC-specific version corresponding to the platform first
-- 
2.17.0

Re: [PATCH] media: i2c: adv748x: Fix pixel rate values

[Niklas Söderlund]

Hi Laurent,

Thanks for your patch.

On 2018-04-21 15:44:44 +0300, Laurent Pinchart wrote:
> The pixel rate, as reported by the V4L2_CID_PIXEL_RATE control, must
> include both horizontal and vertical blanking. Both the AFE and HDMI
> receiver program it incorrectly:
> 
> - The HDMI receiver goes to the trouble of removing blanking to compute
> the rate of active pixels. This is easy to fix by removing the
> computation and returning the incoming pixel clock rate directly.
> 
> - The AFE performs similar calculation, while it should simply return
> the fixed pixel rate for analog sources, mandated by the ADV748x to be
> 28.63636 MHz.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Niklas Söderlund 

This patch uncovered a calculation error in rcar-csi2 which compensated 
for the removing of the blanking in the adv748x, thanks for that! Good 
thing that it's not merged yet, will include the fix in the next version 
of the CSI-2 driver.

> ---
>  drivers/media/i2c/adv748x/adv748x-afe.c  | 11 +--
>  drivers/media/i2c/adv748x/adv748x-hdmi.c |  8 +---
>  2 files changed, 6 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c 
> b/drivers/media/i2c/adv748x/adv748x-afe.c
> index 61514bae7e5c..3e18d5ae813b 100644
> --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> @@ -321,17 +321,16 @@ static const struct v4l2_subdev_video_ops 
> adv748x_afe_video_ops = {
>  static int adv748x_afe_propagate_pixelrate(struct adv748x_afe *afe)
>  {
>   struct v4l2_subdev *tx;
> - unsigned int width, height, fps;
>  
>   tx = adv748x_get_remote_sd(>pads[ADV748X_AFE_SOURCE]);
>   if (!tx)
>   return -ENOLINK;
>  
> - width = 720;
> - height = afe->curr_norm & V4L2_STD_525_60 ? 480 : 576;
> - fps = afe->curr_norm & V4L2_STD_525_60 ? 30 : 25;
> -
> - return adv748x_csi2_set_pixelrate(tx, width * height * fps);
> + /*
> +  * The ADV748x samples analog video signals using an externally supplied
> +  * clock whose frequency is required to be 28.63636 MHz.
> +  */
> + return adv748x_csi2_set_pixelrate(tx, 28636360);
>  }
>  
>  static int adv748x_afe_enum_mbus_code(struct v4l2_subdev *sd,
> diff --git a/drivers/media/i2c/adv748x/adv748x-hdmi.c 
> b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> index 10d229a4f088..aecc2a84dfec 100644
> --- a/drivers/media/i2c/adv748x/adv748x-hdmi.c
> +++ b/drivers/media/i2c/adv748x/adv748x-hdmi.c
> @@ -402,8 +402,6 @@ static int adv748x_hdmi_propagate_pixelrate(struct 
> adv748x_hdmi *hdmi)
>  {
>   struct v4l2_subdev *tx;
>   struct v4l2_dv_timings timings;
> - struct v4l2_bt_timings *bt = 
> - unsigned int fps;
>  
>   tx = adv748x_get_remote_sd(>pads[ADV748X_HDMI_SOURCE]);
>   if (!tx)
> @@ -411,11 +409,7 @@ static int adv748x_hdmi_propagate_pixelrate(struct 
> adv748x_hdmi *hdmi)
>  
>   adv748x_hdmi_query_dv_timings(>sd, );
>  
> - fps = DIV_ROUND_CLOSEST_ULL(bt->pixelclock,
> - V4L2_DV_BT_FRAME_WIDTH(bt) *
> - V4L2_DV_BT_FRAME_HEIGHT(bt));
> -
> - return adv748x_csi2_set_pixelrate(tx, bt->width * bt->height * fps);
> + return adv748x_csi2_set_pixelrate(tx, timings.bt.pixelclock);
>  }
>  
>  static int adv748x_hdmi_enum_mbus_code(struct v4l2_subdev *sd,
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH] drm: rcar-du: of: Include header to define prototypes

[Vaishali Thakkar]

On Tue, Apr 24, 2018 at 9:09 PM, Kieran Bingham
 wrote:
> The symbol 'rcar_du_of_init' is defined by the rcar_du_of module header,
> but it is not included by the C implementation.
>
> Include the header to correctly define the function prototypes.
>
> Fixes the following warning:
>
> linux/drivers/gpu/drm/rcar-du/rcar_du_of.c:319:13:
>warning: symbol 'rcar_du_of_init' was not declared. Should it be static?
> CC  drivers/gpu/drm/rcar-du/rcar_du_of.o
>
> Fixes: 81c0e3dd8292 ("drm: rcar-du: Fix legacy DT to create LVDS encoder 
> nodes")
> Signed-off-by: Kieran Bingham 

Reviewed-by: Vaishali Thakkar 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_of.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> index 68a0b82cb17e..afef69669bb4 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_of.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> @@ -18,6 +18,7 @@
>
>  #include "rcar_du_crtc.h"
>  #include "rcar_du_drv.h"
> +#include "rcar_du_of.h"
>
>  /* 
> -
>   * Generic Overlay Handling
> --
> 2.17.0
>

Re: [PATCH] drm: rcar-du: Use NULL for table initialisation

[Vaishali Thakkar]

On Tue, Apr 24, 2018 at 9:10 PM, Kieran Bingham
 wrote:
> Replace the initialisation of the vsps table with a NULL specifier.
>
> Fixes the following warning:
>  linux/drivers/gpu/drm/rcar-du/rcar_du_kms.c:483:40:
> warning: Using plain integer as NULL pointer
>   CC  drivers/gpu/drm/rcar-du/rcar_du_kms.o

Hi Kieran,

Change looks ok to me.

> Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the same 
> VSP")
> Signed-off-by: Kieran Bingham 

Reviewed-by: Vaishali Thakkar 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index ef72dff00763..cf5b422fc753 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -480,7 +480,7 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
> struct {
> struct device_node *np;
> unsigned int crtcs_mask;
> -   } vsps[RCAR_DU_MAX_VSPS] = { { 0, }, };
> +   } vsps[RCAR_DU_MAX_VSPS] = { { NULL, }, };
> unsigned int vsps_count = 0;
> unsigned int cells;
> unsigned int i;
> --
> 2.17.0
>

[PATCH v2] arm64: dts: renesas: condor: add eMMC support

[Sergei Shtylyov]

Define the Condor board dependent part of the MMC0 (connected to eMMC chip)
device node along with the necessary voltage regulators...

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'renesas-devel-20180424-v4.17-rc2' tag of Simon
Horman's 'renesas.git' repo.

Changes in version 2:
- renamed the pin groups and their labels, alos changing their order;
- reordered this patch before the PCIe patch.

 arch/arm64/boot/dts/renesas/r8a77980-condor.dts |   43 
 1 file changed, 43 insertions(+)

Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -27,6 +27,24 @@
/* first 128MB is reserved for secure area. */
reg = <0 0x4800 0 0x7800>;
};
+
+   d3_3v: regulator-0 {
+   compatible = "regulator-fixed";
+   regulator-name = "D3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vddq_vin01: regulator-1 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDQ_VIN01";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
 };
 
  {
@@ -52,12 +70,37 @@
clock-frequency = <32768>;
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
+
+   vmmc-supply = <_3v>;
+   vqmmc-supply = <_vin01>;
+   mmc-hs200-1_8v;
+   bus-width = <8>;
+   non-removable;
+   status = "okay";
+};
+
  {
avb_pins: avb {
groups = "avb_mdio", "avb_rgmii";
function = "avb";
};
 
+   mmc_pins: mmc {
+   groups = "mmc_data8", "mmc_ctrl", "mmc_ds";
+   function = "mmc";
+   power-source = <3300>;
+   };
+
+   mmc_pins_uhs: mmc_uhs {
+   groups = "mmc_data8", "mmc_ctrl", "mmc_ds";
+   function = "mmc";
+   power-source = <1800>;
+   };
+
scif0_pins: scif0 {
groups = "scif0_data";
function = "scif0";

Re: [PATCH 0/5] arm64: dts: renesas: r8a779xx: sort nodes

[Yoshihiro Kaneko]

Hi Simon-san,

2018-04-24 17:24 GMT+09:00 Simon Horman :
> On Tue, Apr 24, 2018 at 02:31:40AM +0900, Yoshihiro Kaneko wrote:
>> Hi Simon-san,
>>
>> 2018-04-23 19:26 GMT+09:00 Simon Horman :
>> > On Thu, Apr 19, 2018 at 05:14:35AM +0900, Yoshihiro Kaneko wrote:
>> >> Sort nodes of the R-Car M3-N (r8a77965), V3M (r8a77970) and D3 (r8a77995) 
>> >> DTs.
>> >>
>> >> This is part of an ongoing effort to provide consistent node
>> >> order in the DT of Renesas SoCs to improve maintainability.
>> >>
>> >> This should not have any run-time effect.
>> >>
>> >> Based on the devel branch of Simon Horman's renesas tree.
>> >>
>> >> Yoshihiro Kaneko (5):
>> >>   arm64: dts: renesas: r8a77995: sort subnodes of the root node
>> >>   arm64: dts: renesas: r8a77995: sort subnodes of the soc node
>> >>   arm64: dts: renesas: r8a77965: sort subnodes of the root node
>> >>   arm64: dts: renesas: r8a77965: sort subnodes of the soc node
>> >>   arm64: dts: renesas: r8a77970: sort subnodes of the soc node
>> >
>> > Thanks, applied.
>> >
>> > There ware a few nodes added to r8a77970 between when you made
>> > this patchset and when I applied it. I think the r8a77970 is still
>> > sorted as desired. Could you double-check once I push a devel
>> > branch later today?
>>
>> Yes, will do.
>
> Thanks, you should now be able to check renesas-devel-20180423-v4.17-rc2

fcpvd0 should be after vspd0?
It seems good to me except the above.

Re: [PATCH 2/8] dt-bindings: display: bridge: thc63lvd1024: Add lvds map property

[Rob Herring]

On Thu, Apr 19, 2018 at 11:31:03AM +0200, Jacopo Mondi wrote:
> The THC63LVD1024 LVDS to RGB bridge supports two different input mapping
> modes, selectable by means of an external pin.
> 
> Describe the LVDS mode map through a newly defined mandatory property in
> device tree bindings.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/display/bridge/thine,thc63lvd1024.txt  | 3 
> +++
>  1 file changed, 3 insertions(+)

+1 for what Laurent said.

Reviewed-by: Rob Herring 

Re: [PATCH] net: sh-eth: fix sh_eth_start_xmit()'s return type

[Sergei Shtylyov]

Hello!

On 04/24/2018 04:17 PM, Luc Van Oostenryck wrote:

> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
> 
> Fix this by returning 'netdev_tx_t' in this driver too.
> 
> Signed-off-by: Luc Van Oostenryck 

Acked-by: Sergei Shtylyov 

[...]
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
> b/drivers/net/ethernet/renesas/sh_eth.c
> index b6b90a631..0875a169f 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -2454,7 +2454,7 @@ static void sh_eth_tx_timeout(struct net_device *ndev)
>  }
>  
>  /* Packet transmit function */
> -static int sh_eth_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> +static netdev_tx_t sh_eth_start_xmit(struct sk_buff *skb, struct net_device 
> *ndev)

   But aren't you violating 80-column limit?

[...]

MBR, Sergei

Re: [PATCH] video: fbdev: sh_mobile_meram: Drop SUPERH platform dependency

[Bartlomiej Zolnierkiewicz]

On Friday, April 20, 2018 04:20:51 PM Geert Uytterhoeven wrote:
> Since commit a521422ea4ae6128 ("ARM: shmobile: mackerel: Remove Legacy C
> board code"), the only remaining platforms using this driver are SuperH
> SH-Mobile SoCs (sh7723).  As both SUPERH and ARCH_SHMOBILE are set for
> these platforms, the SUPERH dependency can be dropped.
> 
> Signed-off-by: Geert Uytterhoeven 

Patch queued for 4.18 (w/ Laurent's & Simon's ACKs), thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 37/61] perf: simplify getting .drvdata

[Will Deacon]

On Thu, Apr 19, 2018 at 04:06:07PM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 
> ---
> 
> Build tested only. buildbot is happy. Please apply individually.

Thanks, Wolfram. I'll pick this up via the arm perf tree.

Will

Re: [PATCH 58/61] video: fbdev: omap2: omapfb: displays: simplify getting .drvdata

[Bartlomiej Zolnierkiewicz]

On Thursday, April 19, 2018 04:06:28 PM Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 

Patch queued for 4.18, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 57/61] video: fbdev: simplify getting .drvdata

[Bartlomiej Zolnierkiewicz]

On Thursday, April 19, 2018 04:06:27 PM Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 

Patch queued for 4.18, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

[PATCH 1/2] ARM: dts: r8a77470: Add EtherAVB support

[Biju Das]

Define the generic R8A77470 part of the EtherAVB device node.

Signed-off-by: Biju Das 
Reviewed-by: Chris Paterson 
---
 arch/arm/boot/dts/r8a77470.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index baec3ca..c85032f 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -190,6 +190,19 @@
dma-channels = <15>;
};
 
+   avb: ethernet@e680 {
+   compatible = "renesas,etheravb-r8a77470",
+"renesas,etheravb-rcar-gen2";
+   reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
+   interrupts = ;
+   clocks = < CPG_MOD 812>;
+   power-domains = < 32>;
+   resets = < 812>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
scif0: serial@e6e6 {
compatible = "renesas,scif-r8a77470",
 "renesas,rcar-gen2-scif", "renesas,scif";
-- 
2.7.4

[PATCH 0/2] Add EtherAVB support

[Biju Das]

This patch series add EtherAVB support to r8a77470 SoC dtsi and 
iwg23s-sbc board.

Biju Das (2):
  ARM: dts: r8a77470: Add EtherAVB support
  ARM: dts: iwg23s-sbc: Add EtherAVB support

 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 15 ++-
 arch/arm/boot/dts/r8a77470.dtsi   | 13 +
 2 files changed, 27 insertions(+), 1 deletion(-)

-- 
2.7.4

[PATCH 2/2] ARM: dts: iwg23s-sbc: Add EtherAVB support

[Biju Das]

Define the iW-RainboW-G23S board dependent part of the
EtherAVB device node.

Signed-off-by: Biju Das 
Reviewed-by: Chris Paterson 
---
* currently u-boot sets the AVB pin configuration.

 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts 
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index d21baad..e3585da 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -12,11 +12,12 @@
compatible = "iwave,g23s", "renesas,r8a77470";
 
aliases {
+   ethernet0 = 
serial1 = 
};
 
chosen {
-   bootargs = "ignore_loglevel";
+   bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
stdout-path = "serial1:115200n8";
};
 
@@ -26,6 +27,18 @@
};
 };
 
+ {
+   phy-handle = <>;
+   phy-mode = "gmii";
+   renesas,no-ether-link;
+   status = "okay";
+
+   phy3: ethernet-phy@3 {
+   reg = <3>;
+   micrel,led-mode = <1>;
+   };
+};
+
 _clk {
clock-frequency = <2000>;
 };
-- 
2.7.4

[PATCH] drm: rcar-du: Use NULL for table initialisation

[Kieran Bingham]

Replace the initialisation of the vsps table with a NULL specifier.

Fixes the following warning:
 linux/drivers/gpu/drm/rcar-du/rcar_du_kms.c:483:40:
warning: Using plain integer as NULL pointer
  CC  drivers/gpu/drm/rcar-du/rcar_du_kms.o

Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the same VSP")
Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index ef72dff00763..cf5b422fc753 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -480,7 +480,7 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
struct {
struct device_node *np;
unsigned int crtcs_mask;
-   } vsps[RCAR_DU_MAX_VSPS] = { { 0, }, };
+   } vsps[RCAR_DU_MAX_VSPS] = { { NULL, }, };
unsigned int vsps_count = 0;
unsigned int cells;
unsigned int i;
-- 
2.17.0

[PATCH] drm: rcar-du: of: Include header to define prototypes

[Kieran Bingham]

The symbol 'rcar_du_of_init' is defined by the rcar_du_of module header,
but it is not included by the C implementation.

Include the header to correctly define the function prototypes.

Fixes the following warning:

linux/drivers/gpu/drm/rcar-du/rcar_du_of.c:319:13:
   warning: symbol 'rcar_du_of_init' was not declared. Should it be static?
CC  drivers/gpu/drm/rcar-du/rcar_du_of.o

Fixes: 81c0e3dd8292 ("drm: rcar-du: Fix legacy DT to create LVDS encoder nodes")
Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_of.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c 
b/drivers/gpu/drm/rcar-du/rcar_du_of.c
index 68a0b82cb17e..afef69669bb4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_of.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
@@ -18,6 +18,7 @@
 
 #include "rcar_du_crtc.h"
 #include "rcar_du_drv.h"
+#include "rcar_du_of.h"
 
 /* 
-
  * Generic Overlay Handling
-- 
2.17.0

Re: [PATCH v2] serial: sh-sci: Support for HSCIF RX sampling point adjustment

[Geert Uytterhoeven]

Hi Ulrich,

On Wed, Apr 4, 2018 at 5:48 PM, Ulrich Hecht
 wrote:
> HSCIF has facilities that allow moving the RX sampling point by between
> -8 and 7 sampling cycles (one sampling cycles equals 1/15 of a bit
> by default) to improve the error margin in case of slightly mismatched
> bit rates between sender and receiver.
>
> This patch tries to determine if shifting the sampling point can improve
> the error margin and will enable it if so.
>
> Signed-off-by: Ulrich Hecht 
> ---
> This revision dumps the sysfs interface and works out the optimal shift
> on its own. It also moves setting of the HSSRR register back to its
> original location.

Thanks for the update!

Reviewed-by: Geert Uytterhoeven 

One suggestion for improvement below.

> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c

> @@ -2406,8 +2427,27 @@ static void sci_set_termios(struct uart_port *port, 
> struct ktermios *termios,
> serial_port_out(port, SCSCR, scr_val | s->hscif_tot);
> serial_port_out(port, SCSMR, smr_val);
> serial_port_out(port, SCBRR, brr);
> -   if (sci_getreg(port, HSSRR)->size)
> -   serial_port_out(port, HSSRR, srr | HSCIF_SRE);
> +   if (sci_getreg(port, HSSRR)->size) {
> +   unsigned int hssrr = srr | HSCIF_SRE;
> +   /* Calculate deviation from intended rate at the
> +* center of the last stop bit in sampling clocks.
> +*/
> +   int last_stop = bits * 2 - 1;
> +   int deviation = min_err * srr * last_stop / 2 / baud;

DIV_ROUND_CLOSEST()?

> +
> +   if (abs(deviation) >= 2) {
> +   /* At least two sampling clocks off at the
> +* last stop bit; we can increase the error
> +* margin by shifting the sampling point.
> +*/
> +   int shift = min(-8, max(7, deviation / 2));
> +
> +   hssrr |= (shift << HSCIF_SRHP_SHIFT) &
> +HSCIF_SRHP_MASK;
> +   hssrr |= HSCIF_SRDE;
> +   }
> +   serial_port_out(port, HSSRR, hssrr);
> +   }
>
> /* Wait one bit interval */
> udelay((100 + (baud - 1)) / baud);

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 4/4] ARM: dts: renesas: r8a7794: Add FDP1 instances

[Geert Uytterhoeven]

On Sun, Apr 22, 2018 at 12:35 PM, Laurent Pinchart
 wrote:
> The r8a7794 has one FDP1 instance.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 3/4] ARM: dts: renesas: r8a7793: Add FDP1 instances

[Geert Uytterhoeven]

On Sun, Apr 22, 2018 at 12:35 PM, Laurent Pinchart
 wrote:
> The r8a7793 has two FDP1 instances.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/4] ARM: dts: renesas: r8a7791: Add FDP1 instances

[Geert Uytterhoeven]

On Sun, Apr 22, 2018 at 12:35 PM, Laurent Pinchart
 wrote:
> The r8a7791 has two FDP1 instances.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 1/4] ARM: dts: renesas: r8a7790: Add FDP1 instances

[Geert Uytterhoeven]

On Sun, Apr 22, 2018 at 12:35 PM, Laurent Pinchart
 wrote:
> The r8a7790 has three FDP1 instances.
>
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm/boot/dts/r8a7790.dtsi
> +++ b/arch/arm/boot/dts/r8a7790.dtsi
> @@ -1606,6 +1606,33 @@
> resets = < 128>;
> };
>
> +   fdp1@fe94 {

Just wondering: should we go for "display-processor@foo"?

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] arm64: renesas_defconfig: enable R8A77980 SoC

[Geert Uytterhoeven]

On Mon, Apr 23, 2018 at 12:46 PM, Simon Horman
 wrote:
> Enable the Renesas R-Car V3H (R8A77980) SoC in the ARM64 renesas_defconfig.

"E3 (R8A77990)", also in the one-line summary.

> Signed-off-by: Simon Horman 

With the above fixed:
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] arm64: defconfig: enable R8A77990 SoC

[Geert Uytterhoeven]

On Mon, Apr 23, 2018 at 12:45 PM, Simon Horman
 wrote:
> Enable the Renesas R-Car E3 (R8A77990) SoC in the ARM64 defconfig.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] net: sh-eth: fix sh_eth_start_xmit()'s return type

[Geert Uytterhoeven]

On Tue, Apr 24, 2018 at 3:17 PM, Luc Van Oostenryck
 wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
>
> Fix this by returning 'netdev_tx_t' in this driver too.
>
> Signed-off-by: Luc Van Oostenryck 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] dt-bindings: gpio: rcar: Add r8a77470 (RZ/G1C) support

[Geert Uytterhoeven]

On Tue, Apr 24, 2018 at 10:27 AM, Biju Das  wrote:
> Renesas RZ/G1C (R8A77470) SoC GPIO blocks are identical to the R-Car Gen2
> family. Add support for its GPIO controllers.
>
> Signed-off-by: Biju Das 
> Reviewed-by: Chris Paterson 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 4/4] ARM: dts: r8a77470: Add SCIF DMA support

[Geert Uytterhoeven]

On Fri, Apr 20, 2018 at 5:27 PM, Biju Das  wrote:
> Add SCIF DMA support for R8A77470 SoC.
>
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v2 1/2] ARM: dts: r8a77470: Add SCIF support

[Geert Uytterhoeven]

On Tue, Apr 24, 2018 at 10:56 AM, Biju Das  wrote:
> Describe SCIF ports in the R8A77470 device tree.
> Also it fixes the CPG clock index ZS from 6 to 5.
>
> Fixes: 6929dfc5918049 ("ARM: dts: r8a77470: Initial SoC device tree")
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] dt-bindings: thermal: rcar-gen3-thermal: update register size in example

[Niklas Söderlund]

Hi Rob,

On 2018-04-24 09:28:41 -0500, Rob Herring wrote:
> On Tue, Apr 17, 2018 at 10:49:58PM +0200, Niklas Söderlund wrote:
> > From: Niklas Söderlund 
> > 
> > The datasheet have been expanded with more registers and the DT files
> > have been updated with the new size. This change updates the example so
> > writing new DT files can use the enchanted driver which uses the new
> > registers.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  .../devicetree/bindings/thermal/rcar-gen3-thermal.txt   | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Applied with Simon's comments addressed.

Thanks for addressing Simon's comments while applying. I had planed to 
repost the thermal patches I got comments for later today so this is one 
less thing for me to do :-)

> 
> Rob

-- 
Regards,
Niklas Söderlund

Re: [PATCH 1/4] ARM: dts: r8a77470: Add SYS-DMAC support

[Geert Uytterhoeven]

On Fri, Apr 20, 2018 at 5:27 PM, Biju Das  wrote:
> Describe SYS-DMAC0/1 in the R8A77470 device tree.
>
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH/RFC 02/11] dt-bindings: usb: add usb role switch driver

[Rob Herring]

On Wed, Apr 18, 2018 at 05:09:56PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a new documentation for a usb role switch driver.
> The usb role switch framework will parse this to get each device
> pointer by using each remote-endpoint.

Bindings describe h/w, not drivers. This doesn't look like a h/w device.

> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  .../devicetree/bindings/usb/usb-role-switch.txt| 42 
> ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb-role-switch.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-role-switch.txt 
> b/Documentation/devicetree/bindings/usb/usb-role-switch.txt
> new file mode 100644
> index 000..941d582
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-role-switch.txt
> @@ -0,0 +1,42 @@
> +USB role switch driver
> +
> +Optional nodes:
> +- If a role switch driver has OF graph ports, the usb role switch framework
> +  will parse the remote-endpoints in usb_role_switch_register(). The OF graph
> +  port number as follows:
> +0: USB 2.0 host port
> +1: USB 3.0 host port
> +2: UDC port
> +
> +For example:
> + usb-role-sw {
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + usb2_host_sw0: endpoint {
> + remote-endpoint = <_host_ep0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + usb3_host_sw0: endpoint {
> + remote-endpoint = <_host_ep0>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + udc_sw0: endpoint {
> + remote-endpoint = <_ep0>;
> + };
> + };
> + };
> + };
> -- 
> 1.9.1
> 

Re: [PATCH 2/4] ARM: dts: r8a77470: Add IRQC support

[Geert Uytterhoeven]

On Fri, Apr 20, 2018 at 5:27 PM, Biju Das  wrote:
> Describe the IRQC interrupt controller in the R8A77470 device tree.
>
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH/RFC 01/11] Documentation: of: Add device-connection-id property

[Rob Herring]

On Wed, Apr 18, 2018 at 05:09:55PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a new property for device connection framework.

What's the "device connection framework" and what does it have to do 
with DT?

> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/graph.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/graph.txt 
> b/Documentation/devicetree/bindings/graph.txt
> index 0415e2c..fca0030 100644
> --- a/Documentation/devicetree/bindings/graph.txt
> +++ b/Documentation/devicetree/bindings/graph.txt
> @@ -125,4 +125,4 @@ Optional endpoint properties
>  
>  
>  - remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
> -
> +- device-connection-id: string for device connection.

Why do we need this?

> -- 
> 1.9.1
> 

Re: [PATCH 1/2] dt-bindings: thermal: rcar-gen3-thermal: add r8a77965

[Rob Herring]

On Tue, Apr 17, 2018 at 11:00:44PM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund 
> 
> Based on previous work by Ryo Kataoka .
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  .../devicetree/bindings/thermal/rcar-gen3-thermal.txt  | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: [PATCH] dt-bindings: thermal: rcar-gen3-thermal: update register size in example

[Rob Herring]

On Tue, Apr 17, 2018 at 10:49:58PM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund 
> 
> The datasheet have been expanded with more registers and the DT files
> have been updated with the new size. This change updates the example so
> writing new DT files can use the enchanted driver which uses the new
> registers.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  .../devicetree/bindings/thermal/rcar-gen3-thermal.txt   | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Applied with Simon's comments addressed.

Rob

[PATCH] net: sh-eth: fix sh_eth_start_xmit()'s return type

[Luc Van Oostenryck]

The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, but the implementation in this
driver returns an 'int'.

Fix this by returning 'netdev_tx_t' in this driver too.

Signed-off-by: Luc Van Oostenryck 
---
 drivers/net/ethernet/renesas/sh_eth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
b/drivers/net/ethernet/renesas/sh_eth.c
index b6b90a631..0875a169f 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -2454,7 +2454,7 @@ static void sh_eth_tx_timeout(struct net_device *ndev)
 }
 
 /* Packet transmit function */
-static int sh_eth_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t sh_eth_start_xmit(struct sk_buff *skb, struct net_device 
*ndev)
 {
struct sh_eth_private *mdp = netdev_priv(ndev);
struct sh_eth_txdesc *txdesc;
-- 
2.17.0

Re: [PATCH/RFC 04/11] of: platform: add device connection parsing

[Heikki Krogerus]

Hi Yoshihiro,

On Wed, Apr 18, 2018 at 05:09:58PM +0900, Yoshihiro Shimoda wrote:
> This patch adds device connection parsing in of_platform_populate().
> 
> TODO:
>  - How to free the devcon memories?
>  - How to remove the devcon instances?
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/of/platform.c | 66 
> +++
>  include/linux/of.h|  1 +
>  2 files changed, 67 insertions(+)
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index c00d81d..41c018d 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -326,6 +327,63 @@ static const struct of_dev_auxdata *of_dev_lookup(const 
> struct of_dev_auxdata *l
>   return NULL;
>  }
>  
> +static int of_parse_device_connection(struct device_node *np)
> +{
> + struct device_node *child_ep, *parent, *remote_parent;
> + struct platform_device *pdev, *remote_pdev;
> + struct device_connection *devcon = NULL;
> + const char *id;
> +
> + if (of_node_check_flag(np, OF_DEVICE_CONNECTED)) {
> + pr_debug("%s() - skipping %pOF, already device connected\n",
> + __func__, np);
> + return 0;
> + }
> +
> + of_node_set_flag(np, OF_DEVICE_CONNECTED);
> +
> + for_each_endpoint_of_node(np, child_ep) {
> + if (of_property_read_string(child_ep, "device-connection-id",
> + ) < 0)
> + continue;
> +
> + remote_parent = of_graph_get_remote_port_parent(child_ep);
> + if (!remote_parent)
> + return 0;
> +
> + parent = of_graph_get_port_parent(child_ep);
> + if (!parent)
> + return 0;
> +
> + pdev = of_find_device_by_node(parent);
> + if (!pdev)
> + return 0;
> +
> + /*
> +  * WARN_ON in really_probe() may happen if devm_kzalloc is
> +  * used. TODO: How to free this?
> +  */
> + devcon = kzalloc(sizeof(*devcon), GFP_KERNEL);
> + if (!devcon)
> + return -ENOMEM;
> +
> + devcon->id = id;
> + remote_pdev = of_find_device_by_node(remote_parent);
> + if (!remote_pdev) {
> + kfree(devcon);
> + return 0;
> + }
> +
> + devcon->endpoint[0] = dev_name(>dev);
> + devcon->endpoint[1] = dev_name(_pdev->dev);
> +
> + /* TODO: How to remove the connection? */
> + device_connection_add(devcon);

This is wrong. You are converting a connection that is described in
graph into a "build-in" one. If the connection is already described in
graph there is no need to, actually, we _should not_, add it to the
list of "build-in" connection descriptions.

What should be done is that we parse the graph the moment
device_connection_find*() is called. And that should be done in
drivers/base/devcon.c .

> + }
> +
> + return 0;
> +}
> +
>  /**
>   * of_platform_bus_create() - Create a device for a node and its children.
>   * @bus: device node of the bus to instantiate
> @@ -477,6 +535,14 @@ int of_platform_populate(struct device_node *root,
>   }
>   of_node_set_flag(root, OF_POPULATED_BUS);
>  
> + for_each_child_of_node(root, child) {
> + rc = of_parse_device_connection(child);
> + if (rc) {
> + of_node_put(child);
> + break;
> + }
> + }
> +
>   of_node_put(root);
>   return rc;
>  }
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 4d25e4f..30aa103 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -143,6 +143,7 @@ static inline void of_node_put(struct device_node *node) 
> { }
>  #define OF_DETACHED  2 /* node has been detached from the device tree */
>  #define OF_POPULATED 3 /* device already created for the node */
>  #define OF_POPULATED_BUS 4 /* of_platform_populate recursed to children 
> of this node */
> +#define OF_DEVICE_CONNECTED  5 /* checked devcon on of_platform_populate */
>  
>  #define OF_BAD_ADDR  ((u64)-1)


Thanks,

-- 
heikki

[PATCH v2] pinctrl: sh-pfc: Add r8a77470 PFC support

[Biju Das]

Add PFC support for the R8A77470 SoC including pin groups for
some on-chip devices such as SCIF, AVB and MMC.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
V1-->V2
* Incoroporated the following review comments
* Fixed MOD_SEL to MOD_SEL0
* Created seperate pin group for AVB_COL and AVB_CRS
* Added the pin group AVB_CAPTURE and AVB_MATCH
* Added missing SCIF pin groups

 drivers/pinctrl/sh-pfc/Kconfig|5 +
 drivers/pinctrl/sh-pfc/Makefile   |1 +
 drivers/pinctrl/sh-pfc/core.c |6 +
 drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 2482 +
 drivers/pinctrl/sh-pfc/sh_pfc.h   |1 +
 5 files changed, 2495 insertions(+)
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a77470.c

diff --git a/drivers/pinctrl/sh-pfc/Kconfig b/drivers/pinctrl/sh-pfc/Kconfig
index c11b789..1d9b7e0 100644
--- a/drivers/pinctrl/sh-pfc/Kconfig
+++ b/drivers/pinctrl/sh-pfc/Kconfig
@@ -44,6 +44,11 @@ config PINCTRL_PFC_R8A7745
 depends on ARCH_R8A7745
 select PINCTRL_SH_PFC
 
+config PINCTRL_PFC_R8A77470
+def_bool y
+depends on ARCH_R8A77470
+select PINCTRL_SH_PFC
+
 config PINCTRL_PFC_R8A7778
def_bool y
depends on ARCH_R8A7778
diff --git a/drivers/pinctrl/sh-pfc/Makefile b/drivers/pinctrl/sh-pfc/Makefile
index 463775f..b486fcd 100644
--- a/drivers/pinctrl/sh-pfc/Makefile
+++ b/drivers/pinctrl/sh-pfc/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_PINCTRL_PFC_R8A73A4)   += pfc-r8a73a4.o
 obj-$(CONFIG_PINCTRL_PFC_R8A7740)  += pfc-r8a7740.o
 obj-$(CONFIG_PINCTRL_PFC_R8A7743)  += pfc-r8a7791.o
 obj-$(CONFIG_PINCTRL_PFC_R8A7745)  += pfc-r8a7794.o
+obj-$(CONFIG_PINCTRL_PFC_R8A77470) += pfc-r8a77470.o
 obj-$(CONFIG_PINCTRL_PFC_R8A7778)  += pfc-r8a7778.o
 obj-$(CONFIG_PINCTRL_PFC_R8A7779)  += pfc-r8a7779.o
 obj-$(CONFIG_PINCTRL_PFC_R8A7790)  += pfc-r8a7790.o
diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index 74861b7..b069fe3 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -503,6 +503,12 @@ static const struct of_device_id sh_pfc_of_table[] = {
.data = _pinmux_info,
},
 #endif
+#ifdef CONFIG_PINCTRL_PFC_R8A77470
+   {
+   .compatible = "renesas,pfc-r8a77470",
+   .data = _pinmux_info,
+   },
+#endif
 #ifdef CONFIG_PINCTRL_PFC_R8A7778
{
.compatible = "renesas,pfc-r8a7778",
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77470.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
new file mode 100644
index 000..5742e85
--- /dev/null
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77470.c
@@ -0,0 +1,2482 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * R8A77470 processor support - PFC hardware block.
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+
+#include 
+
+#include "sh_pfc.h"
+
+#define CPU_ALL_PORT(fn, sfx)  \
+   PORT_GP_23(0, fn, sfx), \
+   PORT_GP_23(1, fn, sfx), \
+   PORT_GP_32(2, fn, sfx), \
+   PORT_GP_17(3, fn, sfx), \
+   PORT_GP_1(3, 27, fn, sfx),  \
+   PORT_GP_1(3, 28, fn, sfx),  \
+   PORT_GP_1(3, 29, fn, sfx),  \
+   PORT_GP_26(4, fn, sfx), \
+   PORT_GP_32(5, fn, sfx)
+
+enum {
+   PINMUX_RESERVED = 0,
+
+   PINMUX_DATA_BEGIN,
+   GP_ALL(DATA),
+   PINMUX_DATA_END,
+
+   PINMUX_FUNCTION_BEGIN,
+   GP_ALL(FN),
+
+   /* GPSR0 */
+   FN_USB0_PWEN, FN_USB0_OVC, FN_USB1_PWEN, FN_USB1_OVC, FN_CLKOUT,
+   FN_IP0_3_0, FN_IP0_7_4, FN_IP0_11_8, FN_IP0_15_12, FN_IP0_19_16,
+   FN_IP0_23_20, FN_IP0_27_24, FN_IP0_31_28, FN_MMC0_CLK_SDHI1_CLK,
+   FN_MMC0_CMD_SDHI1_CMD, FN_MMC0_D0_SDHI1_D0, FN_MMC0_D1_SDHI1_D1,
+   FN_MMC0_D2_SDHI1_D2, FN_MMC0_D3_SDHI1_D3, FN_IP1_3_0,
+   FN_IP1_7_4, FN_MMC0_D6, FN_MMC0_D7,
+
+   /* GPSR1 */
+   FN_IP1_11_8, FN_IP1_15_12, FN_IP1_19_16, FN_IP1_23_20, FN_IP1_27_24,
+   FN_IP1_31_28, FN_IP2_3_0, FN_IP2_7_4, FN_IP2_11_8, FN_IP2_15_12,
+   FN_IP2_19_16, FN_IP2_23_20, FN_IP2_27_24, FN_IP2_31_28, FN_IP3_3_0,
+   FN_IP3_7_4, FN_IP3_11_8, FN_IP3_15_12, FN_IP3_19_16, FN_IP3_23_20,
+   FN_IP3_27_24, FN_IP3_31_28, FN_IP4_3_0,
+
+   /* GPSR2 */
+   FN_IP4_7_4, FN_IP4_11_8, FN_IP4_15_12, FN_IP4_19_16, FN_IP4_23_20,
+   FN_IP4_27_24, FN_IP4_31_28, FN_IP5_3_0, FN_IP5_7_4, FN_IP5_11_8,
+   FN_IP5_15_12, FN_IP5_19_16, FN_IP5_23_20, FN_IP5_27_24, FN_IP5_31_28,
+   FN_IP6_3_0, FN_IP6_7_4, FN_IP6_11_8, FN_IP6_15_12, FN_IP6_19_16,
+   FN_IP6_23_20, FN_IP6_27_24, FN_IP6_31_28, FN_IP7_3_0, FN_IP7_7_4,
+   FN_IP7_11_8, 

Re: [PATCH v2] pinctrl: sh-pfc: r8a77980: add pin I/O voltage control support

[Geert Uytterhoeven]

On Thu, Apr 19, 2018 at 8:27 PM, Sergei Shtylyov
 wrote:
> Add the pin I/O voltage level control support to the R8A77980 PFC driver.
>
> Loosely based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 
> Reviewed-by: Geert Uytterhoeven 
>
> ---
> The patch is against the 'sh-pfc' branch of Geert's 'renesas-drivers.git' 
> repo.
>
> Changes in version 2:
> - added IOCTRL33 to *enum* ioctrl_regs and its address to 
> pinmux_ioctrl_regs[];
> - fixed the subject;
> - added Geert's tag.

Thanks, queued in sh-pfc-for-v4.18 (with the first character capitalized,
as usual).

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 v3] pinctrl: sh-pfc: r8a77970: fix pin I/O voltage control support

[Geert Uytterhoeven]

On Thu, Apr 19, 2018 at 8:52 PM, Sergei Shtylyov
 wrote:
> I've included the pin I/O voltage control into the R8A77970 PFC driver but
> it was incomplete because:
> - SH_PFC_PIN_CFG_IO_VOLTAGE pin flags weren't set properly;
> - sh_pfc_soc_info::ioctrl_regs wasn't set at all...
>
> Fixes: b92ac66a1819 ("pinctrl: sh-pfc: Add R8A77970 PFC support")
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Geert Uytterhoeven 
i.e. queued in sh-pfc-for-v4.18.

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 RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Lee Jones]

On Tue, 24 Apr 2018, Geert Uytterhoeven wrote:

> On Tue, Apr 24, 2018 at 10:41 AM, Simon Horman  wrote:
> > On Mon, Apr 16, 2018 at 10:12:57AM +0100, Lee Jones wrote:
> >> On Wed, 11 Apr 2018, Simon Horman wrote:
> >> > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> >> > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> >> > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> >> > > ("gpio: correct docs about return value of gpiod_get_direction"). Now,
> >> > > fix this user (until a better, system-wide solution is in place).
> >> > >
> >> > > Signed-off-by: Wolfram Sang 
> >> > > Acked-by: Daniel Thompson 
> >> >
> >> > Reviewed-by: Simon Horman 
> >>
> >> Thanks for the Reviewed-by Simon.  I have applied it to the original mail.
> >>
> >> Do you know why you mail wasn't sent attached to the original thread?
> >> For some reason I received this mail on it's own i.e. not in reply
> >> to the original.
> >
> > No, not off hand. Perhaps I responded to the email in some unusual way
> > but by now I don't recall. In any case I'll try to be more careful
> > in future.
> 
> I see Lee is using gmail for sending, so I assume also for receiving.

Well I'm using their servers, but my set-up is IMAP/Mutt.

> While I did receive Simon's reply in-thread, lately I had issues with gmail
> not always doing so, and sometimes failing to do deduplication when receiving
> email through multiple paths (mailing lists and/or directly).

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 02/10] arm64: defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD

[Geert Uytterhoeven]

Hi Simon,

On Tue, Apr 24, 2018 at 11:36 AM, Simon Horman  wrote:
> On Mon, Apr 23, 2018 at 10:01:51AM +0200, Geert Uytterhoeven wrote:
>> On Mon, Apr 23, 2018 at 3:39 AM, Kuninori Morimoto
>>  wrote:
>> > From: Kuninori Morimoto 
>> >
>> > CONFIG_SND_AUDIO_GRAPH_CARD is needed to use HDMI sound with video
>> >
>> > Signed-off-by: Kuninori Morimoto 
>> > Tested-by: Nguyen Viet Dung 
>>
>> Thanks for your patch!
>>
>> > --- a/arch/arm64/configs/defconfig
>> > +++ b/arch/arm64/configs/defconfig
>> > @@ -440,6 +440,7 @@ CONFIG_SND_SOC_SAMSUNG=y
>> >  CONFIG_SND_SOC_RCAR=m
>> >  CONFIG_SND_SOC_AK4613=m
>> >  CONFIG_SND_SIMPLE_CARD=y
>> > +CONFIG_SND_AUDIO_GRAPH_CARD=y
>>
>> Perhaps "m"?
>
> Do you suggest the same for renesas_defconfig?
> That is, patch 2/10?

No. For {shmobile,renesas}_defconfig we make everything builtin.
For {multi_v7,arm64}_defconfig, we usually make non-critical devices modular.

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/RFC 7/8] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol

[Geert Uytterhoeven]

(Reducing/enhancing CC list)

On Fri, Apr 20, 2018 at 3:28 PM, Geert Uytterhoeven
 wrote:
> All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS
> platform dependencies.  Hence finish the conversion from ARCH_SHMOBILE
> to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit
> 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS").
>
> Signed-off-by: Geert Uytterhoeven 
> ---
> This depends on the previous patches in this series, hence the RFC.
>
> JFTR, after this, the following symbols for drivers supporting only
> Renesas SuperH "SH-Mobile" SoCs can no longer be selected:
>   - CONFIG_KEYBOARD_SH_KEYSC,
>   - CONFIG_VIDEO_SH_VOU,
>   - CONFIG_VIDEO_SH_MOBILE_CEU,
>   - CONFIG_DRM_SHMOBILE[*],
>   - CONFIG_FB_SH_MOBILE_MERAM.
> (changes for a shmobile_defconfig .config)

Apparently CONFIG_VIDEO_SH_MOBILE_CEU was set in the old
armadillo800eva_defconfig, and used by the old board code.

While DT bindings do exist [1], some DT support has been added to the
driver [2], and this even ended up as the example in [3], this was never
enabled in the corresponding board DTS.

Nevertheless, I understand that soc_camera-based driver is obsolete, and
has been replaced by [4], but bindings for r8a7740 are lacking [5].

[1] Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
[2] drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
[3] Documentation/devicetree/bindings/media/video-interfaces.txt
[4] drivers/media/platform/renesas-ceu.c
[5] Documentation/devicetree/bindings/media/renesas,ceu.txt

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] arm64: dts: renesas: r8a7795-es1: Enable IPMMU devices

[Simon Horman]

On Tue, Apr 24, 2018 at 11:32:08AM +0200, Geert Uytterhoeven wrote:
> On Tue, Apr 24, 2018 at 11:26 AM, Simon Horman
>  wrote:
> > Remove 'status = "disabled"' to make sure all IPMMU devices are enabled
> > in DT on the r8a7795 ES1.0 Soc.
> >
> > This is a follow up for a patch by Magnus Damm for the
> > the r8a7795 ES2.0 and other R-Car Gen 3 SoCs.
> >
> > Signed-off-by: Simon Horman 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH 00/10] arm64: renesas: enable HDMI sound on Salvator

[Simon Horman]

On Mon, Apr 23, 2018 at 01:35:59AM +, Kuninori Morimoto wrote:
> 
> Hi Simon
> 
> These patches enable HDMI sound on R-Car Salvator boards on H3/M3.
> Basically, HDMI sound support on "driver side" was already supported,
> but I didn't posted "DT side" patches, because it needed to confirm
> business relationship. Now it be cleared.
> 
> But, unfortunately, DT "full_name" behavior was exchanged from v4.15.
> And driver assumeed that DT is using numerical suffixes, but this idea
> was rejected. Because of these reasons, it needs below patch.
> Simon, can you consider these patches on below ?
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git :: for-4.18
> 
> 9ff7386656f5b7d9524ab7bdf69d508d14800d42
> ("ASoC: rsnd: don't assume node full path name for HDMI probing")
> 
> 1)   : only for renesas, not for upstream
> 2)   : for defconfig
> 3) - 10) : based on 9ff7386656f5b7d9524ab7bdf69d508d14800d42
> 
> Kuninori Morimoto (10):
>1) arm64: renesas_defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD
>2) arm64: defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD

Geert has some comments regarding patch 1 which may also apply to patch 2.
Lets sort that out one way or another.

>3) arm64: dts: renesas: r8a7795: add HDMI sound support
>4) arm64: dts: renesas: r8a7796: add HDMI sound support
>5) arm64: dts: renesas: salvator-common: use audio-graph-card for Sound
>6) arm64: dts: renesas: r8a7795-es1-salvator-x: enable HDMI sound
>7) arm64: dts: renesas: r8a7795-salvator-xs: enable HDMI sound
>8) arm64: dts: renesas: r8a7796-salvator-xs: enable HDMI sound
>9) arm64: dts: renesas: r8a7795-salvator-x: enable HDMI sound
>   10) arm64: dts: renesas: r8a7796-salvator-x: enable HDMI sound

Patches 3 - 10 applied, thanks!

> 
>  .../boot/dts/renesas/r8a7795-es1-salvator-x.dts| 46 
> ++
>  arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 46 
> ++
>  .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 46 
> ++
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  8 
>  arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 28 +
>  .../arm64/boot/dts/renesas/r8a7796-salvator-xs.dts | 28 +
>  arch/arm64/boot/dts/renesas/r8a7796.dtsi   |  4 ++
>  arch/arm64/boot/dts/renesas/salvator-common.dtsi   | 38 ++
>  arch/arm64/configs/defconfig   |  1 +
>  arch/arm64/configs/renesas_defconfig   |  1 +
>  10 files changed, 230 insertions(+), 16 deletions(-)
> 
> -- 
> 1.9.1
> 

Re: [PATCH 02/10] arm64: defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD

[Simon Horman]

On Mon, Apr 23, 2018 at 10:01:51AM +0200, Geert Uytterhoeven wrote:
> Hi Morimoto-san,
> 
> On Mon, Apr 23, 2018 at 3:39 AM, Kuninori Morimoto
>  wrote:
> >
> > From: Kuninori Morimoto 
> >
> > CONFIG_SND_AUDIO_GRAPH_CARD is needed to use HDMI sound with video
> >
> > Signed-off-by: Kuninori Morimoto 
> > Tested-by: Nguyen Viet Dung 
> 
> Thanks for your patch!
> 
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -440,6 +440,7 @@ CONFIG_SND_SOC_SAMSUNG=y
> >  CONFIG_SND_SOC_RCAR=m
> >  CONFIG_SND_SOC_AK4613=m
> >  CONFIG_SND_SIMPLE_CARD=y
> > +CONFIG_SND_AUDIO_GRAPH_CARD=y
> 
> Perhaps "m"?

Do you suggest the same for renesas_defconfig?
That is, patch 2/10?

Re: [PATCH 02/10] arm64: defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD

[Simon Horman]

On Tue, Apr 24, 2018 at 11:31:14AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, Apr 24, 2018 at 11:27 AM, Simon Horman  wrote:
> > On Mon, Apr 23, 2018 at 10:01:51AM +0200, Geert Uytterhoeven wrote:
> >> On Mon, Apr 23, 2018 at 3:39 AM, Kuninori Morimoto
> >>  wrote:
> >> >
> >> > From: Kuninori Morimoto 
> >> >
> >> > CONFIG_SND_AUDIO_GRAPH_CARD is needed to use HDMI sound with video
> >> >
> >> > Signed-off-by: Kuninori Morimoto 
> >> > Tested-by: Nguyen Viet Dung 
> >>
> >> Thanks for your patch!
> >>
> >> > --- a/arch/arm64/configs/defconfig
> >> > +++ b/arch/arm64/configs/defconfig
> >> > @@ -440,6 +440,7 @@ CONFIG_SND_SOC_SAMSUNG=y
> >> >  CONFIG_SND_SOC_RCAR=m
> >> >  CONFIG_SND_SOC_AK4613=m
> >> >  CONFIG_SND_SIMPLE_CARD=y
> >> > +CONFIG_SND_AUDIO_GRAPH_CARD=y
> >>
> >> Perhaps "m"?
> >
> > Hi Geert,
> >
> > do you plan to review the rest of the series?
> 
> No, I'm too scared of audio.

No problem, just wondering if I should wait. I won't.

Re: [PATCH v2 1/2] ARM: dts: r8a77470: Add SCIF support

[Simon Horman]

On Tue, Apr 24, 2018 at 09:56:03AM +0100, Biju Das wrote:
> Describe SCIF ports in the R8A77470 device tree.
> Also it fixes the CPG clock index ZS from 6 to 5.
> 
> Fixes: 6929dfc5918049 ("ARM: dts: r8a77470: Initial SoC device tree")
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Thanks, applied.

Re: [PATCH v2 2/2] ARM: dts: r8a77470: Add SCIF DMA support

[Simon Horman]

On Tue, Apr 24, 2018 at 09:56:04AM +0100, Biju Das wrote:
> Add SCIF DMA support for R8A77470 SoC.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Thanks, applied.

Re: [PATCH v2 2/2] arm64: dts: renesas: Add Renesas Ebisu board support

[Simon Horman]

On Tue, Apr 24, 2018 at 10:31:57AM +0200, Geert Uytterhoeven wrote:
> On Fri, Apr 20, 2018 at 2:28 PM, Yoshihiro Shimoda
>  wrote:
> > From: Takeshi Kihara 
> >
> > Basic support for the Renesas Ebisu board based on R-Car E3:
> >   - Memory,
> >   - Main crystal,
> >   - Serial console,
> >
> > Signed-off-by: Takeshi Kihara 
> > [shimoda: rebase and add SPDX-License-Identifier]
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, tag added.

Re: [PATCH] arm64: dts: renesas: r8a7795-es1: Enable IPMMU devices

[Geert Uytterhoeven]

On Tue, Apr 24, 2018 at 11:26 AM, Simon Horman
 wrote:
> Remove 'status = "disabled"' to make sure all IPMMU devices are enabled
> in DT on the r8a7795 ES1.0 Soc.
>
> This is a follow up for a patch by Magnus Damm for the
> the r8a7795 ES2.0 and other R-Car Gen 3 SoCs.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 02/10] arm64: defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD

[Geert Uytterhoeven]

Hi Simon,

On Tue, Apr 24, 2018 at 11:27 AM, Simon Horman  wrote:
> On Mon, Apr 23, 2018 at 10:01:51AM +0200, Geert Uytterhoeven wrote:
>> On Mon, Apr 23, 2018 at 3:39 AM, Kuninori Morimoto
>>  wrote:
>> >
>> > From: Kuninori Morimoto 
>> >
>> > CONFIG_SND_AUDIO_GRAPH_CARD is needed to use HDMI sound with video
>> >
>> > Signed-off-by: Kuninori Morimoto 
>> > Tested-by: Nguyen Viet Dung 
>>
>> Thanks for your patch!
>>
>> > --- a/arch/arm64/configs/defconfig
>> > +++ b/arch/arm64/configs/defconfig
>> > @@ -440,6 +440,7 @@ CONFIG_SND_SOC_SAMSUNG=y
>> >  CONFIG_SND_SOC_RCAR=m
>> >  CONFIG_SND_SOC_AK4613=m
>> >  CONFIG_SND_SIMPLE_CARD=y
>> > +CONFIG_SND_AUDIO_GRAPH_CARD=y
>>
>> Perhaps "m"?
>
> Hi Geert,
>
> do you plan to review the rest of the series?

No, I'm too scared of audio.

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] dt-bindings: gpio: rcar: Add r8a77470 (RZ/G1C) support

[Simon Horman]

On Tue, Apr 24, 2018 at 09:27:05AM +0100, Biju Das wrote:
> Renesas RZ/G1C (R8A77470) SoC GPIO blocks are identical to the R-Car Gen2
> family. Add support for its GPIO controllers.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Chris Paterson 

Reviewed-by: Simon Horman 

Re: [PATCH 02/10] arm64: defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD

[Simon Horman]

On Mon, Apr 23, 2018 at 10:01:51AM +0200, Geert Uytterhoeven wrote:
> Hi Morimoto-san,
> 
> On Mon, Apr 23, 2018 at 3:39 AM, Kuninori Morimoto
>  wrote:
> >
> > From: Kuninori Morimoto 
> >
> > CONFIG_SND_AUDIO_GRAPH_CARD is needed to use HDMI sound with video
> >
> > Signed-off-by: Kuninori Morimoto 
> > Tested-by: Nguyen Viet Dung 
> 
> Thanks for your patch!
> 
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -440,6 +440,7 @@ CONFIG_SND_SOC_SAMSUNG=y
> >  CONFIG_SND_SOC_RCAR=m
> >  CONFIG_SND_SOC_AK4613=m
> >  CONFIG_SND_SIMPLE_CARD=y
> > +CONFIG_SND_AUDIO_GRAPH_CARD=y
> 
> Perhaps "m"?

Hi Geert,

do you plan to review the rest of the series?

Re: [PATCH 00/04] arm64: dts: renesas: Enable IPMMU devices

[Simon Horman]

On Mon, Apr 23, 2018 at 09:56:06AM +0200, Geert Uytterhoeven wrote:
> Hi Magnus,
> 
> On Sun, Apr 22, 2018 at 12:08 PM, Magnus Damm  wrote:
> > arm64: dts: renesas: Enable IPMMU devices
> >
> > [PATCH 01/04] arm64: dts: renesas: r8a7795: Enable IPMMU devices
> > [PATCH 02/04] arm64: dts: renesas: r8a7796: Enable IPMMU devices
> > [PATCH 03/04] arm64: dts: renesas: r8a77970: Enable IPMMU devices
> > [PATCH 04/04] arm64: dts: renesas: r8a77995: Enable IPMMU devices
> >
> > Following the policy of using DT to describe the hardware and not software
> > support state, ...
> 
> Good policy! So "[PATCH 0/2] arm64: dts: renesas: r8a77970: Add SMP Support"
> can be applied, too?
> 
> > ... this series makes sure all IPMMU devices are enabled in DT
> > for SoCs such as r8a7795, r8a7796, r8a77970 and r8a77995.
> 
> BTW, do you plan to fix arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi, too?

I took the liberty of posting a patch to do that.

[PATCH] arm64: dts: renesas: r8a7795-es1: Enable IPMMU devices

[Simon Horman]

Remove 'status = "disabled"' to make sure all IPMMU devices are enabled
in DT on the r8a7795 ES1.0 Soc.

This is a follow up for a patch by Magnus Damm for the
the r8a7795 ES2.0 and other R-Car Gen 3 SoCs.

Signed-off-by: Simon Horman 
---
Based on renesas-devel-20180423-v4.17-rc2
---
 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
index f9acd125d687..0177f5e60e5a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
@@ -39,7 +39,6 @@
reg = <0 0xe773 0 0x1000>;
renesas,ipmmu-main = <_mm 8>;
#iommu-cells = <1>;
-   status = "disabled";
};
 
/delete-node/ usb-phy@ee0e0200;
-- 
2.11.0

Re: [PATCH 2/2] arm64: dts: renesas: condor: add eMMC support

[Simon Horman]

On Fri, Apr 20, 2018 at 09:51:06PM +0300, Sergei Shtylyov wrote:
> On 04/20/2018 01:03 PM, Simon Horman wrote:
> 
> >> Define the Condor board dependent part of the MMC0 (connected to eMMC chip)
> >> device node along with the necessary voltage regulators...
> >>
> >> Signed-off-by: Sergei Shtylyov 
> >>
> >> ---
> >>  arch/arm64/boot/dts/renesas/r8a77980-condor.dts |   43 
> >> 
> >>  1 file changed, 43 insertions(+)
> >>
> >> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> ===
> >> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> @@ -27,6 +27,24 @@
> >>/* first 128MB is reserved for secure area. */
> >>reg = <0 0x4800 0 0x7800>;
> >>};
> >> +
> >> +  d3_3v: regulator-0 {
> > 
> > Please use reg_3p3v: regulator1 for consistency with salvator-common.dtsi
> 
>Hm, not sure why I have to copy what I consider a bad example... the SoCs 
> are
> not pin compatible anyway. 
> 
> >> +  compatible = "regulator-fixed";
> >> +  regulator-name = "D3.3V";
> > 
> > And "fixed-3.3V"
> 
>Ugh. That's pretty poor name I think. My names do correspond to the 
> schematics
> and these only muddle things up, I think...
> 
> [...]
> >> @@ -70,6 +101,18 @@
> >>function = "avb";
> >>};
> >>  
> >> +  mmc_1_8v_pins: mmc_1_8v {
> >> +  groups = "mmc_data8", "mmc_ctrl", "mmc_ds";
> >> +  function = "mmc";
> >> +  power-source = <1800>;
> >> +  };
> >> +
> >> +  mmc_3_3v_pins: mmc_3_3v {
> >> +  groups = "mmc_data8", "mmc_ctrl", "mmc_ds";
> >> +  function = "mmc";
> >> +  power-source = <3300>;
> >> +  };
> > 
> > Again please make this more consistent with salvator-common.dtsi.
> 
>Ah, you mean the _uhs label name postfix? OK...

Thanks, could you send a v2?

Re: [PATCH 1/2] arm64: dts: renesas: r8a77980: add MMC support

[Simon Horman]

On Fri, Apr 20, 2018 at 10:06:03PM +0300, Sergei Shtylyov wrote:
> On 04/20/2018 12:58 PM, Simon Horman wrote:
> 
> >> Define the generic R8A77980 part of the MMC0 (SDHI2) device node.
> >>
> >> Signed-off-by: Sergei Shtylyov 
> >>
> >> ---
> >>  arch/arm64/boot/dts/renesas/r8a77980.dtsi |   12 
> >>  1 file changed, 12 insertions(+)
> >>
> >> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> >> ===
> >> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> >> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> >> @@ -371,6 +371,18 @@
> >>dma-channels = <16>;
> >>};
> >>  
> >> +  mmc0: mmc@ee14 {
> > 
> > Please use sdhi2: sd@ee14 for consistency with other SoCs
> > (I refereed to the r8a7795).
> 
>Mmm... note that this controller has MMC signals (8 data bits, DS, no 
> CD/WP),
> see manual v0.55. I think it's more correct to call it MMC0 (trken from the
> manual as well)...

Ok, point taken. I've applied this. But in general I would like the
dtsi files to be consistent where it makes sense.

Re: [PATCH 0/3] Add R8A77980/Condor PFC support

[Simon Horman]

On Fri, Apr 20, 2018 at 08:33:20PM +0300, Sergei Shtylyov wrote:
> On 03/09/2018 03:04 PM, Sergei Shtylyov wrote:
> 
> > Here's the set of 3 patches against Simon Horman's 'renesas.git' repo's
> > 'renesas-devel-20180308-v4.16-rc4' tag.  We're adding the R8A77980 PFC node
> > and then describing the pins for SCIF0 and EtherAVB devices declared 
> > earlier.
> > These patches depend on the R8A77980 PFC support in order to work properly.
> 
>   ... and their time has finally come! Please merge.
> 
> > [1/3] arm64: dts: renesas: r8a77980: add PFC support
> > [2/3] arm64: dts: renesas: condor: add SCIF0 pins
> > [3/3] arm64: dts: renesas: condor: add EtherAVB pins

Thanks, applied.

Re: [PATCH] arm64: dts: renesas: v3msk: add EtherAVB pins

[Simon Horman]

On Fri, Apr 20, 2018 at 02:28:51PM +0300, Sergei Shtylyov wrote:
> On 03/14/2018 11:30 PM, Sergei Shtylyov wrote:
> 
> > Add the (previously omitted) EtherAVB pin data to the V3M Starter Kit
> > board's device tree.
> > 
> > Signed-off-by: Sergei Shtylyov 
> > 
> > ---
> > The patch is against the 'renesas-devel-20180314-v4.16-rc5' tag of Simon's
> > 'renesas.git repo. It depends on the R8A77970 PFC driver patch adding 
> > EtherAVB
> > pin groups (posted yesterday) in order to work properly...
> 
>The dependency has been now met, please merge this patch.

Thanks, applied.

Re: [PATCH v2] arm64: dts: renesas: eagle: add EtherAVB pins

[Simon Horman]

On Fri, Apr 20, 2018 at 02:25:46PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 03/14/2018 10:58 PM, Sergei Shtylyov wrote:
> 
> > Add the (previously omitted) EtherAVB pin data to the Eagle board's
> > device tree.
> > 
> > Signed-off-by: Sergei Shtylyov 
> > 
> > ---
> > The patch is against the 'renesas-devel-20180314-v4.16-rc5' tag of Simon's
> > 'renesas.git repo. It depends on the R8A77970 PFC driver patch adding 
> > EtherAVB
> > pin groups (posted yesterday) in order to work properly...
> 
>The dependency has been now met, please merge this patch.

Thanks, applied.

Re: [PATCH] arm64: dts: r8a77965: Add R-Car Gen3 thermal support

[Simon Horman]

On Wed, Apr 18, 2018 at 03:55:34PM +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Tue, Apr 17, 2018 at 11:03 PM, Niklas Söderlund
>  wrote:
> > From: Niklas Söderlund 
> >
> > Based on previous work by Ryo Kataoka .
> >
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 59 +++
> >  1 file changed, 59 insertions(+)
> >
> > Hi Simon,
> >
> > This patch depends on '[PATCH 0/2] thermal: rcar_gen3_thermal: add
> > r8a77965 support'. So it's probably best you hold back applying it to
> 
> Does it? Just on the (trivial) addition of a new compatible value, right?
> 
> > such time it's dependency are accepted. I post it in any case to get
> > review comments and keep it ready for future integration in
> > renesas-drivers branches.
> 
> So I don't think the above is a blocker, but...
> 
> > It also uses numerical values for the power-doamains propery as the
> > defines where not yet available for me. This shall of course be updated
> > before they are accepted.
> 
> They're in v4.17-rc1, so you can update the patch now?

Hi Niklas,

could you find some time to address Geert's feedback.
It sounds like we could apply a v2 without further delay.

Re: [PATCH 0/3] arm64: dts: renesas: Rename EtherAVB "mdc" pin group to "mdio"

[Simon Horman]

On Wed, Apr 18, 2018 at 03:47:33PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Fri, Mar 16, 2018 at 9:39 AM, Simon Horman  wrote:
> > On Tue, Mar 13, 2018 at 08:23:05PM +0100, Geert Uytterhoeven wrote:
> >> On Tue, Mar 13, 2018 at 7:49 PM, Simon Horman  wrote:
> >> > On Mon, Mar 12, 2018 at 04:11:57PM +0100, Geert Uytterhoeven wrote:
> >> >> On Renesas R-Car Gen2 SoCs, the pin group for the MDIO bus is named
> >> >> "mdio".
> >> >>
> >> >> When initial support was added for R-Car H3, the MDIO pin was forgotten,
> >> >> and the MDC pin got its own group named "mdc".  During the addition of
> >> >> support for R-Car M3-W, this mistake was noticed.  But as R-Car H3 and
> >> >> M3-W are pin compatible, and can be mounted on the same boards, the
> >> >> decision was made to just add the MDIO pin to the existing "mdc" group.
> >> >> Later this was extended to R-Car H3 ES2.0, and M3-N, because of pin
> >> >> compatibility, and to R-Car D3, in the name of consistency among R-Car
> >> >> Gen3 SoCs.
> >> >>
> >> >> However, this decision keeps on being questioned when adding new SoC
> >> >> support.  Hence bite the bullet and admit our mistake, and rename the
> >> >> pin group from "mdc" to "mdio", like on R-Car Gen2 SoCs.
> >> >>
> >> >> This series is the DTS part, and depends on the series '[PATCH 0/6]
> >> >> pinctrl: sh-pfc: rcar-gen3: Rename EtherAVB "mdc" pin group to "mdio"'.
> >> >
> >> > could you comment on the forwards/backwards compatibility considerations
> >> > of this series?
> >>
> >> Old and new kernels work with old DT (tested on Salvator-X(S).
> >> New DT requires a new kernel, hence the dependency of the DTS part on the
> >> driver part.
> >
> > Thanks, that is fine by me.
> >
> > I have marked these patches as deferred. Please repost or ping me
> > once the dependency is available in an RC release.
> 
> Now in v4.17-rc1.

Thanks, applied.

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Geert Uytterhoeven]

On Tue, Apr 24, 2018 at 10:41 AM, Simon Horman  wrote:
> On Mon, Apr 16, 2018 at 10:12:57AM +0100, Lee Jones wrote:
>> On Wed, 11 Apr 2018, Simon Horman wrote:
>> > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
>> > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
>> > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
>> > > ("gpio: correct docs about return value of gpiod_get_direction"). Now,
>> > > fix this user (until a better, system-wide solution is in place).
>> > >
>> > > Signed-off-by: Wolfram Sang 
>> > > Acked-by: Daniel Thompson 
>> >
>> > Reviewed-by: Simon Horman 
>>
>> Thanks for the Reviewed-by Simon.  I have applied it to the original mail.
>>
>> Do you know why you mail wasn't sent attached to the original thread?
>> For some reason I received this mail on it's own i.e. not in reply
>> to the original.
>
> No, not off hand. Perhaps I responded to the email in some unusual way
> but by now I don't recall. In any case I'll try to be more careful
> in future.

I see Lee is using gmail for sending, so I assume also for receiving.

While I did receive Simon's reply in-thread, lately I had issues with gmail
not always doing so, and sometimes failing to do deduplication when receiving
email through multiple paths (mailing lists and/or directly).

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v5 00/26] Fix watchdog on Renesas R-Car Gen2 and RZ/G1

[Simon Horman]

On Wed, Apr 18, 2018 at 03:37:29PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, Mar 13, 2018 at 9:05 PM, Simon Horman  wrote:
> > I understand that the watchdog driver has been accepted and that as things
> > currently stand if it is enabled in the build it will be enabled in DT and
> > a crash will result. From my POV that is a regression so I have decided
> > to adopt the alternate plan proposed by Geert above: in short drop DT
> > patches (to avoid enabling broken driver) and enqueue mach-shmobile
> > patches (which don't make things any worse.
> >
> > Patch-by-patch things are as follows.
> >
> > Dropped from "[PATCH v5 00/26] Fix watchdog on Renesas R-Car Gen2 and 
> > RZ/G1":
> >
> > 979d28f29742 ARM: dts: r8a7743: Adjust SMP routine size
> > 0b205f679f5d ARM: dts: r8a7745: Adjust SMP routine size
> > 2ad21a1d78b3 ARM: dts: r8a7790: Adjust SMP routine size
> > 82c978459c77 ARM: dts: r8a7791: Adjust SMP routine size
> > d303698e6ff3 ARM: dts: r8a7792: Adjust SMP routine size
> > d8b8b9a1e295 ARM: dts: r8a7793: Adjust SMP routine size
> > 70b3ab369773 ARM: dts: r8a7794: Adjust SMP routine size
> >
> > ebf26cf1b1de ARM: dts: r8a7743: Add watchdog support to SoC dtsi
> > 5a4566ab3777 ARM: dts: r8a7745: Add watchdog support to SoC dtsi
> > acd58e2bb1e5 ARM: dts: r8a7790: Add watchdog support to SoC dtsi
> > e3f89168e72f ARM: dts: r8a7791: Add watchdog support to SoC dtsi
> > e76a6a69a1fc ARM: dts: r8a7794: Add watchdog support to SoC dtsi
> > 242cc1ab7f7c ARM: dts: iwg20m: Add watchdog support to SoM dtsi
> > 748ed07f6c7c ARM: dts: iwg22m: Add watchdog support to SoM dtsi
> >
> >
> > Dropped from "[PATCH/RFC 00/11] ARM: dts: rcar-gen2: Enable watchdog 
> > support":
> >
> > c257202482e2 ARM: dts: r8a7792: Add RWDT node
> > 01ec04dec8eb ARM: dts: r8a7793: Add RWDT node
> > 8e6ebe4f2f94 ARM: dts: lager: Enable watchdog support
> > f223ad0198f6 ARM: dts: koelsch: Enable watchdog support
> > 1d14d2bb700d ARM: dts: porter: Enable watchdog support
> > bf71652fc955 ARM: dts: blanche: Enable watchdog support
> > 13a0b10aeea4 ARM: dts: wheat: Enable watchdog support
> > 4e247bf110b8 ARM: dts: gose: Enable watchdog support
> > 2dcbd24bbf5e ARM: dts: alt: Enable watchdog support
> > 7f6844c900b4 ARM: dts: silk: Enable watchdog support
> >
> > And applied:
> >
> > [v5] ARM: shmobile: rcar-gen2: Add watchdog support
> > [v5] ARM: shmobile: Add watchdog support
> >
> > In the case of the last patch above I removed the #ifdef from the header 
> > file.
> 
> I guess the time is ripe to apply the DTS patches again, in the following 
> order:
>   1. SMP routine size adjustments,
>   2. Watchdog support additions to dtsi,
>   3. Watchdog enablement for dts?
> 
> Thanks!

Thanks, I have tentatively reapplied all of the above.

Re: [renesas:topic/hs400-mmc-v4 3/4] drivers/mmc/host/tmio_mmc_core.c:1103:5: sparse: symbol 'tmio_mmc_prepare_hs400_tuning' was not declared. Should it be static?

[Simon Horman]

On Wed, Apr 18, 2018 at 08:26:08PM +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> topic/hs400-mmc-v4
> head:   bad50f922dfffd9bc1a54e1512852e45d25b4ac7
> commit: 485c8281e412190ab902c62868cfebf7dc783189 [3/4] mmc: tmio: add eMMC 
> HS400 mode support
> reproduce:
> # apt-get install sparse
> git checkout 485c8281e412190ab902c62868cfebf7dc783189
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
> 
> 
> sparse warnings: (new ones prefixed by >>)
> 
> >> drivers/mmc/host/tmio_mmc_core.c:1103:5: sparse: symbol 
> >> 'tmio_mmc_prepare_hs400_tuning' was not declared. Should it be static?
> >> drivers/mmc/host/tmio_mmc_core.c:1113:6: sparse: symbol 
> >> 'tmio_mmc_prepare_hs400_tuning_downgrade' was not declared. Should it be 
> >> static?
> >> drivers/mmc/host/tmio_mmc_core.c:1122:6: sparse: symbol 
> >> 'tmio_mmc_complete_hs400_tuning' was not declared. Should it be static?
> 
> Please review and possibly fold the followup patch.

Thanks. Yes, I agree that it looks like they should be static.
I'll address this when posting v5 of this patchset.

[PATCH v2 1/2] ARM: dts: r8a77470: Add SCIF support

[Biju Das]

Describe SCIF ports in the R8A77470 device tree.
Also it fixes the CPG clock index ZS from 6 to 5.

Fixes: 6929dfc5918049 ("ARM: dts: r8a77470: Initial SoC device tree")
Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/boot/dts/r8a77470.dtsi | 69 +++--
 1 file changed, 67 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 2f89f33..39549f2 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -190,19 +190,84 @@
dma-channels = <15>;
};
 
+   scif0: serial@e6e6 {
+   compatible = "renesas,scif-r8a77470",
+"renesas,rcar-gen2-scif", "renesas,scif";
+   reg = <0 0xe6e6 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 721>,
+< CPG_CORE 5>, <_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   power-domains = < 32>;
+   resets = < 721>;
+   status = "disabled";
+   };
+
scif1: serial@e6e68000 {
compatible = "renesas,scif-r8a77470",
 "renesas,rcar-gen2-scif", "renesas,scif";
reg = <0 0xe6e68000 0 0x40>;
interrupts = ;
-   clocks = < CPG_MOD 720>,
-< CPG_CORE 6>, <_clk>;
+   clocks = < CPG_MOD 720>,
+< CPG_CORE 5>, <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
power-domains = < 32>;
resets = < 720>;
status = "disabled";
};
 
+   scif2: serial@e6e58000 {
+   compatible = "renesas,scif-r8a77470",
+"renesas,rcar-gen2-scif", "renesas,scif";
+   reg = <0 0xe6e58000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 719>,
+< CPG_CORE 5>, <_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   power-domains = < 32>;
+   resets = < 719>;
+   status = "disabled";
+   };
+
+   scif3: serial@e6ea8000 {
+   compatible = "renesas,scif-r8a77470",
+"renesas,rcar-gen2-scif", "renesas,scif";
+   reg = <0 0xe6ea8000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 718>,
+< CPG_CORE 5>, <_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   power-domains = < 32>;
+   resets = < 718>;
+   status = "disabled";
+   };
+
+   scif4: serial@e6ee {
+   compatible = "renesas,scif-r8a77470",
+"renesas,rcar-gen2-scif", "renesas,scif";
+   reg = <0 0xe6ee 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 715>,
+< CPG_CORE 5>, <_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   power-domains = < 32>;
+   resets = < 715>;
+   status = "disabled";
+   };
+
+   scif5: serial@e6ee8000 {
+   compatible = "renesas,scif-r8a77470",
+"renesas,rcar-gen2-scif", "renesas,scif";
+   reg = <0 0xe6ee8000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 714>,
+< CPG_CORE 5>, <_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   power-domains = < 32>;
+   resets = < 714>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
-- 
2.7.4

[PATCH v2 0/2] Add SCIF support

[Biju Das]

This patch series ass SCIF with DMA support to the r8a77470 SoC dtsi

This patch series tested against renesas-dev branch tag 
"renesas-dev-20180423-v4.17-rc2"

V1-->V2
   Added change log for ZS clock index fix.

Biju Das (2):
  ARM: dts: r8a77470: Add SCIF support
  ARM: dts: r8a77470: Add SCIF DMA support

 arch/arm/boot/dts/r8a77470.dtsi | 87 -
 1 file changed, 85 insertions(+), 2 deletions(-)

-- 
2.7.4

[PATCH v2 2/2] ARM: dts: r8a77470: Add SCIF DMA support

[Biju Das]

Add SCIF DMA support for R8A77470 SoC.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/boot/dts/r8a77470.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 39549f2..baec3ca 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -198,6 +198,9 @@
clocks = < CPG_MOD 721>,
 < CPG_CORE 5>, <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0x29>, < 0x2a>,
+  < 0x29>, < 0x2a>;
+   dma-names = "tx", "rx", "tx", "rx";
power-domains = < 32>;
resets = < 721>;
status = "disabled";
@@ -211,6 +214,9 @@
clocks = < CPG_MOD 720>,
 < CPG_CORE 5>, <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0x2d>, < 0x2e>,
+  < 0x2d>, < 0x2e>;
+   dma-names = "tx", "rx", "tx", "rx";
power-domains = < 32>;
resets = < 720>;
status = "disabled";
@@ -224,6 +230,9 @@
clocks = < CPG_MOD 719>,
 < CPG_CORE 5>, <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0x2b>, < 0x2c>,
+  < 0x2b>, < 0x2c>;
+   dma-names = "tx", "rx", "tx", "rx";
power-domains = < 32>;
resets = < 719>;
status = "disabled";
@@ -237,6 +246,9 @@
clocks = < CPG_MOD 718>,
 < CPG_CORE 5>, <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0x2f>, < 0x30>,
+  < 0x2f>, < 0x30>;
+   dma-names = "tx", "rx", "tx", "rx";
power-domains = < 32>;
resets = < 718>;
status = "disabled";
@@ -250,6 +262,9 @@
clocks = < CPG_MOD 715>,
 < CPG_CORE 5>, <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0xfb>, < 0xfc>,
+  < 0xfb>, < 0xfc>;
+   dma-names = "tx", "rx", "tx", "rx";
power-domains = < 32>;
resets = < 715>;
status = "disabled";
@@ -263,6 +278,9 @@
clocks = < CPG_MOD 714>,
 < CPG_CORE 5>, <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0xfd>, < 0xfe>,
+  < 0xfd>, < 0xfe>;
+   dma-names = "tx", "rx", "tx", "rx";
power-domains = < 32>;
resets = < 714>;
status = "disabled";
-- 
2.7.4

Re: [PATCH 2/2] thermal: rcar_gen3_thermal: update max temperature clamp

[Simon Horman]

On Tue, Apr 17, 2018 at 10:57:47PM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund 
> 
> Change the upper limit to clamp the high temperature value to 120C when
> setting trip points.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Simon Horman 

Re: [PATCH 1/2] thermal: rcar_gen3_thermal: Update calculation formula due to HW evaluation

[Simon Horman]

On Tue, Apr 17, 2018 at 10:57:46PM +0200, Niklas Söderlund wrote:
> From: Hien Dang 
> 
> Due to hardware evaluation result,
> Max temperature is changed from 96 to 116 degree Celsius.
> Also, calculation formula and pseudo FUSE values are changed accordingly.
> 
> Signed-off-by: Dien Pham 
> Signed-off-by: Hien Dang 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Simon Horman 

Re: [PATCH v3] dmaengine: rcar-dmac: Document R-Car D3 bindings

[Simon Horman]

On Mon, Apr 16, 2018 at 01:08:19PM +0200, Geert Uytterhoeven wrote:
> Hi Uli,
> 
> On Tue, Dec 19, 2017 at 10:13 AM, Ulrich Hecht
>  wrote:
> > R8A77995's SYS-DMAC is R-Car Gen3-compatible.
> >
> > Signed-off-by: Ulrich Hecht 
> > Reviewed-by: Geert Uytterhoeven 
> > Reviewed-by: Simon Horman 
> > ---
> > This revision adds the missing Reviewed-Bys.
> 
> Can you please resend to the DMA engine and DT maintainers?
> Thanks!

I have taken the liberty of rebasing this and posting v4.

[PATCH v4] dmaengine: rcar-dmac: Document R-Car D3 bindings

[Simon Horman]

From: Ulrich Hecht 

R8A77995's SYS-DMAC is R-Car Gen3-compatible.

Signed-off-by: Ulrich Hecht 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
[simon: rebased]
Signed-off-by: Simon Horman 
---
Based on v4.17-rc1
---
 Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt 
b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
index aadfb236d53a..11796d43740a 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
+++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
@@ -28,6 +28,7 @@ Required Properties:
- "renesas,dmac-r8a7796" (R-Car M3-W)
- "renesas,dmac-r8a77970" (R-Car V3M)
- "renesas,dmac-r8a77980" (R-Car V3H)
+   - "renesas,dmac-r8a77995" (R-Car D3)
 
 - reg: base address and length of the registers block for the DMAC
 
-- 
2.11.0

Re: [PATCH v2] watchdog: renesas-wdt: Add support for the R8A77965 WDT

[Vaishali Thakkar]

On Tue, Apr 24, 2018 at 2:08 PM, Simon Horman  wrote:
> On Sat, Apr 14, 2018 at 12:18:58PM +0200, Wolfram Sang wrote:
>> Document support for the Watchdog Timer (WDT) Controller in the Renesas
>> R-Car M3-N (R8A77965) SoC. No driver update is needed.
>>
>> Signed-off-by: Takeshi Kihara 
>> [wsa: rebased to top-of-tree]
>> Signed-off-by: Wolfram Sang 
>> Reviewed-by: Geert Uytterhoeven 
>
> Reviewed-by: Simon Horman 

Reviewed-by: Vaishali Thakkar 

>> ---
>>
>> Change since v1: s/M3N/M3-N/ (Thanks, Geert!)
>>
>>  Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt 
>> b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
>> index 123bb1b2654b..613d860f2353 100644
>> --- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
>> +++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
>> @@ -15,6 +15,7 @@ Required properties:
>>- "renesas,r8a7794-wdt" (R-Car E2)
>>- "renesas,r8a7795-wdt" (R-Car H3)
>>- "renesas,r8a7796-wdt" (R-Car M3-W)
>> +  - "renesas,r8a77965-wdt" (R-Car M3-N)
>>- "renesas,r8a77970-wdt" (R-Car V3M)
>>- "renesas,r8a77995-wdt" (R-Car D3)
>>  The generic compatible string must be:
>> --
>> 2.11.0
>>

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Simon Horman]

On Mon, Apr 16, 2018 at 10:12:57AM +0100, Lee Jones wrote:
> On Wed, 11 Apr 2018, Simon Horman wrote:
> 
> > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> > > ("gpio: correct docs about return value of gpiod_get_direction"). Now,
> > > fix this user (until a better, system-wide solution is in place).
> > > 
> > > Signed-off-by: Wolfram Sang 
> > > Acked-by: Daniel Thompson 
> > 
> > Reviewed-by: Simon Horman 
> 
> Thanks for the Reviewed-by Simon.  I have applied it to the original mail.
> 
> Do you know why you mail wasn't sent attached to the original thread?
> For some reason I received this mail on it's own i.e. not in reply
> to the original.

No, not off hand. Perhaps I responded to the email in some unusual way
but by now I don't recall. In any case I'll try to be more careful
in future.

Re: [PATCH v2] watchdog: renesas-wdt: Add support for the R8A77965 WDT

[Simon Horman]

On Sat, Apr 14, 2018 at 12:18:58PM +0200, Wolfram Sang wrote:
> Document support for the Watchdog Timer (WDT) Controller in the Renesas
> R-Car M3-N (R8A77965) SoC. No driver update is needed.
> 
> Signed-off-by: Takeshi Kihara 
> [wsa: rebased to top-of-tree]
> Signed-off-by: Wolfram Sang 
> Reviewed-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

> ---
> 
> Change since v1: s/M3N/M3-N/ (Thanks, Geert!)
> 
>  Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> index 123bb1b2654b..613d860f2353 100644
> --- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
> @@ -15,6 +15,7 @@ Required properties:
>- "renesas,r8a7794-wdt" (R-Car E2)
>- "renesas,r8a7795-wdt" (R-Car H3)
>- "renesas,r8a7796-wdt" (R-Car M3-W)
> +  - "renesas,r8a77965-wdt" (R-Car M3-N)
>- "renesas,r8a77970-wdt" (R-Car V3M)
>- "renesas,r8a77995-wdt" (R-Car D3)
>  The generic compatible string must be:
> -- 
> 2.11.0
> 

Re: [PATCH v2 1/2] arm64: dts: renesas: Add Renesas R8A77990 SoC support

[Simon Horman]

On Tue, Apr 24, 2018 at 10:26:37AM +0200, Geert Uytterhoeven wrote:
> Hi Shimoda-san,
> 
> On Fri, Apr 20, 2018 at 2:28 PM, Yoshihiro Shimoda
>  wrote:
> > This patch adds basic support for the Renesas R-Car E3 (R8A77990) SoC:
> >   - PSCI
> >   - CPU (single)
> >   - Cache controller
> >   - Main clocks and controller
> >   - Interrupt controller
> >   - Timer
> >   - PMU
> >   - Reset controller
> >   - Product register
> >   - System controller
> >   - UART for console
> >
> > Inspried by a patch by Takeshi Kihara in the BSP.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Thanks for you patch!

Thanks for your review.

As I've already applied this patch I'd like to ask Shimoda-san
to send incremental patches to address the issues you raise below.

> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > @@ -0,0 +1,127 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Device Tree Source for the r8a77990 SoC
> > + *
> > + * Copyright (C) 2018 Renesas Electronics Corp.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +/ {
> > +   compatible = "renesas,r8a77990";
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +
> > +   cpus {
> 
> > +   L2_CA53: cache-controller@0 {
> > +   compatible = "cache";
> > +   reg = <0>;
> 
> Please no unit-addresses and reg properties for cache controllers.
> 
> > +   power-domains = < 21>;
> > +   cache-unified;
> > +   cache-level = <2>;
> > +   };
> > +   };
> 
> > +   psci {
> > +   compatible = "arm,psci-0.2";
> 
> "arm,psci-1.0", "arm,psci-0.2"?
> 
> > +   method = "smc";
> > +   };
> > +
> > +   soc: soc {
> 
> > +   rst: reset-controller@e616 {
> > +   compatible = "renesas,r8a77990-rst";
> > +   reg = <0 0xe616 0 0x0200>;
> > +   };
> > +
> > +   sysc: system-controller@e618 {
> > +   compatible = "renesas,r8a77990-sysc";
> > +   reg = <0 0xe618 0 0x0400>;
> > +   #power-domain-cells = <1>;
> > +   };
> > +
> > +   scif2: serial@e6e88000 {
> > +   compatible = "renesas,scif-r8a77990",
> > +"renesas,rcar-gen3-scif", 
> > "renesas,scif";
> > +   reg = <0 0xe6e88000 0 64>;
> > +   interrupts = ;
> > +   clocks = < CPG_MOD 310>;
> > +   clock-names = "fck";
> 
> I assume you plan to add the other clocks later? That's fine for me.
> 
> > +   power-domains = < 32>;
> > +   resets = < 310>;
> > +   status = "disabled";
> > +   };
> 
> 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 2/2] arm64: dts: renesas: Add Renesas Ebisu board support

[Geert Uytterhoeven]

On Fri, Apr 20, 2018 at 2:28 PM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> Basic support for the Renesas Ebisu board based on R-Car E3:
>   - Memory,
>   - Main crystal,
>   - Serial console,
>
> Signed-off-by: Takeshi Kihara 
> [shimoda: rebase and add SPDX-License-Identifier]
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v10 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

[jacopo mondi]

Hi Simon,

On Tue, Apr 24, 2018 at 10:23:56AM +0200, Simon Horman wrote:
> On Mon, Apr 23, 2018 at 05:21:43PM +0200, jacopo mondi wrote:
> > Hi Simon,
> >
> > On Wed, Feb 21, 2018 at 07:29:18PM +0100, Simon Horman wrote:
> > > On Wed, Feb 21, 2018 at 06:47:58PM +0100, Jacopo Mondi wrote:
> > > > Add Capture Engine Unit (CEU) node to device tree.
> > > >
> > > > Signed-off-by: Jacopo Mondi 
> > > > Reviewed-by: Geert Uytterhoeven 
> > > > Reviewed-by: Laurent Pinchart 
> > > > Acked-by: Hans Verkuil 
> > >
> > > This patch depends on the binding for "renesas,r7s72100-ceu".
> > > Please repost or otherwise ping me once that dependency has been accepted.
> >
> > Bindings for the CEU interface went in v4.17-rc1.
> >
> > Could you please resurect this patch?
>
> Sure, I took the liberty of "rebasing" it to preserve the new node-order
> of r7s72100.dtsi. The result is as follows:

That's even better.

Thanks
   j

>
> From: Jacopo Mondi 
> Subject: [PATCH] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)
>
> Add Capture Engine Unit (CEU) node to device tree.
>
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Hans Verkuil 
> [simon: rebased]
> Signed-off-by: Simon Horman 
> ---
>  arch/arm/boot/dts/r7s72100.dtsi | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
> index ecf9516bcda8..4a1aade0e751 100644
> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -375,6 +375,15 @@
>   status = "disabled";
>   };
>
> + ceu: camera@e821 {
> + reg = <0xe821 0x3000>;
> + compatible = "renesas,r7s72100-ceu";
> + interrupts = ;
> + clocks = <_clks R7S72100_CLK_CEU>;
> + power-domains = <_clocks>;
> + status = "disabled";
> + };
> +
>   wdt: watchdog@fcfe {
>   compatible = "renesas,r7s72100-wdt", "renesas,rza-wdt";
>   reg = <0xfcfe 0x6>;
> @@ -429,9 +438,9 @@
>   #clock-cells = <1>;
>   compatible = "renesas,r7s72100-mstp-clocks", 
> "renesas,cpg-mstp-clocks";
>   reg = <0xfcfe042c 4>;
> - clocks = <_clk>;
> - clock-indices = ;
> - clock-output-names = "rtc";
> + clocks = <_clk>, <_clk>;
> + clock-indices = ;
> + clock-output-names = "ceu", "rtc";
>   };
>
>   mstp7_clks: mstp7_clks@fcfe0430 {
> --
> 2.11.0
>
>


signature.asc
Description: PGP signature

[PATCH] dt-bindings: gpio: rcar: Add r8a77470 (RZ/G1C) support

[Biju Das]

Renesas RZ/G1C (R8A77470) SoC GPIO blocks are identical to the R-Car Gen2
family. Add support for its GPIO controllers.

Signed-off-by: Biju Das 
Reviewed-by: Chris Paterson 
---
 Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt 
b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
index 9474138..bd2b802 100644
--- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
+++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
@@ -5,6 +5,7 @@ Required Properties:
   - compatible: should contain one or more of the following:
 - "renesas,gpio-r8a7743": for R8A7743 (RZ/G1M) compatible GPIO controller.
 - "renesas,gpio-r8a7745": for R8A7745 (RZ/G1E) compatible GPIO controller.
+- "renesas,gpio-r8a77470": for R8A77470 (RZ/G1C) compatible GPIO 
controller.
 - "renesas,gpio-r8a7778": for R8A7778 (R-Car M1) compatible GPIO 
controller.
 - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO 
controller.
 - "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO 
controller.
-- 
2.7.4

Re: [PATCH v2 1/2] arm64: dts: renesas: Add Renesas R8A77990 SoC support

[Geert Uytterhoeven]

Hi Shimoda-san,

On Fri, Apr 20, 2018 at 2:28 PM, Yoshihiro Shimoda
 wrote:
> This patch adds basic support for the Renesas R-Car E3 (R8A77990) SoC:
>   - PSCI
>   - CPU (single)
>   - Cache controller
>   - Main clocks and controller
>   - Interrupt controller
>   - Timer
>   - PMU
>   - Reset controller
>   - Product register
>   - System controller
>   - UART for console
>
> Inspried by a patch by Takeshi Kihara in the BSP.
>
> Signed-off-by: Yoshihiro Shimoda 

Thanks for you patch!

> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> @@ -0,0 +1,127 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Device Tree Source for the r8a77990 SoC
> + *
> + * Copyright (C) 2018 Renesas Electronics Corp.
> + */
> +
> +#include 
> +#include 
> +
> +/ {
> +   compatible = "renesas,r8a77990";
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +
> +   cpus {

> +   L2_CA53: cache-controller@0 {
> +   compatible = "cache";
> +   reg = <0>;

Please no unit-addresses and reg properties for cache controllers.

> +   power-domains = < 21>;
> +   cache-unified;
> +   cache-level = <2>;
> +   };
> +   };

> +   psci {
> +   compatible = "arm,psci-0.2";

"arm,psci-1.0", "arm,psci-0.2"?

> +   method = "smc";
> +   };
> +
> +   soc: soc {

> +   rst: reset-controller@e616 {
> +   compatible = "renesas,r8a77990-rst";
> +   reg = <0 0xe616 0 0x0200>;
> +   };
> +
> +   sysc: system-controller@e618 {
> +   compatible = "renesas,r8a77990-sysc";
> +   reg = <0 0xe618 0 0x0400>;
> +   #power-domain-cells = <1>;
> +   };
> +
> +   scif2: serial@e6e88000 {
> +   compatible = "renesas,scif-r8a77990",
> +"renesas,rcar-gen3-scif", "renesas,scif";
> +   reg = <0 0xe6e88000 0 64>;
> +   interrupts = ;
> +   clocks = < CPG_MOD 310>;
> +   clock-names = "fck";

I assume you plan to add the other clocks later? That's fine for me.

> +   power-domains = < 32>;
> +   resets = < 310>;
> +   status = "disabled";
> +   };

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] dt-bindings: arm: consistently name r8a77965 as M3-N

[Simon Horman]

On Tue, Apr 24, 2018 at 09:16:17AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, Apr 24, 2018 at 7:54 AM, Simon Horman
>  wrote:
> > There is an inconsistency between the use of M3N and M3-N.
> > This patch resolves this by consistently using the latter.
> >
> > Signed-off-by: Simon Horman 
> 
> Note that this is for a custom Salvator-X board where the M3-W SiP was
> replaced by an M3-N SiP.  So I have no idea what's on the sticker, if it was
> replaced at all, and thus kept the text from the BSP.

Understood. But I think we should make the naming consistent regardless.

> 
> > --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> > @@ -116,7 +116,7 @@ Boards:
> >  compatible = "renesas,salvator-x", "renesas,r8a7795"
> >- Salvator-X (RTP0RC7796SIPB0011S)
> >  compatible = "renesas,salvator-x", "renesas,r8a7796"
> > -  - Salvator-X (RTP0RC7796SIPB0011S (M3N))
> > +  - Salvator-X (RTP0RC7796SIPB0011S (M3-N))
> >  compatible = "renesas,salvator-x", "renesas,r8a77965"
> >- Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S)
> >  compatible = "renesas,salvator-xs", "renesas,r8a7795"
> \
> Gr{oetje,eeting}s,
> 
> Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 

Re: [PATCH 0/5] arm64: dts: renesas: r8a779xx: sort nodes

[Simon Horman]

On Tue, Apr 24, 2018 at 02:31:40AM +0900, Yoshihiro Kaneko wrote:
> Hi Simon-san,
> 
> 2018-04-23 19:26 GMT+09:00 Simon Horman :
> > On Thu, Apr 19, 2018 at 05:14:35AM +0900, Yoshihiro Kaneko wrote:
> >> Sort nodes of the R-Car M3-N (r8a77965), V3M (r8a77970) and D3 (r8a77995) 
> >> DTs.
> >>
> >> This is part of an ongoing effort to provide consistent node
> >> order in the DT of Renesas SoCs to improve maintainability.
> >>
> >> This should not have any run-time effect.
> >>
> >> Based on the devel branch of Simon Horman's renesas tree.
> >>
> >> Yoshihiro Kaneko (5):
> >>   arm64: dts: renesas: r8a77995: sort subnodes of the root node
> >>   arm64: dts: renesas: r8a77995: sort subnodes of the soc node
> >>   arm64: dts: renesas: r8a77965: sort subnodes of the root node
> >>   arm64: dts: renesas: r8a77965: sort subnodes of the soc node
> >>   arm64: dts: renesas: r8a77970: sort subnodes of the soc node
> >
> > Thanks, applied.
> >
> > There ware a few nodes added to r8a77970 between when you made
> > this patchset and when I applied it. I think the r8a77970 is still
> > sorted as desired. Could you double-check once I push a devel
> > branch later today?
> 
> Yes, will do.

Thanks, you should now be able to check renesas-devel-20180423-v4.17-rc2

Re: [PATCH v10 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

[Simon Horman]

On Mon, Apr 23, 2018 at 05:21:43PM +0200, jacopo mondi wrote:
> Hi Simon,
> 
> On Wed, Feb 21, 2018 at 07:29:18PM +0100, Simon Horman wrote:
> > On Wed, Feb 21, 2018 at 06:47:58PM +0100, Jacopo Mondi wrote:
> > > Add Capture Engine Unit (CEU) node to device tree.
> > >
> > > Signed-off-by: Jacopo Mondi 
> > > Reviewed-by: Geert Uytterhoeven 
> > > Reviewed-by: Laurent Pinchart 
> > > Acked-by: Hans Verkuil 
> >
> > This patch depends on the binding for "renesas,r7s72100-ceu".
> > Please repost or otherwise ping me once that dependency has been accepted.
> 
> Bindings for the CEU interface went in v4.17-rc1.
> 
> Could you please resurect this patch?

Sure, I took the liberty of "rebasing" it to preserve the new node-order
of r7s72100.dtsi. The result is as follows:

From: Jacopo Mondi 
Subject: [PATCH] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

Add Capture Engine Unit (CEU) node to device tree.

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

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index ecf9516bcda8..4a1aade0e751 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -375,6 +375,15 @@
status = "disabled";
};
 
+   ceu: camera@e821 {
+   reg = <0xe821 0x3000>;
+   compatible = "renesas,r7s72100-ceu";
+   interrupts = ;
+   clocks = <_clks R7S72100_CLK_CEU>;
+   power-domains = <_clocks>;
+   status = "disabled";
+   };
+
wdt: watchdog@fcfe {
compatible = "renesas,r7s72100-wdt", "renesas,rza-wdt";
reg = <0xfcfe 0x6>;
@@ -429,9 +438,9 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", 
"renesas,cpg-mstp-clocks";
reg = <0xfcfe042c 4>;
-   clocks = <_clk>;
-   clock-indices = ;
-   clock-output-names = "rtc";
+   clocks = <_clk>, <_clk>;
+   clock-indices = ;
+   clock-output-names = "ceu", "rtc";
};
 
mstp7_clks: mstp7_clks@fcfe0430 {
-- 
2.11.0

RE: [PATCH 3/4] ARM: dts: r8a77470: Add SCIF support

[Biju Das]

Hi Simon and Geert,

Thanks for the feedback.

> Subject: Re: [PATCH 3/4] ARM: dts: r8a77470: Add SCIF support
>
> On Tue, Apr 24, 2018 at 09:19:39AM +0200, Geert Uytterhoeven wrote:
> > Hi Simon,
> >
> > On Tue, Apr 24, 2018 at 9:08 AM, Simon Horman 
> wrote:
> > > On Fri, Apr 20, 2018 at 04:27:08PM +0100, Biju Das wrote:
> > >> Describe SCIF ports in the R8A77470 device tree.
> > >>
> > >> Signed-off-by: Biju Das 
> > >> Reviewed-by: Fabrizio Castro 
> > >> ---
> > >>  arch/arm/boot/dts/r8a77470.dtsi | 69
> > >> +++--
> > >>  1 file changed, 67 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/arch/arm/boot/dts/r8a77470.dtsi
> > >> b/arch/arm/boot/dts/r8a77470.dtsi index 2f89f33..39549f2 100644
> > >> --- a/arch/arm/boot/dts/r8a77470.dtsi
> > >> +++ b/arch/arm/boot/dts/r8a77470.dtsi
> > >> @@ -190,19 +190,84 @@
> > >>   dma-channels = <15>;
> > >>   };
> > >>
> > >> + scif0: serial@e6e6 {
> > >> + compatible = "renesas,scif-r8a77470",
> > >> +  "renesas,rcar-gen2-scif", 
> > >> "renesas,scif";
> > >> + reg = <0 0xe6e6 0 0x40>;
> > >> + interrupts = ;
> > >> + clocks = < CPG_MOD 721>,
> > >> +  < CPG_CORE 5>, <_clk>;
> > >> + clock-names = "fck", "brg_int", "scif_clk";
> > >> + power-domains = < 32>;
> > >> + resets = < 721>;
> > >> + status = "disabled";
> > >> + };
> > >> +
> > >>   scif1: serial@e6e68000 {
> > >>   compatible = "renesas,scif-r8a77470",
> > >>"renesas,rcar-gen2-scif", 
> > >> "renesas,scif";
> > >>   reg = <0 0xe6e68000 0 0x40>;
> > >>   interrupts = ;
> > >> - clocks = < CPG_MOD 720>,
> > >> -  < CPG_CORE 6>, <_clk>;
> > >> + clocks = < CPG_MOD 720>,
> > >> +  < CPG_CORE 5>, <_clk>;
> > >
> > > I am a little unclear why the CPG clock is changed from 6 (ZS?) to 5 
> > > (ZX?).
> > > Could you clarify this for me?
> >
> > #define R8A77470_CLK_ZS 5
> >
> > I guess you queued up the initial .dtsi before the error in
> > include/dt-bindings/clock/r8a77470-cpg-mssr.h was detected?
>
> Thanks, I see that ZS is 5 in renesas-drivers, but when looking at an earlier
> version of the patch to add the indexes it was 6.

Yes, I took this value from renesas-drivers.

> I think that explains things. But could we add an explanation to the
> changelog?

OK. I will add the explanation to the change log.

Regards,
Biju




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

Re: [PATCH 3/4] ARM: dts: r8a77470: Add SCIF support

[Simon Horman]

On Tue, Apr 24, 2018 at 09:19:39AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, Apr 24, 2018 at 9:08 AM, Simon Horman  wrote:
> > On Fri, Apr 20, 2018 at 04:27:08PM +0100, Biju Das wrote:
> >> Describe SCIF ports in the R8A77470 device tree.
> >>
> >> Signed-off-by: Biju Das 
> >> Reviewed-by: Fabrizio Castro 
> >> ---
> >>  arch/arm/boot/dts/r8a77470.dtsi | 69 
> >> +++--
> >>  1 file changed, 67 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/r8a77470.dtsi 
> >> b/arch/arm/boot/dts/r8a77470.dtsi
> >> index 2f89f33..39549f2 100644
> >> --- a/arch/arm/boot/dts/r8a77470.dtsi
> >> +++ b/arch/arm/boot/dts/r8a77470.dtsi
> >> @@ -190,19 +190,84 @@
> >>   dma-channels = <15>;
> >>   };
> >>
> >> + scif0: serial@e6e6 {
> >> + compatible = "renesas,scif-r8a77470",
> >> +  "renesas,rcar-gen2-scif", 
> >> "renesas,scif";
> >> + reg = <0 0xe6e6 0 0x40>;
> >> + interrupts = ;
> >> + clocks = < CPG_MOD 721>,
> >> +  < CPG_CORE 5>, <_clk>;
> >> + clock-names = "fck", "brg_int", "scif_clk";
> >> + power-domains = < 32>;
> >> + resets = < 721>;
> >> + status = "disabled";
> >> + };
> >> +
> >>   scif1: serial@e6e68000 {
> >>   compatible = "renesas,scif-r8a77470",
> >>"renesas,rcar-gen2-scif", 
> >> "renesas,scif";
> >>   reg = <0 0xe6e68000 0 0x40>;
> >>   interrupts = ;
> >> - clocks = < CPG_MOD 720>,
> >> -  < CPG_CORE 6>, <_clk>;
> >> + clocks = < CPG_MOD 720>,
> >> +  < CPG_CORE 5>, <_clk>;
> >
> > I am a little unclear why the CPG clock is changed from 6 (ZS?) to 5 (ZX?).
> > Could you clarify this for me?
> 
> #define R8A77470_CLK_ZS 5
> 
> I guess you queued up the initial .dtsi before the error in
> include/dt-bindings/clock/r8a77470-cpg-mssr.h was detected?

Thanks, I see that ZS is 5 in renesas-drivers,
but when looking at an earlier version of the patch to add the
indexes it was 6.

I think that explains things. But could we add an explanation to the
changelog?

Re: [PATCH v2 2/2] clk: renesas: cpg-mssr: Add support for R-Car E3

[Geert Uytterhoeven]

On Fri, Apr 20, 2018 at 2:27 PM, Yoshihiro Shimoda
 wrote:
> Initial support for R-Car E3 (r8a77990), including core and module
> clocks.
>
> Based on the Table 8.2g of "R-Car Series, 3rd Generation User's Manual:
> Hardware ((Rev. 0.80, Oct 31, 2017) with Manual Errata on Feb. 28, 2018".
>
> Inspried by patches by Takeshi Kihara in the BSP.
>
> Signed-off-by: Yoshihiro Shimoda 

Thanks, will queue in clk-renesas-for-v4.18.

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 1/2] clk: renesas: Add r8a77990 CPG Core Clock Definitions

[Geert Uytterhoeven]

Hi Shimoda-san,

On Fri, Apr 20, 2018 at 2:27 PM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> This patch adds all R-Car E3 Clock Pulse Generator Core Clock Outputs.
>
> Note that internal CPG clocks (S0, S1, S2, S3, SDSRC) are not included,
> as they are used as internal clock sources only, and never referenced
> from DT.
>
> Signed-off-by: Takeshi Kihara 
> [shimoda: add SPDX-License-Identifier]
> Signed-off-by: Yoshihiro Shimoda 

Thanks for your patch!

> --- /dev/null
> +++ b/include/dt-bindings/clock/r8a77990-cpg-mssr.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2018 Renesas Electronics Corp.
> + */
> +#ifndef __DT_BINDINGS_CLOCK_R8A77990_CPG_MSSR_H__
> +#define __DT_BINDINGS_CLOCK_R8A77990_CPG_MSSR_H__
> +
> +#include 
> +
> +/* r8a77990 CPG Core Clocks */
> +#define R8A77990_CLK_Z20

[...]

> +#define R8A77990_CLK_CSI0  47
> +#define R8A77990_CLK_CP49
> +#define R8A77990_CLK_CPEX  50

The numbering should be contiguous.
I'll fix it up while applying, and add "POST3" to the list of internal clocks in
the commit message.

> +
> +#endif /* __DT_BINDINGS_CLOCK_R8A77990_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 05/61] clk: samsung: simplify getting .drvdata

[Chanwoo Choi]

Hi,

On 2018년 04월 19일 23:05, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 
> ---
> 
> Build tested only. buildbot is happy. Please apply individually.
> 
>  drivers/clk/samsung/clk-s3c2410-dclk.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-s3c2410-dclk.c 
> b/drivers/clk/samsung/clk-s3c2410-dclk.c
> index 077df3e539a7..f41d89cef0f1 100644
> --- a/drivers/clk/samsung/clk-s3c2410-dclk.c
> +++ b/drivers/clk/samsung/clk-s3c2410-dclk.c
> @@ -219,8 +219,7 @@ static int s3c24xx_dclk1_div_notify(struct notifier_block 
> *nb,
>  #ifdef CONFIG_PM_SLEEP
>  static int s3c24xx_dclk_suspend(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct s3c24xx_dclk *s3c24xx_dclk = platform_get_drvdata(pdev);
> + struct s3c24xx_dclk *s3c24xx_dclk = dev_get_drvdata(dev);
>  
>   s3c24xx_dclk->reg_save = readl_relaxed(s3c24xx_dclk->base);
>   return 0;
> @@ -228,8 +227,7 @@ static int s3c24xx_dclk_suspend(struct device *dev)
>  
>  static int s3c24xx_dclk_resume(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct s3c24xx_dclk *s3c24xx_dclk = platform_get_drvdata(pdev);
> + struct s3c24xx_dclk *s3c24xx_dclk = dev_get_drvdata(dev);
>  
>   writel_relaxed(s3c24xx_dclk->reg_save, s3c24xx_dclk->base);
>   return 0;
> 

Reviewed-by: Chanwoo Choi 

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH 8/8] drm: connector: Remove DRM_BUS_FLAG_DATA_* flags

[jacopo mondi]

Hi Laurent,

On Tue, Apr 24, 2018 at 12:03:04AM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Thursday, 19 April 2018 12:31:09 EEST Jacopo Mondi wrote:
> > DRM_BUS_FLAG_DATA_* flags, defined in drm_connector.h header file are
> > used to swap ordering of LVDS RGB format to accommodate DRM objects
> > that need to handle LVDS components ordering.
> >
> > Now that the only 2 users of DRM_BUS_FLAG_DATA_* flags have been ported
> > to use the newly introduced MEDIA_BUS_FMT_RGB888_1X7X*_LE media bus
> > formats, remove them.
>
> I'm not opposed to this (despite my review of patch 5/8), but I think the _LE
> suffix isn't the right name for the new formats. _BE and _LE relate to byte
> swapping, while here you really need to describe full mirroring. Maybe a
> _MIRROR variant would be more appropriate ?

As I anticipated in the cover letter, I agree the BE/LE distinction
does not apply well for LVDS formats. I chose to use _LE anyhow as
there are no other format variants defined in media-bus-format.h

I'm open to use either of those suffixes btw, what presses me is to
get rid of those flags only defined in drm_connector.h

thanks
   j

>
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  include/drm/drm_connector.h | 4 
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 675cc3f..9e0d6d5 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -286,10 +286,6 @@ struct drm_display_info {
> >  #define DRM_BUS_FLAG_PIXDATA_POSEDGE   (1<<2)
> >  /* drive data on neg. edge */
> >  #define DRM_BUS_FLAG_PIXDATA_NEGEDGE   (1<<3)
> > -/* data is transmitted MSB to LSB on the bus */
> > -#define DRM_BUS_FLAG_DATA_MSB_TO_LSB   (1<<4)
> > -/* data is transmitted LSB to MSB on the bus */
> > -#define DRM_BUS_FLAG_DATA_LSB_TO_MSB   (1<<5)
> >
> > /**
> >  * @bus_flags: Additional information (like pixel signal polarity) for
>
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>


signature.asc
Description: PGP signature

Re: [PATCH 3/4] ARM: dts: r8a77470: Add SCIF support

[Geert Uytterhoeven]

Hi Simon,

On Tue, Apr 24, 2018 at 9:08 AM, Simon Horman  wrote:
> On Fri, Apr 20, 2018 at 04:27:08PM +0100, Biju Das wrote:
>> Describe SCIF ports in the R8A77470 device tree.
>>
>> Signed-off-by: Biju Das 
>> Reviewed-by: Fabrizio Castro 
>> ---
>>  arch/arm/boot/dts/r8a77470.dtsi | 69 
>> +++--
>>  1 file changed, 67 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/r8a77470.dtsi 
>> b/arch/arm/boot/dts/r8a77470.dtsi
>> index 2f89f33..39549f2 100644
>> --- a/arch/arm/boot/dts/r8a77470.dtsi
>> +++ b/arch/arm/boot/dts/r8a77470.dtsi
>> @@ -190,19 +190,84 @@
>>   dma-channels = <15>;
>>   };
>>
>> + scif0: serial@e6e6 {
>> + compatible = "renesas,scif-r8a77470",
>> +  "renesas,rcar-gen2-scif", "renesas,scif";
>> + reg = <0 0xe6e6 0 0x40>;
>> + interrupts = ;
>> + clocks = < CPG_MOD 721>,
>> +  < CPG_CORE 5>, <_clk>;
>> + clock-names = "fck", "brg_int", "scif_clk";
>> + power-domains = < 32>;
>> + resets = < 721>;
>> + status = "disabled";
>> + };
>> +
>>   scif1: serial@e6e68000 {
>>   compatible = "renesas,scif-r8a77470",
>>"renesas,rcar-gen2-scif", "renesas,scif";
>>   reg = <0 0xe6e68000 0 0x40>;
>>   interrupts = ;
>> - clocks = < CPG_MOD 720>,
>> -  < CPG_CORE 6>, <_clk>;
>> + clocks = < CPG_MOD 720>,
>> +  < CPG_CORE 5>, <_clk>;
>
> I am a little unclear why the CPG clock is changed from 6 (ZS?) to 5 (ZX?).
> Could you clarify this for me?

#define R8A77470_CLK_ZS 5

I guess you queued up the initial .dtsi before the error in
include/dt-bindings/clock/r8a77470-cpg-mssr.h was detected?

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 5/8] media: Add LE version of RGB LVDS formats

[jacopo mondi]

HI Laurent,

On Mon, Apr 23, 2018 at 04:06:01PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Thursday, 19 April 2018 12:31:06 EEST Jacopo Mondi wrote:
> > Some LVDS controller can output swapped versions of LVDS RGB formats.
> > Define and document them in the list of supported media bus formats
>
> I wouldn't introduce those new formats as we don't need them. As a general
> rule we would like to have at least one user for any new format added to the
> API.

I was about to point you to patch [8/8], as the newly introduced
formats allow replacing the DRM_BUS_FLAG_DATA_ flags, defined in
drm_connector.h and which I struggled to find a more appropiate place
where to move them. Or I either duplicate them for bridges, but I
prefer not to, or we remove them, and defining some dedicated formats,
seems more natural to me...

I'll reply to your comment on [8/8] on the format names and other
details.

Thanks
   j

>
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  Documentation/media/uapi/v4l/subdev-formats.rst | 174 +
> >  include/uapi/linux/media-bus-format.h   |   5 +-
> >  2 files changed, 178 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst
> > b/Documentation/media/uapi/v4l/subdev-formats.rst index 9fcabe7..9a5263c
> > 100644
> > --- a/Documentation/media/uapi/v4l/subdev-formats.rst
> > +++ b/Documentation/media/uapi/v4l/subdev-formats.rst
> > @@ -1669,6 +1669,64 @@ JEIDA defined bit mapping will be named
> >- b\ :sub:`2`
> >- g\ :sub:`1`
> >- r\ :sub:`0`
> > +* .. _MEDIA-BUS-FMT-RGB666-1X7X3-SPWG_LE:
> > +
> > +  - MEDIA_BUS_FMT_RGB666_1X7X3_SPWG_LE
> > +  - 0x101b
> > +  - 0
> > +  -
> > +  -
> > +  - b\ :sub:`2`
> > +  - g\ :sub:`1`
> > +  - r\ :sub:`0`
> > +* -
> > +  -
> > +  - 1
> > +  -
> > +  -
> > +  - b\ :sub:`3`
> > +  - g\ :sub:`2`
> > +  - r\ :sub:`1`
> > +* -
> > +  -
> > +  - 2
> > +  -
> > +  -
> > +  - b\ :sub:`4`
> > +  - g\ :sub:`3`
> > +  - r\ :sub:`2`
> > +* -
> > +  -
> > +  - 3
> > +  -
> > +  -
> > +  - b\ :sub:`5`
> > +  - g\ :sub:`4`
> > +  - r\ :sub:`3`
> > +* -
> > +  -
> > +  - 4
> > +  -
> > +  -
> > +  - d
> > +  - g\ :sub:`5`
> > +  - r\ :sub:`4`
> > +* -
> > +  -
> > +  - 5
> > +  -
> > +  -
> > +  - d
> > +  - b\ :sub:`0`
> > +  - r\ :sub:`5`
> > +* -
> > +  -
> > +  - 6
> > +  -
> > +  -
> > +  - d
> > +  - b\ :sub:`1`
> > +  - g\ :sub:`0`
> >  * .. _MEDIA-BUS-FMT-RGB888-1X7X4-SPWG:
> >
> >- MEDIA_BUS_FMT_RGB888_1X7X4_SPWG
> > @@ -1727,6 +1785,64 @@ JEIDA defined bit mapping will be named
> >- b\ :sub:`2`
> >- g\ :sub:`1`
> >- r\ :sub:`0`
> > +* .. _MEDIA-BUS-FMT-RGB888-1X7X4-SPWG_LE:
> > +
> > +  - MEDIA_BUS_FMT_RGB888_1X7X4_SPWG_LE
> > +  - 0x101c
> > +  - 0
> > +  -
> > +  - r\ :sub:`6`
> > +  - b\ :sub:`2`
> > +  - g\ :sub:`1`
> > +  - r\ :sub:`0`
> > +* -
> > +  -
> > +  - 1
> > +  -
> > +  - r\ :sub:`7`
> > +  - b\ :sub:`3`
> > +  - g\ :sub:`2`
> > +  - r\ :sub:`1`
> > +* -
> > +  -
> > +  - 2
> > +  -
> > +  - g\ :sub:`6`
> > +  - b\ :sub:`4`
> > +  - g\ :sub:`3`
> > +  - r\ :sub:`2`
> > +* -
> > +  -
> > +  - 3
> > +  -
> > +  - g\ :sub:`7`
> > +  - b\ :sub:`5`
> > +  - g\ :sub:`4`
> > +  - r\ :sub:`3`
> > +* -
> > +  -
> > +  - 4
> > +  -
> > +  - b\ :sub:`6`
> > +  - d
> > +  - g\ :sub:`5`
> > +  - r\ :sub:`4`
> > +* -
> > +  -
> > +  - 5
> > +  -
> > +  - b\ :sub:`7`
> > +  - d
> > +  - b\ :sub:`0`
> > +  - r\ :sub:`5`
> > +* -
> > +  -
> > +  - 6
> > +  -
> > +  - d
> > +  - d
> > +  - b\ :sub:`1`
> > +  - g\ :sub:`0`
> >  * .. _MEDIA-BUS-FMT-RGB888-1X7X4-JEIDA:
> >
> >- MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA
> > @@ -1785,6 +1901,64 @@ JEIDA defined bit mapping will be named
> >- b\ :sub:`4`
> >- g\ :sub:`3`
> >- r\ :sub:`2`
> > +* .. _MEDIA-BUS-FMT-RGB888-1X7X4-JEIDA_LE:
> > +
> > +  - MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA_LE
> > +  - 0x101d
> > +  - 0
> > +  -
> > +  - r\ :sub:`0`
> > +  - b\ :sub:`4`
> > +  - g\ :sub:`3`
> > +  - r\ :sub:`2`
> > +* -
> > +  -
> > +  - 1
> > +  -
> > +  - r\ :sub:`1`
> > +  - b\ :sub:`5`
> > +  - g\ :sub:`4`
> > +  - r\ :sub:`3`
> > +* -
> > +  -
> > +  - 2
> > +  -
> > +  - g\ :sub:`0`
> > +  - b\ :sub:`6`
> > +  - g\ :sub:`5`
> > +  - r\ :sub:`4`
> > +* -
> > +  -
> > +  - 3
> > +  -
> > +  - g\ :sub:`1`
> > +  - b\ :sub:`7`
> > +  - g\ 

Re: [PATCH] dt-bindings: arm: consistently name r8a77965 as M3-N

[Geert Uytterhoeven]

Hi Simon,

On Tue, Apr 24, 2018 at 7:54 AM, Simon Horman
 wrote:
> There is an inconsistency between the use of M3N and M3-N.
> This patch resolves this by consistently using the latter.
>
> Signed-off-by: Simon Horman 

Note that this is for a custom Salvator-X board where the M3-W SiP was
replaced by an M3-N SiP.  So I have no idea what's on the sticker, if it was
replaced at all, and thus kept the text from the BSP.

> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -116,7 +116,7 @@ Boards:
>  compatible = "renesas,salvator-x", "renesas,r8a7795"
>- Salvator-X (RTP0RC7796SIPB0011S)
>  compatible = "renesas,salvator-x", "renesas,r8a7796"
> -  - Salvator-X (RTP0RC7796SIPB0011S (M3N))
> +  - Salvator-X (RTP0RC7796SIPB0011S (M3-N))
>  compatible = "renesas,salvator-x", "renesas,r8a77965"
>- Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S)
>  compatible = "renesas,salvator-xs", "renesas,r8a7795"
\
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 3/4] ARM: dts: r8a77470: Add SCIF support

[Simon Horman]

On Fri, Apr 20, 2018 at 04:27:08PM +0100, Biju Das wrote:
> Describe SCIF ports in the R8A77470 device tree.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 
> ---
>  arch/arm/boot/dts/r8a77470.dtsi | 69 
> +++--
>  1 file changed, 67 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
> index 2f89f33..39549f2 100644
> --- a/arch/arm/boot/dts/r8a77470.dtsi
> +++ b/arch/arm/boot/dts/r8a77470.dtsi
> @@ -190,19 +190,84 @@
>   dma-channels = <15>;
>   };
>  
> + scif0: serial@e6e6 {
> + compatible = "renesas,scif-r8a77470",
> +  "renesas,rcar-gen2-scif", "renesas,scif";
> + reg = <0 0xe6e6 0 0x40>;
> + interrupts = ;
> + clocks = < CPG_MOD 721>,
> +  < CPG_CORE 5>, <_clk>;
> + clock-names = "fck", "brg_int", "scif_clk";
> + power-domains = < 32>;
> + resets = < 721>;
> + status = "disabled";
> + };
> +
>   scif1: serial@e6e68000 {
>   compatible = "renesas,scif-r8a77470",
>"renesas,rcar-gen2-scif", "renesas,scif";
>   reg = <0 0xe6e68000 0 0x40>;
>   interrupts = ;
> - clocks = < CPG_MOD 720>,
> -  < CPG_CORE 6>, <_clk>;
> + clocks = < CPG_MOD 720>,
> +  < CPG_CORE 5>, <_clk>;

I am a little unclear why the CPG clock is changed from 6 (ZS?) to 5 (ZX?).
Could you clarify this for me?

>   clock-names = "fck", "brg_int", "scif_clk";
>   power-domains = < 32>;
>   resets = < 720>;
>   status = "disabled";
>   };
>  
> + scif2: serial@e6e58000 {
> + compatible = "renesas,scif-r8a77470",
> +  "renesas,rcar-gen2-scif", "renesas,scif";
> + reg = <0 0xe6e58000 0 0x40>;
> + interrupts = ;
> + clocks = < CPG_MOD 719>,
> +  < CPG_CORE 5>, <_clk>;
> + clock-names = "fck", "brg_int", "scif_clk";
> + power-domains = < 32>;
> + resets = < 719>;
> + status = "disabled";
> + };
> +
> + scif3: serial@e6ea8000 {
> + compatible = "renesas,scif-r8a77470",
> +  "renesas,rcar-gen2-scif", "renesas,scif";
> + reg = <0 0xe6ea8000 0 0x40>;
> + interrupts = ;
> + clocks = < CPG_MOD 718>,
> +  < CPG_CORE 5>, <_clk>;
> + clock-names = "fck", "brg_int", "scif_clk";
> + power-domains = < 32>;
> + resets = < 718>;
> + status = "disabled";
> + };
> +
> + scif4: serial@e6ee {
> + compatible = "renesas,scif-r8a77470",
> +  "renesas,rcar-gen2-scif", "renesas,scif";
> + reg = <0 0xe6ee 0 0x40>;
> + interrupts = ;
> + clocks = < CPG_MOD 715>,
> +  < CPG_CORE 5>, <_clk>;
> + clock-names = "fck", "brg_int", "scif_clk";
> + power-domains = < 32>;
> + resets = < 715>;
> + status = "disabled";
> + };
> +
> + scif5: serial@e6ee8000 {
> + compatible = "renesas,scif-r8a77470",
> +  "renesas,rcar-gen2-scif", "renesas,scif";
> + reg = <0 0xe6ee8000 0 0x40>;
> + interrupts = ;
> + clocks = < CPG_MOD 714>,
> +  < CPG_CORE 5>, <_clk>;
> + clock-names = "fck", "brg_int", "scif_clk";
> + power-domains = < 32>;
> + resets = < 714>;
> + status = "disabled";
> + };
> +
>   gic: interrupt-controller@f1001000 {
>   compatible = "arm,gic-400";
>   #interrupt-cells = <3>;
> -- 
> 2.7.4
>