Re: The failure summary report of GEN3(RCAR H3) for linux stable v4.8

[Xuan Truong Nguyen]

Hi Morimoto


About 2 thermal issue, as you already know, fix patches are
applied. These should be solved in next version.
I will understand that you are talking about t thermal issue on Gen2.  
(is that right ?)
Sorry about this, we are just report the issue still happened in v4.8. 
we also marked that

the fix patch were already posted to ML in the detail info.


About sound unbind issue, ALSA SoC framework will be cleanuped
and upgraded soon. I talked this issue with ALSA SoC Maintainer
in this LinuxCon Europe timing, and we agreed about fixup idea.
Maybe it will be solved on +2 or +3 version.

thanks for your information.

best regards
truong

Re: The failure summary report of GEN3(RCAR H3) for linux stable v4.8

[Kuninori Morimoto]

Hi

> We have tested the linux stable v4.8 for Gen3(RCAR H3).
> 
> So we would like to report the summary of the failure.

About 2 thermal issue, as you already know, fix patches are
applied. These should be solved in next version.

About sound unbind issue, ALSA SoC framework will be cleanuped
and upgraded soon. I talked this issue with ALSA SoC Maintainer
in this LinuxCon Europe timing, and we agreed about fixup idea.
Maybe it will be solved on +2 or +3 version.

Best regards
---
Kuninori Morimoto

[PATCH] ARM: dts: r8a7779: Fix DU reg property

[Laurent Pinchart]

The system uses one address cell and one size cell, not two. Fix the DU
DT node.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7779.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index b9bbcce69dfb..9d5b8fa3da8b 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -420,7 +420,7 @@
 
