[PATCH 3/4] arm64: defconfig: Enable USB 3.0 PHY for R-Car

[Yoshihiro Shimoda]

Enable the R-Car's USB 3.0 PHY.

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 9f55541..29650e1 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -554,6 +554,7 @@ CONFIG_PWM_ROCKCHIP=y
 CONFIG_PWM_SAMSUNG=y
 CONFIG_PWM_TEGRA=m
 CONFIG_PHY_RCAR_GEN3_USB2=y
+CONFIG_PHY_RCAR_GEN3_USB3=m
 CONFIG_PHY_HI6220_USB=y
 CONFIG_PHY_QCOM_USB_HS=y
 CONFIG_PHY_SUN4I_USB=y
-- 
1.9.1

[PATCH 1/4] arm64: defconfig: Enable PWM for R-Car

[Yoshihiro Shimoda]

Enable the Renesas R-Car's PWM controller.

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index a850bc5..59c11a5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -548,6 +548,7 @@ CONFIG_PWM=y
 CONFIG_PWM_BCM2835=m
 CONFIG_PWM_CROS_EC=m
 CONFIG_PWM_MESON=m
+CONFIG_PWM_RCAR=m
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_PWM_SAMSUNG=y
 CONFIG_PWM_TEGRA=m
-- 
1.9.1

[PATCH 4/4] arm64: defconfig: Enable USB 3.0 peripheral for R-Car

[Yoshihiro Shimoda]

Enable the R-Car's USB 3.0 peripheral controller.

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 29650e1..ceafd26 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -445,6 +445,7 @@ CONFIG_NOP_USB_XCEIV=y
 CONFIG_USB_ULPI=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_RENESAS_USBHS_UDC=m
+CONFIG_USB_RENESAS_USB3=m
 CONFIG_USB_ULPI_BUS=y
 CONFIG_MMC=y
 CONFIG_MMC_BLOCK_MINORS=32
-- 
1.9.1

[PATCH 0/4] arm64: defconfig: Enable PWM and USB for R-Car

[Yoshihiro Shimoda]

This patch set is based on the renesas.git / renesas-devel-20180213v2-v4.16-rc1
tag.

Yoshihiro Shimoda (4):
  arm64: defconfig: Enable PWM for R-Car
  arm64: defconfig: Enable USB-DMAC for R-Car
  arm64: defconfig: Enable USB 3.0 PHY for R-Car
  arm64: defconfig: Enable USB 3.0 peripheral for R-Car

 arch/arm64/configs/defconfig | 4 
 1 file changed, 4 insertions(+)

-- 
1.9.1

[PATCH 2/4] arm64: defconfig: Enable USB-DMAC for R-Car

[Yoshihiro Shimoda]

Enable the R-Car's USB-DMAC controller. This controller will be used
by HS-USB (renesas_usbhs driver). Since the renesas_usbhs driver
(CONFIG_USB_RENESAS_USBHS_UDC) is enabled as module, the USB-DMAC
driver is also enabled as module.

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 59c11a5..9f55541 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -501,6 +501,7 @@ CONFIG_QCOM_BAM_DMA=y
 CONFIG_QCOM_HIDMA_MGMT=y
 CONFIG_QCOM_HIDMA=y
 CONFIG_RCAR_DMAC=y
+CONFIG_RENESAS_USB_DMAC=m
 CONFIG_VFIO=y
 CONFIG_VFIO_PCI=y
 CONFIG_VIRTIO_PCI=y
-- 
1.9.1

Re: [PATCH] ARM: dts: stout: Initial r8a7790 Stout board support

[Wolfram Sang]

> + chosen {
> + bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
> + stdout-path = "serial0:38400n8";

Hmm, that would be our first board to not have 115200, or? We already
have some other boards upstream where UBoot has 38400 and Linux 115200.
I'd prefer consistency here a little, but no strong opinion and asking
for other opinions.


> + vcc_sdhi0: regulator-vcc-sdhi0 {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "SDHI0 Vcc";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> +
> + gpio = < 24 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };

Just double checking: No 1.8V for SDR50/104?



signature.asc
Description: PGP signature

Re: [PATCH] ARM: shmobile: stout: enable R-Car Gen2 regulator quirk

[Wolfram Sang]

> - * The r8a7790/lager and r8a7791/koelsch development boards have da9063 and
> - * da9210 regulators.  Both regulators have their interrupt request lines 
> tied
> - * to the same interrupt pin (IRQ2) on the SoC.
> + * The r8a7790/lager,stout and r8a7791/koelsch development boards have da9063
> + * and da9210 regulators.  Both regulators have their interrupt request lines
> + * tied to the same interrupt pin (IRQ2) on the SoC.

I think listing the boards here doesn't scale well. Gose is already
missing. How about rephrasing the paragraph to something like "Some Gen2
development boards have..."?

>   *
>   * After cold boot or da9063-induced restart, both the da9063 and da9210 seem
>   * to assert their interrupt request lines.  Hence as soon as one driver
> @@ -118,6 +118,7 @@ static int __init rcar_gen2_regulator_quirk(void)
>  
>   if (!of_machine_is_compatible("renesas,koelsch") &&
>   !of_machine_is_compatible("renesas,lager") &&
> + !of_machine_is_compatible("renesas,stout") &&
>   !of_machine_is_compatible("renesas,gose"))
>   return -ENODEV;
>  
> -- 
> 2.15.1
> 


signature.asc
Description: PGP signature

RE: [PATCH/RFT v4] gpio: gpio-rcar: Support S2RAM

[Yoshihiro Shimoda]

Hi,

> From: Yoshihiro Kaneko, Sent: Monday, February 5, 2018 4:15 AM
> 
> From: Hien Dang 
> 
> This patch adds an implementation that saves and restores the state of
> GPIO configuration on suspend and resume.
> 
> Signed-off-by: Hien Dang 
> Signed-off-by: Takeshi Kihara 
> [Modify structure of the bank info to simplify a saving registers]
> [Remove DEV_PM_OPS macro]
> Signed-off-by: Yoshihiro Kaneko 
> ---

Thank you for the patch. Our team tested this patch and
an issue that an SD card detection pin doesn't work after resumed is resolved.
So,

Tested-by: Nguyen Viet Dung 

Best regards,
Yoshihiro Shimoda

> This patch is based on the for-next branch of linux-gpio tree.
> 
> v2 [Yoshihiro Kaneko]
> * Modify structure of the bank info as suggested by Geert Uytterhoeven
> 
> v3 [Yoshihiro Kaneko]
> * Remove DEV_PM_OPS macro as suggested by Vladimir Zapolskiy
> 
> v4 [Yoshihiro Kaneko]
> * As suggested by Geert Uytterhoeven
>   - make the name of all members of gpio_rcar_bank_info accord with the
> name of the registers
>   - fix type of the 'offset' variable in unsigned int
>   - fix the inverted logic in gpio_rcar_resume()
> 
>  drivers/gpio/gpio-rcar.c | 66 
> 
>  1 file changed, 66 insertions(+)
> 
> diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
> index e76de57..e5b0dbe 100644
> --- a/drivers/gpio/gpio-rcar.c
> +++ b/drivers/gpio/gpio-rcar.c
> @@ -31,6 +31,16 @@
>  #include 
>  #include 
> 
> +struct gpio_rcar_bank_info {
> + u32 iointsel;
> + u32 inoutsel;
> + u32 outdt;
> + u32 posneg;
> + u32 edglevel;
> + u32 bothedge;
> + u32 intmsk;
> +};
> +
>  struct gpio_rcar_priv {
>   void __iomem *base;
>   spinlock_t lock;
> @@ -41,6 +51,7 @@ struct gpio_rcar_priv {
>   unsigned int irq_parent;
>   bool has_both_edge_trigger;
>   bool needs_clk;
> + struct gpio_rcar_bank_info bank_info;
>  };
> 
>  #define IOINTSEL 0x00/* General IO/Interrupt Switching Register */
> @@ -531,11 +542,66 @@ static int gpio_rcar_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
> 
> +#ifdef CONFIG_PM_SLEEP
> +static int gpio_rcar_suspend(struct device *dev)
> +{
> + struct gpio_rcar_priv *p = dev_get_drvdata(dev);
> +
> + p->bank_info.iointsel = gpio_rcar_read(p, IOINTSEL);
> + p->bank_info.inoutsel = gpio_rcar_read(p, INOUTSEL);
> + p->bank_info.outdt = gpio_rcar_read(p, OUTDT);
> + p->bank_info.intmsk = gpio_rcar_read(p, INTMSK);
> + p->bank_info.posneg = gpio_rcar_read(p, POSNEG);
> + p->bank_info.edglevel = gpio_rcar_read(p, EDGLEVEL);
> + if (p->has_both_edge_trigger)
> + p->bank_info.bothedge = gpio_rcar_read(p, BOTHEDGE);
> +
> + return 0;
> +}
> +
> +static int gpio_rcar_resume(struct device *dev)
> +{
> + struct gpio_rcar_priv *p = dev_get_drvdata(dev);
> + unsigned int offset;
> + u32 mask;
> +
> + for (offset = 0; offset < p->gpio_chip.ngpio; offset++) {
> + mask = BIT(offset);
> + /* I/O pin */
> + if (!(p->bank_info.iointsel & mask)) {
> + if (p->bank_info.inoutsel & mask)
> + gpio_rcar_direction_output(
> + >gpio_chip, offset,
> + !!(p->bank_info.outdt & mask));
> + else
> + gpio_rcar_direction_input(>gpio_chip,
> +   offset);
> + } else {
> + /* Interrupt pin */
> + gpio_rcar_config_interrupt_input_mode(
> + p,
> + offset,
> + !(p->bank_info.posneg & mask),
> + !(p->bank_info.edglevel & mask),
> + !!(p->bank_info.bothedge & mask));
> +
> + if (p->bank_info.intmsk & mask)
> + gpio_rcar_write(p, MSKCLR, mask);
> + }
> + }
> +
> + return 0;
> +}
> +#endif /* CONFIG_PM_SLEEP*/
> +
> +static SIMPLE_DEV_PM_OPS(gpio_rcar_pm_ops, gpio_rcar_suspend, 
> gpio_rcar_resume);
> +
>  static struct platform_driver gpio_rcar_device_driver = {
>   .probe  = gpio_rcar_probe,
>   .remove = gpio_rcar_remove,
>   .driver = {
>   .name   = "gpio_rcar",
> + .pm = _rcar_pm_ops,
>   .of_match_table = of_match_ptr(gpio_rcar_of_table),
>   }
>  };
> --
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/5] [RFT] ARM: dts: wheat: Fix ADV7513 address usage

[kbuild test robot]

Hi Kieran,

I love your patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.16-rc1 next-20180213]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kieran-Bingham/dt-bindings-media-adv7604-Add-support-for-i2c_new_secondary_device/20180214-032943
base:   git://linuxtv.org/media_tree.git master
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/r8a7792-wheat.dts:251.24-25 syntax error
   FATAL ERROR: Unable to parse input tree

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


.config.gz
Description: application/gzip

[PATCH] ARM: dts: stout: Initial r8a7790 Stout board support

[Marek Vasut]

Stout base board support making use of 1 GiB of memory,
the Renesas H2 r8a7790 SoC with the SCIFA0 serial port
and CA15 with ARM architected timer.

Furthermore, this device tree contains entries for:
  - 4x LEDs
  - SDHI SD/MMC controller
  - Display unit with HDMI output
  - SH fast ethernet controller
  - QSPI controller with S25FL512S attached to it
  - I2C controller with DA9210 and DA 9063 PMICs

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Kuninori Morimoto 
Cc: Simon Horman 
Cc: Wolfram Sang 
---
 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/r8a7790-stout.dts | 360 
 2 files changed, 361 insertions(+)
 create mode 100644 arch/arm/boot/dts/r8a7790-stout.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f7b73c825231..6d1999467f2e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -790,6 +790,7 @@ dtb-$(CONFIG_ARCH_RENESAS) += \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
+   r8a7790-stout.dtb \
r8a7791-koelsch.dtb \
r8a7791-porter.dtb \
r8a7792-blanche.dtb \
diff --git a/arch/arm/boot/dts/r8a7790-stout.dts 
b/arch/arm/boot/dts/r8a7790-stout.dts
new file mode 100644
index ..9bc892eacc97
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7790-stout.dts
@@ -0,0 +1,360 @@
+/*
+ * Device Tree Source for the Stout board
+ *
+ * Copyright (C) 2018 Marek Vasut 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7790.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Stout";
+   compatible = "renesas,stout", "renesas,r8a7790";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
+   stdout-path = "serial0:38400n8";
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x4000>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   led1 {
+   gpios = < 22 GPIO_ACTIVE_HIGH>;
+   };
+   led2 {
+   gpios = < 23 GPIO_ACTIVE_HIGH>;
+   };
+   led3 {
+   gpios = < 17 GPIO_ACTIVE_HIGH>;
+   };
+   led5 {
+   gpios = < 24 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   fixedregulator3v3: regulator-3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vcc_sdhi0: regulator-vcc-sdhi0 {
+   compatible = "regulator-fixed";
+
+   regulator-name = "SDHI0 Vcc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = < 24 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_out: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   x2_clk: x2-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <14850>;
+   };
+
+   x13_clk: x13-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <14850>;
+   };
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 722>,
+< CPG_MOD 726>, < CPG_MOD 725>,
+<_clk>, <_clk>;
+   clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1",
+ "dclkin.0", "dclkin.1";
+
+   ports {
+   port@0 {
+   endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   port@1 {
+   lvds_connector0: endpoint {
+   };
+   };
+   port@2 {
+   lvds_connector1: endpoint {
+   };
+   };
+   };
+};
+
+_clk {
+   clock-frequency = <2000>;
+};
+
+ {
+
+   pinctrl-0 = <_clk_pins>;
+   

[PATCH] ARM: shmobile: Document Renesas H2-based Stout DT bindings

[Marek Vasut]

Document the Renesas H2 Stout (ADAS Starter Kit) device tree bindings,
listing it as a supported board.

This allows to use checkpatch.pl to validate .dts files referring to
the Stout board.

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Kuninori Morimoto 
Cc: Simon Horman 
Cc: Wolfram Sang 
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 41d3920aaa5e..bf9bb6eda4a6 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -94,6 +94,8 @@ Boards:
 compatible = "renesas,kzm9g", "renesas,sh73a0"
   - Lager (RTP0RC7790SEB00010S)
 compatible = "renesas,lager", "renesas,r8a7790"
+  - Stout (Y-R-CAR-ADAS-SKH2-BOARD)
+compatible = "renesas,stout", "renesas,r8a7790"
   - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
 compatible = "renesas,m3ulcb", "renesas,r8a7796"
   - Marzen (R0P7779A00010S)
-- 
2.15.1

Re: [PATCH v10 10/30] rcar-vin: fix handling of single field frames (top, bottom and alternate fields)

[Laurent Pinchart]

Hi Niklas,

On Wednesday, 14 February 2018 01:12:50 EET Niklas Söderlund wrote:
> On 2018-02-14 00:31:21 +0200, Laurent Pinchart wrote:
> > On Tuesday, 13 February 2018 18:47:04 EET Niklas Söderlund wrote:
> >> On 2018-02-13 18:26:34 +0200, Laurent Pinchart wrote:
> >>> On Monday, 29 January 2018 18:34:15 EET Niklas Söderlund wrote:
>  There was never proper support in the VIN driver to deliver
>  ALTERNATING field format to user-space, remove this field option. The
>  problem is that ALTERNATING filed order requires the sequence numbers
>  of buffers returned to userspace to reflect if fields where dropped or
>  not, something which is not possible with the VIN drivers capture
>  logic.
>  
>  The VIN driver can still capture from a video source which delivers
>  frames in ALTERNATING field order, but needs to combine them using
>  the VIN hardware into INTERLACED field order. Before this change if a
>  source was delivering fields using ALTERNATE the driver would default
>  to combining them using this hardware feature. Only if the user
>  explicitly requested ALTERNATE filed order would incorrect frames be
>  delivered.
>  
>  The height should not be cut in half for the format for TOP or BOTTOM
>  fields settings. This was a mistake and it was made visible by the
>  scaling refactoring. Correct behavior is that the user should request
>  a frame size that fits the half height frame reflected in the field
>  setting. If not the VIN will do its best to scale the top or bottom
>  to the requested format and cropping and scaling do not work as
>  expected.
>  
>  Signed-off-by: Niklas Söderlund
>  
>  Reviewed-by: Hans Verkuil 
>  ---
>  
>   drivers/media/platform/rcar-vin/rcar-dma.c  | 15 +---
>   drivers/media/platform/rcar-vin/rcar-v4l2.c | 53
>   +++
>   2 files changed, 24 insertions(+), 44 deletions(-)
> > 
> > [snip]
> > 
>  diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
>  b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
>  4d5be2d0c79c9c9a..9f7902d29c62e205 100644
>  --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
>  +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
>  @@ -103,6 +103,28 @@ static int rvin_get_source_format(struct
>  rvin_dev *vin,
>   if (ret)
>   return ret;
>  
>  +switch (fmt.format.field) {
>  +case V4L2_FIELD_TOP:
>  +case V4L2_FIELD_BOTTOM:
>  +case V4L2_FIELD_NONE:
>  +case V4L2_FIELD_INTERLACED_TB:
>  +case V4L2_FIELD_INTERLACED_BT:
>  +case V4L2_FIELD_INTERLACED:
>  +break;
>  +case V4L2_FIELD_ALTERNATE:
>  +/*
>  + * Driver do not (yet) support outputting ALTERNATE to a
>  + * userspace. It dose support outputting INTERLACED so 
>  use
> >>> 
> >>> s/dose/does/
> >>> 
>  + * the VIN hardware to combine the two fields.
>  + */
>  +fmt.format.field = V4L2_FIELD_INTERLACED;
>  +fmt.format.height *= 2;
>  +break;
> >>> 
> >>> I don't like this much. The rvin_get_source_format() function is
> >>> supposed to return the media bus format for the bus between the source
> >>> and the VIN. It's the caller that should take the field limitations into
> >>> account, otherwise you end up with a mix of source and VIN data in the
> >>> same structure.
> >> 
> >> When I read your comments I understand your argument better. And I
> >> understand this function is perhaps poorly named. Maybe it should be
> >> renamed to rvin_get_vin_format_from_source().
> > 
> > If you add a comment above the function I could live with that. Would it
> > make sense to pass a v4l2_pix_format structure instead of a
> > v4l2_mbus_framefmt ?
> 
> I now see that the function name is misleading and I will change it as
> per above. I will also add a comment and swap to v4l2_pix_format (which
> was used before v10 but was changed due to your review comments, I'm
> happy you come around :-)

The argument type has to be consistent with the function's purpose and name. 
Now that you propose changing the function's purpose, my previous comments 
have to be updated. And I'm annoyed that you have such a good memory, it 
forces me to invent excuses :-)

> >> The source format is fetched at s_stream() time in order to do format
> >> validation. At this time the field is also taken into account once more
> >> to validate that the VIN format (calculated here) still is valid. It
> >> also handles the question you ask later at s_stream() time, see bellow.
> >> 
>  +default:
>  +vin->format.field = V4L2_FIELD_NONE;
>  +

[PATCH] ARM: shmobile: stout: enable R-Car Gen2 regulator quirk

[Marek Vasut]

Regulator setup is suboptimal on H2 Stout too.

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Kuninori Morimoto 
Cc: Simon Horman 
Cc: Wolfram Sang 
---
 arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c 
b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
index 44438f344dc8..b749450d361f 100644
--- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
@@ -1,9 +1,9 @@
 /*
  * R-Car Generation 2 da9063/da9210 regulator quirk
  *
- * The r8a7790/lager and r8a7791/koelsch development boards have da9063 and
- * da9210 regulators.  Both regulators have their interrupt request lines tied
- * to the same interrupt pin (IRQ2) on the SoC.
+ * The r8a7790/lager,stout and r8a7791/koelsch development boards have da9063
+ * and da9210 regulators.  Both regulators have their interrupt request lines
+ * tied to the same interrupt pin (IRQ2) on the SoC.
  *
  * After cold boot or da9063-induced restart, both the da9063 and da9210 seem
  * to assert their interrupt request lines.  Hence as soon as one driver
@@ -118,6 +118,7 @@ static int __init rcar_gen2_regulator_quirk(void)
 
if (!of_machine_is_compatible("renesas,koelsch") &&
!of_machine_is_compatible("renesas,lager") &&
+   !of_machine_is_compatible("renesas,stout") &&
!of_machine_is_compatible("renesas,gose"))
return -ENODEV;
 
-- 
2.15.1

Re: [PATCH v10 10/30] rcar-vin: fix handling of single field frames (top, bottom and alternate fields)

[Niklas Söderlund]

Hi Laurent,

On 2018-02-14 00:31:21 +0200, Laurent Pinchart wrote:
> Hi Niklas,
> 
> On Tuesday, 13 February 2018 18:47:04 EET Niklas Söderlund wrote:
> > On 2018-02-13 18:26:34 +0200, Laurent Pinchart wrote:
> > > On Monday, 29 January 2018 18:34:15 EET Niklas Söderlund wrote:
> > >> There was never proper support in the VIN driver to deliver ALTERNATING
> > >> field format to user-space, remove this field option. The problem is
> > >> that ALTERNATING filed order requires the sequence numbers of buffers
> > >> returned to userspace to reflect if fields where dropped or not,
> > >> something which is not possible with the VIN drivers capture logic.
> > >> 
> > >> The VIN driver can still capture from a video source which delivers
> > >> frames in ALTERNATING field order, but needs to combine them using the
> > >> VIN hardware into INTERLACED field order. Before this change if a source
> > >> was delivering fields using ALTERNATE the driver would default to
> > >> combining them using this hardware feature. Only if the user explicitly
> > >> requested ALTERNATE filed order would incorrect frames be delivered.
> > >> 
> > >> The height should not be cut in half for the format for TOP or BOTTOM
> > >> fields settings. This was a mistake and it was made visible by the
> > >> scaling refactoring. Correct behavior is that the user should request a
> > >> frame size that fits the half height frame reflected in the field
> > >> setting. If not the VIN will do its best to scale the top or bottom to
> > >> the requested format and cropping and scaling do not work as expected.
> > >> 
> > >> Signed-off-by: Niklas Söderlund 
> > >> Reviewed-by: Hans Verkuil 
> > >> ---
> > >> 
> > >>  drivers/media/platform/rcar-vin/rcar-dma.c  | 15 +---
> > >>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 53 +++
> > >>  2 files changed, 24 insertions(+), 44 deletions(-)
> 
> [snip]
> 
> > >> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > >> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> > >> 4d5be2d0c79c9c9a..9f7902d29c62e205 100644
> > >> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > >> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > >> @@ -103,6 +103,28 @@ static int rvin_get_source_format(struct rvin_dev
> > >> *vin,
> > >>  if (ret)
> > >>  return ret;
> > >> 
> > >> +switch (fmt.format.field) {
> > >> +case V4L2_FIELD_TOP:
> > >> +case V4L2_FIELD_BOTTOM:
> > >> +case V4L2_FIELD_NONE:
> > >> +case V4L2_FIELD_INTERLACED_TB:
> > >> +case V4L2_FIELD_INTERLACED_BT:
> > >> +case V4L2_FIELD_INTERLACED:
> > >> +break;
> > >> +case V4L2_FIELD_ALTERNATE:
> > >> +/*
> > >> + * Driver do not (yet) support outputting ALTERNATE to a
> > >> + * userspace. It dose support outputting INTERLACED so 
> > >> use
> > > 
> > > s/dose/does/
> > > 
> > >> + * the VIN hardware to combine the two fields.
> > >> + */
> > >> +fmt.format.field = V4L2_FIELD_INTERLACED;
> > >> +fmt.format.height *= 2;
> > >> +break;
> > > 
> > > I don't like this much. The rvin_get_source_format() function is supposed
> > > to return the media bus format for the bus between the source and the
> > > VIN. It's the caller that should take the field limitations into account,
> > > otherwise you end up with a mix of source and VIN data in the same
> > > structure.
> > 
> > When I read your comments I understand your argument better. And I
> > understand this function is perhaps poorly named. Maybe it should be
> > renamed to rvin_get_vin_format_from_source().
> 
> If you add a comment above the function I could live with that. Would it make 
> sense to pass a v4l2_pix_format structure instead of a v4l2_mbus_framefmt ?

I now see that the function name is misleading and I will change it as 
per above. I will also add a comment and swap to v4l2_pix_format (which 
was used before v10 but was changed due to your review comments, I'm 
happy you come around :-)

> 
> > The source format is fetched at s_stream() time in order to do format
> > validation. At this time the field is also taken into account once more
> > to validate that the VIN format (calculated here) still is valid. It
> > also handles the question you ask later at s_stream() time, see bellow.
> > 
> > >> +default:
> > >> +vin->format.field = V4L2_FIELD_NONE;
> > >> +break;
> > >> +}
> > >> +
> > >>  memcpy(mbus_fmt, , sizeof(*mbus_fmt));
> > >>  
> > >>  return 0;
> > >> @@ -139,33 +161,6 @@ static int rvin_reset_format(struct rvin_dev *vin)
> > >> 
> > >>  v4l2_fill_pix_format(>format, _fmt);
> > >> 
> > >> -/*
> > >> - * If the subdevice uses ALTERNATE field mode and G_STD 

Re: [PATCH] videodev2.h: add helper to validate colorspace

[Sakari Ailus]

Hi Laurent and Niklas,

On Wed, Feb 14, 2018 at 12:23:05AM +0200, Laurent Pinchart wrote:
> Hi Niklas,
> 
> Thank you for the patch.
> 
> On Wednesday, 14 February 2018 00:08:47 EET Niklas Söderlund wrote:
> > There is no way for drivers to validate a colorspace value, which could
> > be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
> > validate that the colorspace value is part of enum v4l2_colorspace.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  include/uapi/linux/videodev2.h | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > Hi,
> > 
> > I hope this is the correct header to add this helper to. I think it's
> > since if it's in uapi not only can v4l2 drivers use it but tools like
> > v4l-compliance gets access to it and can be updated to use this instead
> > of the hard-coded check of just < 0xff as it was last time I checked.
> > 
> > // Niklas
> > 
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 9827189651801e12..843afd7c5b000553 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -238,6 +238,11 @@ enum v4l2_colorspace {
> > V4L2_COLORSPACE_DCI_P3= 12,
> >  };
> > 
> > +/* Determine if a colorspace is defined in enum v4l2_colorspace */
> > +#define V4L2_COLORSPACE_IS_VALID(colorspace)   \
> > +   (((colorspace) >= V4L2_COLORSPACE_DEFAULT) &&   \
> > +((colorspace) <= V4L2_COLORSPACE_DCI_P3))
> > +
> 
> This looks pretty good to me. I'd remove the parentheses around each test 
> though.

Agreed.

> 
> One potential issue is that if this macro operates on an unsigned value (for 
> instance an u32, which is the type used for the colorspace field in various 
> structures) the compiler will generate a warning:
> 
> enum.c: In function ‘test_4’: 
>   
>   
> enum.c:30:16: warning: comparison of unsigned expression >= 0 is always true 
> [-Wtype-limits]   
>
>   return V4L2_COLORSPACE_IS_VALID(colorspace);
> 
> Dropping the first check would fix that, but wouldn't catch invalid values 
> when operating on a signed type, such as int or enum v4l2_colorspace.

How about simply casting it to u32 first (and removing the first test)?

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v10 10/30] rcar-vin: fix handling of single field frames (top, bottom and alternate fields)

[Laurent Pinchart]

Hi Niklas,

On Tuesday, 13 February 2018 18:47:04 EET Niklas Söderlund wrote:
> On 2018-02-13 18:26:34 +0200, Laurent Pinchart wrote:
> > On Monday, 29 January 2018 18:34:15 EET Niklas Söderlund wrote:
> >> There was never proper support in the VIN driver to deliver ALTERNATING
> >> field format to user-space, remove this field option. The problem is
> >> that ALTERNATING filed order requires the sequence numbers of buffers
> >> returned to userspace to reflect if fields where dropped or not,
> >> something which is not possible with the VIN drivers capture logic.
> >> 
> >> The VIN driver can still capture from a video source which delivers
> >> frames in ALTERNATING field order, but needs to combine them using the
> >> VIN hardware into INTERLACED field order. Before this change if a source
> >> was delivering fields using ALTERNATE the driver would default to
> >> combining them using this hardware feature. Only if the user explicitly
> >> requested ALTERNATE filed order would incorrect frames be delivered.
> >> 
> >> The height should not be cut in half for the format for TOP or BOTTOM
> >> fields settings. This was a mistake and it was made visible by the
> >> scaling refactoring. Correct behavior is that the user should request a
> >> frame size that fits the half height frame reflected in the field
> >> setting. If not the VIN will do its best to scale the top or bottom to
> >> the requested format and cropping and scaling do not work as expected.
> >> 
> >> Signed-off-by: Niklas Söderlund 
> >> Reviewed-by: Hans Verkuil 
> >> ---
> >> 
> >>  drivers/media/platform/rcar-vin/rcar-dma.c  | 15 +---
> >>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 53 +++
> >>  2 files changed, 24 insertions(+), 44 deletions(-)

[snip]

