Re: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate

2017-07-17 Thread Stephen Boyd
On 07/17, Geert Uytterhoeven wrote:
> Hi Wolfram,
> 
> On Mon, Jul 17, 2017 at 11:18 AM, Wolfram Sang  wrote:
> >> >> In .recalc_rate of struct clk_ops, it is desirable to return 0 if an
> >> >> error occurs, but -EINVAL is returned. This patch fixes it.
> >> >>
> >> >> Fixes: 5b1defde7054 ("clk: renesas: cpg-mssr: Extract common R-Car Gen3 
> >> >> support code")
> >> >> Signed-off-by: Takeshi Kihara 
> >> >> Signed-off-by: Yoshihiro Kaneko 
> >> >
> >> > Reviewed-by: Wolfram Sang 
> >>
> >> Why is it desirable to return 0 if an error occurs? Because the return 
> >> type is
> >> unsigned long?
> >
> > Yes, I'd think so. Instead of an arbitrary high, kind-of-random, number, 
> > just
> > return 0 which also indicates that something unexpected happened? Also, all
> > other drivers return zero in an error case (did some quick coccinelle
> > grepping before).
> 
> OK.
> 
> >> Is this routine allowed to fail? I don't see any handling of zero by
> >> its callers.
> >
> > From clk-provider.h:
> >
> >  * @recalc_rate Recalculate the rate of this clock, by querying hardware. 
> > The
> >  *  parent rate is an input parameter.  It is up to the caller 
> > to
> >  *  ensure that the prepare_mutex is held across this call.
> >  *  Returns the calculated rate.  Optional, but recommended - if
> >  *  this op is not set then clock rate will be initialized to 0.
> >
> > What would be the benefit of keeping -EINVAL in an unsigned long?
> 
> I do not mean that -EINVAL is correct. Obviously it isn't. But blindly
> replacing -EINVAL by zero may not be the right solution neither.
> 
> If recalc_rate cannot return an error value, perhaps there is a good reason
> for that?

Presumably you can always figure out what the rate of the clk is,
or at least return the rate of the parent clk if it can't be
figured out for some odd reason. In this case it looks like we
don't have some divider mapping? Why not make it a WARN_ON() and
return 0? Then we can fix the warning by adding the appropriate
mapping in the table and not return some really large frequency.

> 
> I see there's a similar check in cpg_sd_clock_enable(), so the clock also
> cannot be enabled if this condition is met?
> 
> When does this happen? If the firmware leaves a invalid/unsupported setting
> in the register? If we can't recover from that, perhaps the clock's probe
> should just fail instead?
> 
> It looks like the only writer of that field is cpg_sd_clock_set_rate(),
> which always writes a valid/supported value. Is it guaranteed that this
> function is always called first?
> If yes, the checks can just be removed instead?
> 

This also works. I'm dropping this patch from my queue for now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

2017-07-17 Thread Arnd Bergmann
On Mon, Jul 17, 2017 at 4:35 PM, Hans Verkuil  wrote:
> On 17/07/17 16:26, Arnd Bergmann wrote:

>> Let me try again without ccache for now and see what warnings remain.
>> We can find a solution for those first, and then decide how to deal with
>> ccache.
>
> Sounds good.
>
> I'm OK with applying this if there is no other way to prevent these warnings.

Small update: I noticed that having ccache being the default compiler
even with CCACHE_DISABLE=1 causes a lot of these warnings. Completely
taking ccache out of the picture however seems to have eliminated the
warnings about v4l2_subdev_call() and other silly warnings, but not
the interesting ones in the -Wint-in-bool-context category.

   Arnd


[PATCH V4 2/2] mfd: Add ROHM BD9571MWV-M MFD PMIC driver

2017-07-17 Thread Marek Vasut
Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS
entry. The MFD part only specifies the regmap bits for the PMIC and
binds the subdevs together.

Signed-off-by: Marek Vasut 
Cc: linux-ker...@vger.kernel.org
Cc: Geert Uytterhoeven 
Cc: Lee Jones 
---
V2: - Change BD9571MWV_AVS_VD09_VID0,1,2,3 to BD9571MWV_AVS_VD09_VID(n)
- Change BD9571MWV_AVS_DVFS_VID0,1,2,3 to BD9571MWV_AVS_DVFS_VID(n)
- Make the AVS_VD09 range RW, so it can be used by the regulator
  driver for the VD09 regulator
- Report the regmap read return values when attempting to read ID
  registers fails
V3: No change
V4: select REGMAP_IRQ
---
 MAINTAINERS   |  11 ++
 drivers/mfd/Kconfig   |  14 +++
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/bd9571mwv.c   | 230 ++
 include/linux/mfd/bd9571mwv.h | 115 +
 5 files changed, 371 insertions(+)
 create mode 100644 drivers/mfd/bd9571mwv.c
 create mode 100644 include/linux/mfd/bd9571mwv.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 0b6ed8eb58b0..f369c1cb287e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11291,6 +11291,17 @@ L: linux-ser...@vger.kernel.org
 S: Odd Fixes
 F: drivers/tty/serial/rp2.*
 
+ROHM MULTIFUNCTION BD9571MWV-M PMIC DEVICE DRIVERS
+M: Marek Vasut 
+L: linux-ker...@vger.kernel.org
+L: linux-renesas-soc@vger.kernel.org
+S: Supported
+F: drivers/mfd/bd9571mwv.c
+F: drivers/regulator/bd9571mwv-regulator.c
+F: drivers/gpio/gpio-bd9571mwv.c
+F: include/linux/mfd/bd9571mwv.h
+F: Documentation/devicetree/bindings/mfd/bd9571mwv.txt
+
 ROSE NETWORK LAYER
 M: Ralf Baechle 
 L: linux-h...@vger.kernel.org
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 94ad2c1c3d90..667665926fb3 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -133,6 +133,20 @@ config MFD_BCM590XX
help
  Support for the BCM590xx PMUs from Broadcom
 
+config MFD_BD9571MWV
+   tristate "ROHM BD9571MWV PMIC"
+   select MFD_CORE
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   depends on I2C
+   help
+ Support for the ROHM BD9571MWV PMIC, which contains single
+ voltage regulator, voltage sampling units, GPIO block and
+ watchdog block.
+
+ This driver can also be built as a module. If so, the module
+ will be called bd9571mwv.
+
 config MFD_AC100
tristate "X-Powers AC100"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 080793b3fd0e..db15df3d9e8d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_MFD_ACT8945A)+= act8945a.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
 obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
+obj-$(CONFIG_MFD_BD9571MWV)+= bd9571mwv.o
 cros_ec_core-objs  := cros_ec.o
 cros_ec_core-$(CONFIG_ACPI)+= cros_ec_acpi_gpe.o
 obj-$(CONFIG_MFD_CROS_EC)  += cros_ec_core.o
diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
new file mode 100644
index ..64e088dfe7b0
--- /dev/null
+++ b/drivers/mfd/bd9571mwv.c
@@ -0,0 +1,230 @@
+/*
+ * ROHM BD9571MWV-M MFD driver
+ *
+ * Copyright (C) 2017 Marek Vasut 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65086 driver
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static const struct mfd_cell bd9571mwv_cells[] = {
+   { .name = "bd9571mwv-regulator", },
+   { .name = "bd9571mwv-gpio", },
+};
+
+static const struct regmap_range bd9571mwv_readable_yes_ranges[] = {
+   regmap_reg_range(BD9571MWV_VENDOR_CODE, BD9571MWV_PRODUCT_REVISION),
+   regmap_reg_range(BD9571MWV_AVS_SET_MONI, BD9571MWV_AVS_DVFS_VID(3)),
+   regmap_reg_range(BD9571MWV_VD18_VID, BD9571MWV_VD33_VID),
+   regmap_reg_range(BD9571MWV_DVFS_VINIT, BD9571MWV_DVFS_VINIT),
+   regmap_reg_range(BD9571MWV_DVFS_SETVMAX, BD9571MWV_DVFS_MONIVDAC),
+   regmap_reg_range(BD9571MWV_GPIO_IN, BD9571MWV_GPIO_IN),
+   regmap_reg_range(BD9571MWV_GPIO_INT, BD9571MWV_GPIO_INTMASK),
+   regmap_reg_range(BD9571MWV_INT_INTREQ, BD9571MWV_INT_INTMASK),
+};
+
+static const struct regmap_access_table bd9571mwv_readable_table = {
+   .yes_ranges = bd9571mwv_readable_yes_ranges,
+   

Re: [PATCH V3 2/2] mfd: Add ROHM BD9571MWV-M MFD PMIC driver

2017-07-17 Thread Marek Vasut
On 07/10/2017 05:33 PM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Tue, May 2, 2017 at 2:18 PM, Marek Vasut  wrote:
>> Add the MFD part of the ROHM BD9571MWV-M PMIC driver and MAINTAINERS
>> entry. The MFD part only specifies the regmap bits for the PMIC and
>> binds the subdevs together.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: linux-ker...@vger.kernel.org
>> Cc: Geert Uytterhoeven 
>> Cc: Lee Jones 
> 
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -133,6 +133,19 @@ config MFD_BCM590XX
>> help
>>   Support for the BCM590xx PMUs from Broadcom
>>
>> +config MFD_BD9571MWV
>> +   tristate "ROHM BD9571MWV PMIC"
>> +   select MFD_CORE
>> +   select REGMAP_I2C
> 
> Missing "select REGMAP_IRQ".
> 
> Else it fails with:

Added

-- 
Best regards,
Marek Vasut


[PATCH V4 1/2] mfd: Add ROHM BD9571MWV-M PMIC DT bindings

2017-07-17 Thread Marek Vasut
Add DT bindings for the ROHM BD9571MWV-M PMIC. This PMIC has
the following features:
- multiple voltage monitors for 1V8, 2V5, 3V3 voltage rail
- one voltage regulator for DVFS
- two GPIOs

Signed-off-by: Marek Vasut 
Cc: devicet...@vger.kernel.org
Cc: Rob Herring 
Cc: Geert Uytterhoeven 
Cc: linux-renesas-soc@vger.kernel.org
Acked-by: Rob Herring 
---
V2: - Drop the compatible = "regulator-fixed" from the binding example,
  it should not be there.
- List the VD09 regulator
V3: Replace bd9571@30 with pmic@30
V4: No changes
---
 .../devicetree/bindings/mfd/bd9571mwv.txt  | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/bd9571mwv.txt

diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt 
b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
new file mode 100644
index ..9ab216a851d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
@@ -0,0 +1,49 @@
+* ROHM BD9571MWV Power Management Integrated Circuit (PMIC) bindings
+
+Required properties:
+ - compatible  : Should be "rohm,bd9571mwv".
+ - reg : I2C slave address.
+ - interrupt-parent: Phandle to the parent interrupt controller.
+ - interrupts  : The interrupt line the device is connected to.
+ - interrupt-controller: Marks the device node as an interrupt 
controller.
+ - #interrupt-cells: The number of cells to describe an IRQ, should be 2.
+   The first cell is the IRQ number.
+   The second cell is the flags, encoded as trigger
+   masks from ../interrupt-controller/interrupts.txt.
+ - gpio-controller  : Marks the device node as a GPIO Controller.
+ - #gpio-cells  : Should be two.  The first cell is the pin number and
+the second cell is used to specify flags.
+See ../gpio/gpio.txt for more information.
+ - regulators:  : List of child nodes that specify the regulator
+initialization data. Child nodes must be named
+after their hardware counterparts:
+- vd09
+- vd18
+- vd25
+- vd33
+- dvfs
+   Each child node is defined using the standard
+   binding for regulators.
+
+Example:
+
+   pmic: pmic@30 {
+   compatible = "rohm,bd9571mwv";
+   reg = <0x30>;
+   interrupt-parent = <>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   regulators {
+   dvfs: dvfs {
+   regulator-name = "dvfs";
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <103>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   };
+   };
-- 
2.11.0



[renesas-drivers:topic/renesas-overlays 1/86] drivers//of/configfs.c:48:2: error: implicit declaration of function 'of_fdt_unflatten_tree'

2017-07-17 Thread kbuild test robot
tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
topic/renesas-overlays
head:   8361d7e7432d1937f94e1863211fb3f852e37f36
commit: 1ba23467c1d052c0b5c35436c034f0fb7103eeaf [1/86] OF: DT-Overlay configfs 
interface (v7)
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1ba23467c1d052c0b5c35436c034f0fb7103eeaf
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers//of/configfs.c: In function 'create_overlay':
>> drivers//of/configfs.c:48:2: error: implicit declaration of function 
>> 'of_fdt_unflatten_tree' [-Werror=implicit-function-declaration]
 of_fdt_unflatten_tree(blob, NULL, >overlay);
 ^
   cc1: some warnings being treated as errors

vim +/of_fdt_unflatten_tree +48 drivers//of/configfs.c

42  
43  static int create_overlay(struct cfs_overlay_item *overlay, void *blob)
44  {
45  int err;
46  
47  /* unflatten the tree */
  > 48  of_fdt_unflatten_tree(blob, NULL, >overlay);
49  if (overlay->overlay == NULL) {
50  pr_err("%s: failed to unflatten tree\n", __func__);
51  err = -EINVAL;
52  goto out_err;
53  }
54  pr_debug("%s: unflattened OK\n", __func__);
55  
56  /* mark it as detached */
57  of_node_set_flag(overlay->overlay, OF_DETACHED);
58  
59  /* perform resolution */
60  err = of_resolve_phandles(overlay->overlay);
61  if (err != 0) {
62  pr_err("%s: Failed to resolve tree\n", __func__);
63  goto out_err;
64  }
65  pr_debug("%s: resolved OK\n", __func__);
66  
67  err = of_overlay_create(overlay->overlay);
68  if (err < 0) {
69  pr_err("%s: Failed to create overlay (err=%d)\n",
70  __func__, err);
71  goto out_err;
72  }
73  overlay->ov_id = err;
74  
75  out_err:
76  return err;
77  }
78  

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


.config.gz
Description: application/gzip


[PATCH] watchdog: asm9260_wdt: don't round closest with get_timeleft

2017-07-17 Thread Wolfram Sang
We should never return more time left than there actually is. So, switch
to a plain divider instead of DIV_ROUND_CLOSEST.

Signed-off-by: Wolfram Sang 
---

This is similar to a patch for the renesas-rwdt[1]. I think it makes sense to
remove this pattern from the whole subsystem, if we can agree on the behaviour
stated in the patch description. So, this is the other driver using
DIV_ROUND_CLOSEST.

Note: This driver and the lpc18xx_wdt.c extremly likely drive the same IP core.
They would ideally be merged.

[1] https://patchwork.kernel.org/patch/9845459/

 drivers/watchdog/asm9260_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/asm9260_wdt.c b/drivers/watchdog/asm9260_wdt.c
index 53da001f0838ee..f40dd71c904bef 100644
--- a/drivers/watchdog/asm9260_wdt.c
+++ b/drivers/watchdog/asm9260_wdt.c
@@ -82,7 +82,7 @@ static unsigned int asm9260_wdt_gettimeleft(struct 
watchdog_device *wdd)
 
counter = ioread32(priv->iobase + HW_WDTV);
 
-   return DIV_ROUND_CLOSEST(counter, priv->wdt_freq);
+   return counter / priv->wdt_freq;
 }
 
 static int asm9260_wdt_updatetimeout(struct watchdog_device *wdd)
-- 
2.11.0