du: display@fff8 {
compatible = "renesas,du-r8a7779";
-   reg = <0 0xfff8 0 0x4>;
+   reg = <0xfff8 0x4>;
interrupts = ;
clocks = <_clks R8A7779_CLK_DU>;
power-domains = < R8A7779_PD_ALWAYS_ON>;
-- 
Regards,

Laurent Pinchart

[renesas-drivers:topic/gen3-latest 15/23] htmldocs: warning: jobserver unavailable: using -j1. Add '+' to parent make rule.

[kbuild test robot]

tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
topic/gen3-latest
head:   16609b0b44ac7ad775224e727c53e208336836e4
commit: c12058c404f2b908e86c6f6fe80d7112987b0941 [15/23] Merge branch 
'histogram' of https://git.ragnatech.se/linux into renesas-drivers
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

>> warning: jobserver unavailable: using -j1. Add '+' to parent make rule.
   include/linux/init.h:1: warning: no structured comments found
   include/linux/workqueue.h:392: warning: No description found for parameter 
'...'
   include/linux/workqueue.h:392: warning: Excess function parameter 'args' 
description in 'alloc_workqueue'
   include/linux/workqueue.h:413: warning: No description found for parameter 
'...'
   include/linux/workqueue.h:413: warning: Excess function parameter 'args' 
description in 'alloc_ordered_workqueue'
   include/linux/kthread.h:26: warning: No description found for parameter '...'
   kernel/sys.c:1: warning: no structured comments found
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/fence-array.h:61: warning: No description found for parameter 
'fence'
   include/sound/core.h:324: warning: No description found for parameter '...'
   include/sound/core.h:335: warning: No description found for parameter '...'
   include/sound/core.h:388: warning: No description found for parameter '...'
   include/media/media-entity.h:1054: warning: No description found for 
parameter '...'

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


.config.gz
Description: application/gzip

Re: [RFC 1/5] media: i2c: max2175: Add MAX2175 support

[Laurent Pinchart]

Hi Ramesh,

Thank you for the patch.

On Wednesday 12 Oct 2016 15:10:25 Ramesh Shanmugasundaram wrote:
> This patch adds driver support for MAX2175 chip. This is Maxim
> Integrated's RF to Bits tuner front end chip designed for software-defined
> radio solutions. This driver exposes the tuner as a sub-device instance
> with standard and custom controls to configure the device.
> 
> Signed-off-by: Ramesh Shanmugasundaram
>  ---
>  .../devicetree/bindings/media/i2c/max2175.txt  |   60 +
>  drivers/media/i2c/Kconfig  |4 +
>  drivers/media/i2c/Makefile |2 +
>  drivers/media/i2c/max2175/Kconfig  |8 +
>  drivers/media/i2c/max2175/Makefile |4 +
>  drivers/media/i2c/max2175/max2175.c| 1624 +
>  drivers/media/i2c/max2175/max2175.h|  124 ++
>  7 files changed, 1826 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt
>  create mode 100644 drivers/media/i2c/max2175/Kconfig
>  create mode 100644 drivers/media/i2c/max2175/Makefile
>  create mode 100644 drivers/media/i2c/max2175/max2175.c
>  create mode 100644 drivers/media/i2c/max2175/max2175.h
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt
> b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file mode
> 100644
> index 000..2250d5f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> @@ -0,0 +1,60 @@
> +Maxim Integrated MAX2175 RF to Bits tuner
> +-
> +
> +The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
> +RF to Bits® front-end designed for software-defined radio solutions.
> +
> +Required properties:
> +
> +- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
> +- clocks: phandle to the fixed xtal clock.
> +- clock-names: name of the fixed xtal clock.
> +- port: video interface child port node of a tuner that defines the local

As Rob pointed out in his review of patch 3/5, this isn't video.

> +  and remote endpoints. The remote endpoint is assumed to be an SDR device
> +  that is capable of receiving the digital samples from the tuner.
> +
> +Optional properties:
> +
> +- maxim,slave   : empty property indicates this is a slave of 
another
> +  master tuner. This is used to define two tuners in
> +  diversity mode (1 master, 1 slave). By default each
> +  tuner is an individual master.

Would it be useful to make that property a phandle to the master tuner, to 
give drivers a way to access the master ? I haven't checked whether there 
could be use cases for that.

> +- maxim,refout-load: load capacitance value (in pF) on reference output
> +  drive level. The mapping of these load values to
> +  respective bit values are given below.
> +  0 - Reference output disabled
> +  1 - 10pF load
> +  2 - 20pF load
> +  3 - 30pF load
> +  4 - 40pF load
> +  5 - 60pF load
> +  6 - 70pF load

As Geert pointed out, you can simply specify the value in pF.

> +
> +Example:
> +
> +
> +Board specific DTS file
> +
> +/* Fixed XTAL clock node */
> +maxim_xtal: maximextal {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <36864000>;
> +};
> +
> +/* A tuner device instance under i2c bus */
> +max2175_0: tuner@60 {
> + #clock-cells = <0>;

Is the tuner a clock provider ? If it isn't you don't need this property.

> + compatible = "maxim,max2175";
> + reg = <0x60>;
> + clocks = <_xtal>;
> + clock-names = "xtal";
> + maxim,refout-load = <10>;
> +
> + port {
> + max2175_0_ep: endpoint {
> + remote-endpoint = <_rx_v4l2_sdr_device>;
> + };
> + };
> +
> +};

[snip]

> diff --git a/drivers/media/i2c/max2175/Makefile
> b/drivers/media/i2c/max2175/Makefile new file mode 100644
> index 000..9bb46ac
> --- /dev/null
> +++ b/drivers/media/i2c/max2175/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# Makefile for Maxim RF to Bits tuner device
> +#
> +obj-$(CONFIG_SDR_MAX2175) += max2175.o

If there's a single source file you might want to move it to 
drivers/media/i2c/.

> diff --git a/drivers/media/i2c/max2175/max2175.c
> b/drivers/media/i2c/max2175/max2175.c new file mode 100644
> index 000..71b60c2
> --- /dev/null
> +++ b/drivers/media/i2c/max2175/max2175.c
> @@ -0,0 +1,1624 @@
> +/*
> + * Maxim Integrated MAX2175 RF to Bits tuner driver
> + *
> + * This driver & most of the hard coded values are based on the reference
> + * application delivered by Maxim for this chip.
> + *
> + * Copyright (C) 2016 Maxim Integrated Products
> + * Copyright (C) 2016 Renesas Electronics Corporation

Re: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20

[Laurent Pinchart]

Hi Ramesh,

Thank you for the patch.

On Wednesday 12 Oct 2016 15:10:29 Ramesh Shanmugasundaram wrote:
> This patch adds documentation for the three new SDR formats
> 
> V4L2_SDR_FMT_SCU16BE
> V4L2_SDR_FMT_SCU18BE
> V4L2_SDR_FMT_SCU20BE
> 
> Signed-off-by: Ramesh Shanmugasundaram
>  ---
>  .../media/uapi/v4l/pixfmt-sdr-scu16be.rst  | 44 ++
>  .../media/uapi/v4l/pixfmt-sdr-scu18be.rst  | 48 +++
>  .../media/uapi/v4l/pixfmt-sdr-scu20be.rst  | 48 +++
>  Documentation/media/uapi/v4l/sdr-formats.rst   |  3 ++
>  4 files changed, 143 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-scu18be.rst
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-scu20be.rst
> 
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst new file mode 100644
> index 000..d6c2123
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-scu16be.rst
> @@ -0,0 +1,44 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-SDR-FMT-SCU16BE:
> +
> +**
> +V4L2_SDR_FMT_SCU16BE ('SCU16')

The value between parentheses is the ASCII representation of the 4CC, it 
should be SC16. Same comment for the other formats.

> +**
> +
> +Sliced complex unsigned 16-bit big endian IQ sample
> +
> +
> +Description
> +===
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are represented as a 16 bit unsigned big endian number. I value
> +starts first and Q value starts at an offset equalling half of the buffer
> +size. 14 bit data is stored in 16 bit space with unused stuffed bits
> +padded with 0.

Please specify here how the 14-bit numbers are aligned (i.e. padding in bits 
15:14 or bits 1:0 or any other strange option). Same comment for the other 
formats.

> +
> +**Byte Order.**
> +Each cell is one byte.
> +
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +
> +-  .. row 1

Please use the more compact table stable

* - start + 0:
  - I'\ :sub:`0[D13:D6]`
  ...

Same comment for the other formats.

> +
> +   -  start + 0:
> +
> +   -  I'\ :sub:`0[D13:D6]`
> +
> +   -  I'\ :sub:`0[D5:D0]`
> +
> +-  .. row 2
> +
> +   -  start + buffer_size/2:
> +
> +   -  Q'\ :sub:`0[D13:D6]`
> +
> +   -  Q'\ :sub:`0[D5:D0]`

The format looks planar, does it use one V4L2 plane (as does NV12) or two V4L2 
planes (as does NV12M) ? Same question for the other formats.

> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-scu18be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-scu18be.rst new file mode 100644
> index 000..e6e0aff
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-scu18be.rst
> @@ -0,0 +1,48 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-SDR-FMT-SCU18BE:
> +
> +**
> +V4L2_SDR_FMT_SCU18BE ('SCU18')
> +**
> +
> +Sliced complex unsigned 18-bit big endian IQ sample
> +
> +
> +Description
> +===
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are represented as a 18 bit unsigned big endian number. I value
> +starts first and Q value starts at an offset equalling half of the buffer
> +size. 16 bit data is stored in 18 bit space with unused stuffed bits
> +padded with 0.

Your example below suggests that 18 bit data is stored in 24 bits. Similar 
comment for SCU20.

> +
> +**Byte Order.**
> +Each cell is one byte.
> +
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +
> +-  .. row 1
> +
> +   -  start + 0:
> +
> +   -  I'\ :sub:`0[D17:D10]`
> +
> +   -  I'\ :sub:`0[D9:D2]`
> +
> +   -  I'\ :sub:`0[D1:D0]`
> +
> +-  .. row 2
> +
> +   -  start + buffer_size/2:
> +
> +   -  Q'\ :sub:`0[D17:D10]`
> +
> +   -  Q'\ :sub:`0[D9:D2]`
> +
> +   -  Q'\ :sub:`0[D1:D0]`
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-scu20be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-scu20be.rst new file mode 100644
> index 000..374e0a3
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-scu20be.rst
> @@ -0,0 +1,48 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-SDR-FMT-SCU20BE:
> +
> +**
> +V4L2_SDR_FMT_SCU20BE ('SCU20')
> +**
> +
> +Sliced complex unsigned 20-bit big endian IQ sample
> +
> +
> +Description
> +===
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are 

Re: [PATCH 0/6] R-Car DU fixes and cleanups

[Laurent Pinchart]

Hi Tomi and Dave,

On Tuesday 04 Oct 2016 15:31:33 Laurent Pinchart wrote:
> Hello,
> 
> This patch series contains five simple cleanups and fixes for the
> rcar-du-drm driver, as well as an argument constification patch for
> video/of.
> 
> The patches themselves are straightforward, see individual commit messages
> for details. Patch 2/6 (normally merged through the DRM tree) depends on
> patch 1/6 (normally merged through the fbdev tree). As they don't conflict
> with patches 3/6 to 6/6, we can either merge the whole series through the
> DRM tree, or merge patches 1/6 and 2/6 through the fbdev tree and the rest
> through the DRM tree.
> 
> My preference would go for merging the whole series through the DRM tree to
> avoid potential conflicts with the other patches I'm working on for v4.10.
> There is no foreseen conflict at the moment, but I might rework encoder
> handling in the driver that could possibly result in a conflict. Dave, Tomi,
> any preference ? If you're fine with patches not going through your tree,
> could you please ack them ?

Ping ? Tomi, would you be fine with merging 1/6 through the DRM tree ? If so, 
could you please ack it ?

> Cc: David Airlie 
> Cc: Tomi Valkeinen 
> 
> Laurent Pinchart (6):
>   video: of: Constify node argument to display timing functions
>   drm: rcar-du: Constify node argument to rcar_du_lvds_connector_init()
>   drm: rcar-du: Bring HDMI encoder comments in line with the driver
>   drm: rcar-du: Remove test for impossible error condition
>   drm: rcar-du: Remove memory allocation error message
>   drm: rcar-du: Fix crash in encoder failure error path
> 
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c |  6 --
>  drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c |  4 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 10 +-
>  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |  4 +---
>  drivers/video/of_display_timing.c |  6 +++---
>  include/video/of_display_timing.h | 15 ---
>  8 files changed, 21 insertions(+), 28 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: The failure summary report of GEN2 for linux stable v4.8

[Laurent Pinchart]

Hello,

On Tuesday 18 Oct 2016 17:13:32 Laurent Pinchart wrote:

[snip]

> Issue 14 ("USB-CAM: Warning message appears if remove the usb-camera cable
> under using") is likely not a Renesas-specific problem, but as I'm the
> maintainer of the uvcvideo webcam driver you used for testing I'll
> investigate that.

I confirm that this issue can be reproduced on an x86 machine running v4.4.6. 
It isn't Renesas-specific.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 3/3] ARM: dts: gose: add composite video input

[Laurent Pinchart]

Hi Ulrich,

(CC'ing the device tree mailing list - for real this time)

Thank you for the patch.

On Tuesday 18 Oct 2016 17:02:23 Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm/boot/dts/r8a7793-gose.dts | 36 ++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
> b/arch/arm/boot/dts/r8a7793-gose.dts index a47ea4b..2606021 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -390,6 +390,11 @@
>   groups = "vin0_data24", "vin0_sync", "vin0_clkenb", 
"vin0_clk";
>   function = "vin0";
>   };
> +
> + vin1_pins: vin1 {
> + groups = "vin1_data8", "vin1_clk";
> + function = "vin1";
> + };
>  };
> 
>   {
> @@ -515,6 +520,19 @@
>   reg = <0x12>;
>   };
> 
> + composite-in@20 {
> + compatible = "adi,adv7180";
> + reg = <0x20>;
> + remote = <>;
> +
> + port {
> + adv7180: endpoint {
> + bus-width = <8>;
> + remote-endpoint = <>;
> + };
> + };

As explained before, you need to update the ADV7180 DT bindings first to 
document ports. I've discussed this with Hans last week, and we agreed that DT 
should model physical ports. Unfortunately the ADV7180 comes in four different 
packages with different feature sets that affect ports.

ADV7180  K CP32 Z   32-Lead Lead Frame Chip Scale Package
ADV7180  B CP32 Z   32-Lead Lead Frame Chip Scale Package
ADV7180 WB CP32 Z   32-Lead Lead Frame Chip Scale Package

ADV7180  B CP   Z   40-Lead Lead Frame Chip Scale Package
ADV7180 WB CP   Z   40-Lead Lead Frame Chip Scale Package

ADV7180  K ST48 Z   48-Lead Low Profile Quad Flat Package
ADV7180  B ST48 Z   48-Lead Low Profile Quad Flat Package
ADV7180 WB ST48 Z   48-Lead Low Profile Quad Flat Package

ADV7180  B ST   Z   64-Lead Low Profile Quad Flat Package
ADV7180 WB ST   Z   64-Lead Low Profile Quad Flat Package

W tells whether the part is qualified for automotive applications. It has no 
impact from a software point of view. K and B indicate the temperature range, 
and also have no software impact. The Z suffix indicates that the part is RoHS 
compliant (they all are) and also has no impact.

Unfortunately the W and K/B qualifiers come before the package qualifier. I'm 
not sure whether we could simply drop W, K/B and W and specify the following 
compatible strings

- adv7180cp32
- adv7180cp
- adv7180st48
- adv7180st

or if we need more compatible strings that would match the full chip name. 
Feedback on that from the device tree maintainers would be appreciated.

Regardless of what compatible strings end up being used, the bindings should 
document 3 or 6 input ports depending on the model, and one output port. You 
can number the input ports from 0 to 2 or 0 to 5 depending on the model and 
the output port 3 or 6. Another option would be to number the output port 0 
and the input ports 1 to 3 or 1 to 6 depending on the model. That would give a 
fixed number for the output port across all models, but might be a bit 
consuming as most bindings number input ports before output ports.

For the Gose board you should then add one composite connector to the device 
tree ("composite-video-connector") and connect it to port 0 of the 
ADV7180WBCP32.

> + };
> +
>   hdmi@39 {
>   compatible = "adi,adv7511w";
>   reg = <0x39>;
> @@ -622,3 +640,21 @@
>   };
>   };
>  };
> +
> +/* composite video input */
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vin1ep: endpoint {
> + remote-endpoint = <>;
> + bus-width = <8>;
> + };
> + };
> +};

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 3/3] ARM: dts: gose: add composite video input