> >> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> >> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> >> 4d5be2d0c79c9c9a..9f7902d29c62e205 100644
> >> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> >> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> >> @@ -103,6 +103,28 @@ static int rvin_get_source_format(struct rvin_dev
> >> *vin,
> >>if (ret)
> >>return ret;
> >> 
> >> +  switch (fmt.format.field) {
> >> +  case V4L2_FIELD_TOP:
> >> +  case V4L2_FIELD_BOTTOM:
> >> +  case V4L2_FIELD_NONE:
> >> +  case V4L2_FIELD_INTERLACED_TB:
> >> +  case V4L2_FIELD_INTERLACED_BT:
> >> +  case V4L2_FIELD_INTERLACED:
> >> +  break;
> >> +  case V4L2_FIELD_ALTERNATE:
> >> +  /*
> >> +   * Driver do not (yet) support outputting ALTERNATE to a
> >> +   * userspace. It dose support outputting INTERLACED so use
> > 
> > s/dose/does/
> > 
> >> +   * the VIN hardware to combine the two fields.
> >> +   */
> >> +  fmt.format.field = V4L2_FIELD_INTERLACED;
> >> +  fmt.format.height *= 2;
> >> +  break;
> > 
> > I don't like this much. The rvin_get_source_format() function is supposed
> > to return the media bus format for the bus between the source and the
> > VIN. It's the caller that should take the field limitations into account,
> > otherwise you end up with a mix of source and VIN data in the same
> > structure.
> 
> When I read your comments I understand your argument better. And I
> understand this function is perhaps poorly named. Maybe it should be
> renamed to rvin_get_vin_format_from_source().

If you add a comment above the function I could live with that. Would it make 
sense to pass a v4l2_pix_format structure instead of a v4l2_mbus_framefmt ?

> The source format is fetched at s_stream() time in order to do format
> validation. At this time the field is also taken into account once more
> to validate that the VIN format (calculated here) still is valid. It
> also handles the question you ask later at s_stream() time, see bellow.
> 
> >> +  default:
> >> +  vin->format.field = V4L2_FIELD_NONE;
> >> +  break;
> >> +  }
> >> +
> >>memcpy(mbus_fmt, , sizeof(*mbus_fmt));
> >>
> >>return 0;
> >> @@ -139,33 +161,6 @@ static int rvin_reset_format(struct rvin_dev *vin)
> >> 
> >>v4l2_fill_pix_format(>format, _fmt);
> >> 
> >> -  /*
> >> -   * If the subdevice uses ALTERNATE field mode and G_STD is
> >> -   * implemented use the VIN HW to combine the two fields to
> >> -   * one INTERLACED frame. The ALTERNATE field mode can still
> >> -   * be requested in S_FMT and be respected, this is just the
> >> -   * default which is applied at probing or when S_STD is called.
> >> -   */
> >> -  if (vin->format.field == V4L2_FIELD_ALTERNATE &&
> >> -  v4l2_subdev_has_op(vin_to_source(vin), video, g_std))
> >> -  vin->format.field = V4L2_FIELD_INTERLACED;
> >> -
> >> -  switch (vin->format.field) {
> >> -  case V4L2_FIELD_TOP:
> >> -  case V4L2_FIELD_BOTTOM:
> >> -  case V4L2_FIELD_ALTERNATE:
> >> -  vin->format.height /= 2;
> >> -  break;
> >> -  case 

Re: [PATCH] videodev2.h: add helper to validate colorspace

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Wednesday, 14 February 2018 00:08:47 EET Niklas Söderlund wrote:
> There is no way for drivers to validate a colorspace value, which could
> be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
> validate that the colorspace value is part of enum v4l2_colorspace.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  include/uapi/linux/videodev2.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> Hi,
> 
> I hope this is the correct header to add this helper to. I think it's
> since if it's in uapi not only can v4l2 drivers use it but tools like
> v4l-compliance gets access to it and can be updated to use this instead
> of the hard-coded check of just < 0xff as it was last time I checked.
> 
> // Niklas
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 9827189651801e12..843afd7c5b000553 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -238,6 +238,11 @@ enum v4l2_colorspace {
>   V4L2_COLORSPACE_DCI_P3= 12,
>  };
> 
> +/* Determine if a colorspace is defined in enum v4l2_colorspace */
> +#define V4L2_COLORSPACE_IS_VALID(colorspace) \
> + (((colorspace) >= V4L2_COLORSPACE_DEFAULT) &&   \
> +  ((colorspace) <= V4L2_COLORSPACE_DCI_P3))
> +

This looks pretty good to me. I'd remove the parentheses around each test 
though.

One potential issue is that if this macro operates on an unsigned value (for 
instance an u32, which is the type used for the colorspace field in various 
structures) the compiler will generate a warning:

enum.c: In function ‘test_4’:   

  
enum.c:30:16: warning: comparison of unsigned expression >= 0 is always true 
[-Wtype-limits] 
 
  return V4L2_COLORSPACE_IS_VALID(colorspace);

Dropping the first check would fix that, but wouldn't catch invalid values 
when operating on a signed type, such as int or enum v4l2_colorspace.

>  /*
>   * Determine how COLORSPACE_DEFAULT should map to a proper colorspace.
>   * This depends on whether this is a SDTV image (use SMPTE 170M), an

-- 
Regards,

Laurent Pinchart

[PATCH] videodev2.h: add helper to validate colorspace

[Niklas Söderlund]

There is no way for drivers to validate a colorspace value, which could
be provided by user-space by VIDIOC_S_FMT for example. Add a helper to
validate that the colorspace value is part of enum v4l2_colorspace.

Signed-off-by: Niklas Söderlund 
---
 include/uapi/linux/videodev2.h | 5 +
 1 file changed, 5 insertions(+)

Hi,

I hope this is the correct header to add this helper to. I think it's 
since if it's in uapi not only can v4l2 drivers use it but tools like 
v4l-compliance gets access to it and can be updated to use this instead 
of the hard-coded check of just < 0xff as it was last time I checked.

// Niklas

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 9827189651801e12..843afd7c5b000553 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -238,6 +238,11 @@ enum v4l2_colorspace {
V4L2_COLORSPACE_DCI_P3= 12,
 };
 
+/* Determine if a colorspace is defined in enum v4l2_colorspace */
+#define V4L2_COLORSPACE_IS_VALID(colorspace)   \
+   (((colorspace) >= V4L2_COLORSPACE_DEFAULT) &&   \
+((colorspace) <= V4L2_COLORSPACE_DCI_P3))
+
 /*
  * Determine how COLORSPACE_DEFAULT should map to a proper colorspace.
  * This depends on whether this is a SDTV image (use SMPTE 170M), an
-- 
2.16.1

Re: [PATCH v2 0/4] arm64: dts: renesas: r8a77995: Add VSP support

[Laurent Pinchart]

Hi Kieran,

Thank you for the patches.

On Tuesday, 13 February 2018 21:30:33 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The r8a77995-d3 platform supports 3 VSP instances. One VSPBS can be used
> as a dual-input image blender, while two VSPD instances can be utilised as
> part of a display (DU) pipeline.
> 
> Add support for these, along with their required FCPV nodes.
> 
> During review, Laurent noticed that the r8a7795 and r8a7796 were not mapping
> enough register space to handle RPFs with CLUT modules.
> 
> The last two patches fix this issue.
> 
> v2:
>  - Merge FCPV nodes to a single patch
>  - Merge VSP nodes to a single patch
>  - Fix VSP register map size
>  - Add fixes for r8a7795 and r8a7796
> 
> Kieran Bingham (4):
>   arm64: dts: renesas: r8a77995: add FCPV nodes
>   arm64: dts: renesas: r8a77995: add VSP instances
>   arm64: dts: renesas: r8a7795: Fix register mappings on VSPs

Do you plan to also address r8a7795-es1.dtsi ?

>   arm64: dts: renesas: r8a7796: Fix register mappings on VSPs
> 
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi  |  6 ++--
>  arch/arm64/boot/dts/renesas/r8a7796.dtsi  |  6 ++--
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 57 
>  3 files changed, 63 insertions(+), 6 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 3/4] arm64: dts: renesas: r8a7795: Fix register mappings on VSPs

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 21:30:36 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The VSPD includes a CLUT on RPF2. Ensure that the register space is
> mapped correctly to support this.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index 1f32340af2d1..772991db8820
> 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -2607,7 +2607,7 @@
> 
>   vspd0: vsp@fea2 {
>   compatible = "renesas,vsp2";
> - reg = <0 0xfea2 0 0x4000>;
> + reg = <0 0xfea2 0 0x8000>;
>   interrupts = ;
>   clocks = < CPG_MOD 623>;
>   power-domains = < R8A7795_PD_ALWAYS_ON>;
> @@ -2627,7 +2627,7 @@
> 
>   vspd1: vsp@fea28000 {
>   compatible = "renesas,vsp2";
> - reg = <0 0xfea28000 0 0x4000>;
> + reg = <0 0xfea28000 0 0x8000>;
>   interrupts = ;
>   clocks = < CPG_MOD 622>;
>   power-domains = < R8A7795_PD_ALWAYS_ON>;
> @@ -2647,7 +2647,7 @@
> 
>   vspd2: vsp@fea3 {
>   compatible = "renesas,vsp2";
> - reg = <0 0xfea3 0 0x4000>;
> + reg = <0 0xfea3 0 0x8000>;
>   interrupts = ;
>   clocks = < CPG_MOD 621>;
>   power-domains = < R8A7795_PD_ALWAYS_ON>;


-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 4/4] arm64: dts: renesas: r8a7796: Fix register mappings on VSPs

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 21:30:37 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The VSPD includes a CLUT on RPF2. Ensure that the register space is
> mapped correctly to support this.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/arm64/boot/dts/renesas/r8a7796.dtsi | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7796.dtsi index 60755117cba5..3fe5566e0630
> 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -2285,7 +2285,7 @@
> 
>   vspd0: vsp@fea2 {
>   compatible = "renesas,vsp2";
> - reg = <0 0xfea2 0 0x4000>;
> + reg = <0 0xfea2 0 0x8000>;
>   interrupts = ;
>   clocks = < CPG_MOD 623>;
>   power-domains = < R8A7796_PD_ALWAYS_ON>;
> @@ -2305,7 +2305,7 @@
> 
>   vspd1: vsp@fea28000 {
>   compatible = "renesas,vsp2";
> - reg = <0 0xfea28000 0 0x4000>;
> + reg = <0 0xfea28000 0 0x8000>;
>   interrupts = ;
>   clocks = < CPG_MOD 622>;
>   power-domains = < R8A7796_PD_ALWAYS_ON>;
> @@ -2325,7 +2325,7 @@
> 
>   vspd2: vsp@fea3 {
>   compatible = "renesas,vsp2";
> - reg = <0 0xfea3 0 0x4000>;
> + reg = <0 0xfea3 0 0x8000>;
>   interrupts = ;
>   clocks = < CPG_MOD 621>;
>   power-domains = < R8A7796_PD_ALWAYS_ON>;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 2/4] arm64: dts: renesas: r8a77995: add VSP instances

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 21:30:35 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The r8a77995 has a VSPBS to support image processing such as blending of
> two input images, and has two VSPDs to handle display pipelines with a
> DU.
> 
> Signed-off-by: Kieran Bingham 
> 
> ---
> v2:
>  - Fix VSPD register map size
>  - Squash VSPBS and VSPD patches together
> 
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 30 
>  1 file changed, 30 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index
> 196a917afea6..19bd8be9926a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -692,6 +692,16 @@
>   status = "disabled";
>   };
> 
> + vspbs: vsp@fe96 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe96 0 0x4000>;

The VSPBS also has OSD-CLUT support in its RPFs, so you need to extend the 
registers range too.

Apart from that,

Reviewed-by: Laurent Pinchart 

> + interrupts = ;
> + clocks = < CPG_MOD 627>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 627>;
> + renesas,fcp = <>;
> + };
> +
>   fcpvb0: fcp@fe96f000 {
>   compatible = "renesas,fcpv";
>   reg = <0 0xfe96f000 0 0x200>;
> @@ -701,6 +711,16 @@
>   iommus = <_vp0 5>;
>   };
> 
> + vspd0: vsp@fea2 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea2 0 0x8000>;
> + interrupts = ;
> + clocks = < CPG_MOD 623>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 623>;
> + renesas,fcp = <>;
> + };
> +
>   fcpvd0: fcp@fea27000 {
>   compatible = "renesas,fcpv";
>   reg = <0 0xfea27000 0 0x200>;
> @@ -710,6 +730,16 @@
>   iommus = <_vi0 8>;
>   };
> 
> + vspd1: vsp@fea8 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea28000 0 0x8000>;
> + interrupts = ;
> + clocks = < CPG_MOD 622>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 622>;
> + renesas,fcp = <>;
> + };
> +
>   fcpvd1: fcp@fea2f000 {
>   compatible = "renesas,fcpv";
>   reg = <0 0xfea2f000 0 0x200>;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/4] arm64: dts: renesas: r8a77995: add FCPV nodes

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 21:30:34 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The FCPVB handles the interface between the VSPB and memory, while the
> FCPVD handles the interface between the VSPD and memory.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> 
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index
> cd3c6a30fc47..196a917afea6 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -691,6 +691,33 @@
>   #phy-cells = <0>;
>   status = "disabled";
>   };
> +
> + fcpvb0: fcp@fe96f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfe96f000 0 0x200>;
> + clocks = < CPG_MOD 607>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 607>;
> + iommus = <_vp0 5>;
> + };
> +
> + fcpvd0: fcp@fea27000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea27000 0 0x200>;
> + clocks = < CPG_MOD 603>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 603>;
> + iommus = <_vi0 8>;
> + };
> +
> + fcpvd1: fcp@fea2f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea2f000 0 0x200>;
> + clocks = < CPG_MOD 602>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 602>;
> + iommus = <_vi0 9>;
> + };
>   };
> 
>   timer {


-- 
Regards,

Laurent Pinchart

Re: [PATCH v10 30/30] rcar-vin: enable support for r8a77970

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:35 EET Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a77970.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> 2305fedd293db241..496b7d2189d73d37 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -954,6 +954,25 @@ static const struct rvin_info rcar_info_r8a7796 = {
>   .routes = rcar_info_r8a7796_routes,
>  };
> 
> +static const struct rvin_group_route _rcar_info_r8a77970_routes[] = {
> + { .vin = 0, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
> + { .vin = 1, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
> + { .vin = 1, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(3) },
> + { .vin = 2, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
> + { .vin = 2, .csi = RVIN_CSI40, .chan = 2, .mask = BIT(3) },
> + { .vin = 3, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(0) },
> + { .vin = 3, .csi = RVIN_CSI40, .chan = 3, .mask = BIT(3) },
> + { /* Sentinel */ }
> +};
> +
> +static const struct rvin_info rcar_info_r8a77970 = {
> + .model = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> + .routes = _rcar_info_r8a77970_routes,
> +};
> +
>  static const struct of_device_id rvin_of_id_table[] = {
>   {
>   .compatible = "renesas,vin-r8a7778",
> @@ -991,6 +1010,10 @@ static const struct of_device_id rvin_of_id_table[] =
> { .compatible = "renesas,vin-r8a7796",
>   .data = _info_r8a7796,
>   },
> + {
> + .compatible = "renesas,vin-r8a77970",
> + .data = _info_r8a77970,
> + },
>   { /* Sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, rvin_of_id_table);


-- 
Regards,

Laurent Pinchart

Re: [PATCH v10 29/30] rcar-vin: enable support for r8a7796

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:34 EET Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a7796.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 44 ++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> 43d2fa83875817f0..2305fedd293db241 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -914,6 +914,46 @@ static const struct rvin_info rcar_info_r8a7795es1 = {
>   .routes = rcar_info_r8a7795es1_routes,
>  };
> 
> +static const struct rvin_group_route rcar_info_r8a7796_routes[] = {
> + { .vin = 0, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
> + { .vin = 0, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
> + { .vin = 1, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
> + { .vin = 1, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
> + { .vin = 1, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(3) },
> + { .vin = 1, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
> + { .vin = 2, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
> + { .vin = 2, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(2) },
> + { .vin = 2, .csi = RVIN_CSI40, .chan = 2, .mask = BIT(3) },
> + { .vin = 2, .csi = RVIN_CSI20, .chan = 2, .mask = BIT(4) },
> + { .vin = 3, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(0) },
> + { .vin = 3, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(1) },
> + { .vin = 3, .csi = RVIN_CSI40, .chan = 3, .mask = BIT(3) },
> + { .vin = 3, .csi = RVIN_CSI20, .chan = 3, .mask = BIT(4) },
> + { .vin = 4, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
> + { .vin = 4, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
> + { .vin = 5, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
> + { .vin = 5, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
> + { .vin = 5, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(3) },
> + { .vin = 5, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
> + { .vin = 6, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
> + { .vin = 6, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(2) },
> + { .vin = 6, .csi = RVIN_CSI40, .chan = 2, .mask = BIT(3) },
> + { .vin = 6, .csi = RVIN_CSI20, .chan = 2, .mask = BIT(4) },
> + { .vin = 7, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(0) },
> + { .vin = 7, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(1) },
> + { .vin = 7, .csi = RVIN_CSI40, .chan = 3, .mask = BIT(3) },
> + { .vin = 7, .csi = RVIN_CSI20, .chan = 3, .mask = BIT(4) },
> + { /* Sentinel */ }
> +};
> +
> +static const struct rvin_info rcar_info_r8a7796 = {
> + .model = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> + .routes = rcar_info_r8a7796_routes,
> +};
> +
>  static const struct of_device_id rvin_of_id_table[] = {
>   {
>   .compatible = "renesas,vin-r8a7778",
> @@ -947,6 +987,10 @@ static const struct of_device_id rvin_of_id_table[] = {
> .compatible = "renesas,vin-r8a7795",
>   .data = _info_r8a7795,
>   },
> + {
> + .compatible = "renesas,vin-r8a7796",
> + .data = _info_r8a7796,
> + },
>   { /* Sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, rvin_of_id_table);


-- 
Regards,

Laurent Pinchart

Re: [PATCH v10 29/30] rcar-vin: enable support for r8a7796

[Laurent Pinchart]

On Tuesday, 13 February 2018 23:54:55 EET Laurent Pinchart wrote:
> Hi Niklas,
> 
> Thank you for the patch.
> 
> On Monday, 29 January 2018 18:34:34 EET Niklas Söderlund wrote:
> > Add the SoC specific information for Renesas r8a7796.
> > 
> > Signed-off-by: Niklas Söderlund 

And also

Reviewed-by: Laurent Pinchart 

> > ---
> > 
> >  drivers/media/platform/rcar-vin/rcar-core.c | 44
> >  ++
> >  1 file changed, 44 insertions(+)
> > 
> > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> > b/drivers/media/platform/rcar-vin/rcar-core.c index
> > 43d2fa83875817f0..2305fedd293db241 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > @@ -914,6 +914,46 @@ static const struct rvin_info rcar_info_r8a7795es1 =
> > {
> > 
> > .routes = rcar_info_r8a7795es1_routes,
> >  
> >  };
> > 
> > +static const struct rvin_group_route rcar_info_r8a7796_routes[] = {
> > +   { .vin = 0, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
> > +   { .vin = 0, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
> > +   { .vin = 1, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
> > +   { .vin = 1, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
> > +   { .vin = 1, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(3) },
> > +   { .vin = 1, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
> > +   { .vin = 2, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
> > +   { .vin = 2, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(2) },
> > +   { .vin = 2, .csi = RVIN_CSI40, .chan = 2, .mask = BIT(3) },
> > +   { .vin = 2, .csi = RVIN_CSI20, .chan = 2, .mask = BIT(4) },
> > +   { .vin = 3, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(0) },
> > +   { .vin = 3, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(1) },
> > +   { .vin = 3, .csi = RVIN_CSI40, .chan = 3, .mask = BIT(3) },
> > +   { .vin = 3, .csi = RVIN_CSI20, .chan = 3, .mask = BIT(4) },
> > +   { .vin = 4, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
> > +   { .vin = 4, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
> > +   { .vin = 5, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
> > +   { .vin = 5, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
> > +   { .vin = 5, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(3) },
> > +   { .vin = 5, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
> > +   { .vin = 6, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
> > +   { .vin = 6, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(2) },
> > +   { .vin = 6, .csi = RVIN_CSI40, .chan = 2, .mask = BIT(3) },
> > +   { .vin = 6, .csi = RVIN_CSI20, .chan = 2, .mask = BIT(4) },
> > +   { .vin = 7, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(0) },
> > +   { .vin = 7, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(1) },
> > +   { .vin = 7, .csi = RVIN_CSI40, .chan = 3, .mask = BIT(3) },
> > +   { .vin = 7, .csi = RVIN_CSI20, .chan = 3, .mask = BIT(4) },
> > +   { /* Sentinel */ }
> > +};
> > +
> > +static const struct rvin_info rcar_info_r8a7796 = {
> > +   .model = RCAR_GEN3,
> > +   .use_mc = true,
> > +   .max_width = 4096,
> > +   .max_height = 4096,
> > +   .routes = rcar_info_r8a7796_routes,
> > +};
> > +
> > 
> >  static const struct of_device_id rvin_of_id_table[] = {
> >  
> > {
> > 
> > .compatible = "renesas,vin-r8a7778",
> > 
> > @@ -947,6 +987,10 @@ static const struct of_device_id rvin_of_id_table[] =
> > { .compatible = "renesas,vin-r8a7795",
> > 
> > .data = _info_r8a7795,
> > 
> > },
> > 
> > +   {
> > +   .compatible = "renesas,vin-r8a7796",
> > +   .data = _info_r8a7796,
> > +   },
> > 
> > { /* Sentinel */ },
> >  
> >  };
> >  MODULE_DEVICE_TABLE(of, rvin_of_id_table);


-- 
Regards,

Laurent Pinchart

Re: [PATCH v10 28/30] rcar-vin: enable support for r8a7795

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:33 EET Niklas Söderlund wrote:
> Add the SoC specific information for Renesas r8a7795 ES1.x and ES2.0.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar-vin/Kconfig |   2 +-
>  drivers/media/platform/rcar-vin/rcar-core.c | 120 +
>  2 files changed, 121 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/Kconfig
> b/drivers/media/platform/rcar-vin/Kconfig index
> af4c98b44d2e22cb..8fa7ee468c63afb9 100644
> --- a/drivers/media/platform/rcar-vin/Kconfig
> +++ b/drivers/media/platform/rcar-vin/Kconfig
> @@ -6,7 +6,7 @@ config VIDEO_RCAR_VIN
>   select V4L2_FWNODE
>   ---help---
> Support for Renesas R-Car Video Input (VIN) driver.
> -   Supports R-Car Gen2 SoCs.
> +   Supports R-Car Gen2 and Gen3 SoCs.
> 
> To compile this driver as a module, choose M here: the
> module will be called rcar-vin.
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> 7ceff0de40078580..43d2fa83875817f0 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -815,6 +816,104 @@ static const struct rvin_info rcar_info_gen2 = {
>   .max_height = 2048,
>  };
> 
> +static const struct rvin_group_route rcar_info_r8a7795_routes[] = {
> + { .vin = 0, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
> + { .vin = 0, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
> + { .vin = 0, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(2) },
> + { .vin = 1, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
> + { .vin = 1, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(1) | BIT(3) },
> + { .vin = 1, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
> + { .vin = 1, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
> + { .vin = 2, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(0) },
> + { .vin = 2, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
> + { .vin = 2, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(2) },
> + { .vin = 2, .csi = RVIN_CSI40, .chan = 2, .mask = BIT(3) },
> + { .vin = 2, .csi = RVIN_CSI20, .chan = 2, .mask = BIT(4) },
> + { .vin = 3, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(0) },
> + { .vin = 3, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(1) | BIT(2) },
> + { .vin = 3, .csi = RVIN_CSI40, .chan = 3, .mask = BIT(3) },
> + { .vin = 3, .csi = RVIN_CSI20, .chan = 3, .mask = BIT(4) },
> + { .vin = 4, .csi = RVIN_CSI41, .chan = 0, .mask = BIT(0) | BIT(3) },
> + { .vin = 4, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
> + { .vin = 4, .csi = RVIN_CSI41, .chan = 1, .mask = BIT(2) },
> + { .vin = 5, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
> + { .vin = 5, .csi = RVIN_CSI41, .chan = 1, .mask = BIT(1) | BIT(3) },
> + { .vin = 5, .csi = RVIN_CSI41, .chan = 0, .mask = BIT(2) },
> + { .vin = 5, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
> + { .vin = 6, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(0) },
> + { .vin = 6, .csi = RVIN_CSI41, .chan = 0, .mask = BIT(1) },
> + { .vin = 6, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(2) },
> + { .vin = 6, .csi = RVIN_CSI41, .chan = 2, .mask = BIT(3) },
> + { .vin = 6, .csi = RVIN_CSI20, .chan = 2, .mask = BIT(4) },
> + { .vin = 7, .csi = RVIN_CSI41, .chan = 1, .mask = BIT(0) },
> + { .vin = 7, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(1) | BIT(2) },
> + { .vin = 7, .csi = RVIN_CSI41, .chan = 3, .mask = BIT(3) },
> + { .vin = 7, .csi = RVIN_CSI20, .chan = 3, .mask = BIT(4) },
> + { /* Sentinel */ }
> +};
> +
> +static const struct rvin_info rcar_info_r8a7795 = {
> + .model = RCAR_GEN3,
> + .use_mc = true,
> + .max_width = 4096,
> + .max_height = 4096,
> + .routes = rcar_info_r8a7795_routes,
> +};
> +
> +static const struct rvin_group_route rcar_info_r8a7795es1_routes[] = {
> + { .vin = 0, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(0) | BIT(3) },
> + { .vin = 0, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(1) | BIT(4) },
> + { .vin = 0, .csi = RVIN_CSI21, .chan = 0, .mask = BIT(2) | BIT(5) },
> + { .vin = 1, .csi = RVIN_CSI20, .chan = 0, .mask = BIT(0) },
> + { .vin = 1, .csi = RVIN_CSI21, .chan = 0, .mask = BIT(1) },
> + { .vin = 1, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(2) },
> + { .vin = 1, .csi = RVIN_CSI40, .chan = 1, .mask = BIT(3) },
> + { .vin = 1, .csi = RVIN_CSI20, .chan = 1, .mask = BIT(4) },
> + { .vin = 1, .csi = RVIN_CSI21, .chan = 1, .mask = BIT(5) },
> + { .vin = 2, .csi = RVIN_CSI21, .chan = 0, .mask = BIT(0) },
> + { .vin = 2, .csi = RVIN_CSI40, .chan = 0, .mask = BIT(1) },
> +   

Re: [PATCH v10 27/30] rcar-vin: extend {start,stop}_streaming to work with media controller

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:32 EET Niklas Söderlund wrote:
> The procedure to start or stop streaming using the non-MC single
> subdevice and the MC graph and multiple subdevices are quite different.
> Create a new function to abstract which method is used based on which
> mode the driver is running in and add logic to start the MC graph.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 123 +++--
>  1 file changed, 116 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> 811d8f8638d21200..6784e7eb3d96e1c0 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1087,15 +1087,126 @@ static void rvin_buffer_queue(struct vb2_buffer
> *vb) spin_unlock_irqrestore(>qlock, flags);
>  }
> 
> +static int rvin_set_stream(struct rvin_dev *vin, int on)
> +{
> + struct v4l2_subdev_format fmt = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> + struct media_pipeline *pipe;
> + struct media_device *mdev;
> + struct  v4l2_subdev *sd;
> + struct media_pad *pad;
> + int ret;
> +
> + /* No media controller used, simply pass operation to subdevice */
> + if (!vin->info->use_mc) {
> + ret = v4l2_subdev_call(vin->digital->subdev, video, s_stream,
> +on);
> +
> + return ret == -ENOIOCTLCMD ? 0 : ret;
> + }
> +
> + pad = media_entity_remote_pad(>pad);
> + if (!pad)
> + return -EPIPE;
> +
> + sd = media_entity_to_v4l2_subdev(pad->entity);
> +
> + if (!on) {
> + media_pipeline_stop(>vdev.entity);
> + return v4l2_subdev_call(sd, video, s_stream, 0);
> + }
> +
> + fmt.pad = pad->index;
> + if (v4l2_subdev_call(sd, pad, get_fmt, NULL, ))
> + return -EPIPE;
> +
> + switch (fmt.format.code) {
> + case MEDIA_BUS_FMT_YUYV8_1X16:
> + case MEDIA_BUS_FMT_UYVY8_2X8:
> + case MEDIA_BUS_FMT_UYVY10_2X10:
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + vin->code = fmt.format.code;
> + break;
> + default:
> + return -EPIPE;
> + }
> +
> + switch (fmt.format.field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + case V4L2_FIELD_SEQ_TB:
> + case V4L2_FIELD_SEQ_BT:
> + /* Supported natively */
> + break;
> + case V4L2_FIELD_ALTERNATE:
> + switch (vin->format.field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + break;
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + case V4L2_FIELD_SEQ_TB:
> + case V4L2_FIELD_SEQ_BT:
> + /* Use VIN hardware to combine the two fields */
> + fmt.format.height *= 2;
> + break;
> + default:
> + return -EPIPE;
> + }
> + break;
> + default:
> + return -EPIPE;
> + }
> +
> + if (fmt.format.width != vin->format.width ||
> + fmt.format.height != vin->format.height ||
> + fmt.format.code != vin->code)
> + return -EPIPE;

I'd create a rvin_mc_validate_format() function and move this code there. This 
function is growing a bit too big.

> + mdev = vin->vdev.entity.graph_obj.mdev;
> +
> + /*
> +  * The graph lock needs to be taken to protect concurrent
> +  * starts of multiple VIN instances as they might share
> +  * a common subdevice down the line and then should use
> +  * the same pipe.
> +  */
> + mutex_lock(>graph_mutex);

I'd say mutex_lock_interruptible(), but videobuf2 won't support that :-S

> + pipe = sd->entity.pipe ? sd->entity.pipe : >vdev.pipe;
> + ret = __media_pipeline_start(>vdev.entity, pipe);
> + mutex_unlock(>graph_mutex);
> + if (ret)
> + return ret;
> +
> + ret = v4l2_subdev_call(sd, video, s_stream, 1);
> + if (ret == -ENOIOCTLCMD)
> + ret = 0;
> + if (ret)
> + media_pipeline_stop(>vdev.entity);
> +
> + return ret;
> +}
> +
>  static int rvin_start_streaming(struct vb2_queue *vq, unsigned int count)
>  {
>   struct rvin_dev *vin = vb2_get_drv_priv(vq);
> - struct v4l2_subdev *sd;
>   unsigned long flags;
>   int ret;
> 
> - sd = vin_to_source(vin);
> - v4l2_subdev_call(sd, video, s_stream, 1);
> + ret = rvin_set_stream(vin, 1);
> + if (ret) {
> + 

Re: [PATCH v10 26/30] rcar-vin: add link notify for Gen3

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:31 EET Niklas Söderlund wrote:
> Add the ability to process media device link change request. Link
> enabling is a bit complicated on Gen3, whether or not it's possible to
> enable a link depends on what other links already are enabled. On Gen3
> the 8 VINs are split into two subgroup's (VIN0-3 and VIN4-7) and from a
> routing perspective these two groups are independent of each other.
> Each subgroup's routing is controlled by the subgroup VIN master
> instance (VIN0 and VIN4).
> 
> There are a limited number of possible route setups available for each
> subgroup and the configuration of each setup is dictated by the
> hardware. On H3 for example there are 6 possible route setups for each
> subgroup to choose from.
> 
> This leads to the media device link notification code being rather large
> since it will find the best routing configuration to try and accommodate
> as many links as possible. When it's not possible to enable a new link
> due to hardware constrains the link_notifier callback will return
> -EMLINK.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 129 +
>  1 file changed, 129 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> f08277a0dc11f477..7ceff0de40078580 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -24,6 +24,7 @@
> 
>  #include 
>  #include 
> +#include 
> 
>  #include "rcar-vin.h"
> 
> @@ -44,6 +45,133 @@
>   */
>  #define rvin_group_id_to_master(vin) ((vin) < 4 ? 0 : 4)
> 
> +/* 
> + * Media Controller link notification
> + */
> +
> +/* group lock should be held when calling this function */
> +static int rvin_group_entity_to_csi_id(struct rvin_group *group,
> + struct media_entity *entity)
> +{
> + struct v4l2_subdev *sd;
> + int i;

unsigned int.

> +
> + if (!is_media_entity_v4l2_subdev(entity))
> + return -ENODEV;

Can this happen ?

> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + for (i = 0; i < RVIN_CSI_MAX; i++)
> + if (group->csi[i].subdev == sd)
> + return i;
> +
> + return -ENODEV;
> +}
> +
> +static unsigned int rvin_group_get_mask(struct rvin_dev *vin,
> + enum rvin_csi_id csi_id,
> + unsigned char chan)
> +{
> + const struct rvin_group_route *route;
> + unsigned int mask = 0;
> +
> + for (route = vin->info->routes; route->mask; route++) {

Please document the fact that the array needs to be terminated by an empty 
element in the kerneldoc for vin->info->routes.

> + if (route->vin == vin->id &&
> + route->csi == csi_id &&
> + route->chan == chan) {
> + vin_dbg(vin, "Adding route: vin: %d csi: %d chan: %d\n",
> + route->vin, route->csi, route->chan);
> + mask |= route->mask;
> + }
> + }
> +
> + return mask;
> +}
> +
> +static int rvin_group_link_notify(struct media_link *link, u32 flags,
> +   unsigned int notification)
> +{
> + struct rvin_group *group = container_of(link->graph_obj.mdev,
> + struct rvin_group, mdev);
> + unsigned int i, master_id, chan, mask_new, mask = ~0;

I'm sure you could spare a few more lines :-)

> + struct media_entity *entity;
> + struct video_device *vdev;
> + struct media_pad *csi_pad;
> + struct rvin_dev *vin = NULL;
> + int csi_id, ret;
> +
> + ret = v4l2_pipeline_link_notify(link, flags, notification);
> + if (ret)
> + return ret;
> +
> + /* Only care about link enablement for VIN nodes */
> + if (!(flags & MEDIA_LNK_FL_ENABLED) ||
> + !is_media_entity_v4l2_video_device(link->sink->entity))
> + return 0;
> +
> + /* If any entity are in use don't allow link changes */

s/are/is/

> + media_device_for_each_entity(entity, >mdev)
> + if (entity->use_count)
> + return -EBUSY;
> +
> + mutex_lock(>lock);
> +
> + /* Find VIN and its master for which the link */

The words make sense individually. Maybe you could try a different order ? :-)

> + entity = link->sink->entity;
> + vdev = media_entity_to_video_device(entity);

You can combine those two lines and remove the entity variable.

> + for (i = 0; i < RCAR_VIN_NUM; i++) {
> + if (group->vin[i] && >vin[i]->vdev == vdev) {
> + vin = group->vin[i];
> + master_id = rvin_group_id_to_master(vin->id);
> + 

Re: [PATCH v10 25/30] rcar-vin: parse Gen3 OF and setup media graph

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:30 EET Niklas Söderlund wrote:
> The parsing and registering CSI-2 subdevices with the v4l2 async
> framework is a collaborative effort shared between the VIN instances
> which are part of the group. When the last VIN in the group is probed it
> asks all other VINs to parse its share of OF and record the async
> subdevices it finds in the notifier belonging to the last probed VIN.
> 
> Once all CSI-2 subdevices in this notifier are bound proceed to register
> all VIN video devices of the group and crate media device links between
> all CSI-2 and VIN entities according to the SoC specific routing
> configuration.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 250 -
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  12 +-
>  2 files changed, 258 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> 4a64df5019ce45f7..f08277a0dc11f477 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -27,6 +27,23 @@
> 
>  #include "rcar-vin.h"
> 
> +/*
> + * The companion CSI-2 receiver driver (rcar-csi2) is known
> + * and we know it have one source pad (pad 0) and four sink

s/have/has/

> + * pads (pad 1-4). So to translate a pad on the remote
> + * CSI-2 receiver to/from the VIN internal channel number simply
> + * subtract/add or one from the pad/chan number.

s/or one/one/

and maybe s/chan/channel/ ?

> + */
> +#define rvin_group_csi_pad_to_chan(pad) ((pad) - 1)
> +#define rvin_group_csi_chan_to_pad(chan) ((chan) + 1)
> +
> +/*
> + * Not all VINs are created equal, master VINs control the
> + * routing for other VIN's. We can figure out which VIN is
> + * master by looking at a VINs id
> + */
> +#define rvin_group_id_to_master(vin) ((vin) < 4 ? 0 : 4)
> +
>  /* 
>   * Gen3 CSI2 Group Allocator
>   */
> @@ -77,6 +94,8 @@ static int rvin_group_init(struct rvin_group *group,
> struct rvin_dev *vin) snprintf(mdev->bus_info, sizeof(mdev->bus_info),
> "platform:%s",
>dev_name(mdev->dev));
> 
> + group->notifier = NULL;
> +

The group has been allocated with kzalloc() so this isn't necessary.

>   media_device_init(mdev);
> 
>   ret = media_device_register(>mdev);
> @@ -406,6 +425,218 @@ static int rvin_digital_graph_init(struct rvin_dev
> *vin) return 0;
>  }
> 
> +/* 
> + * Group async notifier
> + */
> +
> +static int rvin_group_notify_complete(struct v4l2_async_notifier *notifier)
> +{
> + struct rvin_dev *vin = notifier_to_vin(notifier);
> + const struct rvin_group_route *route;
> + unsigned int i;
> + int ret;
> +
> + ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
> + if (ret) {
> + vin_err(vin, "Failed to register subdev nodes\n");
> + return ret;
> + }
> +
> + /* Register all video nodes for the group */
> + for (i = 0; i < RCAR_VIN_NUM; i++) {
> + if (vin->group->vin[i]) {
> + ret = rvin_v4l2_register(vin->group->vin[i]);
> + if (ret)
> + return ret;
> + }
> + }
> +
> + /* Create all media device links between VINs and CSI-2's */
> + mutex_lock(>group->lock);
> + for (route = vin->info->routes; route->mask; route++) {
> + struct media_pad *source_pad, *sink_pad;
> + struct media_entity *source, *sink;
> + unsigned int source_idx;
> +
> + /* Check that VIN is part of the group */
> + if (!vin->group->vin[route->vin])
> + continue;
> +
> + /* Check that VIN' master is part of the group */
> + if (!vin->group->vin[rvin_group_id_to_master(route->vin)])
> + continue;
> +
> + /* Check that CSI-2 is part of the group */
> + if (!vin->group->csi[route->csi].subdev)
> + continue;
> +
> + source = >group->csi[route->csi].subdev->entity;
> + source_idx = rvin_group_csi_chan_to_pad(route->chan);
> + source_pad = >pads[source_idx];
> +
> + sink = >group->vin[route->vin]->vdev.entity;
> + sink_pad = >pads[0];
> +
> + /* Skip if link already exists */
> + if (media_entity_find_link(source_pad, sink_pad))
> + continue;
> +
> + ret = media_create_pad_link(source, source_idx, sink, 0, 0);
> + if (ret) {
> + vin_err(vin, "Error adding link from %s to %s\n",
> + source->name, sink->name);
> + break;
> +   

Re: [PATCH v10 24/30] rcar-vin: add chsel information to rvin_info

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:29 EET Niklas Söderlund wrote:
> Each Gen3 SoC has a limited set of predefined routing possibilities for
> which CSI-2 device and virtual channel can be routed to which VIN
> instance. Prepare to store this information in the struct rvin_info.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-vin.h | 30 +++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h index
> 903d8fb8426a7860..ca2c2a23cef8506c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -43,6 +43,14 @@ enum model_id {
>   RCAR_GEN3,
>  };
> 
> +enum rvin_csi_id {
> + RVIN_CSI20,
> + RVIN_CSI21,
> + RVIN_CSI40,
> + RVIN_CSI41,
> + RVIN_CSI_MAX,
> +};
> +
>  /**
>   * STOPPED  - No operation in progress
>   * RUNNING  - Operation in progress have buffers
> @@ -81,12 +89,33 @@ struct rvin_graph_entity {
>   unsigned int sink_pad;
>  };
> 
> +/** struct rvin_group_route - Map a CSI-2 receiver and channel to a CHSEL

If my understanding is correct an entry describes a route from a channel of a 
CSI-2 receiver to a VIN, and how to configure the hardware to enable that 
route (in the mask field). Could you expand this single line of documentation 
to explain that more clearly ?

> + * @vin: Which VIN the CSI-2 and VC describes

VC ? Is that virtual channel ? Isn't that internal to the CSI-2 receiver only 
?

> + * @csi: VIN internal number for CSI-2 device

Or just "CSI-2 receiver ID" ?

> + * @chan:Output channel of the CSI-2 receiver. Each R-Car CSI-2

Would "channel" be too long ?

> + *   receiver has four output channels facing the VIN
> + *   devices, each channel can carry one CSI-2 Virtual
> + *   Channel (VC) and there are no correlation between
> + *   output channel number and CSI-2 VC. It's up to the
> + *   CSI-2 receiver driver to configure which VC is
> + *   outputted on which channel, the VIN devices only

s/outputted/output/

> + *   cares about output channels.

s/cares/care/

> + * @mask:Bitmask of chsel values which accommodates route

s/which/that/

Reading the documentation I'm not sure to understand how this works. In 
particular the mask field documentation isn't clear enough.

> + */
> +struct rvin_group_route {
> + unsigned int vin;
> + enum rvin_csi_id csi;
> + unsigned char chan;

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

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

> + unsigned int mask;
> +};
> +
>  /**
>   * struct rvin_info - Information about the particular VIN implementation
>   * @model:   VIN model
>   * @use_mc:  use media controller instead of controlling subdevice
>   * @max_width:   max input width the VIN supports
>   * @max_height:  max input height the VIN supports
> + * @routes:  routing table VIN <-> CSI-2 for the chsel values
>   */
>  struct rvin_info {
>   enum model_id model;
> @@ -94,6 +123,7 @@ struct rvin_info {
> 
>   unsigned int max_width;
>   unsigned int max_height;
> + const struct rvin_group_route *routes;
>  };
> 
>  /**

-- 
Regards,

Laurent Pinchart

Re: [PATCH v10 23/30] rcar-vin: change name of video device

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:28 EET Niklas Söderlund wrote:
> The rcar-vin driver needs to be part of a media controller to support
> Gen3. Give each VIN instance a unique name so it can be referenced from
> userspace.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> 292e1f22a4be36c7..3ac6cdcb18ce4a21 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -1012,7 +1012,7 @@ int rvin_v4l2_register(struct rvin_dev *vin)
>   /* video node */
>   vdev->v4l2_dev = >v4l2_dev;
>   vdev->queue = >queue;
> - strlcpy(vdev->name, KBUILD_MODNAME, sizeof(vdev->name));
> + snprintf(vdev->name, sizeof(vdev->name), "VIN%u output", vin->id);
>   vdev->release = video_device_release_empty;
>   vdev->lock = >lock;
>   vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |


-- 
Regards,

Laurent Pinchart

Re: [PATCH v10 22/30] rcar-vin: add group allocator functions

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:27 EET Niklas Söderlund wrote:
> In media controller mode all VIN instances needs to be part of the same
> media graph. There is also a need for each VIN instance to know about
> and in some cases be able to communicate with other VIN instances.
> 
> Add an allocator framework where the first VIN instance to be probed
> creates a shared data structure and registers a media device.
> Consecutive VINs insert themself into the global group.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 177 -
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  31 +
>  2 files changed, 206 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> 0c6960756c33f86c..4a64df5019ce45f7 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -20,12 +20,177 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> 
>  #include "rcar-vin.h"
> 
> +/* 
> + * Gen3 CSI2 Group Allocator
> + */
> +
> +/* FIXME:  This should if we find a system that supports more
> + * then one group for the whole system be replaced with a linked

s/then/than/

> + * list of groups. And eventually all of this should be replaced
> + * with a global device allocator API.
> + *
> + * But for now this works as on all supported systems there will
> + * be only one group for all instances.
> + */
> +
> +static DEFINE_MUTEX(rvin_group_lock);
> +static struct rvin_group *rvin_group_data;
> +
> +static void rvin_group_cleanup(struct rvin_group *group)
> +{
> + media_device_unregister(>mdev);
> + media_device_cleanup(>mdev);
> + mutex_destroy(>lock);
> +}
> +
> +static int rvin_group_init(struct rvin_group *group, struct rvin_dev *vin)
> +{
> + struct media_device *mdev = >mdev;
> + const struct of_device_id *match;
> + struct device_node *np;
> + int ret;
> +
> + mutex_init(>lock);
> +
> + /* Count number of VINs in the system */
> + group->count = 0;
> + for_each_matching_node(np, vin->dev->driver->of_match_table)
> + if (of_device_is_available(np))
> + group->count++;
> +
> + vin_dbg(vin, "found %u enabled VIN's in DT", group->count);
> +
> + mdev->dev = vin->dev;
> +
> + match = of_match_node(vin->dev->driver->of_match_table,
> +   vin->dev->of_node);
> +
> + strlcpy(mdev->driver_name, KBUILD_MODNAME, sizeof(mdev->driver_name));
> + strlcpy(mdev->model, match->compatible, sizeof(mdev->model));
> + snprintf(mdev->bus_info, sizeof(mdev->bus_info), "platform:%s",
> +  dev_name(mdev->dev));
> +
> + media_device_init(mdev);
> +
> + ret = media_device_register(>mdev);
> + if (ret)
> + rvin_group_cleanup(group);
> +
> + return ret;
> +}
> +
> +static void rvin_group_release(struct kref *kref)
> +{
> + struct rvin_group *group =
> + container_of(kref, struct rvin_group, refcount);
> +
> + mutex_lock(_group_lock);
> +
> + rvin_group_data = NULL;
> +
> + rvin_group_cleanup(group);
> +
> + kfree(group);
> +
> + mutex_unlock(_group_lock);
> +}
> +
> +static int rvin_group_get(struct rvin_dev *vin)
> +{
> + struct rvin_group *group;
> + u32 id;
> + int ret;
> +
> + /* Make sure VIN id is present and sane */
> + ret = of_property_read_u32(vin->dev->of_node, "renesas,id", );
> + if (ret) {
> + vin_err(vin, "%pOF: No renesas,id property found\n",
> + vin->dev->of_node);
> + return -EINVAL;
> + }
> +
> + if (id >= RCAR_VIN_NUM) {
> + vin_err(vin, "%pOF: Invalid renesas,id '%u'\n",
> + vin->dev->of_node, id);
> + return -EINVAL;
> + }

I'd move this out of this function to an OF parsing function, but we don't 
have one yet. Something to keep in mind for later.

> + /* Join or create a VIN group */
> + mutex_lock(_group_lock);
> + if (rvin_group_data) {
> + group = rvin_group_data;
> + kref_get(>refcount);
> + } else {
> + group = kzalloc(sizeof(*group), GFP_KERNEL);
> + if (!group) {
> + ret = -ENOMEM;
> + goto err_group;
> + }
> +
> + ret = rvin_group_init(group, vin);
> + if (ret) {
> + kfree(group);
> + vin_err(vin, "Failed to initialize group\n");
> + goto err_group;
> + }
> +
> + kref_init(>refcount);
> +
> + rvin_group_data = group;
> + }
> + mutex_unlock(_group_lock);
> +
> + /* Add VIN to 

Re: [PATCH v10 21/30] rcar-vin: prepare for media controller mode initialization

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:26 EET Niklas Söderlund wrote:
> Prepare for media controller by calling a different initialization then
> for when running in device centric mode. Add trivial configuration of

s/then for when/than when/

> the mbus and creation of the media pad for the video device entity.
> 
> While we are at it clearly mark the digital device centric notifier
> functions with a comment.
> 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 20 ++--
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  4 
>  2 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> 64034c96f384b3ed..0c6960756c33f86c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -46,6 +46,10 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int
> direction) return -EINVAL;
>  }
> 
> +/* 
> + * Digital async notifier
> + */
> +
>  /* The vin lock shuld be held when calling the subdevice attach and detach
> */ static int rvin_digital_subdevice_attach(struct rvin_dev *vin,
>struct v4l2_subdev *subdev)
> @@ -237,6 +241,16 @@ static int rvin_digital_graph_init(struct rvin_dev
> *vin) return 0;
>  }
> 
> +static int rvin_mc_init(struct rvin_dev *vin)
> +{
> + /* All our sources are CSI-2 */
> + vin->mbus_cfg.type = V4L2_MBUS_CSI2;
> + vin->mbus_cfg.flags = 0;
> +
> + vin->pad.flags = MEDIA_PAD_FL_SINK;
> + return media_entity_pads_init(>vdev.entity, 1, >pad);
> +}
> +
>  /* 
>   * Platform Device Driver
>   */
> @@ -325,8 +339,10 @@ static int rcar_vin_probe(struct platform_device *pdev)
> return ret;
> 
>   platform_set_drvdata(pdev, vin);
> -
> - ret = rvin_digital_graph_init(vin);
> + if (vin->info->use_mc)
> + ret = rvin_mc_init(vin);
> + else
> + ret = rvin_digital_graph_init(vin);
>   if (ret < 0)
>   goto error;
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h index
> 64476bc5c8abc6d0..4caef7193db09c5b 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -101,6 +101,8 @@ struct rvin_info {
>   * @notifier:V4L2 asynchronous subdevs notifier
>   * @digital: entity in the DT for local digital subdevice
>   *
> + * @pad: media pad for the video device entity
> + *
>   * @lock:protects @queue
>   * @queue:   vb2 buffers queue
>   *
> @@ -130,6 +132,8 @@ struct rvin_dev {
>   struct v4l2_async_notifier notifier;
>   struct rvin_graph_entity *digital;
> 
> + struct media_pad pad;
> +
>   struct mutex lock;
>   struct vb2_queue queue;

-- 
Regards,

Laurent Pinchart

Re: [Qemu-devel] [PATCH] device_tree: Increase FDT_MAX_SIZE to 128 KiB

[Peter Maydell]

On 13 February 2018 at 16:41, Geert Uytterhoeven
 wrote:
> It is not uncommon for a contemporary FDT to be larger than 64 KiB,
> leading to failures loading the device tree from sysfs:
>
> qemu-system-aarch64: qemu_fdt_setprop: Couldn't set ...: FDT_ERR_NOSPACE
>
> For reference, the largest arm64 DTB created from the Linux sources is
> 70 KiB large (93 KiB when built with symbols/fixup support).

I think we should probably give ourselves a bit more headroom,
then -- at least 256K.

The ppc boards actually define their own version of this constant:

#define FDT_MAX_SIZE0x0010

so I think we might as well just go with that in device_tree.c for
consistency.

thanks
-- PMM

Re: [PATCH v10 20/30] rcar-vin: use different v4l2 operations in media controller mode

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:25 EET Niklas Söderlund wrote:
> When the driver runs in media controller mode it should not directly
> control the subdevice instead userspace will be responsible for
> configuring the pipeline. To be able to run in this mode a different set
> of v4l2 operations needs to be used.
> 
> Add a new set of v4l2 operations to support operation without directly
> interacting with the source subdevice.
> 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c  |   3 +-
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 155 -
>  2 files changed, 154 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> ae286742f15a3ab5..811d8f8638d21200 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -628,7 +628,8 @@ static int rvin_setup(struct rvin_dev *vin)
>   /* Default to TB */
>   vnmc = VNMC_IM_FULL;
>   /* Use BT if video standard can be read and is 60 Hz format */
> - if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
> + if (!vin->info->use_mc &&
> + !v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
>   if (std & V4L2_STD_525_60)
>   vnmc = VNMC_IM_FULL | VNMC_FOC;
>   }
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> f69ae76b3fda50c7..292e1f22a4be36c7 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -18,11 +18,14 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include "rcar-vin.h"
> 
>  #define RVIN_DEFAULT_FORMAT  V4L2_PIX_FMT_YUYV
> +#define RVIN_DEFAULT_WIDTH   800
> +#define RVIN_DEFAULT_HEIGHT  600
>  #define RVIN_DEFAULT_FIELD   V4L2_FIELD_NONE
>  #define RVIN_DEFAULT_COLORSPACE  V4L2_COLORSPACE_SRGB
> 
> @@ -698,6 +701,83 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
>   .vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
>  };
> 
> +/* 
> + * V4L2 Media Controller
> + */
> +
> +static int __rvin_mc_try_format(struct rvin_dev *vin,
> + struct v4l2_pix_format *pix)
> +{
> + if (pix->field == V4L2_FIELD_ANY)
> + pix->field = RVIN_DEFAULT_FIELD;
> +
> + return rvin_format_align(vin, pix);
> +}
> +
> +static int rvin_mc_try_fmt_vid_cap(struct file *file, void *priv,
> +struct v4l2_format *f)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> +
> + return __rvin_mc_try_format(vin, >fmt.pix);
> +}
> +
> +static int rvin_mc_s_fmt_vid_cap(struct file *file, void *priv,
> +  struct v4l2_format *f)
> +{
> + struct rvin_dev *vin = video_drvdata(file);
> + int ret;
> +
> + if (vb2_is_busy(>queue))
> + return -EBUSY;
> +
> + ret = __rvin_mc_try_format(vin, >fmt.pix);
> + if (ret)
> + return ret;
> +
> + vin->format = f->fmt.pix;
> +
> + return 0;
> +}
> +
> +static int rvin_mc_enum_input(struct file *file, void *priv,
> +   struct v4l2_input *i)
> +{
> + if (i->index != 0)
> + return -EINVAL;
> +
> + i->type = V4L2_INPUT_TYPE_CAMERA;
> + strlcpy(i->name, "Camera", sizeof(i->name));
> +
> + return 0;
> +}
> +
> +static const struct v4l2_ioctl_ops rvin_mc_ioctl_ops = {
> + .vidioc_querycap= rvin_querycap,
> + .vidioc_try_fmt_vid_cap = rvin_mc_try_fmt_vid_cap,
> + .vidioc_g_fmt_vid_cap   = rvin_g_fmt_vid_cap,
> + .vidioc_s_fmt_vid_cap   = rvin_mc_s_fmt_vid_cap,
> + .vidioc_enum_fmt_vid_cap= rvin_enum_fmt_vid_cap,
> +
> + .vidioc_enum_input  = rvin_mc_enum_input,
> + .vidioc_g_input = rvin_g_input,
> + .vidioc_s_input = rvin_s_input,
> +
> + .vidioc_reqbufs = vb2_ioctl_reqbufs,
> + .vidioc_create_bufs = vb2_ioctl_create_bufs,
> + .vidioc_querybuf= vb2_ioctl_querybuf,
> + .vidioc_qbuf= vb2_ioctl_qbuf,
> + .vidioc_dqbuf   = vb2_ioctl_dqbuf,
> + .vidioc_expbuf  = vb2_ioctl_expbuf,
> + .vidioc_prepare_buf = vb2_ioctl_prepare_buf,
> + .vidioc_streamon= vb2_ioctl_streamon,
> + .vidioc_streamoff   = vb2_ioctl_streamoff,
> +
> + .vidioc_log_status  = v4l2_ctrl_log_status,
> + .vidioc_subscribe_event = rvin_subscribe_event,
> + 

[PATCH v2 2/4] arm64: dts: renesas: r8a77995: add VSP instances

[Kieran Bingham]

From: Kieran Bingham 

The r8a77995 has a VSPBS to support image processing such as blending of
two input images, and has two VSPDs to handle display pipelines with a
DU.

Signed-off-by: Kieran Bingham 

---
v2:
 - Fix VSPD register map size
 - Squash VSPBS and VSPD patches together

 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 196a917afea6..19bd8be9926a 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -692,6 +692,16 @@
status = "disabled";
};
 
+   vspbs: vsp@fe96 {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfe96 0 0x4000>;
+   interrupts = ;
+   clocks = < CPG_MOD 627>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 627>;
+   renesas,fcp = <>;
+   };
+
fcpvb0: fcp@fe96f000 {
compatible = "renesas,fcpv";
reg = <0 0xfe96f000 0 0x200>;
@@ -701,6 +711,16 @@
iommus = <_vp0 5>;
};
 
+   vspd0: vsp@fea2 {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfea2 0 0x8000>;
+   interrupts = ;
+   clocks = < CPG_MOD 623>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 623>;
+   renesas,fcp = <>;
+   };
+
fcpvd0: fcp@fea27000 {
compatible = "renesas,fcpv";
reg = <0 0xfea27000 0 0x200>;
@@ -710,6 +730,16 @@
iommus = <_vi0 8>;
};
 
+   vspd1: vsp@fea8 {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfea28000 0 0x8000>;
+   interrupts = ;
+   clocks = < CPG_MOD 622>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 622>;
+   renesas,fcp = <>;
+   };
+
fcpvd1: fcp@fea2f000 {
compatible = "renesas,fcpv";
reg = <0 0xfea2f000 0 0x200>;
-- 
2.7.4

[PATCH v2 3/4] arm64: dts: renesas: r8a7795: Fix register mappings on VSPs

[Kieran Bingham]

From: Kieran Bingham 

The VSPD includes a CLUT on RPF2. Ensure that the register space is
mapped correctly to support this.

Signed-off-by: Kieran Bingham 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 1f32340af2d1..772991db8820 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2607,7 +2607,7 @@
 
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
-   reg = <0 0xfea2 0 0x4000>;
+   reg = <0 0xfea2 0 0x8000>;
interrupts = ;
clocks = < CPG_MOD 623>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
@@ -2627,7 +2627,7 @@
 
vspd1: vsp@fea28000 {
compatible = "renesas,vsp2";
-   reg = <0 0xfea28000 0 0x4000>;
+   reg = <0 0xfea28000 0 0x8000>;
interrupts = ;
clocks = < CPG_MOD 622>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
@@ -2647,7 +2647,7 @@
 
vspd2: vsp@fea3 {
compatible = "renesas,vsp2";
-   reg = <0 0xfea3 0 0x4000>;
+   reg = <0 0xfea3 0 0x8000>;
interrupts = ;
clocks = < CPG_MOD 621>;
power-domains = < R8A7795_PD_ALWAYS_ON>;
-- 
2.7.4

[PATCH v2 4/4] arm64: dts: renesas: r8a7796: Fix register mappings on VSPs

[Kieran Bingham]

From: Kieran Bingham 

The VSPD includes a CLUT on RPF2. Ensure that the register space is
mapped correctly to support this.

Signed-off-by: Kieran Bingham 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 60755117cba5..3fe5566e0630 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -2285,7 +2285,7 @@
 
vspd0: vsp@fea2 {
compatible = "renesas,vsp2";
-   reg = <0 0xfea2 0 0x4000>;
+   reg = <0 0xfea2 0 0x8000>;
interrupts = ;
clocks = < CPG_MOD 623>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
@@ -2305,7 +2305,7 @@
 
vspd1: vsp@fea28000 {
compatible = "renesas,vsp2";
-   reg = <0 0xfea28000 0 0x4000>;
+   reg = <0 0xfea28000 0 0x8000>;
interrupts = ;
clocks = < CPG_MOD 622>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
@@ -2325,7 +2325,7 @@
 
vspd2: vsp@fea3 {
compatible = "renesas,vsp2";
-   reg = <0 0xfea3 0 0x4000>;
+   reg = <0 0xfea3 0 0x8000>;
interrupts = ;
clocks = < CPG_MOD 621>;
power-domains = < R8A7796_PD_ALWAYS_ON>;
-- 
2.7.4

[PATCH v2 1/4] arm64: dts: renesas: r8a77995: add FCPV nodes

[Kieran Bingham]

From: Kieran Bingham 

The FCPVB handles the interface between the VSPB and memory, while the
FCPVD handles the interface between the VSPD and memory.

Signed-off-by: Kieran Bingham 

 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index cd3c6a30fc47..196a917afea6 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -691,6 +691,33 @@
#phy-cells = <0>;
status = "disabled";
};
+
+   fcpvb0: fcp@fe96f000 {
+   compatible = "renesas,fcpv";
+   reg = <0 0xfe96f000 0 0x200>;
+   clocks = < CPG_MOD 607>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 607>;
+   iommus = <_vp0 5>;
+   };
+
+   fcpvd0: fcp@fea27000 {
+   compatible = "renesas,fcpv";
+   reg = <0 0xfea27000 0 0x200>;
+   clocks = < CPG_MOD 603>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 603>;
+   iommus = <_vi0 8>;
+   };
+
+   fcpvd1: fcp@fea2f000 {
+   compatible = "renesas,fcpv";
+   reg = <0 0xfea2f000 0 0x200>;
+   clocks = < CPG_MOD 602>;
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 602>;
+   iommus = <_vi0 9>;
+   };
};
 
timer {
-- 
2.7.4

[PATCH v2 0/4] arm64: dts: renesas: r8a77995: Add VSP support

[Kieran Bingham]

From: Kieran Bingham 

The r8a77995-d3 platform supports 3 VSP instances. One VSPBS can be used
as a dual-input image blender, while two VSPD instances can be utilised as
part of a display (DU) pipeline.

Add support for these, along with their required FCPV nodes.

During review, Laurent noticed that the r8a7795 and r8a7796 were not mapping
enough register space to handle RPFs with CLUT modules.

The last two patches fix this issue.

v2:
 - Merge FCPV nodes to a single patch
 - Merge VSP nodes to a single patch
 - Fix VSP register map size
 - Add fixes for r8a7795 and r8a7796

Kieran Bingham (4):
  arm64: dts: renesas: r8a77995: add FCPV nodes
  arm64: dts: renesas: r8a77995: add VSP instances
  arm64: dts: renesas: r8a7795: Fix register mappings on VSPs
  arm64: dts: renesas: r8a7796: Fix register mappings on VSPs

 arch/arm64/boot/dts/renesas/r8a7795.dtsi  |  6 ++--
 arch/arm64/boot/dts/renesas/r8a7796.dtsi  |  6 ++--
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 57 +++
 3 files changed, 63 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH v4 0/5] Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Kieran Bingham 

Back in 2014, Jean-Michel provided patches [0] to implement a means of
describing software defined I2C addresses for devices through the DT nodes.

The patch to implement the function "i2c_new_secondary_device()" was integrated,
but the corresponding driver update didn't get applied.

This short series re-bases Jean-Michel's patch to mainline for the ADV7604 
driver
in linux-media, and also provides a patch for the ADV7511 DRM Bridge driver 
taking
the same approach.

This series allows us to define the I2C address allocations of these devices in
the device tree for the Renesas D3 platform where these two devices reside on
the same bus and conflict with each other presently..

[0] https://lkml.org/lkml/2014/10/22/468
[1] https://lkml.org/lkml/2014/10/22/469

v2:
 - dt bindings split from driver changes
 - fixed up dt binding property descriptions
 - Update missing edid-i2c address setting (adv7511)
 - Provide update for r8a7792 DTB to account for address conflict

v3:
 - Split map register addresses into individual declarations across all uses

v4:
 - Normalise the usage of the I2C term throughout
 - Fix registration/cleanup of packet client in adv7511
 - Rename adv76xx structures
 - Update commit titles of dt-bindings patches.



Jean-Michel Hautbois (2):
  dt-bindings: media: adv7604: Extend bindings to allow specifying slave
map addresses
  media: adv7604: Add support for i2c_new_secondary_device

Kieran Bingham (3):
  dt-bindings: adv7511: Extend bindings to allow specifying slave map
addresses
  [RFT] ARM: dts: wheat: Fix ADV7513 address usage
  drm: adv7511: Add support for i2c_new_secondary_device

 .../bindings/display/bridge/adi,adv7511.txt| 18 ++-
 .../devicetree/bindings/media/i2c/adv7604.txt  | 18 ++-
 arch/arm/boot/dts/r8a7792-wheat.dts| 12 -
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |  6 +++
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 42 +--
 drivers/media/i2c/adv7604.c| 62 ++
 6 files changed, 115 insertions(+), 43 deletions(-)

-- 
2.7.4

Re: [PATCH v10 19/30] rcar-vin: set a default field to fallback on

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:24 EET Niklas Söderlund wrote:
> If the field is not supported by the driver it should not try to keep
> the current field. Instead it should set it to a default fallback. Since
> trying a format should always result in the same state regardless of the
> current state of the device.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> 6403650aff22a2ed..f69ae76b3fda50c7 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -23,6 +23,7 @@
>  #include "rcar-vin.h"
> 
>  #define RVIN_DEFAULT_FORMAT  V4L2_PIX_FMT_YUYV
> +#define RVIN_DEFAULT_FIELD   V4L2_FIELD_NONE
>  #define RVIN_DEFAULT_COLORSPACE  V4L2_COLORSPACE_SRGB
> 
>  /* 
> @@ -171,7 +172,7 @@ static int rvin_get_source_format(struct rvin_dev
> *vin, fmt.format.height *= 2;
>   break;
>   default:
> - vin->format.field = V4L2_FIELD_NONE;
> + vin->format.field = RVIN_DEFAULT_FIELD;
>   break;
>   }
> 
> @@ -267,9 +268,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
>  {
>   int ret;
> 
> - /* Keep current field if no specific one is asked for */
>   if (pix->field == V4L2_FIELD_ANY)
> - pix->field = vin->format.field;
> + pix->field = RVIN_DEFAULT_FIELD;

Won't this also be caught by the field check in the above function, called 
from __rvin_try_format_source() ? You could just remove this check completely.

However as mentioned in a comment for a previous patch I don't think the field 
handling belongs in rvin_get_source_format(), so you could merge both here. 
Or, if you repurpose and rename rvin_get_source_format(), then the check can 
probably be removed completely. I haven't checked the consolidated code after 
applying all patches from this series, but some refactoring might be useful. 
We'll see.

>   /* Limit to source capabilities */
>   ret = __rvin_try_format_source(vin, which, pix);

-- 
Regards,

Laurent Pinchart

[PATCH v4 2/5] dt-bindings: adv7511: Extend bindings to allow specifying slave map addresses

[Kieran Bingham]

From: Kieran Bingham 

The ADV7511 has four 256-byte maps that can be accessed via the main I2C
ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.

Extend the device tree node bindings to be able to override the default
addresses so that address conflicts with other devices on the same bus
may be resolved at the board description level.

Signed-off-by: Kieran Bingham 
Reviewed-by: Rob Herring 
Reviewed-by: Laurent Pinchart 
---
v2:
 - Fixed up reg: property description to account for multiple optional
   addresses.
 - Minor reword to commit message to account for DT only change
 - Collected Robs RB tag

v3:
 - Split map register addresses into individual declarations.

v4:
 - Update commit title
 - Collect Laurent's RB tag
 - Fix nitpickings
 - Normalise I2C usage (I²C is harder to grep for)

 .../devicetree/bindings/display/bridge/adi,adv7511.txt | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 0047b1394c70..2c887536258c 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -14,7 +14,13 @@ Required properties:
"adi,adv7513"
"adi,adv7533"
 
-- reg: I2C slave address
+- reg: I2C slave addresses
+  The ADV7511 internal registers are split into four pages exposed through
+  different I2C addresses, creating four register maps. Each map has it own
+  I2C address and acts as a standard slave device on the I2C bus. The main
+  address is mandatory, others are optional and revert to defaults if not
+  specified.
+
 
 The ADV7511 supports a large number of input data formats that differ by their
 color depth, color format, clock mode, bit justification and random
@@ -70,6 +76,9 @@ Optional properties:
   rather than generate its own timings for HDMI output.
 - clocks: from common clock binding: reference to the CEC clock.
 - clock-names: from common clock binding: must be "cec".
+- reg-names : Names of maps with programmable addresses.
+   It can contain any map needing a non-default address.
+   Possible maps names are : "main", "edid", "cec", "packet"
 
 Required nodes:
 
@@ -88,7 +97,12 @@ Example
 
adv7511w: hdmi@39 {
compatible = "adi,adv7511w";
-   reg = <39>;
+   /*
+* The EDID page will be accessible on address 0x66 on the I2C
+* bus. All other maps continue to use their default addresses.
+*/
+   reg = <0x39>, <0x66>;
+   reg-names = "main", "edid";
interrupt-parent = <>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <_clock>;
-- 
2.7.4

[PATCH v4 4/5] media: adv7604: Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Jean-Michel Hautbois 

The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I2C ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.

Allow a device tree node to override the default addresses so that
address conflicts with other devices on the same bus may be resolved at
the board description level.

Signed-off-by: Jean-Michel Hautbois 
[Kieran: Re-adapted for mainline]
Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
---
Based upon the original posting :
  https://lkml.org/lkml/2014/10/22/469

v2:
 - Split out DT bindings from driver updates
 - Return -EINVAL on error paths from adv76xx_dummy_client()

v3:
 - No change

v4:
 - s/struct adv76xx_register/struct adv76xx_register_map/
 - s/adv76xx_secondary_names/adv76xx_default_addresses/
 - Normalise I2C usage (s/I²C/I2C/)

 drivers/media/i2c/adv7604.c | 62 +
 1 file changed, 40 insertions(+), 22 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 1544920ec52d..d52c624a2970 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2734,6 +2734,27 @@ static const struct v4l2_ctrl_config 
adv76xx_ctrl_free_run_color = {
 
 /* --- */
 
+struct adv76xx_register_map {
+   const char *name;
+   u8 default_addr;
+};
+
+static const struct adv76xx_register_map adv76xx_default_addresses[] = {
+   [ADV76XX_PAGE_IO] = { "main", 0x4c },
+   [ADV7604_PAGE_AVLINK] = { "avlink", 0x42 },
+   [ADV76XX_PAGE_CEC] = { "cec", 0x40 },
+   [ADV76XX_PAGE_INFOFRAME] = { "infoframe", 0x3e },
+   [ADV7604_PAGE_ESDP] = { "esdp", 0x38 },
+   [ADV7604_PAGE_DPP] = { "dpp", 0x3c },
+   [ADV76XX_PAGE_AFE] = { "afe", 0x26 },
+   [ADV76XX_PAGE_REP] = { "rep", 0x32 },
+   [ADV76XX_PAGE_EDID] = { "edid", 0x36 },
+   [ADV76XX_PAGE_HDMI] = { "hdmi", 0x34 },
+   [ADV76XX_PAGE_TEST] = { "test", 0x30 },
+   [ADV76XX_PAGE_CP] = { "cp", 0x22 },
+   [ADV7604_PAGE_VDP] = { "vdp", 0x24 },
+};
+
 static int adv76xx_core_init(struct v4l2_subdev *sd)
 {
struct adv76xx_state *state = to_state(sd);
@@ -2834,13 +2855,26 @@ static void adv76xx_unregister_clients(struct 
adv76xx_state *state)
 }
 
 static struct i2c_client *adv76xx_dummy_client(struct v4l2_subdev *sd,
-   u8 addr, u8 io_reg)
+  unsigned int page)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
+   struct adv76xx_state *state = to_state(sd);
+   struct adv76xx_platform_data *pdata = >pdata;
+   unsigned int io_reg = 0xf2 + page;
+   struct i2c_client *new_client;
+
+   if (pdata && pdata->i2c_addresses[page])
+   new_client = i2c_new_dummy(client->adapter,
+  pdata->i2c_addresses[page]);
+   else
+   new_client = i2c_new_secondary_device(client,
+   adv76xx_default_addresses[page].name,
+   adv76xx_default_addresses[page].default_addr);
 
-   if (addr)
-   io_write(sd, io_reg, addr << 1);
-   return i2c_new_dummy(client->adapter, io_read(sd, io_reg) >> 1);
+   if (new_client)
+   io_write(sd, io_reg, new_client->addr << 1);
+
+   return new_client;
 }
 
 static const struct adv76xx_reg_seq adv7604_recommended_settings_afe[] = {
@@ -3115,20 +3149,6 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
/* Disable the interrupt for now as no DT-based board uses it. */
state->pdata.int1_config = ADV76XX_INT1_CONFIG_DISABLED;
 
-   /* Use the default I2C addresses. */
-   state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_CEC] = 0x40;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_INFOFRAME] = 0x3e;
-   state->pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38;
-   state->pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_AFE] = 0x26;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_REP] = 0x32;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_EDID] = 0x36;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_HDMI] = 0x34;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_TEST] = 0x30;
-   state->pdata.i2c_addresses[ADV76XX_PAGE_CP] = 0x22;
-   state->pdata.i2c_addresses[ADV7604_PAGE_VDP] = 0x24;
-
/* Hardcode the remaining platform data fields. */
state->pdata.disable_pwrdnb = 0;
state->pdata.disable_cable_det_rst = 0;
@@ -3478,11 +3498,9 @@ static int adv76xx_probe(struct i2c_client *client,
if (!(BIT(i) & state->info->page_mask))

[PATCH v4 1/5] dt-bindings: media: adv7604: Extend bindings to allow specifying slave map addresses

[Kieran Bingham]

From: Jean-Michel Hautbois 

The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I2C ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.

Extend the device tree node bindings to be able to override the default
addresses so that address conflicts with other devices on the same bus
may be resolved at the board description level.

Signed-off-by: Jean-Michel Hautbois 
[Kieran: Re-adapted for mainline]
Signed-off-by: Kieran Bingham 
Reviewed-by: Rob Herring 
Reviewed-by: Laurent Pinchart 

---
Based upon the original posting :
  https://lkml.org/lkml/2014/10/22/469

v2:
 - DT Binding update separated from code change
 - Minor reword to commit message to account for DT only change.
 - Collected Rob's RB tag.

v3:
 - Split map register addresses into individual declarations.

v4:
 - Collect Laurents RB tag
 - Adapt commit title
 - Normalise I2C usage (I²C is harder to grep for)

 .../devicetree/bindings/media/i2c/adv7604.txt  | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt 
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index 9cbd92eb5d05..dcf57e7c60eb 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -13,7 +13,11 @@ Required Properties:
 - "adi,adv7611" for the ADV7611
 - "adi,adv7612" for the ADV7612
 
-  - reg: I2C slave address
+  - reg: I2C slave addresses
+The ADV76xx has up to thirteen 256-byte maps that can be accessed via the
+main I2C ports. Each map has it own I2C address and acts as a standard
+slave device on the I2C bus. The main address is mandatory, others are
+optional and revert to defaults if not specified.
 
   - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
 detection pins, one per HDMI input. The active flag indicates the GPIO
@@ -35,6 +39,11 @@ Optional Properties:
 
   - reset-gpios: Reference to the GPIO connected to the device's reset pin.
   - default-input: Select which input is selected after reset.
+  - reg-names : Names of maps with programmable addresses.
+   It can contain any map needing a non-default address.
+   Possible maps names are :
+ "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
+ "rep", "edid", "hdmi", "test", "cp", "vdp"
 
 Optional Endpoint Properties:
 
@@ -52,7 +61,12 @@ Example:
 
hdmi_receiver@4c {
compatible = "adi,adv7611";
-   reg = <0x4c>;
+   /*
+* The edid page will be accessible @ 0x66 on the I2C bus. All
+* other maps will retain their default addresses.
+*/
+   reg = <0x4c>, <0x66>;
+   reg-names "main", "edid";
 
reset-gpios = < 0 GPIO_ACTIVE_LOW>;
hpd-gpios = < 2 GPIO_ACTIVE_HIGH>;
-- 
2.7.4

[PATCH v4 3/5] [RFT] ARM: dts: wheat: Fix ADV7513 address usage

[Kieran Bingham]

From: Kieran Bingham 

The r8a7792 Wheat board has two ADV7513 devices sharing a single I2C
bus, however in low power mode the ADV7513 will reset it's slave maps to
use the hardware defined default addresses.

The ADV7511 driver was adapted to allow the two devices to be registered
correctly - but it did not take into account the fault whereby the
devices reset the addresses.

This results in an address conflict between the device using the default
addresses, and the other device if it is in low-power-mode.

Repair this issue by moving both devices away from the default address
definitions.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
---
v2:
 - Addition to series

v3:
 - Split map register addresses into individual declarations.

v4:
 - Normalise I2C usage

 arch/arm/boot/dts/r8a7792-wheat.dts | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts 
b/arch/arm/boot/dts/r8a7792-wheat.dts
index b9471b67b728..42fff8837eab 100644
--- a/arch/arm/boot/dts/r8a7792-wheat.dts
+++ b/arch/arm/boot/dts/r8a7792-wheat.dts
@@ -240,9 +240,16 @@
status = "okay";
clock-frequency = <40>;
 
+   /*
+* The adv75xx resets its addresses to defaults during low power power
+* mode. Because we have two ADV7513 devices on the same bus, we must
+* change both of them away from the defaults so that they do not
+* conflict.
+*/
hdmi@3d {
compatible = "adi,adv7513";
-   reg = <0x3d>;
+   reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
+   reg-names = "main", "cec", "edid", "packet";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
@@ -272,7 +279,8 @@
 
hdmi@39 {
compatible = "adi,adv7513";
-   reg = <0x39>;
+   reg = <0x39>, <0x29>, <0x49>, <0x59>;
+   reg-names = "main", "cec", "edid", "packet";
 
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
-- 
2.7.4

[PATCH v4 5/5] drm: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

From: Kieran Bingham 

The ADV7511 has four 256-byte maps that can be accessed via the main I2C
ports. Each map has it own I2C address and acts as a standard slave
device on the I2C bus.

Allow a device tree node to override the default addresses so that
address conflicts with other devices on the same bus may be resolved at
the board description level.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
---
v2:
 - Update missing edid-i2c address setting
 - Split out DT bindings
 - Rename and move the I2C default addresses to their own section

v3:
 - No change

v4:
 - Change registration order of packet/cec to fix error path and
   simplify code change.
 - Collect Laurent's RB tag

 drivers/gpu/drm/bridge/adv7511/adv7511.h |  6 
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 42 ++--
 2 files changed, 33 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index d034b2cb5eee..73d8ccb97742 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -93,6 +93,11 @@
 #define ADV7511_REG_CHIP_ID_HIGH   0xf5
 #define ADV7511_REG_CHIP_ID_LOW0xf6
 
+/* Hardware defined default addresses for I2C register maps */
+#define ADV7511_CEC_I2C_ADDR_DEFAULT   0x3c
+#define ADV7511_EDID_I2C_ADDR_DEFAULT  0x3f
+#define ADV7511_PACKET_I2C_ADDR_DEFAULT0x38
+
 #define ADV7511_CSC_ENABLE BIT(7)
 #define ADV7511_CSC_UPDATE_MODEBIT(5)
 
@@ -321,6 +326,7 @@ enum adv7511_type {
 struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
+   struct i2c_client *i2c_packet;
struct i2c_client *i2c_cec;
 
struct regmap *regmap;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index efa29db5fc2b..802bc433f54a 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -586,7 +586,7 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
/* Reading the EDID only works if the device is powered */
if (!adv7511->powered) {
unsigned int edid_i2c_addr =
-   (adv7511->i2c_main->addr << 1) + 4;
+   (adv7511->i2c_edid->addr << 1);
 
__adv7511_power_on(adv7511);
 
@@ -969,10 +969,10 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
 {
int ret;
 
-   adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,
-adv->i2c_main->addr - 1);
+   adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
+   ADV7511_CEC_I2C_ADDR_DEFAULT);
if (!adv->i2c_cec)
-   return -ENOMEM;
+   return -EINVAL;
i2c_set_clientdata(adv->i2c_cec, adv);
 
adv->regmap_cec = devm_regmap_init_i2c(adv->i2c_cec,
@@ -1082,8 +1082,6 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
struct adv7511_link_config link_config;
struct adv7511 *adv7511;
struct device *dev = >dev;
-   unsigned int main_i2c_addr = i2c->addr << 1;
-   unsigned int edid_i2c_addr = main_i2c_addr + 4;
unsigned int val;
int ret;
 
@@ -1153,23 +1151,34 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
if (ret)
goto uninit_regulators;
 
-   regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
-   regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
-main_i2c_addr - 0xa);
-   regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
-main_i2c_addr - 2);
-
adv7511_packet_disable(adv7511, 0x);
 
-   adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);
+   adv7511->i2c_edid = i2c_new_secondary_device(i2c, "edid",
+   ADV7511_EDID_I2C_ADDR_DEFAULT);
if (!adv7511->i2c_edid) {
-   ret = -ENOMEM;
+   ret = -EINVAL;
goto uninit_regulators;
}
 
+   regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
+adv7511->i2c_edid->addr << 1);
+
+   adv7511->i2c_packet = i2c_new_secondary_device(i2c, "packet",
+   ADV7511_PACKET_I2C_ADDR_DEFAULT);
+   if (!adv7511->i2c_packet) {
+   ret = -EINVAL;
+   goto err_i2c_unregister_edid;
+   }
+
+   regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
+adv7511->i2c_packet->addr << 1);
+
ret = 

Re: [PATCH v10 13/30] rcar-vin: add function to manipulate Gen3 chsel value

[Niklas Söderlund]

Hi Laurent,

On 2018-02-13 19:02:38 +0200, Laurent Pinchart wrote:
> Hi Niklas,
> 
> On Tuesday, 13 February 2018 18:58:09 EET Niklas Söderlund wrote:
> > On 2018-02-13 18:41:33 +0200, Laurent Pinchart wrote:
> > > On Monday, 29 January 2018 18:34:18 EET Niklas Söderlund wrote:
> > > > On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
> > > > feature of this register is that it's only present in the VIN0 and VIN4
> > > > instances. The register in VIN0 controls the routing for VIN0-3 and the
> > > > register in VIN4 controls routing for VIN4-7.
> > > > 
> > > > To be able to control routing from a media device this function is need
> > > > to control runtime PM for the subgroup master (VIN0 and VIN4). The
> > > > subgroup master must be switched on before the register is manipulated,
> > > > once the operation is complete it's safe to switch the master off and
> > > > the new routing will still be in effect.
> > > > 
> > > > Signed-off-by: Niklas Söderlund 
> > > > ---
> > >> 
> > >>  drivers/media/platform/rcar-vin/rcar-dma.c | 28+
> > >>  drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
> > >>  2 files changed, 30 insertions(+)
> > >> 
> > >> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> > >> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> > >> 2f9ad1bec1c8a92f..ae286742f15a3ab5 100644
> > >> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> > >> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> > >> @@ -16,6 +16,7 @@
> > >> 
> > >>  #include 
> > >>  #include 
> > >> +#include 
> > >> 
> > >>  #include 
> > >> 
> > >> @@ -1228,3 +1229,30 @@ int rvin_dma_register(struct rvin_dev *vin, int
> > >> irq)
> > >>  return ret;
> > >>  }
> > >> 
> > >> +
> > >> +/* -
> > >> + * Gen3 CHSEL manipulation
> > >> + */
> > >> +
> > >> +void rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel)
> > >> +{
> > >> +u32 ifmd, vnmc;
> > >> +
> > >> +pm_runtime_get_sync(vin->dev);
> > > 
> > > No need to check for errors ?
> > 
> > You asked the samething for v9 so I will copy paste the same reply :-)
> 
> Oh so you expect me to remember what happened with previous versions ? :-)

:-)

> 
> > Sakari asked the same thing in v4 :-)
> > 
> > In short no its not needed please see Geert's response [1]. If I
> > recall correctly this was also discussed in more detail in another
> > thread for some other driver whit a bit longer answer saying that it
> > pm_runtime_get_sync() fails you have big problems but I can't find
> > that thread now :-(
> > 
> > 1. https://www.spinics.net/lists/linux-media/msg115241.html
> 
> If kmalloc() fails we also have big problems, but we nonetheless check every 
> memory allocation.

I did some quick and dirty statistics for current upstream behavior,

$ git grep pm_runtime_get_sync | wc -l
1044
$ git grep pm_runtime_get_sync | grep = | wc -l
367

It looks like a less then half checks the return value :-) But as it 
will take at least one more incarnation of this patch set I will add a 
check for it get to the good side of things.

> 
> > >> +
> > >> +/* Make register writes take effect immediately */
> > >> +vnmc = rvin_read(vin, VNMC_REG);
> > >> +rvin_write(vin, vnmc & ~VNMC_VUP, VNMC_REG);
> > >> +
> > >> +ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
> > >> +VNCSI_IFMD_CSI_CHSEL(chsel);
> > >> +
> > >> +rvin_write(vin, ifmd, VNCSI_IFMD_REG);
> > >> +
> > >> +vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
> > >> +
> > >> +/* Restore VNMC */
> > >> +rvin_write(vin, vnmc, VNMC_REG);
> > > 
> > > No need for locking around all this ? What happens if this VIN instance
> > > decides to write to another VIN register (for instance due to a userpace
> > > call) when this function has disabled VNMC_VUP ?
> > 
> > You also asked a related question to this in v9 as a start I will copy
> > in that reply.
> > 
> > Media link changes are not allowed when any VIN in the group are
> > streaming so this should not be an issue.
> > 
> > And to compliment that. This function is only valid for a VIN which has
> > the CHSEL register which currently is VIN0 and VIN4. It can only be
> > modified when a media link is enabled. Catching media links are only
> > allowed when all VIN in the system are _not_ streaming. And VNMC_VUP is
> > only enabled when a VIN is streaming so there is no need for locking
> > here.
> 
> This seems a bit fragile to me, could you please capture the explanation in a 
> comment ?
> 

Will do.

> > >> +pm_runtime_put(vin->dev);
> > >> +}
> > >> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> > >> b/drivers/media/platform/rcar-vin/rcar-vin.h index
> > >> 146683142e6533fa..a5dae5b5e9cb704b 100644
> > >> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> > >> +++ 

Re: [PATCH v10 18/30] rcar-vin: add check for colorspace

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:23 EET Niklas Söderlund wrote:
> Add a check to ensure the colorspace from user-space is good. On Gen2 it
> works without this change as the sensor sets the colorspace but on Gen3
> this can fail if the colorspace provided by the user is not good. The
> values to check for comes from v4l2-compliance sources which is the tool
> that found this error. If this check is not preformed v4l2-compliance

s/preformed/performed/

> fails when it tests colorspace.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> 841d62ca27e026d7..6403650aff22a2ed 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -23,6 +23,7 @@
>  #include "rcar-vin.h"
> 
>  #define RVIN_DEFAULT_FORMAT  V4L2_PIX_FMT_YUYV
> +#define RVIN_DEFAULT_COLORSPACE  V4L2_COLORSPACE_SRGB
> 
>  /* 
>   * Format Conversions
> @@ -115,6 +116,10 @@ static int rvin_format_align(struct rvin_dev *vin,
> struct v4l2_pix_format *pix) break;
>   }
> 
> + /* Check that colorspace is reasonable */
> + if (!pix->colorspace || pix->colorspace >= 0xff)

I'd write the first check as

pix->colorspace == V4L2_COLORSPACE_DEFAULT

For the second check I don't think 0xff is a meaningful value. We currently 
have 12 colorspaces defined. If we want to be future-proof I'd add a 
V4L2_COLORSPACE_MAX entry to enum v4l2_colorspace and use that for the check. 
Alternatively you could use V4L2_COLORSPACE_DCI_P3 but the driver would need 
to be updated when new colorspaces get added.

> + pix->colorspace = RVIN_DEFAULT_COLORSPACE;
> +
>   /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
>   walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v10 17/30] rcar-vin: update pixelformat check for M1

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:22 EET Niklas Söderlund wrote:
> If the pixelformat is not supported it should not fail but be set to
> something that works. While we are at it move the check together with
> other pixelformat checks of this function.

Please ignore my related comment to patch 16/30 :-) However, could you move 
this patch before 16/30 ?

> Signed-off-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> bca6e204a574772f..841d62ca27e026d7 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -97,6 +97,10 @@ static int rvin_format_align(struct rvin_dev *vin, struct
> v4l2_pix_format *pix) pix->pixelformat = RVIN_DEFAULT_FORMAT;
>   }
> 
> + if (vin->info->model == RCAR_M1 &&
> + pix->pixelformat == V4L2_PIX_FMT_XBGR32)
> + pix->pixelformat = RVIN_DEFAULT_FORMAT;
> +
>   /* Reject ALTERNATE  until support is added to the driver */
>   switch (pix->field) {
>   case V4L2_FIELD_TOP:
> @@ -121,12 +125,6 @@ static int rvin_format_align(struct rvin_dev *vin,
> struct v4l2_pix_format *pix) pix->bytesperline =
> rvin_format_bytesperline(pix);
>   pix->sizeimage = rvin_format_sizeimage(pix);
> 
> - if (vin->info->model == RCAR_M1 &&
> - pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
> - vin_err(vin, "pixel format XBGR32 not supported on M1\n");
> - return -EINVAL;
> - }
> -
>   vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
>   pix->width, pix->height, pix->bytesperline, pix->sizeimage);

-- 
Regards,

Laurent Pinchart

Re: [PATCH v10 13/30] rcar-vin: add function to manipulate Gen3 chsel value

[Laurent Pinchart]

Hi Niklas,

On Tuesday, 13 February 2018 18:58:09 EET Niklas Söderlund wrote:
> On 2018-02-13 18:41:33 +0200, Laurent Pinchart wrote:
> > On Monday, 29 January 2018 18:34:18 EET Niklas Söderlund wrote:
> > > On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
> > > feature of this register is that it's only present in the VIN0 and VIN4
> > > instances. The register in VIN0 controls the routing for VIN0-3 and the
> > > register in VIN4 controls routing for VIN4-7.
> > > 
> > > To be able to control routing from a media device this function is need
> > > to control runtime PM for the subgroup master (VIN0 and VIN4). The
> > > subgroup master must be switched on before the register is manipulated,
> > > once the operation is complete it's safe to switch the master off and
> > > the new routing will still be in effect.
> > > 
> > > Signed-off-by: Niklas Söderlund 
> > > ---
> >> 
> >>  drivers/media/platform/rcar-vin/rcar-dma.c | 28+
> >>  drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
> >>  2 files changed, 30 insertions(+)
> >> 
> >> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> >> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> >> 2f9ad1bec1c8a92f..ae286742f15a3ab5 100644
> >> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> >> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> >> @@ -16,6 +16,7 @@
> >> 
> >>  #include 
> >>  #include 
> >> +#include 
> >> 
> >>  #include 
> >> 
> >> @@ -1228,3 +1229,30 @@ int rvin_dma_register(struct rvin_dev *vin, int
> >> irq)
> >>return ret;
> >>  }
> >> 
> >> +
> >> +/* -
> >> + * Gen3 CHSEL manipulation
> >> + */
> >> +
> >> +void rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel)
> >> +{
> >> +  u32 ifmd, vnmc;
> >> +
> >> +  pm_runtime_get_sync(vin->dev);
> > 
> > No need to check for errors ?
> 
> You asked the samething for v9 so I will copy paste the same reply :-)

Oh so you expect me to remember what happened with previous versions ? :-)

> Sakari asked the same thing in v4 :-)
> 
> In short no its not needed please see Geert's response [1]. If I
> recall correctly this was also discussed in more detail in another
> thread for some other driver whit a bit longer answer saying that it
> pm_runtime_get_sync() fails you have big problems but I can't find
> that thread now :-(
> 
> 1. https://www.spinics.net/lists/linux-media/msg115241.html

If kmalloc() fails we also have big problems, but we nonetheless check every 
memory allocation.

> >> +
> >> +  /* Make register writes take effect immediately */
> >> +  vnmc = rvin_read(vin, VNMC_REG);
> >> +  rvin_write(vin, vnmc & ~VNMC_VUP, VNMC_REG);
> >> +
> >> +  ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
> >> +  VNCSI_IFMD_CSI_CHSEL(chsel);
> >> +
> >> +  rvin_write(vin, ifmd, VNCSI_IFMD_REG);
> >> +
> >> +  vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
> >> +
> >> +  /* Restore VNMC */
> >> +  rvin_write(vin, vnmc, VNMC_REG);
> > 
> > No need for locking around all this ? What happens if this VIN instance
> > decides to write to another VIN register (for instance due to a userpace
> > call) when this function has disabled VNMC_VUP ?
> 
> You also asked a related question to this in v9 as a start I will copy
> in that reply.
> 
> Media link changes are not allowed when any VIN in the group are
> streaming so this should not be an issue.
> 
> And to compliment that. This function is only valid for a VIN which has
> the CHSEL register which currently is VIN0 and VIN4. It can only be
> modified when a media link is enabled. Catching media links are only
> allowed when all VIN in the system are _not_ streaming. And VNMC_VUP is
> only enabled when a VIN is streaming so there is no need for locking
> here.

This seems a bit fragile to me, could you please capture the explanation in a 
comment ?

> >> +  pm_runtime_put(vin->dev);
> >> +}
> >> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> >> b/drivers/media/platform/rcar-vin/rcar-vin.h index
> >> 146683142e6533fa..a5dae5b5e9cb704b 100644
> >> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> >> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> >> @@ -165,4 +165,6 @@ const struct rvin_video_format
> >> *rvin_format_from_pixel(u32 pixelformat); /* Cropping, composing and
> >> scaling */
> >> 
> >>  void rvin_crop_scale_comp(struct rvin_dev *vin);
> >> 
> >> +void rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel);
> >> +
> >>  #endif

-- 
Regards,

Laurent Pinchart

Re: [PATCH v10 16/30] rcar-vin: update bytesperline and sizeimage calculation

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:21 EET Niklas Söderlund wrote:
> Remove over complicated logic to calculate the value for bytesperline

s/over complicated/overcomplicated/

> and sizeimage that was carried over from the soc_camera port. Update the
> calculations to match how other drivers are doing it.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> 1169e6a279ecfb55..bca6e204a574772f 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -118,10 +118,8 @@ static int rvin_format_align(struct rvin_dev *vin,
> struct v4l2_pix_format *pix) v4l_bound_align_image(>width, 2,
> vin->info->max_width, walign, >height, 4, vin->info->max_height, 2,
> 0);
> 
> - pix->bytesperline = max_t(u32, pix->bytesperline,
> -   rvin_format_bytesperline(pix));
> - pix->sizeimage = max_t(u32, pix->sizeimage,
> -rvin_format_sizeimage(pix));
> + pix->bytesperline = rvin_format_bytesperline(pix);
> + pix->sizeimage = rvin_format_sizeimage(pix);

Thus this mean that the driver will stop supporting configurable strides ? 
Isn't that a regression ?

>   if (vin->info->model == RCAR_M1 &&
>   pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
> @@ -270,11 +268,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
>   if (pix->field == V4L2_FIELD_ANY)
>   pix->field = vin->format.field;
> 
> -
> - /* Always recalculate */
> - pix->bytesperline = 0;
> - pix->sizeimage = 0;
> -
>   /* Limit to source capabilities */
>   ret = __rvin_try_format_source(vin, which, pix);
>   if (ret)


-- 
Regards,

Laurent Pinchart

Re: [PATCH v10 13/30] rcar-vin: add function to manipulate Gen3 chsel value

[Niklas Söderlund]

Hi Laurent,

On 2018-02-13 18:41:33 +0200, Laurent Pinchart wrote:
> Hi Niklas,
> 
> Thank you for the patch.
> 
> On Monday, 29 January 2018 18:34:18 EET Niklas Söderlund wrote:
> > On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
> > feature of this register is that it's only present in the VIN0 and VIN4
> > instances. The register in VIN0 controls the routing for VIN0-3 and the
> > register in VIN4 controls routing for VIN4-7.
> > 
> > To be able to control routing from a media device this function is need
> > to control runtime PM for the subgroup master (VIN0 and VIN4). The
> > subgroup master must be switched on before the register is manipulated,
> > once the operation is complete it's safe to switch the master off and
> > the new routing will still be in effect.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  drivers/media/platform/rcar-vin/rcar-dma.c | 28 +++
> >  drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
> >  2 files changed, 30 insertions(+)
> > 
> > diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> > b/drivers/media/platform/rcar-vin/rcar-dma.c index
> > 2f9ad1bec1c8a92f..ae286742f15a3ab5 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> > @@ -16,6 +16,7 @@
> > 
> >  #include 
> >  #include 
> > +#include 
> > 
> >  #include 
> > 
> > @@ -1228,3 +1229,30 @@ int rvin_dma_register(struct rvin_dev *vin, int irq)
> > 
> > return ret;
> >  }
> > +
> > +/* 
> > + * Gen3 CHSEL manipulation
> > + */
> > +
> > +void rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel)
> > +{
> > +   u32 ifmd, vnmc;
> > +
> > +   pm_runtime_get_sync(vin->dev);
> 
> No need to check for errors ?

You asked the samething for v9 so I will copy paste the same reply :-)

Sakari asked the same thing in v4 :-)

In short no its not needed please see Geert's response [1]. If I 
recall correctly this was also discussed in more detail in another 
thread for some other driver whit a bit longer answer saying that it
pm_runtime_get_sync() fails you have big problems but I can't find 
that thread now :-(

1. https://www.spinics.net/lists/linux-media/msg115241.html

> 
> > +
> > +   /* Make register writes take effect immediately */
> > +   vnmc = rvin_read(vin, VNMC_REG);
> > +   rvin_write(vin, vnmc & ~VNMC_VUP, VNMC_REG);
> > +
> > +   ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
> > +   VNCSI_IFMD_CSI_CHSEL(chsel);
> > +
> > +   rvin_write(vin, ifmd, VNCSI_IFMD_REG);
> > +
> > +   vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
> > +
> > +   /* Restore VNMC */
> > +   rvin_write(vin, vnmc, VNMC_REG);
> 
> No need for locking around all this ? What happens if this VIN instance 
> decides to write to another VIN register (for instance due to a userpace 
> call) 
> when this function has disabled VNMC_VUP ?

You also asked a related question to this in v9 as a start I will copy 
in that reply.

Media link changes are not allowed when any VIN in the group are
streaming so this should not be an issue.

And to compliment that. This function is only valid for a VIN which has 
the CHSEL register which currently is VIN0 and VIN4. It can only be 
modified when a media link is enabled. Catching media links are only 
allowed when all VIN in the system are _not_ streaming. And VNMC_VUP is 
only enabled when a VIN is streaming so there is no need for locking 
here.

> 
> > +   pm_runtime_put(vin->dev);
> > +}
> > diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> > b/drivers/media/platform/rcar-vin/rcar-vin.h index
> > 146683142e6533fa..a5dae5b5e9cb704b 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> > +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> > @@ -165,4 +165,6 @@ const struct rvin_video_format
> > *rvin_format_from_pixel(u32 pixelformat); /* Cropping, composing and
> > scaling */
> >  void rvin_crop_scale_comp(struct rvin_dev *vin);
> > 
> > +void rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel);
> > +
> >  #endif
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Regards,
Niklas Söderlund

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

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:20 EET Niklas Söderlund wrote:
> Part of the format alignment and checking can be shared with the Gen3
> format handling. Break that part out to a separate function.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 93 +---
>  1 file changed, 50 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> c606942e59b5d934..1169e6a279ecfb55 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -86,6 +86,55 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format
> *pix) return pix->bytesperline * pix->height;
>  }
> 
> +static int rvin_format_align(struct rvin_dev *vin, struct v4l2_pix_format
> *pix)
> +{
> + u32 walign;
> +
> + /* If requested format is not supported fallback to the default */
> + if (!rvin_format_from_pixel(pix->pixelformat)) {
> + vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",
> + pix->pixelformat, RVIN_DEFAULT_FORMAT);

I think you can drop the message.

> + pix->pixelformat = RVIN_DEFAULT_FORMAT;
> + }
> +
> + /* Reject ALTERNATE  until support is added to the driver */
> + switch (pix->field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + break;
> + default:
> + pix->field = V4L2_FIELD_NONE;
> + break;
> + }
> +
> + /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
> + walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
> +
> + /* Limit to VIN capabilities */
> + v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
> +   >height, 4, vin->info->max_height, 2, 0);
> +
> + pix->bytesperline = max_t(u32, pix->bytesperline,
> +   rvin_format_bytesperline(pix));
> + pix->sizeimage = max_t(u32, pix->sizeimage,
> +rvin_format_sizeimage(pix));
> +
> + if (vin->info->model == RCAR_M1 &&
> + pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
> + vin_err(vin, "pixel format XBGR32 not supported on M1\n");
> + return -EINVAL;

This shouldn't print a message nor return an error, but default to a supported 
format. You can move the check to the beginning of the function to do so.

> + }
> +
> + vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
> + pix->width, pix->height, pix->bytesperline, pix->sizeimage);
> +
> + return 0;
> +}
> +
>  /*
> ---
> -- * V4L2
>   */
> @@ -215,19 +264,12 @@ static int __rvin_try_format_source(struct rvin_dev
> *vin, static int __rvin_try_format(struct rvin_dev *vin,
>u32 which, struct v4l2_pix_format *pix)
>  {
> - u32 walign;
>   int ret;
> 
>   /* Keep current field if no specific one is asked for */
>   if (pix->field == V4L2_FIELD_ANY)
>   pix->field = vin->format.field;
> 
> - /* If requested format is not supported fallback to the default */
> - if (!rvin_format_from_pixel(pix->pixelformat)) {
> - vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",
> - pix->pixelformat, RVIN_DEFAULT_FORMAT);
> - pix->pixelformat = RVIN_DEFAULT_FORMAT;
> - }
> 
>   /* Always recalculate */
>   pix->bytesperline = 0;
> @@ -238,42 +280,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
>   if (ret)
>   return ret;
> 
> - /* Reject ALTERNATE  until support is added to the driver */
> - switch (pix->field) {
> - case V4L2_FIELD_TOP:
> - case V4L2_FIELD_BOTTOM:
> - case V4L2_FIELD_NONE:
> - case V4L2_FIELD_INTERLACED_TB:
> - case V4L2_FIELD_INTERLACED_BT:
> - case V4L2_FIELD_INTERLACED:
> - break;
> - default:
> - pix->field = V4L2_FIELD_NONE;
> - break;
> - }
> -
> - /* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
> - walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
> -
> - /* Limit to VIN capabilities */
> - v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
> -   >height, 4, vin->info->max_height, 2, 0);
> -
> - pix->bytesperline = max_t(u32, pix->bytesperline,
> -   rvin_format_bytesperline(pix));
> - pix->sizeimage = max_t(u32, pix->sizeimage,
> -rvin_format_sizeimage(pix));
> -
> - if (vin->info->model == RCAR_M1 &&
> - pix->pixelformat 

Re: [PATCH v10 10/30] rcar-vin: fix handling of single field frames (top, bottom and alternate fields)

[Niklas Söderlund]

Hi Laurent,

On 2018-02-13 18:26:34 +0200, Laurent Pinchart wrote:
> Hi Niklas,
> 
> Thank you for the patch.

Thanks for your comments.

> 
> On Monday, 29 January 2018 18:34:15 EET Niklas Söderlund wrote:
> > There was never proper support in the VIN driver to deliver ALTERNATING
> > field format to user-space, remove this field option. The problem is
> > that ALTERNATING filed order requires the sequence numbers of buffers
> > returned to userspace to reflect if fields where dropped or not,
> > something which is not possible with the VIN drivers capture logic.
> > 
> > The VIN driver can still capture from a video source which delivers
> > frames in ALTERNATING field order, but needs to combine them using the
> > VIN hardware into INTERLACED field order. Before this change if a source
> > was delivering fields using ALTERNATE the driver would default to
> > combining them using this hardware feature. Only if the user explicitly
> > requested ALTERNATE filed order would incorrect frames be delivered.
> > 
> > The height should not be cut in half for the format for TOP or BOTTOM
> > fields settings. This was a mistake and it was made visible by the
> > scaling refactoring. Correct behavior is that the user should request a
> > frame size that fits the half height frame reflected in the field
> > setting. If not the VIN will do its best to scale the top or bottom to
> > the requested format and cropping and scaling do not work as expected.
> > 
> > Signed-off-by: Niklas Söderlund 
> > Reviewed-by: Hans Verkuil 
> > ---
> >  drivers/media/platform/rcar-vin/rcar-dma.c  | 15 +---
> >  drivers/media/platform/rcar-vin/rcar-v4l2.c | 53 --
> >  2 files changed, 24 insertions(+), 44 deletions(-)
> > 
> > diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> > b/drivers/media/platform/rcar-vin/rcar-dma.c index
> > fd14be20a6604d7a..c8831e189d362c8b 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> > @@ -617,7 +617,6 @@ static int rvin_setup(struct rvin_dev *vin)
> > case V4L2_FIELD_INTERLACED_BT:
> > vnmc = VNMC_IM_FULL | VNMC_FOC;
> > break;
> > -   case V4L2_FIELD_ALTERNATE:
> > case V4L2_FIELD_NONE:
> > if (vin->continuous) {
> > vnmc = VNMC_IM_ODD_EVEN;
> > @@ -757,18 +756,6 @@ static int rvin_get_active_slot(struct rvin_dev *vin,
> > u32 vnms) return 0;
> >  }
> > 
> > -static enum v4l2_field rvin_get_active_field(struct rvin_dev *vin, u32
> > vnms)
> > -{
> > -   if (vin->format.field == V4L2_FIELD_ALTERNATE) {
> > -   /* If FS is set it's a Even field */
> > -   if (vnms & VNMS_FS)
> > -   return V4L2_FIELD_BOTTOM;
> > -   return V4L2_FIELD_TOP;
> > -   }
> > -
> > -   return vin->format.field;
> > -}
> > -
> >  static void rvin_set_slot_addr(struct rvin_dev *vin, int slot, dma_addr_t
> > addr) {
> > const struct rvin_video_format *fmt;
> > @@ -941,7 +928,7 @@ static irqreturn_t rvin_irq(int irq, void *data)
> > goto done;
> > 
> > /* Capture frame */
> > -   vin->queue_buf[slot]->field = rvin_get_active_field(vin, vnms);
> > +   vin->queue_buf[slot]->field = vin->format.field;
> > vin->queue_buf[slot]->sequence = sequence;
> > vin->queue_buf[slot]->vb2_buf.timestamp = ktime_get_ns();
> > vb2_buffer_done(>queue_buf[slot]->vb2_buf, VB2_BUF_STATE_DONE);
> > diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> > 4d5be2d0c79c9c9a..9f7902d29c62e205 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> > @@ -103,6 +103,28 @@ static int rvin_get_source_format(struct rvin_dev *vin,
> > if (ret)
> > return ret;
> > 
> > +   switch (fmt.format.field) {
> > +   case V4L2_FIELD_TOP:
> > +   case V4L2_FIELD_BOTTOM:
> > +   case V4L2_FIELD_NONE:
> > +   case V4L2_FIELD_INTERLACED_TB:
> > +   case V4L2_FIELD_INTERLACED_BT:
> > +   case V4L2_FIELD_INTERLACED:
> > +   break;
> > +   case V4L2_FIELD_ALTERNATE:
> > +   /*
> > +* Driver do not (yet) support outputting ALTERNATE to a
> > +* userspace. It dose support outputting INTERLACED so use
> 
> s/dose/does/
> 
> > +* the VIN hardware to combine the two fields.
> > +*/
> > +   fmt.format.field = V4L2_FIELD_INTERLACED;
> > +   fmt.format.height *= 2;
> > +   break;
> 
> I don't like this much. The rvin_get_source_format() function is supposed to 
> return the media bus format for the bus between the source and the VIN. It's 
> the caller that should take the field limitations into account, otherwise you 
> end up with a mix of source and VIN data in the same structure.

When I read your comments I understand your argument better. And I 
understand this function 

[PATCH] device_tree: Increase FDT_MAX_SIZE to 128 KiB

[Geert Uytterhoeven]

It is not uncommon for a contemporary FDT to be larger than 64 KiB,
leading to failures loading the device tree from sysfs:

qemu-system-aarch64: qemu_fdt_setprop: Couldn't set ...: FDT_ERR_NOSPACE

For reference, the largest arm64 DTB created from the Linux sources is
70 KiB large (93 KiB when built with symbols/fixup support).

Signed-off-by: Geert Uytterhoeven 
---
 device_tree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/device_tree.c b/device_tree.c
index a24ddff02bdd857c..1ba9b8e0a49e6bbc 100644
--- a/device_tree.c
+++ b/device_tree.c
@@ -29,7 +29,7 @@
 
 #include 
 
-#define FDT_MAX_SIZE  0x1
+#define FDT_MAX_SIZE  0x2
 
 void *create_device_tree(int *sizep)
 {
-- 
2.7.4

Re: [PATCH v10 13/30] rcar-vin: add function to manipulate Gen3 chsel value

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:18 EET Niklas Söderlund wrote:
> On Gen3 the CSI-2 routing is controlled by the VnCSI_IFMD register. One
> feature of this register is that it's only present in the VIN0 and VIN4
> instances. The register in VIN0 controls the routing for VIN0-3 and the
> register in VIN4 controls routing for VIN4-7.
> 
> To be able to control routing from a media device this function is need
> to control runtime PM for the subgroup master (VIN0 and VIN4). The
> subgroup master must be switched on before the register is manipulated,
> once the operation is complete it's safe to switch the master off and
> the new routing will still be in effect.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 28 +++
>  drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
>  2 files changed, 30 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> 2f9ad1bec1c8a92f..ae286742f15a3ab5 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -16,6 +16,7 @@
> 
>  #include 
>  #include 
> +#include 
> 
>  #include 
> 
> @@ -1228,3 +1229,30 @@ int rvin_dma_register(struct rvin_dev *vin, int irq)
> 
>   return ret;
>  }
> +
> +/* 
> + * Gen3 CHSEL manipulation
> + */
> +
> +void rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel)
> +{
> + u32 ifmd, vnmc;
> +
> + pm_runtime_get_sync(vin->dev);

No need to check for errors ?

> +
> + /* Make register writes take effect immediately */
> + vnmc = rvin_read(vin, VNMC_REG);
> + rvin_write(vin, vnmc & ~VNMC_VUP, VNMC_REG);
> +
> + ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
> + VNCSI_IFMD_CSI_CHSEL(chsel);
> +
> + rvin_write(vin, ifmd, VNCSI_IFMD_REG);
> +
> + vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
> +
> + /* Restore VNMC */
> + rvin_write(vin, vnmc, VNMC_REG);

No need for locking around all this ? What happens if this VIN instance 
decides to write to another VIN register (for instance due to a userpace call) 
when this function has disabled VNMC_VUP ?

> + pm_runtime_put(vin->dev);
> +}
> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h
> b/drivers/media/platform/rcar-vin/rcar-vin.h index
> 146683142e6533fa..a5dae5b5e9cb704b 100644
> --- a/drivers/media/platform/rcar-vin/rcar-vin.h
> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h
> @@ -165,4 +165,6 @@ const struct rvin_video_format
> *rvin_format_from_pixel(u32 pixelformat); /* Cropping, composing and
> scaling */
>  void rvin_crop_scale_comp(struct rvin_dev *vin);
> 
> +void rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel);
> +
>  #endif

-- 
Regards,

Laurent Pinchart

Re: [PATCH v10 11/30] rcar-vin: move media bus configuration to struct rvin_info

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:16 EET Niklas Söderlund wrote:
> Bus configuration will once the driver is extended to support Gen3
> contain information not specific to only the directly connected parallel
> subdevice. Move it to struct rvin_dev to show it's not always coupled
> to the parallel subdevice.

The subject line still mentions rvin_info instead of rvin_dev.

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

[PATCH 1/2] vfio: platform: Fix reset module leak in error path

[Geert Uytterhoeven]

If the IOMMU group setup fails, the reset module is not released.

Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by 
default")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/vfio/platform/vfio_platform_common.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 35469af87f88678e..b60bb5326668498c 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -680,18 +680,23 @@ int vfio_platform_probe_common(struct 
vfio_platform_device *vdev,
group = vfio_iommu_group_get(dev);
if (!group) {
pr_err("VFIO: No IOMMU group for device %s\n", vdev->name);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto put_reset;
}
 
ret = vfio_add_group_dev(dev, _platform_ops, vdev);
-   if (ret) {
-   vfio_iommu_group_put(group, dev);
-   return ret;
-   }
+   if (ret)
+   goto put_iommu;
 
mutex_init(>igate);
 
return 0;
+
+put_iommu:
+   vfio_iommu_group_put(group, dev);
+put_reset:
+   vfio_platform_put_reset(vdev);
+   return ret;
 }
 EXPORT_SYMBOL_GPL(vfio_platform_probe_common);
 
-- 
2.7.4

[PATCH 0/2] vfio: platform: Improve reset support

[Geert Uytterhoeven]

Hi all,

This patch series improves reset support for vfio-platform:
  - The first patch fixes a bug I ran into while working on this.
  - The second patch implements generic DT reset support, for devices
that are connected to an SoC-internal reset controller and can be
reset in a generic way.  This avoids having to write/change a
vfio-specific reset driver for each and every device to be
passed-through to a guest.

This has been tested using the R-Car Gen3 GPIO Pass-Through Prototype
posted last week: the GPIO module is reset before QEMU opens the vfio
device, and reset again after QEMU has released it, as can be witnessed
by the LEDs on the Salvator-XS board.

Thanks for your comments!

Geert Uytterhoeven (2):
  vfio: platform: Fix reset module leak in error path
  vfio: platform: Add generic DT reset support

 drivers/vfio/platform/vfio_platform_common.c  | 38 ++-
 drivers/vfio/platform/vfio_platform_private.h |  1 +
 2 files changed, 32 insertions(+), 7 deletions(-)

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

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

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

[PATCH 2/2] vfio: platform: Add generic DT reset support

[Geert Uytterhoeven]

Vfio-platform requires reset support, provided either by ACPI, or, on DT
platforms, by a device-specific reset driver matching against the
device's compatible value.

On many SoCs, devices are connected to an SoC-internal reset controller,
and can be reset in a generic way.  Hence add support to reset such
devices using the reset controller subsystem, provided the reset
hierarchy is described correctly in DT using the "resets" property.

Devices that require a more complex reset procedure can still
provide a device-specific reset driver, as that takes precedence.

Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
becomes a no-op if reset controller support is disabled.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/vfio/platform/vfio_platform_common.c  | 23 +--
 drivers/vfio/platform/vfio_platform_private.h |  1 +
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index b60bb5326668498c..5d1e48f96e423508 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -112,7 +113,13 @@ static bool vfio_platform_has_reset(struct 
vfio_platform_device *vdev)
if (VFIO_PLATFORM_IS_ACPI(vdev))
return vfio_platform_acpi_has_reset(vdev);
 
-   return vdev->of_reset ? true : false;
+   if (vdev->of_reset)
+   return true;
+
+   if (!IS_ERR_OR_NULL(vdev->reset_control))
+   return true;
+
+   return false;
 }
 
 static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
