Re: [PATCH v3 2/3] arm64: dts: renesas: draak: Describe CVBS input

[kbuild test robot]

Hi Jacopo,

I love your patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[cannot apply to renesas/next v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jacopo-Mondi/arm64-dts-Draak-Enable-video-inputs-and-VIN4/20180521-052159
base:   git://linuxtv.org/media_tree.git master
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 >>):

>> Error: arch/arm64/boot/dts/renesas/r8a77995-draak.dts:272.1-6 Label or path 
>> vin4 not found
>> FATAL ERROR: Syntax error parsing input tree

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


.config.gz
Description: application/gzip

Re: [PATCH v2] v4l: vsp1: Fix vsp1_regs.h license header

[Nobuhiro Iwamatsu]

Hi,

2018-05-20 16:24 GMT+09:00 Laurent Pinchart
:
> All source files of the vsp1 driver are licensed under the GPLv2+ except
> for vsp1_regs.h which is licensed under GPLv2. This is caused by a bad
> copy that dates back from the initial version of the driver. Fix
> it.
>
> Cc: Nobuhiro Iwamatsu 
> Acked-by: Kieran Bingham 
> Acked-by: Sergei Shtylyov
> Acked-by: Niklas Söderlund 
> Acked-by: Wolfram Sang 
> Signed-off-by: Laurent Pinchart 
> ---
> Iwamatsu-san,
>
> While working on the VSP1 driver I noticed that all source files are
> licensed under the GPLv2+ except for vsp1_regs.h which is licensed under
> GPLv2. I'd like to fix this inconsistency. As you have contributed to
> that file, could you please provide your explicit ack if you agree to
> this change ?

Yes,  I agree with this change.

Acked-by: Nobuhiro Iwamatsu 

> ---
>  drivers/media/platform/vsp1/vsp1_regs.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_regs.h 
> b/drivers/media/platform/vsp1/vsp1_regs.h
> index 0d249ff9f564..e82661216c1d 100644
> --- a/drivers/media/platform/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> +/* SPDX-License-Identifier: GPL-2.0+ */
>  /*
>   * vsp1_regs.h  --  R-Car VSP1 Registers Definitions
>   *
> --
> Regards,
>
> Laurent Pinchart
>

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Re: [PATCH 0/3] sh_eth: fix typos/grammar

[David Miller]

From: Sergei Shtylyov 
Date: Sat, 19 May 2018 23:57:50 +0300

> Here's a set of 3 patches against DaveM's 'net-next.git' repo plus the 
> R8A77980
> support patches posted earlier. They fix the comments typos/grammar and 
> another
> typo in the EESR bit...

Series applied.

Re: [Qemu-devel] [PATCH v3 RESEND 3/3] nvram: at24c: use standard error reporting

[Peter Maydell]

On 20 May 2018 at 08:00, Wolfram Sang  wrote:
> Replace the ERR macro with error_report() because fprintf is deprecated.
> This also fixes the prefix printed out twice.
>
> Reviewed-by: Philippe Mathieu-Daudé 
> Signed-off-by: Wolfram Sang 
> ---
>  hw/nvram/eeprom_at24c.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
> @@ -63,8 +61,7 @@ int at24c_eeprom_event(I2CSlave *s, enum i2c_event event)
>  if (ee->blk && ee->changed) {
>  int len = blk_pwrite(ee->blk, 0, ee->mem, ee->rsize, 0);
>  if (len != ee->rsize) {
> -ERR(TYPE_AT24C_EE
> -" : failed to write backing file\n");
> +error_report("failed to write backing file");
>  }
>  DPRINTK("Wrote to backing file\n");
>  }
> @@ -125,7 +122,7 @@ int at24c_eeprom_init(I2CSlave *i2c)
>  EEPROMState *ee = AT24C_EE(i2c);
>
>  if (!ee->rsize) {
> -ERR("rom-size not allowed to be 0\n");
> +error_report("rom-size not allowed to be 0");
>  exit(1);
>  }

Hi; if we're going to overhaul the error handling for this
device, I think we might as well do it properly, by moving
the code in this init function which can fail into a new
device realize method. The realize method takes an Error**
and can report failures that way rather than by causing
QEMU to exit.

> @@ -166,8 +162,7 @@ void at24c_eeprom_reset(DeviceState *state)
>  int len = blk_pread(ee->blk, 0, ee->mem, ee->rsize);
>
>  if (len != ee->rsize) {
> -ERR(TYPE_AT24C_EE
> -" : Failed initial sync with backing file\n");
> +error_report("Failed initial sync with backing file");
>  }
>  DPRINTK("Reset read backing file\n");
>  }

Errors in reset and event methods are a bit more awkward;
error_report is an improvement in those cases.

thanks
-- PMM

Re: [PATCH 1/2] vsp-lib: Capture the kernel log messages in test log files

[Niklas Söderlund]

Hi Laurent,

Thanks for your patch.

On 2018-05-19 23:34:25 +0300, Laurent Pinchart wrote:
> It can be useful to capture kernel log messages in test log files for
> diagnostic purpose. Add a simple mechanism to do so by capturing the
> full kernel log at the end of the test. The kernel log is cleared first
> before starting the test to avoid capturing unrelated messages.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  scripts/vsp-lib.sh | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/scripts/vsp-lib.sh b/scripts/vsp-lib.sh
> index 0f3992a7827e..e672686a377e 100755
> --- a/scripts/vsp-lib.sh
> +++ b/scripts/vsp-lib.sh
> @@ -1075,6 +1075,9 @@ test_init() {
>   echo "Using device $mdev ($dev)" | ./logger.sh config >> $logfile
>  
>   vsp_runner=./vsp-runner.sh
> +
> + # Clear the kernel log
> + dmesg -c > /dev/null

I agree it's useful to capture the kernel log messages during a test, I 
did the same thing in vin-tests. What I did learn was that when 
something do go wrong you kind of want the whole kernel log from boot 
and truncating it could be annoying. Just the other day I got feed up 
with this in vin-tests and found a different way, as it's still fresh in 
my memory maybe it could be useful for you too, or not :-)

marker=$(dmesg | tail -n 1 | sed 's/^\[\([^]]*\)\].*/\1/g')