[Laurent Pinchart]

Hi Ulrich,

(CC'ing the device tree mailing list)

Thank you for the patch.

On Tuesday 18 Oct 2016 17:02:23 Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm/boot/dts/r8a7793-gose.dts | 36 ++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
> b/arch/arm/boot/dts/r8a7793-gose.dts index a47ea4b..2606021 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -390,6 +390,11 @@
>   groups = "vin0_data24", "vin0_sync", "vin0_clkenb", 
"vin0_clk";
>   function = "vin0";
>   };
> +
> + vin1_pins: vin1 {
> + groups = "vin1_data8", "vin1_clk";
> + function = "vin1";
> + };
>  };
> 
>   {
> @@ -515,6 +520,19 @@
>   reg = <0x12>;
>   };
> 
> + composite-in@20 {
> + compatible = "adi,adv7180";
> + reg = <0x20>;
> + remote = <>;
> +
> + port {
> + adv7180: endpoint {
> + bus-width = <8>;
> + remote-endpoint = <>;
> + };
> + };

As explained before, you need to update the ADV7180 DT bindings first to 
document ports. I've discussed this with Hans last week, and we agreed that DT 
should model physical ports. Unfortunately the ADV7180 comes in four different 
packages with different feature sets that affect ports.

ADV7180  K CP32 Z   32-Lead Lead Frame Chip Scale Package
ADV7180  B CP32 Z   32-Lead Lead Frame Chip Scale Package
ADV7180 WB CP32 Z   32-Lead Lead Frame Chip Scale Package

ADV7180  B CP   Z   40-Lead Lead Frame Chip Scale Package
ADV7180 WB CP   Z   40-Lead Lead Frame Chip Scale Package

ADV7180  K ST48 Z   48-Lead Low Profile Quad Flat Package
ADV7180  B ST48 Z   48-Lead Low Profile Quad Flat Package
ADV7180 WB ST48 Z   48-Lead Low Profile Quad Flat Package

ADV7180  B ST   Z   64-Lead Low Profile Quad Flat Package
ADV7180 WB ST   Z   64-Lead Low Profile Quad Flat Package

W tells whether the part is qualified for automotive applications. It has no 
impact from a software point of view. K and B indicate the temperature range, 
and also have no software impact. The Z suffix indicates that the part is RoHS 
compliant (they all are) and also has no impact.

Unfortunately the W and K/B qualifiers come before the package qualifier. I'm 
not sure whether we could simply drop W, K/B and W and specify the following 
compatible strings

- adv7180cp32
- adv7180cp
- adv7180st48
- adv7180st

or if we need more compatible strings that would match the full chip name. 
Feedback on that from the device tree maintainers would be appreciated.

Regardless of what compatible strings end up being used, the bindings should 
document 3 or 6 input ports depending on the model, and one output port. You 
can number the input ports from 0 to 2 or 0 to 5 depending on the model and 
the output port 3 or 6. Another option would be to number the output port 0 
and the input ports 1 to 3 or 1 to 6 depending on the model. That would give a 
fixed number for the output port across all models, but might be a bit 
consuming as most bindings number input ports before output ports.

For the Gose board you should then add one composite connector to the device 
tree ("composite-video-connector") and connect it to port 0 of the 
ADV7180WBCP32.

> + };
> +
>   hdmi@39 {
>   compatible = "adi,adv7511w";
>   reg = <0x39>;
> @@ -622,3 +640,21 @@
>   };
>   };
>  };
> +
> +/* composite video input */
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vin1ep: endpoint {
> + remote-endpoint = <>;
> + bus-width = <8>;
> + };
> + };
> +};

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 2/3] ARM: dts: gose: add HDMI input

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Tuesday 18 Oct 2016 17:02:22 Ulrich Hecht wrote:
> Identical to the setup on Lager.

You probably mean on Koelsch ?

> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm/boot/dts/r8a7793-gose.dts | 64 +++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
> b/arch/arm/boot/dts/r8a7793-gose.dts index dc311eb..a47ea4b 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -253,6 +253,17 @@
>   };
>   };
> 
> + hdmi-in {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +
>   hdmi-out {
>   compatible = "hdmi-connector";
>   type = "a";

For consistency you might want to rename the hdmi-out endpoint like you did 
for Lager and Koelsch.

With that fixed,

Reviewed-by: Laurent Pinchart 

> @@ -374,6 +385,11 @@
>   groups = "audio_clk_a";
>   function = "audio_clk";
>   };
> +
> + vin0_pins: vin0 {
> + groups = "vin0_data24", "vin0_sync", "vin0_clkenb", 
"vin0_clk";
> + function = "vin0";
> + };
>  };
> 
>   {
> @@ -531,6 +547,33 @@
>   };
>   };
> 
> + hdmi-in@4c {
> + compatible = "adi,adv7612";
> + reg = <0x4c>;
> + interrupt-parent = <>;
> + interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> + default-input = <0>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7612_in: endpoint {
> + remote-endpoint = <_con_in>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + adv7612_out: endpoint {
> + remote-endpoint = <>;
> + };
> + };
> + };
> + };
> +
>   eeprom@50 {
>   compatible = "renesas,r1ex24002", "atmel,24c02";
>   reg = <0x50>;
> @@ -558,3 +601,24 @@
>   {
>   shared-pin;
>  };
> +
> +/* HDMI video input */
> + {
> + status = "okay";
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vin0ep2: endpoint {
> + remote-endpoint = <_out>;
> + bus-width = <24>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> +};

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/3] ARM: dts: r8a7793: Enable VIN0-VIN2

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Tuesday 18 Oct 2016 17:02:21 Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/arm/boot/dts/r8a7793.dtsi | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
> index a7d11b9..629d3d6 100644
> --- a/arch/arm/boot/dts/r8a7793.dtsi
> +++ b/arch/arm/boot/dts/r8a7793.dtsi
> @@ -852,6 +852,33 @@
>   status = "disabled";
>   };
> 
> + vin0: video@e6ef {
> + compatible = "renesas,vin-r8a7793", "renesas,rcar-gen2-vin";
> + reg = <0 0xe6ef 0 0x1000>;
> + interrupts = ;
> + clocks = <_clks R8A7793_CLK_VIN0>;
> + power-domains = < R8A7793_PD_ALWAYS_ON>;
> + status = "disabled";
> + };
> +
> + vin1: video@e6ef1000 {
> + compatible = "renesas,vin-r8a7793", "renesas,rcar-gen2-vin";
> + reg = <0 0xe6ef1000 0 0x1000>;
> + interrupts = ;
> + clocks = <_clks R8A7793_CLK_VIN1>;
> + power-domains = < R8A7793_PD_ALWAYS_ON>;
> + status = "disabled";
> + };
> +
> + vin2: video@e6ef2000 {
> + compatible = "renesas,vin-r8a7793", "renesas,rcar-gen2-vin";
> + reg = <0 0xe6ef2000 0 0x1000>;
> + interrupts = ;
> + clocks = <_clks R8A7793_CLK_VIN2>;
> + power-domains = < R8A7793_PD_ALWAYS_ON>;
> + status = "disabled";
> + };
> +
>   qspi: spi@e6b1 {
>   compatible = "renesas,qspi-r8a7793", "renesas,qspi";
>   reg = <0 0xe6b1 0 0x2c>;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 0/2] Renesas Lager/Koelsch HDMI input

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patches.

For the whole series,

Reviewed-by: Laurent Pinchart 

On Tuesday 18 Oct 2016 17:01:32 Ulrich Hecht wrote:
> Hi!
> 
> This series enables HDMI input on the Lager and Koelsch boards.
> It sits on renesas-next-20161017-v4.9-rc1.
> 
> I have tried to address all concerns raised by reviewers (correctly, I
> hope), see below for details.
> 
> CU
> Uli
>  
> Changes since v1:
> - modeled decoder inputs/outputs and connectors
> - removed unnecessary "remote" nodes
> - r8a7790-lager.dts: "ok" -> "okay"
> - r8a7791-koelsch.dts: set ADV7612 interrupt to GP4_2 
> 
> Hans Verkuil (1):
>   ARM: dts: koelsch: add HDMI input
> 
> William Towle (1):
>   ARM: dts: lager: Add entries for VIN HDMI input support
> 
> arch/arm/boot/dts/r8a7790-lager.dts   | 66 ++--
> arch/arm/boot/dts/r8a7791-koelsch.dts | 68 ++--
> 2 files changed, 130 insertions(+), 4 deletions(-)

-- 
Regards,

Laurent Pinchart

RE: [RFC 3/5] media: platform: rcar_drif: Add DRIF support

[Ramesh Shanmugasundaram]

Hi Rob,

Thank you for the review comments.