@@ -127,8 +134,15 @@ static int vfio_platform_get_reset(struct 
vfio_platform_device *vdev)
vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>reset_module);
}
+   if (vdev->of_reset)
+   return 0;
+
+   vdev->reset_control = __of_reset_control_get(vdev->device->of_node,
+NULL, 0, false, false);
+   if (!IS_ERR(vdev->reset_control))
+   return 0;
 
-   return vdev->of_reset ? 0 : -ENOENT;
+   return PTR_ERR(vdev->reset_control);
 }
 
 static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
@@ -138,6 +152,8 @@ static void vfio_platform_put_reset(struct 
vfio_platform_device *vdev)
 
if (vdev->of_reset)
module_put(vdev->reset_module);
+
+   reset_control_put(vdev->reset_control);
 }
 
 static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
@@ -217,6 +233,9 @@ static int vfio_platform_call_reset(struct 
vfio_platform_device *vdev,
} else if (vdev->of_reset) {
dev_info(vdev->device, "reset\n");
return vdev->of_reset(vdev);
+   } else if (!IS_ERR_OR_NULL(vdev->reset_control)) {
+   dev_info(vdev->device, "reset\n");
+   return reset_control_reset(vdev->reset_control);
}
 
dev_warn(vdev->device, "no reset function found!\n");
diff --git a/drivers/vfio/platform/vfio_platform_private.h 
b/drivers/vfio/platform/vfio_platform_private.h
index 85ffe5d9d1abd94e..a56e80ae5986540b 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -60,6 +60,7 @@ struct vfio_platform_device {
const char  *compat;
const char  *acpihid;
struct module   *reset_module;
+   struct reset_control*reset_control;
struct device   *device;
 
/*
-- 
2.7.4

Re: [PATCH v10 10/30] rcar-vin: fix handling of single field frames (top, bottom and alternate fields)

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:15 EET Niklas Söderlund wrote:
> There was never proper support in the VIN driver to deliver ALTERNATING
> field format to user-space, remove this field option. The problem is
> that ALTERNATING filed order requires the sequence numbers of buffers
> returned to userspace to reflect if fields where dropped or not,
> something which is not possible with the VIN drivers capture logic.
> 
> The VIN driver can still capture from a video source which delivers
> frames in ALTERNATING field order, but needs to combine them using the
> VIN hardware into INTERLACED field order. Before this change if a source
> was delivering fields using ALTERNATE the driver would default to
> combining them using this hardware feature. Only if the user explicitly
> requested ALTERNATE filed order would incorrect frames be delivered.
> 
> The height should not be cut in half for the format for TOP or BOTTOM
> fields settings. This was a mistake and it was made visible by the
> scaling refactoring. Correct behavior is that the user should request a
> frame size that fits the half height frame reflected in the field
> setting. If not the VIN will do its best to scale the top or bottom to
> the requested format and cropping and scaling do not work as expected.
> 
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Hans Verkuil 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c  | 15 +---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 53 --
>  2 files changed, 24 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
> b/drivers/media/platform/rcar-vin/rcar-dma.c index
> fd14be20a6604d7a..c8831e189d362c8b 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -617,7 +617,6 @@ static int rvin_setup(struct rvin_dev *vin)
>   case V4L2_FIELD_INTERLACED_BT:
>   vnmc = VNMC_IM_FULL | VNMC_FOC;
>   break;
> - case V4L2_FIELD_ALTERNATE:
>   case V4L2_FIELD_NONE:
>   if (vin->continuous) {
>   vnmc = VNMC_IM_ODD_EVEN;
> @@ -757,18 +756,6 @@ static int rvin_get_active_slot(struct rvin_dev *vin,
> u32 vnms) return 0;
>  }
> 
> -static enum v4l2_field rvin_get_active_field(struct rvin_dev *vin, u32
> vnms)
> -{
> - if (vin->format.field == V4L2_FIELD_ALTERNATE) {
> - /* If FS is set it's a Even field */
> - if (vnms & VNMS_FS)
> - return V4L2_FIELD_BOTTOM;
> - return V4L2_FIELD_TOP;
> - }
> -
> - return vin->format.field;
> -}
> -
>  static void rvin_set_slot_addr(struct rvin_dev *vin, int slot, dma_addr_t
> addr) {
>   const struct rvin_video_format *fmt;
> @@ -941,7 +928,7 @@ static irqreturn_t rvin_irq(int irq, void *data)
>   goto done;
> 
>   /* Capture frame */
> - vin->queue_buf[slot]->field = rvin_get_active_field(vin, vnms);
> + vin->queue_buf[slot]->field = vin->format.field;
>   vin->queue_buf[slot]->sequence = sequence;
>   vin->queue_buf[slot]->vb2_buf.timestamp = ktime_get_ns();
>   vb2_buffer_done(>queue_buf[slot]->vb2_buf, VB2_BUF_STATE_DONE);
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> 4d5be2d0c79c9c9a..9f7902d29c62e205 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -103,6 +103,28 @@ static int rvin_get_source_format(struct rvin_dev *vin,
> if (ret)
>   return ret;
> 
> + switch (fmt.format.field) {
> + case V4L2_FIELD_TOP:
> + case V4L2_FIELD_BOTTOM:
> + case V4L2_FIELD_NONE:
> + case V4L2_FIELD_INTERLACED_TB:
> + case V4L2_FIELD_INTERLACED_BT:
> + case V4L2_FIELD_INTERLACED:
> + break;
> + case V4L2_FIELD_ALTERNATE:
> + /*
> +  * Driver do not (yet) support outputting ALTERNATE to a
> +  * userspace. It dose support outputting INTERLACED so use

s/dose/does/

> +  * the VIN hardware to combine the two fields.
> +  */
> + fmt.format.field = V4L2_FIELD_INTERLACED;
> + fmt.format.height *= 2;
> + break;

I don't like this much. The rvin_get_source_format() function is supposed to 
return the media bus format for the bus between the source and the VIN. It's 
the caller that should take the field limitations into account, otherwise you 
end up with a mix of source and VIN data in the same structure.

> + default:
> + vin->format.field = V4L2_FIELD_NONE;
> + break;
> + }
> +
>   memcpy(mbus_fmt, , sizeof(*mbus_fmt));
> 
>   return 0;
> @@ -139,33 +161,6 @@ static int rvin_reset_format(struct rvin_dev *vin)
> 
>   v4l2_fill_pix_format(>format, _fmt);
> 
> - /*
> -  * If 

Re: [PATCH v10 09/30] rcar-vin: read subdevice format for crop only when needed

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:14 EET Niklas Söderlund wrote:
> Instead of caching the subdevice format each time the video device
> format is set read it directly when it's needed. As it turns out the
> format is only needed when figuring out the max rectangle for cropping.
> 
> This simplifies the code and makes it clearer what the source format is
> used for.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 112 +---
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  12 ---
>  2 files changed, 61 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> b/drivers/media/platform/rcar-vin/rcar-v4l2.c index
> c2265324c7c96308..4d5be2d0c79c9c9a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -90,35 +90,54 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format
> *pix) * V4L2
>   */
> 
> -static void rvin_reset_crop_compose(struct rvin_dev *vin)
> +static int rvin_get_source_format(struct rvin_dev *vin,
> +   struct v4l2_mbus_framefmt *mbus_fmt)
>  {
> + struct v4l2_subdev_format fmt = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + .pad = vin->digital->source_pad,
> + };
> + int ret;
> +
> + ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
> + if (ret)
> + return ret;
> +
> + memcpy(mbus_fmt, , sizeof(*mbus_fmt));

You can use

*mbus_fmt = fmt.format;

That way the compiler will catch more mistakes, for instance incompatible 
types between the two arguments.

> +
> + return 0;
> +}
> +
> +static int rvin_reset_crop_compose(struct rvin_dev *vin)
> +{
> + struct v4l2_mbus_framefmt source_fmt;
> + int ret;
> +
> + ret = rvin_get_source_format(vin, _fmt);
> + if (ret)
> + return ret;
> +
>   vin->crop.top = vin->crop.left = 0;
> - vin->crop.width = vin->source.width;
> - vin->crop.height = vin->source.height;
> + vin->crop.width = source_fmt.width;
> + vin->crop.height = source_fmt.height;
> 
>   vin->compose.top = vin->compose.left = 0;
>   vin->compose.width = vin->format.width;
>   vin->compose.height = vin->format.height;
> +
> + return 0;
>  }
> 
>  static int rvin_reset_format(struct rvin_dev *vin)
>  {
> - struct v4l2_subdev_format fmt = {
> - .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> - };
> - struct v4l2_mbus_framefmt *mf = 
> + struct v4l2_mbus_framefmt source_fmt;
>   int ret;
> 
> - fmt.pad = vin->digital->source_pad;
> -
> - ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
> + ret = rvin_get_source_format(vin, _fmt);
>   if (ret)
>   return ret;

You retrieve the source format once here...

> - vin->format.width   = mf->width;
> - vin->format.height  = mf->height;
> - vin->format.colorspace  = mf->colorspace;
> - vin->format.field   = mf->field;
> + v4l2_fill_pix_format(>format, _fmt);
> 
>   /*
>* If the subdevice uses ALTERNATE field mode and G_STD is
> @@ -147,7 +166,9 @@ static int rvin_reset_format(struct rvin_dev *vin)
>   break;
>   }
> 
> - rvin_reset_crop_compose(vin);
> + ret = rvin_reset_crop_compose(vin);

... and this function then retrieves it a second time. Can't you pass it to 
rvin_reset_crop_compose() ? If the source changes its format autonomously 
between the two calls you'll end up with an inconsistent result otherwise.

> + if (ret)
> + return ret;
> 
>   vin->format.bytesperline = rvin_format_bytesperline(>format);
>   vin->format.sizeimage = rvin_format_sizeimage(>format);
> @@ -156,9 +177,7 @@ static int rvin_reset_format(struct rvin_dev *vin)
>  }
> 
>  static int __rvin_try_format_source(struct rvin_dev *vin,
> - u32 which,
> - struct v4l2_pix_format *pix,
> - struct rvin_source_fmt *source)
> + u32 which, struct v4l2_pix_format *pix)
>  {
>   struct v4l2_subdev *sd;
>   struct v4l2_subdev_pad_config *pad_cfg;
> @@ -190,25 +209,16 @@ static int __rvin_try_format_source(struct rvin_dev
> *vin,
> 
>   v4l2_fill_pix_format(pix, );
> 
> - source->width = pix->width;
> - source->height = pix->height;
> -
>   pix->field = field;
>   pix->width = width;
>   pix->height = height;
> -
> - vin_dbg(vin, "Source resolution: %ux%u\n", source->width,
> - source->height);
> -
>  done:
>   v4l2_subdev_free_pad_config(pad_cfg);
>   return ret;
>  }
> 
>  static int __rvin_try_format(struct rvin_dev *vin,
> -  u32 which,
> -  struct v4l2_pix_format *pix,
> -

Re: [PATCH v10 04/30] rcar-vin: move subdevice handling to async callbacks

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:09 EET Niklas Söderlund wrote:
> In preparation for Gen3 support move the subdevice initialization and
> clean up from rvin_v4l2_{register,unregister}() directly to the async
> callbacks. This simplifies the addition of Gen3 support as the
> rvin_v4l2_register() can be shared for both Gen2 and Gen3 while direct
> subdevice control are only used on Gen2.
> 
> While moving this code drop a large comment which is copied from the
> framework documentation and fold rvin_mbus_supported() into its only
> caller. Also move the initialization and cleanup code to separate
> functions to increase readability.
> 
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 108 ++--
>  drivers/media/platform/rcar-vin/rcar-v4l2.c |  35 -
>  2 files changed, 74 insertions(+), 69 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> b/drivers/media/platform/rcar-vin/rcar-core.c index
> 47f06acde2e698f2..663309ca9c04f208 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -46,46 +46,88 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int
> direction) return -EINVAL;
>  }
> 
> -static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
> +/* The vin lock shuld be held when calling the subdevice attach and detach
> */ +static int rvin_digital_subdevice_attach(struct rvin_dev *vin,
> +  struct v4l2_subdev *subdev)
>  {
> - struct v4l2_subdev *sd = entity->subdev;
>   struct v4l2_subdev_mbus_code_enum code = {
>   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
>   };
> + int ret;
> 
> + /* Find source and sink pad of remote subdevice */
> + ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
> + if (ret < 0)
> + return ret;
> + vin->digital->source_pad = ret;
> +
> + ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
> + vin->digital->sink_pad = ret < 0 ? 0 : ret;
> +
> + /* Find compatible subdevices mbus format */
> + vin->digital->code = 0;
>   code.index = 0;
> - code.pad = entity->source_pad;
> - while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, )) {
> + code.pad = vin->digital->source_pad;
> + while (!vin->digital->code &&
> +!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
>   code.index++;
>   switch (code.code) {
>   case MEDIA_BUS_FMT_YUYV8_1X16:
>   case MEDIA_BUS_FMT_UYVY8_2X8:
>   case MEDIA_BUS_FMT_UYVY10_2X10:
>   case MEDIA_BUS_FMT_RGB888_1X24:
> - entity->code = code.code;
> - return true;
> + vin->digital->code = code.code;
> + vin_dbg(vin, "Found media bus format for %s: %d\n",
> + subdev->name, vin->digital->code);
> + break;
>   default:
>   break;
>   }
>   }
> 
> - return false;
> -}
> -
> -static int rvin_digital_notify_complete(struct v4l2_async_notifier
> *notifier) -{
> - struct rvin_dev *vin = notifier_to_vin(notifier);
> - int ret;
> -
> - /* Verify subdevices mbus format */
> - if (!rvin_mbus_supported(vin->digital)) {
> + if (!vin->digital->code) {
>   vin_err(vin, "Unsupported media bus format for %s\n",
> - vin->digital->subdev->name);
> + subdev->name);
>   return -EINVAL;
>   }
> 
> - vin_dbg(vin, "Found media bus format for %s: %d\n",
> - vin->digital->subdev->name, vin->digital->code);
> + /* Read tvnorms */
> + ret = v4l2_subdev_call(subdev, video, g_tvnorms, >vdev.tvnorms);
> + if (ret < 0 && ret != -ENOIOCTLCMD && ret != -ENODEV)
> + return ret;
> +
> + /* Add the controls */
> + ret = v4l2_ctrl_handler_init(>ctrl_handler, 16);
> + if (ret < 0)
> + return ret;
> +
> + ret = v4l2_ctrl_add_handler(>ctrl_handler, subdev->ctrl_handler,
> + NULL);
> + if (ret < 0) {
> + v4l2_ctrl_handler_free(>ctrl_handler);
> + return ret;
> + }
> +
> + vin->vdev.ctrl_handler = >ctrl_handler;
> +
> + vin->digital->subdev = subdev;
> +
> + return 0;
> +}
> +
> +static void rvin_digital_subdevice_detach(struct rvin_dev *vin)
> +{
> + rvin_v4l2_unregister(vin);
> + v4l2_ctrl_handler_free(>ctrl_handler);
> +
> + vin->vdev.ctrl_handler = NULL;
> + vin->digital->subdev = NULL;
> +}
> +
> +static int rvin_digital_notify_complete(struct v4l2_async_notifier
> *notifier) +{
> + struct rvin_dev *vin = notifier_to_vin(notifier);
> + int ret;
> 
>   ret = 

Re: [PATCH v10 01/30] rcar-vin: add Gen3 devicetree bindings documentation

[Laurent Pinchart]

Hi Niklas,

Thank you for the patch.

On Monday, 29 January 2018 18:34:06 EET Niklas Söderlund wrote:
> Document the devicetree bindings for the CSI-2 inputs available on Gen3.
> 
> There is a need to add a custom property 'renesas,id' and to define
> which CSI-2 input is described in which endpoint under the port@1 node.
> This information is needed since there are a set of predefined routes
> between each VIN and CSI-2 block. This routing table will be kept
> inside the driver but in order for it to act on it it must know which
> VIN and CSI-2 is which.
> 
> Signed-off-by: Niklas Söderlund 
> Acked-by: Rob Herring 

Reviewed-by: Laurent Pinchart 

> ---
>  .../devicetree/bindings/media/rcar_vin.txt | 118 +++---
>  1 file changed, 106 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
> b/Documentation/devicetree/bindings/media/rcar_vin.txt index
> c60e6b0a89b67a8c..90d92836284b7f68 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
>  ---
> 
>  The rcar_vin device provides video input capabilities for the Renesas R-Car
> -family of devices. The current blocks are always slaves and suppot one
> input -channel which can be either RGB, YUYV or BT656.
> +family of devices.
> +
> +Each VIN instance has a single parallel input that supports RGB and YUV
> video, +with both external synchronization and BT.656 synchronization for
> the latter. +Depending on the instance the VIN input is connected to
> external SoC pins, or +on Gen3 platforms to a CSI-2 receiver.
> 
>   - compatible: Must be one or more of the following
> - "renesas,vin-r8a7743" for the R8A7743 device
> @@ -16,6 +20,8 @@ channel which can be either RGB, YUYV or BT656.
> - "renesas,vin-r8a7793" for the R8A7793 device
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> +   - "renesas,vin-r8a7796" for the R8A7796 device
> +   - "renesas,vin-r8a77970" for the R8A77970 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
>   device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
> @@ -31,21 +37,38 @@ channel which can be either RGB, YUYV or BT656.
>  Additionally, an alias named vinX will need to be created to specify
>  which video input device this is.
> 
> -The per-board settings:
> +The per-board settings Gen2 platforms:
>   - port sub-node describing a single endpoint connected to the vin
> as described in video-interfaces.txt[1]. Only the first one will
> be considered as each vin interface has one input port.
> 
> -   These settings are used to work out video input format and widths
> -   into the system.
> +The per-board settings Gen3 platforms:
> 
> +Gen3 platforms can support both a single connected parallel input source
> +from external SoC pins (port0) and/or multiple parallel input sources
> +from local SoC CSI-2 receivers (port1) depending on SoC.
> 
> -Device node example
> 
> +- renesas,id - ID number of the VIN, VINx in the documentation.
> +- ports
> +- port 0 - sub-node describing a single endpoint connected to the VIN
> +  from external SoC pins described in video-interfaces.txt[1].
> +  Describing more then one endpoint in port 0 is invalid. Only VIN
> +  instances that are connected to external pins should have port 0.
> +- port 1 - sub-nodes describing one or more endpoints connected to
> +  the VIN from local SoC CSI-2 receivers. The endpoint numbers must
> +  use the following schema.
> 
> - aliases {
> -vin0 = 
> - };
> +- Endpoint 0 - sub-node describing the endpoint connected to CSI20
> +- Endpoint 1 - sub-node describing the endpoint connected to CSI21
> +- Endpoint 2 - sub-node describing the endpoint connected to CSI40
> +- Endpoint 3 - sub-node describing the endpoint connected to CSI41
> +
> +Device node example for Gen2 platforms
> +--
> +
> +aliases {
> +vin0 = 
> +};
> 
>  vin0: vin@e6ef {
>  compatible = "renesas,vin-r8a7790",
> "renesas,rcar-gen2-vin"; @@ -55,8 +78,8 @@ Device node example
>  status = "disabled";
>  };
> 
> -Board setup example (vin1 composite video input)
> -
> +Board setup example for Gen2 platforms (vin1 composite video input)
> +---
> 
> {
>  status = "ok";
> @@ -95,6 +118,77 @@ Board setup example (vin1 composite video input)
>  };
>  };
> 
> +Device node example for Gen3 

Re: [PATCH] ata: sata_rcar: Remove unused variable in sata_rcar_init_controller()

[Tejun Heo]

On Tue, Feb 13, 2018 at 01:43:23PM +0100, Geert Uytterhoeven wrote:
> drivers/ata/sata_rcar.c: In function 'sata_rcar_init_controller':
> drivers/ata/sata_rcar.c:821:8: warning: unused variable 'base' 
> [-Wunused-variable]
> 
> Fixes: da77d76b95a0e894 ("sata_rcar: Reset SATA PHY when Salvator-X board 
> resumes")
> Signed-off-by: Geert Uytterhoeven 

Applied to libata/for-4.16-fixes.

Thanks.

-- 
tejun

Re: [PATCH] ARM: dts: lager: Move cec_clock to root node

[Niklas Söderlund]

Hi Geert,

Thanks for your patch.

On 2018-02-13 14:40:45 +0100, Geert Uytterhoeven wrote:
> cec-clock is a fixed clock generator that is not controlled by i2c-12
> and thus should not be a child of the i2c-12 bus node. Rather, it should
> be a child of the root node of the DT.
> 
> Fixes: c5aa87977626e778 ("ARM: dts: lager: Add CEC clock for HDMI 
> transmitter")
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Niklas Söderlund 

> ---
>  arch/arm/boot/dts/r8a7790-lager.dts | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
> b/arch/arm/boot/dts/r8a7790-lager.dts
> index b42579ea7a50d47c..3c66366f7c550034 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -247,6 +247,12 @@
>   };
>   };
>  
> + cec_clock: cec-clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <1200>;
> + };
> +
>   hdmi-out {
>   compatible = "hdmi-connector";
>   type = "a";
> @@ -352,12 +358,6 @@
>   };
>   };
>  
> - cec_clock: cec-clock {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <1200>;
> - };
> -
>   hdmi@39 {
>   compatible = "adi,adv7511w";
>   reg = <0x39>;
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH] ARM: dts: lager: Move cec_clock to root node

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Tuesday, 13 February 2018 15:40:45 EET Geert Uytterhoeven wrote:
> cec-clock is a fixed clock generator that is not controlled by i2c-12
> and thus should not be a child of the i2c-12 bus node. Rather, it should
> be a child of the root node of the DT.
> 
> Fixes: c5aa87977626e778 ("ARM: dts: lager: Add CEC clock for HDMI
> transmitter")
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/arm/boot/dts/r8a7790-lager.dts | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
> b/arch/arm/boot/dts/r8a7790-lager.dts index
> b42579ea7a50d47c..3c66366f7c550034 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -247,6 +247,12 @@
>   };
>   };
> 
> + cec_clock: cec-clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <1200>;
> + };
> +
>   hdmi-out {
>   compatible = "hdmi-connector";
>   type = "a";
> @@ -352,12 +358,6 @@
>   };
>   };
> 
> - cec_clock: cec-clock {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <1200>;
> - };
> -
>   hdmi@39 {
>   compatible = "adi,adv7511w";
>   reg = <0x39>;

-- 
Regards,

Laurent Pinchart

[PATCH] ARM: dts: lager: Move cec_clock to root node

[Geert Uytterhoeven]

cec-clock is a fixed clock generator that is not controlled by i2c-12
and thus should not be a child of the i2c-12 bus node. Rather, it should
be a child of the root node of the DT.

Fixes: c5aa87977626e778 ("ARM: dts: lager: Add CEC clock for HDMI transmitter")
Signed-off-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index b42579ea7a50d47c..3c66366f7c550034 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -247,6 +247,12 @@
};
};
 