[PATCH v8 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

2017-07-17 Thread Niklas Söderlund
A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
hardware blocks are connected between the video sources and the video
grabbers (VIN).

Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/Kconfig |  12 +
 drivers/media/platform/rcar-vin/Makefile|   1 +
 drivers/media/platform/rcar-vin/rcar-csi2.c | 822 
 3 files changed, 835 insertions(+)
 create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c

diff --git a/drivers/media/platform/rcar-vin/Kconfig 
b/drivers/media/platform/rcar-vin/Kconfig
index af4c98b44d2e22cb..6875f30c1ae42631 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -1,3 +1,15 @@
+config VIDEO_RCAR_CSI2
+   tristate "R-Car MIPI CSI-2 Receiver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
+   depends on ARCH_RENESAS || COMPILE_TEST
+   select V4L2_FWNODE
+   ---help---
+ Support for Renesas R-Car MIPI CSI-2 receiver.
+ Supports R-Car Gen3 SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called rcar-csi2.
+
 config VIDEO_RCAR_VIN
tristate "R-Car Video Input (VIN) Driver"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && 
MEDIA_CONTROLLER
diff --git a/drivers/media/platform/rcar-vin/Makefile 
b/drivers/media/platform/rcar-vin/Makefile
index 48c5632c21dc060b..5ab803d3e7c1aa57 100644
--- a/drivers/media/platform/rcar-vin/Makefile
+++ b/drivers/media/platform/rcar-vin/Makefile
@@ -1,3 +1,4 @@
 rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
 
+obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
 obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
b/drivers/media/platform/rcar-vin/rcar-csi2.c
new file mode 100644
index ..09a78dce29725a55
--- /dev/null
+++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
@@ -0,0 +1,822 @@
+/*
+ * Driver for Renesas R-Car MIPI CSI-2 Receiver
+ *
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register offsets and bits */
+
+/* Control Timing Select */
+#define TREF_REG   0x00
+#define TREF_TREF  (1 << 0)
+
+/* Software Reset */
+#define SRST_REG   0x04
+#define SRST_SRST  (1 << 0)
+
+/* PHY Operation Control */
+#define PHYCNT_REG 0x08
+#define PHYCNT_SHUTDOWNZ   (1 << 17)
+#define PHYCNT_RSTZ(1 << 16)
+#define PHYCNT_ENABLECLK   (1 << 4)
+#define PHYCNT_ENABLE_3(1 << 3)
+#define PHYCNT_ENABLE_2(1 << 2)
+#define PHYCNT_ENABLE_1(1 << 1)
+#define PHYCNT_ENABLE_0(1 << 0)
+
+/* Checksum Control */
+#define CHKSUM_REG 0x0c
+#define CHKSUM_ECC_EN  (1 << 1)
+#define CHKSUM_CRC_EN  (1 << 0)
+
+/*
+ * Channel Data Type Select
+ * VCDT[0-15]:  Channel 1 VCDT[16-31]:  Channel 2
+ * VCDT2[0-15]: Channel 3 VCDT2[16-31]: Channel 4
+ */
+#define VCDT_REG   0x10
+#define VCDT2_REG  0x14
+#define VCDT_VCDTN_EN  (1 << 15)
+#define VCDT_SEL_VC(n) (((n) & 0x3) << 8)
+#define VCDT_SEL_DTN_ON(1 << 6)
+#define VCDT_SEL_DT(n) (((n) & 0x3f) << 0)
+
+/* Frame Data Type Select */
+#define FRDT_REG   0x18
+
+/* Field Detection Control */
+#define FLD_REG0x1c
+#define FLD_FLD_NUM(n) (((n) & 0xff) << 16)
+#define FLD_FLD_EN4(1 << 3)
+#define FLD_FLD_EN3(1 << 2)
+#define FLD_FLD_EN2(1 << 1)
+#define FLD_FLD_EN (1 << 0)
+
+/* Automatic Standby Control */
+#define ASTBY_REG  0x20
+
+/* Long Data Type Setting 0 */
+#define LNGDT0_REG 0x28
+
+/* Long Data Type Setting 1 */
+#define LNGDT1_REG 0x2c
+
+/* Interrupt Enable */
+#define INTEN_REG  0x30
+
+/* Interrupt Source Mask */
+#define INTCLOSE_REG   0x34
+
+/* Interrupt Status Monitor */
+#define INTSTATE_REG   0x38
+
+/* Interrupt Error Status Monitor */
+#define INTERRSTATE_REG  

[PATCH v8 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

2017-07-17 Thread Niklas Söderlund
Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers
are located between the video sources (CSI-2 transmitters) and the video
grabbers (VIN) on Gen3 of Renesas R-Car SoC.

Each CSI-2 device is connected to more then one VIN device which
simultaneously can receive video from the same CSI-2 device. Each VIN
device can also be connected to more then one CSI-2 device. The routing
of which link are used are controlled by the VIN devices. There are only
a few possible routes which are set by hardware limitations, which are
different for each SoC in the Gen3 family.

To work with the limitations of routing possibilities it is necessary
for the DT bindings to describe which VIN device is connected to which
CSI-2 device. This is why port 1 needs to to assign reg numbers for each
VIN device that be connected to it. To setup and to know which links are
valid for each SoC is the responsibility of the VIN driver since the
register to configure it belongs to the VIN hardware.

Signed-off-by: Niklas Söderlund 
---
 .../devicetree/bindings/media/rcar-csi2.txt| 118 +
 1 file changed, 118 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt

diff --git a/Documentation/devicetree/bindings/media/rcar-csi2.txt 
b/Documentation/devicetree/bindings/media/rcar-csi2.txt
new file mode 100644
index ..c298a7d821153219
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rcar-csi2.txt
@@ -0,0 +1,118 @@
+Renesas R-Car MIPI CSI-2
+
+
+The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
+family of devices. It is to be used in conjunction with the R-Car VIN module,
+which provides the video capture capabilities.
+
+Mandatory properties
+
+ - compatible: Must be one or more of the following
+   - "renesas,r8a7795-csi2" for the R8A7795 device.
+   - "renesas,r8a7796-csi2" for the R8A7796 device.
+   - "renesas,rcar-gen3-csi2" for a generic R-Car Gen3 compatible device.
+
+   When compatible with a generic version nodes must list the
+   SoC-specific version corresponding to the platform first
+   followed by the generic version.
+
+ - reg: the register base and size for the device registers
+ - interrupts: the interrupt for the device
+ - clocks: Reference to the parent clock
+
+The device node shall contain two 'port' child nodes according to the
+bindings defined in Documentation/devicetree/bindings/media/
+video-interfaces.txt. Port 0 shall connect the node that is the video
+source for to the CSI-2. Port 1 shall connect all the R-Car VIN
+modules, which can make use of the CSI-2 module.
+
+- Port 0 - Video source (Mandatory)
+   - Reg 0 - sub-node describing the endpoint that is the video source
+
+- Port 1 - VIN instances (Mandatory for all VIN present in the SoC)
+   - Reg 0 - sub-node describing the endpoint that is VIN0
+   - Reg 1 - sub-node describing the endpoint that is VIN1
+   - Reg 2 - sub-node describing the endpoint that is VIN2
+   - Reg 3 - sub-node describing the endpoint that is VIN3
+   - Reg 4 - sub-node describing the endpoint that is VIN4
+   - Reg 5 - sub-node describing the endpoint that is VIN5
+   - Reg 6 - sub-node describing the endpoint that is VIN6
+   - Reg 7 - sub-node describing the endpoint that is VIN7
+
+Example:
+
+/* SoC properties */
+
+csi20: csi2@fea8 {
+compatible = "renesas,r8a7796-csi2";
+reg = <0 0xfea8 0 0x1>;
+interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+clocks = < CPG_MOD 714>;
+power-domains = < R8A7796_PD_ALWAYS_ON>;
+status = "disabled";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+reg = <1>;
+
+csi20vin0: endpoint@0 {
+reg = <0>;
+remote-endpoint = <>;
+};
+csi20vin1: endpoint@1 {
+reg = <1>;
+remote-endpoint = <>;
+};
+csi20vin2: endpoint@2 {
+reg = <2>;
+remote-endpoint = <>;
+};
+csi20vin3: endpoint@3 {
+reg = <3>;
+remote-endpoint = <>;
+};
+csi20vin4: endpoint@4 {
+  

[PATCH v8 0/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 support

2017-07-17 Thread Niklas Söderlund
Hi,

This is the latest incarnation of R-Car MIPI CSI-2 receiver driver. It's
based on top of the media-tree and are tested on Renesas Salvator-X together
with the out of tree patches for rcar-vin to add support for Gen3 VIN
and a driver for ADV7482. If anyone is interested to test
video grabbing using these out of tree patches please see [1].

It depends on the patches:

- [PATCH v4 0/3] v4l2-async: add subnotifier registration for subdevices

Changes since v7:
- Rebase on top of the latest incremental async patches.
- Fix comments on DT documentation.
- Use v4l2_ctrl_g_ctrl_int64() instead of v4l2_g_ext_ctrls().
- Handle try formats in .set_fmt() and .get_fmt().
- Don't call v4l2_device_register_subdev_nodes() as this is not needed 
  with the complete() callbacks synchronized.
- Fix line over 80 chars.
- Fix varies spelling mistakes.

Changes since v6:
- Rebased on top of Sakaris fwnode patches.
- Changed of RCAR_CSI2_PAD_MAX to NR_OF_RCAR_CSI2_PAD.
- Remove assumtion about unkown medis bus type, thanks Sakari for
  pointing this out.
- Created table for supported format information instead of scattering
  this information around the driver, thanks Sakari!
- Small newline fixes and reduce some indentation levels.

Changes since v5:
- Make use of the incremental async subnotifer and helper to map DT
  endpoint to media pad number. This moves functionality which
  previously in the Gen3 patches for R-Car VIN driver to this R-Car
  CSI-2 driver. This is done in preparation to support the ADV7482
  driver in development by Kieran which will register more then one
  subdevice and the CSI-2 driver needs to cope wit this. Further more it
  prepares the driver for another use-case where more then one subdevice
  is present upstream for the CSI-2.
- Small cleanups.
- Add explicit include for linux/io.h, thanks Kieran.

Changes since v4:
- Match SoC part numbers and drop trailing space in documentation,
  thanks Geert for pointing this out.
- Clarify that the driver is a CSI-2 receiver by supervised
  s/interface/receiver/, thanks Laurent.
- Add entries in Kconfig and Makefile alphabetically instead of append.
- Rename struct rcar_csi2 member swap to lane_swap.
- Remove macros to wrap calls to dev_{dbg,info,warn,err}.
- Add wrappers for ioread32 and iowrite32.
- Remove unused interrupt handler, but keep checking in probe that there
  are a interrupt define in DT.
- Rework how to wait for LP-11 state, thanks Laurent for the great idea!
- Remove unneeded delay in rcar_csi2_reset()
- Remove check for duplicated lane id:s from DT parsing. Broken out to a
  separate patch adding this check directly to v4l2_of_parse_endpoint().
- Fixed rcar_csi2_start() to ask it's source subdevice for information
  about pixel rate and frame format. With this change having
  {set,get}_fmt operations became redundant, it was only used for
  figuring out this out so dropped them.
- Tabulated frequency settings map.
- Dropped V4L2_SUBDEV_FL_HAS_DEVNODE it should never have been set.
- Switched from MEDIA_ENT_F_ATV_DECODER to
  MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER as entity function. I can't
  find a more suitable function, and what the hardware do is to fetch
  video from an external chip and passes it on to a another SoC internal
  IP it's sort of a formatter.
- Break out DT documentation and code in two patches.

Changes since v3:
- Update DT binding documentation with input from Geert Uytterhoeven,
  thanks!

Changes since v2:
- Added media control pads as this is needed by the new rcar-vin driver.
- Update DT bindings after review comments and to add r8a7796 support.
- Add get_fmt handler.
- Fix media bus format error s/YUYV8/UYVY8/

Changes since v1:
- Drop dependency on a pad aware s_stream operation.
- Use the DT bindings format "renesas,-", thanks Geert
  for pointing this out.

1. http://elinux.org/R-Car/Tests:rcar-vin

Niklas Söderlund (2):
  media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation
  media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

 .../devicetree/bindings/media/rcar-csi2.txt| 118 +++
 drivers/media/platform/rcar-vin/Kconfig|  12 +
 drivers/media/platform/rcar-vin/Makefile   |   1 +
 drivers/media/platform/rcar-vin/rcar-csi2.c| 822 +
 4 files changed, 953 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt
 create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c

-- 
2.13.1



[PATCH v4 3/3] v4l: async: add subnotifier to subdevices

2017-07-17 Thread Niklas Söderlund
Add a subdevice specific notifier which can be used by a subdevice
driver to compliment the master device notifier to extend the subdevice
discovery.

The master device registers the subdevices closest to itself in its
notifier while the subdevice(s) register notifiers for their closest
neighboring devices. Subdevice drivers configures a notifier at probe
time which are registered by the v4l2-async framework once the subdevice
itself is register, since it's only at this point the v4l2_dev is
available to the subnotifier.

Using this incremental approach two problems can be solved:

1. The master device no longer has to care how many devices exist in
   the pipeline. It only needs to care about its closest subdevice and
   arbitrary long pipelines can be created without having to adapt the
   master device for each case.

2. Subdevices which are represented as a single DT node but register
   more than one subdevice can use this to improve the pipeline
   discovery, since the subdevice driver is the only one who knows which
   of its subdevices is linked with which subdevice of a neighboring DT
   node.

To allow subdevices to provide its own list of subdevices to the
v4l2-async framework v4l2_async_subdev_register_notifier() is added.
This new function must be called before the subdevice itself is
registered with the v4l2-async framework using
v4l2_async_register_subdev().

Signed-off-by: Niklas Söderlund 
---
 Documentation/media/kapi/v4l2-subdev.rst |  12 +++
 drivers/media/v4l2-core/v4l2-async.c | 134 +--
 include/media/v4l2-async.h   |  25 ++
 include/media/v4l2-subdev.h  |   5 ++
 4 files changed, 168 insertions(+), 8 deletions(-)

diff --git a/Documentation/media/kapi/v4l2-subdev.rst 
b/Documentation/media/kapi/v4l2-subdev.rst
index e1f0b726e438f963..5957176965a6a3ef 100644
--- a/Documentation/media/kapi/v4l2-subdev.rst
+++ b/Documentation/media/kapi/v4l2-subdev.rst
@@ -262,6 +262,18 @@ is called. After all subdevices have been located the 
.complete() callback is
 called. When a subdevice is removed from the system the .unbind() method is
 called. All three callbacks are optional.
 
+Subdevice drivers might in turn register subnotifier objects with an
+array of other subdevice descriptors that the subdevice needs for its
+own operation. Subnotifiers are an extension of the bridge drivers
+notifier to allow for a incremental registering and matching of
+subdevices. This is useful when a driver only has information about
+which subdevice is closest to itself and would require knowledge from the
+driver of that subdevice to know which other subdevice(s) lie beyond.
+By registering subnotifiers drivers can incrementally move the subdevice
+matching down the chain of drivers. This is performed using the
+:c:func:`v4l2_async_subdev_register_notifier` call which must be performed
+before registering the subdevice using :c:func:`v4l2_async_register_subdev`.
+
 V4L2 sub-device userspace API
 -
 
diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 8fc84f7962386ddd..558fb3ec07e7fba8 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -100,6 +100,61 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct 
v4l2_async_notifier *
return NULL;
 }
 
+static int v4l2_async_notifier_complete(struct v4l2_async_notifier *notifier)
+{
+   struct v4l2_subdev *sd, *tmp;
+
+   if (!notifier->num_subdevs)
+   return 0;
+
+   list_for_each_entry_safe(sd, tmp, >done, async_list) {
+   v4l2_async_notifier_complete(>subnotifier);
+   }
+
+   if (notifier->complete)
+   return notifier->complete(notifier);
+
+   return 0;
+}
+
+static bool
+v4l2_async_is_notifier_complete(struct v4l2_async_notifier *notifier)
+{
+   struct v4l2_subdev *sd, *tmp;
+
+   if (!list_empty(>waiting))
+   return false;
+
+   list_for_each_entry_safe(sd, tmp, >done, async_list) {
+   /* Don't consider empty subnotifiers */
+   if (!sd->subnotifier.num_subdevs)
+   continue;
+
+   if (!v4l2_async_is_notifier_complete(>subnotifier))
+   return false;
+   }
+
+   return true;
+}
+
+static int
+v4l2_async_try_complete_notifier(struct v4l2_async_notifier *notifier)
+{
+   struct v4l2_async_notifier *root = notifier;
+
+   while (root->subnotifier) {
+   root = subnotifier_to_v4l2_subdev(root)->notifier;
+   /* No root notifier can be found at this time */
+   if (!root)
+   return 0;
+   }
+
+   if (v4l2_async_is_notifier_complete(root))
+   return v4l2_async_notifier_complete(root);
+
+   return 0;
+}
+
 static int v4l2_async_test_notify(struct v4l2_async_notifier *notifier,
   

[PATCH v4 1/3] v4l: async: fix unbind error in v4l2_async_notifier_unregister()

2017-07-17 Thread Niklas Söderlund
The call to v4l2_async_cleanup() will set sd->asd to NULL so passing it
to notifier->unbind() have no effect and leaves the notifier confused.
Call the unbind() callback prior to cleaning up the subdevice to avoid
this.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/v4l2-core/v4l2-async.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 851f128eba2219ad..0acf288d7227ba97 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -226,14 +226,14 @@ void v4l2_async_notifier_unregister(struct 
v4l2_async_notifier *notifier)
 
d = get_device(sd->dev);
 
+   if (notifier->unbind)
+   notifier->unbind(notifier, sd, sd->asd);
+
v4l2_async_cleanup(sd);
 
/* If we handled USB devices, we'd have to lock the parent too 
*/
device_release_driver(d);
 
-   if (notifier->unbind)
-   notifier->unbind(notifier, sd, sd->asd);
-
/*
 * Store device at the device cache, in order to call
 * put_device() on the final step
-- 
2.13.1



[PATCH v4 0/3] v4l2-async: add subnotifier registration for subdevices

2017-07-17 Thread Niklas Söderlund
Hi,

This is a rewrite of the feature since v3, maybe it should have been 
posted as a new series?

This series enables incremental async find and bind of subdevices,
please se patch 3/3 for a more detailed description of the new behavior, 
changelog in this cover letter for the differences to v3. The two 
primary reasons for a new implementation where:

1. Hans expressed an interest having the async complete() callbacks to 
   happen only once all notifiers in the pipeline where complete. To do 
   this a stronger connection between the notifiers where needed, hence 
   the subnotifier is now embedded in struct v4l2_subdev.

   Whit this change it is possible to check all notifiers in a pipeline 
   is complete before calling any of them.

2. There where concerns that the v3 solution was a bit to complex and 
   hard to refactor in the future if other issues in the v4l2-async 
   framework where to be addressed. By hiding the notifier in the struct 
   v4l2_subdev and adding a new function to set that structure the 
   interface towards drivers are minimized while everything else happens 
   in the v4l2-async framework. This leaves the interface in a good 
   position for possible changes in v4l2-async.

This is tested on Renesas H3 and M3-W together with the Renesas CSI-2
and VIN Gen3 driver (posted separately). It is based on top of the media-tree.

* Changes since v3
- Almost a complete rewrite, so drop all Ack-ed by tags.
- Do not add new functions to register/unregister subnotifiers from 
  callbacks. Instead have have the subdevice drivers populate the 
  subnotifer list at probe time and have the v4l2-async framework handle 
  the (un)registration of the notifiers.
- Synchronize the call off the complete() callbacks. They will now all 
  happens once all notifiers in a pipeline are all complete and from the 
  edge towards the root device.
- Add a new function v4l2_async_subdev_register_notifier() to hide the 
  setup of the subnotifier internals to ease improvements later.

* Changes since v2
- Fixed lots of spelling mistakes, thanks Hans!
- Used a goto instead if state variable when restarting iteration over
  subdev list as suggested by Sakari. Thank you it's much easier read
  now.
- Added Acked-by from Sakari and Hans, thanks!
- Rebased to latest media-tree.

* Changes since v1:
- Added a pre-patch which adds an error check which was previously in
  the new incremental async code but is more useful on its own.
- Added documentation to Documentation/media/kapi/v4l2-subdev.rst.
- Fixed data type of bool variable.
- Added call to lockdep_assert_held(), thanks Sakari.
- Fixed commit messages typo, thanks Sakari.

Niklas Söderlund (3):
  v4l: async: fix unbind error in v4l2_async_notifier_unregister()
  v4l: async: do not hold list_lock when reprobing devices
  v4l: async: add subnotifier to subdevices

 Documentation/media/kapi/v4l2-subdev.rst |  12 +++
 drivers/media/v4l2-core/v4l2-async.c | 165 +--
 include/media/v4l2-async.h   |  25 +
 include/media/v4l2-subdev.h  |   5 +
 4 files changed, 179 insertions(+), 28 deletions(-)

-- 
2.13.1



[PATCH v4 2/3] v4l: async: do not hold list_lock when reprobing devices

2017-07-17 Thread Niklas Söderlund
There is no good reason to hold the list_lock when reprobing the devices
and it prevents a clean implementation of subdevice notifiers. Move the
actual release of the devices outside of the loop which requires the
lock to be held.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/v4l2-core/v4l2-async.c | 29 ++---
 1 file changed, 10 insertions(+), 19 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 0acf288d7227ba97..8fc84f7962386ddd 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -206,7 +206,7 @@ void v4l2_async_notifier_unregister(struct 
v4l2_async_notifier *notifier)
unsigned int notif_n_subdev = notifier->num_subdevs;
unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
struct device **dev;
-   int i = 0;
+   int i, count = 0;
 
if (!notifier->v4l2_dev)
return;
@@ -222,37 +222,28 @@ void v4l2_async_notifier_unregister(struct 
v4l2_async_notifier *notifier)
list_del(>list);
 
list_for_each_entry_safe(sd, tmp, >done, async_list) {
-   struct device *d;
-
-   d = get_device(sd->dev);
+   if (dev)
+   dev[count] = get_device(sd->dev);
+   count++;
 
if (notifier->unbind)
notifier->unbind(notifier, sd, sd->asd);
 
v4l2_async_cleanup(sd);
+   }
 
-   /* If we handled USB devices, we'd have to lock the parent too 
*/
-   device_release_driver(d);
+   mutex_unlock(_lock);
 
-   /*
-* Store device at the device cache, in order to call
-* put_device() on the final step
-*/
+   for (i = 0; i < count; i++) {
+   /* If we handled USB devices, we'd have to lock the parent too 
*/
if (dev)
-   dev[i++] = d;
-   else
-   put_device(d);
+   device_release_driver(dev[i]);
}
 
-   mutex_unlock(_lock);
-
/*
 * Call device_attach() to reprobe devices
-*
-* NOTE: If dev allocation fails, i is 0, and the whole loop won't be
-* executed.
 */
-   while (i--) {
+   for (i = 0; dev && i < count; i++) {
struct device *d = dev[i];
 
if (d && device_attach(d) < 0) {
-- 
2.13.1



Re: [PATCH 2/6] ARM: shmobile_defconfig: Cleanup from non-existing options

2017-07-17 Thread Krzysztof Kozlowski
On Mon, Jul 17, 2017 at 09:29:24AM +0200, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> On Mon, Jul 17, 2017 at 7:49 AM, Krzysztof Kozlowski  wrote:
> > Remove options which do not exist anymore:
> >  - DRM_RCAR_HDMI was merged to generic DRM bridge and is obsolete since
> >commit 5c602531feb3 ("drm: rcar-du: Replace manual bridge
> >implementation with DRM bridge");
> >
> >  - SND_SOC_RSRC_CARD was replaced by SND_SIMPLE_SCU_CARD in commit
> >d12c6216c4a5 ("ASoC: rsrc-card: rename rsrc-card to simple-scu-card
> >phase3");
> >
> > Signed-off-by: Krzysztof Kozlowski 
> 
> These have already be fixed in the defconfig-for-v4.14 branch Simon Horman's
> tree (git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git).
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/log/?h=defconfig-for-v4.14
> 
> They're not yet in -next as v4.13-rc1 wasn't released at that time, and
> Simon is now on holidays.

Ahhh, thanks for noticing this!

Best regards,
Krzysztof



Applied "spi: sh-msiof: Add support for R-Car H3" to the spi tree

2017-07-17 Thread Mark Brown
The patch

   spi: sh-msiof: Add support for R-Car H3

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 3d108f1e2d4c21026750cd4107e03b3e7a3e98a0 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven 
Date: Wed, 12 Jul 2017 12:24:07 +0200
Subject: [PATCH] spi: sh-msiof: Add support for R-Car H3

Add support for MSIOF in r8a7795 (R-Car H3).
Due to a hardware erratum on R-Car H3 ES1.x, this is only supported on
ES2.0 and later.

No driver update is needed.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Mark Brown 
---
 Documentation/devicetree/bindings/spi/sh-msiof.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt 
b/Documentation/devicetree/bindings/spi/sh-msiof.txt
index 64ee489571c4..39e5ef7c5e71 100644
--- a/Documentation/devicetree/bindings/spi/sh-msiof.txt
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -6,6 +6,7 @@ Required properties:
 "renesas,msiof-r8a7792" (R-Car V2H)
 "renesas,msiof-r8a7793" (R-Car M2-N)
 "renesas,msiof-r8a7794" (R-Car E2)
+"renesas,msiof-r8a7795" (R-Car H3)
 "renesas,msiof-r8a7796" (R-Car M3-W)
 "renesas,msiof-sh73a0" (SH-Mobile AG5)
 "renesas,sh-mobile-msiof" (generic SH-Mobile 
compatibile device)
-- 
2.13.2



Re: [PATCH net-next repost v2] dt-bindings: net: ravb : Add support for r8a7743 SoC

2017-07-17 Thread David Miller
From: Biju Das 
Date: Mon, 17 Jul 2017 09:33:52 +0100

> Add a new compatible string for the RZ/G1M (R8A7743) SoC.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Simon Horman 

Applied.


[RFC v2 6/6] ARM: dts: blanche: add SCIF1 and MAX9260 deserializer

2017-07-17 Thread Ulrich Hecht
Adds serial port SCIF1 and the MAX9260 deserializers connected to it.

Signed-off-by: Ulrich Hecht 
---
 arch/arm/boot/dts/r8a7792-blanche.dts | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7792-blanche.dts 
b/arch/arm/boot/dts/r8a7792-blanche.dts
index 9b67dca..2ae9a87 100644
--- a/arch/arm/boot/dts/r8a7792-blanche.dts
+++ b/arch/arm/boot/dts/r8a7792-blanche.dts
@@ -21,6 +21,7 @@
aliases {
serial0 = 
serial1 = 
+   serial2 = 
};
 
chosen {
@@ -186,6 +187,16 @@
gpio = < 12 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+   mux: mux-controller {
+   compatible = "gpio-mux";
+   #mux-control-cells = <0>;
+
+   mux-gpios = < 12 GPIO_ACTIVE_HIGH>,
+   < 13 GPIO_ACTIVE_HIGH>,
+   < 14 GPIO_ACTIVE_HIGH>,
+   < 15 GPIO_ACTIVE_HIGH>;
+   };
 };
 
 _clk {
@@ -202,6 +213,11 @@
function = "scif0";
};
 
+   scif1_pins: scif1 {
+   groups = "scif1_data";
+   function = "scif1";
+   };
+
scif3_pins: scif3 {
groups = "scif3_data";
function = "scif3";
@@ -246,6 +262,42 @@
status = "okay";
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+
+   mux-controls = <>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   gmsl-deserializer@0 {
+   compatible = "maxim,max9260";
+   reg = <0x8>;
+   };
+   gmsl-deserializer@1 {
+   compatible = "maxim,max9260";
+   reg = <0x9>;
+   };
+   gmsl-deserializer@2 {
+   compatible = "maxim,max9260";
+   reg = <0xa>;
+   };
+   gmsl-deserializer@3 {
+   compatible = "maxim,max9260";
+   reg = <0xb>;
+   };
+   gmsl-deserializer@4 {
+   compatible = "maxim,max9260";
+   reg = <0x4>;
+   };
+   gmsl-deserializer@5 {
+   compatible = "maxim,max9260";
+   reg = <0x5>;
+   };
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
2.7.4



[RFC v2 5/6] max9260: add driver for i2c over GMSL passthrough

2017-07-17 Thread Ulrich Hecht
This driver implements tunnelling of i2c requests over GMSL via a
MAX9260 deserializer. It provides an i2c adapter that can be used
to reach devices on the far side of the link.

Signed-off-by: Ulrich Hecht 
---
 drivers/media/i2c/Kconfig   |   6 +
 drivers/media/i2c/Makefile  |   1 +
 drivers/media/i2c/max9260.c | 288 
 3 files changed, 295 insertions(+)
 create mode 100644 drivers/media/i2c/max9260.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 7641667..a405d67 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -423,6 +423,12 @@ config VIDEO_VPX3220
  To compile this driver as a module, choose M here: the
  module will be called vpx3220.
 
+config VIDEO_MAX9260
+   tristate "Maxim MAX9260 GMSL deserializer support"
+   depends on I2C
+   ---help---
+ This driver supports the Maxim MAX9260 GMSL deserializer.
+
 comment "Video and audio decoders"
 
 config VIDEO_SAA717X
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 30e856c..3b6f6f2 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
 obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
+obj-$(CONFIG_VIDEO_MAX9260) += max9260.o
 obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
 obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
 obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
diff --git a/drivers/media/i2c/max9260.c b/drivers/media/i2c/max9260.c
new file mode 100644
index 000..ca34e67
--- /dev/null
+++ b/drivers/media/i2c/max9260.c
@@ -0,0 +1,288 @@
+/*
+ * Maxim MAX9260 GMSL Deserializer Driver
+ *
+ * Copyright (C) 2017 Ulrich Hecht
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SYNC   0x79
+#define ACK0xc3
+
+#define RX_FINISHED0
+#define RX_FRAME_ERROR 1
+#define RX_EXPECT_ACK  2
+#define RX_EXPECT_ACK_DATA 3
+#define RX_EXPECT_DATA 4
+
+struct max9260_device {
+   struct serdev_device *serdev;
+   u8 *rx_buf;
+   int rx_len;
+   int rx_state;
+   wait_queue_head_t rx_wq;
+   struct i2c_adapter adap;
+};
+
+static void wait_for_transaction(struct max9260_device *dev)
+{
+   wait_event_interruptible_timeout(dev->rx_wq,
+   dev->rx_state <= RX_FRAME_ERROR,
+   HZ/2);
+}
+
+static void max9260_transact(struct max9260_device *dev,
+int expect,
+u8 *request, int len)
+{
+   serdev_device_mux_select(dev->serdev);
+
+   serdev_device_set_baudrate(dev->serdev, 115200);
+   serdev_device_set_parity(dev->serdev, 1, 0);
+
+   dev->rx_state = expect;
+   serdev_device_write_buf(dev->serdev, request, len);
+
+   wait_for_transaction(dev);
+
+   serdev_device_mux_deselect(dev->serdev);
+}
+
+static int max9260_read_reg(struct max9260_device *dev, int reg)
+{
+   u8 request[] = { 0x79, 0x91, reg, 1 };
+   u8 rx;
+
+   dev->rx_len = 1;
+   dev->rx_buf = 
+
+   max9260_transact(dev, RX_EXPECT_ACK_DATA, request, 4);
+
+   if (dev->rx_state == RX_FINISHED)
+   return rx;
+
+   return -EIO;
+}
+
+static int max9260_setup(struct max9260_device *dev)
+{
+   int ret;
+
+   ret = max9260_read_reg(dev, 0x1e);
+
+   if (ret != 0x02) {
+   dev_err(>serdev->dev,
+   "device does not identify as MAX9260\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static void max9260_uart_write_wakeup(struct serdev_device *serdev)
+{
+}
+
+static int max9260_uart_receive_buf(struct serdev_device *serdev,
+   const u8 *data, size_t count)
+{
+   struct max9260_device *dev = serdev_device_get_drvdata(serdev);
+   int accepted;
+
+   switch (dev->rx_state) {
+   case RX_FINISHED:
+   dev_dbg(>serdev->dev, "excess data ignored\n");
+   return count;
+
+   case RX_EXPECT_ACK:
+   case RX_EXPECT_ACK_DATA:
+   if (data[0] != ACK) {
+   dev_dbg(>serdev->dev, "frame error");
+   dev->rx_state = RX_FRAME_ERROR;
+   wake_up_interruptible(>rx_wq);
+   return 1;
+   }
+
+   if (dev->rx_state == RX_EXPECT_ACK_DATA) {
+   dev->rx_state = RX_EXPECT_DATA;
+   } else {
+   dev->rx_state = RX_FINISHED;
+   wake_up_interruptible(>rx_wq);

[RFC v2 4/6] serial: core: support deferring serdev controller registration

2017-07-17 Thread Ulrich Hecht
serdev controllers may depend on other devices (such as multiplexers)
and thus require deferred probing support.

Signed-off-by: Ulrich Hecht 
---
 drivers/tty/serial/serial_core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index f534a40..30a8997 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2785,6 +2785,10 @@ int uart_add_one_port(struct uart_driver *drv, struct 
uart_port *uport)
uport->line, uport->dev, port, uport->tty_groups);
if (likely(!IS_ERR(tty_dev))) {
device_set_wakeup_capable(tty_dev, 1);
+   } else if (PTR_ERR(tty_dev) == -EPROBE_DEFER) {
+   ret = -EPROBE_DEFER;
+   state->uart_port = NULL;
+   goto out;
} else {
dev_err(uport->dev, "Cannot register tty device on line %d\n",
   uport->line);
-- 
2.7.4



[RFC v2 2/6] serdev: add method to set parity

2017-07-17 Thread Ulrich Hecht
Adds serdev_device_set_parity() and an implementation for ttyport.

Signed-off-by: Ulrich Hecht 
---
 drivers/tty/serdev/core.c   | 12 
 drivers/tty/serdev/serdev-ttyport.c | 17 +
 include/linux/serdev.h  |  4 
 3 files changed, 33 insertions(+)

diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index f71b473..1fbaa4c 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -242,6 +242,18 @@ int serdev_device_set_tiocm(struct serdev_device *serdev, 
int set, int clear)
 }
 EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
 
+int serdev_device_set_parity(struct serdev_device *serdev,
+bool enable, bool odd)
+{
+   struct serdev_controller *ctrl = serdev->ctrl;
+
+   if (!ctrl || !ctrl->ops->set_parity)
+   return -ENOTSUPP;
+
+   return ctrl->ops->set_parity(ctrl, enable, odd);
+}
+EXPORT_SYMBOL_GPL(serdev_device_set_parity);
+
 static int serdev_drv_probe(struct device *dev)
 {
const struct serdev_device_driver *sdrv = 
to_serdev_device_driver(dev->driver);
diff --git a/drivers/tty/serdev/serdev-ttyport.c 
b/drivers/tty/serdev/serdev-ttyport.c
index 302018d..9114956 100644
--- a/drivers/tty/serdev/serdev-ttyport.c
+++ b/drivers/tty/serdev/serdev-ttyport.c
@@ -195,6 +195,22 @@ static int ttyport_set_tiocm(struct serdev_controller 
*ctrl, unsigned int set, u
return tty->driver->ops->tiocmset(tty, set, clear);
 }
 
+static int ttyport_set_parity(struct serdev_controller *ctrl,
+ bool enable, bool odd)
+{
+   struct serport *serport = serdev_controller_get_drvdata(ctrl);
+   struct tty_struct *tty = serport->tty;
+   struct ktermios ktermios = tty->termios;
+
+   ktermios.c_cflag &= ~(PARENB | PARODD);
+   if (enable)
+   ktermios.c_cflag |= PARENB;
+   if (odd)
+   ktermios.c_cflag |= PARODD;
+
+   return tty_set_termios(tty, );
+}
+
 static const struct serdev_controller_ops ctrl_ops = {
.write_buf = ttyport_write_buf,
.write_flush = ttyport_write_flush,
@@ -206,6 +222,7 @@ static const struct serdev_controller_ops ctrl_ops = {
.wait_until_sent = ttyport_wait_until_sent,
.get_tiocm = ttyport_get_tiocm,
.set_tiocm = ttyport_set_tiocm,
+   .set_parity = ttyport_set_parity,
 };
 
 struct device *serdev_tty_port_register(struct tty_port *port,
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index e69402d..8b67fcd 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -90,6 +90,7 @@ struct serdev_controller_ops {
void (*wait_until_sent)(struct serdev_controller *, long);
int (*get_tiocm)(struct serdev_controller *);
int (*set_tiocm)(struct serdev_controller *, unsigned int, unsigned 
int);
+   int (*set_parity)(struct serdev_controller *, bool, bool);
 };
 
 /**
@@ -298,6 +299,9 @@ static inline int serdev_device_set_rts(struct 
serdev_device *serdev, bool enabl
return serdev_device_set_tiocm(serdev, 0, TIOCM_RTS);
 }
 
+int serdev_device_set_parity(struct serdev_device *serdev,
+bool enable, bool odd);
+
 /*
  * serdev hooks into TTY core
  */
-- 
2.7.4



[RFC v2 0/6] serdev multiplexing support

2017-07-17 Thread Ulrich Hecht
Hi!

This is a new attempt to add multiplexer support to serdev. It is now based
on the mux subsystem, making it more generic than the previous iteration
("[RFC 0/4] serdev GPIO-based multiplexing support").

Thanks to reviewers for their comments. This revision incorporates the
changes suggested as far as they are still applicable, which mostly applies
to those concerning the MAX9260 i2c adapter driver.

New patches have been added that fix a small issue in the mux include files
("mux: include compiler.h from mux/consumer.h"), and implement deferred
probing of serdev controllers ("serial: core: support deferring serdev
controller registration"), hopefully correctly.

This series depends on the "pinctrl: sh-pfc: r8a7792: Add SCIF1 pin groups"
patch as well as v15 of the mux subsystem series ("[PATCH v15 00/13] mux
controller abstraction and iio/i2c muxes").

CU
Uli


Ulrich Hecht (6):
  mux: include compiler.h from mux/consumer.h
  serdev: add method to set parity
  serdev: add multiplexer support
  serial: core: support deferring serdev controller registration
  max9260: add driver for i2c over GMSL passthrough
  ARM: dts: blanche: add SCIF1 and MAX9260 deserializer

 arch/arm/boot/dts/r8a7792-blanche.dts |  52 ++
 drivers/media/i2c/Kconfig |   6 +
 drivers/media/i2c/Makefile|   1 +
 drivers/media/i2c/max9260.c   | 288 ++
 drivers/tty/serdev/Kconfig|   3 +
 drivers/tty/serdev/Makefile   |   1 +
 drivers/tty/serdev/core.c |  26 ++-
 drivers/tty/serdev/mux.c  |  66 
 drivers/tty/serdev/serdev-ttyport.c   |  17 ++
 drivers/tty/serial/serial_core.c  |   4 +
 include/linux/mux/consumer.h  |   2 +
 include/linux/serdev.h|  20 ++-
 12 files changed, 482 insertions(+), 4 deletions(-)
 create mode 100644 drivers/media/i2c/max9260.c
 create mode 100644 drivers/tty/serdev/mux.c

-- 
2.7.4



[RFC v2 3/6] serdev: add multiplexer support

2017-07-17 Thread Ulrich Hecht
Adds an interface for slave device multiplexing using the mux subsystem.

Signed-off-by: Ulrich Hecht 
---
 drivers/tty/serdev/Kconfig  |  3 +++
 drivers/tty/serdev/Makefile |  1 +
 drivers/tty/serdev/core.c   | 14 +-
 drivers/tty/serdev/mux.c| 66 +
 include/linux/serdev.h  | 16 ---
 5 files changed, 96 insertions(+), 4 deletions(-)
 create mode 100644 drivers/tty/serdev/mux.c

diff --git a/drivers/tty/serdev/Kconfig b/drivers/tty/serdev/Kconfig
index cdc6b82..9096b71 100644
--- a/drivers/tty/serdev/Kconfig
+++ b/drivers/tty/serdev/Kconfig
@@ -13,4 +13,7 @@ config SERIAL_DEV_CTRL_TTYPORT
depends on TTY
depends on SERIAL_DEV_BUS != m
 
+config SERIAL_DEV_MUX
+   bool "Serial device multiplexer support"
+
 endif
diff --git a/drivers/tty/serdev/Makefile b/drivers/tty/serdev/Makefile
index 0cbdb94..d713381 100644
--- a/drivers/tty/serdev/Makefile
+++ b/drivers/tty/serdev/Makefile
@@ -1,5 +1,6 @@
 serdev-objs := core.o
 
 obj-$(CONFIG_SERIAL_DEV_BUS) += serdev.o
+obj-$(CONFIG_SERIAL_DEV_MUX) += mux.o
 
 obj-$(CONFIG_SERIAL_DEV_CTRL_TTYPORT) += serdev-ttyport.o
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index 1fbaa4c..92c5bfa 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -305,7 +305,8 @@ struct serdev_device *serdev_device_alloc(struct 
serdev_controller *ctrl)
return NULL;
 
serdev->ctrl = ctrl;
-   ctrl->serdev = serdev;
+   if (!ctrl->serdev)
+   ctrl->serdev = serdev;
device_initialize(>dev);
serdev->dev.parent = >dev;
serdev->dev.bus = _bus_type;
@@ -368,6 +369,8 @@ static int of_serdev_register_devices(struct 
serdev_controller *ctrl)
struct serdev_device *serdev = NULL;
int err;
bool found = false;
+   int nr = 0;
+   u32 reg;
 
for_each_available_child_of_node(ctrl->dev.of_node, node) {
if (!of_get_property(node, "compatible", NULL))
@@ -380,6 +383,10 @@ static int of_serdev_register_devices(struct 
serdev_controller *ctrl)
continue;
 
serdev->dev.of_node = node;
+   serdev->nr = nr++;
+
+   if (!of_property_read_u32(node, "reg", ))
+   serdev->mux_addr = reg;
 
err = serdev_device_add(serdev);
if (err) {
@@ -414,6 +421,11 @@ int serdev_controller_add(struct serdev_controller *ctrl)
if (ret)
return ret;
 
+#ifdef CONFIG_SERIAL_DEV_MUX
+   if (of_serdev_register_mux(ctrl) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+#endif
+
ret = of_serdev_register_devices(ctrl);
if (ret)
goto out_dev_del;
diff --git a/drivers/tty/serdev/mux.c b/drivers/tty/serdev/mux.c
new file mode 100644
index 000..fc9405b
--- /dev/null
+++ b/drivers/tty/serdev/mux.c
@@ -0,0 +1,66 @@
+/*
+ * Copyright (C) 2017 Ulrich Hecht
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int serdev_device_mux_select(struct serdev_device *serdev)
+{
+   struct mux_control *mux = serdev->ctrl->mux;
+   int ret;
+
+   if (!mux)
+   return -EINVAL;
+
+   ret = mux_control_select(mux, serdev->mux_addr);
+   serdev->ctrl->mux_do_not_deselect = ret < 0;
+
+   serdev->ctrl->serdev = serdev;
+
+   return ret;
+}
+
+int serdev_device_mux_deselect(struct serdev_device *serdev)
+{
+   struct mux_control *mux = serdev->ctrl->mux;
+
+   if (!mux)
+   return -EINVAL;
+
+   if (!serdev->ctrl->mux_do_not_deselect)
+   return mux_control_deselect(mux);
+   else
+   return 0;
+}
+
+int of_serdev_register_mux(struct serdev_controller *ctrl)
+{
+   struct mux_control *mux;
+   struct device *dev = >dev;
+
+   mux = devm_mux_control_get(dev, NULL);
+
+   if (IS_ERR(mux)) {
+   if (PTR_ERR(mux) != -EPROBE_DEFER)
+   dev_err(dev, "failed to get control mux\n");
+   return PTR_ERR(mux);
+   }
+
+   ctrl->mux = mux;
+
+   return 0;
+}
+
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 8b67fcd..26d5994 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct serdev_controller;
 struct serdev_device;
@@ -51,6 +52,7 @@ struct serdev_device {
const struct 

[RFC v2 1/6] mux: include compiler.h from mux/consumer.h

2017-07-17 Thread Ulrich Hecht
Required for __must_check.

Signed-off-by: Ulrich Hecht 
---
 include/linux/mux/consumer.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/mux/consumer.h b/include/linux/mux/consumer.h
index 5577e1b..ea96d4c 100644
--- a/include/linux/mux/consumer.h
+++ b/include/linux/mux/consumer.h
@@ -13,6 +13,8 @@
 #ifndef _LINUX_MUX_CONSUMER_H
 #define _LINUX_MUX_CONSUMER_H
 
+#include 
+
 struct device;
 struct mux_control;
 
-- 
2.7.4



[PATCH 5/5] watchdog: renesas_wdt: add another divider option

2017-07-17 Thread Wolfram Sang
If we set RWTCSRB to 0, we can gain 4096 as another divider value. This
is supported by all R-Car Gen2 and Gen3 devices which we aim to support.

Signed-off-by: Wolfram Sang 
---
 drivers/watchdog/renesas_wdt.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
index 599ba5aaa0536f..e3f204bb8802aa 100644
--- a/drivers/watchdog/renesas_wdt.c
+++ b/drivers/watchdog/renesas_wdt.c
@@ -23,21 +23,22 @@
 #define RWTCSRA_WOVF   BIT(4)
 #define RWTCSRA_WRFLG  BIT(5)
 #define RWTCSRA_TMEBIT(7)
+#define RWTCSRB8
 
 #define RWDT_DEFAULT_TIMEOUT 60U
 
 /*
  * In probe, clk_rate is checked to be not more than 16 bit * biggest clock
- * divider (10 bits). d is only a factor to fully utilize the WDT counter and
+ * divider (12 bits). d is only a factor to fully utilize the WDT counter and
  * will not exceed its 16 bits. Thus, no overflow, we stay below 32 bits.
  */
 #define MUL_BY_CLKS_PER_SEC(p, d) \
DIV_ROUND_UP((d) * (p)->clk_rate, clk_divs[(p)->cks])
 
-/* d is 16 bit, clk_divs 10 bit -> no 32 bit overflow */
+/* d is 16 bit, clk_divs 12 bit -> no 32 bit overflow */
 #define DIV_BY_CLKS_PER_SEC(p, d) ((d) * clk_divs[(p)->cks] / (p)->clk_rate)
 
-static const unsigned int clk_divs[] = { 1, 4, 16, 32, 64, 128, 1024 };
+static const unsigned int clk_divs[] = { 1, 4, 16, 32, 64, 128, 1024, 4096 };
 
 static bool nowayout = WATCHDOG_NOWAYOUT;
 module_param(nowayout, bool, 0);
@@ -77,6 +78,7 @@ static int rwdt_start(struct watchdog_device *wdev)
 
clk_prepare_enable(priv->clk);
 
+   rwdt_write(priv, 0, RWTCSRB);
rwdt_write(priv, priv->cks, RWTCSRA);
rwdt_init_timeout(wdev);
 
-- 
2.11.0



[PATCH 4/5] watchdog: renesas_wdt: apply better precision

2017-07-17 Thread Wolfram Sang
The error margin of the clks_per_second variable was too large and
caused offsets when used with clock frequencies which left a remainder
after applying the dividers. Now we always calculate directly using the
clock rate and the divider using some helper macros. That also means
that DIV_ROUND_UP moves from probe to the multiplication macro. In
probe, we don't need to ensure anymore that 'clks_per_sec' would go too
fast but rather ensure that the lower limit is really at least 1 to
certainly get a full cycle.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Wolfram Sang 
---
 drivers/watchdog/renesas_wdt.c | 28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
index d2390695d3453f..599ba5aaa0536f 100644
--- a/drivers/watchdog/renesas_wdt.c
+++ b/drivers/watchdog/renesas_wdt.c
@@ -26,6 +26,17 @@
 
 #define RWDT_DEFAULT_TIMEOUT 60U
 
+/*
+ * In probe, clk_rate is checked to be not more than 16 bit * biggest clock
+ * divider (10 bits). d is only a factor to fully utilize the WDT counter and
+ * will not exceed its 16 bits. Thus, no overflow, we stay below 32 bits.
+ */
+#define MUL_BY_CLKS_PER_SEC(p, d) \
+   DIV_ROUND_UP((d) * (p)->clk_rate, clk_divs[(p)->cks])
+
+/* d is 16 bit, clk_divs 10 bit -> no 32 bit overflow */
+#define DIV_BY_CLKS_PER_SEC(p, d) ((d) * clk_divs[(p)->cks] / (p)->clk_rate)
+
 static const unsigned int clk_divs[] = { 1, 4, 16, 32, 64, 128, 1024 };
 
 static bool nowayout = WATCHDOG_NOWAYOUT;
@@ -37,7 +48,7 @@ struct rwdt_priv {
void __iomem *base;
struct watchdog_device wdev;
struct clk *clk;
-   unsigned int clks_per_sec;
+   unsigned long clk_rate;
u8 cks;
 };
 
@@ -55,7 +66,7 @@ static int rwdt_init_timeout(struct watchdog_device *wdev)
 {
struct rwdt_priv *priv = watchdog_get_drvdata(wdev);
 
-   rwdt_write(priv, 65536 - wdev->timeout * priv->clks_per_sec, RWTCNT);
+   rwdt_write(priv, 65536 - MUL_BY_CLKS_PER_SEC(priv, wdev->timeout), 
RWTCNT);
 
return 0;
 }
@@ -92,7 +103,7 @@ static unsigned int rwdt_get_timeleft(struct watchdog_device 
*wdev)
struct rwdt_priv *priv = watchdog_get_drvdata(wdev);
u16 val = readw_relaxed(priv->base + RWTCNT);
 
-   return (65536 - val) / priv->clks_per_sec;
+   return DIV_BY_CLKS_PER_SEC(priv, 65536 - val);
 }
 
 static const struct watchdog_info rwdt_ident = {
@@ -112,7 +123,7 @@ static int rwdt_probe(struct platform_device *pdev)
 {
struct rwdt_priv *priv;
struct resource *res;
-   unsigned long rate, clks_per_sec;
+   unsigned long clks_per_sec;
int ret, i;
 
priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
@@ -128,14 +139,13 @@ static int rwdt_probe(struct platform_device *pdev)
if (IS_ERR(priv->clk))
return PTR_ERR(priv->clk);
 
-   rate = clk_get_rate(priv->clk);
-   if (!rate)
+   priv->clk_rate = clk_get_rate(priv->clk);
+   if (!priv->clk_rate)
return -ENOENT;
 
for (i = ARRAY_SIZE(clk_divs) - 1; i >= 0; i--) {
-   clks_per_sec = DIV_ROUND_UP(rate, clk_divs[i]);
+   clks_per_sec = priv->clk_rate / clk_divs[i];
if (clks_per_sec && clks_per_sec < 65536) {
-   priv->clks_per_sec = clks_per_sec;
priv->cks = i;
break;
}
@@ -153,7 +163,7 @@ static int rwdt_probe(struct platform_device *pdev)
priv->wdev.ops = _ops,
priv->wdev.parent = >dev;
priv->wdev.min_timeout = 1;
-   priv->wdev.max_timeout = 65536 / clks_per_sec;
+   priv->wdev.max_timeout = DIV_BY_CLKS_PER_SEC(priv, 65536);
priv->wdev.timeout = min(priv->wdev.max_timeout, RWDT_DEFAULT_TIMEOUT);
 
platform_set_drvdata(pdev, priv);
-- 
2.11.0



[PATCH 0/5] watchdog: renesas_wdt: improve precision

2017-07-17 Thread Wolfram Sang
Currently, the renesas-rwdt driver is not precise with input clocks which have
a remainder after the clock divisors are applied. This series should fix the
situation and also pays attention to ensure variables have proper types and are
divided properly. As a cherry on top, we also get a new divider value to allow
for higher max_timeout :)

Originally brought to attention by this BSP patch:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=7d56256a4d189a83e278ec2013eb1f3648bc7411

Tested with a Salvator-X (R-Car M3-W) and the clock driver hacked to supply the
internal clock of 32552 Hz instead of the externally supplied 32768 Hz.

A branch can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
renesas/watchdog-fixes

Please comment or apply...

Thanks,

   Wolfram


Wolfram Sang (5):
  watchdog: renesas_wdt: avoid (theoretical) type overflow
  watchdog: renesas_wdt: check rate also for upper limit
  watchdog: renesas_wdt: don't round closest with get_timeleft
  watchdog: renesas_wdt: apply better precision
  watchdog: renesas_wdt: add another divider option

 drivers/watchdog/renesas_wdt.c | 37 -
 1 file changed, 24 insertions(+), 13 deletions(-)

-- 
2.11.0



[PATCH 1/5] watchdog: renesas_wdt: avoid (theoretical) type overflow

2017-07-17 Thread Wolfram Sang
Because the smallest clock divider we can select is 1, 'clks_per_sec'
must be the same type as 'rate'.

Signed-off-by: Wolfram Sang 
---
 drivers/watchdog/renesas_wdt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
index cf61c92f7ecd63..4f8a3563b6aa53 100644
--- a/drivers/watchdog/renesas_wdt.c
+++ b/drivers/watchdog/renesas_wdt.c
@@ -112,8 +112,7 @@ static int rwdt_probe(struct platform_device *pdev)
 {
struct rwdt_priv *priv;
struct resource *res;
-   unsigned long rate;
-   unsigned int clks_per_sec;
+   unsigned long rate, clks_per_sec;
int ret, i;
 
priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
-- 
2.11.0



[PATCH 3/5] watchdog: renesas_wdt: don't round closest with get_timeleft

2017-07-17 Thread Wolfram Sang
We should never return more time left than there actually is. So, switch
to a plain divider instead of DIV_ROUND_CLOSEST.

Signed-off-by: Wolfram Sang 
---
 drivers/watchdog/renesas_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
index 0b9e8a9b1dd14c..d2390695d3453f 100644
--- a/drivers/watchdog/renesas_wdt.c
+++ b/drivers/watchdog/renesas_wdt.c
@@ -92,7 +92,7 @@ static unsigned int rwdt_get_timeleft(struct watchdog_device 
*wdev)
struct rwdt_priv *priv = watchdog_get_drvdata(wdev);
u16 val = readw_relaxed(priv->base + RWTCNT);
 
-   return DIV_ROUND_CLOSEST(65536 - val, priv->clks_per_sec);
+   return (65536 - val) / priv->clks_per_sec;
 }
 
 static const struct watchdog_info rwdt_ident = {
-- 
2.11.0



[PATCH 2/5] watchdog: renesas_wdt: check rate also for upper limit

2017-07-17 Thread Wolfram Sang
When checking the clock rate, ensure also that counting all 16 bits
takes at least one second to match the granularity of the framework.

Signed-off-by: Wolfram Sang 
---
 drivers/watchdog/renesas_wdt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
index 4f8a3563b6aa53..0b9e8a9b1dd14c 100644
--- a/drivers/watchdog/renesas_wdt.c
+++ b/drivers/watchdog/renesas_wdt.c
@@ -134,14 +134,14 @@ static int rwdt_probe(struct platform_device *pdev)
 
for (i = ARRAY_SIZE(clk_divs) - 1; i >= 0; i--) {
clks_per_sec = DIV_ROUND_UP(rate, clk_divs[i]);
-   if (clks_per_sec) {
+   if (clks_per_sec && clks_per_sec < 65536) {
priv->clks_per_sec = clks_per_sec;
priv->cks = i;
break;
}
}
 
-   if (!clks_per_sec) {
+   if (i < 0) {
dev_err(>dev, "Can't find suitable clock divider\n");
return -ERANGE;
}
-- 
2.11.0



Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

2017-07-17 Thread Hans Verkuil
On 17/07/17 16:26, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuil  wrote:
>> On 14/07/17 11:36, Arnd Bergmann wrote:
>>> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
>>> void *fh,
>>>* digitizer/slicer.  Note, cx18_av_vbi() wipes the passed in
>>>* fmt->fmt.sliced under valid calling conditions
>>>*/
>>> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced))
>>> - return -EINVAL;
>>> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, 
>>> >fmt.sliced);
>>> + if (ret)
>>> + return ret;
>>
>> Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' 
>> wouldn't
>> break something.
> 
> I think Dan was recommending the opposite here, if I understood you
> both correctly:
> he said we should propagate the error code unless we know it's wrong, while 
> you
> want to keep the current behavior to avoid introducing changes ;-)
> 
> I guess in either case, looking at the callers more carefully would be
> a good idea.

The subtle problem here is that v4l2_subdev_call will return -ENOIOCTLCMD if
ops->vbi->g_sliced_fmt == NULL, which typically is not returned to userspace
but either ignored or replaced by another error. It indicates that the
sub device doesn't implement this operation, and it depends on the context
and the operation whether or not that is to be considered an error.

I have no clue what is expected here, without digging deep in the code.

Better to keep it as-is. It really isn't important to waste time on this.

> 
>>> - return 0;
>>> + return ret;
>>>  }
>>>
>>>  int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames)
>>>
>>
>> This is all very hackish, though. I'm not terribly keen on this patch. It's 
>> not
>> clear to me *why* these warnings appear in your setup.
> 
> it's possible that this only happened with 'ccache', which first preprocesses
> the source and the passes it with v4l2_subdev_call expanded into the
> compiler. This means the line looks like
> 
> if ((!(cx->sd_av) ? -ENODEV :
> (((cx->sd_av)->ops->vbi && (cx->sd_av)->ops->vbi->g_sliced_fmt) ?
>(cx->sd_av)->ops->vbi->g_sliced_fmt(cx->sd_av)),
> >fmt.sliced) :
>-ENOIOCTLCMD))
> 
> The compiler now complains about the sub-expression that it sees for
> cx->sd_av==NULL:
> 
>if (-ENODEV)
> 
> which it considers nonsense because it is always true and the value gets
> ignored.
> 
> Let me try again without ccache for now and see what warnings remain.
> We can find a solution for those first, and then decide how to deal with
> ccache.

Sounds good.

I'm OK with applying this if there is no other way to prevent these warnings.

Regards,

Hans

> 
> Arnd
> 




Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

2017-07-17 Thread Hans Verkuil
On 17/07/17 16:26, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuil  wrote:
>> On 14/07/17 11:36, Arnd Bergmann wrote:
>>> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
>>> void *fh,
>>>* digitizer/slicer.  Note, cx18_av_vbi() wipes the passed in
>>>* fmt->fmt.sliced under valid calling conditions
>>>*/
>>> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced))
>>> - return -EINVAL;
>>> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, 
>>> >fmt.sliced);
>>> + if (ret)
>>> + return ret;
>>
>> Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' 
>> wouldn't
>> break something.
> 
> I think Dan was recommending the opposite here, if I understood you
> both correctly:
> he said we should propagate the error code unless we know it's wrong, while 
> you
> want to keep the current behavior to avoid introducing changes ;-)
> 
> I guess in either case, looking at the callers more carefully would be
> a good idea.

The subtle problem here is that v4l2_subdev_call will return -ENOIOCTLCMD if
ops->vbi->g_sliced_fmt == NULL, which typically is not returned to userspace
but either ignored or replaced by another error. It indicates that the
sub device doesn't implement this operation, and it depends on the context
and the operation whether or not that is to be considered an error.

I have no clue what is expected here, without digging deep in the code.

Better to keep it as-is. It really isn't important to waste time on this.

> 
>>> - return 0;
>>> + return ret;
>>>  }
>>>
>>>  int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames)
>>>
>>
>> This is all very hackish, though. I'm not terribly keen on this patch. It's 
>> not
>> clear to me *why* these warnings appear in your setup.
> 
> it's possible that this only happened with 'ccache', which first preprocesses
> the source and the passes it with v4l2_subdev_call expanded into the
> compiler. This means the line looks like
> 
> if ((!(cx->sd_av) ? -ENODEV :
> (((cx->sd_av)->ops->vbi && (cx->sd_av)->ops->vbi->g_sliced_fmt) ?
>(cx->sd_av)->ops->vbi->g_sliced_fmt(cx->sd_av)),
> >fmt.sliced) :
>-ENOIOCTLCMD))
> 
> The compiler now complains about the sub-expression that it sees for
> cx->sd_av==NULL:
> 
>if (-ENODEV)
> 
> which it considers nonsense because it is always true and the value gets
> ignored.
> 
> Let me try again without ccache for now and see what warnings remain.
> We can find a solution for those first, and then decide how to deal with
> ccache.

Sounds good.

I'm OK with applying this if there is no other way to prevent these warnings.

Regards,

Hans

> 
> Arnd
> 




Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

2017-07-17 Thread Dan Carpenter
On Mon, Jul 17, 2017 at 04:26:23PM +0200, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuil  wrote:
> > On 14/07/17 11:36, Arnd Bergmann wrote:
> >> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file 
> >> *file, void *fh,
> >>* digitizer/slicer.  Note, cx18_av_vbi() wipes the passed in
> >>* fmt->fmt.sliced under valid calling conditions
> >>*/
> >> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced))
> >> - return -EINVAL;
> >> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, 
> >> >fmt.sliced);
> >> + if (ret)
> >> + return ret;
> >
> > Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' 
> > wouldn't
> > break something.
> 
> I think Dan was recommending the opposite here, if I understood you
> both correctly:
> he said we should propagate the error code unless we know it's wrong, while 
> you
> want to keep the current behavior to avoid introducing changes ;-)
> 

I don't know the subsystem rules at all, so don't listen to me.

regards,
dan carpenter



Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

2017-07-17 Thread Arnd Bergmann
On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuil  wrote:
> On 14/07/17 11:36, Arnd Bergmann wrote:
>> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
>> void *fh,
>>* digitizer/slicer.  Note, cx18_av_vbi() wipes the passed in
>>* fmt->fmt.sliced under valid calling conditions
>>*/
>> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced))
>> - return -EINVAL;
>> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced);
>> + if (ret)
>> + return ret;
>
> Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' 
> wouldn't
> break something.

