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

[Simon Horman]

On Wed, May 23, 2018 at 11:37:47AM +0300, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Wednesday, 23 May 2018 11:33:26 EEST Simon Horman wrote:
> > On Tue, May 22, 2018 at 01:04:56PM +0200, Geert Uytterhoeven wrote:
> > > On Tue, May 22, 2018 at 11:05 AM, Simon Horman <ho...@verge.net.au> wrote:
> > >>> --- a/drivers/media/platform/vsp1/vsp1_regs.h
> > >>> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
> > >>> @@ -1,4 +1,4 @@
> > >>> -/* SPDX-License-Identifier: GPL-2.0 */
> > >>> +/* SPDX-License-Identifier: GPL-2.0+ */
> > >> 
> > >> While you are changing this line, I believe the correct format is
> > >> to use a '//' comment.
> > >> 
> > >> i.e.:
> > >> 
> > >> // SPDX-License-Identifier: GPL-2.0+
> > > 
> > > Not for C header files, only for C source files.
> > 
> > Wow!
> 
> Yes, it's a mess :-( The rationale is that the assembler doesn't support C++-
> style comments, so we need to use C-style comments in header files. We should 
> really have standardized usage of C-style comments everywhere, it makes no 
> sense to me.

I'm reading this email while standing on my head
and things make much more sense :)

Re: [PATCH] media: dt-bindings: media: rcar_vin: add support for r8a77965

[Simon Horman]

On Sun, May 13, 2018 at 08:58:18PM +0200, Niklas Söderlund wrote:
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1c669eb35..c2c57dcf73f4851b 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -21,6 +21,7 @@ on Gen3 platforms to a CSI-2 receiver.
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7796" for the R8A7796 device
> +   - "renesas,vin-r8a77965" for the R8A77965 device
> - "renesas,vin-r8a77970" for the R8A77970 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
>   device.
> -- 
> 2.17.0
> 

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

[Simon Horman]

On Tue, May 22, 2018 at 01:04:56PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, May 22, 2018 at 11:05 AM, Simon Horman <ho...@verge.net.au> wrote:
> >> --- a/drivers/media/platform/vsp1/vsp1_regs.h
> >> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
> >> @@ -1,4 +1,4 @@
> >> -/* SPDX-License-Identifier: GPL-2.0 */
> >> +/* SPDX-License-Identifier: GPL-2.0+ */
> >
> > While you are changing this line, I believe the correct format is
> > to use a '//' comment.
> >
> > i.e.:
> >
> > // SPDX-License-Identifier: GPL-2.0+
> 
> Not for C header files, only for C source files.

Wow!

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

[Simon Horman]

On Sun, May 20, 2018 at 10:24:37AM +0300, Laurent Pinchart wrote:
> All source files of the vsp1 driver are licensed under the GPLv2+ except
> for vsp1_regs.h which is licensed under GPLv2. This is caused by a bad
> copy that dates back from the initial version of the driver. Fix
> it.
> 
> Cc: Nobuhiro Iwamatsu 
> Acked-by: Kieran Bingham 
> Acked-by: Sergei Shtylyov
> Acked-by: Niklas Söderlund 
> Acked-by: Wolfram Sang 
> Signed-off-by: Laurent Pinchart 
> ---
> Iwamatsu-san,
> 
> While working on the VSP1 driver I noticed that all source files are
> licensed under the GPLv2+ except for vsp1_regs.h which is licensed under
> GPLv2. I'd like to fix this inconsistency. As you have contributed to
> that file, could you please provide your explicit ack if you agree to
> this change ?
> ---
>  drivers/media/platform/vsp1/vsp1_regs.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_regs.h 
> b/drivers/media/platform/vsp1/vsp1_regs.h
> index 0d249ff9f564..e82661216c1d 100644
> --- a/drivers/media/platform/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> +/* SPDX-License-Identifier: GPL-2.0+ */

While you are changing this line, I believe the correct format is
to use a '//' comment.

i.e.:

// SPDX-License-Identifier: GPL-2.0+