+   cec_clock: cec-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1200>;
+   };
+
hdmi-out {
compatible = "hdmi-connector";
type = "a";
@@ -352,12 +358,6 @@
};
};
 
-   cec_clock: cec-clock {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <1200>;
-   };
-
hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
-- 
2.7.4

renesas-drivers-2018-02-13-v4.16-rc1

[Geert Uytterhoeven]

I have pushed renesas-drivers-2018-02-13-v4.16-rc1 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

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

Today's version is based on renesas-devel-20180212-v4.16-rc1.

Included branches with driver code:
  - clk-renesas
  - sh-pfc
  - topic/rcar-genpd-wakeup-v4
  - topic/r8a77970-eagle-pfc-v1
  - topic/r8a77970-eagle-gpio-v1
  - topic/r8a77970-eagle-i2c-v1
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/cpufreq-automatic
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/rcar-gen3-cpufreq-little-dts
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/ipmmu-driver-v6
  - git://linuxtv.org/pinchartl/media.git#drm-du-iommu-v1-20171115
  - git://linuxtv.org/pinchartl/media.git#tags/vsp1-discom-v1-20171215
  - git://linuxtv.org/pinchartl/media.git#tags/drm-next-colorkey-v1-20171215
  - git://git.ragnatech.se/linux#for-renesas-drivers
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#vsp1/vga-performance-fix