>  }
>  
>  test_start() {
> @@ -1086,6 +1089,8 @@ test_complete() {
>   echo "Done: $1" | ./logger.sh >> $logfile
>   echo $1 >&2
>  
> + dmesg -c | ./logger.sh kernel >> $logfile
> +

dmesg | sed "1,/$marker/d" | ./logger.sh kernel >> $logfile

>   rm -f ${frames_dir}frame-*.bin
>   rm -f ${frames_dir}histo-*.bin
>   rm -f ${frames_dir}rpf.*.bin
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Regards,
Niklas Söderlund

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

[Yoshihiro Kaneko]

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

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

v4 [Yoshihiro Kaneko]
rcar_thermal.c:
- add Tested-by tag
* As suggested by Simon Horman
- add comment to ".nirqs = 2" of rcar_gen3_thermal

rcar-thermal.txt:
* As suggested by Simon Horman
- update the explanation of the interrupts

r8a77995.dtsi:
- repositioned the thermal subnode by bus address order


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

rcar-thermal.txt:
* No change

r8a77995.dtsi:
* No change


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

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

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

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

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

-- 
1.9.1

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

[Yoshihiro Kaneko]

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

Signed-off-by: Yoshihiro Kaneko 
Tested-by: Ulrich Hecht 
---
 drivers/thermal/rcar_thermal.c | 158 -
 1 file changed, 126 insertions(+), 32 deletions(-)

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

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

[Yoshihiro Kaneko]

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

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 82aed7e..d4884e3 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -216,6 +216,18 @@
#power-domain-cells = <1>;
};
 
+   thermal: thermal@e619 {
+   compatible = "renesas,thermal-r8a77995";
+   reg = <0 0xe619 0 0x10>, <0 0xe6190100 0 0x38>;
+   interrupts = ,
+,
+;
+   clocks = < CPG_MOD 522>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 522>;
+   #thermal-sensor-cells = <0>;
+   };
+
intc_ex: interrupt-controller@e61c {
compatible = "renesas,intc-ex-r8a77995", "renesas,irqc";
#interrupt-cells = <2>;
@@ -785,6 +797,25 @@
};
};
 
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+   thermal-sensors = <>;
+
+   trips {
+   cpu-crit {
+   temperature = <12>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   };
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupts-extended = < GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) 
| IRQ_TYPE_LEVEL_LOW)>,
-- 
1.9.1