>  /*
>   * vsp1_regs.h  --  R-Car VSP1 Registers Definitions
>   *
> -- 
> Regards,
> 
> Laurent Pinchart
> 

Re: [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties

[Simon Horman]

On Thu, May 17, 2018 at 11:01:10AM +0200, jacopo mondi wrote:
> Hi Niklas,
> 
> On Thu, May 17, 2018 at 12:13:07AM +0200, Niklas Söderlund wrote:
> > Hi Jacopo,
> >
> > Thanks for your work.
> >
> > On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> > > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > > driver and only confuse users. Remove them in all Gen2 SoC that used
> > > them.
> > >
> > > Signed-off-by: Jacopo Mondi 
> > > ---
> > >  arch/arm/boot/dts/r8a7790-lager.dts   | 3 ---
> > >  arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> > >  arch/arm/boot/dts/r8a7791-porter.dts  | 1 -
> > >  arch/arm/boot/dts/r8a7793-gose.dts| 3 ---
> > >  arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> > >  arch/arm/boot/dts/r8a7794-silk.dts| 1 -
> > >  6 files changed, 12 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
> > > b/arch/arm/boot/dts/r8a7790-lager.dts
> > > index 063fdb6..b56b309 100644
> > > --- a/arch/arm/boot/dts/r8a7790-lager.dts
> > > +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> > > @@ -873,10 +873,8 @@
> > >   port {
> > >   vin0ep2: endpoint {
> > >   remote-endpoint = <_out>;
> > > - bus-width = <24>;
> >
> > I can't really make up my mind if this is a good thing or not. Device
> > tree describes the hardware and not what the drivers make use of. And
> > the fact is that this bus is 24 bits wide. So I'm not sure we should
> > remove these properties. But I would love to hear what others think
> > about this.
> >
> 
> Just to point out those properties are not even documented in rcar-vin
> bindings (actually, none of them was).
> 
> I feel it's wrong to have them here, as someone may think that
> changing their value should actually change the VIN interface behavior,
> which it's not true, leading to massive confusion and quite some code
> digging for no reason (and they will get mad at us at some point, probably :)

I think its fine that the driver doesn't implement something described in
DT - we are describing the hardware not the implementation. But I think its
not fine that DT includes properties not described in the binding.

So I think we should either
a) Fix the binding documentation, but perhaps it is already correct
   in which case we should;
b) Apply this patch

Once we have decided what is the correct description of the hardware we
can consider implications on the driver implementation.

Re: [PATCH v2 2/2] ARM: dts: r8a7740: Add CEU0

[Simon Horman]

On Wed, May 16, 2018 at 09:40:09AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
> 
> On Thu, Apr 26, 2018 at 8:24 PM, Jacopo Mondi  
> wrote:
> > Describe CEU0 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
> >
> > Reported-by: Geert Uytterhoeven 
> > Signed-off-by: Jacopo Mondi 
> 
> Thanks for your patch!
> 
> Reviewed-by: Geert Uytterhoeven 
> 
> Minor question below.
> 
> > --- a/arch/arm/boot/dts/r8a7740.dtsi
> > +++ b/arch/arm/boot/dts/r8a7740.dtsi
> > @@ -67,6 +67,16 @@
> > power-domains = <_d4>;
> > };
> >
> > +   ceu0: ceu@fe91 {
> > +   reg = <0xfe91 0x3000>;
> > +   compatible = "renesas,r8a7740-ceu";
> > +   interrupts = ;
> > +   clocks = <_clks R8A7740_CLK_CEU20>;
> > +   clock-names = "ceu20";
> 
> Why the "clock-names" property? It's not mentioned in the DT bindings, and
> may cause issues if the bindings are ever amended.

I have dropped that property for now.

> 
> > +   power-domains = <_a4r>;
> > +   status = "disabled";
> > +   };
> > +
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> 

Re: [PATCH v2 0/2] Fix potential buffer overrun root cause

[Simon Horman]

On Fri, May 11, 2018 at 04:41:24PM +0200, Niklas Söderlund wrote:
> Hi,
> 
> Commit 015060cb7795eac3 ("media: rcar-vin: enable field toggle after a
> set number of lines for Gen3") was an attempt to fix the issue of
> writing outside the capture buffer for VIN Gen3. Unfortunately it only
> fixed a symptom of a problem to such a degree I could no longer
> reproduce it.
> 
> Jacopo on the other hand working on a different setup still ran into the
> issue. And he even figured out the root cause of the issue. When I
> submitted the original VIN Gen3 support I had when addressing a review
> comment missed to keep the crop and compose dimensions in sync with the
> requested format resulting in the DMA engine not properly stopping
> before writing outside the buffer.
> 
> This series reverts the incorrect fix in 1/2 and applies a correct one
> in 2/2. I think this should be picked up for v4.18.
> 
> * Changes since v1
> - Add commit message to 1/2.
> 
> Niklas Söderlund (2):
>   Revert "media: rcar-vin: enable field toggle after a set number of
> lines for Gen3"
>   rcar-vin: fix crop and compose handling for Gen3

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

Re: [PATCH] media: dt-bindings: media: rcar_vin: add support for r8a77965

[Simon Horman]

On Sun, May 13, 2018 at 08:58:18PM +0200, Niklas Söderlund wrote:
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

[PATCH] media: rcar-vin: Drop unnecessary register properties from example vin port

[Simon Horman]

The example vin port node does not have an address and thus does not
need address-cells or address size-properties.

Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
---
 Documentation/devicetree/bindings/media/rcar_vin.txt | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index a19517e1c669..2a0c59e97f40 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -107,9 +107,6 @@ Board setup example for Gen2 platforms (vin1 composite 
video input)
 status = "okay";
 
 port {
-#address-cells = <1>;
-#size-cells = <0>;
-
 vin1ep0: endpoint {
 remote-endpoint = <>;
 bus-width = <8>;
-- 
2.11.0

Re: [PATCH v2 2/2] ARM: dts: r8a7740: Add CEU0

[Simon Horman]

On Thu, Apr 26, 2018 at 08:24:43PM +0200, Jacopo Mondi wrote:
> Describe CEU0 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
> 
> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Jacopo Mondi 

Thanks, applied.

Re: [PATCH v2 1/2] dt-bindings: media: renesas-ceu: Add R-Mobile R8A7740

[Simon Horman]

On Thu, Apr 26, 2018 at 08:24:42PM +0200, Jacopo Mondi wrote:
> Add R-Mobile A1 R8A7740 SoC to the list of compatible values for the CEU
> unit.
> 
> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

> ---
>  Documentation/devicetree/bindings/media/renesas,ceu.txt | 7 ---
>  drivers/media/platform/renesas-ceu.c| 1 +
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt 
> b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> index 3fc66df..8a7a616 100644
> --- a/Documentation/devicetree/bindings/media/renesas,ceu.txt
> +++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
> @@ -2,14 +2,15 @@ Renesas Capture Engine Unit (CEU)
>  --
>  
>  The Capture Engine Unit is the image capture interface found in the Renesas
> -SH Mobile and RZ SoCs.
> +SH Mobile, R-Mobile and RZ SoCs.
>  
>  The interface supports a single parallel input with data bus width of 8 or 16
>  bits.
>  
>  Required properties:
> -- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1H
> -  and RZ/A1M SoCs.
> +- compatible: Shall be one of the following values:
> + "renesas,r7s72100-ceu" for CEU units found in RZ/A1H and RZ/A1M SoCs
> + "renesas,r8a7740-ceu" for CEU units found in R-Mobile A1 R8A7740 SoCs

Nit: I think you can drop R8A7740 as I believe that by adding it to
R-Mobile A1 you have constructed a tautology (I mean "R-Mobile A1" =
"R8A7740" as far as I know).

>  - reg: Registers address base and size.
>  - interrupts: The interrupt specifier.
>  
> diff --git a/drivers/media/platform/renesas-ceu.c 
> b/drivers/media/platform/renesas-ceu.c
> index 6599dba..c964a56 100644
> --- a/drivers/media/platform/renesas-ceu.c
> +++ b/drivers/media/platform/renesas-ceu.c
> @@ -1545,6 +1545,7 @@ static const struct ceu_data ceu_data_sh4 = {
>  #if IS_ENABLED(CONFIG_OF)
>  static const struct of_device_id ceu_of_match[] = {
>   { .compatible = "renesas,r7s72100-ceu", .data = _data_rz },
> + { .compatible = "renesas,r8a7740-ceu", .data = _data_rz },
>   { }
>  };
>  MODULE_DEVICE_TABLE(of, ceu_of_match);
> -- 
> 2.7.4
> 

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

[Simon Horman]

On Thu, Apr 26, 2018 at 05:20:05PM +0200, Niklas Söderlund wrote:
> Hi Simon,
> 
> Thanks for your feedback.
> 
> On 2018-04-25 09:18:51 +0200, Simon Horman wrote:
> > On Wed, Apr 25, 2018 at 01:45:06AM +0200, Niklas Söderlund wrote:
> > > Store the group pointer before disassociating the VIN from the group.
> > > 
> > > Fixes: 3bb4c3bc85bf77a7 ("media: rcar-vin: add group allocator functions")
> > > Reported-by: Colin Ian King <colin.k...@canonical.com>
> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > > ---
> > >  drivers/media/platform/rcar-vin/rcar-core.c | 12 +++-
> > >  1 file changed, 7 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> > > b/drivers/media/platform/rcar-vin/rcar-core.c
> > > index 7bc2774a11232362..d3072e166a1ca24f 100644
> > > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > > @@ -338,19 +338,21 @@ static int rvin_group_get(struct rvin_dev *vin)
> > >  
> > >  static void rvin_group_put(struct rvin_dev *vin)
> > >  {
> > > - mutex_lock(>group->lock);
> > > + struct rvin_group *group = vin->group;
> > > +
> > > + mutex_lock(>lock);
> > 
> > Hi Niklas, its not clear to me why moving the lock is safe.
> > Could you explain the locking scheme a little?
> 
> The lock here protects the members of the group struct and not any of 
> the members of the vin struct. The intent of the rvin_group_put() 
> function is:
> 
> 1. Disassociate the vin struct from the group struct. This is done by 
>removing the pointer to the vin from the group->vin array and 
>removing the pointer from vin->group to the group struct. Here the 
>lock is needed to protect access to the group->vin array.
> 
> 2. Decrease the refcount of the struct group and if we are the last one 
>out release the group.
> 
> The problem with the original code is that I first disassociate group 
> from the vin 'vin->group = NULL' but still use the pointer stored in the 
> vin struct when I try to disassociate the vin from the group 
> 'vin->group->vin[vin->id]'.
> 
> AFIK can tell the locking here is fine, the problem was that I pulled 
> the rug from under my own feet in how I access the lock in order to not 
> having to declare a variable to store the pointer in ;-)
> 
> Do this explanation help put you at ease?

Thanks, I am completely relaxed now :)

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

> > >   vin->group = NULL;
> > >   vin->v4l2_dev.mdev = NULL;
> > >  
> > > - if (WARN_ON(vin->group->vin[vin->id] != vin))
> > > + if (WARN_ON(group->vin[vin->id] != vin))
> > >   goto out;
> > >  
> > > - vin->group->vin[vin->id] = NULL;
> > > + group->vin[vin->id] = NULL;
> > >  out:
> > > - mutex_unlock(>group->lock);
> > > + mutex_unlock(>lock);
> > >  
> > > - kref_put(>group->refcount, rvin_group_release);
> > > + kref_put(>refcount, rvin_group_release);
> > >  }
> > >  
> > >  /* 
> > > -
> > > -- 
> > > 2.17.0
> > > 
> 
> -- 
> Regards,
> Niklas Söderlund
> 

Re: [PATCH 2/2] ARM: dts: r8a7740: Enable CEU0

[Simon Horman]

On Thu, Apr 26, 2018 at 09:26:09AM +0200, jacopo mondi wrote:
> Hi Simon,
> 
> On Thu, Apr 26, 2018 at 08:11:30AM +0200, Simon Horman wrote:
> > Thanks Jacopo,
> >
> > I'm very pleased to see this series.
> 
> Credits to Geert that pointed out to me R-Mobile A1 comes with a CEU.
> I should mention him in next iteration actually, sorry about that.
> 
> >
> > On Wed, Apr 25, 2018 at 01:15:20PM +0200, Jacopo Mondi wrote:
> > > Enable CEU0 peripheral for Renesas R-Mobile A1 R8A7740.
> >
> > Given 'status = "disabled"' below I think you
> > are describing but not enabling CEU0. Also in the subject.
> 
> Right.
> 
> >
> > Should we also describe CEU1?
> 
> Armadillo board file only describe CEU0. If there are R-Mobile A1
> board files where I can steal informations from I can do that. If
> there's a public datasheet, that would be even better.

I have the datasheet, so perhaps I can add CEU1 after you have added CEU0.

> > > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> > > ---
> > >  arch/arm/boot/dts/r8a7740.dtsi | 10 ++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/r8a7740.dtsi 
> > > b/arch/arm/boot/dts/r8a7740.dtsi
> > > index afd3bc5..05ec41e 100644
> > > --- a/arch/arm/boot/dts/r8a7740.dtsi
> > > +++ b/arch/arm/boot/dts/r8a7740.dtsi
> > > @@ -67,6 +67,16 @@
> > >   power-domains = <_d4>;
> > >   };
> > >
> > > + ceu0: ceu@fe91 {
> > > + reg = <0xfe91 0x100>;
> >
> > Should the size of the range be 0x3000 ?
> > That would seem to match my reading of table 32.3
> > and also be consistent with r7s72100.dtsi.
> 
> I got this from
> 
> static struct resource ceu0_resources[] = {
>   [0] = {
>   .name   = "CEU",
>   .start  = 0xfe91,
>   .end= 0xfe91009f,
>   .flags  = IORESOURCE_MEM,
>   },
> but I also noticed the r7s72100 one was bigger.
> I'm fine enlarging this, if that's what the manual reports too.

I think that would be best.

> > > + compatible = "renesas,r8a7740-ceu";
> > > + interrupts = ;
> > > + clocks = <_clks R8A7740_CLK_CEU20>;
> > > + clock-names = "ceu20";
> > > + power-domains = <_a4mp>;
> >
> > My reading of table 1.7 is that the power domain should be A4R (_a4r).
> 
> Ah yes, my bad.
> 
> The long time goal would be describe the camera module (mt9t112) which
> is installed on armadillo. Unfortunately that would probably require
> some more work on the CEU side.

Thanks, understood.

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

[Simon Horman]

On Wed, Apr 25, 2018 at 01:43:21AM +0200, Niklas Söderlund wrote:
> The compatible string "renesas,rcar-gen3-vin" was added before the
> Gen3 driver code was added but it's not possible to use. Each SoC in the
> Gen3 series require SoC specific knowledge in the driver to function.
> Remove it before it is added to any device tree descriptions.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

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

Re: [PATCH 2/2] ARM: dts: r8a7740: Enable CEU0

[Simon Horman]

Thanks Jacopo,

I'm very pleased to see this series.

On Wed, Apr 25, 2018 at 01:15:20PM +0200, Jacopo Mondi wrote:
> Enable CEU0 peripheral for Renesas R-Mobile A1 R8A7740.

Given 'status = "disabled"' below I think you
are describing but not enabling CEU0. Also in the subject.

Should we also describe CEU1?

> 
> Signed-off-by: Jacopo Mondi 
> ---
>  arch/arm/boot/dts/r8a7740.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
> index afd3bc5..05ec41e 100644
> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -67,6 +67,16 @@
>   power-domains = <_d4>;
>   };
>  
> + ceu0: ceu@fe91 {
> + reg = <0xfe91 0x100>;

Should the size of the range be 0x3000 ?
That would seem to match my reading of table 32.3
and also be consistent with r7s72100.dtsi.

> + compatible = "renesas,r8a7740-ceu";
> + interrupts = ;
> + clocks = <_clks R8A7740_CLK_CEU20>;
> + clock-names = "ceu20";
> + power-domains = <_a4mp>;

My reading of table 1.7 is that the power domain should be A4R (_a4r).

> + status = "disabled";
> + };
> +
>   cmt1: timer@e6138000 {
>   compatible = "renesas,cmt-48-r8a7740", "renesas,cmt-48";
>   reg = <0xe6138000 0x170>;
> -- 
> 2.7.4
> 

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

[Simon Horman]

On Wed, Apr 25, 2018 at 01:45:06AM +0200, Niklas Söderlund wrote:
> Store the group pointer before disassociating the VIN from the group.
> 
> Fixes: 3bb4c3bc85bf77a7 ("media: rcar-vin: add group allocator functions")
> Reported-by: Colin Ian King 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 7bc2774a11232362..d3072e166a1ca24f 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -338,19 +338,21 @@ static int rvin_group_get(struct rvin_dev *vin)
>  
>  static void rvin_group_put(struct rvin_dev *vin)
>  {
> - mutex_lock(>group->lock);
> + struct rvin_group *group = vin->group;
> +
> + mutex_lock(>lock);

Hi Niklas, its not clear to me why moving the lock is safe.
Could you explain the locking scheme a little?

>  
>   vin->group = NULL;
>   vin->v4l2_dev.mdev = NULL;
>  
> - if (WARN_ON(vin->group->vin[vin->id] != vin))
> + if (WARN_ON(group->vin[vin->id] != vin))
>   goto out;
>  
> - vin->group->vin[vin->id] = NULL;
> + group->vin[vin->id] = NULL;
>  out:
> - mutex_unlock(>group->lock);
> + mutex_unlock(>lock);
>  
> - kref_put(>group->refcount, rvin_group_release);
> + kref_put(>refcount, rvin_group_release);
>  }
>  
>  /* 
> -
> -- 
> 2.17.0
> 

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

[Simon Horman]

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

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

From: Jacopo Mondi <jacopo+rene...@jmondi.org>
Subject: [PATCH] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

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

Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verk...@cisco.com>
[simon: rebased]
Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
---
 arch/arm/boot/dts/r7s72100.dtsi | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

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

Re: [PATCH 4/8] arm64: dts: renesas: eagle: Add thc63 LVDS map

[Simon Horman]

On Thu, Apr 19, 2018 at 11:31:05AM +0200, Jacopo Mondi wrote:
> Add LVDS map mode description property to THC63LVD1024 LVDS decoder in
> R-Car V3M-Eagle board device tree.
> 
> Signed-off-by: Jacopo Mondi 

Hi Jacopo,

it looks like there has been a request to change this binding.
So I have marked this as "Changes Requested". Please repost or otherwise
ping me if that turns out not to be the case.

> ---
>  arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts 
> b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> index ebfbb51..2609fa3 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> @@ -56,6 +56,7 @@
>   compatible = "thine,thc63lvd1024";
>  
>   vcc-supply = <>;
> + thine,map = <1>;
>  
>   ports {
>   #address-cells = <1>;
> -- 
> 2.7.4
> 

Re: [PATCH/RFC 7/8] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol

[Simon Horman]

On Fri, Apr 20, 2018 at 03:28:33PM +0200, Geert Uytterhoeven wrote:
> All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS
> platform dependencies.  Hence finish the conversion from ARCH_SHMOBILE
> to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit
> 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS").
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> This depends on the previous patches in this series, hence the RFC.

Thanks, I have marked this and the following patch as deferred.
Please repost or otherwise ping me once the dependencies are in place.

Re: [PATCH/RFC 7/8] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol

[Simon Horman]

On Fri, Apr 20, 2018 at 03:28:33PM +0200, Geert Uytterhoeven wrote:
> All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS
> platform dependencies.  Hence finish the conversion from ARCH_SHMOBILE
> to ARCH_RENESAS for Renesas 32-bit ARM SoCs, as started by commit
> 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS").
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> This depends on the previous patches in this series, hence the RFC.
> 
> JFTR, after this, the following symbols for drivers supporting only
> Renesas SuperH "SH-Mobile" SoCs can no longer be selected:
>   - CONFIG_KEYBOARD_SH_KEYSC,
>   - CONFIG_VIDEO_SH_VOU,
>   - CONFIG_VIDEO_SH_MOBILE_CEU,
>   - CONFIG_DRM_SHMOBILE[*],
>   - CONFIG_FB_SH_MOBILE_MERAM.
> (changes for a shmobile_defconfig .config)
> 
> [*] CONFIG_DRM_SHMOBILE has a dependency on ARM, but it was never wired
> up.  From the use of sh_mobile_meram, I guess it was meant for
> SH-Mobile AP4 on Mackerel or AP4EVB, which are long gone.
> So the only remaining upstream platforms that could make use of it
> are legacy SuperH SH-Mobile SoCs?

That sounds about right. If there is interest I can sift through my mail
archive and see if it yields any answers.

Re: [PATCH 6/8] ASoC: sh: Update menu title and platform dependency

[Simon Horman]

On Fri, Apr 20, 2018 at 03:28:32PM +0200, Geert Uytterhoeven wrote:
> Change the menu title to refer to "Renesas SoCs" instead of "SuperH", as
> both SuperH and ARM SoCs are supported.
> 
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is ARCH_RENESAS a more appropriate platform dependency for Renesas ARM
> SoCs than the legacy ARCH_SHMOBILE, hence use the former.
> Renesas SuperH SH-Mobile SoCs are still covered by the SUPERH
> dependency.
> 
> This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> future.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

Re: [PATCH 5/8] staging: emxx_udc: Change platform dependency to ARCH_RENESAS

[Simon Horman]

On Fri, Apr 20, 2018 at 03:28:31PM +0200, Geert Uytterhoeven wrote:
> Emma Mobile is a Renesas ARM SoC.  Since commit 9b5ba0df4ea4f940 ("ARM:
> shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate
> platform dependency than the legacy ARCH_SHMOBILE, hence use the
> former.
> 
> This will allow to drop ARCH_SHMOBILE on ARM in the near future.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

Re: [PATCH 4/8] sh_eth: Change platform check to CONFIG_ARCH_RENESAS

[Simon Horman]

On Fri, Apr 20, 2018 at 03:28:30PM +0200, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
> 
> Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
> check.
> 
> This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> future.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

Re: [PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS

[Simon Horman]

On Fri, Apr 20, 2018 at 03:28:29PM +0200, Geert Uytterhoeven wrote:
> The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
> only.  Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
> ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
> than the legacy ARCH_SHMOBILE, hence use the former.
> 
> This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> future.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

Re: [PATCH 2/8] dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS

[Simon Horman]

On Fri, Apr 20, 2018 at 03:28:28PM +0200, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
> 
> Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
> check, just like before support for Renesas ARM SoCs was added.
> 
> Instead of blindly changing all the #ifdefs, switch the main code block
> in sh_dmae_probe() to IS_ENABLED(), as this allows to remove all the
> remaining #ifdefs.
> 
> This will allow to drop ARCH_SHMOBILE on ARM in the near future.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

Re: [PATCH 1/8] arm: shmobile: Change platform dependency to ARCH_RENESAS

[Simon Horman]

On Fri, Apr 20, 2018 at 05:53:18PM +0300, Sergei Shtylyov wrote:
> On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote:
> 
> > Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> > is ARCH_RENESAS a more appropriate platform dependency than the legacy
> 
>"ARCH_RENESAS is", no?

Thanks, applied with that corrected.

> 
> > ARCH_SHMOBILE, hence use the former.
> > 
> > This will allow to drop ARCH_SHMOBILE on ARM in the near future.
> > 
> > Signed-off-by: Geert Uytterhoeven 
> [...]
> 
> MBR, Sergei
> 

Re: [PATCH] media: entity: fix spelling for media_entity_get_fwnode_pad()

[Simon Horman]

On Sun, Apr 08, 2018 at 06:11:52PM +0200, Niklas Söderlund wrote:
> From: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> 
> s/dose/does/
> 
> Fixes: d295c6a460cd2ac6 ("[media] media: entity: Add 
> media_entity_get_fwnode_pad() function")
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

Re: [PATCH v6] ARM: dts: wheat: Fix ADV7513 address usage

[Simon Horman]

On Mon, Mar 26, 2018 at 10:04:24AM +0100, Kieran Bingham wrote:
> Hi Simon,
> 
> On 26/03/18 09:31, Simon Horman wrote:
> > On Fri, Mar 23, 2018 at 09:16:13PM +, Kieran Bingham wrote:
> >> Hi Simon,
> >>
> >> On 23/03/18 08:51, Simon Horman wrote:
> >>> On Thu, Mar 22, 2018 at 09:30:40PM +, Kieran Bingham wrote:
> >>>> 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.
> >>>
> >>> Hi Kierean,
> >>>
> >>> as this is a fix
> >>> a) Does it warrant a fixes tag?
> >>>Fixes: f6eea82a87db ("ARM: dts: wheat: add DU support")
> >>> b) Does it warrant being posted as a fix for v4.16;
> >>> c) or v4.17?
> >>
> >> Tricky one, yes it could but this DTS fix, will only actually 'fix' the 
> >> issue if
> >> the corresponding driver updates to allow secondary addresses to be parsed 
> >> are
> >> also backported.
> >>
> >> It should be safe to back port the dts fix without the driver updates, but 
> >> the
> >> addresses specified by this patch will simply be ignored.
> > 
> > In that case I think its safe to add the fixes tag and take the DTS patch
> > via the renesas tree. Perhaps applying it for v4.18 and allowing automatic
> > backporting to take its course is the cleanest option.
> > 
> >> Thus if this is marked with the fixes tag the corresponding patch "drm: 
> >> adv7511:
> >> Add support for i2c_new_secondary_device" should also be marked.
> >>
> >> It looks like that patch has yet to be picked up by the DRM subsystem, so 
> >> how
> >> about I bundle both of these two patches together in a repost along with 
> >> the
> >> fixes tag.
> >>
> >> In fact, I don't think the ADV7511 dt-bindings update has made any progress
> >> either. (dt-bindings: adv7511: Extend bindings to allow specifying slave 
> >> map
> >> addresses). The media tree variants for the adv7604 have already been 
> >> picked up
> >> by Mauro I believe though.
> >>
> >> I presume it would be acceptable for this dts patch (or rather all three 
> >> patches
> >> mentioned) to get integrated through the DRM tree ?
> > 
> > Unless there is a strong reason I would prefer the dts patch to go via
> > my tree. The reason is to avoid merge conflicts bubbling up to Linus,
> > which really is something best avoided.
> 
> That's perfectly fine with me.
> 
> Feel free to add:
> 
> Fixes: f6eea82a87db ("ARM: dts: wheat: add DU support")
> 
> as you suggested when you apply, or alternatively let me know if you need a 
> repost.

Thanks, applied for v4.18 with the fixes tag.

Re: [PATCH v6] ARM: dts: wheat: Fix ADV7513 address usage

[Simon Horman]

On Fri, Mar 23, 2018 at 09:16:13PM +, Kieran Bingham wrote:
> Hi Simon,
> 
> On 23/03/18 08:51, Simon Horman wrote:
> > On Thu, Mar 22, 2018 at 09:30:40PM +, Kieran Bingham wrote:
> >> 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.
> > 
> > Hi Kierean,
> > 
> > as this is a fix
> > a) Does it warrant a fixes tag?
> >Fixes: f6eea82a87db ("ARM: dts: wheat: add DU support")
> > b) Does it warrant being posted as a fix for v4.16;
> > c) or v4.17?
> 
> Tricky one, yes it could but this DTS fix, will only actually 'fix' the issue 
> if
> the corresponding driver updates to allow secondary addresses to be parsed are
> also backported.
> 
> It should be safe to back port the dts fix without the driver updates, but the
> addresses specified by this patch will simply be ignored.

In that case I think its safe to add the fixes tag and take the DTS patch
via the renesas tree. Perhaps applying it for v4.18 and allowing automatic
backporting to take its course is the cleanest option.

> Thus if this is marked with the fixes tag the corresponding patch "drm: 
> adv7511:
> Add support for i2c_new_secondary_device" should also be marked.
> 
> It looks like that patch has yet to be picked up by the DRM subsystem, so how
> about I bundle both of these two patches together in a repost along with the
> fixes tag.
> 
> In fact, I don't think the ADV7511 dt-bindings update has made any progress
> either. (dt-bindings: adv7511: Extend bindings to allow specifying slave map
> addresses). The media tree variants for the adv7604 have already been picked 
> up
> by Mauro I believe though.
> 
> I presume it would be acceptable for this dts patch (or rather all three 
> patches
> mentioned) to get integrated through the DRM tree ?

Unless there is a strong reason I would prefer the dts patch to go via
my tree. The reason is to avoid merge conflicts bubbling up to Linus,
which really is something best avoided.

Re: [PATCH v6] ARM: dts: wheat: Fix ADV7513 address usage

[Simon Horman]

On Thu, Mar 22, 2018 at 09:30:40PM +, Kieran Bingham wrote:
> 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.

Hi Kierean,

as this is a fix
a) Does it warrant a fixes tag?
   Fixes: f6eea82a87db ("ARM: dts: wheat: add DU support")
b) Does it warrant being posted as a fix for v4.16;
c) or v4.17?

Re: [PATCH] dt-bindings: media: rcar_vin: Use status "okay"

[Simon Horman]

On Sun, Mar 18, 2018 at 07:47:57AM -0500, Rob Herring wrote:
> On Fri, Mar 09, 2018 at 10:34:40AM +0100, Geert Uytterhoeven wrote:
> > According to the Devicetree Specification, "ok" is not a valid status.
> 
> Correct.
> 
> > Fixes: 47c71bd61b772cd7 ("[media] rcar_vin: add devicetree support")
> > Signed-off-by: Geert Uytterhoeven 
> > ---
> > For the checkpatch TODO list?
> > https://www.devicetree.org/
> > 
> >  Documentation/devicetree/bindings/media/rcar_vin.txt | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> > b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > index 68c5c497b7fa5551..a19517e1c669eb35 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -81,7 +81,7 @@ Board setup example for Gen2 platforms (vin1 composite 
> > video input)
> >  ---
> >  
> > {
> > -status = "ok";
> > +status = "okay";
> 
> However, I prefer that status not be in examples as it applies to any 
> node and the SoC/board split is not relevant to binding docs. I'd 
> cleaned all these up except for the cases with SoC/board split.

Hi Rob,

I'm a little confused. This example is a board override for
a node (implicitly) defined in the DT of an SoC. Could you clarify
when the status should be omitted?

> 
> >  pinctrl-0 = <_pins>;
> >  pinctrl-names = "default";
> >  
> > @@ -104,7 +104,7 @@ Board setup example for Gen2 platforms (vin1 composite 
> > video input)
> >  pinctrl-0 = <_pins>;
> >  pinctrl-names = "default";
> >  
> > -status = "ok";
> > +status = "okay";
> >  
> >  port {
> >  #address-cells = <1>;
> > -- 
> > 2.7.4
> > 
> 

Re: [PATCH] media: platform: Drop OF dependency of VIDEO_RENESAS_VSP1

[Simon Horman]

On Tue, Mar 06, 2018 at 01:37:38PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 06 Mar 2018 18:35:32 +0200
> Laurent Pinchart  escreveu:
> 
> > Hi Mauro,
> > 
> > On Tuesday, 6 March 2018 18:25:15 EET Mauro Carvalho Chehab wrote:
> > > Em Mon, 26 Feb 2018 19:09:10 +0100 Geert Uytterhoeven escreveu:  
> > > > VIDEO_RENESAS_VSP1 depends on ARCH_RENESAS && OF.
> > > > As ARCH_RENESAS implies OF, the latter can be dropped.
> > > > 
> > > > Signed-off-by: Geert Uytterhoeven 
> > > > ---
> > > > 
> > > >  drivers/media/platform/Kconfig | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/media/platform/Kconfig
> > > > b/drivers/media/platform/Kconfig index 
> > > > 614fbef08ddcabb0..2b8b1ad0edd9eb31
> > > > 100644
> > > > --- a/drivers/media/platform/Kconfig
> > > > +++ b/drivers/media/platform/Kconfig
> > > > @@ -448,7 +448,7 @@ config VIDEO_RENESAS_FCP
> > > > 
> > > >  config VIDEO_RENESAS_VSP1
> > > >  
> > > > tristate "Renesas VSP1 Video Processing Engine"
> > > > depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
> > > > 
> > > > -   depends on (ARCH_RENESAS && OF) || COMPILE_TEST
> > > > +   depends on ARCH_RENESAS || COMPILE_TEST  
> > > 
> > > That is not correct!
> > > 
> > > COMPILE_TEST doesn't depend on OF. With this patch, it will likely
> > > cause build failures with randconfigs.  
> > 
> > ARCH_RENESAS implies OF, so replacing (ARCH_RENESAS && OF) with 
> > ARCH_RENESAS 
> > doesn't change anything. The driver can be compiled with COMPILE_TEST and 
> > !OF 
> > both before and after this patch.

FWIIW, I think this is a useful cleanup.

> OK!
> > 
> > > > depends on (!ARM64 && !VIDEO_RENESAS_FCP) || VIDEO_RENESAS_FCP
> > > > select VIDEOBUF2_DMA_CONTIG
> > > > select VIDEOBUF2_VMALLOC  
> > 
> 
> 
> 
> Thanks,
> Mauro
> 

Re: [PATCH] media: renesas-ceu: mark PM functions as __maybe_unused

[Simon Horman]

On Thu, Mar 01, 2018 at 12:19:37AM +0100, Arnd Bergmann wrote:
> The PM runtime operations are unused when CONFIG_PM is disabled,
> leading to a harmless warning:
> 
> drivers/media/platform/renesas-ceu.c:1003:12: error: 'ceu_runtime_suspend' 
> defined but not used [-Werror=unused-function]
>  static int ceu_runtime_suspend(struct device *dev)
> ^~~
> drivers/media/platform/renesas-ceu.c:987:12: error: 'ceu_runtime_resume' 
> defined but not used [-Werror=unused-function]
>  static int ceu_runtime_resume(struct device *dev)
> ^~
> 
> This adds a __maybe_unused annotation to shut up the warning.
> 
> Fixes: 32e5a70dc8f4 ("media: platform: Add Renesas CEU driver")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

Re: [PATCH] media: platform: Drop OF dependency of VIDEO_RENESAS_VSP1

[Simon Horman]

On Mon, Feb 26, 2018 at 07:09:10PM +0100, Geert Uytterhoeven wrote:
> VIDEO_RENESAS_VSP1 depends on ARCH_RENESAS && OF.
> As ARCH_RENESAS implies OF, the latter can be dropped.
> 
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>

My reasoning is that ARCH_RENESAS depends on ARCH_MULTI_V7,
which in turn depends on ARCH_MULTIPLATFORM which selects OF via USE_OF

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

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

[Simon Horman]

On Thu, Feb 22, 2018 at 11:37:20AM +0100, Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Hans Verkuil 

I have marked this patch as deferred as it depends on the binding for
"renesas,r7s72100-ceu".  Please repost or otherwise ping me once that
dependency has been accepted.

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

[Simon Horman]

On Wed, Feb 21, 2018 at 06:47:58PM +0100, Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Hans Verkuil 

This patch depends on the binding for "renesas,r7s72100-ceu".
Please repost or otherwise ping me once that dependency has been accepted.

Re: [PATCH v4 1/9] dt-bindings: media: Add Renesas CEU bindings

[Simon Horman]

On Fri, Jan 12, 2018 at 12:50:41AM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
> 
> Thank you for the patch.
> 
> On Tuesday, 9 January 2018 18:25:23 EET Jacopo Mondi wrote:
> > Add bindings documentation for Renesas Capture Engine Unit (CEU).
> > 
> > Signed-off-by: Jacopo Mondi 
> 
> Reviewed-by: Laurent Pinchart 

Hi,

I see that these bindings have now been reviewed. What is their (likely)
path to upstream from here? I'd like to accept the related DTS changes
once there is a clear path for the bindings to land in upstream.

Re: [PATCH v3 4/9] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

[Simon Horman]

On Thu, Jan 04, 2018 at 05:03:12PM +0100, Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Laurent Pinchart 

This looks good to me. Please ping me once the bindings, which I assume are
the only dependency, are Acked or accepted.

Re: [PATCH v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list

[Simon Horman]

On Thu, Nov 16, 2017 at 06:22:48PM +, Fabrizio Castro wrote:
> Change the sorting of the part numbers from descending to ascending to
> match with other documentation.
> 
> Signed-off-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com>
> Reviewed-by: Biju Das <biju@bp.renesas.com>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

Re: [PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

[Simon Horman]

On Thu, Nov 16, 2017 at 06:22:49PM +, Fabrizio Castro wrote:
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
> 
> Signed-off-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com>
> Reviewed-by: Biju Das <biju....@bp.renesas.com>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

Re: [PATCH v2 1/4] dt-bindings: media: rcar_vin: Reverse SoC part number list

[Simon Horman]

On Thu, Nov 16, 2017 at 06:22:48PM +, Fabrizio Castro wrote:
> Change the sorting of the part numbers from descending to ascending to
> match with other documentation.
> 
> Signed-off-by: Fabrizio Castro <fabrizio.cas...@bp.renesas.com>
> Reviewed-by: Biju Das <biju@bp.renesas.com>

Reviewed-by: Simon Horman <horms+rene...@verge.net.au>

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

[Simon Horman]

On Wed, Nov 15, 2017 at 11:55:57AM +0100, Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.

Other patches in this series (which are not for my tree) appear
to warrant updating. Accordingly I am marking this patch as
"Changes Requested" and am expecting it to be reposted at some point.

Re: [PATCH 20/20] arm64: dts: renesas: salvator: use VC1 for CVBS

[Simon Horman]

On Wed, Aug 30, 2017 at 10:08:24AM +0200, Niklas Söderlund wrote:
> Hi Simon,
> 
> On 2017-08-30 09:36:37 +0200, Simon Horman wrote:
> > On Fri, Aug 11, 2017 at 11:57:03AM +0200, Niklas Söderlund wrote:
> > > In order to test Virtual Channels use VC1 for CVBS input from the
> > > adv748x.
> > > 
> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > > ---
> > >  arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
> > > b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > index 7b67efcb1d22090a..8047fe1df065d63b 100644
> > > --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> > > @@ -41,7 +41,7 @@
> > >   };
> > >  
> > >   chosen {
> > > - bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
> > > + bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp 
> > > adv748x.txbvc=1";
> > >   stdout-path = "serial0:115200n8";
> > >   };
> > 
> > Hi Niklas,
> > 
> > I'm somewhat surprised to see what appears to be a new module parameter.
> > I'm not going to reject this but did you give consideration to doing this
> > another way?
> 
> This is my fault when sending this series out it should be marked as RFC 
> as it's stated in the cover-letter. This new module parameter is not 
> intended to be unstreamed, not even the driver parts. It's only usage is 
> to be able to easy test the multiplexed media pad using the onboard 
> Salvator-X components.
> 
> > 
> > In any case I have marked this as "Deferred" pending acceptance of the
> > driver change. If you think it can go in now then I'm open to discussion.
> 
> You can mark it as rejected and forget about it :-)

Thanks for the clarification, I marked it as RFC :)

Re: [PATCH v1.5 0/6] R-Car DU: Fix IOMMU operation when connected to VSP

[Simon Horman]

On Fri, Dec 09, 2016 at 01:35:06PM +0100, Ulrich Hecht wrote:
> Hi!
> 
> This is a slightly updated version of Laurent's series that adds the fix
> suggested by Magnus Damm and connects the FCP devices on M3-W to their
> IPMMU. It also drops the patches that have already been picked up in the
> media tree.
> 
> With this series and an assortment of patches from the renesas-drivers tree (
> iommu/ipmmu-vmsa: Remove platform data handling
> iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context
> iommu/ipmmu-vmsa: Break out utlb parsing code
> iommu/ipmmu-vmsa: Break out domain allocation code
> iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops
> iommu/ipmmu-vmsa: ARM and ARM64 archdata access
> iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency
> iommu/ipmmu-vmsa: Introduce features, break out alias
> iommu/ipmmu-vmsa: Add optional root device feature
> iommu/ipmmu-vmsa: Enable multi context support
> iommu/ipmmu-vmsa: Reuse iommu groups
> iommu/ipmmu-vmsa: Make use of IOMMU_OF_DECLARE()
> iommu/ipmmu-vmsa: Teach xlate() to skip disabled iommus
> iommu/ipmmu-vmsa: IPMMU device is 64-bit bus master
> iommu/ipmmu-vmsa: Write IMCTR twice
> iommu/ipmmu-vmsa: Make IMBUSCTR setup optional
> iommu/ipmmu-vmsa: Allow two bit SL0
> iommu/ipmmu-vmsa: Hook up r8a7795 DT matching code
> iommu/ipmmu-vmsa: Add r8a7796 DT binding
> iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
> iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
> arm64: dts: r8a7795: Add IPMMU device nodes
> arm64: dts: r8a7795: Hook up SYS-DMAC to IPMMU
> arm64: dts: r8a7795: Point FCP devices to IPMMU
> arm64: dts: r8a7795: Connect Ethernet AVB to IPMMU
> arm64: dts: r8a7796: Add IPMMU device nodes
> clk: renesas: r8a7796: Add FCP clocks
> clk: renesas: r8a7796: Add VSP clocks
> clk: renesas: r8a7796: Add DU and LVDS clocks
> drm: rcar-du: Add R8A7796 device support
> arm64: dts: renesas: r8a7795: Remove FCP SoC-specific compatible strings
> arm64: dts: renesas: r8a7796: Add FCPF and FCPV instances
> arm64: dts: renesas: r8a7796: Add VSP instances
> arm64: dts: renesas: r8a7796: Add DU device to DT
> arm64: dts: renesas: r8a7796-salvator-x: Enable DU
> ), I can enable IPMMU on both the H3 and M3-W Salvator-X boards with no ill
> effects on the results of the vsp-tests suite.
> 
> CU
> Uli
> 
> 
> Laurent Pinchart (4):
>   v4l: rcar-fcp: Don't get/put module reference
>   v4l: rcar-fcp: Add an API to retrieve the FCP device
>   v4l: vsp1: Add API to map and unmap DRM buffers through the VSP
>   drm: rcar-du: Map memory through the VSP device
> 
> Ulrich Hecht (2):
>   v4l: vsp1: Provide display list and VB2 queue with FCP device
>   arm64: dts: r8a7796: Connect FCP devices to IPMMU

Hi Ulrich,

I am wondering what the status of this work is.

Re: [PATCH 20/20] arm64: dts: renesas: salvator: use VC1 for CVBS

[Simon Horman]

On Fri, Aug 11, 2017 at 11:57:03AM +0200, Niklas Söderlund wrote:
> In order to test Virtual Channels use VC1 for CVBS input from the
> adv748x.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
> b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> index 7b67efcb1d22090a..8047fe1df065d63b 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -41,7 +41,7 @@
>   };
>  
>   chosen {
> - bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
> + bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp 
> adv748x.txbvc=1";
>   stdout-path = "serial0:115200n8";
>   };

Hi Niklas,

I'm somewhat surprised to see what appears to be a new module parameter.
I'm not going to reject this but did you give consideration to doing this
another way?

In any case I have marked this as "Deferred" pending acceptance of the
driver change. If you think it can go in now then I'm open to discussion.

Re: [PATCH 3/4] arm: dts: renesas: add cec clock for Koelsch board

[Simon Horman]

On Mon, Aug 14, 2017 at 05:34:41PM +0200, Geert Uytterhoeven wrote:
> On Sun, Jul 30, 2017 at 3:07 PM, Hans Verkuil  wrote:
> > From: Hans Verkuil 
> 
> Probably the one-line summary should be
> 
> ARM: dts: koelsch: Add CEC clock  for HDMI transmitter
> 
> > The adv7511 on the Koelsch board has a 12 MHz fixed clock
> > for the CEC block. Specify this in the dts to enable CEC support.
> >
> > Signed-off-by: Hans Verkuil 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, I have applied this patch with the updated one-line summary.

Re: [PATCH v4 2/2] arm64: dts: renesas: salvator-x: Add ADV7482 support

[Simon Horman]

On Tue, Jun 13, 2017 at 01:35:08AM +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> Provide ADV7482, and the needed connectors
> 
> Signed-off-by: Kieran Bingham 

I am marking this as deferred pending acceptance of the bindings.

Re: [PATCH v3 0/4] r8a7793 Gose video input support

[Simon Horman]

On Fri, May 26, 2017 at 08:49:07AM +0200, Simon Horman wrote:
> On Fri, May 19, 2017 at 03:07:00PM +0200, Ulrich Hecht wrote:
> > Hi!
> > 
> > This is a by-the-datasheet implementation of analog and digital video input
> > on the Gose board.
> > 
> > This revision adds new bindings that distinguish between ADV7180 variants
> > with three and six input ports. There are numerous variants of this chip,
> > but since all that have "CP" in their names have three inputs, and all that
> > have "ST" have six, I have limited myself to two new compatible strings,
> > "adv7180cp" and "adv7180st".
> > 
> > The digital input patch has received minor tweaks of the port names for
> > consistency, and the Gose analog input patch has been modified to use the
> > new bindings, and a composite video connector has been added.
> > 
> > CU
> > Uli
> > 
> > 
> > Changes since v2:
> > - hdmi: port hdmi_con renamed to hdmi_con_out
> > - adv7180: added new compatibility strings and bindings
> > - composite: added connector, use new bindings
> > 
> > Changes since v1:
> > - r8a7793.dtsi: added VIN2
> > - modeled HDMI decoder input/output and connector
> > - added "renesas,rcar-gen2-vin" compat strings
> > - removed unnecessary "remote" node and aliases
> > - set ADV7612 interrupt to GP4_2
> > 
> > 
> > Ulrich Hecht (4):
> >   ARM: dts: gose: add HDMI input
> 
> I have queued-up the above patch for v4.13.
> 
> >   media: adv7180: add adv7180cp, adv7180st compatible strings
> >   media: adv7180: Add adv7180cp, adv7180st bindings
> >   ARM: dts: gose: add composite video input
> 
> I have marked the above dts patch as "deferred" pending acceptance
> of the binding. Please repost or otherwise ping me once that has happened.

It looks like Hans will pick up the driver patches.
Accordingly I have queued-up the last dts patch above.

Re: [PATCH v3 0/4] r8a7793 Gose video input support

[Simon Horman]

On Mon, May 29, 2017 at 11:08:12AM +0200, Hans Verkuil wrote:
> On 05/19/2017 03:07 PM, Ulrich Hecht wrote:
> >Hi!
> >
> >This is a by-the-datasheet implementation of analog and digital video input
> >on the Gose board.
> >
> >This revision adds new bindings that distinguish between ADV7180 variants
> >with three and six input ports. There are numerous variants of this chip,
> >but since all that have "CP" in their names have three inputs, and all that
> >have "ST" have six, I have limited myself to two new compatible strings,
> >"adv7180cp" and "adv7180st".
> >
> >The digital input patch has received minor tweaks of the port names for
> >consistency, and the Gose analog input patch has been modified to use the
> >new bindings, and a composite video connector has been added.
> 
> Looks good. I assume the dts changes go through 
> linux-renesas-...@vger.kernel.org?

Yes, I will pick up the dts changes.

> I'll pick up the adv7180 changes.

Thanks!

Re: [PATCH v3 0/4] r8a7793 Gose video input support

[Simon Horman]

On Fri, May 19, 2017 at 03:07:00PM +0200, Ulrich Hecht wrote:
> Hi!
> 
> This is a by-the-datasheet implementation of analog and digital video input
> on the Gose board.
> 
> This revision adds new bindings that distinguish between ADV7180 variants
> with three and six input ports. There are numerous variants of this chip,
> but since all that have "CP" in their names have three inputs, and all that
> have "ST" have six, I have limited myself to two new compatible strings,
> "adv7180cp" and "adv7180st".
> 
> The digital input patch has received minor tweaks of the port names for
> consistency, and the Gose analog input patch has been modified to use the
> new bindings, and a composite video connector has been added.
> 
> CU
> Uli
> 
> 
> Changes since v2:
> - hdmi: port hdmi_con renamed to hdmi_con_out
> - adv7180: added new compatibility strings and bindings
> - composite: added connector, use new bindings
> 
> Changes since v1:
> - r8a7793.dtsi: added VIN2
> - modeled HDMI decoder input/output and connector
> - added "renesas,rcar-gen2-vin" compat strings
> - removed unnecessary "remote" node and aliases
> - set ADV7612 interrupt to GP4_2
> 
> 
> Ulrich Hecht (4):
>   ARM: dts: gose: add HDMI input

I have queued-up the above patch for v4.13.

>   media: adv7180: add adv7180cp, adv7180st compatible strings
>   media: adv7180: Add adv7180cp, adv7180st bindings
>   ARM: dts: gose: add composite video input

I have marked the above dts patch as "deferred" pending acceptance
of the binding. Please repost or otherwise ping me once that has happened.

>  .../devicetree/bindings/media/i2c/adv7180.txt  |  15 +++
>  arch/arm/boot/dts/r8a7793-gose.dts | 127 
> -
>  drivers/media/i2c/adv7180.c|   2 +
>  3 files changed, 142 insertions(+), 2 deletions(-)
> 
> -- 
> 2.7.4
> 

Re: [PATCH 0/5] RFC: ADV748x HDMI/Analog video receiver

[Simon Horman]

On Fri, Apr 28, 2017 at 09:47:05AM +0100, Kieran Bingham wrote:
> Hi Simon,
> 
> On 28/04/17 08:09, Simon Horman wrote:
> > On Thu, Apr 27, 2017 at 07:25:59PM +0100, Kieran Bingham wrote:
> >> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> >>
> >> This is an RFC for the Analog Devices ADV748x driver, and follows on from a
> >> previous posting by Niklas Söderlund [0] of an earlier incarnation of this
> >> driver.
> > 
> > ...
> > 
> >> This series presents the following patches:
> >>
> >>  [PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous
> >>  [PATCH 2/5] rcar-vin: Match sources against ports if specified.
> >>  [PATCH 3/5] media: i2c: adv748x: add adv748x driver
> >>  [PATCH 4/5] arm64: dts: r8a7795: salvator-x: enable VIN, CSI and ADV7482
> >>  [PATCH 5/5] arm64: dts: r8a7796: salvator-x: enable VIN, CSI and ADV7482
> > 
> > I am marking the above dts patches as "RFC" and do not plan to apply them
> > unless you ping me or repost them.
> 
> Yes, sorry - the whole series was supposed to be marked as RFC, but I didn't
> think about it - and apparently only applied the tag to the cover letter.
> 
> Apologies for any confusion.

It was clear enough, though an tag RFC in every patch would be better.
In any case I was referring to how I have handled these patches in
patchwork.

Apologies for any confusion.

> > Assuming they don't cause any
> > regressions I would be happy to consider applying them as soon as their
> > dependencies are accepted.
> 
> Does that mean you've done a cursory glance over the content ? :-)

Yes, I did take a quick glance.

> In this instance, the port numbers need to revert back to a zero-base,
> but I would appreciate an eye on how and where I've put the
> representation of the physical hdmi/cvbs connectors. Having modified
> plenty of DT, but not actually submitted much - I still feel 'new' at it
> - so I'm sure I may not have followed the standards quite right yet.

Assuming you are talking about where in the DT file the hdmi and cvbs nodes
should go, I think this is somewhat arbitrary so long as they are within
the top-level node - what you have looks good to me.

> The dts patches are based heavily on the previous posting by Niklas, but I 
> have
> extended to put the extra hdmi and cvbs links in.
> 
> Regards
> --
> Kieran
> 

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

[Simon Horman]

On Fri, Apr 28, 2017 at 11:40:20AM +0300, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Friday 28 Apr 2017 07:16:24 Simon Horman wrote:
> > On Wed, Apr 26, 2017 at 06:56:06PM +0300, Laurent Pinchart wrote:
> > > On Tuesday 21 Feb 2017 01:42:15 Laurent Pinchart wrote:
> > >> On Thursday 20 Oct 2016 10:49:11 Simon Horman wrote:
> > >>> On Tue, Oct 18, 2016 at 05:02:20PM +0200, Ulrich Hecht wrote:
> > >>>> Hi!
> > >>>> 
> > >>>> This is a by-the-datasheet implementation of analog and digital video
> > >>>> input on the Gose board.
> > >>>> 
> > >>>> I have tried to address all concerns raised by reviewers, with the
> > >>>> exception of the composite input patch, which has been left as is for
> > >>>> now.
> > >>>> 
> > >>>> CU
> > >>>> Uli
> > >>>> 
> > >>>> 
> > >>>> Changes since v1:
> > >>>> - r8a7793.dtsi: added VIN2
> > >>>> - modeled HDMI decoder input/output and connector
> > >>>> - added "renesas,rcar-gen2-vin" compat strings
> > >>>> - removed unnecessary "remote" node and aliases
> > >>>> - set ADV7612 interrupt to GP4_2
> > >>>> 
> > >>>> Ulrich Hecht (3):
> > >>>>   ARM: dts: r8a7793: Enable VIN0-VIN2
> > >>> 
> > >>> I have queued up the above patch with Laurent and Geert's tags.
> > >>> 
> > >>>>   ARM: dts: gose: add HDMI input
> > >>>>   ARM: dts: gose: add composite video input
> > >>> 
> > >>> Please address the review of the above two patches and repost.
> > >> 
> > >> Could you please do so ? Feedback on 2/3 should be easy to handle. For
> > >> 3/3, you might need to ping the DT maintainers.
> > > 
> > > Ping. These are the only two patches that block
> > > 
> > > VIN,v4.12,public,ulrich,Gen2 VIN integration
> > 
> > Sorry, I'm unsure how these slipped through the cracks.
> > I now have them queued up locally for v4.13 and I plan to push this morning.
> 
> Please don't, the ping was for Ulrich, he needs to address review comments on 
> patches 2/3 and 3/3.

Oh, sorry. I will dequeue them.

Re: [PATCH 0/5] RFC: ADV748x HDMI/Analog video receiver

[Simon Horman]

On Thu, Apr 27, 2017 at 07:25:59PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> This is an RFC for the Analog Devices ADV748x driver, and follows on from a
> previous posting by Niklas Söderlund [0] of an earlier incarnation of this
> driver.

...

> This series presents the following patches:
> 
>  [PATCH 1/5] v4l2-subdev: Provide a port mapping for asynchronous
>  [PATCH 2/5] rcar-vin: Match sources against ports if specified.
>  [PATCH 3/5] media: i2c: adv748x: add adv748x driver
>  [PATCH 4/5] arm64: dts: r8a7795: salvator-x: enable VIN, CSI and ADV7482
>  [PATCH 5/5] arm64: dts: r8a7796: salvator-x: enable VIN, CSI and ADV7482

I am marking the above dts patches as "RFC" and do not plan to apply them
unless you ping me or repost them. Assuming they don't cause any
regressions I would be happy to consider applying them as soon as their
dependencies are accepted.

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

[Simon Horman]

On Wed, Apr 26, 2017 at 06:56:06PM +0300, Laurent Pinchart wrote:
> Hi Ulrich,
> 
> On Tuesday 21 Feb 2017 01:42:15 Laurent Pinchart wrote:
> > On Thursday 20 Oct 2016 10:49:11 Simon Horman wrote:
> > > On Tue, Oct 18, 2016 at 05:02:20PM +0200, Ulrich Hecht wrote:
> > >> Hi!
> > >> 
> > >> This is a by-the-datasheet implementation of analog and digital video
> > >> input on the Gose board.
> > >> 
> > >> I have tried to address all concerns raised by reviewers, with the
> > >> exception of the composite input patch, which has been left as is for
> > >> now.
> > >> 
> > >> CU
> > >> Uli
> > >> 
> > >> 
> > >> Changes since v1:
> > >> - r8a7793.dtsi: added VIN2
> > >> - modeled HDMI decoder input/output and connector
> > >> - added "renesas,rcar-gen2-vin" compat strings
> > >> - removed unnecessary "remote" node and aliases
> > >> - set ADV7612 interrupt to GP4_2
> > >> 
> > >> Ulrich Hecht (3):
> > >>   ARM: dts: r8a7793: Enable VIN0-VIN2
> > > 
> > > I have queued up the above patch with Laurent and Geert's tags.
> > > 
> > >>   ARM: dts: gose: add HDMI input
> > >>   ARM: dts: gose: add composite video input
> > > 
> > > Please address the review of the above two patches and repost.
> > 
> > Could you please do so ? Feedback on 2/3 should be easy to handle. For 3/3,
> > you might need to ping the DT maintainers.
> 
> Ping. These are the only two patches that block
> 
> VIN,v4.12,public,ulrich,Gen2 VIN integration

Sorry, I'm unsure how these slipped through the cracks.
I now have them queued up locally for v4.13 and I plan to push this morning.

Re: [PATCH] rcar-vin: Use of_nodes as specified by the subdev

[Simon Horman]

On Wed, Apr 26, 2017 at 11:00:30AM +0200, Niklas Söderlund wrote:
> Hi Simon,
> 
> Thanks for your feedback.
> 
> On 2017-04-26 09:23:20 +0200, Simon Horman wrote:
> > Hi Kieran,
> > 
> > On Tue, Apr 25, 2017 at 03:55:00PM +0100, Kieran Bingham wrote:
> > > From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> > > 
> > > The rvin_digital_notify_bound() call dereferences the subdev->dev
> > > pointer to obtain the of_node. On some error paths, this dev node can be
> > > set as NULL. The of_node is mapped into the subdevice structure on
> > > initialisation, so this is a safer source to compare the nodes.
> > > 
> > > Dereference the of_node from the subdev structure instead of the dev
> > > structure.
> > > 
> > > Fixes: 83fba2c06f19 ("rcar-vin: rework how subdevice is found and
> > >   bound")
> > > Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> > > ---
> > >  drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> > > b/drivers/media/platform/rcar-vin/rcar-core.c
> > > index 5861ab281150..a530dc388b95 100644
> > > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > > @@ -469,7 +469,7 @@ static int rvin_digital_notify_bound(struct 
> > > v4l2_async_notifier *notifier,
> > >  
> > >   v4l2_set_subdev_hostdata(subdev, vin);
> > >  
> > > - if (vin->digital.asd.match.of.node == subdev->dev->of_node) {
> > > + if (vin->digital.asd.match.of.node == subdev->of_node) {
> > >   /* Find surce and sink pad of remote subdevice */
> > >  
> > >   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
> > 
> > I see two different accesses to subdev->dev->of_node in the version of
> > rcar-core.c in linux-next. So I'm unsure if the following comment makes
> > sense in the context of the version you are working on. It is that
> > I wonder if all accesses to subdev->dev->of_node should be updated.
> 
> Are you sure you checked linux-next and not renesas-drivers? I checked 
> next-20170424.
> 
> $ git grep "dev->of_node" -- drivers/media/platform/rcar-vin/
> drivers/media/platform/rcar-vin/rcar-core.c:107:if 
> (vin->digital.asd.match.of.node == subdev->dev->of_node) {
> drivers/media/platform/rcar-vin/rcar-core.c:161:ep = 
> of_graph_get_endpoint_by_regs(vin->dev->of_node, 0, 0);
> 
> Here vin->dev->of_node is correct and subdev->dev->of_node should be 
> fixed by Kieran patch. I'm only asking to be sure I did not miss 
> anything. In renesas-drivers the Gen3 patches are included and more 
> references to subdev->dev->of_node exists, but as Kieran sates these 
> fixes will be squashed into those patches since they are not yet picked 
> up.

I think we are seeing the same thing, sorry for the noise.

git show next-20170424:drivers/media/platform/rcar-vin/rcar-core.c | grep -A 3 
"dev->of_node"
if (vin->digital.asd.match.of.node == subdev->dev->of_node) {
vin_dbg(vin, "bound digital subdev %s\n", subdev->name);
vin->digital.subdev = subdev;
return 0;
--
ep = of_graph_get_endpoint_by_regs(vin->dev->of_node, 0, 0);
if (!ep)
return 0;

Re: [PATCH] rcar-vin: Use of_nodes as specified by the subdev

[Simon Horman]

On Wed, Apr 26, 2017 at 08:48:25AM +0100, Kieran Bingham wrote:
> Hi Simon,
> 
> On 26/04/17 08:23, Simon Horman wrote:
> > Hi Kieran,
> > 
> > On Tue, Apr 25, 2017 at 03:55:00PM +0100, Kieran Bingham wrote:
> >> From: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> >>
> >> The rvin_digital_notify_bound() call dereferences the subdev->dev
> >> pointer to obtain the of_node. On some error paths, this dev node can be
> >> set as NULL. The of_node is mapped into the subdevice structure on
> >> initialisation, so this is a safer source to compare the nodes.
> >>
> >> Dereference the of_node from the subdev structure instead of the dev
> >> structure.
> >>
> >> Fixes: 83fba2c06f19 ("rcar-vin: rework how subdevice is found and
> >>bound")
> >> Signed-off-by: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
> >> ---
> >>  drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> >> b/drivers/media/platform/rcar-vin/rcar-core.c
> >> index 5861ab281150..a530dc388b95 100644
> >> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> >> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> >> @@ -469,7 +469,7 @@ static int rvin_digital_notify_bound(struct 
> >> v4l2_async_notifier *notifier,
> >>  
> >>v4l2_set_subdev_hostdata(subdev, vin);
> >>  
> >> -  if (vin->digital.asd.match.of.node == subdev->dev->of_node) {
> >> +  if (vin->digital.asd.match.of.node == subdev->of_node) {
> >>/* Find surce and sink pad of remote subdevice */
> >>  
> >>ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
> > 
> > I see two different accesses to subdev->dev->of_node in the version of
> > rcar-core.c in linux-next. So I'm unsure if the following comment makes
> > sense in the context of the version you are working on. It is that
> > I wonder if all accesses to subdev->dev->of_node should be updated.
> 
> Yes, all uses in rcar-core should be updated, This patch is targeted directly 
> at
> mainline, in which only one reference occurs.
> 
> I presume(?) the references in linux-next, relate to the previous version of
> this patch which I posted as a reply to Niklas' patch series:
>  "[PATCH v3 00/27] rcar-vin: Add Gen3 with media controller support"
> 
> The first version of this patch (which was titled differently) covered three
> uses, but two of them were not yet in mainline.
> 
> The 'fixes' for those references are going to be squashed in to Niklas' next
> version of his patchset.

Understood, sounds good to me.

Re: [PATCH] rcar-vin: Use of_nodes as specified by the subdev

[Simon Horman]

Hi Kieran,

On Tue, Apr 25, 2017 at 03:55:00PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The rvin_digital_notify_bound() call dereferences the subdev->dev
> pointer to obtain the of_node. On some error paths, this dev node can be
> set as NULL. The of_node is mapped into the subdevice structure on
> initialisation, so this is a safer source to compare the nodes.
> 
> Dereference the of_node from the subdev structure instead of the dev
> structure.
> 
> Fixes: 83fba2c06f19 ("rcar-vin: rework how subdevice is found and
>   bound")
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 5861ab281150..a530dc388b95 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -469,7 +469,7 @@ static int rvin_digital_notify_bound(struct 
> v4l2_async_notifier *notifier,
>  
>   v4l2_set_subdev_hostdata(subdev, vin);
>  
> - if (vin->digital.asd.match.of.node == subdev->dev->of_node) {
> + if (vin->digital.asd.match.of.node == subdev->of_node) {
>   /* Find surce and sink pad of remote subdevice */
>  
>   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);

I see two different accesses to subdev->dev->of_node in the version of
rcar-core.c in linux-next. So I'm unsure if the following comment makes
sense in the context of the version you are working on. It is that
I wonder if all accesses to subdev->dev->of_node should be updated.

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

[Simon Horman]

Hi Ulrich,

On Tue, Oct 18, 2016 at 05:02:20PM +0200, Ulrich Hecht wrote:
> Hi!
> 
> This is a by-the-datasheet implementation of analog and digital video input
> on the Gose board.
> 
> I have tried to address all concerns raised by reviewers, with the exception
> of the composite input patch, which has been left as is for now.
> 
> CU
> Uli
> 
> 
> Changes since v1:
> - r8a7793.dtsi: added VIN2
> - modeled HDMI decoder input/output and connector
> - added "renesas,rcar-gen2-vin" compat strings
> - removed unnecessary "remote" node and aliases
> - set ADV7612 interrupt to GP4_2
> 
> 
> Ulrich Hecht (3):
>   ARM: dts: r8a7793: Enable VIN0-VIN2

I have queued up the above patch with Laurent and Geert's tags.

>   ARM: dts: gose: add HDMI input
>   ARM: dts: gose: add composite video input

Please address the review of the above two patches and repost.

Thanks!

> 
>  arch/arm/boot/dts/r8a7793-gose.dts | 100 
> +
>  arch/arm/boot/dts/r8a7793.dtsi |  27 ++
>  2 files changed, 127 insertions(+)
> 
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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 2/2] ARM: dts: koelsch: add HDMI input

[Simon Horman]

On Wed, Oct 19, 2016 at 09:33:11AM +0200, Geert Uytterhoeven wrote:
> On Tue, Oct 18, 2016 at 5:01 PM, Ulrich Hecht
>  wrote:
> > From: Hans Verkuil 
> >
> > Add support in the dts for the HDMI input. Based on the Lager dts
> > patch from Ultich Hecht.
> 
> Ulrich ;-)

I have queued up this patch with Ulrich's name corrected.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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 0/2] Renesas Lager/Koelsch HDMI input

[Simon Horman]

On Tue, Oct 18, 2016 at 06:17:25PM +0300, Laurent Pinchart wrote:
> Hi Ulrich,
> 
> Thank you for the patches.
> 
> For the whole series,
> 
> Reviewed-by: Laurent Pinchart 

Thanks, series applied with Laurent's tag.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Simon Horman]

On Sat, Sep 17, 2016 at 01:25:47PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 9/16/2016 4:09 PM, Ulrich Hecht wrote:
> 
> >From: William Towle 
> >
> >Add DT entries for vin0, vin0_pins, and adv7612.
> >
> >Sets the 'default-input' property for ADV7612, enabling image and video
> >capture without the need to have userspace specifying routing.
> >
> >Signed-off-by: William Towle 
> >Signed-off-by: Rob Taylor 
> >[uli: added interrupt, renamed endpoint, merged default-input]
> >Signed-off-by: Ulrich Hecht 
> >---
> > arch/arm/boot/dts/r8a7790-lager.dts | 39 
> > +
> > 1 file changed, 39 insertions(+)
> >
> >diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
> >b/arch/arm/boot/dts/r8a7790-lager.dts
> >index 52b56fc..fc9d129 100644
> >--- a/arch/arm/boot/dts/r8a7790-lager.dts
> >+++ b/arch/arm/boot/dts/r8a7790-lager.dts
> [...]
> >@@ -722,6 +742,25 @@
> > status = "okay";
> > };
> >
> >+/* HDMI video input */
> >+ {
> >+pinctrl-0 = <_pins>;
> >+pinctrl-names = "default";
> >+
> >+status = "ok";
> 
>Should be "okay", although "ok" is also valid.

Ulrich, could you fix this and repost?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] MAINTAINERS: Add entry for the Renesas VIN driver

[Simon Horman]

On Thu, Sep 15, 2016 at 03:22:38PM +0300, Laurent Pinchart wrote:
> Hi Niklas,
> 
> Thank you for the patch.
> 
> On Thursday 15 Sep 2016 14:18:36 Niklas Söderlund wrote:
> > The driver is maintained and supported, document it as such.
> > 
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> 
> Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

I like this a lot:

Acked-by: Simon Horman <horms+rene...@verge.net.au>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 8/8] r8a7791-koelsch.dts: add HDMI input

[Simon Horman]

On Wed, May 11, 2016 at 04:02:56PM +0200, Ulrich Hecht wrote:
> From: Hans Verkuil 
> 
> Add support in the dts for the HDMI input. Based on the Lager dts
> patch from Ultich Hecht.

Please use "ARM: dts: koelsch:" as the prefix for this patch title.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/2] media: soc_camera: rcar_vin: add fallback and r8a7792 bindings

[Simon Horman]

On Tue, Mar 15, 2016 at 09:40:25AM +0900, Simon Horman wrote:
> Hi,
> 
> this short series adds add fallback and r8a7792 bindings to rcar_vin.
> 
> Based on media-tree/master

Hi Guennadi,

I am wondering if you could consider applying this series too.
It still applies cleanly on top of media-tree/master.

Thanks in advance!

> 
> Changes since v3:
> * Add Acks
> * Correct typo in changelog
> 
> Simon Horman (1):
>   media: soc_camera: rcar_vin: add device tree support for r8a7792
> 
> Yoshihiro Kaneko (1):
>   media: soc_camera: rcar_vin: add R-Car Gen 2 and 3 fallback
> compatibility strings
> 
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 12 ++--
>  drivers/media/platform/soc_camera/rcar_vin.c |  2 ++
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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] media: rcar_vin: Use ARCH_RENESAS

[Simon Horman]

On Tue, Mar 08, 2016 at 10:03:55AM +0900, Simon Horman wrote:
> Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
> 
> This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
> 
> Signed-off-by: Simon Horman <horms+rene...@verge.net.au>

Hi Guennadi,

I am wondering if you could consider applying this patch.

Thanks!

> ---
> Based on media-tree/next

The above should have been media-tree/master

> 
> v2
> * Break out of a (slightly) larger patch
> ---
>  drivers/media/platform/soc_camera/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/soc_camera/Kconfig 
> b/drivers/media/platform/soc_camera/Kconfig
> index 355298989dd8..08db3b040bbe 100644
> --- a/drivers/media/platform/soc_camera/Kconfig
> +++ b/drivers/media/platform/soc_camera/Kconfig
> @@ -28,7 +28,7 @@ config VIDEO_PXA27x
>  config VIDEO_RCAR_VIN
>   tristate "R-Car Video Input (VIN) support"
>   depends on VIDEO_DEV && SOC_CAMERA
> - depends on ARCH_SHMOBILE || COMPILE_TEST
> + depends on ARCH_RENESAS || COMPILE_TEST
>   depends on HAS_DMA
>   select VIDEOBUF2_DMA_CONTIG
>   select SOC_CAMERA_SCALE_CROP
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 repost] media: platform: rcar_jpu, vsp1: Use ARCH_RENESAS

[Simon Horman]

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Acked-by: Geert Uytterhoeven <geert+rene...@glider.be>
Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verk...@cisco.com>
Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
---
Mauro, please consider applying this patch.

Based on media-tree/master

v3
* Update subject to not refer to sh_vou
* Added acks from Laurent Pinchart and Hans Verkuil

v2
* Do not update VIDEO_SH_VOU to use ARCH_RENESAS as this is
  used by some SH-based platforms and is not used by any ARM-based platforms
  so a dependency on ARCH_SHMOBILE is correct for that driver
* Added Geert Uytterhoeven's Ack
---
 drivers/media/platform/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 201f5c296a95..84e041c0a70e 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -238,7 +238,7 @@ config VIDEO_SH_VEU
 config VIDEO_RENESAS_JPU
tristate "Renesas JPEG Processing Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
---help---
@@ -250,7 +250,7 @@ config VIDEO_RENESAS_JPU
 config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
-   depends on (ARCH_SHMOBILE && OF) || COMPILE_TEST
+   depends on (ARCH_RENESAS && OF) || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
---help---
  This is a V4L2 driver for the Renesas VSP1 video processing engine.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 0/2] media: soc_camera: rcar_vin: add fallback and r8a7792 bindings

[Simon Horman]

Hi,

this short series adds add fallback and r8a7792 bindings to rcar_vin.

Based on media-tree/master

Changes since v3:
* Add Acks
* Correct typo in changelog

Simon Horman (1):
  media: soc_camera: rcar_vin: add device tree support for r8a7792

Yoshihiro Kaneko (1):
  media: soc_camera: rcar_vin: add R-Car Gen 2 and 3 fallback
compatibility strings

 Documentation/devicetree/bindings/media/rcar_vin.txt | 12 ++--
 drivers/media/platform/soc_camera/rcar_vin.c |  2 ++
 2 files changed, 12 insertions(+), 2 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/2] media: soc_camera: rcar_vin: add device tree support for r8a7792