Included fixes:
  - regulator: Fix resume from suspend to idle
  - [LOCAL] arm64: defconfig: Update renesas_defconfig

Included subsystem trees:
  - git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
  - git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
  - git://people.freedesktop.org/~airlied/linux#drm-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
  - git://linuxtv.org/mchehab/media-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
  - git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
  - git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
  - git://git.infradead.org/users/vkoul/slave-dma.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
  - git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
  - git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
  - git://github.com/bzolnier/linux.git#fbdev-for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
  - git://www.linux-watchdog.org/linux-watchdog-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
  - git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git#for-next

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v3 1/5] dt-bindings: media: adv7604: Add support for i2c_new_secondary_device

[Laurent Pinchart]

Hi Kieran,

On Tuesday, 13 February 2018 15:14:43 EET Kieran Bingham wrote:
> On 13/02/18 12:06, Laurent Pinchart wrote:
> > On Tuesday, 13 February 2018 00:07:49 EET Kieran Bingham wrote:
> >> From: Jean-Michel Hautbois 
> >> 
> >> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
> >> I²C ports. Each map has it own I²C address and acts as a standard slave
> >> device on the I²C bus.
> >> 
> >> Extend the device tree node bindings to be able to override the default
> >> addresses so that address conflicts with other devices on the same bus
> >> may be resolved at the board description level.
> >> 
> >> Signed-off-by: Jean-Michel Hautbois 
> >> [Kieran: Re-adapted for mainline]
> >> Signed-off-by: Kieran Bingham 
> >> Reviewed-by: Rob Herring 
> > 
> > Nitpicking, I might not mention i2c_new_secondary_device in the subject,
> > as this is a DT bindings change. I don't mind too much though, as long as
> > the bindings themselves don't contain Linux-specific information, and they
> > don't, so
> 
> How about: ... adv7604: Extend bindings to allow specifying slave map
> addresses