> Subject: Re: [RFC 3/5] media: platform: rcar_drif: Add DRIF support
> 
> On Wed, Oct 12, 2016 at 03:10:27PM +0100, Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3
> SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> >
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and
> > the tuner device, which is registered as a sub-device, determines the
> > receive sample rate and format.
> >
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF
> > acts as a slave device and the tuner device acts as a master
> > transmitting the samples. The driver allows asynchronous binding of a
> > tuner device that is registered as a v4l2 sub-device. The driver can
> > learn about the tuner it is interfaced with based on port endpoint
> > properties of the device in device tree. The V4L2 SDR device inherits
> > the controls exposed by the tuner device.
> >
> > The device can also be configured to use either one or both of the
> > data pins at runtime based on the master (tuner) configuration.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > 
> > ---
> >  .../devicetree/bindings/media/renesas,drif.txt |  109 ++
> >  drivers/media/platform/Kconfig |   25 +
> >  drivers/media/platform/Makefile|1 +
> >  drivers/media/platform/rcar_drif.c | 1534
> 
> >  4 files changed, 1669 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/media/renesas,drif.txt
> >  create mode 100644 drivers/media/platform/rcar_drif.c
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > new file mode 100644
> > index 000..24239d9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,109 @@
> > +Renesas R-Car Gen3 DRIF controller (DRIF)
> 
> Define what is DRIF here, not just in the commit text.

Agreed.

> 
> > +-
> > +
> > +Required properties:
> > +
> > +- compatible: "renesas,drif-r8a7795" if DRIF controller is a part of
> R8A7795 SoC.
> 
> renesas,r8a7795-drif would be the normal ordering.

Agreed.

> 
> > + "renesas,rcar-gen3-drif" 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
> > + followed by the generic version.
> > +
> > +- reg: offset and length of each sub-channel.
> > +- interrupts: associated with each sub-channel.
> > +- clocks: phandles and clock specifiers for each sub-channel.
> > +- clock-names: clock input name strings: "fck0", "fck1".
> > +- pinctrl-0: pin control group to be used for this controller.
> > +- pinctrl-names: must be "default".
> > +- dmas: phandles to the DMA channels for each sub-channel.
> > +- dma-names: names for the DMA channels: "rx0", "rx1".
> > +
> > +Required child nodes:
> > +-
> > +- Each DRIF channel can have one or both of the sub-channels enabled
> > +in a
> > +  setup. The sub-channels are represented as a child node. The name
> > +of the
> > +  child nodes are "sub-channel0" and "sub-channel1" respectively.
> > +Each child
> > +  node supports the "status" property only, which is used to
> > +enable/disable
> > +  the respective sub-channel.
> > +
> > +Optional properties:
> > +
> > +- port: video interface child port node of a channel that defines the
> > +local
> 
> This is an audio device, why does it have a video port?

Apologies for the wording. I intend to refer a regular port node like mentioned 
here - https://www.kernel.org/doc/Documentation/devicetree/bindings/graph.txt

> 
> > +  and remote endpoints. The remote endpoint is assumed to a tuner
> > +subdevice
> > +  endpoint.
> > +- power-domains: phandle to respective power domain.
> > +- renesas,syncmd   : sync mode
> > +0 (Frame start sync pulse mode. 1-bit width pulse
> > +   indicates start of a frame)
> > +1 (L/R sync or I2S mode) (default)
> > +- renesas,lsb-first: empty property indicates lsb bit is received
> first.
> > +When not defined msb bit is received first (default)
> > +- renesas,syncac-pol-high  : empty property indicates sync signal
> polarity.
> > +When defined, active high or high->low sync signal.
> > +When not 

RE: [RFC 1/5] media: i2c: max2175: Add MAX2175 support

[Ramesh Shanmugasundaram]

Hi Geert,

Thank you for the review. 

> Subject: Re: [RFC 1/5] media: i2c: max2175: Add MAX2175 support
> 
[...]
> 
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> > @@ -0,0 +1,60 @@
> > +Maxim Integrated MAX2175 RF to Bits tuner
> > +-
> > +
> > +The MAX2175 IC is an advanced analog/digital hybrid-radio receiver
> > +with RF to Bits® front-end designed for software-defined radio
> solutions.
> > +
> > +Required properties:
> > +
> > +- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
> > +- clocks: phandle to the fixed xtal clock.
> > +- clock-names: name of the fixed xtal clock.
> > +- port: video interface child port node of a tuner that defines the
> > +local
> > +  and remote endpoints. The remote endpoint is assumed to be an SDR
> > +device
> > +  that is capable of receiving the digital samples from the tuner.
> > +
> > +Optional properties:
> > +
> > +- maxim,slave : empty property indicates this is a slave of another
> > +master tuner. This is used to define two tuners in
> > +diversity mode (1 master, 1 slave). By default each
> > +tuner is an individual master.
> > +- maxim,refout-load: load capacitance value (in pF) on reference output
> > +drive level. The mapping of these load values to
> > +respective bit values are given below.
> > +0 - Reference output disabled
> > +1 - 10pF load
> > +2 - 20pF load
> > +3 - 30pF load
> > +4 - 40pF load
> > +5 - 60pF load
> > +6 - 70pF load
> 
> For properties involving units, usually the unit is made part of the
> property name, e.g. maxim,refout-load-pF = 40.
> This avoids confusion, and allows for extension later.

Agreed. I have modified it as

- maxim,refout-load-pF: load capacitance value (in pF) on reference
output drive level. The default is refout disabled
or no load. The possible load values are 
10pF
20pF
30pF
40pF
60pF
70pF

> 
> > +/* A tuner device instance under i2c bus */
> > +max2175_0: tuner@60 {
> > +   #clock-cells = <0>;
> > +   compatible = "maxim,max2175";
> > +   reg = <0x60>;
> > +   clocks = <_xtal>;
> > +   clock-names = "xtal";
> > +   maxim,refout-load = <10>;
> 
> 10 is not listed above. Perhaps you meant 10 pF?

Yes.

> 
> > --- /dev/null
> > +++ b/drivers/media/i2c/max2175/max2175.c
> > @@ -0,0 +1,1624 @@
> 
> > +/* NOTE: Any addition/deletion in the below list should be reflected
> > +in
> > + * max2175_modetag enum
> > + */
> 
> You can drop the above comment if you make this explicit using C99
> designated initializers, cfr. below.
> 
> > +static const struct max2175_rxmode eu_rx_modes[] = { /* Indexed by EU
> modetag */
> > +   /* EU modes */
> > +   { MAX2175_BAND_VHF, 18264, 0, { 0, 0, 0, 0 } },
> 
> [MAX2175_DAB_1_2] = { MAX2175_BAND_VHF, 18264, 0, { 0, 0, 0, 0 } },
> 
> > +};
> > +
> > +static const struct max2175_rxmode na_rx_modes[] = { /* Indexed by NA
> modetag */
> > +   /* NA modes */
> > +   { MAX2175_BAND_FM, 98255520, 1, { 0, 0, 0, 0 } },
> 
> [MAX2175_NA_FM_1_0] = { MAX2175_BAND_FM, 98255520, 1, { 0, 0, 0, 0 } },
> 

Thank you. Using designated initializers now.

> > +struct max2175_ctx {
> > +   struct v4l2_subdev sd;
> > +   struct i2c_client *client;
> > +   struct device *dev;
> > +
> > +   /* Cached configuration */
> > +   u8 regs[256];
> > +   enum max2175_modetag mode;  /* Receive mode tag */
> > +   u32 freq;   /* In Hz */
> > +   struct max2175_rxmode *rx_modes;
> > +
> > +   /* Device settings */
> > +   bool master;
> > +   u32 decim_ratio;
> > +   u64 xtal_freq;
> > +
> > +   /* ROM values */
> > +   u8 rom_bbf_bw_am;
> > +   u8 rom_bbf_bw_fm;
> > +   u8 rom_bbf_bw_dab;
> > +
> > +   /* Local copy of old settings */
> > +   u8 i2s_test;
> > +
> > +   u8 nbd_gain;
> > +   u8 nbd_threshold;
> > +   u8 wbd_gain;
> > +   u8 wbd_threshold;
> > +   u8 bbd_threshold;
> > +   u8 bbdclip_threshold;
> > +   u8 lt_wbd_threshold;
> > +   u8 lt_wbd_gain;
> > +
> > +   /* Controls */
> > +   struct v4l2_ctrl_handler ctrl_hdl;
> > +   struct v4l2_ctrl *lna_gain; /* LNA gain value */
> > +   struct v4l2_ctrl *if_gain;  /* I/F gain value */
> > +   struct v4l2_ctrl *pll_lock; /* PLL lock */
> > +   struct v4l2_ctrl *i2s_en;   /* I2S output enable */
> > +   struct v4l2_ctrl *i2s_mode; /* I2S mode value */
> > +   struct v4l2_ctrl 

[PATCH v2 2/3] ARM: dts: gose: add HDMI input

[Ulrich Hecht]

Identical to the setup on Lager.

Signed-off-by: Ulrich Hecht 
---
 arch/arm/boot/dts/r8a7793-gose.dts | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index dc311eb..a47ea4b 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -253,6 +253,17 @@
};
};
 
+   hdmi-in {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+
hdmi-out {
compatible = "hdmi-connector";
type = "a";
@@ -374,6 +385,11 @@
groups = "audio_clk_a";
function = "audio_clk";
};
+
+   vin0_pins: vin0 {
+   groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk";
+   function = "vin0";
+   };
 };
 
  {
@@ -531,6 +547,33 @@
};
};
 