[Simon Horman]

Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility string
there appears to be no need for a driver updates.

By documenting this compat string it may be used in DTSs shipped, for
example as part of ROMs. It must be used in conjunction with the Gen2
fallback compat string. At this time there are no known differences between
the r8a7792 IP block and that implemented by the driver for the Gen2
fallback compat string. Thus there is no need to update the driver as the
use of the Gen2 fallback compat string will activate the correct code in
the current driver while leaving the option for r8a7792-specific driver
code to be activated in an updated driver should the need arise.

Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
v4
* s/sting/string/ in changelog
* Added Ack from Geert Uytterhoeven

v3
* New patch
---
 Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 4266123888ed..6a4e61cbe011 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -9,6 +9,7 @@ channel which can be either RGB, YUYV or BT656.
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7793" for the R8A7793 device
+   - "renesas,vin-r8a7792" for the R8A7792 device
- "renesas,vin-r8a7791" for the R8A7791 device
- "renesas,vin-r8a7790" for the R8A7790 device
- "renesas,vin-r8a7779" for the R8A7779 device
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/2] media: soc_camera: rcar_vin: add R-Car Gen 2 and 3 fallback compatibility strings

[Simon Horman]

From: Yoshihiro Kaneko <ykaneko0...@gmail.com>

Add fallback compatibility string for R-Car Gen 1 and 2.