Sounds good to me.

> > Reviewed-by: Laurent Pinchart 
> 
> Collected, thanks.
> 
> --
> Kieran
> 
> >> ---
> >> 
> >> Based upon the original posting :
> >>   https://lkml.org/lkml/2014/10/22/469
> >> 
> >> v2:
> >>  - DT Binding update separated from code change
> >>  - Minor reword to commit message to account for DT only change.
> >>  - Collected Rob's RB tag.
> >> 
> >> v3:
> >>  - Split map register addresses into individual declarations.
> >>  
> >>  .../devicetree/bindings/media/i2c/adv7604.txt  | 18
> >> 
> >> -- 1 file changed, 16 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> >> b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
> >> 9cbd92eb5d05..ebb5f070c05b 100644
> >> --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> >> +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> >> 
> >> @@ -13,7 +13,11 @@ Required Properties:
> >>  - "adi,adv7611" for the ADV7611
> >>  - "adi,adv7612" for the ADV7612
> >> 
> >> -  - reg: I2C slave address
> >> +  - reg: I2C slave addresses
> >> +The ADV76xx has up to thirteen 256-byte maps that can be accessed
> >> via
> >> the +main I²C ports. Each map has it own I²C address and acts as a
> >> standard +slave device on the I²C bus. The main address is mandatory,
> >> others are +optional and revert to defaults if not specified.
> >> 
> >>- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
> >>
> >>  detection pins, one per HDMI input. The active flag indicates the
> >>  GPIO
> >> 
> >> @@ -35,6 +39,11 @@ Optional Properties:
> >>- reset-gpios: Reference to the GPIO connected to the device's reset
> >>pin.
> >> 
> >> - default-input: Select which input is selected after reset.
> >> +  - reg-names : Names of maps with programmable addresses.
> >> +  It can contain any map needing a non-default address.
> >> +  Possible maps names are :
> >> +"main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
> >> +"rep", "edid", "hdmi", "test", "cp", "vdp"
> >> 
> >>  Optional Endpoint Properties:
> >> @@ -52,7 +61,12 @@ Example:
> >>hdmi_receiver@4c {
> >>
> >>compatible = "adi,adv7611";
> >> 
> >> -  reg = <0x4c>;
> >> +  /*
> >> +   * The edid page will be accessible @ 0x66 on the i2c bus. All
> >> +   * other maps will retain their default addresses.
> >> +   */
> >> +  reg = <0x4c>, <0x66>;
> >> +  reg-names "main", "edid";
> >> 
> >>reset-gpios = < 0 GPIO_ACTIVE_LOW>;
> >>hpd-gpios = < 2 GPIO_ACTIVE_HIGH>;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 1/5] dt-bindings: media: adv7604: Add support for i2c_new_secondary_device

[Kieran Bingham]

Hi Laurent,

On 13/02/18 12:06, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.

Thank you for your review,

> On Tuesday, 13 February 2018 00:07:49 EET Kieran Bingham wrote:
>> From: Jean-Michel Hautbois 
>>
>> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
>> I²C ports. Each map has it own I²C address and acts as a standard slave
>> device on the I²C bus.
>>
>> Extend the device tree node bindings to be able to override the default
>> addresses so that address conflicts with other devices on the same bus
>> may be resolved at the board description level.
>>
>> Signed-off-by: Jean-Michel Hautbois 
>> [Kieran: Re-adapted for mainline]
>> Signed-off-by: Kieran Bingham 
>> Reviewed-by: Rob Herring 
> 
> Nitpicking, I might not mention i2c_new_secondary_device in the subject, as 
> this is a DT bindings change. I don't mind too much though, as long as the 
> bindings themselves don't contain Linux-specific information, and they don't, 
> so
How about: ... adv7604: Extend bindings to allow specifying slave map addresses



> Reviewed-by: Laurent Pinchart 

Collected, thanks.

--
Kieran


> 
>> ---
>> Based upon the original posting :
>>   https://lkml.org/lkml/2014/10/22/469
>>
>> v2:
>>  - DT Binding update separated from code change
>>  - Minor reword to commit message to account for DT only change.
>>  - Collected Rob's RB tag.
>>
>> v3:
>>  - Split map register addresses into individual declarations.
>>
>>  .../devicetree/bindings/media/i2c/adv7604.txt  | 18
>> -- 1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
>> 9cbd92eb5d05..ebb5f070c05b 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> @@ -13,7 +13,11 @@ Required Properties:
>>  - "adi,adv7611" for the ADV7611
>>  - "adi,adv7612" for the ADV7612
>>
>> -  - reg: I2C slave address
>> +  - reg: I2C slave addresses
>> +The ADV76xx has up to thirteen 256-byte maps that can be accessed via
>> the +main I²C ports. Each map has it own I²C address and acts as a
>> standard +slave device on the I²C bus. The main address is mandatory,
>> others are +optional and revert to defaults if not specified.
>>
>>- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
>>  detection pins, one per HDMI input. The active flag indicates the GPIO
>> @@ -35,6 +39,11 @@ Optional Properties:
>>
>>- reset-gpios: Reference to the GPIO connected to the device's reset pin.
>> - default-input: Select which input is selected after reset.
>> +  - reg-names : Names of maps with programmable addresses.
>> +It can contain any map needing a non-default address.
>> +Possible maps names are :
>> +  "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
>> +  "rep", "edid", "hdmi", "test", "cp", "vdp"
>>
>>  Optional Endpoint Properties:
>>
>> @@ -52,7 +61,12 @@ Example:
>>
>>  hdmi_receiver@4c {
>>  compatible = "adi,adv7611";
>> -reg = <0x4c>;
>> +/*
>> + * The edid page will be accessible @ 0x66 on the i2c bus. All
>> + * other maps will retain their default addresses.
>> + */
>> +reg = <0x4c>, <0x66>;
>> +reg-names "main", "edid";
>>
>>  reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>>  hpd-gpios = < 2 GPIO_ACTIVE_HIGH>;
> 
> 

Re: [PATCH] ravb: add support for changing MTU

[Niklas Söderlund]

Hi Sergei,

Thanks for your feedback.

On 2018-02-13 13:01:04 +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 02/12/2018 11:00 PM, Niklas Söderlund wrote:
> 
> > Allow for chancing the MTU within the limit of the maximum size of a
> 
>Changing. :-)

Yes :-)

> 
> > descriptor (2048 bytes). Add the callback to change MTU from user-space
> > and take the configurable MTU into account when configuring the
> > hardware.
> > 
> > Signed-off-by: Niklas Söderlund 
> [...]
> > diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
> > b/drivers/net/ethernet/renesas/ravb_main.c
> > index c87f57ca44371586..a4870c9e42195802 100644
> > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > @@ -300,9 +300,9 @@ static void ravb_ring_format(struct net_device *ndev, 
> > int q)
> > for (i = 0; i < priv->num_rx_ring[q]; i++) {
> > /* RX descriptor */
> > rx_desc = >rx_ring[q][i];
> > -   rx_desc->ds_cc = cpu_to_le16(PKT_BUF_SZ);
> > +   rx_desc->ds_cc = cpu_to_le16(priv->rx_buf_sz);
> > dma_addr = dma_map_single(ndev->dev.parent, 
> > priv->rx_skb[q][i]->data,
> > - PKT_BUF_SZ,
> > + le16_to_cpu(rx_desc->ds_cc),
> 
>   Why not 'priv->rx_buf_sz'?

To align the arguments used with the one in ravb_rx() which uses 
le16_to_cpu(rx_desc->ds_cc) already before this patch.

static bool ravb_rx(struct net_device *ndev, int *quota, int q)
{
...
/* Refill the RX ring buffers. */
for (; priv->cur_rx[q] - priv->dirty_rx[q] > 0; 
priv->dirty_rx[q]++) {
...
desc->ds_cc = cpu_to_le16(priv->rx_buf_sz);

if (!priv->rx_skb[q][entry]) {
...
dma_addr = dma_map_single(ndev->dev.parent, 
skb->data,
  le16_to_cpu(desc->ds_cc),
  DMA_FROM_DEVICE);
...
}
...
}
...
}

I have no preference one way or the other but I think both call sites 
should look the same :-)

> 
> [...]
> > @@ -346,6 +346,10 @@ static int ravb_ring_init(struct net_device *ndev, int 
> > q)
> > int ring_size;
> > int i;
> >  
> > +   /* +16 gets room from the status from the card. */
> > +   priv->rx_buf_sz = (ndev->mtu <= 1492 ? PKT_BUF_SZ : ndev->mtu) +
> > +   ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN + 16;
> 
>Mhm, I don't think FCS gets added to the frame buffer... And why add 16?

And +16 is added as the comment above states, to leave from the 
descriptor status appended by the hardware. This is already the case 
with PKT_BUF_SZ which for ravb is is set to 1538. MTU (1500) + ETH_HLEN 
(14) + VLAN_HLEN(4) + ETH_FCS_LEN(4) + ravb status (16) == 1538.

This is also what the sh_eth driver do and I think it's value to keep 
these to driver as similar as possible in this regard, would you not 
agree? If in deed the FSC is not added I think we should fix this for 
both drivers in a follow up commit.

> 
> [...]
> 
> MBR, Sergei

-- 
Regards,
Niklas Söderlund

Re: [PATCH v2 5/5] drm: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

Hi Dan

Thank you for the review,

On 13/02/18 07:23, Dan Carpenter wrote:
> On Mon, Feb 12, 2018 at 06:11:57PM +, Kieran Bingham wrote:
>> +adv7511->i2c_packet = i2c_new_secondary_device(i2c, "packet",
>> +ADV7511_PACKET_I2C_ADDR_DEFAULT);
>> +if (!adv7511->i2c_packet) {
>> +ret = -EINVAL;
>> +goto err_unregister_cec;
>> +}
>> +
>> +regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
>> + adv7511->i2c_packet->addr << 1);
>> +
>>  INIT_WORK(>hpd_work, adv7511_hpd_work);
>>  
>>  if (i2c->irq) {
>> @@ -1181,7 +1190,7 @@ static int adv7511_probe(struct i2c_client *i2c, const 
>> struct i2c_device_id *id)
>>  IRQF_ONESHOT, dev_name(dev),
>>  adv7511);
>>  if (ret)
>> -goto err_unregister_cec;
>> +goto err_unregister_packet;
>>  }
>>  
>>  adv7511_power_off(adv7511);
> 
> There is another goto which needs to be updated if adv7511_cec_init()
> fails.