+   hdmi-in@4c {
+   compatible = "adi,adv7612";
+   reg = <0x4c>;
+   interrupt-parent = <>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+   default-input = <0>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7612_in: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   adv7612_out: endpoint {
+   remote-endpoint = <>;
+   };
+   };
+   };
+   };
+
eeprom@50 {
compatible = "renesas,r1ex24002", "atmel,24c02";
reg = <0x50>;
@@ -558,3 +601,24 @@
  {
shared-pin;
 };
+
+/* HDMI video input */
+ {
+   status = "okay";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vin0ep2: endpoint {
+   remote-endpoint = <_out>;
+   bus-width = <24>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   data-active = <1>;
+   };
+   };
+};
-- 
2.7.4

[PATCH v2 1/3] ARM: dts: r8a7793: Enable VIN0-VIN2

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 arch/arm/boot/dts/r8a7793.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index a7d11b9..629d3d6 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -852,6 +852,33 @@
status = "disabled";
};
 
+   vin0: video@e6ef {
+   compatible = "renesas,vin-r8a7793", "renesas,rcar-gen2-vin";
+   reg = <0 0xe6ef 0 0x1000>;
+   interrupts = ;
+   clocks = <_clks R8A7793_CLK_VIN0>;
+   power-domains = < R8A7793_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   vin1: video@e6ef1000 {
+   compatible = "renesas,vin-r8a7793", "renesas,rcar-gen2-vin";
+   reg = <0 0xe6ef1000 0 0x1000>;
+   interrupts = ;
+   clocks = <_clks R8A7793_CLK_VIN1>;
+   power-domains = < R8A7793_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   vin2: video@e6ef2000 {
+   compatible = "renesas,vin-r8a7793", "renesas,rcar-gen2-vin";
+   reg = <0 0xe6ef2000 0 0x1000>;
+   interrupts = ;
+   clocks = <_clks R8A7793_CLK_VIN2>;
+   power-domains = < R8A7793_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
qspi: spi@e6b1 {
compatible = "renesas,qspi-r8a7793", "renesas,qspi";
reg = <0 0xe6b1 0 0x2c>;
-- 
2.7.4

[PATCH v2 0/3] r8a7793 Gose video input support

[Ulrich Hecht]

Hi!

This is a by-the-datasheet implementation of analog and digital video input
on the Gose board.

I have tried to address all concerns raised by reviewers, with the exception
of the composite input patch, which has been left as is for now.

CU
Uli


Changes since v1:
- r8a7793.dtsi: added VIN2
- modeled HDMI decoder input/output and connector
- added "renesas,rcar-gen2-vin" compat strings
- removed unnecessary "remote" node and aliases
- set ADV7612 interrupt to GP4_2


Ulrich Hecht (3):
  ARM: dts: r8a7793: Enable VIN0-VIN2
  ARM: dts: gose: add HDMI input
  ARM: dts: gose: add composite video input

 arch/arm/boot/dts/r8a7793-gose.dts | 100 +
 arch/arm/boot/dts/r8a7793.dtsi |  27 ++
 2 files changed, 127 insertions(+)

-- 
2.7.4

[PATCH v2 3/3] ARM: dts: gose: add composite video input

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 arch/arm/boot/dts/r8a7793-gose.dts | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index a47ea4b..2606021 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -390,6 +390,11 @@
groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk";
function = "vin0";
};
+
+   vin1_pins: vin1 {
+   groups = "vin1_data8", "vin1_clk";
+   function = "vin1";
+   };
 };
 
  {
@@ -515,6 +520,19 @@
reg = <0x12>;
};
 
+   composite-in@20 {
+   compatible = "adi,adv7180";
+   reg = <0x20>;
+   remote = <>;
+
+   port {
+   adv7180: endpoint {
+   bus-width = <8>;
+   remote-endpoint = <>;
+   };
+   };
+   };
+
hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
@@ -622,3 +640,21 @@
};
};
 };
+
+/* composite video input */
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vin1ep: endpoint {
+   remote-endpoint = <>;
+   bus-width = <8>;
+   };
+   };
+};
-- 
2.7.4

[PATCH v2 2/2] ARM: dts: koelsch: add HDMI input

[Ulrich Hecht]

From: Hans Verkuil 

Add support in the dts for the HDMI input. Based on the Lager dts
patch from Ultich Hecht.

Signed-off-by: Hans Verkuil 
[uli: removed "renesas," prefixes from pfc nodes]
Signed-off-by: Ulrich Hecht 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 68 +--
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index f17bfa0..c457b43 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -265,12 +265,23 @@
};
};
 
+   hdmi-in {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+
hdmi-out {
compatible = "hdmi-connector";
type = "a";
 
port {
-   hdmi_con: endpoint {
+   hdmi_con_out: endpoint {
remote-endpoint = <_out>;
};
};
@@ -414,6 +425,11 @@
function = "usb1";
};
 
+   vin0_pins: vin0 {
+   groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk";
+   function = "vin0";
+   };
+
vin1_pins: vin1 {
groups = "vin1_data8", "vin1_clk";
function = "vin1";
@@ -617,7 +633,34 @@
port@1 {
reg = <1>;
adv7511_out: endpoint {
-   remote-endpoint = <_con>;
+   remote-endpoint = <_con_out>;
+   };
+   };
+   };
+   };
+
+   hdmi-in@4c {
+   compatible = "adi,adv7612";
+   reg = <0x4c>;
+   interrupt-parent = <>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+   default-input = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7612_in: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   adv7612_out: endpoint {
+   remote-endpoint = <>;
};
};
};
@@ -699,6 +742,27 @@
cpu0-supply = <_dvfs>;
 };
 
+/* HDMI video input */
+ {
+   status = "okay";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vin0ep2: endpoint {
+   remote-endpoint = <_out>;
+   bus-width = <24>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   data-active = <1>;
+   };
+   };
+};
+
 /* composite video input */
  {
status = "okay";
-- 
2.7.4

[PATCH v2 0/2] Renesas Lager/Koelsch HDMI input

[Ulrich Hecht]

Hi!

This series enables HDMI input on the Lager and Koelsch boards.
It sits on renesas-next-20161017-v4.9-rc1.

I have tried to address all concerns raised by reviewers (correctly, I hope),
see below for details.

CU
Uli


Changes since v1:
- modeled decoder inputs/outputs and connectors
- removed unnecessary "remote" nodes
- r8a7790-lager.dts: "ok" -> "okay"
- r8a7791-koelsch.dts: set ADV7612 interrupt to GP4_2


Hans Verkuil (1):
  ARM: dts: koelsch: add HDMI input

William Towle (1):
  ARM: dts: lager: Add entries for VIN HDMI input support

 arch/arm/boot/dts/r8a7790-lager.dts   | 66 --
 arch/arm/boot/dts/r8a7791-koelsch.dts | 68 +--
 2 files changed, 130 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH v2 1/2] ARM: dts: lager: Add entries for VIN HDMI input support

[Ulrich Hecht]

From: William Towle 

Add DT entries for vin0, vin0_pins, and adv7612.

Sets the 'default-input' property for ADV7612, enabling image and video
capture without the need to have userspace specifying routing.

Signed-off-by: William Towle 
Signed-off-by: Rob Taylor 
[uli: added interrupt, renamed endpoint, merged default-input]
Signed-off-by: Ulrich Hecht 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 66 +++--
 1 file changed, 64 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 52b56fc..4342682 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -231,12 +231,23 @@
};
};
 
+   hdmi-in {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+
hdmi-out {
compatible = "hdmi-connector";
type = "a";
 
port {
-   hdmi_con: endpoint {
+   hdmi_con_out: endpoint {
remote-endpoint = <_out>;
};
};
@@ -427,6 +438,11 @@
function = "usb2";
};
 
+   vin0_pins: vin0 {
+   groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk";
+   function = "vin0";
+   };
+
vin1_pins: vin1 {
groups = "vin1_data8", "vin1_clk";
function = "vin1";
@@ -646,7 +662,34 @@
port@1 {
reg = <1>;
adv7511_out: endpoint {
-   remote-endpoint = <_con>;
+   remote-endpoint = <_con_out>;
+   };
+   };
+   };
+   };
+
+   hdmi-in@4c {
+   compatible = "adi,adv7612";
+   reg = <0x4c>;
+   interrupt-parent = <>;
+   interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+   default-input = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7612_in: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   adv7612_out: endpoint {
+   remote-endpoint = <>;
};
};
};
@@ -722,6 +765,25 @@
status = "okay";
 };
 