In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and 3. But beyond that its not clear what the relationship
between IP blocks might be. For example, I believe that r8a7790 is older
than r8a7791 but that doesn't imply that the latter is a descendant of the
former or vice versa.

We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.

For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.

Signed-off-by: Yoshihiro Kaneko <ykaneko0...@gmail.com>
Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
v4 [Simon Horman]
* Added Ack from Geert Uytterhoeven

v3 [Simon Horman]
* Reworked and expanded changelog.
* Minor documentation enhancements.

v2 [Yoshihiro Kaneko]
* As suggested by Geert Uytterhoeven
  drivers/media/platform/soc_camera/rcar_vin.c:
- The generic compatibility values are listed at the end of the
  rcar_vin_of_table[].

v1 [Yoshihiro Kaneko]
---
 Documentation/devicetree/bindings/media/rcar_vin.txt | 11 +--
 drivers/media/platform/soc_camera/rcar_vin.c |  2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 619193ccf7ff..4266123888ed 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -5,7 +5,7 @@ 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.
 
- - compatible: Must be one of the following
+ - compatible: Must be one or more of the following
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7793" for the R8A7793 device
@@ -13,6 +13,13 @@ channel which can be either RGB, YUYV or BT656.
- "renesas,vin-r8a7790" for the R8A7790 device
- "renesas,vin-r8a7779" for the R8A7779 device
- "renesas,vin-r8a7778" for the R8A7778 device
+   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
+   - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
+
+   When compatible with the generic version nodes must list the
+   SoC-specific version corresponding to the platform first
+   followed by the generic version.
+
  - reg: the register base and size for the device registers
  - interrupts: the interrupt for the device
  - clocks: Reference to the parent clock