Aha - thanks - I'll look into this now.


> 
>> @@ -1203,6 +1212,8 @@ static int adv7511_probe(struct i2c_client *i2c, const 
>> struct i2c_device_id *id)
>>  adv7511_audio_init(dev, adv7511);
>>  return 0;
>>  
>> +err_unregister_packet:
>> +i2c_unregister_device(adv7511->i2c_packet);
>>  err_unregister_cec:
>>  i2c_unregister_device(adv7511->i2c_cec);
>>  if (adv7511->cec_clk)
> 
> 
> regards,
> dan carpenter
> 

RE: [PATCH v5 14/26] ARM: shmobile: defconfig: Enable RENESAS_WDT_GEN

[Fabrizio Castro]

Hello Simon,

what do you think about enabling the watchdog in multi_v7_defconfig as a module?

Thanks,
Fab

> Subject: [PATCH v5 14/26] ARM: shmobile: defconfig: Enable RENESAS_WDT_GEN
>
> R-Car Gen2 and RZ/G1 platforms come with a watchdog IP, therefore enable
> its driver by default.
>
> Signed-off-by: Fabrizio Castro 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> Reviewed-by: Wolfram Sang 
> ---
> v4->v5:
> * no change
>
>  arch/arm/configs/shmobile_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/shmobile_defconfig 
> b/arch/arm/configs/shmobile_defconfig
> index 578434c..d5cdad8 100644
> --- a/arch/arm/configs/shmobile_defconfig
> +++ b/arch/arm/configs/shmobile_defconfig
> @@ -132,6 +132,7 @@ CONFIG_CPU_THERMAL=y
>  CONFIG_RCAR_THERMAL=y
>  CONFIG_WATCHDOG=y
>  CONFIG_DA9063_WATCHDOG=y
> +CONFIG_RENESAS_WDT=y
>  CONFIG_MFD_AS3711=y
>  CONFIG_MFD_DA9063=y
>  CONFIG_REGULATOR_FIXED_VOLTAGE=y
> --
> 2.7.4




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

[PATCH v6 09/26] soc: renesas: rcar-rst: Enable watchdog as reset trigger for Gen2

[Fabrizio Castro]

This patch allows for platform specific quirks as some of the SoC need
further customization for the watchdog to work properly, like for R-Car
Gen2 and for RZ/G.

Signed-off-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com>
Signed-off-by: Ramesh Shanmugasundaram <ramesh.shanmugasunda...@bp.renesas.com>
---
v5->v6:
* rebased on top of renesas-devel-20180213-v4.16-rc1

 drivers/soc/renesas/rcar-rst.c | 37 ++---
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/renesas/rcar-rst.c b/drivers/soc/renesas/rcar-rst.c
index e2340eb..3413666 100644
--- a/drivers/soc/renesas/rcar-rst.c
+++ b/drivers/soc/renesas/rcar-rst.c
@@ -13,8 +13,18 @@
 #include 
 #include 
 
+#define WDTRSTCR_RESET 0xA55A0002
+#define WDTRSTCR   0x0054
+
+static int rcar_rst_enable_wdt_reset(void __iomem *base)
+{
+   iowrite32(WDTRSTCR_RESET, base + WDTRSTCR);
+   return 0;
+}
+
 struct rst_config {
-   unsigned int modemr;/* Mode Monitoring Register Offset */
+   unsigned int modemr;/* Mode Monitoring Register Offset */
+   int (*configure)(void *base);   /* Platform specific configuration */
 };
 
 static const struct rst_config rcar_rst_gen1 __initconst = {
@@ -23,6 +33,11 @@ static const struct rst_config rcar_rst_gen1 __initconst = {
 
 static const struct rst_config rcar_rst_gen2 __initconst = {
.modemr = 0x60,
+   .configure = rcar_rst_enable_wdt_reset,
+};
+
+static const struct rst_config rcar_rst_gen3 __initconst = {
+   .modemr = 0x60,
 };
 
 static const struct of_device_id rcar_rst_matches[] __initconst = {
@@ -38,12 +53,12 @@ static const struct of_device_id rcar_rst_matches[] 
__initconst = {
{ .compatible = "renesas,r8a7792-rst", .data = _rst_gen2 },
{ .compatible = "renesas,r8a7793-rst", .data = _rst_gen2 },
{ .compatible = "renesas,r8a7794-rst", .data = _rst_gen2 },
-   /* R-Car Gen3 is handled like R-Car Gen2 */
-   { .compatible = "renesas,r8a7795-rst", .data = _rst_gen2 },
-   { .compatible = "renesas,r8a7796-rst", .data = _rst_gen2 },
-   { .compatible = "renesas,r8a77970-rst", .data = _rst_gen2 },
-   { .compatible = "renesas,r8a77980-rst", .data = _rst_gen2 },
-   { .compatible = "renesas,r8a77995-rst", .data = _rst_gen2 },
+   /* R-Car Gen3 */
+   { .compatible = "renesas,r8a7795-rst", .data = _rst_gen3 },
+   { .compatible = "renesas,r8a7796-rst", .data = _rst_gen3 },
+   { .compatible = "renesas,r8a77970-rst", .data = _rst_gen3 },
+   { .compatible = "renesas,r8a77980-rst", .data = _rst_gen3 },
+   { .compatible = "renesas,r8a77995-rst", .data = _rst_gen3 },
{ /* sentinel */ }
 };
 
@@ -72,6 +87,14 @@ static int __init rcar_rst_init(void)
rcar_rst_base = base;
cfg = match->data;
saved_mode = ioread32(base + cfg->modemr);
+   if (cfg->configure) {
+   error = cfg->configure(base);
+   if (error) {
+   pr_warn("%pOF: Cannot run SoC specific configuration\n",
+   np);
+   goto out_put;
+   }
+   }
 
pr_debug("%pOF: MODE = 0x%08x\n", np, saved_mode);
 
-- 
2.7.4

Re: [PATCH v2 3/3] mmc: renesas_sdhi: add eMMC HS400 mode support

[Wolfram Sang]

On Tue, Feb 13, 2018 at 12:38:44PM +0100, Simon Horman wrote:
> On Wed, Feb 07, 2018 at 11:21:44PM +0100, Wolfram Sang wrote:
> > 
> > > + /* Reset HS400 mode */
> > > + sd_ctrl_write16(host, CTL_SDIF_MODE, ~0x0001 &
> > > + sd_ctrl_read16(host, CTL_SDIF_MODE));
> > > + sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2,
> > > +~(SH_MOBILE_SDHI_SCC_TMPPORT2_HS400EN |
> > > +  SH_MOBILE_SDHI_SCC_TMPPORT2_HS400OSEL) &
> > > + sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2));
> > > +
> > 
> > This looks like code duplication. Can't we simply call
> > renesas_sdhi_reset_hs400_mode()?
> 
> Yes, thanks for noticing. I will make that so.
> 
> I think that the previous few lines, not added by this patch,
> can also be consolidated into a renesas_sdhi_reset_scc() function
> and re-used in renesas_sdhi_reset_scc().

Even better!



signature.asc
Description: PGP signature

Re: [PATCH v2 2/3] mmc: tmio: add eMMC HS400 mode support

[Wolfram Sang]

On Tue, Feb 13, 2018 at 12:33:53PM +0100, Simon Horman wrote:
> On Wed, Feb 07, 2018 at 11:20:12PM +0100, Wolfram Sang wrote:
> > 
> > Hi Simon,
> > 
> > > + void (*disable_scc)(struct mmc_host *mmc);
> > 
> > Do we really need this callback? I'd think it can be folded into
> > reset_hs400_mode() because it is called only once?
> > 
> > > + void (*prepare_hs400_tuning)(struct mmc_host *mmc, struct mmc_ios *ios);
> > 
> > Can't we use the host->ops->prepare_hs400_tuning() callback invoked by
> > the core?
> 
> Empirically that does not seem to work.

:( Pity.

> > > + void (*reset_hs400_mode)(struct mmc_host *mmc);
> > 
> > Maybe we can get rid of this, too? See later...
> > 
> > > + if (host->disable_scc)
> > > + host->disable_scc(mmc);
> > 
> > (Here, this can be folded into the next callback)
> 
> Yes, agreed. I've folded the callbacks as you suggest.

Cool, thanks!

> > > +
> > > + /* reset HS400 mode */
> > > + if (ios->timing != MMC_TIMING_MMC_HS400 && host->reset_hs400_mode)
> > > + host->reset_hs400_mode(mmc);
> > 
> > I wonder: If for any ios which is != MMC_TIMING_MMC_HS400, the
> > hs400_mode needs to be reset. Couldn't we as well then disable the mode
> > always after the MMC_TIMING_MMC_HS400 tuning was selected? Just
> > brainstorming here...
> 
> Perhaps but I'm unsure where we would hook in this change, any ideas?

I think this becomes moot if we can't get the prepare-callback of the
core to work. I'd think it makes sense to have both callbacks from here
moved to the core or none to keep at least one kind of symmetry.



signature.asc
Description: PGP signature

RE: [PATCH v5 09/26] soc: renesas: rcar-rst: Enable watchdog as reset trigger for Gen2

[Fabrizio Castro]

Hello Simon,

> Subject: Re: [PATCH v5 09/26] soc: renesas: rcar-rst: Enable watchdog as 
> reset trigger for Gen2
>
> On Mon, Feb 12, 2018 at 05:44:18PM +, Fabrizio Castro wrote:
> > This patch allows for platform specific quirks as some of the SoC need
> > further customization for the watchdog to work properly, like for R-Car
> > Gen2 and for RZ/G.
> >
> > Signed-off-by: Fabrizio Castro 
> > Signed-off-by: Ramesh Shanmugasundaram 
> > 
>
> I am fine with this patch but please rebase it on top of
> renesas-devel-20180212-v4.16-rc1 (or later).

sure, I will.

Thanks,
Fab



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

Re: [PATCH v2 1/3] mmc: tmio: correct treatment of errors during tuning

[Wolfram Sang]

> I think we can drop this patch for now.

Nice! But we should keep it in mind and recall it, if issues pop up
later.



signature.asc
Description: PGP signature

Re: [PATCH 4/4] arm64: dts: renesas: r8a77995: add VSPD instances

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 00:25:29 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The r8a77995 has two VSPDs to handle display pipelines with a DU.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index
> 50c891f6649f..2c14a8dfd201 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -711,6 +711,16 @@
>   iommus = <_vp0 5>;
>   };
> 
> + vspd0: vsp@fea2 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea2 0 0x4000>;

Same issue as in patch 3/4 (for which I have incorrectly mentioned VSPD 
instead of VSPBS). I'd just extend the region size to 0x8000 for both VSPDs.

Apart from that,

Reviewed-by: Laurent Pinchart 

> + interrupts = ;
> + clocks = < CPG_MOD 623>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 623>;
> + renesas,fcp = <>;
> + };
> +
>   fcpvd0: fcp@fea27000 {
>   compatible = "renesas,fcpv";
>   reg = <0 0xfea27000 0 0x200>;
> @@ -720,6 +730,16 @@
>   iommus = <_vi0 8>;
>   };
> 
> + vspd1: vsp@fea8 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea28000 0 0x4000>;
> + interrupts = ;
> + clocks = < CPG_MOD 622>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 622>;
> + renesas,fcp = <>;
> + };
> +
>   fcpvd1: fcp@fea2f000 {
>   compatible = "renesas,fcpv";
>   reg = <0 0xfea2f000 0 0x200>;

-- 
Regards,

Laurent Pinchart

Re: [PATCH 3/4] arm64: dts: renesas: r8a77995: add VSPBS instance

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 00:25:28 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The r8a77995 has a VSPBS to support image processing such as blending of
> 2 input images.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index
> 196a917afea6..50c891f6649f 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -692,6 +692,16 @@
>   status = "disabled";
>   };
> 
> + vspbs: vsp@fe96 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe96 0 0x4000>;

Unless I'm mistaken the VSPD instance has a CLUT on RPF2, so you need to 
extend the memory region to include it. It's probably safe to set the size to 
0x8000 to include the whole VSP memory region, even if most of the 
0x4000-0x7fff range is not used.

It seems that r8a7795 and r8a7796 suffer from the same issue upstream, they 
should be fixed.

Apart from that,

Reviewed-by: Laurent Pinchart 

> + interrupts = ;
> + clocks = < CPG_MOD 627>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 627>;
> + renesas,fcp = <>;
> + };
> +
>   fcpvb0: fcp@fe96f000 {
>   compatible = "renesas,fcpv";
>   reg = <0 0xfe96f000 0 0x200>;

-- 
Regards,

Laurent Pinchart

[PATCH] ata: sata_rcar: Remove unused variable in sata_rcar_init_controller()

[Geert Uytterhoeven]

drivers/ata/sata_rcar.c: In function 'sata_rcar_init_controller':
drivers/ata/sata_rcar.c:821:8: warning: unused variable 'base' 
[-Wunused-variable]

Fixes: da77d76b95a0e894 ("sata_rcar: Reset SATA PHY when Salvator-X board 
resumes")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/ata/sata_rcar.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ata/sata_rcar.c b/drivers/ata/sata_rcar.c
index 6f47ca34767d74fe..6456e07db72a7ea4 100644
--- a/drivers/ata/sata_rcar.c
+++ b/drivers/ata/sata_rcar.c
@@ -818,7 +818,6 @@ static void sata_rcar_init_module(struct sata_rcar_priv 
*priv)
 static void sata_rcar_init_controller(struct ata_host *host)
 {
struct sata_rcar_priv *priv = host->private_data;
-   void __iomem *base = priv->base;
 
/* reset and setup phy */
switch (priv->type) {
-- 
2.7.4

[PATCH v3 2/2] mmc: renesas_sdhi: add eMMC HS400 mode support

[Simon Horman]

From: Masaharu Hayakawa 

This patch adds processing for selecting HS400 mode.

Signed-off-by: Masaharu Hayakawa 
Signed-off-by: Simon Horman 
---
v3 [Simon Horman]
* Consolidate disable_scc and reset_hs400_mode into reset_hs400_tuning
  callback
* Reuse renesas_sdhi_reset_hs400_mode() in renesas_sdhi_hw_reset()
* Factor out renesas_sdhi_reset_scc()

v2 [Simon Horman]
* Updated to new version from BSP v3.6.0
* Dropped 4 and 8 tap differentiation as all SoCs currently supported
  by the driver in upstream use 4 taps for HS400.

v1 [Simon Horman]
* Combined patched by Ai Kyuse and Masaharu Hayakawa
* Rebase

v0 [Masaharu Hayakawa]
---
 drivers/mmc/host/renesas_sdhi_core.c | 133 +--
 1 file changed, 111 insertions(+), 22 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index 80943fa07db6..f4c202019cd0 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -211,6 +211,7 @@ static int renesas_sdhi_start_signal_voltage_switch(struct 
mmc_host *mmc,
 #define SH_MOBILE_SDHI_SCC_CKSEL   0x006
 #define SH_MOBILE_SDHI_SCC_RVSCNTL 0x008
 #define SH_MOBILE_SDHI_SCC_RVSREQ  0x00A
+#define SH_MOBILE_SDHI_SCC_TMPPORT20x00E
 
 /* Definitions for values the SH_MOBILE_SDHI_SCC_DTCNTL register */
 #define SH_MOBILE_SDHI_SCC_DTCNTL_TAPENBIT(0)
@@ -223,6 +224,9 @@ static int renesas_sdhi_start_signal_voltage_switch(struct 
mmc_host *mmc,
 #define SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN   BIT(0)
 /* Definitions for values the SH_MOBILE_SDHI_SCC_RVSREQ register */
 #define SH_MOBILE_SDHI_SCC_RVSREQ_RVSERR   BIT(2)
+/* Definitions for values the SH_MOBILE_SDHI_SCC_TMPPORT2 register */
+#define SH_MOBILE_SDHI_SCC_TMPPORT2_HS400OSEL  BIT(4)
+#define SH_MOBILE_SDHI_SCC_TMPPORT2_HS400ENBIT(31)
 
 static inline u32 sd_scc_read32(struct tmio_mmc_host *host,
struct renesas_sdhi *priv, int addr)
@@ -243,33 +247,30 @@ static unsigned int renesas_sdhi_init_tuning(struct 
tmio_mmc_host *host)
 
priv = host_to_priv(host);
 
-   /* set sampling clock selection range */
-   sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL,
-  0x8 << SH_MOBILE_SDHI_SCC_DTCNTL_TAPNUM_SHIFT);
-
/* Initialize SCC */
sd_ctrl_write32_as_16_and_16(host, CTL_STATUS, 0x0);
 
-   sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL,
-  SH_MOBILE_SDHI_SCC_DTCNTL_TAPEN |
-  sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL));
-
sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
 
+   /* set sampling clock selection range */
+   sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL,
+  SH_MOBILE_SDHI_SCC_DTCNTL_TAPEN |
+  0x8 << SH_MOBILE_SDHI_SCC_DTCNTL_TAPNUM_SHIFT);
+
sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_CKSEL,
   SH_MOBILE_SDHI_SCC_CKSEL_DTSEL |
   sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_CKSEL));
 
-   sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, CLK_CTL_SCLKEN |
-   sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
-
sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_RVSCNTL,
   ~SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN &
   sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_RVSCNTL));
 
sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_DT2FF, priv->scc_tappos);
 
+   sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, CLK_CTL_SCLKEN |
+   sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
+
/* Read TAPNUM */
return (sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_DTCNTL) >>
SH_MOBILE_SDHI_SCC_DTCNTL_TAPNUM_SHIFT) &
@@ -285,13 +286,103 @@ static void renesas_sdhi_prepare_tuning(struct 
tmio_mmc_host *host,
sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_TAPSET, tap);
 }
 
+static void renesas_sdhi_prepare_hs400_tuning(struct mmc_host *mmc,
+ struct mmc_ios *ios)
+{
+   struct tmio_mmc_host *host = mmc_priv(mmc);
+   struct renesas_sdhi *priv = host_to_priv(host);
+
+   sd_ctrl_write16(host, CTL_SD_CARD_CLK_CTL, ~CLK_CTL_SCLKEN &
+   sd_ctrl_read16(host, CTL_SD_CARD_CLK_CTL));
+
+   /* Set HS400 mode */
+   sd_ctrl_write16(host, CTL_SDIF_MODE, 0x0001 |
+   sd_ctrl_read16(host, CTL_SDIF_MODE));
+   sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2,
+  (SH_MOBILE_SDHI_SCC_TMPPORT2_HS400EN |
+   SH_MOBILE_SDHI_SCC_TMPPORT2_HS400OSEL) |
+   sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2));
+
+   /* Set the sampling clock selection 

[PATCH v3 0/2] mmc: renesas_sdhi: add eMMC HS400 mode support

[Simon Horman]

Hi,

this patch-set provides SDHI driver support for eMMC HS400.

Based on mmc/next

Dependencies for applying these patches: none

Dependencies to test eMMC HS400:
* [PATCH] clk: renesas: rcar-gen3: Fix SD divider setting
* [PATCH v2] arm64: dts: salvator-common: Enable HS400 of SDHI2

To assist testing and review this patch and the above mentioned
dependencies, which are necessary and sufficient to enable HS400 on H3 /
Salvator-X, M3-W 1.0 / Salvator-X and H3 ES2.0 Salvator-XS are available
at:

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/hs400-v3

Changes since v2:
* Consolidate disable_scc and reset_hs400_mode into reset_hs400_tuning
  callback
* Reuse renesas_sdhi_reset_hs400_mode() in renesas_sdhi_hw_reset()
* Factor out renesas_sdhi_reset_scc()

Changes since v1:
* Use updated code from BSP v3.6.0
* Ironed out dependencies, eMMC HS400 is now working on
  H3 / Salvator-X, M3-W 1.0 / Salvator-X and H3 ES2.0 Salvator-XS.

Masaharu Hayakawa (2):
  mmc: tmio: add eMMC HS400 mode support
  mmc: renesas_sdhi: add eMMC HS400 mode support

 drivers/mmc/host/renesas_sdhi_core.c | 133 +--
 drivers/mmc/host/tmio_mmc.h  |   5 ++
 drivers/mmc/host/tmio_mmc_core.c |  24 ++-
 3 files changed, 138 insertions(+), 24 deletions(-)

-- 
2.11.0

[PATCH v3 1/2] mmc: tmio: add eMMC HS400 mode support

[Simon Horman]

From: Masaharu Hayakawa 

This patch adds processing for selecting HS400 mode.

Signed-off-by: Masaharu Hayakawa 
Signed-off-by: Simon Horman 
---
v3 [Simon Horman]
* Consolidate disable_scc and reset_hs400_mode into reset_hs400_tuning
  callback

v2 [Simon Horman]
* Updated to new version of BSP patch from BSP v3.6.0
* Dropped 4 and 8 tap differentiation as all SoCs currently supported
  by the driver in upstream use 4 taps for HS400.
* Minor cleanup

v1 [Simon Horman]
* Combined patches by Ai Kyuse and Masaharu Hayakawa.
* Rebase
* Minor clean-up

v0 [Masaharu Hayakawa]
---
 drivers/mmc/host/tmio_mmc.h  |  5 +
 drivers/mmc/host/tmio_mmc_core.c | 24 ++--
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index e7d651352dc9..bac620109a90 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -46,6 +46,7 @@
 #define CTL_DMA_ENABLE 0xd8
 #define CTL_RESET_SD 0xe0
 #define CTL_VERSION 0xe2
+#define CTL_SDIF_MODE 0xe6
 #define CTL_SDIO_REGS 0x100
 #define CTL_CLK_AND_WAIT_CTL 0x138
 #define CTL_RESET_SDIO 0x1e0
@@ -191,6 +192,10 @@ struct tmio_mmc_host {
/* Tuning values: 1 for success, 0 for failure */
DECLARE_BITMAP(taps, BITS_PER_BYTE * sizeof(long));
unsigned int tap_num;
+   unsigned long tap_set;
+
+   void (*prepare_hs400_tuning)(struct mmc_host *mmc, struct mmc_ios *ios);
+   void (*reset_hs400_tuning)(struct mmc_host *mmc);
 
const struct tmio_mmc_dma_ops *dma_ops;
 };
diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 33494241245a..889b4d43085b 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -199,6 +199,13 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
tmio_mmc_clk_stop(host);
return;
}
+   /*
+* Both HS400 and HS200/SD104 set 200MHz, but some devices need to
+* set 400MHz to distinguish the CPG settings in HS400.
+*/
+   if (host->mmc->ios.timing == MMC_TIMING_MMC_HS400 &&
+   new_clock == 2)
+   new_clock = 4;
 
if (host->clk_update)
clock = host->clk_update(host, new_clock) / 512;
@@ -209,8 +216,13 @@ static void tmio_mmc_set_clock(struct tmio_mmc_host *host,
clock <<= 1;
 
/* 1/1 clock is option */
-   if ((host->pdata->flags & TMIO_MMC_CLK_ACTUAL) && ((clk >> 22) & 0x1))
-   clk |= 0xff;
+   if ((host->pdata->flags & TMIO_MMC_CLK_ACTUAL) &&
+   ((clk >> 22) & 0x1)) {
+   if (!(host->mmc->ios.timing == MMC_TIMING_MMC_HS400))
+   clk |= 0xff;
+   else
+   clk &= ~0xff;
+   }
 
if (host->set_clk_div)
host->set_clk_div(host->pdev, (clk >> 22) & 1);
@@ -1001,6 +1013,9 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
struct device *dev = >pdev->dev;
unsigned long flags;
 
+   if (host->reset_hs400_tuning)
+   host->reset_hs400_tuning(mmc);
+
mutex_lock(>ios_lock);
 
spin_lock_irqsave(>lock, flags);
@@ -1051,6 +1066,11 @@ static void tmio_mmc_set_ios(struct mmc_host *mmc, 
struct mmc_ios *ios)
"%s.%d: IOS interrupted: clk %u, mode %u",
current->comm, task_pid_nr(current),
ios->clock, ios->power_mode);
+
+   /* HS400 Register setting */
+   if (ios->timing == MMC_TIMING_MMC_HS400 && host->prepare_hs400_tuning)
+   host->prepare_hs400_tuning(mmc, ios);
+
host->mrq = NULL;
 
host->clk_cache = ios->clock;
-- 
2.11.0

Re: [PATCH 2/4] arm64: dts: renesas: r8a77995: add FCPVD nodes

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 00:25:27 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The FCPVD handles the interface between the VSPD and memory.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

I would however squash this with patch 1/4 from the same series.

> ---
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index
> 6cf935d307d9..196a917afea6 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -700,6 +700,24 @@
>   resets = < 607>;
>   iommus = <_vp0 5>;
>   };
> +
> + fcpvd0: fcp@fea27000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea27000 0 0x200>;
> + clocks = < CPG_MOD 603>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 603>;
> + iommus = <_vi0 8>;
> + };
> +
> + fcpvd1: fcp@fea2f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea2f000 0 0x200>;
> + clocks = < CPG_MOD 602>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 602>;
> + iommus = <_vi0 9>;
> + };
>   };
> 
>   timer {


-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/4] arm64: dts: renesas: r8a77995: add FCPVB node

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 00:25:26 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The FCPVB handles the interface between the VSPB and memory.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> ---
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index
> cd3c6a30fc47..6cf935d307d9 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -691,6 +691,15 @@
>   #phy-cells = <0>;
>   status = "disabled";
>   };
> +
> + fcpvb0: fcp@fe96f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfe96f000 0 0x200>;
> + clocks = < CPG_MOD 607>;
> + power-domains = < R8A77995_PD_ALWAYS_ON>;
> + resets = < 607>;
> + iommus = <_vp0 5>;
> + };
>   };
> 
>   timer {

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 5/5] drm: adv7511: Add support for i2c_new_secondary_device

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 00:07:53 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
> ports. Each map has it own I²C address and acts as a standard slave
> device on the I²C bus.
> 
> Allow a device tree node to override the default addresses so that
> address conflicts with other devices on the same bus may be resolved at
> the board description level.
> 
> Signed-off-by: Kieran Bingham 
> ---
> v2:
>  - Update missing edid-i2c address setting
>  - Split out DT bindings
>  - Rename and move the I2C default addresses to their own section
> 
>  drivers/gpu/drm/bridge/adv7511/adv7511.h |  6 
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 42 
>  2 files changed, 33 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h index d034b2cb5eee..04e6759ee45b
> 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -93,6 +93,11 @@
>  #define ADV7511_REG_CHIP_ID_HIGH 0xf5
>  #define ADV7511_REG_CHIP_ID_LOW  0xf6
> 
> +/* Hardware defined default addresses for i2c register maps */

s/i2c/I2C/ ? That's really because I had to find something :-)

Reviewed-by: Laurent Pinchart 