+/* HDMI video input */
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+
+   port {
+   vin0ep2: endpoint {
+   remote-endpoint = <_out>;
+   bus-width = <24>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   pclk-sample = <1>;
+   data-active = <1>;
+   };
+   };
+};
+
 /* composite video input */
  {
pinctrl-0 = <_pins>;
-- 
2.7.4

Re: [RFC 3/5] media: platform: rcar_drif: Add DRIF support

[Geert Uytterhoeven]

Hi Ramesh,

On Wed, Oct 12, 2016 at 4:10 PM, Ramesh Shanmugasundaram
 wrote:
> This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
> The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> device represents a channel and each channel can have one or two
> sub-channels respectively depending on the target board.
>
> DRIF supports only Rx functionality. It receives samples from a RF
> frontend tuner chip it is interfaced with. The combination of DRIF and the
> tuner device, which is registered as a sub-device, determines the receive
> sample rate and format.
>
> In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> the tuner device, which can be provided by a third party vendor. DRIF acts
> as a slave device and the tuner device acts as a master transmitting the
> samples. The driver allows asynchronous binding of a tuner device that
> is registered as a v4l2 sub-device. The driver can learn about the tuner
> it is interfaced with based on port endpoint properties of the device in
> device tree. The V4L2 SDR device inherits the controls exposed by the
> tuner device.
>
> The device can also be configured to use either one or both of the data
> pins at runtime based on the master (tuner) configuration.

Thanks for your patch!

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> @@ -0,0 +1,109 @@
> +Renesas R-Car Gen3 DRIF controller (DRIF)
> +-
> +
> +Required properties:
> +
> +- compatible: "renesas,drif-r8a7795" if DRIF controller is a part of R8A7795 
> SoC.

"renesas,r8a7795-drif", as Rob already pointed out.

> + "renesas,rcar-gen3-drif" 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
> + followed by the generic version.
> +
> +- reg: offset and length of each sub-channel.
> +- interrupts: associated with each sub-channel.
> +- clocks: phandles and clock specifiers for each sub-channel.
> +- clock-names: clock input name strings: "fck0", "fck1".
> +- pinctrl-0: pin control group to be used for this controller.
> +- pinctrl-names: must be "default".
> +- dmas: phandles to the DMA channels for each sub-channel.
> +- dma-names: names for the DMA channels: "rx0", "rx1".
> +
> +Required child nodes:
> +-
> +- Each DRIF channel can have one or both of the sub-channels enabled in a
> +  setup. The sub-channels are represented as a child node. The name of the
> +  child nodes are "sub-channel0" and "sub-channel1" respectively. Each child
> +  node supports the "status" property only, which is used to enable/disable
> +  the respective sub-channel.

> +Example
> +
> +
> +SoC common dtsi file
> +
> +drif0: rif@e6f4 {
> +   compatible = "renesas,drif-r8a7795",
> +  "renesas,rcar-gen3-drif";
> +   reg = <0 0xe6f4 0 0x64>, <0 0xe6f5 0 0x64>;
> +   interrupts = ,
> +  ;
> +   clocks = < CPG_MOD 515>, < CPG_MOD 514>;
> +   clock-names = "fck0", "fck1";
> +   dmas = < 0x20>, < 0x22>;
> +   dma-names = "rx0", "rx1";

I could not find the DMAC channels in the datasheet?
Most modules are either tied to dmac0, or two both dmac1 and dmac2.
In the latter case, you want to list two sets of dmas, one for each DMAC.

> +   power-domains = < R8A7795_PD_ALWAYS_ON>;
> +   status = "disabled";
> +
> +   sub-channel0 {
> +   status = "disabled";
> +   };
> +
> +   sub-channel1 {
> +   status = "disabled";
> +   };
> +
> +};

As you're modelling this in DT under a single device node, this means you
cannot use runtime PM to manage the module clocks of the individual channels.

An alternative could be to have two separate nodes for each channel,
and tie them together using a phandle.

Gr{oetje,eeting}s,

Geert

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

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

renesas-drivers-2016-10-18-v4.9-rc1

[Geert Uytterhoeven]

I have pushed renesas-drivers-2016-10-18-v4.9-rc1 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

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

As we are currently focusing on a stable v4.9, no for-next branches
of various subsystem trees have been included.

Today's version is based on renesas-devel-20161017-v4.9-rc1.

Included branches with driver code:
  - clk-renesas-for-v4.10
  - sh-pfc-for-v4.10
  - topic/rcar-secondary-booting-in-debug-mode-v1-rebased1
  - topic/renesas-soc-id-v1-rebased1
  - topic/r8a7796-ravb-v1-rebased1
  - topic/r8a7796-dmac-driver-v1-rebased2
  - topic/r8a7796-dmac-dts-v1-rebased2~3
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/sdr104-driver-v7
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/sdr104-integration-v7
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/sdr104-v7
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#renesas/topic/sdhi-8bit-emmc
  - topic/vin-gen2-driver-v1-rebased2
  - topic/rcar-du-lvds-mode-selection-v1
  - topic/rcar-gen3-usb2-role-swap-v1
  - https://git.ragnatech.se/linux#histogram
  - git://linuxtv.org/pinchartl/media.git#iommu/devel/du
  - topic/ipmmu-multi-arch-v5-rebased1
  - topic/r8a7795-ipmmu-v2-rebased3
  - topic/r8a7796-ipmmu-v1-rebased3
  - topic/salvator-x-ipmmu-rfc-v3-rebased4~1
  - topic/vin-gen2-dts-v1-rebased2
  - topic/r8a7795-es2-v1-rebased1

Included fixes:
  - tty: serial_core: Move uart_console() check after console registration

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] [media] v4l: rcar-fcp: Don't force users to check for disabled FCP support

[Laurent Pinchart]

Hi Greg,

On Tuesday 18 Oct 2016 16:05:21 Greg KH wrote:
> On Tue, Oct 18, 2016 at 04:24:20PM +0300, Laurent Pinchart wrote:
> > commit fd44aa9a254b18176ec3792a18e7de6977030ca8 upstream.
> > 
> > The rcar_fcp_enable() function immediately returns successfully when the
> > FCP device pointer is NULL to avoid forcing the users to check the FCP
> > device manually before every call. However, the stub version of the
> > function used when the FCP driver is disabled returns -ENOSYS
> > unconditionally, resulting in a different API contract for the two
> > versions of the function.
> > 
> > As a user that requires FCP support will fail at probe time when calling
> > rcar_fcp_get() if the FCP driver is disabled, the stub version of the
> > rcar_fcp_enable() function will only be called with a NULL FCP device.
> > We can thus return 0 unconditionally to align the behaviour with the
> > normal version of the function.
> > 
> > Fixes: 94fcdf829793 ("[media] v4l: vsp1: Add FCP support")
> > Reported-by: Sergei Shtylyov 
> > Signed-off-by: Laurent Pinchart
> > 
> > Reviewed-by: Geert Uytterhoeven 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> > 
> >  include/media/rcar-fcp.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> What stable kernel(s) do you want this applied to?

That's for v4.8, sorry for not having mentioned it.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] [media] v4l: rcar-fcp: Don't force users to check for disabled FCP support

[Greg KH]

On Tue, Oct 18, 2016 at 04:24:20PM +0300, Laurent Pinchart wrote:
> commit fd44aa9a254b18176ec3792a18e7de6977030ca8 upstream.
> 
> The rcar_fcp_enable() function immediately returns successfully when the
> FCP device pointer is NULL to avoid forcing the users to check the FCP
> device manually before every call. However, the stub version of the
> function used when the FCP driver is disabled returns -ENOSYS
> unconditionally, resulting in a different API contract for the two
> versions of the function.
> 
> As a user that requires FCP support will fail at probe time when calling
> rcar_fcp_get() if the FCP driver is disabled, the stub version of the
> rcar_fcp_enable() function will only be called with a NULL FCP device.
> We can thus return 0 unconditionally to align the behaviour with the
> normal version of the function.
> 
> Fixes: 94fcdf829793 ("[media] v4l: vsp1: Add FCP support")
> Reported-by: Sergei Shtylyov 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Geert Uytterhoeven 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  include/media/rcar-fcp.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

What stable kernel(s) do you want this applied to?

thanks,

greg k-h

[PATCH] [media] v4l: rcar-fcp: Don't force users to check for disabled FCP support

[Laurent Pinchart]

commit fd44aa9a254b18176ec3792a18e7de6977030ca8 upstream.

The rcar_fcp_enable() function immediately returns successfully when the
FCP device pointer is NULL to avoid forcing the users to check the FCP
device manually before every call. However, the stub version of the
function used when the FCP driver is disabled returns -ENOSYS
unconditionally, resulting in a different API contract for the two
versions of the function.

As a user that requires FCP support will fail at probe time when calling
rcar_fcp_get() if the FCP driver is disabled, the stub version of the
rcar_fcp_enable() function will only be called with a NULL FCP device.
We can thus return 0 unconditionally to align the behaviour with the
normal version of the function.

Fixes: 94fcdf829793 ("[media] v4l: vsp1: Add FCP support")
Reported-by: Sergei Shtylyov 
Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/rcar-fcp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/media/rcar-fcp.h b/include/media/rcar-fcp.h
index 4c7fc77eaf29..8723f05c6321 100644
--- a/include/media/rcar-fcp.h
+++ b/include/media/rcar-fcp.h
@@ -29,7 +29,7 @@ static inline struct rcar_fcp_device *rcar_fcp_get(const 
struct device_node *np)
 static inline void rcar_fcp_put(struct rcar_fcp_device *fcp) { }
 static inline int rcar_fcp_enable(struct rcar_fcp_device *fcp)
 {
-   return -ENOSYS;
+   return 0;
 }
 static inline void rcar_fcp_disable(struct rcar_fcp_device *fcp) { }
 #endif
-- 
Regards,

Laurent Pinchart

Re: The failure summary report of GEN2 for linux stable v4.8

[Wolfram Sang]

Hi all,

> We have tested the linux stable v4.8 for Gen2 Koelsch and Lager