@@ -37,7 +44,7 @@ Device node example
};
 
 vin0: vin@0xe6ef {
-compatible = "renesas,vin-r8a7790";
+compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin";
 clocks = <_clks R8A7790_CLK_VIN0>;
 reg = <0 0xe6ef 0 0x1000>;
 interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index 3b8edf458964..3f9c1b8456c3 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1845,6 +1845,8 @@ static const struct of_device_id rcar_vin_of_table[] = {
{ .compatible = "renesas,vin-r8a7790", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,vin-r8a7779", .data = (void *)RCAR_H1 },
{ .compatible = "renesas,vin-r8a7778", .data = (void *)RCAR_M1 },
+   { .compatible = "renesas,rcar-gen3-vin", .data = (void *)RCAR_GEN3 },
+   { .compatible = "renesas,rcar-gen2-vin", .data = (void *)RCAR_GEN2 },
{ },
 };
 MODULE_DEVICE_TABLE(of, rcar_vin_of_table);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] media: soc_camera: rcar_vin: add R-Car Gen 2 and 3 fallback compatibility strings

[Simon Horman]

On Fri, Mar 11, 2016 at 09:04:14AM +0100, Geert Uytterhoeven wrote:
> On Fri, Mar 11, 2016 at 4:25 AM, Simon Horman
> <horms+rene...@verge.net.au> wrote:
> > From: Yoshihiro Kaneko <ykaneko0...@gmail.com>
> >
> > Add fallback compatibility string for R-Car Gen 1 and 2.
> >
> > In the case of Renesas R-Car hardware we know that there are generations of
> > SoCs, e.g. Gen 2 and 3. But beyond that its not clear what the relationship
> > between IP blocks might be. For example, I believe that r8a7790 is older
> > than r8a7791 but that doesn't imply that the latter is a descendant of the
> > former or vice versa.
> >
> > We can, however, by examining the documentation and behaviour of the
> > hardware at run-time observe that the current driver implementation appears
> > to be compatible with the IP blocks on SoCs within a given generation.
> >
> > For the above reasons and convenience when enabling new SoCs a
> > per-generation fallback compatibility string scheme being adopted for
> > drivers for Renesas SoCs.
> >
> > Signed-off-by: Yoshihiro Kaneko <ykaneko0...@gmail.com>
> > Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
> 
> Acked-by: Geert Uytterhoeven <geert+rene...@glider.be>
> 
> > --- a/drivers/media/platform/soc_camera/rcar_vin.c
> > +++ b/drivers/media/platform/soc_camera/rcar_vin.c
> > @@ -1845,6 +1845,8 @@ static const struct of_device_id rcar_vin_of_table[] 
> > = {
> > { .compatible = "renesas,vin-r8a7790", .data = (void *)RCAR_GEN2 },
> > { .compatible = "renesas,vin-r8a7779", .data = (void *)RCAR_H1 },
> > { .compatible = "renesas,vin-r8a7778", .data = (void *)RCAR_M1 },
> > +   { .compatible = "renesas,rcar-gen3-vin", .data = (void *)RCAR_GEN3 
> > },
> > +   { .compatible = "renesas,rcar-gen2-vin", .data = (void *)RCAR_GEN2 
> > },
> 
> Your patch is correct, but I would sort gen2 before gen3, though.

I don't feel strongly about this but I chose the order above to reflect the
sorting of the per-soc compat strings in this driver: numerically from
largest to smallest.

> > { },
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/2] media: soc_camera: rcar_vin: add R-Car Gen 2 and 3 fallback compatibility strings

[Simon Horman]

From: Yoshihiro Kaneko <ykaneko0...@gmail.com>

Add fallback compatibility string for R-Car Gen 1 and 2.

In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and 3. But beyond that its not clear what the relationship
between IP blocks might be. For example, I believe that r8a7790 is older
than r8a7791 but that doesn't imply that the latter is a descendant of the
former or vice versa.

We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.

For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.

Signed-off-by: Yoshihiro Kaneko <ykaneko0...@gmail.com>
Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
---
v3 [Simon Horman]
* Reworked and expanded changelog.
* Minor documentation enhancements.

v2 [Yoshihiro Kaneko]
* As suggested by Geert Uytterhoeven
  drivers/media/platform/soc_camera/rcar_vin.c:
- The generic compatibility values are listed at the end of the
  rcar_vin_of_table[].

v1 [Yoshihiro Kaneko]
---
 Documentation/devicetree/bindings/media/rcar_vin.txt | 11 +--
 drivers/media/platform/soc_camera/rcar_vin.c |  2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 619193ccf7ff..4266123888ed 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -5,7 +5,7 @@ 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.
 
- - compatible: Must be one of the following
+ - compatible: Must be one or more of the following
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7793" for the R8A7793 device
@@ -13,6 +13,13 @@ channel which can be either RGB, YUYV or BT656.
- "renesas,vin-r8a7790" for the R8A7790 device
- "renesas,vin-r8a7779" for the R8A7779 device
- "renesas,vin-r8a7778" for the R8A7778 device
+   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
+   - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
+
+   When compatible with the generic version nodes must list the
+   SoC-specific version corresponding to the platform first
+   followed by the generic version.
+
  - reg: the register base and size for the device registers
  - interrupts: the interrupt for the device
  - clocks: Reference to the parent clock
@@ -37,7 +44,7 @@ Device node example
};
 
 vin0: vin@0xe6ef {
-compatible = "renesas,vin-r8a7790";
+compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin";
 clocks = <_clks R8A7790_CLK_VIN0>;
 reg = <0 0xe6ef 0 0x1000>;
 interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index 3b8edf458964..3f9c1b8456c3 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1845,6 +1845,8 @@ static const struct of_device_id rcar_vin_of_table[] = {
{ .compatible = "renesas,vin-r8a7790", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,vin-r8a7779", .data = (void *)RCAR_H1 },
{ .compatible = "renesas,vin-r8a7778", .data = (void *)RCAR_M1 },
+   { .compatible = "renesas,rcar-gen3-vin", .data = (void *)RCAR_GEN3 },
+   { .compatible = "renesas,rcar-gen2-vin", .data = (void *)RCAR_GEN2 },
{ },
 };
 MODULE_DEVICE_TABLE(of, rcar_vin_of_table);
-- 
2.7.0.rc3.207.g0ac5344

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] media: soc_camera: rcar_vin: add device tree support for r8a7792

[Simon Horman]

Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility string
there appears to be no need for a driver updates.

By documenting this compat sting it may be used in DTSs shipped, for
example as part of ROMs. It must be used in conjunction with the Gen2
fallback compat string. At this time there are no known differences between
the r8a7792 IP block and that implemented by the driver for the Gen2
fallback compat string. Thus there is no need to update the driver as the
use of the Gen2 fallback compat string will activate the correct code in
the current driver while leaving the option for r8a7792-specific driver
code to be activated in an updated driver should the need arise.

Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
---
v3
* New patch
---
 Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 4266123888ed..6a4e61cbe011 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -9,6 +9,7 @@ channel which can be either RGB, YUYV or BT656.
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7793" for the R8A7793 device
+   - "renesas,vin-r8a7792" for the R8A7792 device
- "renesas,vin-r8a7791" for the R8A7791 device
- "renesas,vin-r8a7790" for the R8A7790 device
- "renesas,vin-r8a7779" for the R8A7779 device
-- 
2.7.0.rc3.207.g0ac5344

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/2] media: soc_camera: rcar_vin: add fallback and r8a7792 bindings

[Simon Horman]

Hi,

this short series adds add fallback and r8a7792 bindings to rcar_vin.

Based on media-tree/master

Simon Horman (1):
  media: soc_camera: rcar_vin: add device tree support for r8a7792

Yoshihiro Kaneko (1):
  media: soc_camera: rcar_vin: add R-Car Gen 2 and 3 fallback
compatibility strings

 Documentation/devicetree/bindings/media/rcar_vin.txt | 12 ++--
 drivers/media/platform/soc_camera/rcar_vin.c |  2 ++
 2 files changed, 12 insertions(+), 2 deletions(-)

-- 
2.7.0.rc3.207.g0ac5344

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] media: rcar_vin: Use ARCH_RENESAS

[Simon Horman]

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Signed-off-by: Simon Horman <horms+rene...@verge.net.au>

---
Based on media-tree/next

v2
* Break out of a (slightly) larger patch
---
 drivers/media/platform/soc_camera/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index 355298989dd8..08db3b040bbe 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -28,7 +28,7 @@ config VIDEO_PXA27x
 config VIDEO_RCAR_VIN
tristate "R-Car Video Input (VIN) support"
depends on VIDEO_DEV && SOC_CAMERA
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select SOC_CAMERA_SCALE_CROP
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] media: sh_mobile_ceu_camera: Remove dependency on SUPERH

[Simon Horman]

A dependency on ARCH_SHMOBILE seems to be the best option for
sh_mobile_ceu_camera:

* For Super H based SoCs: sh_mobile_ceu is used on SH_AP325RXA, SH_ECOVEC,
  SH_KFR2R09, SH_MIGOR, and SH_7724_SOLUTION_ENGINE which depend on
  CPU_SUBTYPE_SH7722, CPU_SUBTYPE_SH7723, or CPU_SUBTYPE_SH7724 which all
  select ARCH_SHMOBILE.

* For ARM Based SoCs: Since the removal of legacy (non-multiplatform)
  support this driver has not been used by any Renesas ARM based SoCs.
  The Renesas ARM based SoCs currently select ARCH_SHMOBILE, however,
  it is planned that this will no longer be the case.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Thanks to Geert Uytterhoeven for analysis and portions of the
change log text.

Cc: Geert Uytterhoeven <ge...@linux-m68k.org>
Signed-off-by: Simon Horman <horms+rene...@verge.net.au>

--
Based on media-tree/next

v2
* Break out of a (slightly) larger patch
* Re-work to drop SUPERH dependency rather than replacing
  ARCH_SHMOBILE with ARCH_RENESAS.
---
 drivers/media/platform/soc_camera/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index 08db3b040bbe..83029a4854ae 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -45,7 +45,7 @@ config VIDEO_SH_MOBILE_CSI2
 config VIDEO_SH_MOBILE_CEU
tristate "SuperH Mobile CEU Interface driver"
depends on VIDEO_DEV && SOC_CAMERA && HAS_DMA && HAVE_CLK
-   depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST
+   depends on ARCH_SHMOBILE || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select SOC_CAMERA_SCALE_CROP
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media: sh_mobile_ceu_camera, rcar_vin: Use ARCH_RENESAS

[Simon Horman]