[PATCH v4 2/3] dt-bindings: thermal: rcar-thermal: add R8A77995 support

[Yoshihiro Kaneko]

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

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

Re: [PATCH 5/5] arm64: dts: renesas: r8a77995-draak: add X12 input dot clock

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Wednesday, 16 May 2018 11:38:22 EEST Simon Horman wrote:
> On Tue, May 15, 2018 at 02:20:40PM +0200, Ulrich Hecht wrote:
> > 74.25 Mhz oscillator X12 is connected to DU_DOTCLKIN0.
> > 
> > Signed-off-by: Ulrich Hecht 

Reviewed-by: Laurent Pinchart 

> > ---
> > 
> >  arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 11 +++
> >  1 file changed, 11 insertions(+)
> 
> This looks fine but I will wait to see if there are other reviews before
> applying.
> 
> Reviewed-by: Simon Horman 

As far as I'm concerned this patch can be merged already. I would however 
possibly hold off merging patch 3/5 and 4/5 until they can be tested.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 4/5] arm64: dts: renesas: r8a77995-draak: add HDMI output

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Tuesday, 15 May 2018 15:20:39 EEST Ulrich Hecht wrote:
> Adds LVDS decoder, HDMI encoder and connector for Draak boards.
> 
> Signed-off-by: Ulrich Hecht 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 80 +++
>  1 file changed, 80 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts index 9d73de8..b059e32
> 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -27,6 +27,41 @@
>   stdout-path = "serial0:115200n8";
>   };
> 
> + lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> + vcc-supply = <_3p3v>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + thc63lvd1024_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + thc63lvd1024_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + hdmi-out {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_out: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +
>   vga {
>   compatible = "vga-connector";
> 
> @@ -154,6 +189,39 @@
>   reg = <0x50>;
>   pagesize = <8>;
>   };
> +
> + hdmi@39 {
> + compatible = "adi,adv7511w";
> + reg = <0x39>, <0x3f>, <0x38>, <0x3c>;
> + reg-names = "main", "edid", "packet", "cec";
> + interrupt-parent = <>;
> + interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "rgb";
> + adi,input-clock = "1x";
> + adi,input-style = <1>;
> + adi,input-justification = "evenly";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7511_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <_con_out>;
> + };
> + };
> + };
> + };
>  };
> 
>   {
> @@ -176,6 +244,18 @@
>   };
>  };
> 
> + {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + lvds0_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +};
> +
>   {
>   status = "okay";
>  };


-- 
Regards,

Laurent Pinchart