So we would like to report the summary of the failure.


Thank you!

Is it possible to get access to the full logfiles? I am especially 
interested in the backtraces after the Kernel oops or warning.


Kind regards,

   Wolfram

Re: [RFC 3/5] media: platform: rcar_drif: Add DRIF support

[Rob Herring]

On Wed, Oct 12, 2016 at 03:10:27PM +0100, Ramesh Shanmugasundaram wrote:
> This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
> The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> device represents a channel and each channel can have one or two
> sub-channels respectively depending on the target board.
> 
> DRIF supports only Rx functionality. It receives samples from a RF
> frontend tuner chip it is interfaced with. The combination of DRIF and the
> tuner device, which is registered as a sub-device, determines the receive
> sample rate and format.
> 
> In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> the tuner device, which can be provided by a third party vendor. DRIF acts
> as a slave device and the tuner device acts as a master transmitting the
> samples. The driver allows asynchronous binding of a tuner device that
> is registered as a v4l2 sub-device. The driver can learn about the tuner
> it is interfaced with based on port endpoint properties of the device in
> device tree. The V4L2 SDR device inherits the controls exposed by the
> tuner device.
> 
> The device can also be configured to use either one or both of the data
> pins at runtime based on the master (tuner) configuration.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
>  .../devicetree/bindings/media/renesas,drif.txt |  109 ++
>  drivers/media/platform/Kconfig |   25 +
>  drivers/media/platform/Makefile|1 +
>  drivers/media/platform/rcar_drif.c | 1534 
> 
>  4 files changed, 1669 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
>  create mode 100644 drivers/media/platform/rcar_drif.c
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt 
> b/Documentation/devicetree/bindings/media/renesas,drif.txt
> new file mode 100644
> index 000..24239d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> @@ -0,0 +1,109 @@
> +Renesas R-Car Gen3 DRIF controller (DRIF)

Define what is DRIF here, not just in the commit text.

> +-
> +
> +Required properties:
> +
> +- compatible: "renesas,drif-r8a7795" if DRIF controller is a part of R8A7795 
> SoC.

renesas,r8a7795-drif would be the normal ordering.

> +   "renesas,rcar-gen3-drif" 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
> +   followed by the generic version.
> +
> +- reg: offset and length of each sub-channel.
> +- interrupts: associated with each sub-channel.
> +- clocks: phandles and clock specifiers for each sub-channel.
> +- clock-names: clock input name strings: "fck0", "fck1".
> +- pinctrl-0: pin control group to be used for this controller.
> +- pinctrl-names: must be "default".
> +- dmas: phandles to the DMA channels for each sub-channel.
> +- dma-names: names for the DMA channels: "rx0", "rx1".
> +
> +Required child nodes:
> +-
> +- Each DRIF channel can have one or both of the sub-channels enabled in a
> +  setup. The sub-channels are represented as a child node. The name of the
> +  child nodes are "sub-channel0" and "sub-channel1" respectively. Each child
> +  node supports the "status" property only, which is used to enable/disable
> +  the respective sub-channel.
> +
> +Optional properties:
> +
> +- port: video interface child port node of a channel that defines the local

This is an audio device, why does it have a video port?

> +  and remote endpoints. The remote endpoint is assumed to a tuner subdevice
> +  endpoint.
> +- power-domains: phandle to respective power domain.
> +- renesas,syncmd   : sync mode
> +  0 (Frame start sync pulse mode. 1-bit width pulse
> + indicates start of a frame)
> +  1 (L/R sync or I2S mode) (default)
> +- renesas,lsb-first: empty property indicates lsb bit is received first.
> +  When not defined msb bit is received first (default)
> +- renesas,syncac-pol-high  : empty property indicates sync signal polarity.
> +  When defined, active high or high->low sync signal.
> +  When not defined, active low or low->high sync signal
> +  (default)
> +- renesas,dtdl : delay between sync signal and start of reception.
> +  Must contain one of the following values:
> +  0   (no bit delay)
> +  50  (0.5-clock-cycle delay)
> +  100 (1-clock-cycle delay) (default)
> +  150 (1.5-clock-cycle delay)
> +  200 (2-clock-cycle delay)
> +- 

Re: [PATCH 3/4] arm64: dts: renesas: r8a7796: Add DU device to DT

[Laurent Pinchart]

Hi Simon,

On Tuesday 18 Oct 2016 11:05:32 Geert Uytterhoeven wrote:
> On Mon, Oct 17, 2016 at 11:34 PM, Laurent Pinchart wrote:
> > Add the DU device to r8a7796.dtsi in a disabled state.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> 
> Reviewed-by: Geert Uytterhoeven 

Could you please pick patches 1/4 to 3/4 from this series and apply them to 
your tree ? For convenience I've pushed them to

git://linuxtv.org/pinchartl/media.git drm/r8a7796/dt

along with patch "arm64: dts: renesas: r8a7795: Remove FCP SoC-specific 
compatible strings" that has been acked too. If you pull from that branch 
please make sure you skip the top-most patch "arm64: dts: renesas: r8a7796-
salvator-x: Enable DU" for now.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 3/4] arm64: dts: renesas: r8a7796: Add DU device to DT

[Geert Uytterhoeven]

On Mon, Oct 17, 2016 at 11:34 PM, Laurent Pinchart
 wrote:
> Add the DU device to r8a7796.dtsi in a disabled state.
>
> 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/3] clk: renesas: r8a7796: Add DU and LVDS clocks

[Geert Uytterhoeven]

On Mon, Oct 17, 2016 at 11:12 PM, Laurent Pinchart
 wrote:
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Geert Uytterhoeven 

> ---
>  drivers/clk/renesas/r8a7796-cpg-mssr.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c 
> b/drivers/clk/renesas/r8a7796-cpg-mssr.c
> index 679054658f99..20bd0643b238 100644
> --- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
> +++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
> @@ -134,6 +134,10 @@ static const struct mssr_mod_clk r8a7796_mod_clks[] 
> __initconst = {
> DEF_MOD("vspd0", 623,   R8A7796_CLK_S0D2),
> DEF_MOD("vspb",  626,   R8A7796_CLK_S0D1),
> DEF_MOD("vspi0", 631,   R8A7796_CLK_S0D1),
> +   DEF_MOD("du2",   722,   R8A7796_CLK_S0D2),
> +   DEF_MOD("du1",   723,   R8A7796_CLK_S0D2),
> +   DEF_MOD("du0",   724,   R8A7796_CLK_S0D2),

I'll fix up the DU parent clock to S2D1 now we got confirmation.

> +   DEF_MOD("lvds",  727,   R8A7796_CLK_S0D4),

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/3] clk: renesas: r8a7796: Add VSP clocks

[Geert Uytterhoeven]

On Mon, Oct 17, 2016 at 11:12 PM, Laurent Pinchart
 wrote:
> 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/3] clk: renesas: r8a7796: Add FCP clocks

[Geert Uytterhoeven]

On Mon, Oct 17, 2016 at 11:12 PM, Laurent Pinchart
 wrote:
> 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