On Mon, Mar 07, 2016 at 08:53:56AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> Oops, seems I dropped all CCs in my earlier reply. Fixing up...
> 
> On Mon, Mar 7, 2016 at 2:28 AM, Simon Horman <ho...@verge.net.au> wrote:
> > On Thu, Mar 03, 2016 at 09:40:07AM +0100, Geert Uytterhoeven wrote:
> >> On Thu, Mar 3, 2016 at 2:52 AM, Simon Horman <horms+rene...@verge.net.au> 
> >> wrote:
> >> > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
> >> >
> >> > This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> >> > ARCH_RENESAS the motivation for which being that RENESAS seems to be a 
> >> > more
> >> > appropriate name than SHMOBILE for the majority of Renesas ARM based 
> >> > SoCs.
> >> >
> >> > Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
> >>
> >> > --- a/drivers/media/platform/soc_camera/Kconfig
> >> > +++ b/drivers/media/platform/soc_camera/Kconfig
> >> > @@ -36,7 +36,7 @@ config VIDEO_PXA27x
> >> >  config VIDEO_RCAR_VIN
> >> > tristate "R-Car Video Input (VIN) support"
> >> > depends on VIDEO_DEV && SOC_CAMERA
> >> > -   depends on ARCH_SHMOBILE || COMPILE_TEST
> >> > +   depends on ARCH_RENESAS || COMPILE_TEST
> >>
> >> OK
> >>
> >> >>  config VIDEO_SH_MOBILE_CEU
> >> > tristate "SuperH Mobile CEU Interface driver"
> >> > depends on VIDEO_DEV && SOC_CAMERA && HAS_DMA && HAVE_CLK
> >> > -   depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST
> >> > +   depends on ARCH_RENESAS || SUPERH || COMPILE_TEST
> >>
> >> I think dropping the SUPERH dependency is the right approach here, as all
> >> SuperH platforms using this driver select ARCH_SHMOBILE.
> >>
> >> "sh_mobile_ceu" is used on SH_AP325RXA, SH_ECOVEC, SH_KFR2R09, SH_MIGOR,
> >> and SH_7724_SOLUTION_ENGINE, which depend on either CPU_SUBTYPE_SH7722,
> >>  CPU_SUBTYPE_SH7723, or
> >> CPU_SUBTYPE_SH7724, and all three select ARCH_SHMOBILE.
> >
> > Dropping SUPERH seems fine to me. But in that case I think the following
> > would be best as I would like to stop selecting ARCH_SHMOBILE for
> > the ARM SoCs.
> >
> > depends on ARCH_RENESAS || ARCH_SHMOBILE || COMPILE_TEST
> 
> Do we need this driver with ARCH_RENESAS? It does not support DT.
> 
> R8a7740 has the sh_mobile_ceu hardware, but support for it was dropped with
> r8a7740/armadillo legacy removal.

Silly me, no it is not needed.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] media: sh_mobile_ceu_camera, rcar_vin: Use ARCH_RENESAS

[Simon Horman]

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
---
 drivers/media/platform/soc_camera/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

 Based on media-tree/master

diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index f2776cd415ca..20ad48458cff 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -36,7 +36,7 @@ config VIDEO_PXA27x
 config VIDEO_RCAR_VIN
tristate "R-Car Video Input (VIN) support"
depends on VIDEO_DEV && SOC_CAMERA
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select SOC_CAMERA_SCALE_CROP
@@ -53,7 +53,7 @@ config VIDEO_SH_MOBILE_CSI2
 config VIDEO_SH_MOBILE_CEU
tristate "SuperH Mobile CEU Interface driver"
depends on VIDEO_DEV && SOC_CAMERA && HAS_DMA && HAVE_CLK
-   depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST
+   depends on ARCH_RENESAS || SUPERH || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select SOC_CAMERA_SCALE_CROP
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" 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] media: platform: rcar_jpu, sh_vou, vsp1: Use ARCH_RENESAS

[Simon Horman]

On Wed, Mar 02, 2016 at 12:32:39PM +0100, Hans Verkuil wrote:
> Hi Simon,
> 
> Note that the patch subject still mentions sh_vou.
> 
> Otherwise:
> 
> Acked-by: Hans Verkuil 

[snip]

On Wed, Mar 02, 2016 at 04:17:10PM +0300, Sergei Shtylyov wrote:

[snip]

> >v2
> >* Do not update VIDEO_SH_VOU to use ARCH_RENESAS as this is
> >   used by some SH-based platforms and is not used by any ARM-based platforms
> >   so a dependency on ARCH_SHMOBILE is correct for that driver
> 
>You forgot to remove it from the subject though.

[snip]


Thanks, I have posted v3 with sh_vou removed from the subject line.

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] media: platform: rcar_jpu, vsp1: Use ARCH_RENESAS

[Simon Horman]

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Acked-by: Geert Uytterhoeven <geert+rene...@glider.be>
Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Acked-by: Hans Verkuil <hans.verk...@cisco.com>
Signed-off-by: Simon Horman <horms+rene...@verge.net.au>

---
Based on media-tree/master

v3
* Update subject to not refer to sh_vou
* Added acks from Laurent Pinchart and Hans Verkuil

v2
* Do not update VIDEO_SH_VOU to use ARCH_RENESAS as this is
  used by some SH-based platforms and is not used by any ARM-based platforms
  so a dependency on ARCH_SHMOBILE is correct for that driver
* Added Geert Uytterhoeven's Ack
---
 drivers/media/platform/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 201f5c296a95..84e041c0a70e 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -238,7 +238,7 @@ config VIDEO_SH_VEU
 config VIDEO_RENESAS_JPU
tristate "Renesas JPEG Processing Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
---help---
@@ -250,7 +250,7 @@ config VIDEO_RENESAS_JPU
 config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
-   depends on (ARCH_SHMOBILE && OF) || COMPILE_TEST
+   depends on (ARCH_RENESAS && OF) || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
---help---
  This is a V4L2 driver for the Renesas VSP1 video processing engine.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] rcar_jpu: add fallback compatibility string

[Simon Horman]

Add fallback compatibility string.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman <horms+rene...@verge.net.au>
---
 Documentation/devicetree/bindings/media/renesas,jpu.txt | 13 +++--
 drivers/media/platform/rcar_jpu.c   |  1 +
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/renesas,jpu.txt 
b/Documentation/devicetree/bindings/media/renesas,jpu.txt
index 0cb94201bf92..c96de75f0089 100644
--- a/Documentation/devicetree/bindings/media/renesas,jpu.txt
+++ b/Documentation/devicetree/bindings/media/renesas,jpu.txt
@@ -5,11 +5,12 @@ and decoding function conforming to the JPEG baseline 
process, so that the JPU
 can encode image data and decode JPEG data quickly.
 
 Required properties:
-  - compatible: should containg one of the following:
-   - "renesas,jpu-r8a7790" for R-Car H2
-   - "renesas,jpu-r8a7791" for R-Car M2-W
-   - "renesas,jpu-r8a7792" for R-Car V2H
-   - "renesas,jpu-r8a7793" for R-Car M2-N
+- compatible: "renesas,jpu-", "renesas,jpu" as fallback.
+   Examples with soctypes are:
+ - "renesas,jpu-r8a7790" for R-Car H2
+ - "renesas,jpu-r8a7791" for R-Car M2-W
+ - "renesas,jpu-r8a7792" for R-Car V2H
+ - "renesas,jpu-r8a7793" for R-Car M2-N
 
   - reg: Base address and length of the registers block for the JPU.
   - interrupts: JPU interrupt specifier.
@@ -17,7 +18,7 @@ Required properties:
 
 Example: R8A7790 (R-Car H2) JPU node
jpeg-codec@fe98 {
-   compatible = "renesas,jpu-r8a7790";
+   compatible = "renesas,jpu-r8a7790", "renesas,jpu";
reg = <0 0xfe98 0 0x10300>;
interrupts = <0 272 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7790_CLK_JPU>;
diff --git a/drivers/media/platform/rcar_jpu.c 
b/drivers/media/platform/rcar_jpu.c
index f8e3e83c52a2..53cec95abb08 100644
--- a/drivers/media/platform/rcar_jpu.c
+++ b/drivers/media/platform/rcar_jpu.c
@@ -1611,6 +1611,7 @@ static const struct of_device_id jpu_dt_ids[] = {
{ .compatible = "renesas,jpu-r8a7791" }, /* M2-W */
{ .compatible = "renesas,jpu-r8a7792" }, /* V2H */
{ .compatible = "renesas,jpu-r8a7793" }, /* M2-N */
+   { .compatible = "renesas,jpu" },
{ },
 };
 MODULE_DEVICE_TABLE(of, jpu_dt_ids);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] VSP1: Add support for lookup tables

[Simon Horman]

On Mon, Nov 16, 2015 at 06:46:41AM +0200, Laurent Pinchart wrote:
> Hello,
> 
> The VSP1 includes two lookup table modules, a 1D LUT and a 3D cubic lookup
> table (CLU). This patch series fixes the LUT implementation and adds support
> for the CLU.
> 
> The patches are based on top of
> 
>   git://linuxtv.org/media_tree.git master
> 
> and have been tested on a Koelsch board.
> 
> Laurent Pinchart (4):
>   v4l: vsp1: Fix LUT format setting
>   v4l: vsp1: Add Cubic Look Up Table (CLU) support
>   ARM: Renesas: r8a7790: Enable CLU support in VSPS
>   ARM: Renesas: r8a7791: Enable CLU support in VSPS

I marked the "ARM: Renesas:" patches as deferred pending the binding
being accepted.

I know we are moving towards "Renesas:" but could you stick to "shmobile"
for now?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Renesas Lager: Device Tree entries for VIN HDMI input, version 2

[Simon Horman]

Hi William,

On Thu, Aug 13, 2015 at 12:36:48PM +0100, William Towle wrote:
>   Version 2 ... removes some redundant configuration from device nodes,
> and provides some supplementary logic for automatic initialisation of
> state->pdata.default_input based on the hardware present.
> 
>   (Obsoletes corresponding parts of "HDMI and Composite capture on
> Lager...", published previously)
> 
> Cheers,
>   Wills.
> 
> To follow:
>   [PATCH 1/3] ARM: shmobile: lager dts: Add entries for VIN HDMI input
>   [PATCH 2/3] media: adv7604: automatic "default-input" selection
>   [PATCH 3/3] ARM: shmobile: lager dts: specify default-input for

I am wondering about the status of patch 2 of the series,
is it queued-up anywhere?

I am also wondering about the relationship between patch 2 and 3.
Does 3 work without 2? Does 2 make 3 unnecessary?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] R-Car JPEG Processing Unit

[Simon Horman]

Hi Mikhail,

On Wed, Jul 22, 2015 at 04:19:53AM +0300, Mikhail Ulyanov wrote:
 Hi Simon,
 
 2015-07-22 3:41 GMT+03:00 Simon Horman ho...@verge.net.au:
  Hi Mikhail,
 
  On Tue, Jul 21, 2015 at 05:00:19AM +0300, Mikhail Ulyanov wrote:
  This series of patches contains a driver for the JPEG codec integrated
  peripheral found in the Renesas R-Car SoCs and associated DT documentation.
 
  I am wondering if you have any plans to post patches to integrate this
  change on any Reneas boards - by which I mean patches to update dts and/or
  dtsi files. I would be very happy to see such patches submitted for review.
 Yes, i have such plans. I suppose it was already (partially)reviewed.
 https://www.marc.info/?l=linux-shm=140867246726948w=4
 As soon as driver patches will be accepted i will resubmit this patches.

Excellent. Sorry for forgetting about having seen the patch at the URL above.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] R-Car JPEG Processing Unit

[Simon Horman]

Hi Mikhail,

On Tue, Jul 21, 2015 at 05:00:19AM +0300, Mikhail Ulyanov wrote:
 This series of patches contains a driver for the JPEG codec integrated
 peripheral found in the Renesas R-Car SoCs and associated DT documentation.

I am wondering if you have any plans to post patches to integrate this
change on any Reneas boards - by which I mean patches to update dts and/or
dtsi files. I would be very happy to see such patches submitted for review.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] rcar_vin: Remove obsolete r8a779x-vin platform_device_id entries

[Simon Horman]

On Tue, Jun 23, 2015 at 02:59:43PM +0200, Geert Uytterhoeven wrote:
 Since commit a483dcbfa21f919c (ARM: shmobile: lager: Remove legacy
 board support), R-Car Gen2 SoCs are only supported in generic DT-only
 ARM multi-platform builds.  The driver doesn't need to match platform
 devices by name anymore, hence remove the corresponding
 platform_device_id entry.
 
 Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be

Acked-by: Simon Horman horms+rene...@verge.net.au

 ---
  drivers/media/platform/soc_camera/rcar_vin.c | 2 --
  1 file changed, 2 deletions(-)
 
 diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
 b/drivers/media/platform/soc_camera/rcar_vin.c
 index db7700b0af7cd569..ef784d311253b142 100644
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 @@ -1834,8 +1834,6 @@ MODULE_DEVICE_TABLE(of, rcar_vin_of_table);
  #endif
  
  static struct platform_device_id rcar_vin_id_table[] = {
 - { r8a7791-vin,  RCAR_GEN2 },
 - { r8a7790-vin,  RCAR_GEN2 },
   { r8a7779-vin,  RCAR_H1 },
   { r8a7778-vin,  RCAR_M1 },
   { uPD35004-vin, RCAR_E1 },
 -- 
 1.9.1
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-sh in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 4/4] soc-camera: Skip v4l2 clock registration if host doesn't provide clk ops

[Simon Horman]

Hi,

On Mon, Mar 16, 2015 at 02:00:25AM +0200, Laurent Pinchart wrote:
 Hi Guennadi,
 
 On Sunday 15 March 2015 18:56:44 Guennadi Liakhovetski wrote:
  On Mon, 9 Mar 2015, Laurent Pinchart wrote:
   If the soc-camera host doesn't provide clock start and stop operations
   registering a v4l2 clock is pointless. Don't do it.
  
  This can introduce breakage only for camera-host drivers, that don't
  provide .clock_start() or .clock_stop(). After your other 3 patches from
  this patch set there will be one such driver in the tree - rcar_vin.c. I
  wouldn't mind this patch as long as we can have an ack from an rcar_vin.c
  maintainer. Since I don't see one in MAINTAINERS, who can ack this? Simon?
 
 I don't think we have an official maintainer. Maybe a Tested-by would be 
 enough in this case ?

I am quite happy to act as the maintainer of last resort for Renesas IP
blocks and to be listed in MAINTAINERS if that is helpful.

With regards to testing, I am also happy to help there, though in this
case I would appreciate some help with a test case.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/3] media: soc_camera: rcar_vin: Add scaling support

[Simon Horman]

Hi Guennadi,

On Sun, Nov 23, 2014 at 12:45:38PM +0100, Guennadi Liakhovetski wrote:
 From: Koji Matsuoka koji.matsuoka...@renesas.com
 
 Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
 Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
 [g.liakhovet...@gmx.de: minor stylistic and formatting corrections]
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
 
 Kaneko-san, Matsuoka-san, could you please have a look at this version of 
 this your patch? Are my changes to it ok? Also, please test this my 
 branch: 
 http://git.linuxtv.org/cgit.cgi/gliakhovetski/v4l-dvb.git/log/?h=for-3.19-1 
 before I push it to Mauro. Patches applied more or less cleanly, and there 
 don't seem to be any functional dependencies, that I might have broken, 
 the driver compiles with no warnings, still, would be good if you could 
 test it! Otherwise waiting for updates for other your patches! Patch 
 rcar_vin: Add BT.709 24-bit RGB888 input support is also marked Ok by 
 me, but I couldn't push it yet, because it depends on other patches, that 
 have to be updated.