> +#define ADV7511_CEC_I2C_ADDR_DEFAULT 0x3c
> +#define ADV7511_EDID_I2C_ADDR_DEFAULT0x3f
> +#define ADV7511_PACKET_I2C_ADDR_DEFAULT  0x38
> +
>  #define ADV7511_CSC_ENABLE   BIT(7)
>  #define ADV7511_CSC_UPDATE_MODE  BIT(5)
> 
> @@ -322,6 +327,7 @@ struct adv7511 {
>   struct i2c_client *i2c_main;
>   struct i2c_client *i2c_edid;
>   struct i2c_client *i2c_cec;
> + struct i2c_client *i2c_packet;
> 
>   struct regmap *regmap;
>   struct regmap *regmap_cec;
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index
> efa29db5fc2b..5e61b928c9c0 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -586,7 +586,7 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
>   /* Reading the EDID only works if the device is powered */
>   if (!adv7511->powered) {
>   unsigned int edid_i2c_addr =
> - (adv7511->i2c_main->addr << 1) + 4;
> + (adv7511->i2c_edid->addr << 1);
> 
>   __adv7511_power_on(adv7511);
> 
> @@ -969,10 +969,10 @@ static int adv7511_init_cec_regmap(struct adv7511
> *adv) {
>   int ret;
> 
> - adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,
> -  adv->i2c_main->addr - 1);
> + adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
> + ADV7511_CEC_I2C_ADDR_DEFAULT);
>   if (!adv->i2c_cec)
> - return -ENOMEM;
> + return -EINVAL;
>   i2c_set_clientdata(adv->i2c_cec, adv);
> 
>   adv->regmap_cec = devm_regmap_init_i2c(adv->i2c_cec,
> @@ -1082,8 +1082,6 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id) struct adv7511_link_config link_config;
>   struct adv7511 *adv7511;
>   struct device *dev = >dev;
> - unsigned int main_i2c_addr = i2c->addr << 1;
> - unsigned int edid_i2c_addr = main_i2c_addr + 4;
>   unsigned int val;
>   int ret;
> 
> @@ -1153,24 +1151,35 @@ static int adv7511_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id) if (ret)
>   goto uninit_regulators;
> 
> - regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
> - regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
> -  main_i2c_addr - 0xa);
> - regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
> -  main_i2c_addr - 2);
> -
>   adv7511_packet_disable(adv7511, 0x);
> 
> - adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);
> + adv7511->i2c_edid = i2c_new_secondary_device(i2c, "edid",
> + ADV7511_EDID_I2C_ADDR_DEFAULT);
>   if (!adv7511->i2c_edid) {
> - ret = -ENOMEM;
> + ret = -EINVAL;
>   goto uninit_regulators;
>   }
> 
> + regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
> +  adv7511->i2c_edid->addr << 1);
> +
>   ret = adv7511_init_cec_regmap(adv7511);
>   if (ret)
>   goto err_i2c_unregister_edid;
> 
> + regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
> +  adv7511->i2c_cec->addr << 1);
> +
> + adv7511->i2c_packet = i2c_new_secondary_device(i2c, "packet",
> + 

Re: [PATCH v3 4/5] media: adv7604: Add support for i2c_new_secondary_device

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 00:07:52 EET Kieran Bingham wrote:
> From: Jean-Michel Hautbois 
> 
> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
> I²C ports. Each map has it own I²C address and acts as a standard slave
> device on the I²C bus.
> 
> Allow a device tree node to override the default addresses so that
> address conflicts with other devices on the same bus may be resolved at
> the board description level.
> 
> Signed-off-by: Jean-Michel Hautbois 
> [Kieran: Re-adapted for mainline]
> Signed-off-by: Kieran Bingham 
> 
> ---
> Based upon the original posting :
>   https://lkml.org/lkml/2014/10/22/469
> 
> v2:
>  - Split out DT bindings from driver updates
>  - Return -EINVAL on error paths from adv76xx_dummy_client()
> 
>  drivers/media/i2c/adv7604.c | 62 ++
>  1 file changed, 40 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 1544920ec52d..872e124793f8 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -2734,6 +2734,27 @@ static const struct v4l2_ctrl_config
> adv76xx_ctrl_free_run_color = {
> 
>  /* - */
> 
> +struct adv76xx_register {

adv76xx_register seems to imply that this describes a particular register, 
while the structure describes a registers map. How about adv76xx_register_map, 
adv76xx_register_bank or adv76xx_register_page ?

> + const char *name;
> + u8 default_addr;
> +};
> +
> +static const struct adv76xx_register adv76xx_secondary_names[] = {

The table doesn't contain secondary names only as there's an entry for the 
main map. How about calling it adv76xx_default_addresses or something along 
the same line ?

> + [ADV76XX_PAGE_IO] = { "main", 0x4c },
> + [ADV7604_PAGE_AVLINK] = { "avlink", 0x42 },
> + [ADV76XX_PAGE_CEC] = { "cec", 0x40 },
> + [ADV76XX_PAGE_INFOFRAME] = { "infoframe", 0x3e },
> + [ADV7604_PAGE_ESDP] = { "esdp", 0x38 },
> + [ADV7604_PAGE_DPP] = { "dpp", 0x3c },
> + [ADV76XX_PAGE_AFE] = { "afe", 0x26 },
> + [ADV76XX_PAGE_REP] = { "rep", 0x32 },
> + [ADV76XX_PAGE_EDID] = { "edid", 0x36 },
> + [ADV76XX_PAGE_HDMI] = { "hdmi", 0x34 },
> + [ADV76XX_PAGE_TEST] = { "test", 0x30 },
> + [ADV76XX_PAGE_CP] = { "cp", 0x22 },
> + [ADV7604_PAGE_VDP] = { "vdp", 0x24 },
> +};
> +
>  static int adv76xx_core_init(struct v4l2_subdev *sd)
>  {
>   struct adv76xx_state *state = to_state(sd);
> @@ -2834,13 +2855,26 @@ static void adv76xx_unregister_clients(struct
> adv76xx_state *state) }
> 
>  static struct i2c_client *adv76xx_dummy_client(struct v4l2_subdev *sd,
> - u8 addr, u8 io_reg)
> +unsigned int i)

Maybe unsigned int page ?

With these fixed,

Reviewed-by: Laurent Pinchart 

>  {
>   struct i2c_client *client = v4l2_get_subdevdata(sd);
> + struct adv76xx_state *state = to_state(sd);
> + struct adv76xx_platform_data *pdata = >pdata;
> + unsigned int io_reg = 0xf2 + i;
> + struct i2c_client *new_client;
> +
> + if (pdata && pdata->i2c_addresses[i])
> + new_client = i2c_new_dummy(client->adapter,
> +pdata->i2c_addresses[i]);
> + else
> + new_client = i2c_new_secondary_device(client,
> + adv76xx_secondary_names[i].name,
> + adv76xx_secondary_names[i].default_addr);
> 
> - if (addr)
> - io_write(sd, io_reg, addr << 1);
> - return i2c_new_dummy(client->adapter, io_read(sd, io_reg) >> 1);
> + if (new_client)
> + io_write(sd, io_reg, new_client->addr << 1);
> +
> + return new_client;
>  }
> 
>  static const struct adv76xx_reg_seq adv7604_recommended_settings_afe[] = {
> @@ -3115,20 +3149,6 @@ static int adv76xx_parse_dt(struct adv76xx_state
> *state) /* Disable the interrupt for now as no DT-based board uses it. */
> state->pdata.int1_config = ADV76XX_INT1_CONFIG_DISABLED;
> 
> - /* Use the default I2C addresses. */
> - state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42;
> - state->pdata.i2c_addresses[ADV76XX_PAGE_CEC] = 0x40;
> - state->pdata.i2c_addresses[ADV76XX_PAGE_INFOFRAME] = 0x3e;
> - state->pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38;
> - state->pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c;
> - state->pdata.i2c_addresses[ADV76XX_PAGE_AFE] = 0x26;
> - state->pdata.i2c_addresses[ADV76XX_PAGE_REP] = 0x32;
> - state->pdata.i2c_addresses[ADV76XX_PAGE_EDID] = 0x36;
> - state->pdata.i2c_addresses[ADV76XX_PAGE_HDMI] = 0x34;
> - state->pdata.i2c_addresses[ADV76XX_PAGE_TEST] = 0x30;
> 

Re: [PATCH v3 3/5] [RFT] ARM: dts: wheat: Fix ADV7513 address usage

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 00:07:51 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The r8a7792 Wheat board has two ADV7513 devices sharing a single i2c
> bus, however in low power mode the ADV7513 will reset it's slave maps to
> use the hardware defined default addresses.
> 
> The ADV7511 driver was adapted to allow the two devices to be registered
> correctly - but it did not take into account the fault whereby the
> devices reset the addresses.
> 
> This results in an address conflict between the device using the default
> addresses, and the other device if it is in low-power-mode.
> 
> Repair this issue by moving both devices away from the default address
> definitions.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> ---
> v2:
>  - Addition to series
> 
> v3:
>  - Split map register addresses into individual declarations.
> 
>  arch/arm/boot/dts/r8a7792-wheat.dts | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/r8a7792-wheat.dts
> b/arch/arm/boot/dts/r8a7792-wheat.dts index b9471b67b728..42fff8837eab
> 100644
> --- a/arch/arm/boot/dts/r8a7792-wheat.dts
> +++ b/arch/arm/boot/dts/r8a7792-wheat.dts
> @@ -240,9 +240,16 @@
>   status = "okay";
>   clock-frequency = <40>;
> 
> + /*
> +  * The adv75xx resets its addresses to defaults during low power power
> +  * mode. Because we have two ADV7513 devices on the same bus, we must
> +  * change both of them away from the defaults so that they do not
> +  * conflict.
> +  */
>   hdmi@3d {
>   compatible = "adi,adv7513";
> - reg = <0x3d>;
> + reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
> + reg-names = "main", "cec", "edid", "packet";
> 
>   adi,input-depth = <8>;
>   adi,input-colorspace = "rgb";
> @@ -272,7 +279,8 @@
> 
>   hdmi@39 {
>   compatible = "adi,adv7513";
> - reg = <0x39>;
> + reg = <0x39>, <0x29>, <0x49>, <0x59>;
> + reg-names = "main", "cec", "edid", "packet";
> 
>   adi,input-depth = <8>;
>   adi,input-colorspace = "rgb";

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 2/5] dt-bindings: adv7511: Add support for i2c_new_secondary_device

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 00:07:50 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
> ports. Each map has it own I²C address and acts as a standard slave
> device on the I²C bus.
> 
> Extend the device tree node bindings to be able to override the default
> addresses so that address conflicts with other devices on the same bus
> may be resolved at the board description level.
> 
> Signed-off-by: Kieran Bingham 
> Reviewed-by: Rob Herring 

Same comment as for 1/5 about the subject line.

> ---
> v2:
>  - Fixed up reg: property description to account for multiple optional
>addresses.
>  - Minor reword to commit message to account for DT only change
>  - Collected Robs RB tag
> 
> v3:
>  - Split map register addresses into individual declarations.
> 
>  .../devicetree/bindings/display/bridge/adi,adv7511.txt | 18 +--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index
> 0047b1394c70..3f85c351dd39 100644
> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> @@ -14,7 +14,13 @@ Required properties:
>   "adi,adv7513"
>   "adi,adv7533"
> 
> -- reg: I2C slave address
> +- reg: I2C slave addresses
> +  The ADV7511 internal registers are split into four pages exposed through
> +  different I2C addresses, creating four register maps. Each map has it own
> +  I2C address and acts as a standard slave device on the I²C bus. The main
> +  address is mandatory, others are optional and revert to defaults if not
> +  specified.

Nitpicking again, you're mixing I2C and I²C.

> +
> 
>  The ADV7511 supports a large number of input data formats that differ by
> their color depth, color format, clock mode, bit justification and random
> @@ -70,6 +76,9 @@ Optional properties:
>rather than generate its own timings for HDMI output.
>  - clocks: from common clock binding: reference to the CEC clock.
>  - clock-names: from common clock binding: must be "cec".
> +- reg-names : Names of maps with programmable addresses.
> + It can contain any map needing a non-default address.
> + Possible maps names are : "main", "edid", "cec", "packet"
> 
>  Required nodes:
> 
> @@ -88,7 +97,12 @@ Example
> 
>   adv7511w: hdmi@39 {
>   compatible = "adi,adv7511w";
> - reg = <39>;
> + /*
> +  * The EDID page will be accessible on address 0x66 on the i2c

And now you're using lowercase :-)

> +  * bus. All other maps continue to use their default addresses.
> +  */
> + reg = <0x39>, <0x66>;
> + reg-names = "main", "edid";
>   interrupt-parent = <>;
>   interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
>   clocks = <_clock>;

With these fixed (or not, up to you),

Reviewed-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 1/5] dt-bindings: media: adv7604: Add support for i2c_new_secondary_device

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Tuesday, 13 February 2018 00:07:49 EET Kieran Bingham wrote:
> From: Jean-Michel Hautbois 
> 
> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
> I²C ports. Each map has it own I²C address and acts as a standard slave
> device on the I²C bus.
> 
> Extend the device tree node bindings to be able to override the default
> addresses so that address conflicts with other devices on the same bus
> may be resolved at the board description level.
> 
> Signed-off-by: Jean-Michel Hautbois 
> [Kieran: Re-adapted for mainline]
> Signed-off-by: Kieran Bingham 
> Reviewed-by: Rob Herring 

Nitpicking, I might not mention i2c_new_secondary_device in the subject, as 
this is a DT bindings change. I don't mind too much though, as long as the 
bindings themselves don't contain Linux-specific information, and they don't, 
so

Reviewed-by: Laurent Pinchart 

> ---
> Based upon the original posting :
>   https://lkml.org/lkml/2014/10/22/469
> 
> v2:
>  - DT Binding update separated from code change
>  - Minor reword to commit message to account for DT only change.
>  - Collected Rob's RB tag.
> 
> v3:
>  - Split map register addresses into individual declarations.
> 
>  .../devicetree/bindings/media/i2c/adv7604.txt  | 18
> -- 1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
> 9cbd92eb5d05..ebb5f070c05b 100644
> --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> @@ -13,7 +13,11 @@ Required Properties:
>  - "adi,adv7611" for the ADV7611
>  - "adi,adv7612" for the ADV7612
> 
> -  - reg: I2C slave address
> +  - reg: I2C slave addresses
> +The ADV76xx has up to thirteen 256-byte maps that can be accessed via
> the +main I²C ports. Each map has it own I²C address and acts as a
> standard +slave device on the I²C bus. The main address is mandatory,
> others are +optional and revert to defaults if not specified.
> 
>- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
>  detection pins, one per HDMI input. The active flag indicates the GPIO
> @@ -35,6 +39,11 @@ Optional Properties:
> 
>- reset-gpios: Reference to the GPIO connected to the device's reset pin.
> - default-input: Select which input is selected after reset.
> +  - reg-names : Names of maps with programmable addresses.
> + It can contain any map needing a non-default address.
> + Possible maps names are :
> +   "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
> +   "rep", "edid", "hdmi", "test", "cp", "vdp"
> 
>  Optional Endpoint Properties:
> 
> @@ -52,7 +61,12 @@ Example:
> 
>   hdmi_receiver@4c {
>   compatible = "adi,adv7611";
> - reg = <0x4c>;
> + /*
> +  * The edid page will be accessible @ 0x66 on the i2c bus. All
> +  * other maps will retain their default addresses.
> +  */
> + reg = <0x4c>, <0x66>;
> + reg-names "main", "edid";
> 
>   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>   hpd-gpios = < 2 GPIO_ACTIVE_HIGH>;


-- 
Regards,

Laurent Pinchart

Re: [PATCH 02/15] clk: renesas: cpg-msr: Add support for R-Car M3-N

[Kieran Bingham]

Hi Jacopo,

Thanks for the patch.

I haven't really looked at the rest of the patch yet - but the title stands out:

[PATCH 02/15] clk: renesas: cpg-msr: Add support for R-Car M3-N

Should this be s/cpg-msr/cpg-mssr/ ?

--
Regards

Kieran



On 13/02/18 09:45, Jacopo Mondi wrote:
> Initial support for R-Car M3-N (r8a77965), including core and module
> clocks.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  .../devicetree/bindings/clock/renesas,cpg-mssr.txt |   1 +
>  drivers/clk/renesas/Kconfig|   5 +
>  drivers/clk/renesas/Makefile   |   1 +
>  drivers/clk/renesas/r8a77965-cpg-mssr.c| 333 
> +
>  drivers/clk/renesas/renesas-cpg-mssr.c |   6 +
>  drivers/clk/renesas/renesas-cpg-mssr.h |   1 +
>  include/dt-bindings/clock/r8a77965-cpg-mssr.h  |  62 
>  7 files changed, 409 insertions(+)
>  create mode 100644 drivers/clk/renesas/r8a77965-cpg-mssr.c
>  create mode 100644 include/dt-bindings/clock/r8a77965-cpg-mssr.h
> 
> diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt 
> b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> index f1890d0..246ab63 100644
> --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> @@ -22,6 +22,7 @@ Required Properties:
>- "renesas,r8a7794-cpg-mssr" for the r8a7794 SoC (R-Car E2)
>- "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3)
>- "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W)
> +  - "renesas,r8a77965-cpg-mssr" for the r8a77965 SoC (R-Car M3-N)
>- "renesas,r8a77970-cpg-mssr" for the r8a77970 SoC (R-Car V3M)
>- "renesas,r8a77995-cpg-mssr" for the r8a77995 SoC (R-Car D3)
>  
> diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
> index 84b40b9..047d6b5 100644
> --- a/drivers/clk/renesas/Kconfig
> +++ b/drivers/clk/renesas/Kconfig
> @@ -15,6 +15,7 @@ config CLK_RENESAS
>   select CLK_R8A7794 if ARCH_R8A7794
>   select CLK_R8A7795 if ARCH_R8A7795
>   select CLK_R8A7796 if ARCH_R8A7796
> + select CLK_R8A77965 if ARCH_R8A77965
>   select CLK_R8A77970 if ARCH_R8A77970
>   select CLK_R8A77995 if ARCH_R8A77995
>   select CLK_SH73A0 if ARCH_SH73A0
> @@ -97,6 +98,10 @@ config CLK_R8A7796
>   bool "R-Car M3-W clock support" if COMPILE_TEST
>   select CLK_RCAR_GEN3_CPG
>  
> +config CLK_R8A77965
> + bool "R-Car M3-N clock support" if COMPILE_TEST
> + select CLK_RCAR_GEN3_CPG
> +
>  config CLK_R8A77970
>   bool "R-Car V3M clock support" if COMPILE_TEST
>   select CLK_RCAR_GEN3_CPG
> diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
> index 34c4e0b..2e0982f 100644
> --- a/drivers/clk/renesas/Makefile
> +++ b/drivers/clk/renesas/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_CLK_R8A7792)   += r8a7792-cpg-mssr.o
>  obj-$(CONFIG_CLK_R8A7794)+= r8a7794-cpg-mssr.o
>  obj-$(CONFIG_CLK_R8A7795)+= r8a7795-cpg-mssr.o
>  obj-$(CONFIG_CLK_R8A7796)+= r8a7796-cpg-mssr.o
> +obj-$(CONFIG_CLK_R8A77965)   += r8a77965-cpg-mssr.o
>  obj-$(CONFIG_CLK_R8A77970)   += r8a77970-cpg-mssr.o
>  obj-$(CONFIG_CLK_R8A77995)   += r8a77995-cpg-mssr.o
>  obj-$(CONFIG_CLK_SH73A0) += clk-sh73a0.o
> diff --git a/drivers/clk/renesas/r8a77965-cpg-mssr.c 
> b/drivers/clk/renesas/r8a77965-cpg-mssr.c
> new file mode 100644
> index 000..f29d42c
> --- /dev/null
> +++ b/drivers/clk/renesas/r8a77965-cpg-mssr.c
> @@ -0,0 +1,333 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * r8a77965 Clock Pulse Generator / Module Standby and Software Reset
> + *
> + * Copyright (C) 2018 Jacopo Mondi 
> + *
> + * Based on r8a7795-cpg-mssr.c
> + *
> + * Copyright (C) 2015 Glider bvba
> + * Copyright (C) 2015 Renesas Electronics Corp.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "renesas-cpg-mssr.h"
> +#include "rcar-gen3-cpg.h"
> +
> +enum clk_ids {
> + /* Core Clock Outputs exported to DT */
> + LAST_DT_CORE_CLK = R8A77965_CLK_OSC,
> +
> + /* External Input Clocks */
> + CLK_EXTAL,
> + CLK_EXTALR,
> +
> + /* Internal Core Clocks */
> + CLK_MAIN,
> + CLK_PLL0,
> + CLK_PLL1,
> + CLK_PLL3,
> + CLK_PLL4,
> + CLK_PLL1_DIV2,
> + CLK_PLL1_DIV4,
> + CLK_S0,
> + CLK_S1,
> + CLK_S2,
> + CLK_S3,
> + CLK_SDSRC,
> + CLK_SSPSRC,
> + CLK_RINT,
> +
> + /* Module Clocks */
> + MOD_CLK_BASE
> +};
> +
> +static const struct cpg_core_clk r8a77965_core_clks[] __initconst = {
> + /* External Clock Inputs */
> + DEF_INPUT("extal",  CLK_EXTAL),
> + DEF_INPUT("extalr", CLK_EXTALR),
> +
> + /* Internal Core Clocks */
> + DEF_BASE(".main",   CLK_MAIN, CLK_TYPE_GEN3_MAIN, CLK_EXTAL),
> + 

Re: [PATCH v2 0/3] mmc: renesas_sdhi: add eMMC HS400 mode support

[Simon Horman]

On Thu, Feb 08, 2018 at 12:37:03PM +0100, Simon Horman wrote:
> On Wed, Feb 07, 2018 at 11:26:30PM +0100, Wolfram Sang wrote:
> > 
> > > * [PATCH] clk: renesas: rcar-gen3: Fix SD divider setting
> > 
> > I tried to address this one before:
> > 
> > [PATCH 0/3] clk: renesas: rcar-gen3-cpg: updates to SD divider table
> > 
> > but this had problems with H3 ES1.0 :(
> > 
> > I haven't yet compared the above dependency patch with what I did back
> > then. Will need to do that hopefully tomorrow. But as I read it, it
> > worked fine for you on H3 ES1.0?
> 
> Yes, it seemed to, though my memory of the testing is not fresh at this point.

I've done some more testing. This seems to work on:

* H3 ES1.0 / Salvator-X
* M3W ES1.0 / Salvator-X
* H3 ES2.0 / Salvator-XS

Re: [PATCH 0/3] Add R8A77970/Eagle PFC support

[Simon Horman]

On Tue, Feb 13, 2018 at 01:46:58PM +0300, Sergei Shtylyov wrote:
> On 02/13/2018 10:52 AM, Simon Horman wrote:
> 
> > Here's the set of 3 patches against Simon Horman's 'renesas.git' repo's
> > 'renesas-devel-20171110-v4.14-rc8' tag.  We're adding the R8A77970 PFC 
> > node
> > and then describing the pins for SCIF0 and EtherAVB devices declared 
> > earlier.
> > These patches depend on the R8A77970 PFC suport in order to work 
> > properly.
> >
> > [1/3] arm64: dts: renesas: r8a77970: add PFC support
> > [2/3] arm64: dts: renesas: eagle: add SCIF0 pins
> > [3/3] arm64: dts: renesas: eagle: add EtherAVB pins
> 
>  Hi Sergei,
> 
>  I have marked these patches as deferred pending acceptance of the PFC
>  driver. Please repost or otherwise ping me once that dependency has been
>  accepted.
> >>>
> >>> Has the dependency blocking this series been resolved yet ?
> >>
> >>Now it is, except for the 3rd patch... Simon, do I need to repost the 
> >> first two?
> >> The 1st one did apply to 4.16-rc1 here with a fuzz...
> > 
> > Thanks for bringing this to my attention.  No need to repost. I've applied
> > all three patches and plan to push later today.
> 
>My mentioning of the patch #3 wasn't just random: that patch shouldn't 
> have been
> merged since the EtherAVB pin groups were dropped by Geert while merging the 
> R8A77970
> PFC code. Now Eagle can't mount NFS root.

Sorry, parse error earlier this morning.

I will drop patch #3.

Re: [PATCH v2 3/3] mmc: renesas_sdhi: add eMMC HS400 mode support

[Simon Horman]

On Wed, Feb 07, 2018 at 11:21:44PM +0100, Wolfram Sang wrote:
> 
> > +   /* Reset HS400 mode */
> > +   sd_ctrl_write16(host, CTL_SDIF_MODE, ~0x0001 &
> > +   sd_ctrl_read16(host, CTL_SDIF_MODE));
> > +   sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2,
> > +  ~(SH_MOBILE_SDHI_SCC_TMPPORT2_HS400EN |
> > +SH_MOBILE_SDHI_SCC_TMPPORT2_HS400OSEL) &
> > +   sd_scc_read32(host, priv, SH_MOBILE_SDHI_SCC_TMPPORT2));
> > +
> 
> This looks like code duplication. Can't we simply call
> renesas_sdhi_reset_hs400_mode()?

Yes, thanks for noticing. I will make that so.

I think that the previous few lines, not added by this patch,
can also be consolidated into a renesas_sdhi_reset_scc() function
and re-used in renesas_sdhi_reset_scc().

Re: [PATCH v2 2/3] mmc: tmio: add eMMC HS400 mode support

[Simon Horman]

On Wed, Feb 07, 2018 at 11:20:12PM +0100, Wolfram Sang wrote:
> 
> Hi Simon,
> 
> > +   void (*disable_scc)(struct mmc_host *mmc);
> 
> Do we really need this callback? I'd think it can be folded into
> reset_hs400_mode() because it is called only once?
> 
> > +   void (*prepare_hs400_tuning)(struct mmc_host *mmc, struct mmc_ios *ios);
> 
> Can't we use the host->ops->prepare_hs400_tuning() callback invoked by
> the core?

Empirically that does not seem to work.

> > +   void (*reset_hs400_mode)(struct mmc_host *mmc);
> 
> Maybe we can get rid of this, too? See later...
> 
> > +   if (host->disable_scc)
> > +   host->disable_scc(mmc);
> 
> (Here, this can be folded into the next callback)

Yes, agreed. I've folded the callbacks as you suggest.

> > +
> > +   /* reset HS400 mode */
> > +   if (ios->timing != MMC_TIMING_MMC_HS400 && host->reset_hs400_mode)
> > +   host->reset_hs400_mode(mmc);
> 
> I wonder: If for any ios which is != MMC_TIMING_MMC_HS400, the
> hs400_mode needs to be reset. Couldn't we as well then disable the mode
> always after the MMC_TIMING_MMC_HS400 tuning was selected? Just
> brainstorming here...

Perhaps but I'm unsure where we would hook in this change, any ideas?

Re: [PATCH v2 1/3] mmc: tmio: correct treatment of errors during tuning

[Simon Horman]

On Wed, Feb 07, 2018 at 10:52:52PM +0100, Wolfram Sang wrote:
> On Fri, Jan 19, 2018 at 02:39:04PM +0100, Simon Horman wrote:
> > From: Masaharu Hayakawa 
> > 
> > If the return value of mmc_send_tuning() is error other than -EILSEQ, the
> > tuning fails and process goes out of for_loop.  But the correct processing
> > is to judge their TAP as bad.
> 
> Ideally, we would have more specific reasons why this is correct processing.
> 
> What other codes could happen here?

I mistakenly attached log below following to patch 2/3 rather than 1/3 (this
patch) which explains my reason for including this patch in the series.

However, I am no longer able to reproduce this problem - I tried to do so
in order to work out which errors were being handled differently with
and without the patch.

I think we can drop this patch for now.



* M3-W ES1.0 / Salvator-X

[1.812758] renesas_sdhi_internal_dmac ee10.sd: Got CD GPIO
[1.818778] renesas_sdhi_internal_dmac ee10.sd: Got WP GPIO
[1.874951] renesas_sdhi_internal_dmac ee14.sd: mmc0 base at 0xee14
+max clock rate 200 MHz
[1.884950] renesas_sdhi_internal_dmac ee16.sd: Got CD GPIO
[1.891088] renesas_sdhi_internal_dmac ee16.sd: Got WP GPIO
[2.083508] mmc0: new HS400 MMC card at address 0001
[2.084827] mmcblk0: mmc0:0001 eMMC   28.8 GiB
[2.085234] mmcblk0boot0: mmc0:0001 eMMC   partition 1 4.00 MiB
[2.085727] mmcblk0boot1: mmc0:0001 eMMC   partition 2 4.00 MiB
[2.086398] mmcblk0rpmb: mmc0:0001 eMMC   partition 3 4.00 MiB, chardev
+(243:0)
[2.097926]  mmcblk0: p1
[2.360533] renesas_sdhi_internal_dmac ee10.sd: Got CD GPIO
[2.367633] renesas_sdhi_internal_dmac ee10.sd: Got WP GPIO
[2.424700] renesas_sdhi_internal_dmac ee10.sd: mmc1 base at 0xee10
+max clock rate 200 MHz
[2.436021] renesas_sdhi_internal_dmac ee16.sd: Got CD GPIO
[2.443100] renesas_sdhi_internal_dmac ee16.sd: Got WP GPIO

* On H3 ES2.0 / Salvator-XS:

[2.452354] renesas_sdhi_internal_dmac ee10.sd: Got CD GPIO
[2.458344] renesas_sdhi_internal_dmac ee10.sd: Got WP GPIO
[2.513917] renesas_sdhi_internal_dmac ee14.sd: mmc0 base at 0xee14
+max clock rate 200 MHz
[2.523564] renesas_sdhi_internal_dmac ee16.sd: Got CD GPIO
[2.529559] renesas_sdhi_internal_dmac ee16.sd: Got WP GPIO
[2.636678] renesas_sdhi_internal_dmac ee14.sd: Tuning procedure failed
[2.643739] mmc0: tuning execution failed: -5
[2.648211] mmc0: error -5 whilst initialising MMC card
[2.730078] renesas_sdhi_internal_dmac ee14.sd: Tuning procedure failed
[2.730085] mmc0: tuning execution failed: -5
[2.730093] mmc0: error -5 whilst initialising MMC card
[2.858718] renesas_sdhi_internal_dmac ee14.sd: Tuning procedure failed
[2.858725] mmc0: tuning execution failed: -5
[2.858733] mmc0: error -5 whilst initialising MMC card
[2.991258] renesas_sdhi_internal_dmac ee10.sd: Got CD GPIO
[2.998333] renesas_sdhi_internal_dmac ee10.sd: Got WP GPIO
[3.063121] renesas_sdhi_internal_dmac ee14.sd: Tuning procedure failed
[3.063128] mmc0: tuning execution failed: -5
[3.063135] mmc0: error -5 whilst initialising MMC card
[3.085170] renesas_sdhi_internal_dmac ee16.sd: Got CD GPIO
[3.09] renesas_sdhi_internal_dmac ee16.sd: Got WP GPIO

> 
> > Signed-off-by: Masaharu Hayakawa 
> > Signed-off-by: Simon Horman 
> > ---
> > v2 [Simon Horman]
> > * Added to patchset targeted at upstream
> > * Minor revision of changelog
> > 
> > v0 [Masaharu Hayakawa]
> > ---
> >  drivers/mmc/host/tmio_mmc_core.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> > 
> > diff --git a/drivers/mmc/host/tmio_mmc_core.c 
> > b/drivers/mmc/host/tmio_mmc_core.c
> > index 6d8719be75a8..41767d33ef97 100644
> > --- a/drivers/mmc/host/tmio_mmc_core.c
> > +++ b/drivers/mmc/host/tmio_mmc_core.c
> > @@ -800,10 +800,7 @@ static int tmio_mmc_execute_tuning(struct mmc_host 
> > *mmc, u32 opcode)
> > if (host->prepare_tuning)
> > host->prepare_tuning(host, i % host->tap_num);
> >  
> > -   ret = mmc_send_tuning(mmc, opcode, NULL);
> > -   if (ret && ret != -EILSEQ)
> > -   goto out;
> > -   if (ret == 0)
> > +   if (!mmc_send_tuning(mmc, opcode, NULL))
> 
> I'd prefer (mmc_send_tuning() == 0) here instead of '!mmc_send_tuning()'.
> This reads as 'is ok' while the other reads more 'if not ok'.
> 
> > set_bit(i, host->taps);
> >  
> > usleep_range(1000, 1200);
> > -- 
> > 2.11.0
> >