I think Dan was recommending the opposite here, if I understood you
both correctly:
he said we should propagate the error code unless we know it's wrong, while you
want to keep the current behavior to avoid introducing changes ;-)

I guess in either case, looking at the callers more carefully would be
a good idea.

>> - return 0;
>> + return ret;
>>  }
>>
>>  int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames)
>>
>
> This is all very hackish, though. I'm not terribly keen on this patch. It's 
> not
> clear to me *why* these warnings appear in your setup.

it's possible that this only happened with 'ccache', which first preprocesses
the source and the passes it with v4l2_subdev_call expanded into the
compiler. This means the line looks like

if ((!(cx->sd_av) ? -ENODEV :
(((cx->sd_av)->ops->vbi && (cx->sd_av)->ops->vbi->g_sliced_fmt) ?
   (cx->sd_av)->ops->vbi->g_sliced_fmt(cx->sd_av)),
>fmt.sliced) :
   -ENOIOCTLCMD))

The compiler now complains about the sub-expression that it sees for
cx->sd_av==NULL:

   if (-ENODEV)

which it considers nonsense because it is always true and the value gets
ignored.

Let me try again without ccache for now and see what warnings remain.
We can find a solution for those first, and then decide how to deal with
ccache.

Arnd


Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

2017-07-17 Thread Hans Verkuil
On 14/07/17 11:36, Arnd Bergmann wrote:
> v4l2_subdev_call is a macro returning whatever the callback return
> type is, usually 'int'. With gcc-7 and ccache, this can lead to
> many wanings like:
> 
> media/platform/pxa_camera.c: In function 'pxa_mbus_build_fmts_xlate':
> media/platform/pxa_camera.c:766:27: error: ?: using integer constants in 
> boolean context [-Werror=int-in-bool-context]
>   while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
> media/atomisp/pci/atomisp2/atomisp_cmd.c: In function 'atomisp_s_ae_window':
> media/atomisp/pci/atomisp2/atomisp_cmd.c:6414:52: error: ?: using integer 
> constants in boolean context [-Werror=int-in-bool-context]
>   if (v4l2_subdev_call(isp->inputs[asd->input_curr].camera,
> 
> The best workaround I could come up with is to change all the
> callers that use the return code from v4l2_subdev_call() in an
> 'if' or 'while' condition.
> 
> In case of simple 'if' checks, adding a temporary variable is
> usually ok, and sometimes this can be used to propagate or
> print an error code, so I do that.
> 
> For the 'while' loops, I ended up adding an otherwise useless
> comparison with zero, which unfortunately makes the code a little
> uglied.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/media/pci/cx18/cx18-ioctl.c  |  6 --
>  drivers/media/pci/saa7146/mxb.c  |  5 +++--
>  drivers/media/platform/atmel/atmel-isc.c |  4 ++--
>  drivers/media/platform/atmel/atmel-isi.c |  4 ++--
>  drivers/media/platform/blackfin/bfin_capture.c   |  4 ++--
>  drivers/media/platform/omap3isp/ispccdc.c|  5 +++--
>  drivers/media/platform/pxa_camera.c  |  3 ++-
>  drivers/media/platform/rcar-vin/rcar-core.c  |  2 +-
>  drivers/media/platform/rcar-vin/rcar-dma.c   |  4 +++-
>  drivers/media/platform/soc_camera/soc_camera.c   |  4 ++--
>  drivers/media/platform/stm32/stm32-dcmi.c|  4 ++--
>  drivers/media/platform/ti-vpe/cal.c  |  6 --
>  drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 13 +++--
>  13 files changed, 37 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/media/pci/cx18/cx18-ioctl.c 
> b/drivers/media/pci/cx18/cx18-ioctl.c
> index 80b902b12a78..1803f28fc501 100644
> --- a/drivers/media/pci/cx18/cx18-ioctl.c
> +++ b/drivers/media/pci/cx18/cx18-ioctl.c
> @@ -188,6 +188,7 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
> void *fh,
>  {
>   struct cx18 *cx = fh2id(fh)->cx;
>   struct v4l2_sliced_vbi_format *vbifmt = >fmt.sliced;
> + int ret;
>  
>   /* sane, V4L2 spec compliant, defaults */
>   vbifmt->reserved[0] = 0;
> @@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, 
> void *fh,
>* digitizer/slicer.  Note, cx18_av_vbi() wipes the passed in
>* fmt->fmt.sliced under valid calling conditions
>*/
> - if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced))
> - return -EINVAL;
> + ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, >fmt.sliced);
> + if (ret)
> + return ret;

Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' 
wouldn't
break something.