Re: [PATCH 3/5] arm64: dts: renesas: r8a77995: Add LVDS support

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Tuesday, 15 May 2018 15:20:38 EEST Ulrich Hecht wrote:
> From: Kieran Bingham 
> 
> The r8a77995 D3 platform has 2 LVDS channels connected to the DU.
> 
> Signed-off-by: Kieran Bingham 
> [uli: moved lvds* into the soc node, added PM domains, resets]
> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 56 
>  1 file changed, 56 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index ba98865..8e78110d 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -757,12 +757,68 @@
>   port@1 {
>   reg = <1>;
>   du_out_lvds0: endpoint {
> + remote-endpoint = <_in>;
>   };
>   };
> 
>   port@2 {
>   reg = <2>;
>   du_out_lvds1: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + lvds0: lvds-encoder@feb9 {
> + compatible = "renesas,r8a77995-lvds";
> + reg = <0 0xfeb9 0 0x20>;
> + clocks = < CPG_MOD 727>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 727>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds0_in: endpoint {
> + remote-endpoint = 
> <_out_lvds0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + lvds0_out: endpoint {
> + };
> + };
> + };
> + };
> +
> + lvds1: lvds-encoder@feb90100 {
> + compatible = "renesas,r8a77995-lvds";
> + reg = <0 0xfeb90100 0 0x20>;
> + clocks = < CPG_MOD 727>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 727>;

While there seems to be a single clock for both LVDS encoders, it appears that 
two separate reset lines are used.

Apart from that,

Reviewed-by: Laurent Pinchart 

Given that the LVDS encoder driver isn't functional yet I wouldn't rule out a 
need to update the LVDS DT bindings in order to properly support D3. I don't 
mind if this patch gets merged already (provided the reset problem gets fixed 
of course), as long as it won't be considered a blocker for DT bindings 
rework. Otherwise I'd prefer delaying upstreaming until the whole series can 
be tested.

> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds1_in: endpoint {
> + remote-endpoint = 
> <_out_lvds1>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + lvds1_out: endpoint {
>   };
>   };
>   };

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/5] drm: rcar-du: lvds: Add R8A77995 support

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Tuesday, 15 May 2018 15:20:37 EEST Ulrich Hecht wrote:
> Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 3d2d3bb..58fb9f8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -511,6 +511,11 @@ static const struct rcar_lvds_device_info
> rcar_lvds_r8a77970_info = { .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR |
> RCAR_LVDS_QUIRK_GEN3_LVEN, };
> 
> +static const struct rcar_lvds_device_info rcar_lvds_r8a77995_info = {
> + .gen = 3,
> + .quirks = RCAR_LVDS_QUIRK_GEN3_LVEN,

I'm afraid this won't be enough. With this patch the driver will call 
rcar_lvds_lvdpllcr_gen3(), which writes values to the LVDPLLCR register that 
don't match the register layout for D3.

While I'm fine with an initial version that doesn't support fine-grained 
control of the LVDS PLL to achieve the HDMI clock accuracy requirements, we 
need the LVDS encoder to be at least functional for the patches to get merged.

There are also other registers not related to the PLL that need to be set 
(such as the LVDSTRIPE register), and other differences in register layouts 
(for instance the D3 doesn't have a PLLON bit in register LVDC0).

Even the LVEN bit seems to need special handling on D3. According to version 
1.00 of the datasheet it should be set to 1 at the same time as bit LVRES.

Could you please study the datasheet in details and update the code 
accordingly ?

> +};
> +
>  static const struct of_device_id rcar_lvds_of_table[] = {
>   { .compatible = "renesas,r8a7743-lvds", .data = _lvds_gen2_info },
>   { .compatible = "renesas,r8a7790-lvds", .data = _lvds_r8a7790_info 
> },
> @@ -519,6 +524,7 @@ static const struct of_device_id rcar_lvds_of_table[] =
> { { .compatible = "renesas,r8a7795-lvds", .data = _lvds_gen3_info }, {
> .compatible = "renesas,r8a7796-lvds", .data = _lvds_gen3_info }, {
> .compatible = "renesas,r8a77970-lvds", .data = _lvds_r8a77970_info },
> + { .compatible = "renesas,r8a77995-lvds", .data = 
> _lvds_r8a77995_info
> }, { }
>  };

-- 
Regards,

Laurent Pinchart

Re: [PATCH 0/5] R-Car D3 LVDS/HDMI support

[Laurent Pinchart]

Hi Ulrich,

On Tuesday, 15 May 2018 15:20:35 EEST Ulrich Hecht wrote:
> Hi!
> 
> This adds D3 support to the DU and LVDS drivers, not including LVDS PLL
> support.
> 
> It also adds LVDS encoders to the D3 device tree, and LVDS decoder, HDMI
> encoder and HDMI output connector to the Draak device tree.
> 
> In theory that should be good enough to provide HDMI output on the Draak
> board, but in practice the lack of LVDS PLL support prevents generation of
> close-enough dot clock frequencies.
> 
> This series is based on renesas-drivers-2018-05-02-v4.17-rc3 and requires
> Jacopo's "drm: bridge: Add thc63lvd1024 LVDS decoder driver" patch.

As HDMI output isn't functional yet this is difficult to test. Could you add 
support for the VGA output (using the DU DPAD) in v2 of the patch series ? VGA 
should work without LVDS PLL support as the clock frequency requirements are 
not as strict as for HDMI.

> Kieran Bingham (1):
>   arm64: dts: renesas: r8a77995: Add LVDS support
> 
> Koji Matsuoka (1):
>   drm: rcar-du: Add r8a77995 device support
> 
> Ulrich Hecht (3):
>   drm: rcar-du: lvds: Add R8A77995 support
>   arm64: dts: renesas: r8a77995-draak: add HDMI output
>   arm64: dts: renesas: r8a77995-draak: add X12 input dot clock
> 
>  arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 91 +++
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi  | 56 
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 26 
>  drivers/gpu/drm/rcar-du/rcar_lvds.c|  6 ++
>  4 files changed, 179 insertions(+)

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/5] drm: rcar-du: Add r8a77995 device support

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Tuesday, 15 May 2018 15:20:36 EEST Ulrich Hecht wrote:
> From: Koji Matsuoka 
> 
> Add support for the R-Car D3 (R8A77995) SoC to the R-Car DU driver.
> 
> Signed-off-by: Koji Matsuoka 
> Signed-off-by: Ulrich Hecht 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 05745e8..ba82842 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -266,6 +266,31 @@ static const struct rcar_du_device_info
> rcar_du_r8a77970_info = { .num_lvds = 1,
>  };
> 
> +static const struct rcar_du_device_info rcar_du_r8a77995_info = {
> + .gen = 3,
> + .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> +   | RCAR_DU_FEATURE_EXT_CTRL_REGS
> +   | RCAR_DU_FEATURE_VSP1_SOURCE,
> + .num_crtcs = 2,
> + .routes = {
> + /* R8A77995 has two LVDS output and one RGB output.
> +  */

This comment holds on a single line.

Apart from that the patch looks good to me, but it conflicts with

commit 5361cc7f8e9146f393cfcb76890d8c80a4e73086
Author: Kieran Bingham 
Date:   Fri Apr 27 23:21:52 2018 +0100

drm: rcar-du: Split CRTC handling to support hardware indexing

that has been queued in Dave's DRM tree for v4.18. The num_crtcs field has 
been replaced with a channels_mask field. I can fix when applying but I can't 
test the result as I don't have a D3 board, so I'd prefer if you could submit 
a v2 rebased on top of Dave's drm-next branch.

I'm also wondering whether we also need

commit 6f3850955384cff722f02530f570806897b02a87
Author: Koji Matsuoka 
Date:   Wed Dec 6 20:30:24 2017 +0900

drm: rcar-du: Fix digital RGB routing for R8A77995

from the BSP. What's your opinion ?

> + [RCAR_DU_OUTPUT_DPAD0] = {
> + .possible_crtcs = BIT(0) | BIT(1),
> + .port = 0,
> + },
> + [RCAR_DU_OUTPUT_LVDS0] = {
> + .possible_crtcs = BIT(0),
> + .port = 1,
> + },
> + [RCAR_DU_OUTPUT_LVDS1] = {
> + .possible_crtcs = BIT(1),
> + .port = 2,
> + },
> + },
> + .num_lvds = 2,
> +};
> +
>  static const struct of_device_id rcar_du_of_table[] = {
>   { .compatible = "renesas,du-r8a7743", .data = _du_r8a7743_info },
>   { .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
> @@ -278,6 +303,7 @@ static const struct of_device_id rcar_du_of_table[] = {
>   { .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
>   { .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
>   { .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
> + { .compatible = "renesas,du-r8a77995", .data = _du_r8a77995_info },
>   { }
>  };

-- 
Regards,

Laurent Pinchart

[PATCH v2] v4l: vsp1: Fix vsp1_regs.h license header

[Laurent Pinchart]

All source files of the vsp1 driver are licensed under the GPLv2+ except
for vsp1_regs.h which is licensed under GPLv2. This is caused by a bad
copy that dates back from the initial version of the driver. Fix
it.

Cc: Nobuhiro Iwamatsu 
Acked-by: Kieran Bingham 
Acked-by: Sergei Shtylyov
Acked-by: Niklas Söderlund 
Acked-by: Wolfram Sang 
Signed-off-by: Laurent Pinchart 
---
Iwamatsu-san,

While working on the VSP1 driver I noticed that all source files are
licensed under the GPLv2+ except for vsp1_regs.h which is licensed under
GPLv2. I'd like to fix this inconsistency. As you have contributed to
that file, could you please provide your explicit ack if you agree to
this change ?
---
 drivers/media/platform/vsp1/vsp1_regs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_regs.h 
b/drivers/media/platform/vsp1/vsp1_regs.h
index 0d249ff9f564..e82661216c1d 100644
--- a/drivers/media/platform/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+/* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * vsp1_regs.h  --  R-Car VSP1 Registers Definitions
  *
-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] i2c: mux: demux-pinctrl: use proper parent device for demux adapter

[Peter Rosin]

On 2018-05-20 08:45, Wolfram Sang wrote:
> On Sat, May 19, 2018 at 11:40:04PM +0200, Peter Rosin wrote:
>> On 2018-04-30 13:55, Wolfram Sang wrote:
>>> Due to a typo, the wrong parent device was assigned to the newly created
>>> demuxing adapter device. It got connected to the demuxing platform
>>> device but not to the selected parent I2C adapter device. Fix it to get
>>> a proper parent-child relationship of the demuxed busses, needed also for
>>> proper PM.
>>>
>>
>> Should this one have a Fixes: tag? Should it go to current or next? Is
>> a backport to stable good enough?
> 
> A Fixes tag is probably apropriate. I don't think it should go to
> stable, though, because it will break a scheme a user might be using.
> This can't be avoided for a kernel upgrade here, but IMO we shouldn't
> enforce it for a stable update. Especially, given this is not a real
> bug, but more something improper. For the same reason, I'd think -next
> is good enough.
> 
> Thanks, will resend!

Hmm, in that case, I think a Fixes tag is best left out, because I suspect
the net effect is mostly a bunch of mails from the stable trees as the
automatic patch-picker finds this patch. So, I plan to go with this patch.

Ok?

Cheers,
Peter

Re: [PATCH v6 9/9] v4l: vsp1: Reduce display list body size

[Laurent Pinchart]

Hi Kieran,

On Wednesday, 28 February 2018 22:52:43 EEST Kieran Bingham wrote:
> The display list originally allocated a body of 256 entries to store all
> of the register lists required for each frame.
> 
> This has now been separated into fragments for constant stream setup, and
> runtime updates.
> 
> Empirical testing shows that the body0 now uses a maximum of 41
> registers for each frame, for both DRM and Video API pipelines thus a
> rounded 64 entries provides a suitable allocation.
> 
> Signed-off-by: Kieran Bingham 

Just wondering, why have you dropped this from new versions of the patch 
series ?

> ---
>  drivers/media/platform/vsp1/vsp1_dl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index a762e840d147..6b5743a431a2
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -21,7 +21,7 @@
>  #include "vsp1.h"
>  #include "vsp1_dl.h"
> 
> -#define VSP1_DL_NUM_ENTRIES  256
> +#define VSP1_DL_NUM_ENTRIES  64
> 
>  #define VSP1_DLH_INT_ENABLE  (1 << 1)
>  #define VSP1_DLH_AUTO_START  (1 << 0)


-- 
Regards,

Laurent Pinchart

[PATCH v3 RESEND 0/3] nvram: at24c: fix problems related to "rom-size"

[Wolfram Sang]

I used this driver as a template for a custom one. While hacking on my own, I
noticed some problems in this driver, too. This series fixes the first set of
them, related to the "rom-size" parameter. It fixes a segfault.

I think the first patch is clearly suitable for stable. I think the second one,
too, but not as clearly. The third one is a cleanup and not for stable. Still,
I am open for opinions about these thoughts.

Thanks,

   Wolfram

This is the same v3 as last time. Rebased to current master, but that produced
no diff.

Changes since v2:

* removed '\n' from error_report-strings
* made sure checkpatch is happy
* added tags from Philippe (thanks!)

Changes since v1:

* reordered patches according to significance for stable
* use AT24C_ROMSIZE_DEFAULT instead of magic value
* patch 3 doesn't improve the ERR macro anymore but replaces
  it completely with error_report().


Wolfram Sang (3):
  nvram: at24c: prevent segfault by checking "rom-size"
  nvram: at24c: use a sane default for "rom-size"
  nvram: at24c: use standard error reporting

 hw/nvram/eeprom_at24c.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

-- 
2.11.0

[PATCH v3 RESEND 1/3] nvram: at24c: prevent segfault by checking "rom-size"

[Wolfram Sang]

The value for "rom-size" is used as a divisor, so it must not be 0 or it
will segfault. A size of 0 wouldn't make sense anyhow.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Wolfram Sang 
---
 hw/nvram/eeprom_at24c.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hw/nvram/eeprom_at24c.c b/hw/nvram/eeprom_at24c.c
index 22183f5360..ccf78b25e4 100644
--- a/hw/nvram/eeprom_at24c.c
+++ b/hw/nvram/eeprom_at24c.c
@@ -121,6 +121,11 @@ int at24c_eeprom_init(I2CSlave *i2c)
 {
 EEPROMState *ee = AT24C_EE(i2c);
 
+if (!ee->rsize) {
+ERR("rom-size not allowed to be 0\n");
+exit(1);
+}
+
 ee->mem = g_malloc0(ee->rsize);
 
 if (ee->blk) {
-- 
2.11.0

[PATCH v3 RESEND 3/3] nvram: at24c: use standard error reporting

[Wolfram Sang]

Replace the ERR macro with error_report() because fprintf is deprecated.
This also fixes the prefix printed out twice.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Wolfram Sang 
---
 hw/nvram/eeprom_at24c.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/hw/nvram/eeprom_at24c.c b/hw/nvram/eeprom_at24c.c
index ab1ef686e2..c35b29e503 100644
--- a/hw/nvram/eeprom_at24c.c
+++ b/hw/nvram/eeprom_at24c.c
@@ -13,6 +13,7 @@
 #include "hw/hw.h"
 #include "hw/i2c/i2c.h"
 #include "sysemu/block-backend.h"
+#include "qemu/error-report.h"
 
 /* #define DEBUG_AT24C */
 
@@ -22,9 +23,6 @@
 #define DPRINTK(FMT, ...) do {} while (0)
 #endif
 
-#define ERR(FMT, ...) fprintf(stderr, TYPE_AT24C_EE " : " FMT, \
-## __VA_ARGS__)
-
 #define TYPE_AT24C_EE "at24c-eeprom"
 #define AT24C_EE(obj) OBJECT_CHECK(EEPROMState, (obj), TYPE_AT24C_EE)
 
@@ -63,8 +61,7 @@ int at24c_eeprom_event(I2CSlave *s, enum i2c_event event)
 if (ee->blk && ee->changed) {
 int len = blk_pwrite(ee->blk, 0, ee->mem, ee->rsize, 0);
 if (len != ee->rsize) {
-ERR(TYPE_AT24C_EE
-" : failed to write backing file\n");
+error_report("failed to write backing file");
 }
 DPRINTK("Wrote to backing file\n");
 }
@@ -125,7 +122,7 @@ int at24c_eeprom_init(I2CSlave *i2c)
 EEPROMState *ee = AT24C_EE(i2c);
 
 if (!ee->rsize) {
-ERR("rom-size not allowed to be 0\n");
+error_report("rom-size not allowed to be 0");
 exit(1);
 }
 
@@ -135,7 +132,7 @@ int at24c_eeprom_init(I2CSlave *i2c)
 int64_t len = blk_getlength(ee->blk);
 
 if (len != ee->rsize) {
-ERR(TYPE_AT24C_EE " : Backing file size %lu != %u\n",
+error_report("Backing file size %lu != %u",
 (unsigned long)len, (unsigned)ee->rsize);
 exit(1);
 }
@@ -143,8 +140,7 @@ int at24c_eeprom_init(I2CSlave *i2c)
 if (blk_set_perm(ee->blk, BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE,
  BLK_PERM_ALL, _fatal) < 0)
 {
-ERR(TYPE_AT24C_EE
-" : Backing file incorrect permission\n");
+error_report("Backing file incorrect permission");
 exit(1);
 }
 }
@@ -166,8 +162,7 @@ void at24c_eeprom_reset(DeviceState *state)
 int len = blk_pread(ee->blk, 0, ee->mem, ee->rsize);
 
 if (len != ee->rsize) {
-ERR(TYPE_AT24C_EE
-" : Failed initial sync with backing file\n");
+error_report("Failed initial sync with backing file");
 }
 DPRINTK("Reset read backing file\n");
 }
-- 
2.11.0

[PATCH v3 RESEND 2/3] nvram: at24c: use a sane default for "rom-size"

[Wolfram Sang]

0 as "rom-size" will lead to an error message. Let's use the size of a
small 24c01 which has 128 byte.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Wolfram Sang 
---
 hw/nvram/eeprom_at24c.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/hw/nvram/eeprom_at24c.c b/hw/nvram/eeprom_at24c.c
index ccf78b25e4..ab1ef686e2 100644
--- a/hw/nvram/eeprom_at24c.c
+++ b/hw/nvram/eeprom_at24c.c
@@ -28,6 +28,9 @@
 #define TYPE_AT24C_EE "at24c-eeprom"
 #define AT24C_EE(obj) OBJECT_CHECK(EEPROMState, (obj), TYPE_AT24C_EE)
 
+/* default is the size of a 24c01 EEPROM */
+#define AT24C_ROMSIZE_DEFAULT 128
+
 typedef struct EEPROMState {
 I2CSlave parent_obj;
 
@@ -171,7 +174,7 @@ void at24c_eeprom_reset(DeviceState *state)
 }
 
 static Property at24c_eeprom_props[] = {
-DEFINE_PROP_UINT32("rom-size", EEPROMState, rsize, 0),
+DEFINE_PROP_UINT32("rom-size", EEPROMState, rsize, AT24C_ROMSIZE_DEFAULT),
 DEFINE_PROP_BOOL("writable", EEPROMState, writable, true),
 DEFINE_PROP_DRIVE("drive", EEPROMState, blk),
 DEFINE_PROP_END_OF_LIST()
-- 
2.11.0

Re: [PATCH 2/2] i2c: mux: demux-pinctrl: add symlinks to the demux device in sysfs

[Wolfram Sang]

> > +   sysfs_create_link(>cur_adap.dev.kobj, >dev->kobj,
> > +  "demux_device");
> > +   sysfs_create_link(>dev->kobj, >cur_adap.dev.kobj,
> > +  "channel-0");
> > +
> 
> From sysfs.h:
> int __must_check sysfs_create_link(...);

Darn, right... Will fix!

Re: [PATCH 1/2] i2c: mux: demux-pinctrl: use proper parent device for demux adapter

[Wolfram Sang]

On Sat, May 19, 2018 at 11:40:04PM +0200, Peter Rosin wrote:
> On 2018-04-30 13:55, Wolfram Sang wrote:
> > Due to a typo, the wrong parent device was assigned to the newly created
> > demuxing adapter device. It got connected to the demuxing platform
> > device but not to the selected parent I2C adapter device. Fix it to get
> > a proper parent-child relationship of the demuxed busses, needed also for
> > proper PM.
> > 
> 
> Should this one have a Fixes: tag? Should it go to current or next? Is
> a backport to stable good enough?

A Fixes tag is probably apropriate. I don't think it should go to
stable, though, because it will break a scheme a user might be using.
This can't be avoided for a kernel upgrade here, but IMO we shouldn't
enforce it for a stable update. Especially, given this is not a real
bug, but more something improper. For the same reason, I'd think -next
is good enough.

Thanks, will resend!

   Wolfram