[PATCH v2 3/3] clk: renesas: r8a7796: Add DU and LVDS clocks

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Updated the DU* parent clocks to S2D1
---
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c 
b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index 679054658f99..c1af1ec1bcaa 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -134,6 +134,10 @@ static const struct mssr_mod_clk r8a7796_mod_clks[] 
__initconst = {
DEF_MOD("vspd0", 623,   R8A7796_CLK_S0D2),
DEF_MOD("vspb",  626,   R8A7796_CLK_S0D1),
DEF_MOD("vspi0", 631,   R8A7796_CLK_S0D1),
+   DEF_MOD("du2",   722,   R8A7796_CLK_S2D1),
+   DEF_MOD("du1",   723,   R8A7796_CLK_S2D1),
+   DEF_MOD("du0",   724,   R8A7796_CLK_S2D1),
+   DEF_MOD("lvds",  727,   R8A7796_CLK_S0D4),
DEF_MOD("etheravb",  812,   R8A7796_CLK_S0D6),
DEF_MOD("gpio7", 905,   R8A7796_CLK_S3D4),
DEF_MOD("gpio6", 906,   R8A7796_CLK_S3D4),
-- 
Regards,

Laurent Pinchart

[PATCH v2 2/3] clk: renesas: r8a7796: Add VSP clocks

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c 
b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index 41a3677a4b3a..679054658f99 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -129,6 +129,11 @@ static const struct mssr_mod_clk r8a7796_mod_clks[] 
__initconst = {
DEF_MOD("fcpf0", 615,   R8A7796_CLK_S0D1),
DEF_MOD("fcpci0",617,   R8A7796_CLK_S0D1),
DEF_MOD("fcpcs", 619,   R8A7796_CLK_S0D1),
+   DEF_MOD("vspd2", 621,   R8A7796_CLK_S0D2),
+   DEF_MOD("vspd1", 622,   R8A7796_CLK_S0D2),
+   DEF_MOD("vspd0", 623,   R8A7796_CLK_S0D2),
+   DEF_MOD("vspb",  626,   R8A7796_CLK_S0D1),
+   DEF_MOD("vspi0", 631,   R8A7796_CLK_S0D1),
DEF_MOD("etheravb",  812,   R8A7796_CLK_S0D6),
DEF_MOD("gpio7", 905,   R8A7796_CLK_S3D4),
DEF_MOD("gpio6", 906,   R8A7796_CLK_S3D4),
-- 
Regards,

Laurent Pinchart

[PATCH v2 1/3] clk: renesas: r8a7796: Add FCP clocks

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c 
b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index eb347ed265f2..41a3677a4b3a 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -121,6 +121,14 @@ static const struct mssr_mod_clk r8a7796_mod_clks[] 
__initconst = {
DEF_MOD("rwdt0", 402,   R8A7796_CLK_R),
DEF_MOD("intc-ap",   408,   R8A7796_CLK_S3D1),
DEF_MOD("thermal",   522,   R8A7796_CLK_CP),
+   DEF_MOD("fcpvd2",601,   R8A7796_CLK_S0D2),
+   DEF_MOD("fcpvd1",602,   R8A7796_CLK_S0D2),
+   DEF_MOD("fcpvd0",603,   R8A7796_CLK_S0D2),
+   DEF_MOD("fcpvb0",607,   R8A7796_CLK_S0D1),
+   DEF_MOD("fcpvi0",611,   R8A7796_CLK_S0D1),
+   DEF_MOD("fcpf0", 615,   R8A7796_CLK_S0D1),
+   DEF_MOD("fcpci0",617,   R8A7796_CLK_S0D1),
+   DEF_MOD("fcpcs", 619,   R8A7796_CLK_S0D1),
DEF_MOD("etheravb",  812,   R8A7796_CLK_S0D6),
DEF_MOD("gpio7", 905,   R8A7796_CLK_S3D4),
DEF_MOD("gpio6", 906,   R8A7796_CLK_S3D4),
-- 
Regards,

Laurent Pinchart

[PATCH v2 0/3] R-Car M3-W: Add FCP, VSP and DU clocks

[Laurent Pinchart]

Hello,

This patch series adds all the r8a7796 FCP, VSP and DU clocks. This includes
not only all the clocks required for display, but also the FCPC, FCPF, VSPB
and VSPI0 clocks to cover all the FCP and VSP instances.

The FCPC parent clocks haven't been confirmed yet.

Laurent Pinchart (3):
  clk: renesas: r8a7796: Add FCP clocks
  clk: renesas: r8a7796: Add VSP clocks
  clk: renesas: r8a7796: Add DU and LVDS clocks

 drivers/clk/renesas/r8a7796-cpg-mssr.c | 17 +
 1 file changed, 17 insertions(+)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] dt-bindings: media: renesas-fcp: Remove SoC-specific compatible strings

[Geert Uytterhoeven]

On Mon, Oct 17, 2016 at 10:29 PM, Laurent Pinchart
 wrote:
> The FCP IP cores include a version register that identifies which SoC
> model the IP is integrated in. SoC-specific compatible strings are not
> needed.
>
> Signed-off-by: Laurent Pinchart 

Acked-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/2] arm64: dts: r8a7795: Remove FCP SoC-specific compatible strings

[Geert Uytterhoeven]

On Mon, Oct 17, 2016 at 10:29 PM, Laurent Pinchart
 wrote:
> The SoC-specific compatible strings have been removed from the FCP DT
> bindings, removed them from the device tree.
>
> 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] phy: rcar-gen3-usb2: add sysfs for usb role swap

[Geert Uytterhoeven]

Hi Shimoda-san,

On Tue, Oct 18, 2016 at 8:19 AM, Yoshihiro Shimoda
 wrote:
>> From: geert.uytterhoe...@gmail.com
>> Sent: Monday, October 17, 2016 9:28 PM
>> On Mon, Oct 17, 2016 at 9:10 AM, Yoshihiro Shimoda
>>  wrote:
>> > This patch adds sysfs "otg_inputs" for usb role swap. This parameter
>> > is write-only and if you use them as the following, you can swap
>> > the usb role.
>>
>> Thank you for your patch!
>
> Thank you for the review!
>
>> > For example:
>> >  1) connect a usb cable using 2 salvator-x boards
>> >  2) On A-device (as host), you input the following command:
>> ># echo a_bus_req/ > 
>> > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs
>> >  3) On B-device (as peripheral), you input the following command:
>> ># echo b_bus_req > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs
>>
>> At first, I thought the trailing "/" was a typo...
>>
>> > --- /dev/null
>> > +++ b/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
>> > @@ -0,0 +1,11 @@
>> > +What:  /sys/devices/platform//otg-inputs
>> > +Date:  October 2016
>> > +KernelVersion: 4.10
>> > +Contact:   Yoshihiro Shimoda 
>> > +Description:
>> > +   This write-only file changes the phy mode for role swap of 
>> > usb.
>> > +   This file accepts the following strings:
>> > +"a_bus_req/" - switching from A-Host to A-Peripheral
>> > +"a_bus_drop" - switching from A-Peripheral to A-Host
>> > +"b_bus_req"  - switching from B-Peripheral to B-Host
>> > +"b_bus_req/" - switching from B-Host to B-Peripheral
>>
>> ... until I read the above.
>>
>> What's the rationale of doing it like this? I.e.
>>   1. Why differentiate by trailing "/"?
>
> This usb role swap feature is not compatible with USB OTG though,
> but this strings are from the manual that usb.org released:
> http://www.usb.org/developers/docs/usb20_docs/
>  --> usb_20_091216.zip
>   --> USB OTG and Embedded Host/USB_OTG_and_EH_2-0-version 1_1a.pdf
>Please refer to the following figures:
> - Figure 7-1: OTG A-device with HNP State Diagram
> - Figure 7-4: OTG B-device with HNP State Diagram
>
> So, it seems the "/" means FALSE.
>
>>   2. Why the asymmetry ("a_bus_drop" vs. "a_bus_req")?
>
> This is also related the document.
>  - From "a_host" to "a_suspend" state if "a_bus_req/" event happens.
>  - From "a_suspend" to "a_host" state if "a_bus_req" event happens.
>   (But the driver doesn't support it and we can use "a_bus_drop".)
>  - From "a_peripheral" to "a_wait_vfall" state if "a_bus_drop" event happens.

Thanks for the explanation!

Regardless, I think it would be good to CC the USB maintainer and mailing
list on next submission.

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] phy: rcar-gen3-usb2: add sysfs for usb role swap

[Yoshihiro Shimoda]

Hi Geert-san,

> From: geert.uytterhoe...@gmail.com
> Sent: Monday, October 17, 2016 9:28 PM
> 
> Hi Shimoda-san,
> 
> On Mon, Oct 17, 2016 at 9:10 AM, Yoshihiro Shimoda
>  wrote:
> > This patch adds sysfs "otg_inputs" for usb role swap. This parameter
> > is write-only and if you use them as the following, you can swap
> > the usb role.
> 
> Thank you for your patch!

Thank you for the review!

> > For example:
> >  1) connect a usb cable using 2 salvator-x boards
> >  2) On A-device (as host), you input the following command:
> ># echo a_bus_req/ > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs
> >  3) On B-device (as peripheral), you input the following command:
> ># echo b_bus_req > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs
> 
> At first, I thought the trailing "/" was a typo...
> 
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
> > @@ -0,0 +1,11 @@
> > +What:  /sys/devices/platform//otg-inputs
> > +Date:  October 2016
> > +KernelVersion: 4.10
> > +Contact:   Yoshihiro Shimoda 
> > +Description:
> > +   This write-only file changes the phy mode for role swap of 
> > usb.
> > +   This file accepts the following strings:
> > +"a_bus_req/" - switching from A-Host to A-Peripheral
> > +"a_bus_drop" - switching from A-Peripheral to A-Host
> > +"b_bus_req"  - switching from B-Peripheral to B-Host
> > +"b_bus_req/" - switching from B-Host to B-Peripheral
> 
> ... until I read the above.
> 
> What's the rationale of doing it like this? I.e.
>   1. Why differentiate by trailing "/"?

This usb role swap feature is not compatible with USB OTG though,
but this strings are from the manual that usb.org released:
http://www.usb.org/developers/docs/usb20_docs/
 --> usb_20_091216.zip
  --> USB OTG and Embedded Host/USB_OTG_and_EH_2-0-version 1_1a.pdf
   Please refer to the following figures:
- Figure 7-1: OTG A-device with HNP State Diagram
- Figure 7-4: OTG B-device with HNP State Diagram

So, it seems the "/" means FALSE.

>   2. Why the asymmetry ("a_bus_drop" vs. "a_bus_req")?

This is also related the document.
 - From "a_host" to "a_suspend" state if "a_bus_req/" event happens.
 - From "a_suspend" to "a_host" state if "a_bus_req" event happens.
  (But the driver doesn't support it and we can use "a_bus_drop".)
 - From "a_peripheral" to "a_wait_vfall" state if "a_bus_drop" event happens.

> I do not really follow USB development, so I please accepty my apologies if
> I missed the discussion and valid arguments that lead to this.
> 
> I did find Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg,
> which uses similar naming, but a slightly different mechanism (multiple
> sysfs virtual files with 0/1 states).

I also did look at the document. But, I prefer one parameter to control it.

Best regards,
Yoshihiro Shimoda

> Thanks!
> 
> 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