Thanks for reworking this patch.
I will see about getting someone to look into testing it and
re-working the other patches.

 Thanks
 Guennadi
 
  drivers/media/platform/soc_camera/rcar_vin.c | 451 
 ++-
  1 file changed, 442 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
 b/drivers/media/platform/soc_camera/rcar_vin.c
 index c60560a..c71ef2b 100644
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 @@ -64,6 +64,30 @@
  #define VNDMR_REG0x58/* Video n Data Mode Register */
  #define VNDMR2_REG   0x5C/* Video n Data Mode Register 2 */
  #define VNUVAOF_REG  0x60/* Video n UV Address Offset Register */
 +#define VNC1A_REG0x80/* Video n Coefficient Set C1A Register */
 +#define VNC1B_REG0x84/* Video n Coefficient Set C1B Register */
 +#define VNC1C_REG0x88/* Video n Coefficient Set C1C Register */
 +#define VNC2A_REG0x90/* Video n Coefficient Set C2A Register */
 +#define VNC2B_REG0x94/* Video n Coefficient Set C2B Register */
 +#define VNC2C_REG0x98/* Video n Coefficient Set C2C Register */
 +#define VNC3A_REG0xA0/* Video n Coefficient Set C3A Register */
 +#define VNC3B_REG0xA4/* Video n Coefficient Set C3B Register */
 +#define VNC3C_REG0xA8/* Video n Coefficient Set C3C Register */
 +#define VNC4A_REG0xB0/* Video n Coefficient Set C4A Register */
 +#define VNC4B_REG0xB4/* Video n Coefficient Set C4B Register */
 +#define VNC4C_REG0xB8/* Video n Coefficient Set C4C Register */
 +#define VNC5A_REG0xC0/* Video n Coefficient Set C5A Register */
 +#define VNC5B_REG0xC4/* Video n Coefficient Set C5B Register */
 +#define VNC5C_REG0xC8/* Video n Coefficient Set C5C Register */
 +#define VNC6A_REG0xD0/* Video n Coefficient Set C6A Register */
 +#define VNC6B_REG0xD4/* Video n Coefficient Set C6B Register */
 +#define VNC6C_REG0xD8/* Video n Coefficient Set C6C Register */
 +#define VNC7A_REG0xE0/* Video n Coefficient Set C7A Register */
 +#define VNC7B_REG0xE4/* Video n Coefficient Set C7B Register */
 +#define VNC7C_REG0xE8/* Video n Coefficient Set C7C Register */
 +#define VNC8A_REG0xF0/* Video n Coefficient Set C8A Register */
 +#define VNC8B_REG0xF4/* Video n Coefficient Set C8B Register */
 +#define VNC8C_REG0xF8/* Video n Coefficient Set C8C Register */
  
  /* Register bit fields for R-Car VIN */
  /* Video n Main Control Register bits */
 @@ -117,6 +141,324 @@ enum chip_id {
   RCAR_E1,
  };
  
 +struct vin_coeff {
 + unsigned short xs_value;
 + u32 coeff_set[24];
 +};
 +
 +static const struct vin_coeff vin_coeff_set[] = {
 + { 0x, {
 + 0x, 0x, 0x,
 + 0x, 0x, 0x,
 + 0x, 0x, 0x,
 + 0x, 0x, 0x,
 + 0x, 0x, 0x,
 + 0x, 0x, 0x,
 + 0x, 0x, 0x,
 + 0x, 0x, 0x },
 + },
 + { 0x1000, {
 + 0x000fa400, 0x000fa400, 0x09625902,
 + 0x03f8, 0x0403, 0x3de0d9f0,
 + 0x001fffed, 0x0804, 0x3cc1f9c3,
 + 0x001003de, 0x0c01, 0x3cb34d7f,
 + 0x002003d2, 0x0c00, 0x3d24a92d,
 + 0x00200bca, 0x0bff, 0x3df600d2,

Re: [PATCH] media: soc_camera: rcar_vin: Fix alignment of clipping size

[Simon Horman]

Hi,

On Fri, Oct 31, 2014 at 04:40:46PM +0300, Sergei Shtylyov wrote:
 Hello.
 
 On 10/31/2014 12:10 PM, Yoshihiro Kaneko wrote:
 
 From: Koji Matsuoka koji.matsuoka...@renesas.com
 
 Since the Start Line Pre-Clip register, the Start Pixel Pre-Clip
 register and the End Line Post-Clip register do not have restriction
 
Hm, my R-Car H1 manual says to specify an even number for the Start Pixel
 Pre-Clip Register.

Thanks. I have confirmed with Matsuoka-san that you are correct.

It seems to me that the following portion of the patch should be removed
accordingly.

--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1558,8 +1558,8 @@ static int rcar_vin_set_crop(struct soc_camera_device 
*icd,
cam-width = mf.width;
cam-height = mf.height;

-   cam-vin_left = rect-left  ~1;
-   cam-vin_top = rect-top  ~1;
+   cam-vin_left = rect-left;
+   cam-vin_top = rect-top;

/* Use VIN cropping to crop to the new window. */
ret = rcar_vin_set_rect(icd);

 of H/W to a setting value, the processing of alignment is unnecessary.
 This patch corrects so that processing of alignment is not performed.
 
 However, the End Pixel Post-Clip register has restriction
 of H/W which must be an even number value at the time of the
 output of YCbCr-422 format. By this patch, the processing of
 alignment to an even number value is added on the above-mentioned
 conditions.
 
Well, the R-Car H1/M1A manuals don't specify such restriction.

Thanks, I have confirmed with Matsuoka-san that the above text
is somewhat misleading. And I think it should read something more like this:

In the case where YCbCr-422 is used and
(End pixel post clip) - (Start pixel post clip) is
odd one will be added by the hardware to round it up
to an even number.

I see this in section 26.2.11 Video n End Pixel Post-Clip Register (VnEPPoC)
if the R-Car Gen 2 manual.

 The variable set to a register is as follows.
 
   - Start Line Pre-Clip register
 cam-vin_top
   - Start Pixel Pre-Clip register
 cam-vin_left
   - End Line Post-Clip register
 pix-height
   - End Pixel Post-Clip register
 pix-width
 
 Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
 Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
 ---
   drivers/media/platform/soc_camera/rcar_vin.c | 18 ++
   1 file changed, 14 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
 b/drivers/media/platform/soc_camera/rcar_vin.c
 index d3d2f7d..1934e15 100644
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 [...]
 @@ -1761,8 +1761,18 @@ static int rcar_vin_try_fmt(struct soc_camera_device 
 *icd,
  }
 
  /* FIXME: calculate using depth and bus width */
 -v4l_bound_align_image(pix-width, 2, VIN_MAX_WIDTH, 1,
 -  pix-height, 4, VIN_MAX_HEIGHT, 2, 0);
 +/*
 + * When performing a YCbCr-422 format output, even if it performs
 + * odd number clipping by pixel post clip processing, it is outputted
 
s/outputted/output/ -- it's an irregular verb.
 
 + * to a memory per even pixels.
 + */
 +if ((pixfmt == V4L2_PIX_FMT_NV16) || (pixfmt == V4L2_PIX_FMT_YUYV) ||
 +(pixfmt == V4L2_PIX_FMT_UYVY))
 
This is certainly asking to be a *switch* statement instead...
 
 +v4l_bound_align_image(pix-width, 5, VIN_MAX_WIDTH, 1,
 +  pix-height, 2, VIN_MAX_HEIGHT, 0, 0);
 +else
 +v4l_bound_align_image(pix-width, 5, VIN_MAX_WIDTH, 0,
 +  pix-height, 2, VIN_MAX_HEIGHT, 0, 0);
 
 WBR, Sergei
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-sh in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support

[Simon Horman]

On Sat, Nov 01, 2014 at 12:06:38AM +0900, Yoshihiro Kaneko wrote:
 From: Koji Matsuoka koji.matsuoka...@renesas.com
 
 Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
 Signed-off-by: Simon Horman horms+rene...@verge.net.au
 Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com

Hi Guennadi,

this patch has been through a few revisions but this one seems
to make the reviewers happy. Could you take a look at it when you have
a chance?

 ---
 
 This patch is against master branch of linuxtv.org/media_tree.git.
 
 v4 [Yoshihiro Kaneko]
 * indent with a tab, not with spaces
 
 v3 [Yoshihiro Kaneko]
 * fixes the detection of RGB input
 
 v2 [Yoshihiro Kaneko]
 * remove unused definition as suggested by Sergei Shtylyov
 * use VNMC_INF_RGB888 directly instead of VNMC_INF_RGB_MASK as a bit-field
   mask
 
  drivers/media/platform/soc_camera/rcar_vin.c | 15 +++
  1 file changed, 15 insertions(+)
 
 diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
 b/drivers/media/platform/soc_camera/rcar_vin.c
 index 20defcb..7becec0 100644
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 @@ -74,6 +74,7 @@
  #define VNMC_INF_YUV10_BT656 (2  16)
  #define VNMC_INF_YUV10_BT601 (3  16)
  #define VNMC_INF_YUV16   (5  16)
 +#define VNMC_INF_RGB888  (6  16)
  #define VNMC_VUP (1  10)
  #define VNMC_IM_ODD  (0  3)
  #define VNMC_IM_ODD_EVEN (1  3)
 @@ -272,6 +273,10 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
  
   /* input interface */
   switch (icd-current_fmt-code) {
 + case V4L2_MBUS_FMT_RGB888_1X24:
 + /* BT.601/BT.709 24-bit RGB-888 */
 + vnmc |= VNMC_INF_RGB888;
 + break;
   case V4L2_MBUS_FMT_YUYV8_1X16:
   /* BT.601/BT.1358 16bit YCbCr422 */
   vnmc |= VNMC_INF_YUV16;
 @@ -331,6 +336,15 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
   if (output_is_yuv)
   vnmc |= VNMC_BPS;
  
 + /*
 +  * The above assumes YUV input, toggle BPS for RGB input.
 +  * RGB inputs can be detected by checking that the most-significant
 +  * two bits of INF are set. This corresponds to the bits
 +  * set in VNMC_INF_RGB888.
 +  */
 + if ((vnmc  VNMC_INF_RGB888) == VNMC_INF_RGB888)
 + vnmc ^= VNMC_BPS;
 +
   /* progressive or interlaced mode */
   interrupts = progressive ? VNIE_FIE | VNIE_EFE : VNIE_EFE;
  
 @@ -1013,6 +1027,7 @@ static int rcar_vin_get_formats(struct 
 soc_camera_device *icd, unsigned int idx,
   case V4L2_MBUS_FMT_YUYV8_1X16:
   case V4L2_MBUS_FMT_YUYV8_2X8:
   case V4L2_MBUS_FMT_YUYV10_2X10:
 + case V4L2_MBUS_FMT_RGB888_1X24:
   if (cam-extra_fmt)
   break;
  
 -- 
 1.9.1
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] v4l: vsp1: Remove support for platform data

[Simon Horman]

On Thu, Oct 30, 2014 at 04:09:13PM +0200, Laurent Pinchart wrote:
 Now that all platforms instantiate the VSP1 through DT, platform data
 support isn't needed anymore.
 
 Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com

Very nice :)

Acked-by: Simon Horman horms+rene...@verge.net.au

 ---
  drivers/media/platform/Kconfig |  2 +-
  drivers/media/platform/vsp1/vsp1.h | 14 +-
  drivers/media/platform/vsp1/vsp1_drv.c | 81 
 --
  drivers/media/platform/vsp1/vsp1_wpf.c |  2 +-
  include/linux/platform_data/vsp1.h | 27 
  5 files changed, 43 insertions(+), 83 deletions(-)
  delete mode 100644 include/linux/platform_data/vsp1.h
 
 diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
 index 0c61155699f7..0c301d8ded7f 100644
 --- a/drivers/media/platform/Kconfig
 +++ b/drivers/media/platform/Kconfig
 @@ -231,7 +231,7 @@ config VIDEO_SH_VEU
  config VIDEO_RENESAS_VSP1
   tristate Renesas VSP1 Video Processing Engine
   depends on VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API  HAS_DMA
 - depends on ARCH_SHMOBILE || COMPILE_TEST
 + depends on (ARCH_SHMOBILE  OF) || COMPILE_TEST
   select VIDEOBUF2_DMA_CONTIG
   ---help---
 This is a V4L2 driver for the Renesas VSP1 video processing engine.
 diff --git a/drivers/media/platform/vsp1/vsp1.h 
 b/drivers/media/platform/vsp1/vsp1.h
 index 12467191dff4..989e96f7e360 100644
 --- a/drivers/media/platform/vsp1/vsp1.h
 +++ b/drivers/media/platform/vsp1/vsp1.h
 @@ -16,7 +16,6 @@
  #include linux/io.h
  #include linux/list.h
  #include linux/mutex.h
 -#include linux/platform_data/vsp1.h
  
  #include media/media-device.h
  #include media/v4l2-device.h
 @@ -40,9 +39,20 @@ struct vsp1_uds;
  #define VSP1_MAX_UDS 3
  #define VSP1_MAX_WPF 4
  
 +#define VSP1_HAS_LIF (1  0)
 +#define VSP1_HAS_LUT (1  1)
 +#define VSP1_HAS_SRU (1  2)
 +
 +struct vsp1_platform_data {
 + unsigned int features;
 + unsigned int rpf_count;
 + unsigned int uds_count;
 + unsigned int wpf_count;
 +};
 +
  struct vsp1_device {
   struct device *dev;
 - struct vsp1_platform_data *pdata;
 + struct vsp1_platform_data pdata;
  
   void __iomem *mmio;
   struct clk *clock;
 diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
 b/drivers/media/platform/vsp1/vsp1_drv.c
 index 3e6601b5b4de..d1911f8f1d55 100644
 --- a/drivers/media/platform/vsp1/vsp1_drv.c
 +++ b/drivers/media/platform/vsp1/vsp1_drv.c
 @@ -40,7 +40,7 @@ static irqreturn_t vsp1_irq_handler(int irq, void *data)
   irqreturn_t ret = IRQ_NONE;
   unsigned int i;
  
 - for (i = 0; i  vsp1-pdata-wpf_count; ++i) {
 + for (i = 0; i  vsp1-pdata.wpf_count; ++i) {
   struct vsp1_rwpf *wpf = vsp1-wpf[i];
   struct vsp1_pipeline *pipe;
   u32 status;
 @@ -181,7 +181,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
  
   list_add_tail(vsp1-hst-entity.list_dev, vsp1-entities);
  
 - if (vsp1-pdata-features  VSP1_HAS_LIF) {
 + if (vsp1-pdata.features  VSP1_HAS_LIF) {
   vsp1-lif = vsp1_lif_create(vsp1);
   if (IS_ERR(vsp1-lif)) {
   ret = PTR_ERR(vsp1-lif);
 @@ -191,7 +191,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
   list_add_tail(vsp1-lif-entity.list_dev, vsp1-entities);
   }
  
 - if (vsp1-pdata-features  VSP1_HAS_LUT) {
 + if (vsp1-pdata.features  VSP1_HAS_LUT) {
   vsp1-lut = vsp1_lut_create(vsp1);
   if (IS_ERR(vsp1-lut)) {
   ret = PTR_ERR(vsp1-lut);
 @@ -201,7 +201,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
   list_add_tail(vsp1-lut-entity.list_dev, vsp1-entities);
   }
  
 - for (i = 0; i  vsp1-pdata-rpf_count; ++i) {
 + for (i = 0; i  vsp1-pdata.rpf_count; ++i) {
   struct vsp1_rwpf *rpf;
  
   rpf = vsp1_rpf_create(vsp1, i);
 @@ -214,7 +214,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
   list_add_tail(rpf-entity.list_dev, vsp1-entities);
   }
  
 - if (vsp1-pdata-features  VSP1_HAS_SRU) {
 + if (vsp1-pdata.features  VSP1_HAS_SRU) {
   vsp1-sru = vsp1_sru_create(vsp1);
   if (IS_ERR(vsp1-sru)) {
   ret = PTR_ERR(vsp1-sru);
 @@ -224,7 +224,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
   list_add_tail(vsp1-sru-entity.list_dev, vsp1-entities);
   }
  
 - for (i = 0; i  vsp1-pdata-uds_count; ++i) {
 + for (i = 0; i  vsp1-pdata.uds_count; ++i) {
   struct vsp1_uds *uds;
  
   uds = vsp1_uds_create(vsp1, i);
 @@ -237,7 +237,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
   list_add_tail(uds-entity.list_dev, vsp1-entities);
   }
  
 - for (i = 0; i  vsp1-pdata-wpf_count; ++i) {
 + for (i = 0; i  vsp1

Re: [PATCH v2] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support

[Simon Horman]

On Wed, Oct 29, 2014 at 02:31:41PM +0300, Sergei Shtylyov wrote:
 Hello.
 
 On 10/29/2014 7:11 AM, Simon Horman wrote:
 
 From: Koji Matsuoka koji.matsuoka...@renesas.com
 
 Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
 Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
 ---
 
 This patch is against master branch of linuxtv.org/media_tree.git.
 
 v2 [Yoshihiro Kaneko]
 * remove unused/useless definition as suggested by Sergei Shtylyov
 
 I didn't say it's useless, I just suspected that you missed the 
  necessary
 test somewhere...
 
 Sorry for my inaccurate description.
 
drivers/media/platform/soc_camera/rcar_vin.c | 9 +
1 file changed, 9 insertions(+)
 
 diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
 b/drivers/media/platform/soc_camera/rcar_vin.c
 index 20defcb..cb5e682 100644
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 @@ -74,6 +74,7 @@
#define VNMC_INF_YUV10_BT656  (2  16)
#define VNMC_INF_YUV10_BT601  (3  16)
#define VNMC_INF_YUV16(5  16)
 +#define VNMC_INF_RGB888(6  16)
#define VNMC_VUP  (1  10)
#define VNMC_IM_ODD   (0  3)
#define VNMC_IM_ODD_EVEN  (1  3)
 
 [...]
 
 @@ -331,6 +336,9 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
  if (output_is_yuv)
  vnmc |= VNMC_BPS;
 
 +   if (vnmc  VNMC_INF_RGB888)
 +   vnmc ^= VNMC_BPS;
 +
 
 Hm, this also changes the behavior for VNMC_INF_YUV16 and
 VNMC_INF_YUV10_BT{601|656}. Is this actually intended?
 
 Probably this code is incorrect.
 Thank you for your review.
 
 Thanks, I have confirmed with Matsuoka-san that there is a problem here.
 
 He has provided the following fix. Could you see about squashing it into
 the above patch and reposting?
 
 From: Koji Matsuoka koji.matsuoka...@renesas.com
 
 [PATCH] media: soc_camera: rcar_vin: Fix bit field check
 
 Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
 
 diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
 b/drivers/media/platform/soc_camera/rcar_vin.c
 index 013d75c..da62d94 100644
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 @@ -94,7 +94,7 @@
   #define VNMC_INF_YUV8_BT601(1  16)
   #define VNMC_INF_YUV16 (5  16)
   #define VNMC_INF_RGB888(6  16)
 -#define VNMC_INF_RGB_MASK   (6  16)
 +#define VNMC_INF_MASK   (7  16)
 
#define it above VNMC_INF_YUV8_BT656 please.
 
   #define VNMC_VUP   (1  10)
   #define VNMC_IM_ODD(0  3)
   #define VNMC_IM_ODD_EVEN   (1  3)
 @@ -675,7 +675,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
  if (output_is_yuv)
  vnmc |= VNMC_BPS;
 
 -if (vnmc  VNMC_INF_RGB_MASK)
 +if ((vnmc  VNMC_INF_MASK) == VNMC_INF_RGB888)
 
Is he sure it shouldn't be (vnmc  VNMC_INF_RGB888) == VNMC_INF_RGB888 to
 also cover 16-bit RGB666 and 12-bit RGB88?

Nice, I think that is a good idea (although the latter formats aren't
supported by the driver yet, right?).

Its somewhat unobvious how that logic works so perhaps we should add a
comment like this

/* If input and output use the same colorspace, use bypass mode */
if (output_is_yuv)
vnmc |= VNMC_BPS;

/* The above assumes YUV input, toggle BPS for RGB input.
 * RGB inputs can be detected by checking that the most-significant
 * two bits of INF are set. This corresponds to the bits
 * set in VNMC_INF_RGB888. */
if ((vnmc  VNMC_INF_RGB888)) == VNMC_INF_RGB888)
vnmc ^= VNMC_BPS;
--
To unsubscribe from this list: send the line unsubscribe linux-media 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] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support

[Simon Horman]

Hi Kaneko-san, Hi Sergei,

On Tue, Oct 21, 2014 at 08:33:52PM +0900, Yoshihiro Kaneko wrote:
 Hello Sergei,
 
 2014-10-21 19:22 GMT+09:00 Sergei Shtylyov 
 sergei.shtyl...@cogentembedded.com:
  Hello.
 
  On 10/21/2014 9:08 AM, Yoshihiro Kaneko wrote:
 
  From: Koji Matsuoka koji.matsuoka...@renesas.com
 
 
  Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
  Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
  ---
 
 
  This patch is against master branch of linuxtv.org/media_tree.git.
 
 
  v2 [Yoshihiro Kaneko]
  * remove unused/useless definition as suggested by Sergei Shtylyov
 
 
 I didn't say it's useless, I just suspected that you missed the necessary
  test somewhere...
 
 Sorry for my inaccurate description.
 
 
drivers/media/platform/soc_camera/rcar_vin.c | 9 +
1 file changed, 9 insertions(+)
 
 
  diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
  b/drivers/media/platform/soc_camera/rcar_vin.c
  index 20defcb..cb5e682 100644
  --- a/drivers/media/platform/soc_camera/rcar_vin.c
  +++ b/drivers/media/platform/soc_camera/rcar_vin.c
  @@ -74,6 +74,7 @@
#define VNMC_INF_YUV10_BT656  (2  16)
#define VNMC_INF_YUV10_BT601  (3  16)
#define VNMC_INF_YUV16(5  16)
  +#define VNMC_INF_RGB888(6  16)
#define VNMC_VUP  (1  10)
#define VNMC_IM_ODD   (0  3)
#define VNMC_IM_ODD_EVEN  (1  3)
 
  [...]
 
  @@ -331,6 +336,9 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
  if (output_is_yuv)
  vnmc |= VNMC_BPS;
 
  +   if (vnmc  VNMC_INF_RGB888)
  +   vnmc ^= VNMC_BPS;
  +
 
 
 Hm, this also changes the behavior for VNMC_INF_YUV16 and
  VNMC_INF_YUV10_BT{601|656}. Is this actually intended?
 
 Probably this code is incorrect.
 Thank you for your review.

Thanks, I have confirmed with Matsuoka-san that there is a problem here.

He has provided the following fix. Could you see about squashing it into
the above patch and reposting?


From: Koji Matsuoka koji.matsuoka...@renesas.com

[PATCH] media: soc_camera: rcar_vin: Fix bit field check

Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com

diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index 013d75c..da62d94 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -94,7 +94,7 @@
 #define VNMC_INF_YUV8_BT601(1  16)
 #define VNMC_INF_YUV16 (5  16)
 #define VNMC_INF_RGB888(6  16)
-#define VNMC_INF_RGB_MASK  (6  16)
+#define VNMC_INF_MASK  (7  16)
 #define VNMC_VUP   (1  10)
 #define VNMC_IM_ODD(0  3)
 #define VNMC_IM_ODD_EVEN   (1  3)
@@ -675,7 +675,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
if (output_is_yuv)
vnmc |= VNMC_BPS;
 
-   if (vnmc  VNMC_INF_RGB_MASK)
+   if ((vnmc  VNMC_INF_MASK) == VNMC_INF_RGB888)
vnmc ^= VNMC_BPS;
 
/* progressive or interlaced mode */
--
To unsubscribe from this list: send the line unsubscribe linux-media 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] media: soc_camera: rcar_vin: Enable VSYNC field toggle mode

[Simon Horman]

On Wed, Oct 22, 2014 at 01:05:36PM +0900, Yoshihiro Kaneko wrote:
 From: Koji Matsuoka koji.matsuoka...@renesas.com
 
 By applying this patch, it sets to VSYNC field toggle mode not only
 at the time of progressive mode but at the time of an interlace mode.
 
 Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
 Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com

Acked-by: Simon Horman horms+rene...@verge.net.au

Guennadi, could you consider this patch when you get a chance?

 ---
 
 This patch is against master branch of linuxtv.org/media_tree.git.
 
 v2 [Yoshihiro Kaneko]
 * improve the macro definition for the VLV field
 
  drivers/media/platform/soc_camera/rcar_vin.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
 b/drivers/media/platform/soc_camera/rcar_vin.c
 index 9300076..beaf8e5 100644
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 @@ -107,6 +107,7 @@
  #define VNDMR2_VPS   (1  30)
  #define VNDMR2_HPS   (1  29)
  #define VNDMR2_FTEV  (1  17)
 +#define VNDMR2_VLV(n)((n  0xf)  12)
  
  #define VIN_MAX_WIDTH2048
  #define VIN_MAX_HEIGHT   2048
 @@ -827,7 +828,7 @@ static int rcar_vin_set_bus_param(struct 
 soc_camera_device *icd)
   if (ret  0  ret != -ENOIOCTLCMD)
   return ret;
  
 - val = priv-field == V4L2_FIELD_NONE ? VNDMR2_FTEV : 0;
 + val = VNDMR2_FTEV | VNDMR2_VLV(1);
   if (!(common_flags  V4L2_MBUS_VSYNC_ACTIVE_LOW))
   val |= VNDMR2_VPS;
   if (!(common_flags  V4L2_MBUS_HSYNC_ACTIVE_LOW))
 -- 
 1.9.1
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media: soc_camera: rcar_vin: Add DT support for r8a7793 and r8a7794 SoCs

[Simon Horman]

On Mon, Oct 20, 2014 at 11:51:29AM +0900, Yoshihiro Kaneko wrote:
 Based on platform device work by Matsuoka-san.
 
 Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com

Acked-by: Simon Horman horms+rene...@verge.net.au

 ---
 
 Compile tested only.
 
 This patch is against master branch of linuxtv.org/media_tree.git.
 
  Documentation/devicetree/bindings/media/rcar_vin.txt | 2 ++
  drivers/media/platform/soc_camera/rcar_vin.c | 2 ++
  2 files changed, 4 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
 b/Documentation/devicetree/bindings/media/rcar_vin.txt
 index ba61782..9dafe6b 100644
 --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
 +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
 @@ -6,6 +6,8 @@ family of devices. The current blocks are always slaves and 
 suppot one input
  channel which can be either RGB, YUYV or BT656.
  
   - compatible: Must be one of the following
 +   - renesas,vin-r8a7794 for the R8A7794 device
 +   - renesas,vin-r8a7793 for the R8A7793 device
 - renesas,vin-r8a7791 for the R8A7791 device
 - renesas,vin-r8a7790 for the R8A7790 device
 - renesas,vin-r8a7779 for the R8A7779 device
 diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
 b/drivers/media/platform/soc_camera/rcar_vin.c
 index 234cf86..c023aab 100644
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 @@ -1871,6 +1871,8 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
  
  #ifdef CONFIG_OF
  static struct of_device_id rcar_vin_of_table[] = {
 + { .compatible = renesas,vin-r8a7794, .data = (void *)RCAR_GEN2 },
 + { .compatible = renesas,vin-r8a7793, .data = (void *)RCAR_GEN2 },
   { .compatible = renesas,vin-r8a7791, .data = (void *)RCAR_GEN2 },
   { .compatible = renesas,vin-r8a7790, .data = (void *)RCAR_GEN2 },
   { .compatible = renesas,vin-r8a7779, .data = (void *)RCAR_H1 },
 -- 
 1.9.1
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-sh in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] media: soc_camera: rcar_vin: Add r8a7794, r8a7793 device support

[Simon Horman]

Hi Guennadi,

On Thu, Oct 16, 2014 at 10:27:13PM +0200, Guennadi Liakhovetski wrote:
 Hello,
 
 Thanks for the patches. Could you please fold these two into one - they 
 really don't deserve to be separated.

Thanks. Kaneko-san could you squash these patches and repost?

 As for your other series - patches 
 there look mostly good - from just a formal review. If you don't mind, 
 I'll adjust a couple of cosmetic issues like missing curly braces in 
 
   if (a)
   x();
   else {
   y();
   z();
   }
 
 or multiline comments or similar minor things.

Feel free to make any minor updates.

 Thanks
 Guennadi
 
 On Tue, 14 Oct 2014, Yoshihiro Kaneko wrote:
 
  This series is against master branch of linuxtv.org/media_tree.git.
  
  Koji Matsuoka (2):
media: soc_camera: rcar_vin: Add r8a7794 device support
media: soc_camera: rcar_vin: Add r8a7793 device support
  
   drivers/media/platform/soc_camera/rcar_vin.c | 2 ++
   1 file changed, 2 insertions(+)
  
  -- 
  1.9.1
  
 --
 To unsubscribe from this list: send the line unsubscribe linux-sh in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
--
To unsubscribe from this list: send the line unsubscribe linux-media 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] media: soc_camera: rcar_vin: Add r8a7794, r8a7793 device support

[Simon Horman]

On Fri, Oct 17, 2014 at 11:01:07AM +0300, Laurent Pinchart wrote:
 Hi Kaneko-san,
 
 Thank you for the patch.
 
 Could you please also update 
 Documentation/devicetree/bindings/media/rcar_vin.txt with the new compatible 
 strings ?

Hi Laurent,

thanks for pointing that out. It is true that we want DT support for the
new SoCs for this driver and in that case updating the bindings
documentation would be necessary.  However, this patch adds platform device
support.

What I suggest is dropping this patch for now and working on
a replacement that adds DT support only. I do not believe there
are any plans to use a platform device in mainline for this driver on the
new SoCs.

 On Friday 17 October 2014 16:07:39 Yoshihiro Kaneko wrote:
  From: Koji Matsuoka koji.matsuoka...@renesas.com
  
  Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
  Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
  Acked-by: Simon Horman horms+rene...@verge.net.au
  
  ---
  
  This patch is against master branch of linuxtv.org/media_tree.git.
  
  v2 [Yoshihiro Kaneko]
  * Squashed r8a7793 and r8a7794 patches
  
   drivers/media/platform/soc_camera/rcar_vin.c | 2 ++
   1 file changed, 2 insertions(+)
  
  diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
  b/drivers/media/platform/soc_camera/rcar_vin.c index 234cf86..4acae8f
  100644
  --- a/drivers/media/platform/soc_camera/rcar_vin.c
  +++ b/drivers/media/platform/soc_camera/rcar_vin.c
  @@ -1881,6 +1881,8 @@ MODULE_DEVICE_TABLE(of, rcar_vin_of_table);
   #endif
  
   static struct platform_device_id rcar_vin_id_table[] = {
  +   { r8a7794-vin,  RCAR_GEN2 },
  +   { r8a7793-vin,  RCAR_GEN2 },
  { r8a7791-vin,  RCAR_GEN2 },
  { r8a7790-vin,  RCAR_GEN2 },
  { r8a7779-vin,  RCAR_H1 },
 
 -- 
 Regards,
 
 Laurent Pinchart
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-sh in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] media: soc_camera: rcar_vin: Add r8a7794, r8a7793 device support

[Simon Horman]

[CC Mauro Carvalho Chehab]

On Tue, Oct 14, 2014 at 04:20:22PM +0900, Yoshihiro Kaneko wrote:
 This series is against master branch of linuxtv.org/media_tree.git.
 
 Koji Matsuoka (2):
   media: soc_camera: rcar_vin: Add r8a7794 device support
   media: soc_camera: rcar_vin: Add r8a7793 device support
 
  drivers/media/platform/soc_camera/rcar_vin.c | 2 ++
  1 file changed, 2 insertions(+)

Acked-by: Simon Horman horms+rene...@verge.net.au

If the series needs reposting to a different CC list -
e.g. including Mauro - please let Kaneko-san or myself know.


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support

[Simon Horman]

[CC Mauro Carvalho Chehab]

On Tue, Oct 14, 2014 at 03:22:10PM +0900, Yoshihiro Kaneko wrote:
 From: Koji Matsuoka koji.matsuoka...@renesas.com
 
 Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
 Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
 ---
 
 This patch is against master branch of linuxtv.org/media_tree.git.

Acked-by: Simon Horman horms+rene...@verge.net.au

If the series needs reposting to a different CC list -
e.g. including Mauro - please let Kaneko-san or myself know.

 
  drivers/media/platform/soc_camera/rcar_vin.c | 10 ++
  include/linux/platform_data/camera-rcar.h|  1 +
  2 files changed, 11 insertions(+)
 
 diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
 b/drivers/media/platform/soc_camera/rcar_vin.c
 index 20defcb..7eb4f1e 100644
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 @@ -74,6 +74,8 @@
  #define VNMC_INF_YUV10_BT656 (2  16)
  #define VNMC_INF_YUV10_BT601 (3  16)
  #define VNMC_INF_YUV16   (5  16)
 +#define VNMC_INF_RGB888  (6  16)
 +#define VNMC_INF_RGB_MASK(6  16)
  #define VNMC_VUP (1  10)
  #define VNMC_IM_ODD  (0  3)
  #define VNMC_IM_ODD_EVEN (1  3)
 @@ -272,6 +274,10 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
  
   /* input interface */
   switch (icd-current_fmt-code) {
 + case V4L2_MBUS_FMT_RGB888_1X24:
 + /* BT.601/BT.709 24-bit RGB-888 */
 + vnmc |= VNMC_INF_RGB888;
 + break;
   case V4L2_MBUS_FMT_YUYV8_1X16:
   /* BT.601/BT.1358 16bit YCbCr422 */
   vnmc |= VNMC_INF_YUV16;
 @@ -331,6 +337,9 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
   if (output_is_yuv)
   vnmc |= VNMC_BPS;
  
 + if (vnmc  VNMC_INF_RGB_MASK)
 + vnmc ^= VNMC_BPS;
 +
   /* progressive or interlaced mode */
   interrupts = progressive ? VNIE_FIE | VNIE_EFE : VNIE_EFE;
  
 @@ -1013,6 +1022,7 @@ static int rcar_vin_get_formats(struct 
 soc_camera_device *icd, unsigned int idx,
   case V4L2_MBUS_FMT_YUYV8_1X16:
   case V4L2_MBUS_FMT_YUYV8_2X8:
   case V4L2_MBUS_FMT_YUYV10_2X10:
 + case V4L2_MBUS_FMT_RGB888_1X24:
   if (cam-extra_fmt)
   break;
  
 diff --git a/include/linux/platform_data/camera-rcar.h 
 b/include/linux/platform_data/camera-rcar.h
 index dfc83c5..03a9df6 100644
 --- a/include/linux/platform_data/camera-rcar.h
 +++ b/include/linux/platform_data/camera-rcar.h
 @@ -17,6 +17,7 @@
  #define RCAR_VIN_VSYNC_ACTIVE_LOW(1  1)
  #define RCAR_VIN_BT601   (1  2)
  #define RCAR_VIN_BT656   (1  3)
 +#define RCAR_VIN_BT709   (1  4)
  
  struct rcar_vin_platform_data {
   unsigned int flags;
 -- 
 1.9.1
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media: soc_camera: rcar_vin: Add YUYV capture format support

[Simon Horman]

[CC Mauro Carvalho Chehab]

On Tue, Oct 14, 2014 at 03:24:38PM +0900, Yoshihiro Kaneko wrote:
 From: Koji Matsuoka koji.matsuoka...@renesas.com
 
 Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
 Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
 ---
 
 This patch is against master branch of linuxtv.org/media_tree.git.
 
  drivers/media/platform/soc_camera/rcar_vin.c | 8 
  1 file changed, 8 insertions(+)

Acked-by: Simon Horman horms+rene...@verge.net.au

If the series needs reposting to a different CC list -
e.g. including Mauro - please let Kaneko-san or myself know.

 diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
 b/drivers/media/platform/soc_camera/rcar_vin.c
 index 7eb4f1e..61c36b0 100644
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 @@ -889,6 +889,14 @@ static const struct soc_mbus_pixelfmt rcar_vin_formats[] 
 = {
   .layout = SOC_MBUS_LAYOUT_PLANAR_Y_C,
   },
   {
 + .fourcc = V4L2_PIX_FMT_YUYV,
 + .name   = YUYV,
 + .bits_per_sample= 16,
 + .packing= SOC_MBUS_PACKING_NONE,
 + .order  = SOC_MBUS_ORDER_LE,
 + .layout = SOC_MBUS_LAYOUT_PACKED,
 + },
 + {
   .fourcc = V4L2_PIX_FMT_UYVY,
   .name   = UYVY,
   .bits_per_sample= 16,
 -- 
 1.9.1
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-sh in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] media: soc_camera: Fix VIDIOC_S_CROP ioctl miscalculation

[Simon Horman]

[CC Mauro Carvalho Chehab]

On Tue, Oct 14, 2014 at 03:25:24PM +0900, Yoshihiro Kaneko wrote:
 From: Koji Matsuoka koji.matsuoka...@renesas.com
 
 This patch corrects the miscalculation of the capture buffer
 size and clipping data update in VIDIOC_S_CROP sequence.
 
 Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
 Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com

Acked-by: Simon Horman horms+rene...@verge.net.au

If the series needs reposting to a different CC list -
e.g. including Mauro - please let Kaneko-san or myself know.

 ---
 
 This patch is against master branch of linuxtv.org/media_tree.git.
 
  drivers/media/platform/soc_camera/rcar_vin.c   | 5 -
  drivers/media/platform/soc_camera/soc_scale_crop.c | 6 --
  2 files changed, 4 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
 b/drivers/media/platform/soc_camera/rcar_vin.c
 index 61c36b0..5196c81 100644
 --- a/drivers/media/platform/soc_camera/rcar_vin.c
 +++ b/drivers/media/platform/soc_camera/rcar_vin.c
 @@ -1119,9 +1119,6 @@ static int rcar_vin_set_crop(struct soc_camera_device 
 *icd,
   cam-width = mf.width;
   cam-height = mf.height;
  
 - icd-user_width  = cam-width;
 - icd-user_height = cam-height;
 -
   cam-vin_left = rect-left  ~1;
   cam-vin_top = rect-top  ~1;
  
 @@ -1130,8 +1127,6 @@ static int rcar_vin_set_crop(struct soc_camera_device 
 *icd,
   if (ret  0)
   return ret;
  
 - cam-subrect = *rect;
 -
   dev_dbg(dev, VIN cropped to %ux%u@%u:%u\n,
   icd-user_width, icd-user_height,
   cam-vin_left, cam-vin_top);
 diff --git a/drivers/media/platform/soc_camera/soc_scale_crop.c 
 b/drivers/media/platform/soc_camera/soc_scale_crop.c
 index 8e74fb7..7a1951a 100644
 --- a/drivers/media/platform/soc_camera/soc_scale_crop.c
 +++ b/drivers/media/platform/soc_camera/soc_scale_crop.c
 @@ -74,14 +74,14 @@ static void update_subrect(struct v4l2_rect *rect, struct 
 v4l2_rect *subrect)
  
   if (rect-left  subrect-left)
   subrect-left = rect-left;
 - else if (rect-left + rect-width 
 + else if (rect-left + rect-width 
subrect-left + subrect-width)
   subrect-left = rect-left + rect-width -
   subrect-width;
  
   if (rect-top  subrect-top)
   subrect-top = rect-top;
 - else if (rect-top + rect-height 
 + else if (rect-top + rect-height 
subrect-top + subrect-height)
   subrect-top = rect-top + rect-height -
   subrect-height;
 @@ -117,6 +117,7 @@ int soc_camera_client_s_crop(struct v4l2_subdev *sd,
   dev_dbg(dev, Camera S_CROP successful for %dx%d@%d:%d\n,
   rect-width, rect-height, rect-left, rect-top);
   *target_rect = *cam_rect;
 + *subrect = *rect;
   return 0;
   }
  
 @@ -204,6 +205,7 @@ int soc_camera_client_s_crop(struct v4l2_subdev *sd,
  
   if (!ret) {
   *target_rect = *cam_rect;
 + *subrect = *rect;
   update_subrect(target_rect, subrect);
   }
  
 -- 
 1.9.1
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html