>  
>   vbifmt->service_set = cx18_get_service_set(vbifmt);
>   return 0;



> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> index 97093baf28ac..fe56a037f065 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> @@ -6405,19 +6405,20 @@ int atomisp_s_ae_window(struct atomisp_sub_device 
> *asd,
>   struct atomisp_device *isp = asd->isp;
>   /* Coverity CID 298071 - initialzize struct */
>   struct v4l2_subdev_selection sel = { 0 };
> + int ret;
>  
>   sel.r.left = arg->x_left;
>   sel.r.top = arg->y_top;
>   sel.r.width = arg->x_right - arg->x_left + 1;
>   sel.r.height = arg->y_bottom - arg->y_top + 1;
>  
> - if (v4l2_subdev_call(isp->inputs[asd->input_curr].camera,
> -  pad, set_selection, NULL, )) {
> - dev_err(isp->dev, "failed to call sensor set_selection.\n");
> - return -EINVAL;
> - }
> + ret = v4l2_subdev_call(isp->inputs[asd->input_curr].camera,
> +pad, set_selection, NULL, );
> + if (ret)
> + dev_err(isp->dev, "failed to call sensor set_selection: %d\n",
> + ret);

Same here: just keep the 'return -EINVAL'.

>  
> - return 0;
> + return ret;
>  }
>  
>  int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames)
> 

This is all very hackish, though. I'm not terribly keen on this patch. It's not
clear to me *why* these warnings appear in your setup.

Regards,

Hans


Re: [renesas-drivers:topic/renesas-overlays 20/86] drivers//of/unittest.c:2586:3: error: implicit declaration of function '__of_attach_node_sysfs'

2017-07-17 Thread Geert Uytterhoeven
On Mon, Jul 17, 2017 at 3:13 PM, kbuild test robot
 wrote:
> tree:   
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> topic/renesas-overlays
> head:   21b4ee226c68bdaba9db7f6fc7cbdfab58db40b9
> commit: 3b480353c59beefd9537feca3febda56339bbb21 [20/86] of: rename 
> *_node_sysfs to _node_post
> config: x86_64-randconfig-x013-201729 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> git checkout 3b480353c59beefd9537feca3febda56339bbb21
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>drivers//of/unittest.c: In function 'of_unittest_overlay_high_level':
>>> drivers//of/unittest.c:2586:3: error: implicit declaration of function 
>>> '__of_attach_node_sysfs' [-Werror=implicit-function-declaration]
>   __of_attach_node_sysfs(np);
>   ^~

Upstream got one more user of __of_attach_node_sysfs() to be converted...

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] ARM: shmobile: Remove ARCH_SHMOBILE_MULTI

2017-07-17 Thread Geert Uytterhoeven
The migration from ARCH_SHMOBILE_MULTI to ARCH_RENESAS has been
completed in v4.12 by commit 9ed2d4bc5c0c244d ("ARM: dts: renesas:
Switch from ARCH_SHMOBILE_MULTI to ARCH_RENESAS"), so the
ARCH_SHMOBILE_MULTI symbol can be removed.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Reference final commit.
---
 arch/arm/mach-shmobile/Kconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index ad7d604ff0013268..280e7312a9e1b300 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -1,9 +1,6 @@
 config ARCH_SHMOBILE
bool
 
-config ARCH_SHMOBILE_MULTI
-   bool
-
 config PM_RMOBILE
bool
select PM
@@ -34,7 +31,6 @@ menuconfig ARCH_RENESAS
depends on ARCH_MULTI_V7 && MMU
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select ARCH_SHMOBILE
-   select ARCH_SHMOBILE_MULTI
select ARM_GIC
select GPIOLIB
select HAVE_ARM_SCU if SMP
-- 
2.7.4



[PATCH] ARM: shmobile: Remove ARCH_SHMOBILE_MULTI

2017-07-17 Thread Geert Uytterhoeven
The migration from ARCH_SHMOBILE_MULTI to ARCH_RENESAS has been
completed in v4.12 by commit 9ed2d4bc5c0c244d ("ARM: dts: renesas:
Switch from ARCH_SHMOBILE_MULTI to ARCH_RENESAS"), so the
ARCH_SHMOBILE_MULTI symbol can be removed.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Reference final commit.
---
 arch/arm/mach-shmobile/Kconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index ad7d604ff0013268..280e7312a9e1b300 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -1,9 +1,6 @@
 config ARCH_SHMOBILE
bool
 
-config ARCH_SHMOBILE_MULTI
-   bool
-
 config PM_RMOBILE
bool
select PM
@@ -34,7 +31,6 @@ menuconfig ARCH_RENESAS
depends on ARCH_MULTI_V7 && MMU
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select ARCH_SHMOBILE
-   select ARCH_SHMOBILE_MULTI
select ARM_GIC
select GPIOLIB
select HAVE_ARM_SCU if SMP
-- 
2.7.4



[renesas-drivers:topic/renesas-overlays 20/86] drivers//of/unittest.c:2586:3: error: implicit declaration of function '__of_attach_node_sysfs'

2017-07-17 Thread kbuild test robot
tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
topic/renesas-overlays
head:   21b4ee226c68bdaba9db7f6fc7cbdfab58db40b9
commit: 3b480353c59beefd9537feca3febda56339bbb21 [20/86] of: rename 
*_node_sysfs to _node_post
config: x86_64-randconfig-x013-201729 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 3b480353c59beefd9537feca3febda56339bbb21
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers//of/unittest.c: In function 'of_unittest_overlay_high_level':
>> drivers//of/unittest.c:2586:3: error: implicit declaration of function 
>> '__of_attach_node_sysfs' [-Werror=implicit-function-declaration]
  __of_attach_node_sysfs(np);
  ^~
   In file included from include/linux/err.h:4:0,
from include/linux/clk.h:15,
from drivers//of/unittest.c:7:
   drivers//of/unittest.c: At top level:
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'strcpy' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:390:2: note: in expansion of macro 'if'
 if (p_size == (size_t)-1 && q_size == (size_t)-1)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'kmemdup' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:380:2: note: in expansion of macro 'if'
 if (p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'kmemdup' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:378:2: note: in expansion of macro 'if'
 if (__builtin_constant_p(size) && p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr_inv' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:369:2: note: in expansion of macro 'if'
 if (p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr_inv' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:367:2: note: in expansion of macro 'if'
 if (__builtin_constant_p(size) && p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:358:2: note: in expansion of macro 'if'
 if (p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memchr' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:356:2: note: in expansion of macro 'if'
 if (__builtin_constant_p(size) && p_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memcmp' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~
   include/linux/string.h:348:2: note: in expansion of macro 'if'
 if (p_size < size || q_size < size)
 ^~
   include/linux/compiler.h:162:4: warning: '__f' is static but declared in 
inline function 'memcmp' which is not static
   __f = { \
   ^
   include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^~

[PATCH v2 04/05] iommu/ipmmu-vmsa: Replace local utlb code with fwspec ids

2017-07-17 Thread Magnus Damm
From: Magnus Damm 

Now when both 32-bit and 64-bit code inside the driver is using
fwspec it is possible to replace the utlb handling with fwspec ids
that get populated from ->of_xlate().

Suggested-by: Robin Murphy 
Signed-off-by: Magnus Damm 
---

 Changes since V1:
 - Rebased to apply on top of earlier changes in series

 drivers/iommu/ipmmu-vmsa.c |  104 
 1 file changed, 19 insertions(+), 85 deletions(-)

--- 0006/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-07-17 21:12:11.650607110 +0900
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -59,8 +60,6 @@ struct ipmmu_vmsa_domain {
 
 struct ipmmu_vmsa_iommu_priv {
struct ipmmu_vmsa_device *mmu;
-   unsigned int *utlbs;
-   unsigned int num_utlbs;
struct device *dev;
struct list_head list;
 };
@@ -550,13 +549,14 @@ static int ipmmu_attach_device(struct io
   struct device *dev)
 {
struct ipmmu_vmsa_iommu_priv *priv = to_priv(dev);
+   struct iommu_fwspec *fwspec = dev->iommu_fwspec;
struct ipmmu_vmsa_device *mmu = priv->mmu;
struct ipmmu_vmsa_domain *domain = to_vmsa_domain(io_domain);
unsigned long flags;
unsigned int i;
int ret = 0;
 
-   if (!mmu) {
+   if (!priv || !priv->mmu) {
dev_err(dev, "Cannot attach to IPMMU\n");
return -ENXIO;
}
@@ -583,8 +583,8 @@ static int ipmmu_attach_device(struct io
if (ret < 0)
return ret;
 
-   for (i = 0; i < priv->num_utlbs; ++i)
-   ipmmu_utlb_enable(domain, priv->utlbs[i]);
+   for (i = 0; i < fwspec->num_ids; ++i)
+   ipmmu_utlb_enable(domain, fwspec->ids[i]);
 
return 0;
 }
@@ -592,12 +592,12 @@ static int ipmmu_attach_device(struct io
 static void ipmmu_detach_device(struct iommu_domain *io_domain,
struct device *dev)
 {
-   struct ipmmu_vmsa_iommu_priv *priv = to_priv(dev);
+   struct iommu_fwspec *fwspec = dev->iommu_fwspec;
struct ipmmu_vmsa_domain *domain = to_vmsa_domain(io_domain);
unsigned int i;
 
-   for (i = 0; i < priv->num_utlbs; ++i)
-   ipmmu_utlb_disable(domain, priv->utlbs[i]);
+   for (i = 0; i < fwspec->num_ids; ++i)
+   ipmmu_utlb_disable(domain, fwspec->ids[i]);
 
/*
 * TODO: Optimize by disabling the context when no device is attached.
@@ -633,102 +633,36 @@ static phys_addr_t ipmmu_iova_to_phys(st
return domain->iop->iova_to_phys(domain->iop, iova);
 }
 
-static int ipmmu_find_utlbs(struct ipmmu_vmsa_device *mmu, struct device *dev,
-   unsigned int *utlbs, unsigned int num_utlbs)
-{
-   unsigned int i;
-
-   for (i = 0; i < num_utlbs; ++i) {
-   struct of_phandle_args args;
-   int ret;
-
-   ret = of_parse_phandle_with_args(dev->of_node, "iommus",
-"#iommu-cells", i, );
-   if (ret < 0)
-   return ret;
-
-   of_node_put(args.np);
-
-   if (args.np != mmu->dev->of_node || args.args_count != 1)
-   return -EINVAL;
-
-   utlbs[i] = args.args[0];
-   }
-
-   return 0;
-}
-
-static int ipmmu_init_platform_device(struct device *dev)
+static int ipmmu_init_platform_device(struct device *dev,
+ struct of_phandle_args *args)
 {
+   struct platform_device *ipmmu_pdev;
struct ipmmu_vmsa_iommu_priv *priv;
-   struct ipmmu_vmsa_device *mmu;
-   unsigned int *utlbs;
-   unsigned int i;
-   int num_utlbs;
-   int ret = -ENODEV;
-
-   /* Find the master corresponding to the device. */
 
-   num_utlbs = of_count_phandle_with_args(dev->of_node, "iommus",
-  "#iommu-cells");
-   if (num_utlbs < 0)
+   ipmmu_pdev = of_find_device_by_node(args->np);
+   if (!ipmmu_pdev)
return -ENODEV;
 
-   utlbs = kcalloc(num_utlbs, sizeof(*utlbs), GFP_KERNEL);
-   if (!utlbs)
-   return -ENOMEM;
-
-   spin_lock(_devices_lock);
-
-   list_for_each_entry(mmu, _devices, list) {
-   ret = ipmmu_find_utlbs(mmu, dev, utlbs, num_utlbs);
-   if (!ret) {
-   /*
-* TODO Take a reference to the MMU to protect
-* against device removal.
-*/
-   break;
-   }
-   }
-
-   spin_unlock(_devices_lock);
-
-   if (ret < 0)
-   goto error;
-
-   for (i = 0; i < num_utlbs; ++i) {
-   if (utlbs[i] >= mmu->num_utlbs) {
-   ret = 

[PATCH v2 02/05] iommu/ipmmu-vmsa: Consistent ->of_xlate() handling

2017-07-17 Thread Magnus Damm
From: Magnus Damm 

The 32-bit ARM code gets updated to make use of ->of_xlate() and the
code is shared between 64-bit and 32-bit ARM. The of_device_is_available()
check gets dropped since it is included in of_iommu_xlate().

Suggested-by: Robin Murphy 
Signed-off-by: Magnus Damm 
---

 Changes since V1:
 - Moved "Initialize once" check to ipmmu_of_xlate() - thanks Geert!

 drivers/iommu/ipmmu-vmsa.c |   51 ++--
 1 file changed, 17 insertions(+), 34 deletions(-)

--- 0002/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-07-17 21:03:38.340607110 +0900
@@ -734,6 +734,16 @@ error:
return ret;
 }
 
+static int ipmmu_of_xlate(struct device *dev,
+ struct of_phandle_args *spec)
+{
+   /* Initialize once - xlate() will call multiple times */
+   if (to_priv(dev))
+   return 0;
+
+   return ipmmu_init_platform_device(dev);
+}
+
 #if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
 
 static struct iommu_domain *ipmmu_domain_alloc(unsigned type)
@@ -750,11 +760,11 @@ static int ipmmu_add_device(struct devic
struct iommu_group *group;
int ret;
 
-   if (to_priv(dev)) {
-   dev_warn(dev, "IOMMU driver already assigned to device %s\n",
-dev_name(dev));
-   return -EINVAL;
-   }
+   /*
+* Only let through devices that have been verified in xlate()
+*/
+   if (!to_priv(dev))
+   return -ENODEV;
 
/* Create a device group and add the device to it. */
group = iommu_group_alloc();
@@ -773,10 +783,6 @@ static int ipmmu_add_device(struct devic
goto error;
}
 
-   ret = ipmmu_init_platform_device(dev);
-   if (ret < 0)
-   goto error;
-
/*
 * Create the ARM mapping, used by the ARM DMA mapping core to allocate
 * VAs. This will allocate a corresponding IOMMU domain.
@@ -817,24 +823,13 @@ error:
if (!IS_ERR_OR_NULL(group))
iommu_group_remove_device(dev);
 
-   kfree(to_priv(dev)->utlbs);
-   kfree(to_priv(dev));
-   set_priv(dev, NULL);
-
return ret;
 }
 
 static void ipmmu_remove_device(struct device *dev)
 {
-   struct ipmmu_vmsa_iommu_priv *priv = to_priv(dev);
-
arm_iommu_detach_device(dev);
iommu_group_remove_device(dev);
-
-   kfree(priv->utlbs);
-   kfree(priv);
-
-   set_priv(dev, NULL);
 }
 
 static const struct iommu_ops ipmmu_ops = {
@@ -849,6 +844,7 @@ static const struct iommu_ops ipmmu_ops
.add_device = ipmmu_add_device,
.remove_device = ipmmu_remove_device,
.pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K,
+   .of_xlate = ipmmu_of_xlate,
 };
 
 #endif /* !CONFIG_ARM && CONFIG_IOMMU_DMA */
@@ -958,19 +954,6 @@ static struct iommu_group *ipmmu_find_gr
return group;
 }
 
-static int ipmmu_of_xlate_dma(struct device *dev,
- struct of_phandle_args *spec)
-{
-   /* If the IPMMU device is disabled in DT then return error
-* to make sure the of_iommu code does not install ops
-* even though the iommu device is disabled
-*/
-   if (!of_device_is_available(spec->np))
-   return -ENODEV;
-
-   return ipmmu_init_platform_device(dev);
-}
-
 static const struct iommu_ops ipmmu_ops = {
.domain_alloc = ipmmu_domain_alloc_dma,
.domain_free = ipmmu_domain_free_dma,
@@ -984,7 +967,7 @@ static const struct iommu_ops ipmmu_ops
.remove_device = ipmmu_remove_device_dma,
.device_group = ipmmu_find_group_dma,
.pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K,
-   .of_xlate = ipmmu_of_xlate_dma,
+   .of_xlate = ipmmu_of_xlate,
 };
 
 #endif /* CONFIG_IOMMU_DMA */


[PATCH v2 01/05] iommu/ipmmu-vmsa: Use iommu_device_register()/unregister()

2017-07-17 Thread Magnus Damm
From: Magnus Damm 

Extend the driver to make use of iommu_device_register()/unregister()
functions together with iommu_device_set_ops() and iommu_set_fwnode().

These used to be part of the earlier posted 64-bit ARM (r8a7795) series but
it turns out that these days they are required on 32-bit ARM as well.

Signed-off-by: Magnus Damm 
---

 Changes since V1:
 - Perform iommu_device_set_ops() and iommu_device_set_fwnode() before
   iommu_device_register() - thanks Robin!

 drivers/iommu/ipmmu-vmsa.c |   10 ++
 1 file changed, 10 insertions(+)

--- 0001/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-07-17 21:01:47.140607110 +0900
@@ -35,6 +35,7 @@
 struct ipmmu_vmsa_device {
struct device *dev;
void __iomem *base;
+   struct iommu_device iommu;
struct list_head list;
 
unsigned int num_utlbs;
@@ -1054,6 +1055,13 @@ static int ipmmu_probe(struct platform_d
 
ipmmu_device_reset(mmu);
 
+   iommu_device_set_ops(>iommu, _ops);
+   iommu_device_set_fwnode(>iommu, >dev.of_node->fwnode);
+
+   ret = iommu_device_register(>iommu);
+   if (ret)
+   return ret;
+
/*
 * We can't create the ARM mapping here as it requires the bus to have
 * an IOMMU, which only happens when bus_set_iommu() is called in
@@ -1077,6 +1085,8 @@ static int ipmmu_remove(struct platform_
list_del(>list);
spin_unlock(_devices_lock);
 
+   iommu_device_unregister(>iommu);
+
 #if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
arm_iommu_release_mapping(mmu->mapping);
 #endif


[PATCH v2 05/05] iommu/ipmmu-vmsa: Clean up device tracking

2017-07-17 Thread Magnus Damm
From: Robin Murphy 

Get rid of now unused device tracking code. Future code should instead
be able to use driver_for_each_device() for this purpose.

This is a simplified version of the following patch from Robin
[PATCH] iommu/ipmmu-vmsa: Clean up group allocation

Signed-off-by: Robin Murphy 
Signed-off-by: Magnus Damm 
---

 Change since V1:
 - New patch

 drivers/iommu/ipmmu-vmsa.c |   12 
 1 file changed, 12 deletions(-)

--- 0008/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-07-17 21:35:26.690607110 +0900
@@ -37,7 +37,6 @@ struct ipmmu_vmsa_device {
struct device *dev;
void __iomem *base;
struct iommu_device iommu;
-   struct list_head list;
 
unsigned int num_utlbs;
spinlock_t lock;/* Protects ctx and domains[] */
@@ -64,9 +63,6 @@ struct ipmmu_vmsa_iommu_priv {
struct list_head list;
 };
 
-static DEFINE_SPINLOCK(ipmmu_devices_lock);
-static LIST_HEAD(ipmmu_devices);
-
 static struct ipmmu_vmsa_domain *to_vmsa_domain(struct iommu_domain *dom)
 {
return container_of(dom, struct ipmmu_vmsa_domain, io_domain);
@@ -970,10 +966,6 @@ static int ipmmu_probe(struct platform_d
 * ipmmu_init() after the probe function returns.
 */
 
-   spin_lock(_devices_lock);
-   list_add(>list, _devices);
-   spin_unlock(_devices_lock);
-
platform_set_drvdata(pdev, mmu);
 
return 0;
@@ -983,10 +975,6 @@ static int ipmmu_remove(struct platform_
 {
struct ipmmu_vmsa_device *mmu = platform_get_drvdata(pdev);
 
-   spin_lock(_devices_lock);
-   list_del(>list);
-   spin_unlock(_devices_lock);
-
iommu_device_unregister(>iommu);
 
 #if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)


[PATCH v2 03/05] iommu/ipmmu-vmsa: Use fwspec on both 32 and 64-bit ARM

2017-07-17 Thread Magnus Damm
From: Robin Murphy 

Consolidate the 32-bit and 64-bit code to make use of fwspec instead
of archdata for the 32-bit ARM case.

This is a simplified version of the fwspec handling code from Robin
posted as [PATCH] iommu/ipmmu-vmsa: Convert to iommu_fwspec

Signed-off-by: Robin Murphy 
Signed-off-by: Magnus Damm 
---

 Changes since V1:
 - Rebased to apply on top of earlier changes in series

 drivers/iommu/ipmmu-vmsa.c |   21 +++--
 1 file changed, 3 insertions(+), 18 deletions(-)

--- 0004/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-07-17 21:04:54.850607110 +0900
@@ -73,22 +73,9 @@ static struct ipmmu_vmsa_domain *to_vmsa
return container_of(dom, struct ipmmu_vmsa_domain, io_domain);
 }
 
-
 static struct ipmmu_vmsa_iommu_priv *to_priv(struct device *dev)
 {
-#if defined(CONFIG_ARM)
-   return dev->archdata.iommu;
-#else
-   return dev->iommu_fwspec->iommu_priv;
-#endif
-}
-static void set_priv(struct device *dev, struct ipmmu_vmsa_iommu_priv *p)
-{
-#if defined(CONFIG_ARM)
-   dev->archdata.iommu = p;
-#else
-   dev->iommu_fwspec->iommu_priv = p;
-#endif
+   return dev->iommu_fwspec ? dev->iommu_fwspec->iommu_priv : NULL;
 }
 
 #define TLB_LOOP_TIMEOUT   100 /* 100us */
@@ -726,7 +713,7 @@ static int ipmmu_init_platform_device(st
priv->utlbs = utlbs;
priv->num_utlbs = num_utlbs;
priv->dev = dev;
-   set_priv(dev, priv);
+   dev->iommu_fwspec->iommu_priv = priv;
return 0;
 
 error:
@@ -887,14 +874,12 @@ static void ipmmu_domain_free_dma(struct
 
 static int ipmmu_add_device_dma(struct device *dev)
 {
-   struct iommu_fwspec *fwspec = dev->iommu_fwspec;
struct iommu_group *group;
 
/*
 * Only let through devices that have been verified in xlate()
-* We may get called with dev->iommu_fwspec set to NULL.
 */
-   if (!fwspec || !fwspec->iommu_priv)
+   if (!to_priv(dev))
return -ENODEV;
 
group = iommu_group_get_for_dev(dev);


[PATCH v2 00/05] iommu/ipmmu-vmsa: 32-bit ARM update V2

2017-07-17 Thread Magnus Damm
iommu/ipmmu-vmsa: 32-bit ARM update V2

[PATCH v2 01/05] iommu/ipmmu-vmsa: Use iommu_device_register()/unregister()
[PATCH v2 02/05] iommu/ipmmu-vmsa: Consistent ->of_xlate() handling
[PATCH v2 03/05] iommu/ipmmu-vmsa: Use fwspec on both 32 and 64-bit ARM
[PATCH v2 04/05] iommu/ipmmu-vmsa: Replace local utlb code with fwspec ids
[PATCH v2 05/05] iommu/ipmmu-vmsa: Clean up device tracking

This series updates the IPMMU driver to make use of recent IOMMU framework
changes and also improves code sharing in the driver between the 32-bit and
64-bit dma-mapping architecture glue code.

Suggested-by: Robin Murphy  (Patch 2 and 4)
Signed-off-by: Robin Murphy  (Patch 3 and 5)
Signed-off-by: Magnus Damm 
---

 Changes since V1:
 - Minor changes to patch 1 and 2 - thanks Robin and Geert!
 - Added patch 5 to include further clean ups

 Developed on top of v4.13-rc1

 drivers/iommu/ipmmu-vmsa.c |  198 ++--
 1 file changed, 49 insertions(+), 149 deletions(-)


RE: [PATCH] ARM: dts: iwg20m: Correct indentation of mmcif0 properties

2017-07-17 Thread Chris Paterson
Hello Geert,

> From: Geert Uytterhoeven [mailto:geert+rene...@glider.be]
> Sent: 17 July 2017 13:07
> 
> Fixes: 4658c4b789d8e2ae ("ARM: dts: iwg20m: Add MMCIF0 support")
> Signed-off-by: Geert Uytterhoeven 

Thanks for this, I'm not sure how we all missed it before!

Reviewed-by: Chris Paterson 

Kind regards, Chris

> ---
>  arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
> b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
> index f78dbc542a824f40..ff799381863763de 100644
> --- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
> +++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
> @@ -45,11 +45,11 @@
>  };
> 
>   {
> - pinctrl-0 = <_pins>;
> - pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> 
> - vmmc-supply = <_3p3v>;
> - bus-width = <8>;
> - non-removable;
> - status = "okay";
> + vmmc-supply = <_3p3v>;
> + bus-width = <8>;
> + non-removable;
> + status = "okay";
>  };
> --
> 2.7.4



[PATCH] ARM: dts: iwg20m: Correct indentation of mmcif0 properties

2017-07-17 Thread Geert Uytterhoeven
Fixes: 4658c4b789d8e2ae ("ARM: dts: iwg20m: Add MMCIF0 support")
Signed-off-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi 
b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
index f78dbc542a824f40..ff799381863763de 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
+++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
@@ -45,11 +45,11 @@
 };
 
  {
-   pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
 
-   vmmc-supply = <_3p3v>;
-   bus-width = <8>;
-   non-removable;
-   status = "okay";
+   vmmc-supply = <_3p3v>;
+   bus-width = <8>;
+   non-removable;
+   status = "okay";
 };
-- 
2.7.4



[PATCH] clk: renesas: Allow compile-testing of all (sub)drivers

2017-07-17 Thread Geert Uytterhoeven
Enable compile-testing of the remaining clock drivers and subdrivers,
now dummies are available for of_clk_get_from_provider(),
of_device_compatible_match(), and rcar_rst_read_mode_pins(), and the
CPG/MSSR driver core has been converted from of_match_node() to
of_device_get_match_data().

Signed-off-by: Geert Uytterhoeven 
---
To be queued in clk-renesas-for-v4.14.

 drivers/clk/renesas/Kconfig | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index 78d1df9112ba3932..85526ca3920229c8 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -34,94 +34,94 @@ config CLK_EMEV2
bool "Emma Mobile EV2 clock support" if COMPILE_TEST
 
 config CLK_RZA1
-   bool
+   bool "RZ/A1H clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
 
 config CLK_R8A73A4
-   bool
+   bool "R-Mobile APE6 clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
select CLK_RENESAS_DIV6
 
 config CLK_R8A7740
-   bool
+   bool "R-Mobile A1 clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
select CLK_RENESAS_DIV6
 
 config CLK_R8A7743
-   bool
+   bool "RZ/G1M clock support" if COMPILE_TEST
select CLK_RCAR_GEN2_CPG
 
 config CLK_R8A7745
-   bool
+   bool "RZ/G1E clock support" if COMPILE_TEST
select CLK_RCAR_GEN2_CPG
 
 config CLK_R8A7778
-   bool
+   bool "R-Car M1A clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
 
 config CLK_R8A7779
-   bool
+   bool "R-Car H1 clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
 
 config CLK_R8A7790
-   bool
+   bool "R-Car H2 clock support" if COMPILE_TEST
select CLK_RCAR_GEN2 if CLK_RENESAS_LEGACY
select CLK_RCAR_GEN2_CPG
select CLK_RENESAS_DIV6
 
 config CLK_R8A7791
-   bool
+   bool "R-Car M2-W/N clock support" if COMPILE_TEST
select CLK_RCAR_GEN2 if CLK_RENESAS_LEGACY
select CLK_RCAR_GEN2_CPG
select CLK_RENESAS_DIV6
 
 config CLK_R8A7792
-   bool
+   bool "R-Car V2H clock support" if COMPILE_TEST
select CLK_RCAR_GEN2 if CLK_RENESAS_LEGACY
select CLK_RCAR_GEN2_CPG
 
 config CLK_R8A7794
-   bool
+   bool "R-Car E2 clock support" if COMPILE_TEST
select CLK_RCAR_GEN2 if CLK_RENESAS_LEGACY
select CLK_RCAR_GEN2_CPG
select CLK_RENESAS_DIV6
 
 config CLK_R8A7795
-   bool
+   bool "R-Car H3 clock support" if COMPILE_TEST
select CLK_RCAR_GEN3_CPG
 
 config CLK_R8A7796
-   bool
+   bool "R-Car M3-W clock support" if COMPILE_TEST
select CLK_RCAR_GEN3_CPG
 
 config CLK_SH73A0
-   bool
+   bool "SH-Mobile AG5 clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
select CLK_RENESAS_DIV6
 
 
 # Family
 config CLK_RCAR_GEN2
-   bool
+   bool "R-Car Gen2 legacy clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSTP
select CLK_RENESAS_DIV6
 
 config CLK_RCAR_GEN2_CPG
-   bool
+   bool "R-Car Gen2 CPG clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSSR
 
 config CLK_RCAR_GEN3_CPG
-   bool
+   bool "R-Car Gen3 CPG clock support" if COMPILE_TEST
select CLK_RENESAS_CPG_MSSR
 
 
 # Generic
 config CLK_RENESAS_CPG_MSSR
-   bool
+   bool "CPG/MSSR clock support" if COMPILE_TEST
select CLK_RENESAS_DIV6
 
 config CLK_RENESAS_CPG_MSTP
-   bool
+   bool "MSTP clock support" if COMPILE_TEST
 
 config CLK_RENESAS_DIV6
bool "DIV6 clock support" if COMPILE_TEST
-- 
2.7.4



Re: [PATCH 4/6] ARM: vexpress_defconfig: Cleanup from non-existing options

2017-07-17 Thread Liviu Dudau
On Mon, Jul 17, 2017 at 07:49:54AM +0200, Krzysztof Kozlowski wrote:
> ARCH_VEXPRESS_CA9X4 is gone since commit 81cc3f868d30 ("ARM: vexpress:
> Remove non-DT code").
> 
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Liviu Dudau 

Thanks for the cleanup!

Best regards,
Liviu

> ---
>  arch/arm/configs/vexpress_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/configs/vexpress_defconfig 
> b/arch/arm/configs/vexpress_defconfig
> index 0fa0ed577b15..edae1c58fe80 100644
> --- a/arch/arm/configs/vexpress_defconfig
> +++ b/arch/arm/configs/vexpress_defconfig
> @@ -19,7 +19,6 @@ CONFIG_MODULE_UNLOAD=y
>  # CONFIG_IOSCHED_DEADLINE is not set
>  # CONFIG_IOSCHED_CFQ is not set
>  CONFIG_ARCH_VEXPRESS=y
> -CONFIG_ARCH_VEXPRESS_CA9X4=y
>  CONFIG_ARCH_VEXPRESS_DCSCB=y
>  CONFIG_ARCH_VEXPRESS_TC2_PM=y
>  # CONFIG_SWP_EMULATE is not set
> -- 
> 2.7.4
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯


[PULL REQUEST: Renesas Drivers] vsp1/pa-improvements (v2)

2017-07-17 Thread Kieran Bingham
Hi Geert,

Please consider the following for integration in Renesas Drivers

This branch (based on a vanilla v4.13-rc1) has been tested successfully on a
Salvator-X (ES 1.0) and Salvator-XS (ES 2.0) (with 5 iterations of the tests
each)


The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:

  Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)

are available in the git repository at:

  g...@gitolite.kernel.org:pub/scm/linux/kernel/git/kbingham/rcar.git 
vsp1/pa-improvements/v2

for you to fetch changes up to 0bc6b19d31e26b4ee0b5cddff249a9b9493a5d7f:

  v4l: vsp1: Allow entities to participate in the partition algorithm 
(2017-07-17 09:53:18 +0100)


Kieran Bingham (6):
  v4l: vsp1: Move vsp1_video_pipeline_setup_partitions() function
  v4l: vsp1: Calculate partition sizes at stream start.
  v4l: vsp1: Remove redundant context variables
  v4l: vsp1: Move partition rectangles to struct and operate directly
  v4l: vsp1: Provide UDS register updates
  v4l: vsp1: Allow entities to participate in the partition algorithm

 drivers/media/platform/vsp1/vsp1_entity.h |   8 ++
 drivers/media/platform/vsp1/vsp1_pipe.c   |  22 
 drivers/media/platform/vsp1/vsp1_pipe.h   |  48 -
 drivers/media/platform/vsp1/vsp1_regs.h   |  14 +++
 drivers/media/platform/vsp1/vsp1_rpf.c|  31 +++---
 drivers/media/platform/vsp1/vsp1_sru.c|  30 ++
 drivers/media/platform/vsp1/vsp1_uds.c|  43 +++-
 drivers/media/platform/vsp1/vsp1_video.c  | 163 +-
 drivers/media/platform/vsp1/vsp1_wpf.c|  33 --
 9 files changed, 289 insertions(+), 103 deletions(-)


Re: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate

2017-07-17 Thread Wolfram Sang

Scrap my response from before, please. Not sure myself what I was trying
to defend :/



signature.asc
Description: PGP signature


Re: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate

2017-07-17 Thread Wolfram Sang

> I do not mean that -EINVAL is correct. Obviously it isn't. But blindly
> replacing -EINVAL by zero may not be the right solution neither.

Okay, it may not be perfect but it is definately better :)



signature.asc
Description: PGP signature


Re: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate

2017-07-17 Thread Geert Uytterhoeven
Hi Wolfram,

On Mon, Jul 17, 2017 at 11:18 AM, Wolfram Sang  wrote:
>> >> In .recalc_rate of struct clk_ops, it is desirable to return 0 if an
>> >> error occurs, but -EINVAL is returned. This patch fixes it.
>> >>
>> >> Fixes: 5b1defde7054 ("clk: renesas: cpg-mssr: Extract common R-Car Gen3 
>> >> support code")
>> >> Signed-off-by: Takeshi Kihara 
>> >> Signed-off-by: Yoshihiro Kaneko 
>> >
>> > Reviewed-by: Wolfram Sang 
>>
>> Why is it desirable to return 0 if an error occurs? Because the return type 
>> is
>> unsigned long?
>
> Yes, I'd think so. Instead of an arbitrary high, kind-of-random, number, just
> return 0 which also indicates that something unexpected happened? Also, all
> other drivers return zero in an error case (did some quick coccinelle
> grepping before).

OK.

>> Is this routine allowed to fail? I don't see any handling of zero by
>> its callers.
>
> From clk-provider.h:
>
>  * @recalc_rate Recalculate the rate of this clock, by querying hardware. The
>  *  parent rate is an input parameter.  It is up to the caller to
>  *  ensure that the prepare_mutex is held across this call.
>  *  Returns the calculated rate.  Optional, but recommended - if
>  *  this op is not set then clock rate will be initialized to 0.
>
> What would be the benefit of keeping -EINVAL in an unsigned long?

I do not mean that -EINVAL is correct. Obviously it isn't. But blindly
replacing -EINVAL by zero may not be the right solution neither.

If recalc_rate cannot return an error value, perhaps there is a good reason
for that?

I see there's a similar check in cpg_sd_clock_enable(), so the clock also
cannot be enabled if this condition is met?

When does this happen? If the firmware leaves a invalid/unsupported setting
in the register? If we can't recover from that, perhaps the clock's probe
should just fail instead?

It looks like the only writer of that field is cpg_sd_clock_set_rate(),
which always writes a valid/supported value. Is it guaranteed that this
function is always called first?
If yes, the checks can just be removed instead?

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: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate

2017-07-17 Thread Wolfram Sang
Hi Geert,

> >> In .recalc_rate of struct clk_ops, it is desirable to return 0 if an
> >> error occurs, but -EINVAL is returned. This patch fixes it.
> >>
> >> Fixes: 5b1defde7054 ("clk: renesas: cpg-mssr: Extract common R-Car Gen3 
> >> support code")
> >> Signed-off-by: Takeshi Kihara 
> >> Signed-off-by: Yoshihiro Kaneko 
> >
> > Reviewed-by: Wolfram Sang 
> 
> Why is it desirable to return 0 if an error occurs? Because the return type is
> unsigned long?

Yes, I'd think so. Instead of an arbitrary high, kind-of-random, number, just
return 0 which also indicates that something unexpected happened? Also, all
other drivers return zero in an error case (did some quick coccinelle
grepping before).

> 
> Is this routine allowed to fail? I don't see any handling of zero by
> its callers.

From clk-provider.h:

 * @recalc_rate Recalculate the rate of this clock, by querying hardware. The
 *  parent rate is an input parameter.  It is up to the caller to
 *  ensure that the prepare_mutex is held across this call.
 *  Returns the calculated rate.  Optional, but recommended - if
 *  this op is not set then clock rate will be initialized to 0.

What would be the benefit of keeping -EINVAL in an unsigned long?

Regards,

   Wolfram


signature.asc
Description: PGP signature


Re: [RFC] pinctrl: sh-pfc: propagate errors on group config

2017-07-17 Thread Geert Uytterhoeven
On Mon, Jun 20, 2016 at 8:40 AM, Wolfram Sang  wrote:
> From: Wolfram Sang 
>
> On group configuration, bail out if setting one of the individual pins
> fails. We don't need to roll-back, the pinctrl core will do this for us.
>
> Signed-off-by: Wolfram Sang 
> ---
>
> Tested on a Lager and Salvator-X without problems. Needs probably more testing
> on various HW to avoid regressions?

Queueing in sh-pfc-for-v4.14, now commit 13132b3f44d36009 ("ARM: dts:
armadillo800eva: Split LCD mux and gpio") is in v4.13-rc1.

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 net-next repost v2] dt-bindings: net: ravb : Add support for r8a7743 SoC

2017-07-17 Thread Biju Das
Add a new compatible string for the RZ/G1M (R8A7743) SoC.

Signed-off-by: Biju Das 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
---
v1->v2
* Changed the subject
* re-formatted the required properties

 .../devicetree/bindings/net/renesas,ravb.txt   | 29 +-
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt 
b/Documentation/devicetree/bindings/net/renesas,ravb.txt
index b519503..4717bc2 100644
--- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -4,19 +4,24 @@ This file provides information on what the device node for 
the Ethernet AVB
 interface contains.
 
 Required properties:
-- compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790 
SoC.
- "renesas,etheravb-r8a7791" if the device is a part of R8A7791 SoC.
- "renesas,etheravb-r8a7792" if the device is a part of R8A7792 SoC.
- "renesas,etheravb-r8a7793" if the device is a part of R8A7793 SoC.
- "renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC.
- "renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC.
- "renesas,etheravb-r8a7796" if the device is a part of R8A7796 SoC.
- "renesas,etheravb-rcar-gen2" for generic R-Car Gen 2 compatible 
interface.
- "renesas,etheravb-rcar-gen3" for generic R-Car Gen 3 compatible 
interface.
+- compatible: Must contain one or more of the following:
+  - "renesas,etheravb-r8a7743" for the R8A7743 SoC.
+  - "renesas,etheravb-r8a7790" for the R8A7790 SoC.
+  - "renesas,etheravb-r8a7791" for the R8A7791 SoC.
+  - "renesas,etheravb-r8a7792" for the R8A7792 SoC.
+  - "renesas,etheravb-r8a7793" for the R8A7793 SoC.
+  - "renesas,etheravb-r8a7794" for the R8A7794 SoC.
+  - "renesas,etheravb-rcar-gen2" as a fallback for the above
+   R-Car Gen2 and RZ/G1 devices.
 
- When compatible with the generic version, nodes must list the
- SoC-specific version corresponding to the platform first
- followed by the generic version.
+  - "renesas,etheravb-r8a7795" for the R8A7795 SoC.
+  - "renesas,etheravb-r8a7796" for the R8A7796 SoC.
+  - "renesas,etheravb-rcar-gen3" as a fallback for the above
+   R-Car Gen3 devices.
+
+   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 (1) the register block and (2) the stream buffer.
 - interrupts: A list of interrupt-specifiers, one for each entry in
-- 
1.9.1



Re: [PATCH 3/3] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for vin nodes

2017-07-17 Thread Geert Uytterhoeven
On Tue, Jul 11, 2017 at 2:56 PM, Simon Horman
 wrote:
> Use R-Car Gen 2 fallback binding for vind nodes in DT for r8a7794 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7794 and the
> fallback binding for R-Car Gen 2
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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


Re: [PATCH 2/3] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for vin nodes

2017-07-17 Thread Geert Uytterhoeven
On Tue, Jul 11, 2017 at 2:56 PM, Simon Horman
 wrote:
> Use R-Car Gen 2 fallback binding for vind nodes in DT for r8a7791 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7791 and the
> fallback binding for R-Car Gen 2
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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


Re: [PATCH 1/3] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for vin nodes

2017-07-17 Thread Geert Uytterhoeven
On Tue, Jul 11, 2017 at 2:56 PM, Simon Horman
 wrote:
> Use R-Car Gen 2 fallback binding for vind nodes in DT for r8a7790 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7790 and the
> fallback binding for R-Car Gen 2
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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


Re: [PATCH] arm64: dts: renesas: salvator-common: Remove extra LVDS port label

2017-07-17 Thread Geert Uytterhoeven
On Thu, Jul 13, 2017 at 2:17 PM, Laurent Pinchart
 wrote:
> The DU LVDS output is on port 3 on R8A7795 but on port 2 on R8A7796. The
> lvds_connector label thus can't be defined in salvator-common.dtsi,
> common to the two SoCs.
>
> The lvds_connector label is meant for convience to be referenced from
> panel device tree files, such as r8a77xx-aa104xd12-panel.dtsi or
> r8a77xx-aa121td01-panel.dtsi.  As those files are not included in any
> device tree source, and the label never used elsewhere, we can simply
> remove it. Out-of-tree patches that include panel device tree files can
> then add a
>
> #define lvds_connector du_out_lvds0
>
> before including the panel device tree file.
>
> 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: clk: renesas: rcar-gen3: Fix error return code in cpg_sd_clock_recalc_rate

2017-07-17 Thread Geert Uytterhoeven
Hi Wolfram, Kaneko-san,

On Fri, Jul 14, 2017 at 4:25 PM, Wolfram Sang  wrote:
> On Thu, Apr 20, 2017 at 02:46:33AM +0900, Yoshihiro Kaneko wrote:
>> From: Takeshi Kihara 
>>
>> In .recalc_rate of struct clk_ops, it is desirable to return 0 if an
>> error occurs, but -EINVAL is returned. This patch fixes it.
>>
>> Fixes: 5b1defde7054 ("clk: renesas: cpg-mssr: Extract common R-Car Gen3 
>> support code")
>> Signed-off-by: Takeshi Kihara 
>> Signed-off-by: Yoshihiro Kaneko 
>
> Reviewed-by: Wolfram Sang 

Why is it desirable to return 0 if an error occurs? Because the return type is
unsigned long?

Is this routine allowed to fail? I don't see any handling of zero by
its callers.

Gr{oetje,eeting}s,

Geert

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

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


Re: [PATCH] drm: rcar-du: Setup planes before enabling CRTC to avoid flicker

2017-07-17 Thread Kieran Bingham
Hi Maxime,

On 17/07/17 07:32, Maxime Ripard wrote:
> On Thu, Jul 13, 2017 at 05:25:08PM +0100, Kieran Bingham wrote:
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 82b978a5dae6..c2f382feca07 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -255,9 +255,9 @@ static void rcar_du_atomic_commit_tail(struct 
> drm_atomic_state *old_state)
>  
>   /* Apply the atomic update. */
>   drm_atomic_helper_commit_modeset_disables(dev, old_state);
> - drm_atomic_helper_commit_modeset_enables(dev, old_state);
>   drm_atomic_helper_commit_planes(dev, old_state,
>   DRM_PLANE_COMMIT_ACTIVE_ONLY);

 Except for DRM_PLANE_COMMIT_ACTIVE_ONLY, this function now looks very much 
 like
 the default drm_atomic_helper_commit_tail() code.

 Reading around other uses /variants of commit_tail() style functions in 
 other
 drivers has left me confused as to how the ordering affects things here.

 Could be worth adding a comment at least to describe why we can't use the
 default helper...
>>>
>>> Or better still ... Use Maxime's new :
>>>
>>> [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for 
>>> runtime_pm users
>>
>> Never mind - I've just looked again, and seen that this new helper function 
>> is
>> the ordering previous to *this* patch, and therefore isn't the same.
>>
>> However - it's worth noting that Maxime's patch converts this function to the
>> new helper - which contradicts this patch's motivations.
> 
> So I guess I should drop the renesas modifications in my serie then?

Yes, Please.

I think we have a few extra modifications in this function as well which will
take it further away from a default implementation.

Regards

Kieran

> 
> Maxime
> 


Re: [PATCH 2/6] ARM: shmobile_defconfig: Cleanup from non-existing options

2017-07-17 Thread Geert Uytterhoeven
Hi Krzysztof,

On Mon, Jul 17, 2017 at 7:49 AM, Krzysztof Kozlowski  wrote:
> Remove options which do not exist anymore:
>  - DRM_RCAR_HDMI was merged to generic DRM bridge and is obsolete since
>commit 5c602531feb3 ("drm: rcar-du: Replace manual bridge
>implementation with DRM bridge");
>
>  - SND_SOC_RSRC_CARD was replaced by SND_SIMPLE_SCU_CARD in commit
>d12c6216c4a5 ("ASoC: rsrc-card: rename rsrc-card to simple-scu-card
>phase3");
>
> Signed-off-by: Krzysztof Kozlowski 

These have already be fixed in the defconfig-for-v4.14 branch Simon Horman's
tree (git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git).

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/log/?h=defconfig-for-v4.14

They're not yet in -next as v4.13-rc1 wasn't released at that time, and
Simon is now on holidays.

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/6] ARM: multi_v7_defconfig: Cleanup from non-existing options

2017-07-17 Thread Geert Uytterhoeven
Hi Krzysztof,

On Mon, Jul 17, 2017 at 7:49 AM, Krzysztof Kozlowski  wrote:
> Remove options which do not exist anymore:



>  - DRM_RCAR_HDMI was merged to generic DRM bridge and is obsolete since
>commit 5c602531feb3 ("drm: rcar-du: Replace manual bridge
>implementation with DRM bridge");
>
>  - SND_SOC_RSRC_CARD was replaced by SND_SIMPLE_SCU_CARD in commit
>d12c6216c4a5 ("ASoC: rsrc-card: rename rsrc-card to simple-scu-card
>phase3");

These have already be fixed in the defconfig-for-v4.14 branch Simon Horman's
tree (git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git).
They're not yet in -next as v4.13-rc1 wasn't released at that time, and
Simon is noew on holidays.

Gr{oetje,eeting}s,

Geert

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

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


Re: [PATCH 4/4] drm/sun4i: make sure we don't have a commit pending

2017-07-17 Thread Chen-Yu Tsai
On Mon, Jul 17, 2017 at 2:55 PM, Maxime Ripard
 wrote:
> On Fri, Jul 14, 2017 at 04:56:01PM +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard
>>  wrote:
>> > In the earlier display engine designs, any register access while a commit
>> > is pending is forbidden.
>> >
>> > One of the symptoms is that reading a register will return another, random,
>> > register value which can lead to register corruptions if we ever do a
>> > read/modify/write cycle.
>>
>> Alternatively, if changes to the backend (layers) are guaranteed to happen
>> while the CRTC is disabled (which seems to be the case after looking at
>> drm_atomic_helper_commit_planes and drm_atomic_helper_commit_tail), we
>> could just turn on register auto-commit all the time and not deal with
>> this.
>
> As far as I understand, it will only be the case if we need a new
> modeset or we changed the active CRTC or connectors. But if you change
> only the format, buffers or properties it won't be the case, and we'll
> need to commit.

So in other words, if someone were to use it for actual compositing and
moved the upper composited layer around, we would need commit support to be
safe.

Sounds more or less like something a video player would do.

Thanks
ChenYu


Re: [PATCH 4/4] drm/sun4i: make sure we don't have a commit pending

2017-07-17 Thread Maxime Ripard
On Fri, Jul 14, 2017 at 04:56:01PM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard
>  wrote:
> > In the earlier display engine designs, any register access while a commit
> > is pending is forbidden.
> >
> > One of the symptoms is that reading a register will return another, random,
> > register value which can lead to register corruptions if we ever do a
> > read/modify/write cycle.
> 
> Alternatively, if changes to the backend (layers) are guaranteed to happen
> while the CRTC is disabled (which seems to be the case after looking at
> drm_atomic_helper_commit_planes and drm_atomic_helper_commit_tail), we
> could just turn on register auto-commit all the time and not deal with
> this.

As far as I understand, it will only be the case if we need a new
modeset or we changed the active CRTC or connectors. But if you change
only the format, buffers or properties it won't be the case, and we'll
need to commit.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature


Re: [PATCH] drm: rcar-du: Setup planes before enabling CRTC to avoid flicker

2017-07-17 Thread Maxime Ripard
On Thu, Jul 13, 2017 at 05:25:08PM +0100, Kieran Bingham wrote:
> >>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> >>> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>> index 82b978a5dae6..c2f382feca07 100644
> >>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> >>> @@ -255,9 +255,9 @@ static void rcar_du_atomic_commit_tail(struct 
> >>> drm_atomic_state *old_state)
> >>>  
> >>>   /* Apply the atomic update. */
> >>>   drm_atomic_helper_commit_modeset_disables(dev, old_state);
> >>> - drm_atomic_helper_commit_modeset_enables(dev, old_state);
> >>>   drm_atomic_helper_commit_planes(dev, old_state,
> >>>   DRM_PLANE_COMMIT_ACTIVE_ONLY);
> >>
> >> Except for DRM_PLANE_COMMIT_ACTIVE_ONLY, this function now looks very much 
> >> like
> >> the default drm_atomic_helper_commit_tail() code.
> >>
> >> Reading around other uses /variants of commit_tail() style functions in 
> >> other
> >> drivers has left me confused as to how the ordering affects things here.
> >>
> >> Could be worth adding a comment at least to describe why we can't use the
> >> default helper...
> > 
> > Or better still ... Use Maxime's new :
> > 
> > [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for 
> > runtime_pm users
> 
> Never mind - I've just looked again, and seen that this new helper function is
> the ordering previous to *this* patch, and therefore isn't the same.
> 
> However - it's worth noting that Maxime's patch converts this function to the
> new helper - which contradicts this patch's motivations.

So I guess I should drop the renesas modifications in my serie then?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature