Re: [PATCH v3 8/9] media: rcar-vin: Rename _rcar_info to rcar_info

[Sergei Shtylyov]

Hello!

On 5/18/2018 5:40 PM, Jacopo Mondi wrote:


Remove trailing underscore to align all rcar_group_route structure


   Leading, not trailing (judging on the patch).


declarations.
 Signed-off-by: Jacopo Mondi 
---
  drivers/media/platform/rcar-vin/rcar-core.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index dcebb42..b740f41 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1060,7 +1060,7 @@ static const struct rvin_info rcar_info_r8a7796 = {
.routes = rcar_info_r8a7796_routes,
  };
  
-static const struct rvin_group_route _rcar_info_r8a77970_routes[] = {

+static const struct rvin_group_route rcar_info_r8a77970_routes[] = {
{ .csi = RVIN_CSI40, .channel = 0, .vin = 0, .mask = BIT(0) | BIT(3) },
{ .csi = RVIN_CSI40, .channel = 0, .vin = 1, .mask = BIT(2) },
{ .csi = RVIN_CSI40, .channel = 1, .vin = 1, .mask = BIT(3) },
@@ -1076,7 +1076,7 @@ static const struct rvin_info rcar_info_r8a77970 = {
.use_mc = true,
.max_width = 4096,
.max_height = 4096,
-   .routes = _rcar_info_r8a77970_routes,
+   .routes = rcar_info_r8a77970_routes,
  };
  
  static const struct of_device_id rvin_of_id_table[] = {


MBR, Sergei

Re: [PATCH] dt-bindings: media: rcar_vin: fix style for ports and endpoints

[Sergei Shtylyov]

On 5/17/2018 2:32 AM, Niklas Söderlund wrote:


The style for referring to ports and endpoint are wrong. Refer to them
using lowercase and a unit address, port@x and endpoint@x.

Signed-off-by: Niklas Söderlund 
Reported-by: Geert Uytterhoeven 


   More typos, yay! :-)


---
  .../devicetree/bindings/media/rcar_vin.txt| 20 +--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index c2c57dcf73f4851b..a574b9c037c05a3c 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -45,23 +45,23 @@ The per-board settings Gen2 platforms:
  The per-board settings Gen3 platforms:
  
  Gen3 platforms can support both a single connected parallel input source

-from external SoC pins (port0) and/or multiple parallel input sources
-from local SoC CSI-2 receivers (port1) depending on SoC.
+from external SoC pins (port@0) and/or multiple parallel input sources
+from local SoC CSI-2 receivers (port@1) depending on SoC.
  
  - renesas,id - ID number of the VIN, VINx in the documentation.

  - ports
-- port 0 - sub-node describing a single endpoint connected to the VIN
+- port@0 - sub-node describing a single endpoint connected to the VIN
from external SoC pins described in video-interfaces.txt[1].
-  Describing more then one endpoint in port 0 is invalid. Only VIN
-  instances that are connected to external pins should have port 0.
-- port 1 - sub-nodes describing one or more endpoints connected to
+  Describing more then one endpoint in port@0 is invalid. Only VIN


   s/then/than/.


+  instances that are connected to external pins should have port@0.
+- port@1 - sub-nodes describing one or more endpoints connected to
the VIN from local SoC CSI-2 receivers. The endpoint numbers must
use the following schema.

[...]

MBR, Sergei

Re: [PATCH] rcar-vin: sync which hardware buffer to start capture from

[Sergei Shtylyov]

Hello!

On 5/17/2018 2:22 AM, Niklas Söderlund wrote:


When starting the VIN capture procedure we are not guaranteed that the
first buffer writing to is VnMB1 to which we assigned the first buffer


   Written, perhaps?


queued. This is problematic for two reasons. Buffers might not be
dequeued in the same order they where queued for capture. Future
features planed for the VIN driver is support for outputing frames in


   Outputting.


SEQ_TB/BT format and to do that it's important that capture starts from
the first buffer slot, VnMB1.

We are guaranteed that capturing always happens in sequence (VnMB1 ->
VnMB2 -> VnMB3 -> VnMB1). So drop up to two frames when starting
capturing so that the driver always returns buffers in the same order
they are queued and prepare for SEQ_TB/BT output.

Signed-off-by: Niklas Söderlund 
---
  drivers/media/platform/rcar-vin/rcar-dma.c | 16 +++-
  drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
  2 files changed, 17 insertions(+), 1 deletion(-)


[...]

MBR, Sergei

Re: [PATCH 3/6] media: rcar-vin: Handle data-active property

[Sergei Shtylyov]

Hello!

On 5/16/2018 7:32 PM, Jacopo Mondi wrote:


The data-active property has to be specified when running with embedded


   Prop names are typically enclosed in "".


synchronization. The VIN peripheral can use HSYNC in place of CLOCKENB


   CLKENB, maybe?


when the CLOCKENB pin is not connected, this requires explicit
synchronization to be in use.

Now that the driver supports 'data-active' property, it makes not sense


   "data-active", s/not/no/.


to zero the mbus configuration flags when running with implicit synch


   Sync is better. :-)


(V4L2_MBUS_BT656).

Signed-off-by: Jacopo Mondi 

[...]

MBR, Sergei

Re: [PATCH 5/5] media: rcar-vin: Use FTEV for digital input

[Sergei Shtylyov]

Hello!

On 5/11/2018 12:59 PM, Jacopo Mondi wrote:


Since commit (015060cb


   Need 12 digits here, and SHA1 ID should be cited outside the parens.


"media: rcar-vin: enable field toggle after a set
number of lines for Gen3)


   The commit summary must be enclosed in ("").
   And I think Niklas has posted the patches reverting that commit and fixing 
the driver properly.



the VIN generates an internal field signal
toggle after a fixed number of received lines, and uses the internal
field signal to drive capture operations. When capturing from digital
input, using FTEH driven field signal toggling messes up the received
image sizes. Fall back to use FTEV driven signal toggling when capturing
from digital input.

As explained in the comment, this disables buffer overflow protection
for digital input capture, for which the FOE overflow might be used in
future.

Signed-off-by: Jacopo Mondi 

[...]

MBR, Sergei

Re: [PATCH v2 2/2] rcar-vin: fix crop and compose handling for Gen3

[Sergei Shtylyov]

Hello!

On 05/11/2018 05:41 PM, Niklas Söderlund wrote:

> When refactoring the Gen3 enablement series crop and compose handling
> where broken. This went unnoticed but can result in writing out side the

   s/Where/Were/?

> capture buffer. Fix this by restoring the crop and compose to reflect
> the format dimensions as we have not yet enabled the scaler for Gen3.
> 
> Fixes: 5e7c623632fcf8f5 ("media: rcar-vin: use different v4l2 operations in 
> media controller mode")
> Reported-by: Jacopo Mondi 
> Signed-off-by: Niklas Söderlund 
[...]

MBR, Sergei

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

[Sergei Shtylyov]

Hello!

On 4/28/2018 12:46 AM, 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 <nobuhiro.iwamatsu...@renesas.com>
Cc: Kieran Bingham <kieran.bingham+rene...@ideasonboard.com>
Cc: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
Cc: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
Cc: Wolfram Sang <wsa+rene...@sang-engineering.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>

[...]

Acked-by: Sergei Shtylyov<sergei.shtyl...@cogentembedded.com>

MBR, Sergei

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

[Sergei Shtylyov]

On 04/20/2018 04:28 PM, 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>
[...]

Acked-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

MBR, Sergei

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

[Sergei Shtylyov]

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?

> 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 v7] media: platform: Renesas IMR driver

[Sergei Shtylyov]

On 04/16/2018 04:27 PM, Geert Uytterhoeven wrote:

>> The image renderer, or the distortion correction engine, is a drawing
>> processor with a simple instruction system capable of referencing video
>> capture data or data in an external memory as the 2D texture data and
>> performing texture mapping and drawing with respect to any shape that is
>> split into triangular objects.
>>
>> This V4L2 memory-to-memory device driver only supports image renderer light
>> extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
>> can be added later...
>>
>> Based on the original patch by Konstantin Kozhevnikov.
>>
>> Signed-off-by: Konstantin Kozhevnikov 
>> <konstantin.kozhevni...@cogentembedded.com>
>> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
>> Acked-by: Rob Herring <r...@kernel.org>
> 
>>  Documentation/devicetree/bindings/media/rcar_imr.txt |   27
>>  Documentation/media/v4l-drivers/index.rst|1
>>  Documentation/media/v4l-drivers/rcar_imr.rst |  372 +++
>>  drivers/media/platform/Kconfig   |   13
>>  drivers/media/platform/Makefile  |1
>>  drivers/media/platform/rcar_imr.c| 1832 
>> +++
>>  include/uapi/linux/rcar_imr.h|  182 +
>>  7 files changed, 2428 insertions(+)
> 
> What's the status of this patch?

   Changes requested, and I'm still having no bandwidth to make them... 

> The compatible value "renesas,r8a7796-imr-lx4" has been in use since v4.14.

   That's because the SoC bindings are unlikely to change...

> Thanks!
> 
> Gr{oetje,eeting}s,
> 
> Geert

MBR, Sergei

Re: [PATCH 02/15] v4l: vsp1: Remove outdated comment

[Sergei Shtylyov]

Hello!

On 2/27/2018 12:45 AM, Laurent Pinchart wrote:


The entities in the pipeline are all started when the LIF is setup.
Remove the outdated comment that state otherwise.


   States?


Signed-off-by: Laurent Pinchart 

[...]

MBR, Sergei

Re: [PATCH v4] v4l: vsp1: Fix video output on R8A77970

[Sergei Shtylyov]

On 02/22/2018 09:46 PM, Laurent Pinchart wrote:

>>> From: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
>>>
>>> Commit d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL,
>>> and VSP2-D instances") added support for the VSP2-D found in the R-Car
>>> V3M (R8A77970) but the video output that VSP2-D sends to DU has a greenish
>>> garbage-like line repeated every 8 screen rows. It turns out that R-Car
>>> V3M has the LIF0 buffer attribute register that you need to set to a non-
>>> default value in order to get rid of the output artifacts.
>>>
>>> Based on the original (and large) patch by Daisuke Matsushita
>>> <daisuke.matsushita...@hitachi.com>.
>>>
>>> Fixes: d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and
>>> VSP2-D instances") Signed-off-by: Sergei Shtylyov
>>> <sergei.shtyl...@cogentembedded.com> Reviewed-by: Laurent Pinchart
>>> <laurent.pinchart+rene...@ideasonboard.com> [Removed braces, added
>>> VI6_IP_VERSION_MASK to improve readabiliy]
>>> Signed-off-by: Laurent Pinchart
>>> <laurent.pinchart+rene...@ideasonboard.com>
>>
>> [...]
>>
>>> diff --git a/drivers/media/platform/vsp1/vsp1_regs.h
>>> b/drivers/media/platform/vsp1/vsp1_regs.h index
>>> b1912c83a1da..dae0c1901297 100644
>>> --- a/drivers/media/platform/vsp1/vsp1_regs.h
>>> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
>>
>> [...]
>>
>>> @@ -705,6 +710,7 @@
>>>   */
>>>  
>>>  #define VI6_IP_VERSION 0x3f00
>>>
>>> +#define VI6_IP_VERSION_MASK(0x << 0)
>>
>> Perhaps (VI6_IP_VERSION_MODEL_MASK | VI6_IP_VERSION_SOC_MASK) would be 
>> clearer?
> 
> I thought about it and the line length went over 80 characters so I went for 
> an easy solution. I can change it if you want.

   OK, let's be leave it as is.

MBR, Sergei

Re: [PATCH v3] vsp1: fix video output on R8A77970

[Sergei Shtylyov]

On 02/22/2018 07:26 PM, Laurent Pinchart wrote:
> Hi Sergei,
> 
> Thank you for the patch.
> 
> On Thursday, 18 January 2018 16:05:51 EET Sergei Shtylyov wrote:
>> Commit d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL,
>> and VSP2-D instances") added support for the VSP2-D found in the R-Car
>> V3M (R8A77970) but the video output that VSP2-D sends to DU has a greenish
>> garbage-like line repeated every 8 screen rows. It turns out that R-Car
>> V3M has the LIF0 buffer attribute register that you need to set to a non-
>> default value in order to get rid of the output artifacts...
>>
>> Based on the original (and large) patch by Daisuke Matsushita
>> <daisuke.matsushita...@hitachi.com>.
>>
>> Fixes: d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and
>> VSP2-D instances") Signed-off-by: Sergei Shtylyov
>> <sergei.shtyl...@cogentembedded.com>
>>
>> ---
>> This patch is against the 'media_tree.git' repo's 'fixes' branch.
>>
>> Changes in version 3:
>> - reworded the comment in lif_configure();
>> - reworded the patch description.
>>
>> Changes in version 2:
>> - added a  comment before the V3M SoC check;
>> - fixed indetation in that check;
>> - reformatted  the patch description.
>>
>>  drivers/media/platform/vsp1/vsp1_lif.c  |   15 +++
>>  drivers/media/platform/vsp1/vsp1_regs.h |5 +
>>  2 files changed, 20 insertions(+)
>>
>> Index: media_tree/drivers/media/platform/vsp1/vsp1_lif.c
>> ===
>> --- media_tree.orig/drivers/media/platform/vsp1/vsp1_lif.c
>> +++ media_tree/drivers/media/platform/vsp1/vsp1_lif.c
>> @@ -155,6 +155,21 @@ static void lif_configure(struct vsp1_en
>>  (obth << VI6_LIF_CTRL_OBTH_SHIFT) |
>>  (format->code == 0 ? VI6_LIF_CTRL_CFMT : 0) |
>>  VI6_LIF_CTRL_REQSEL | VI6_LIF_CTRL_LIF_EN);
>> +
>> +/*
>> + * On R-Car V3M the LIF0 buffer attribute register has to be set
>> + * to a non-default value to guarantee proper operation (otherwise
>> + * artifacts may appear on the output). The value required by
>> + * the manual is not explained but is likely a buffer size or
>> + * threshold...
> 
> One period is enough :-)

   Naw, I just like ellipsis! :-)

>> + */
>> +if ((entity->vsp1->version &
>> + (VI6_IP_VERSION_MODEL_MASK | VI6_IP_VERSION_SOC_MASK)) ==
>> +(VI6_IP_VERSION_MODEL_VSPD_V3 | VI6_IP_VERSION_SOC_V3M)) {
>> +vsp1_lif_write(lif, dl, VI6_LIF_LBA,
>> +   VI6_LIF_LBA_LBA0 |
>> +   (1536 << VI6_LIF_LBA_LBA1_SHIFT));
>> +}
> 
> There's no need for braces

   Well, multi-line statement was asking for them...

> or inner parentheses.

   I thought so too. :-)

> To make this easier to read I 
> propose defining a new macro VI6_IP_VERSION_MASK that combines both the model 
> and SoC. Otherwise this looks good to me,
> 
> Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> 
> I'll post a v4 with that change in reply to this e-mail, please let me know 
> if 
> you're fine with it.

   Generally fine, yes...

[...]

MBR, Sergei

Re: [PATCH v4] v4l: vsp1: Fix video output on R8A77970

[Sergei Shtylyov]

On 02/22/2018 07:32 PM, Laurent Pinchart wrote:

> From: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
> 
> Commit d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL,
> and VSP2-D instances") added support for the VSP2-D found in the R-Car
> V3M (R8A77970) but the video output that VSP2-D sends to DU has a greenish
> garbage-like line repeated every 8 screen rows. It turns out that R-Car
> V3M has the LIF0 buffer attribute register that you need to set to a non-
> default value in order to get rid of the output artifacts.
> 
> Based on the original (and large) patch by Daisuke Matsushita
> <daisuke.matsushita...@hitachi.com>.
> 
> Fixes: d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and 
> VSP2-D instances")
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> [Removed braces, added VI6_IP_VERSION_MASK to improve readabiliy]
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>

[...]
> diff --git a/drivers/media/platform/vsp1/vsp1_regs.h 
> b/drivers/media/platform/vsp1/vsp1_regs.h
> index b1912c83a1da..dae0c1901297 100644
> --- a/drivers/media/platform/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
[...]
> @@ -705,6 +710,7 @@
>   */
>  
>  #define VI6_IP_VERSION   0x3f00
> +#define VI6_IP_VERSION_MASK  (0x << 0)

   Perhaps (VI6_IP_VERSION_MODEL_MASK | VI6_IP_VERSION_SOC_MASK) would be 
clearer?

MBR, Sergei

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

[Sergei Shtylyov]

Hello!

On 1/30/2018 12:58 PM, 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 
---
  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 ab9645a..5fe62f9 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi

[...]

@@ -667,4 +667,13 @@
power-domains = <_clocks>;
status = "disabled";
};
+
+   ceu: ceu@e821 {


   The DT spec dictates the generic node names should be used. For the R-Car 
VIN we use "video@...", hence I suggest that use the same here.



+   reg = <0xe821 0x3000>;
+   compatible = "renesas,r7s72100-ceu";
+   interrupts = ;
+   clocks = <_clks R7S72100_CLK_CEU>;
+   power-domains = <_clocks>;
+   status = "disabled";
+   };
  };


MBR, Sergei

[PATCH v3] vsp1: fix video output on R8A77970

[Sergei Shtylyov]

Commit d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL,
and VSP2-D instances") added support for the VSP2-D found in the R-Car
V3M (R8A77970) but the video output that VSP2-D sends to DU has a greenish
garbage-like line repeated every 8 screen rows. It turns out that R-Car
V3M has the LIF0 buffer attribute register that you need to set to a non-
default value in order to get rid of the output artifacts...

Based on the original (and large) patch by Daisuke Matsushita
<daisuke.matsushita...@hitachi.com>.

Fixes: d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and 
VSP2-D instances")
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'fixes' branch.

Changes in version 3:
- reworded the comment in lif_configure();
- reworded the patch description.

Changes in version 2:
- added a  comment before the V3M SoC check;
- fixed indetation in that check;
- reformatted  the patch description.

 drivers/media/platform/vsp1/vsp1_lif.c  |   15 +++
 drivers/media/platform/vsp1/vsp1_regs.h |5 +
 2 files changed, 20 insertions(+)

Index: media_tree/drivers/media/platform/vsp1/vsp1_lif.c
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_lif.c
+++ media_tree/drivers/media/platform/vsp1/vsp1_lif.c
@@ -155,6 +155,21 @@ static void lif_configure(struct vsp1_en
(obth << VI6_LIF_CTRL_OBTH_SHIFT) |
(format->code == 0 ? VI6_LIF_CTRL_CFMT : 0) |
VI6_LIF_CTRL_REQSEL | VI6_LIF_CTRL_LIF_EN);
+
+   /*
+* On R-Car V3M the LIF0 buffer attribute register has to be set
+* to a non-default value to guarantee proper operation (otherwise
+* artifacts may appear on the output). The value required by
+* the manual is not explained but is likely a buffer size or
+* threshold...
+*/
+   if ((entity->vsp1->version &
+(VI6_IP_VERSION_MODEL_MASK | VI6_IP_VERSION_SOC_MASK)) ==
+   (VI6_IP_VERSION_MODEL_VSPD_V3 | VI6_IP_VERSION_SOC_V3M)) {
+   vsp1_lif_write(lif, dl, VI6_LIF_LBA,
+  VI6_LIF_LBA_LBA0 |
+  (1536 << VI6_LIF_LBA_LBA1_SHIFT));
+   }
 }
 
 static const struct vsp1_entity_operations lif_entity_ops = {
Index: media_tree/drivers/media/platform/vsp1/vsp1_regs.h
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_regs.h
+++ media_tree/drivers/media/platform/vsp1/vsp1_regs.h
@@ -693,6 +693,11 @@
 #define VI6_LIF_CSBTH_LBTH_MASK(0x7ff << 0)
 #define VI6_LIF_CSBTH_LBTH_SHIFT   0
 
+#define VI6_LIF_LBA0x3b0c
+#define VI6_LIF_LBA_LBA0   (1 << 31)
+#define VI6_LIF_LBA_LBA1_MASK  (0xfff << 16)
+#define VI6_LIF_LBA_LBA1_SHIFT 16
+
 /* 
-
  * Security Control Registers
  */

Re: [PATCH -next] media: rcar_drif: fix error return code in rcar_drif_alloc_dmachannels()

[Sergei Shtylyov]

Hello!

On 01/17/2018 02:24 PM, Wei Yongjun wrote:


Fix to return error code -ENODEV from the dma_request_slave_channel()
error handling case instead of 0, as done elsewhere in this function.
rc can be overwrite to 0 by dmaengine_slave_config() in the for loop.


   Overwritten.


Signed-off-by: Wei Yongjun 

[...]

MBR, Sergei

Re: [PATCH v2] vsp1: fix video output on R8A77970

[Sergei Shtylyov]

Hello!

On 01/15/2018 03:51 PM, Laurent Pinchart wrote:


On Tuesday, 26 December 2017 23:14:12 EET Sergei Shtylyov wrote:

Laurent has added support for the VSP2-D found on R-Car V3M (R8A77970) but


I'm not sure there's a need to state my name in the commit message.


   You were the author of the patch this one has in the Fixes: tag, so I 
thought that was appropriate. I can remove that if you don't want you name 
mentioned...



the video  output that VSP2-D sends to DU has a greenish garbage-like line


Why does the text in your patches (commit message, comments, ...) sometime
have double spaces between words ?


   The text looks more pleasant (at least to me). Can remove them if you want...


repeated every 8 or so screen rows.


Is it every "8 or so" rows, or exactly every 8 rows ?


   You really want me to count the pixels?


It turns out that V3M has a teeny LIF register (at least it's documented!)
that you need to set to some kind of a  magic value for the LIF to work
correctly...

Based on the original (and large) patch by Daisuke Matsushita
<daisuke.matsushita...@hitachi.com>.


What else is in the big patch ? Is it available somewhere ?


   Assorted changes gathered together only because they all bring the support 
for R8A77970. If you're really curious, here you are:


https://github.com/CogentEmbedded/meta-rcar/blob/v2.12.0/meta-rcar-gen3/recipes-kernel/linux/linux-renesas/0030-arm64-renesas-r8a7797-Add-Renesas-R8A7797-SoC-suppor.patch


Fixes: d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and
VSP2-D instances")
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

Changes in version 2:
- added a  comment before the V3M SoC check;
- fixed indetation in that check;
- reformatted  the patch description.

  drivers/media/platform/vsp1/vsp1_lif.c  |   12 
  drivers/media/platform/vsp1/vsp1_regs.h |5 +
  2 files changed, 17 insertions(+)

Index: media_tree/drivers/media/platform/vsp1/vsp1_lif.c
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_lif.c
+++ media_tree/drivers/media/platform/vsp1/vsp1_lif.c
@@ -155,6 +155,18 @@ static void lif_configure(struct vsp1_en
(obth << VI6_LIF_CTRL_OBTH_SHIFT) |
(format->code == 0 ? VI6_LIF_CTRL_CFMT : 0) |
VI6_LIF_CTRL_REQSEL | VI6_LIF_CTRL_LIF_EN);
+
+   /*
+* R-Car V3M has the buffer attribute register you absolutely need
+* to write kinda magic value to  for the LIF to work correctly...
+*/


I'm not sure about the "kinda" magic value. 1536 is very likely a buffer size.


   Well, that's only guessing. The manual doesn't say anything about what the 
number is.



How about the following text ?

/*
 * On V3M the LBA register has to be set to a non-default value to


   I'd then spell its full name, LIF0 Buffer Attribute register.


 * guarantee proper operation (otherwise artifacts may appear on the
 * output). The value required by the datasheet is not documented but
 * is likely a buffer size or threshold.
 */

>

   OK,  can change that (modulo the name).


The commit message should also be updated to feel a bit less magic.


   I'll see about it.


+   if ((entity->vsp1->version &
+(VI6_IP_VERSION_MODEL_MASK | VI6_IP_VERSION_SOC_MASK)) ==
+   (VI6_IP_VERSION_MODEL_VSPD_V3 | VI6_IP_VERSION_SOC_V3M)) {
+   vsp1_lif_write(lif, dl, VI6_LIF_LBA,
+  VI6_LIF_LBA_LBA0 |
+  (1536 << VI6_LIF_LBA_LBA1_SHIFT));
+   }
  }


The datasheet documents the register as being present on both V3M and M3-W
(and the test I've just run on H3 shows that the register is present there as
well). Should we program it on M3-W or leave it to the default value that
should be what is recommended by the datasheet for that SoC ?


   If the default value matches what's recommended by the manual, then I'd 
leave the register alone. But my task was R8A77970 support only anyway...



[..]

MBR, Sergei

[PATCH v2] vsp1: fix video output on R8A77970

[Sergei Shtylyov]

Laurent has added support for the VSP2-D found on R-Car V3M (R8A77970) but
the video  output that VSP2-D sends to DU has a greenish garbage-like line
repeated every 8 or so screen rows. It turns out that V3M has a teeny LIF
register (at least it's documented!) that you need to set to some kind of
a  magic value for the LIF to work correctly...

Based on the original (and large) patch by Daisuke Matsushita
<daisuke.matsushita...@hitachi.com>.

Fixes: d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and 
VSP2-D instances")
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

Changes in version 2:
- added a  comment before the V3M SoC check;
- fixed indetation in that check;
- reformatted  the patch description.

 drivers/media/platform/vsp1/vsp1_lif.c  |   12 
 drivers/media/platform/vsp1/vsp1_regs.h |5 +
 2 files changed, 17 insertions(+)

Index: media_tree/drivers/media/platform/vsp1/vsp1_lif.c
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_lif.c
+++ media_tree/drivers/media/platform/vsp1/vsp1_lif.c
@@ -155,6 +155,18 @@ static void lif_configure(struct vsp1_en
(obth << VI6_LIF_CTRL_OBTH_SHIFT) |
(format->code == 0 ? VI6_LIF_CTRL_CFMT : 0) |
VI6_LIF_CTRL_REQSEL | VI6_LIF_CTRL_LIF_EN);
+
+   /*
+* R-Car V3M has the buffer attribute register you absolutely need
+* to write kinda magic value to  for the LIF to work correctly...
+*/
+   if ((entity->vsp1->version &
+(VI6_IP_VERSION_MODEL_MASK | VI6_IP_VERSION_SOC_MASK)) ==
+   (VI6_IP_VERSION_MODEL_VSPD_V3 | VI6_IP_VERSION_SOC_V3M)) {
+   vsp1_lif_write(lif, dl, VI6_LIF_LBA,
+  VI6_LIF_LBA_LBA0 |
+  (1536 << VI6_LIF_LBA_LBA1_SHIFT));
+   }
 }
 
 static const struct vsp1_entity_operations lif_entity_ops = {
Index: media_tree/drivers/media/platform/vsp1/vsp1_regs.h
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_regs.h
+++ media_tree/drivers/media/platform/vsp1/vsp1_regs.h
@@ -693,6 +693,11 @@
 #define VI6_LIF_CSBTH_LBTH_MASK(0x7ff << 0)
 #define VI6_LIF_CSBTH_LBTH_SHIFT   0
 
+#define VI6_LIF_LBA0x3b0c
+#define VI6_LIF_LBA_LBA0   (1 << 31)
+#define VI6_LIF_LBA_LBA1_MASK  (0xfff << 16)
+#define VI6_LIF_LBA_LBA1_SHIFT 16
+
 /* 
-
  * Security Control Registers
  */

Re: [PATCH] vsp1: fix video output on R8A77970

[Sergei Shtylyov]

Hello!

On 12/26/2017 12:21 AM, Sergei Shtylyov wrote:


Laurent has added support for the VSP2-D found on R-Car V3M (R8A77970) but
the video output that VSP2-D sends to DU has a greenish garbage-like line
repeated every 8 or so screen rows.  It turns out that V3M has a teeny LIF
register (at least it's documented!) that you need to set to some kind of
a magic value for the LIF to work correctly...

Based on the original (and large) patch by  Daisuke Matsushita
<daisuke.matsushita...@hitachi.com>.

Fixes: d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and VSP2-D 
instances")
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

 drivers/media/platform/vsp1/vsp1_lif.c  |8 
 drivers/media/platform/vsp1/vsp1_regs.h |5 +
 2 files changed, 13 insertions(+)

Index: media_tree/drivers/media/platform/vsp1/vsp1_lif.c
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_lif.c
+++ media_tree/drivers/media/platform/vsp1/vsp1_lif.c
@@ -155,6 +155,14 @@ static void lif_configure(struct vsp1_en
(obth << VI6_LIF_CTRL_OBTH_SHIFT) |
(format->code == 0 ? VI6_LIF_CTRL_CFMT : 0) |
VI6_LIF_CTRL_REQSEL | VI6_LIF_CTRL_LIF_EN);
+


   I remember I was going to add a comment here but apparently forgot to do 
it yesterday... Will repost.



+   if ((entity->vsp1->version &
+   (VI6_IP_VERSION_MODEL_MASK | VI6_IP_VERSION_SOC_MASK)) ==
+   (VI6_IP_VERSION_MODEL_VSPD_V3 | VI6_IP_VERSION_SOC_V3M)) {
+   vsp1_lif_write(lif, dl, VI6_LIF_LBA,
+  VI6_LIF_LBA_LBA0 |
+  (1536 << VI6_LIF_LBA_LBA1_SHIFT));
+   }
 }

[...]

MBR, Sergei

[PATCH] vsp1: fix video output on R8A77970

[Sergei Shtylyov]

Laurent has added support for the VSP2-D found on R-Car V3M (R8A77970) but
the video output that VSP2-D sends to DU has a greenish garbage-like line
repeated every 8 or so screen rows.  It turns out that V3M has a teeny LIF
register (at least it's documented!) that you need to set to some kind of
a magic value for the LIF to work correctly...

Based on the original (and large) patch by  Daisuke Matsushita
<daisuke.matsushita...@hitachi.com>.

Fixes: d455b45f8393 ("v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and 
VSP2-D instances")
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

 drivers/media/platform/vsp1/vsp1_lif.c  |8 
 drivers/media/platform/vsp1/vsp1_regs.h |5 +
 2 files changed, 13 insertions(+)

Index: media_tree/drivers/media/platform/vsp1/vsp1_lif.c
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_lif.c
+++ media_tree/drivers/media/platform/vsp1/vsp1_lif.c
@@ -155,6 +155,14 @@ static void lif_configure(struct vsp1_en
(obth << VI6_LIF_CTRL_OBTH_SHIFT) |
(format->code == 0 ? VI6_LIF_CTRL_CFMT : 0) |
VI6_LIF_CTRL_REQSEL | VI6_LIF_CTRL_LIF_EN);
+
+   if ((entity->vsp1->version &
+   (VI6_IP_VERSION_MODEL_MASK | VI6_IP_VERSION_SOC_MASK)) ==
+   (VI6_IP_VERSION_MODEL_VSPD_V3 | VI6_IP_VERSION_SOC_V3M)) {
+   vsp1_lif_write(lif, dl, VI6_LIF_LBA,
+  VI6_LIF_LBA_LBA0 |
+  (1536 << VI6_LIF_LBA_LBA1_SHIFT));
+   }
 }
 
 static const struct vsp1_entity_operations lif_entity_ops = {
Index: media_tree/drivers/media/platform/vsp1/vsp1_regs.h
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_regs.h
+++ media_tree/drivers/media/platform/vsp1/vsp1_regs.h
@@ -693,6 +693,11 @@
 #define VI6_LIF_CSBTH_LBTH_MASK(0x7ff << 0)
 #define VI6_LIF_CSBTH_LBTH_SHIFT   0
 
+#define VI6_LIF_LBA0x3b0c
+#define VI6_LIF_LBA_LBA0   (1 << 31)
+#define VI6_LIF_LBA_LBA1_MASK  (0xfff << 16)
+#define VI6_LIF_LBA_LBA1_SHIFT 16
+
 /* 
-
  * Security Control Registers
  */

Re: [PATCH 5/9] v4l: vsp1: Document the vsp1_du_atomic_config structure

[Sergei Shtylyov]

Hello!

On 12/3/2017 1:57 PM, Laurent Pinchart wrote:


The structure is used in the API that the VSP1 driver exposes to the DU
driver. Documenting it is thus important.

Signed-off-by: Laurent Pinchart 
---
  include/media/vsp1.h | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 68a8abe4fac5..7850f96fb708 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -41,6 +41,16 @@ struct vsp1_du_lif_config {
  int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
  const struct vsp1_du_lif_config *cfg);
  
+/**

+ * struct vsp1_du_atomic_config - VSP atomic configuration parameters
+ * @pixelformat: plan pixel format (V4L2 4CC)


   s/plan/plane/?

[...]

MBR, Sergei

Re: [PATCH 07/13] media: soc_camera pad-aware driver initialisation

[Sergei Shtylyov]

On 10/27/2017 10:52 AM, Sergei Shtylyov wrote:


Add detection of source pad number for drivers aware of the media
controller API, so that the combination of soc_camera and rcar_vin
can create device nodes to support modern drivers such as adv7604.c
(for HDMI on Lager) and the converted adv7180.c (for composite)
underneath.

Building rcar_vin gains a dependency on CONFIG_MEDIA_CONTROLLER, in
line with requirements for building the drivers associated with it.

Signed-off-by: William Towle <william.to...@codethink.co.uk>
Signed-off-by: Rob Taylor <rob.tay...@codethink.co.uk>
---
  drivers/media/platform/soc_camera/Kconfig  |    1 +
  drivers/media/platform/soc_camera/rcar_vin.c   |    1 +


    This driver no longer exists. What did you base on?


   Sorry, I didn't realize I was replying to 2 years old patch. :-)

[...]

MBR, Sergei

Re: [PATCH 07/13] media: soc_camera pad-aware driver initialisation

[Sergei Shtylyov]

Hello!

On 7/23/2015 2:21 PM, William Towle wrote:


Add detection of source pad number for drivers aware of the media
controller API, so that the combination of soc_camera and rcar_vin
can create device nodes to support modern drivers such as adv7604.c
(for HDMI on Lager) and the converted adv7180.c (for composite)
underneath.

Building rcar_vin gains a dependency on CONFIG_MEDIA_CONTROLLER, in
line with requirements for building the drivers associated with it.

Signed-off-by: William Towle 
Signed-off-by: Rob Taylor 
---
  drivers/media/platform/soc_camera/Kconfig  |1 +
  drivers/media/platform/soc_camera/rcar_vin.c   |1 +


   This driver no longer exists. What did you base on?


  drivers/media/platform/soc_camera/soc_camera.c |   36 
  include/media/soc_camera.h |1 +
  4 files changed, 39 insertions(+)

[...]

@@ -1310,8 +1313,33 @@ static int soc_camera_probe_finish(struct 
soc_camera_device *icd)
return ret;
}
  
+	icd->src_pad_idx = 0;

+#if defined(CONFIG_MEDIA_CONTROLLER)
/* At this point client .probe() should have run already */
+   ret = media_entity_init(>vdev->entity, 1, , 0);
+   if (ret < 0) {
+   goto eusrfmt;
+   } else {
+   int pad_idx;
+
+   for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++)
+   if (sd->entity.pads[pad_idx].flags
+   == MEDIA_PAD_FL_SOURCE)


   Please leave == on the previous line...

[...]

MBR, Sergei

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 09/19/2017 01:59 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
  Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
  1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
  - adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
generator. The chip will rely on the sync signals in the DSI data lanes,
rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


It's called "phandle" in the DT speak. :-)
Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


   No, you only say that there'll be the clock phandle only. The clock
specifier may follow the phandle for the clock devices that have
"#clock-cells" prop != 0.


I have to say that I just copy-and-pasted this from other bindings.


  :-)


Would this be better?

- clocks: list of clock specifiers, corresponding to entries in
 the clock-names property;


  Didn't you say that there'll be only one clock, "cec"? If so, there's
gonna  be a single clock phandle+specifier pair. They always go in pairs. :-)


- clock-names: from common clock binding: must be "cec".


- clocks: cec clock phandle, corresponding to the clock-names entry.


 The clock phandle and specifier.


- clock-names: from common clock binding: must be "cec".

This OK?


 Well, you seem to be going in circles, the above was almost the same as
the original prop description...


- clocks: from common clock binding: reference to the CEC clock.
- clock-names: from common clock binding: must be "cec".

This avoids the whole issue of having just a phandle or a phandle + specifier.


   OK, let's go with this one. Thank you!


Regards,

Hans


MBR, Sergei

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 9/19/2017 1:35 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
 - adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
   generator. The chip will rely on the sync signals in the DSI data lanes,
   rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


   It's called "phandle" in the DT speak. :-)
   Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


  No, you only say that there'll be the clock phandle only. The clock
specifier may follow the phandle for the clock devices that have
"#clock-cells" prop != 0.


I have to say that I just copy-and-pasted this from other bindings.


 :-)


Would this be better?

- clocks: list of clock specifiers, corresponding to entries in
the clock-names property;


 Didn't you say that there'll be only one clock, "cec"? If so, there's
gonna  be a single clock phandle+specifier pair. They always go in pairs. :-)


- clock-names: from common clock binding: must be "cec".


- clocks: cec clock phandle, corresponding to the clock-names entry.


   The clock phandle and specifier.


- clock-names: from common clock binding: must be "cec".

This OK?


   Well, you seem to be going in circles, the above was almost the same as 
the original prop description...



Regards,

Hans


MBR, Sergei

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 9/19/2017 1:07 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
- adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
  generator. The chip will rely on the sync signals in the DSI data lanes,
  rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


  It's called "phandle" in the DT speak. :-)
  Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


 No, you only say that there'll be the clock phandle only. The clock
specifier may follow the phandle for the clock devices that have
"#clock-cells" prop != 0.


I have to say that I just copy-and-pasted this from other bindings.


   :-)


Would this be better?

- clocks: list of clock specifiers, corresponding to entries in
   the clock-names property;


   Didn't you say that there'll be only one clock, "cec"? If so, there's 
gonna  be a single clock phandle+specifier pair. They always go in pairs. :-)



- clock-names: from common clock binding: must be "cec".

Regards,

Hans


MBR, Sergei

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

On 9/19/2017 12:29 PM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
   Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
   1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
   - adi,disable-timing-generator: Only for ADV7533. Disables the internal 
timing
 generator. The chip will rely on the sync signals in the DSI data lanes,
 rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


 It's called "phandle" in the DT speak. :-)
 Are you sure the clock specifier would always be absent?


Sorry? I don't understand the question. Did you mean: "can be absent?"?


   No, you only say that there'll be the clock phandle only. The clock 
specifier may follow the phandle for the clock devices that have 
"#clock-cells" prop != 0.



Regards,

 Hans

[...]

MBR, Sergei

Re: [PATCHv2 1/2] dt-bindings: adi,adv7511.txt: document cec clock

[Sergei Shtylyov]

Hello!

On 9/19/2017 10:33 AM, Hans Verkuil wrote:


From: Hans Verkuil 

Document the cec clock binding.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
  Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 
  1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
  - adi,disable-timing-generator: Only for ADV7533. Disables the internal timing
generator. The chip will rely on the sync signals in the DSI data lanes,
rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.


   It's called "phandle" in the DT speak. :-)
   Are you sure the clock specifier would always be absent?


+- clock-names: from common clock binding: must be "cec".
  
  Required nodes:
  

[...]

MBR, Sergei

Re: [PATCH v7] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 08/17/2017 10:59 AM, Hans Verkuil wrote:


A quick review. I'm concentrating on the mesh ioctl, since that's what sets this
driver apart.


   OK, waiting for the detailed review...


Index: media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
===
--- /dev/null
+++ media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
@@ -0,0 +1,372 @@
+Renesas R-Car Image Renderer (IMR) Driver
+=
+
+This file documents some driver-specific aspects of the IMR driver, such as
+the driver-specific ioctl.


Just drop the part ', such as...'.

Can you add a high-level description of the functionality here? Similar to what
you did in the bindings document.


   Sure, I can.


+
+The ioctl reference
+~~~
+
+See ``include/uapi/linux/rcar_imr.h`` for the data structures used.
+
+VIDIOC_IMR_MESH - Set mapping data
+^^
+
+Argument: ``struct imr_map_desc``
+
+**Description**:
+
+This ioctl sets up the mesh through which the input frames will be transformed
+into the output frames. The mesh can be strictly rectangular (when
+``IMR_MAP_MESH`` bit is set in ``imr_map_desc::type``) or arbitrary (when that
+bit is not set).


Wouldn't something like 'IMR_MAP_RECTANGULAR' be much more descriptive than 
_MESH?
There is nothing in the name _MESH to indicate that this switches the data to
rectangles.


   Well, in my Russian mind, mesh consists of the rectangles. :-)


+
+A rectangular mesh consists of the imr_mesh structure followed by M*N vertex
+objects (where M is ``imr_mesh::rows`` and N is ``imr_mesh::columns``).
+In case either ``IMR_MAP_AUTOSG`` or ``IMR_MAP_AUTODG`` (not both) bits are
+set in ``imr_map_desc::type``, ``imr_mesh::{x|y}0`` specify the coordinates
+of the top left corner of the auto-generated mesh and ``imr_mesh::d{x|y}``
+specify the mesh's X/Y steps.


So if the auto bits are set, then there are no vertex objects?


   No, there are no source or destination (not both) coordinate structures 
present in the vertex object; at least one of them must always be there.



Since it's auto generated by the hardware?


   Yes.


I believe we discussed in the past whether 'type' should be split in a 'type'
and 'flags' field.


   In this version, I still tried Cogent's original userland working, so the 
structures were left intact (aside of renaming).



+
+An arbitrary mesh consists of the imr_vbo structure followed by N triangle
+objects (where N is ``imr_vbo::num``), consisting of 3 vertex objects each.
+Setting ``IMR_MAP_AUTODG`` and ``IMR_MAP_AUTOSG`` bits in
+``imr_map_desc::type``) isn't allowed for this type of mesh.
+
+The vertex object has a complex structure depending on some of the bits in
+``imr_map_desc::type``:
+
+    ==  ==  
===
+IMR_MAP_CLCE  IMR_MAP_LUCE  IMR_MAP_AUTODG  IMR_MAP_AUTOSG  Vertex structure 
variant


You should explain the meaning of these bits in this section. I.e., what does
CLCE or AUTODG stand for?


   I think I have explained the IRM_MAPO_AUTO* bits above.


+    ==  ==  
===
+\   ``imr_full_coord``
+\   X   ``imr_dst_coord``
+\   X   ``imr_src_coord``
+\ X 
``imr_full_coord_any_correct``
+\ X X   
``imr_auto_coord_any_correct``
+\ X X   
``imr_auto_coord_any_crrect``


crrect -> correct


+X   
``imr_full_coord_any_correct``
+X   X   
``imr_auto_coord_any_correct``
+X   X   
``imr_auto_coord_any_correct``
+X X 
``imr_full_coord_both_correct``
+X X X   
``imr_auto_coord_both_correct``
+X X X   
``imr_auto_coord_both_correct``
+    ==  ==  
===
+
+The luma correction is calculated according to the following formula (where
+``Y`` is the luma value after texture mapping, ``Y'`` is the luma value after
+luma correction, ``lscal`` and ``lofst`` are the luma correction scale and
+offset taken from ``struct imr_luma_correct``, ``YLDPO`` is a luma correction
+scale decimal point position specified by ``IMR_MAP_YLDPO(n)``): ::
+
+   Y' = ((Y * lscal) >> YLDPO) + lofst
+
+The chroma correction is calculated according to the following formula (where
+``U/V`` are the chroma values after 

[PATCH v7] media: platform: Renesas IMR driver

[Sergei Shtylyov]

The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...

Based on the original patch by Konstantin Kozhevnikov.

Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
Acked-by: Rob Herring <r...@kernel.org>

---
The patch is against the 'media_tree.git' repo's 'master' branch.

Changes in version 7:
- switched to using 'v4l2_fh::m2m_ctx' which permitted using v4l2_m2m_fop_{poll|
  mmap} instead of imr_{poll|mmap}();
- moved the configuration check from imr_qbuf() to imr_buf_prepare(), replacing
  the former with v4l2_m2m_ioctl_qbuf();
- renamed imr_cfg_[un]ref() to imr_cfg_{get|put}();
- removed VB2_USERPTR from imr_queue_init();
- removed V4L2_CAP_VIDEO_{CAPTURE|OUTPUT} device capabilities;
- replaced "luminance" with "luma" and "chrominance" with "chroma" in the
  driver and UAPI header comments;
- fixed typo in the email address in MODULE_AUTHOR();
- added the vertex-related structures to the UAPI header;
- replaced  the '__packed' annotations with explicit __attribute__((packed)) in
  the UAPI  header;
- fixed/clarified the comments in the UAPI  header;
- added the dependence table for  the vertex object variants in the driver
  document;
- added the description of the luma/chroma correction in the driver document;
- added the mesh construction code example to the driver document;
- removed the fragments effectively duplicating the UAPI hearder comments in
  the driver document, referring a reader to that header instead;
- clarified the use of the auto-generated source/destination coordinates in
  the driver document;
- marked up the references to the code in the driver document;
- fixed typo/wording in the driver document;
- removed the main text indentation in the driver document;
- changed the patch authorship to mine;
- added Rob Herring's ACK.

Changes in version 6:
- fixed the bug where if imr_cfg_create() fails, 'ctx->cfg' wasn't set to NULL
  and so wouldn't fail the validity checks;
- fixed the height minimum/alignment passed to v4l_bound_align_image();
- removed the buggy !V4L2_TYPE_IS_OUTPUT() check from imr_qbuf();
- added the driver UAPI documentation;
- replaced 'imr_ctx::crop' array with the 'imr_ctx::rect' structure;
- replaced imr_{g|s}_crop() with imr_{g|s}_selection();
- removed 'imr_format_info::name' and the related code;
- completely rewrote imr_queue_setup();
- moved the applicable code from imr_buf_queue() to imr_buf_prepare(), moved
  the  rest of imr_buf_queue() after imr_buf_finish();
- removed imr_start_streaming();
- assigned 'src_vq->dev' and 'dst_vq->dev' in imr_queue_init();
- clarified the math in imt_tri_type_{a|b|c}_length();
- removed useless local variables, added useful variables, avoided casts to
  'void *', and clarified the pointer math in imr_tri_set_type_{a|b|c}();
- replaced kmalloc()/copy_from_user() calls with memdup_user() call;
- moved the 'type' variable assignment in imr_ioctl_map() after the following
  comment;
- merged the matrix size checks for the cases of the automatic generation
  pattern and the absolute coordinates in imr_ioctl_map();
- swapped the operands in the VBO size check in imr_ioctl_map();
- moved setting device capabilities from imr_querycap() to imr_probe();
- replaced imr_{reqbufs|querybuf|dqbuf|expbuf|streamon|streamoff}() with the
  generic helpers, implemented vidioc_{create_bufs|prepare_buf}() methods;
- set the valid default queue pixel format in imr_probe();
- used tabs for indentation where possible in imr_probe();
- removed the rest of the *inline* keywords;
- declared 'imr_map_desc::data' as '__u64' instead of 'void *';
- switched to '__u{16|32}' instead of 'u{16|32}' in the UAPI header;
- spelled out the VBO abbreviation and removed redundancy in the UAPI header
  comments.

Changes in version 5:
- used ALIGN() macro in imr_ioctl_map();
- moved the display list #define's after the register #define's, removing the
  redundant comment;
- uppercased the "tbd" abbreviation in the comments;
- made the TRI instruction types A/B/C named consistently;
- avoided quotes around the coordinate's names;
- avoided some  hyphens in the comments;
- removed spaces around / and before ? in the comments;
- reworded some comments;
- reformatted some multiline comments;
- fixed typos in the comments.

Changes in version 4:
- added/used the SUSR fields/shifts.

Changes in version 3:
- added/used the {UV|CP}DPOR fields/shifts;
- removed unsupport

Re: [PATCH v6] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 07/06/2017 09:16 PM, Sergei Shtylyov wrote:

[...]

+=
+
+This file documents some driver-specific aspects of the IMR driver, such as
+driver-specific ioctls.
+
+The ioctl reference
+~~~
+
+VIDIOC_IMR_MESH - Set mapping data
+^^
+
+Argument: struct imr_map_desc
+
+**Description**:
+
+This ioctl sets up the mesh using which the input frames will be


s/using/through/


+transformed into the output frames. The mesh can be strictly rectangular
+(when IMR_MAP_MESH bit is set in imr_map_desc::type) or arbitrary (when
+that bit is not set).
+
+A rectangular mesh consists of the imr_mesh structure followed by M*N
+vertex objects (where M is imr_mesh::rows and N is imr_mesh::columns).
+In case either IMR_MAP_AUTOSG or IMR_MAP_AUTODG bits were set in
+imr_map_desc::type, imr_mesh::{x|y}0 specify the coordinates of the top
+left corner of the auto-generated mesh and imr_mesh::d{x|y} specify the
+mesh's X/Y steps.


What if any of the other types are used like IMR_MAP_LUCE?


   IMR_MAP_LUCE only affects the vertex object.


Is this documented in a Renesas datasheet?


   Yes.


   Well, not exactly. The different mesh types are a software concept, the 
hardware only understands series of triangles.


[...]


Regards,

Hans


MBR, Sergei

Re: [PATCH v6] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 07/03/2017 03:43 PM, Hans Verkuil wrote:


Index: media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
===
--- /dev/null
+++ media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
@@ -0,0 +1,86 @@
+Renesas R-Car Image Rendeder (IMR) Driver


Rendeder -> Renderer


   Oops, sorry. :-)


+=
+
+This file documents some driver-specific aspects of the IMR driver, such as
+driver-specific ioctls.
+
+The ioctl reference
+~~~
+
+VIDIOC_IMR_MESH - Set mapping data
+^^
+
+Argument: struct imr_map_desc
+
+**Description**:
+
+This ioctl sets up the mesh using which the input frames will be


s/using/through/


+transformed into the output frames. The mesh can be strictly rectangular
+(when IMR_MAP_MESH bit is set in imr_map_desc::type) or arbitrary (when
+that bit is not set).
+
+A rectangular mesh consists of the imr_mesh structure followed by M*N
+vertex objects (where M is imr_mesh::rows and N is imr_mesh::columns).
+In case either IMR_MAP_AUTOSG or IMR_MAP_AUTODG bits were set in
+imr_map_desc::type, imr_mesh::{x|y}0 specify the coordinates of the top
+left corner of the auto-generated mesh and imr_mesh::d{x|y} specify the
+mesh's X/Y steps.


What if any of the other types are used like IMR_MAP_LUCE?


   IMR_MAP_LUCE only affects the vertex object.


Is this documented in a Renesas datasheet?


   Yes.


If so, add a reference to that in this
documentation.


   Unfortunately it's not publicly available.


+
+An arbitrary mesh consists of the imr_vbo structure followed by N
+triangle objects (where N is imr_vbo::num), consisting of 3 vertex
+objects each.
+
+A vertex object has a complex structure:
+
+.. code-block:: none
+
+__u16vvertical   \ source coordinates (only present
+__u16uhorizontal / if IMR_MAP_AUTOSG isn't set)
+__u16Yvertical   \ destination coordinates (only here
+__u16Xhorizontal / if IMR_MAP_AUTODG isn't set)
+__s8lofstoffset \  luminance correction parameters
+__u8lscalscale   > (only present if IMR_MAP_LUCE
+__u16reserved   /  is set)
+__s8vrofsV value offset \  hue correction parameters
+__u8vrsclV value scale   \ (only present if IMR_MAP_CLCE
+__s8ubofsU value offset  / is set)
+__u8ubsclU value scale  /


Is this the internal structure? Or something that userspace has to fill in?


   Yes, the user space have to pass that to the driver which constructs the 
display lists using these data.



It's not clear at all.

I recommend giving a few code examples of how this should be used.


   Konstantin, can we give some examples?


+
+**Return value**:
+
+On success 0 is returned. On error -1 is returned and errno is set
+appropriately.
+
+**Data types**:
+
+.. code-block:: none
+
+* struct imr_map_desc
+
+__u32typemapping types


This is a bitmask? If so, what combination of bits are allowed?


   Yes, bitmask.


+__u32sizetotal size of the mesh structure
+__u64datamap-specific user-pointer
+
+IMR_MAP_MESHregular mesh specification
+IMR_MAP_AUTOSGauto-generated source coordinates
+IMR_MAP_AUTODGauto-generated destination coordinates
+IMR_MAP_LUCEluminance correction flag
+IMR_MAP_CLCEchromacity correction flag


You probably mean 'chroma'. 'chromacity' isn't a word.


   But it's recognized by all online translators I've tried. :-)


+IMR_MAP_TCMvertex clockwise-mode order
+IMR_MAP_UVDPOR(n)source coordinate decimal point position
+IMR_MAP_DDPdestination coordinate sub-pixel mode
+IMR_MAP_YLDPO(n)luminance correction offset decimal point
+position
+IMR_MAP_UBDPO(n)chromacity (U) correction offset decimal point
+position
+IMR_MAP_VRDPO(n)chromacity (V) correction offset decimal point
+position


There is no documentation what how these types relate to IMR_MAP_MESH and
IMR_MAP_AUTOS/DG.


   They are basically orthogonal, IIRC.


+
+* struct imr_meshregular mesh specification
+
+__u16rows, columnsrectangular mesh sizes
+__u16x0, y0, dx, dyauto-generated mesh parameters
+
+* struct imr_vbovertex-buffer-object (VBO) descriptor
+
+__u16numnumber of triangles


Sorry, this needs more work.


   Sigh, everybody hates writing docs, I guess... :-)


Regards,

Hans


MBR, Sergei

Re: [PATCH v6] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 07/03/2017 03:25 PM, Hans Verkuil wrote:


From: Konstantin Kozhevnikov 

The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...

[Sergei: merged 2 original patches, added  the patch description, removed
unrelated parts,  added the binding document and the UAPI documentation,
ported the driver to the modern kernel, renamed the UAPI header file and
the guard macros to match the driver name, extended the copyrights, fixed
up Kconfig prompt/depends/help, made use of the BIT/GENMASK() macros,
sorted  #include's, replaced 'imr_ctx::crop' array with the 'imr_ctx::rect'
structure, replaced imr_{g|s}_crop() with imr_{g|s}_selection(), completely
rewrote imr_queue_setup(), removed 'imr_format_info::name', moved the
applicable code from imr_buf_queue() to imr_buf_prepare() and moved the
rest of imr_buf_queue() after imr_buf_finish(), assigned 'src_vq->dev' and
'dst_vq->dev' in imr_queue_init(), removed imr_start_streaming(), assigned
'src_vq->dev' and 'dst_vq->dev' in imr_queue_init(), clarified the math in
imt_tri_type_{a|b|c}_length(), clarified the pointer math and avoided casts
to 'void *' in imr_tri_set_type_{a|b|c}(), replaced imr_{reqbufs|querybuf|
dqbuf|expbuf|streamon|streamoff}() with the generic helpers, implemented
vidioc_{create_bufs|prepare_buf}() methods, used ALIGN() macro and merged
the matrix size checks and replaced kmalloc()/copy_from_user() calls with
memdup_user() call in imr_ioctl_map(), moved setting device capabilities
from imr_querycap() to imr_probe(), set the valid default queue format in
imr_probe(), removed leading dots and fixed grammar in the comments, fixed
up  the indentation  to use  tabs where possible, renamed DLSR, CMRCR.
DY1{0|2}, and ICR bits to match the manual, changed the prefixes of the
CMRCR[2]/TRI{M|C}R bits/fields to match the manual, removed non-existent
TRIMR.D{Y|U}D{X|V}M bits, added/used the IMR/{UV|CP}DPOR/SUSR bits/fields/
shifts, separated the register offset/bit #define's, sorted instruction
macros by opcode, removed unsupported LINE instruction, masked the register
address in WTL[2]/WTS instruction macros, moved the display list #define's
after the register #define's, removing the redundant comment, avoided
setting reserved bits when writing CMRCCR[2]/TRIMCR, used the SR bits
instead of a bare number, removed *inline* from .c file, fixed lines over
80 columns, removed useless spaces, comments, parens, operators, casts,
braces, variables, #include's, statements, and even 1 function, added
useful local variable, uppercased and spelled out the abbreviations,
made comment wording more consistent/correct, fixed the comment typos,
reformatted some multiline comments, inserted empty line after declaration,
removed extra empty lines,  reordered some local variable desclarations,
removed calls to 4l2_err() on kmalloc() failure, replaced '*' with 'x'
in some format strings for v4l2_dbg(), fixed the error returned by
imr_default(), avoided code duplication in the IRQ handler, used '__packed'
for the UAPI structures, declared 'imr_map_desc::data' as '__u64' instead
of 'void *', switched to '__u{16|32}' in the UAPI header, enclosed the
macro parameters in parens, exchanged the values of IMR_MAP_AUTO{S|D}G
macros.]


As Geert suggested, just replace this with a 'Based-on' line.


   OK, the list grew too long indeed. :-)





Index: media_tree/drivers/media/platform/rcar_imr.c
===
--- /dev/null
+++ media_tree/drivers/media/platform/rcar_imr.c
@@ -0,0 +1,1877 @@





+/* add reference to the current configuration */
+static struct imr_cfg *imr_cfg_ref(struct imr_ctx *ctx)


imr_cfg_ref -> imr_cfg_ref_get


   OK, but imr_cfg_get() seems a better name.


+{
+struct imr_cfg *cfg = ctx->cfg;
+
+BUG_ON(!cfg);


Perhaps this can be replaced by:

if (WARN_ON(!cfg))
return NULL;


   I'm afraid imr_device_run() will cause oops in this case...


+cfg->refcount++;
+return cfg;
+}
+
+/* mesh configuration destructor */
+static void imr_cfg_unref(struct imr_ctx *ctx, struct imr_cfg *cfg)


imr_cfg_unref -> imr_cfg_ref_put


  OK, but I'll call it imr_cfg_put().


That follows the standard naming conventions for refcounting.


+{
+struct imr_device *imr = ctx->imr;
+
+/* no atomicity is required as operation is locked with device mutex */
+if (!cfg || --cfg->refcount)
+return;
+
+/* release memory allocated for a display list */
+if (cfg->dl_vaddr)
+dma_free_writecombine(imr->dev, 

Re: [PATCH v3] media: platform: rcar_imr: add IMR-LSX3 support

[Sergei Shtylyov]

On 06/30/2017 12:42 AM, Rob Herring wrote:


Add support for the image renderer light SRAM extended 3 (IMR-LSX3) found
only in the R-Car V2H (R8A7792) SoC.  It differs  from IMR-LX4 in that it
supports only planar video formats but can use the video capture data for
the textures.

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch  is against the 'media_tree.git' repo's 'master' branch plus the
latest version of the Renesas IMR driver...

Changes in version 3:
- fixed compilation errors, resolved rejects, refreshed the patch atop of the
  IMR driver patch (version 6).

Changes in version 2:
- renamed *enum* 'imr_gen' to 'imr_type' and the *struct* field of this type
  from 'gen' to 'type';
- rename *struct* 'imr_type' to 'imr_info' and the fields/variables of this type
  from 'type' to 'info';
- added comments to IMR-LX4 only CMRCR2 bits;
- added IMR type check to the WTS instruction writing to CMRCCR2.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   11 +-


You missed my ack on v2.


   Sorry again, realized that just after posting v3.


 drivers/media/platform/rcar_imr.c|  101 +++
 2 files changed, 92 insertions(+), 20 deletions(-)


MBR, Sergei

[PATCH v2] media: platform: rcar_imr: add IMR-LX3 support

[Sergei Shtylyov]

Add support for the image renderer light extended 3 (IMR-LX3) found only in
the R-Car V2H (R8A7792) SoC. It's mostly the same as IMR-LSX3 but doesn't
support video capture data as a source of 2D textures.

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch  is against the 'media_tree.git' repo's 'master' branch plus the
latest version of  the Renesas IMR driver and the patch adding IMR-LSX3 support.

Changes in version 2:
- refreshed the patch atop of the IMR driver patch (version 6) and IMR-LSX3
  patch (version 3).

 Documentation/devicetree/bindings/media/rcar_imr.txt |4 ++
 drivers/media/platform/rcar_imr.c|   27 ---
 2 files changed, 22 insertions(+), 9 deletions(-)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- media_tree.orig/Documentation/devicetree/bindings/media/rcar_imr.txt
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -9,6 +9,10 @@ and drawing with respect to any shape th
 Required properties:
 
 - compatible:
+  "renesas,-imr-lx3", "renesas,imr-lx3" as a fallback for the image
+  renderer light extended 3 (IMR-LX3) found in the R-Car gen2 SoCs, where the
+  examples with  are:
+  - "renesas,r8a7792-imr-lx3" for R-Car V2H;
   "renesas,-imr-lsx3", "renesas,imr-lsx3" as a fallback for the image
   renderer light SRAM extended 3 (IMR-LSX3) found in the R-Car gen2 SoCs, where
   the examples with  are:
Index: media_tree/drivers/media/platform/rcar_imr.c
===
--- media_tree.orig/drivers/media/platform/rcar_imr.c
+++ media_tree/drivers/media/platform/rcar_imr.c
@@ -1,5 +1,5 @@
 /*
- * rcar_imr.c -- R-Car IMR-LSX3/LX4 Driver
+ * rcar_imr.c -- R-Car IMR-LX3/LSX3/LX4 Driver
  *
  * Copyright (C) 2015-2017 Cogent Embedded, Inc. <sou...@cogentembedded.com>
  *
@@ -82,6 +82,7 @@ struct imr_format_info {
 };
 
 enum imr_type {
+   IMR_LX3,
IMR_LSX3,
IMR_LX4,
 };
@@ -163,7 +164,7 @@ struct imr_ctx {
 #define IMR_SSAR   0x38
 #define IMR_DSTR   0x3C
 #define IMR_SSTR   0x40
-#define IMR_DSOR   0x50
+#define IMR_DSOR   0x50/* IMR-LSX3/LX4 only */
 #define IMR_CMRCR  0x54
 #define IMR_CMRCSR 0x58
 #define IMR_CMRCCR 0x5C
@@ -210,7 +211,7 @@ struct imr_ctx {
 #define IMR_CMRCR_DUV  GENMASK(4, 3)
 #define IMR_CMRCR_SUV_SHIFT5
 #define IMR_CMRCR_SUV  GENMASK(6, 5)
-#define IMR_CMRCR_YISM BIT(7)
+#define IMR_CMRCR_YISM BIT(7)  /* IMR-LSX3/LX4 only */
 #define IMR_CMRCR_Y10  BIT(8)
 #define IMR_CMRCR_Y12  BIT(9)
 #define IMR_CMRCR_SY10 BIT(11)
@@ -224,7 +225,7 @@ struct imr_ctx {
 #define IMR_TRIMR_AUTOSG   BIT(3)
 #define IMR_TRIMR_TCM  BIT(6)
 
-#define IMR_TRICR_YCFORM   BIT(31)
+#define IMR_TRICR_YCFORM   BIT(31) /* IMR-LSX3/LX4 only */
 
 #define IMR_UVDPOR_UVDPO_SHIFT 0
 #define IMR_UVDPOR_UVDPO   GENMASK(2, 0)
@@ -306,7 +307,7 @@ static u32 __imr_flags_common(u32 iflags
return iflags & oflags & IMR_F_PLANES_MASK;
 }
 
-static const struct imr_format_info imr_lsx3_formats[] = {
+static const struct imr_format_info imr_lx3_formats[] = {
{
.fourcc = V4L2_PIX_FMT_NV16,
.flags  = IMR_F_Y8 | IMR_F_UV8 | IMR_F_PLANAR,
@@ -372,10 +373,16 @@ static const struct imr_format_info imr_
},
 };
 
+static const struct imr_info imr_lx3 = {
+   .type   = IMR_LX3,
+   .formats= imr_lx3_formats,
+   .num_formats= ARRAY_SIZE(imr_lx3_formats),
+};
+
 static const struct imr_info imr_lsx3 = {
.type   = IMR_LSX3,
-   .formats= imr_lsx3_formats,
-   .num_formats= ARRAY_SIZE(imr_lsx3_formats),
+   .formats= imr_lx3_formats,
+   .num_formats= ARRAY_SIZE(imr_lx3_formats),
 };
 
 static const struct imr_info imr_lx4 = {
@@ -798,7 +805,8 @@ static void imr_dl_program_setup(struct
*dl++ = IMR_OP_WTS(IMR_CPDPOR, __imr_cpdp(type));
 
/* reset rendering mode registers */
-   *dl++ = IMR_OP_WTS(IMR_CMRCCR,  0xDBFE);
+   *dl++ = IMR_OP_WTS(IMR_CMRCCR, ctx->imr->info->type >= IMR_LSX3 ?
+  0xDBFE : 0xDB7E);
*dl++ = IMR_OP_WTS(IMR_CMRCCR2, ctx->imr->info->type == IMR_LX4 ?
   0x9065 : IMR_CMRCR2_LUTE);
 
@@ -1919,6 +1927,7 @@ static const struct dev_pm_ops imr_pm_op
 
 /* device table */
 static const struct of_device_id imr_of_match[] = {
+   { .compatible = "renesas,imr-lx3",  .data = _lx3, },
{ .compatible = "renesas,imr-lsx3", .data = _lsx3, },
{ .compatible = "renesas,imr-lx4",  .data = _lx4,  },
 

[PATCH v3] media: platform: rcar_imr: add IMR-LSX3 support

[Sergei Shtylyov]

Add support for the image renderer light SRAM extended 3 (IMR-LSX3) found
only in the R-Car V2H (R8A7792) SoC.  It differs  from IMR-LX4 in that it
supports only planar video formats but can use the video capture data for
the textures.

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch  is against the 'media_tree.git' repo's 'master' branch plus the
latest version of the Renesas IMR driver...

Changes in version 3:
- fixed compilation errors, resolved rejects, refreshed the patch atop of the
  IMR driver patch (version 6).

Changes in version 2:
- renamed *enum* 'imr_gen' to 'imr_type' and the *struct* field of this type
  from 'gen' to 'type';
- rename *struct* 'imr_type' to 'imr_info' and the fields/variables of this type
  from 'type' to 'info';
- added comments to IMR-LX4 only CMRCR2 bits;
- added IMR type check to the WTS instruction writing to CMRCCR2.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   11 +-
 drivers/media/platform/rcar_imr.c|  101 +++
 2 files changed, 92 insertions(+), 20 deletions(-)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- media_tree.orig/Documentation/devicetree/bindings/media/rcar_imr.txt
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -8,9 +8,14 @@ and drawing with respect to any shape th
 
 Required properties:
 
-- compatible: "renesas,-imr-lx4", "renesas,imr-lx4" as a fallback for
-  the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs,
-  where the examples with  are:
+- compatible:
+  "renesas,-imr-lsx3", "renesas,imr-lsx3" as a fallback for the image
+  renderer light SRAM extended 3 (IMR-LSX3) found in the R-Car gen2 SoCs, where
+  the examples with  are:
+  - "renesas,r8a7792-imr-lsx3" for R-Car V2H;
+  "renesas,-imr-lx4", "renesas,imr-lx4" as a fallback for the image
+  renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs, where the
+  examples with  are:
   - "renesas,r8a7795-imr-lx4" for R-Car H3,
   - "renesas,r8a7796-imr-lx4" for R-Car M3-W.
 - reg: offset and length of the register block;
Index: media_tree/drivers/media/platform/rcar_imr.c
===
--- media_tree.orig/drivers/media/platform/rcar_imr.c
+++ media_tree/drivers/media/platform/rcar_imr.c
@@ -1,5 +1,5 @@
 /*
- * rcar_imr.c -- R-Car IMR-LX4 Driver
+ * rcar_imr.c -- R-Car IMR-LSX3/LX4 Driver
  *
  * Copyright (C) 2015-2017 Cogent Embedded, Inc. <sou...@cogentembedded.com>
  *
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -81,8 +81,21 @@ struct imr_format_info {
u32 flags;
 };
 
+enum imr_type {
+   IMR_LSX3,
+   IMR_LX4,
+};
+
+/* IMR type specific data */
+struct imr_info {
+   enum imr_type   type;
+   const struct imr_format_info *formats;
+   unsigned intnum_formats;
+};
+
 /* per-device data */
 struct imr_device {
+   const struct imr_info   *info;
struct device   *dev;
struct clk  *clock;
void __iomem*mmio;
@@ -190,6 +203,7 @@ struct imr_ctx {
 #define IMR_IMR_IEMBIT(1)
 #define IMR_IMR_INMBIT(2)
 
+#define IMR_CMRCR_TXTM BIT(0)  /* IMR-LSX3 only */
 #define IMR_CMRCR_LUCE BIT(1)
 #define IMR_CMRCR_CLCE BIT(2)
 #define IMR_CMRCR_DUV_SHIFT3
@@ -229,11 +243,11 @@ struct imr_ctx {
 #define IMR_CPDPOR_YLDPO   GENMASK(10, 8)
 
 #define IMR_CMRCR2_LUTEBIT(0)
-#define IMR_CMRCR2_YUV422E BIT(2)
-#define IMR_CMRCR2_YUV422FORM  BIT(5)
-#define IMR_CMRCR2_UVFORM  BIT(6)
-#define IMR_CMRCR2_TCTEBIT(12)
-#define IMR_CMRCR2_DCTEBIT(15)
+#define IMR_CMRCR2_YUV422E BIT(2)  /* IMR-LX4 only */
+#define IMR_CMRCR2_YUV422FORM  BIT(5)  /* IMR-LX4 only */
+#define IMR_CMRCR2_UVFORM  BIT(6)  /* IMR-LX4 only */
+#define IMR_CMRCR2_TCTEBIT(12) /* IMR-LX4 only */
+#define IMR_CMRCR2_DCTEBIT(15) /* IMR-LX4 only */
 
 
/***
  * Display list commands
@@ -292,6 +306,29 @@ static u32 __imr_flags_common(u32 iflags
return iflags & oflags & IMR_F_PLANES_MASK;
 }
 
+static const struct imr_format_info imr_lsx3_formats[] = {
+   {
+   .fourcc = V4L2_PIX_FMT_NV16,
+   .flags  = IMR_F_Y8 | IMR_F_UV8 | IMR_F_PLANAR,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_GREY,
+   .flags  = IMR_F_Y8 | IMR_F_PLANAR,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_Y10,
+   .flags  = IMR_F_Y8 | IMR

Re: [PATCH v6] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 06/26/2017 10:49 PM, Rob Herring wrote:


From: Konstantin Kozhevnikov <konstantin.kozhevni...@cogentembedded.com>

The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...

[Sergei: merged 2 original patches, added  the patch description, removed
unrelated parts,  added the binding document and the UAPI documentation,
ported the driver to the modern kernel, renamed the UAPI header file and
the guard macros to match the driver name, extended the copyrights, fixed
up Kconfig prompt/depends/help, made use of the BIT/GENMASK() macros,
sorted  #include's, replaced 'imr_ctx::crop' array with the 'imr_ctx::rect'
structure, replaced imr_{g|s}_crop() with imr_{g|s}_selection(), completely
rewrote imr_queue_setup(), removed 'imr_format_info::name', moved the
applicable code from imr_buf_queue() to imr_buf_prepare() and moved the
rest of imr_buf_queue() after imr_buf_finish(), assigned 'src_vq->dev' and
'dst_vq->dev' in imr_queue_init(), removed imr_start_streaming(), assigned
'src_vq->dev' and 'dst_vq->dev' in imr_queue_init(), clarified the math in
imt_tri_type_{a|b|c}_length(), clarified the pointer math and avoided casts
to 'void *' in imr_tri_set_type_{a|b|c}(), replaced imr_{reqbufs|querybuf|
dqbuf|expbuf|streamon|streamoff}() with the generic helpers, implemented
vidioc_{create_bufs|prepare_buf}() methods, used ALIGN() macro and merged
the matrix size checks and replaced kmalloc()/copy_from_user() calls with
memdup_user() call in imr_ioctl_map(), moved setting device capabilities
from imr_querycap() to imr_probe(), set the valid default queue format in
imr_probe(), removed leading dots and fixed grammar in the comments, fixed
up  the indentation  to use  tabs where possible, renamed DLSR, CMRCR.
DY1{0|2}, and ICR bits to match the manual, changed the prefixes of the
CMRCR[2]/TRI{M|C}R bits/fields to match the manual, removed non-existent
TRIMR.D{Y|U}D{X|V}M bits, added/used the IMR/{UV|CP}DPOR/SUSR bits/fields/
shifts, separated the register offset/bit #define's, sorted instruction
macros by opcode, removed unsupported LINE instruction, masked the register
address in WTL[2]/WTS instruction macros, moved the display list #define's
after the register #define's, removing the redundant comment, avoided
setting reserved bits when writing CMRCCR[2]/TRIMCR, used the SR bits
instead of a bare number, removed *inline* from .c file, fixed lines over
80 columns, removed useless spaces, comments, parens, operators, casts,
braces, variables, #include's, statements, and even 1 function, added
useful local variable, uppercased and spelled out the abbreviations,
made comment wording more consistent/correct, fixed the comment typos,
reformatted some multiline comments, inserted empty line after declaration,
removed extra empty lines,  reordered some local variable desclarations,
removed calls to 4l2_err() on kmalloc() failure, replaced '*' with 'x'
in some format strings for v4l2_dbg(), fixed the error returned by
imr_default(), avoided code duplication in the IRQ handler, used '__packed'
for the UAPI structures, declared 'imr_map_desc::data' as '__u64' instead
of 'void *', switched to '__u{16|32}' in the UAPI header, enclosed the
macro parameters in parens, exchanged the values of IMR_MAP_AUTO{S|D}G
macros.]


TL;DR needed here IMO.


   Not sure I understand... stands for "too long; didn't read", right?


Not sure anyone really cares every detail you
changed in re-writing this. If they did, it should all be separate
commits.


   AFAIK this is a way that's things are dealt with when you submit somebody 
else's work with your changes. Sorry if the list is too long...



Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>


I acked v5 and it doesn't seem the binding changed.


   Sorry, I realized that I'd missed to collect you ACK just after sending 
v6... I believe there'll be v7 yet, so I'll finally collect it.



Rob


MBR, Sergei

Re: [PATCH v5] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 03/17/2017 05:24 PM, Hans Verkuil wrote:


Sorry for the long wait before I got around to reviewing this, but here
are (finally!) my review comments.


   Addressing your comments took significant time too, and I wasn't able to 
address all of them yet...



On 03/09/17 21:08, Sergei Shtylyov wrote:

From: Konstantin Kozhevnikov <konstantin.kozhevni...@cogentembedded.com>

The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...

[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the  guard macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed DLSR, CMRCR.DY1{0|2}, and ICR bits to
match the manual, changed the prefixes of the CMRCR[2]/TRI{M|C}R bits/
fields to match the manual, removed non-existent TRIMR.D{Y|U}D{X|V}M bits,
added/used the IMR/{UV|CP}DPOR/SUSR bits/fields/shifts, separated the
register offset/bit #define's, sorted the instruction macros by opcode,
removed unsupported LINE instruction, masked the register address in
WTL[2]/WTS instruction macros, moved the display list #define's after
the register #define's, removing the redundant comment, avoided setting
reserved bits when writing CMRCCR[2]/TRIMCR, used the SR bits instead of
a bare number, used ALIGN() macro in imr_ioctl_map(), removed *inline*
from .c file, fixed lines over 80 columns, removed useless spaces,
comments, parens, operators, casts, braces, variables, #include's,
statements, and even 1 function, uppercased the abbreviations, made
comment wording more consistent/correct, fixed the comment typos,
reformatted some multiline comments, inserted empty line after declaration,
removed extra empty lines, reordered some local variable desclarations,
removed calls to 4l2_err() on kmalloc() failure, replaced '*' with 'x'
in some format strings for v4l2_dbg(), fixed the error returned by
imr_default(), avoided code duplication in the IRQ handler, used
'__packed' for the UAPI structures, enclosed the macro parameters in
parens, exchanged the values of IMR_MAP_AUTO{S|D}G macros.]

Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>


[...]


Index: media_tree/drivers/media/platform/rcar_imr.c
===
--- /dev/null
+++ media_tree/drivers/media/platform/rcar_imr.c
@@ -0,0 +1,1943 @@

[...]

+/* M2M device processing queue initialization */
+static int imr_queue_init(void *priv, struct vb2_queue *src_vq,
+ struct vb2_queue *dst_vq)
+{
+   struct imr_ctx  *ctx = priv;
+   int ret;
+
+   memset(src_vq, 0, sizeof(*src_vq));
+   src_vq->type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
+   src_vq->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF;
+   src_vq->drv_priv = ctx;
+   src_vq->buf_struct_size = sizeof(struct imr_buffer);
+   src_vq->ops = _qops;
+   src_vq->mem_ops = _dma_contig_memops;
+   src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+   src_vq->lock = >imr->mutex;

[...]

+   ret = vb2_queue_init(src_vq);
+   if (ret)
+   return ret;
+
+   memset(dst_vq, 0, sizeof(*dst_vq));
+   dst_vq->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   dst_vq->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF;


Drop VB2_USERPTR here and above. Not recommended to use this with dma-contig.


   Hm... but we need it -- that's what Konstantin has been actively using.

[...]

+/* retrieve current queue format; operation is locked? */
+static int imr_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
+{
+   struct imr_ctx  *ctx = fh_to_ctx(priv);
+   struct imr_q_data   *q_data;
+   struct vb2_queue*vq;
+
+   vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
+   if (!vq)
+   return -EINVAL;
+
+   q_data = >queue[V4L2_TYPE_IS_OUTPUT(f->type) ? 0 : 1];
+
+   /* processing is locked? TBD */
+   f->fmt.pix = q_data->fmt;
+
+   return 0;
+}
+
+/* test particular format; operation is not locked */
+static int imr_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
+{
+   

[PATCH v6] media: platform: Renesas IMR driver

[Sergei Shtylyov]

From: Konstantin Kozhevnikov <konstantin.kozhevni...@cogentembedded.com>

The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...

[Sergei: merged 2 original patches, added  the patch description, removed
unrelated parts,  added the binding document and the UAPI documentation,
ported the driver to the modern kernel, renamed the UAPI header file and
the guard macros to match the driver name, extended the copyrights, fixed
up Kconfig prompt/depends/help, made use of the BIT/GENMASK() macros,
sorted  #include's, replaced 'imr_ctx::crop' array with the 'imr_ctx::rect'
structure, replaced imr_{g|s}_crop() with imr_{g|s}_selection(), completely
rewrote imr_queue_setup(), removed 'imr_format_info::name', moved the
applicable code from imr_buf_queue() to imr_buf_prepare() and moved the
rest of imr_buf_queue() after imr_buf_finish(), assigned 'src_vq->dev' and
'dst_vq->dev' in imr_queue_init(), removed imr_start_streaming(), assigned
'src_vq->dev' and 'dst_vq->dev' in imr_queue_init(), clarified the math in
imt_tri_type_{a|b|c}_length(), clarified the pointer math and avoided casts
to 'void *' in imr_tri_set_type_{a|b|c}(), replaced imr_{reqbufs|querybuf|
dqbuf|expbuf|streamon|streamoff}() with the generic helpers, implemented
vidioc_{create_bufs|prepare_buf}() methods, used ALIGN() macro and merged
the matrix size checks and replaced kmalloc()/copy_from_user() calls with
memdup_user() call in imr_ioctl_map(), moved setting device capabilities
from imr_querycap() to imr_probe(), set the valid default queue format in
imr_probe(), removed leading dots and fixed grammar in the comments, fixed
up  the indentation  to use  tabs where possible, renamed DLSR, CMRCR.
DY1{0|2}, and ICR bits to match the manual, changed the prefixes of the
CMRCR[2]/TRI{M|C}R bits/fields to match the manual, removed non-existent
TRIMR.D{Y|U}D{X|V}M bits, added/used the IMR/{UV|CP}DPOR/SUSR bits/fields/
shifts, separated the register offset/bit #define's, sorted instruction
macros by opcode, removed unsupported LINE instruction, masked the register
address in WTL[2]/WTS instruction macros, moved the display list #define's
after the register #define's, removing the redundant comment, avoided
setting reserved bits when writing CMRCCR[2]/TRIMCR, used the SR bits
instead of a bare number, removed *inline* from .c file, fixed lines over
80 columns, removed useless spaces, comments, parens, operators, casts,
braces, variables, #include's, statements, and even 1 function, added
useful local variable, uppercased and spelled out the abbreviations,
made comment wording more consistent/correct, fixed the comment typos,
reformatted some multiline comments, inserted empty line after declaration,
removed extra empty lines,  reordered some local variable desclarations,
removed calls to 4l2_err() on kmalloc() failure, replaced '*' with 'x'
in some format strings for v4l2_dbg(), fixed the error returned by
imr_default(), avoided code duplication in the IRQ handler, used '__packed'
for the UAPI structures, declared 'imr_map_desc::data' as '__u64' instead
of 'void *', switched to '__u{16|32}' in the UAPI header, enclosed the
macro parameters in parens, exchanged the values of IMR_MAP_AUTO{S|D}G
macros.]

Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
Changes in version 6:
- fixed the bug where if imr_cfg_create() fails, 'ctx->cfg' wasn't set to NULL
  and so wouldn't fail the validity checks;
- fixed the height minimum/alignment passed to v4l_bound_align_image();
- removed the buggy !V4L2_TYPE_IS_OUTPUT() check from imr_qbuf();
- added the driver UAPI documentation;
- replaced 'imr_ctx::crop' array with the 'imr_ctx::rect' structure;
- replaced imr_{g|s}_crop() with imr_{g|s}_selection();
- removed 'imr_format_info::name' and the related code;
- completely rewrote imr_queue_setup();
- moved the applicable code from imr_buf_queue() to imr_buf_prepare(), moved
  the  rest of imr_buf_queue() after imr_buf_finish();
- removed imr_start_streaming();
- assigned 'src_vq->dev' and 'dst_vq->dev' in imr_queue_init();
- clarified the math in imt_tri_type_{a|b|c}_length();
- removed useless local variables, added useful variables, avoided casts to
  'void *', and clarified the pointer math in imr_tri_set_type_{a|b|c}();
- replaced kmalloc()/copy_from_user() calls with memdup_user() call;
- moved the 'type' variable assignment in imr_ioctl_map() after the following
  comment;
- merged the matrix siz

Re: [PATCH v5] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 06/07/2017 10:26 AM, Hans Verkuil wrote:


Any progress on this?


   Yes. :-)


There where a bunch of comments,


   I think I've addresses most of those (except those I didn't quite 
understand).


but I haven't seen anything since.


   I'm still busy documenting the driver. :-(


Regards,

Hans


MBR, Sergei

Re: [PATCH] ALSA: hda - Fix applying MSI dual-codec mobo quirk

[Sergei Shtylyov]

Hello!

On 6/1/2017 11:58 PM, Takashi Iwai wrote:


The previous commit [63691587f7b0: ALSA: hda - Apply dual-codec quirk
for MSI Z270-Gaming mobo] attempted to apply the existing dual-codec


   The standard way of citing a commit is: commit 63691587f7b0 ("ALSA: hda - 
Apply dual-codec quirk for MSI Z270-Gaming mobo"), just like in the Fixes: tag.



quirk for a MSI mobo.  But it turned out that this isn't applied
properly due to the MSI-vendor quirk before this entry.  I overlooked
such two MSI entries just because they were put in the wrong position,
although we have a list ordered by PCI SSID numbers.

This patch fixes it by rearranging the unordered entries.

Fixes: 63691587f7b0 ("ALSA: hda - Apply dual-codec quirk for MSI Z270-Gaming 
mobo")
Reported-by: Rudolf Schmidt 
Signed-off-by: Takashi Iwai 

[...]

MBR, Sergei

Re: [PATCH 6/7] [media] soc_camera: rcar_vin: use proper name for the R-Car SoC

[Sergei Shtylyov]

Hello!

   Why "soc_camera:" in the subject?
   The 'soc_camera" driver has been removed (replaced by a "normal" V4L2 
driver).

MBR, Sergei

Re: [PATCH v2 17/17] rcar-vin: fix bug in pixelformat selection

[Sergei Shtylyov]

Hello!

On 5/24/2017 3:15 AM, Niklas Söderlund wrote:


From: Niklas Söderlund 

If the requested pixelformat is not supported fallback to the default
format, do not revert the entire format.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index de71e5fa8b10cb5e..81ff59c3b4744075 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c

[...]

@@ -218,17 +217,11 @@ static int __rvin_try_format(struct rvin_dev *vin,
if (pix->field == V4L2_FIELD_ANY)
pix->field = vin->format.field;

-   /*
-* Retrieve format information and select the current format if the
-* requested format isn't supported.
-*/
-   info = rvin_format_from_pixel(pix->pixelformat);
-   if (!info) {
-   vin_dbg(vin, "Format %x not found, keeping %x\n",
-   pix->pixelformat, vin->format.pixelformat);
-   *pix = vin->format;
-   pix->width = rwidth;
-   pix->height = rheight;
+   /* If requested format is not supported fallback to the default */
+   if (!rvin_format_from_pixel(pix->pixelformat)) {
+   vin_dbg(vin, "Format 0x%x not found, using default 0x%x\n",


s/0x%x/%#x/, maybe?


+   pix->pixelformat, RVIN_DEFAULT_FORMAT);
+   pix->pixelformat = RVIN_DEFAULT_FORMAT;
}

/* Always recalculate */


MBR, Sergei

Re: [PATCH 1/2] v4l: vsp1: Add support for colorkey alpha blending

[Sergei Shtylyov]

On 05/04/2017 01:53 PM, agheorghe wrote:


The vsp2 hw supports changing of the alpha of pixels that match a color
key, this patch adds support for this feature in order to be used by
the rcar-du driver.
The colorkey is interpreted different depending of the pixel format:
* RGB   - all color components have to match.
* YCbCr - only the Y component has to match.

Signed-off-by: agheorghe 


  Your full name is absolutely necessary here.

MBR, Sergei

Re: [PATCH 4/5] arm64: dts: r8a7795: salvator-x: enable VIN, CSI and ADV7482

[Sergei Shtylyov]

Hello!

On 4/27/2017 9:26 PM, Kieran Bingham wrote:


From: Kieran Bingham 

Provide bindings between the VIN, CSI and the ADV7482 on the r8a7795.

Signed-off-by: Kieran Bingham 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 129 +
 1 file changed, 129 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 27b9bae60dc0..a20623faa9d2 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts

[...]

@@ -387,6 +403,50 @@
};
 };

+ {
+   status = "okay";
+
+   clock-frequency = <10>;
+
+   video_receiver@70 {


   Hyphens are preferred in the node names.

[...]

MBR, Sergei

[PATCH] media: platform: rcar_imr: add IMR-LX3 support

[Sergei Shtylyov]

Add support for the image renderer light extended 3 (IMR-LX3) found only in
the R-Car V2H (R8A7792) SoC. It's mostly the same as IMR-LSX3 but doesn't
support video capture data as a source of 2D textures.

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch  is against the 'media_tree.git' repo's 'master' branch plus the
latest version of  the Renesas IMR driver and the patch adding IMR-LSX3 support.

 Documentation/devicetree/bindings/media/rcar_imr.txt |4 ++
 drivers/media/platform/rcar_imr.c|   27 ---
 2 files changed, 22 insertions(+), 9 deletions(-)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- media_tree.orig/Documentation/devicetree/bindings/media/rcar_imr.txt
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -9,6 +9,10 @@ and drawing with respect to any shape th
 Required properties:
 
 - compatible:
+  "renesas,-imr-lx3", "renesas,imr-lx3" as a fallback for the image
+  renderer light extended 3 (IMR-LX3) found in the R-Car gen2 SoCs, where the
+  examples with  are:
+  - "renesas,r8a7792-imr-lx3" for R-Car V2H;
   "renesas,-imr-lsx3", "renesas,imr-lsx3" as a fallback for the image
   renderer light SRAM extended 3 (IMR-LSX3) found in the R-Car gen2 SoCs, where
   the examples with  are:
Index: media_tree/drivers/media/platform/rcar_imr.c
===
--- media_tree.orig/drivers/media/platform/rcar_imr.c
+++ media_tree/drivers/media/platform/rcar_imr.c
@@ -1,5 +1,5 @@
 /*
- * rcar_imr.c -- R-Car IMR-LSX3/LX4 Driver
+ * rcar_imr.c -- R-Car IMR-LX3/LSX3/LX4 Driver
  *
  * Copyright (C) 2015-2017 Cogent Embedded, Inc. <sou...@cogentembedded.com>
  *
@@ -82,6 +82,7 @@ struct imr_format_info {
 };
 
 enum imr_type {
+   IMR_LX3,
IMR_LSX3,
IMR_LX4,
 };
@@ -153,7 +154,7 @@ struct imr_ctx {
 #define IMR_SSAR   0x38
 #define IMR_DSTR   0x3C
 #define IMR_SSTR   0x40
-#define IMR_DSOR   0x50
+#define IMR_DSOR   0x50/* IMR-LSX3/LX4 only */
 #define IMR_CMRCR  0x54
 #define IMR_CMRCSR 0x58
 #define IMR_CMRCCR 0x5C
@@ -200,7 +201,7 @@ struct imr_ctx {
 #define IMR_CMRCR_DUV  GENMASK(4, 3)
 #define IMR_CMRCR_SUV_SHIFT5
 #define IMR_CMRCR_SUV  GENMASK(6, 5)
-#define IMR_CMRCR_YISM BIT(7)
+#define IMR_CMRCR_YISM BIT(7)  /* IMR-LSX3/LX4 only */
 #define IMR_CMRCR_Y10  BIT(8)
 #define IMR_CMRCR_Y12  BIT(9)
 #define IMR_CMRCR_SY10 BIT(11)
@@ -214,7 +215,7 @@ struct imr_ctx {
 #define IMR_TRIMR_AUTOSG   BIT(3)
 #define IMR_TRIMR_TCM  BIT(6)
 
-#define IMR_TRICR_YCFORM   BIT(31)
+#define IMR_TRICR_YCFORM   BIT(31) /* IMR-LSX3/LX4 only */
 
 #define IMR_UVDPOR_UVDPO_SHIFT 0
 #define IMR_UVDPOR_UVDPO   GENMASK(2, 0)
@@ -296,7 +297,7 @@ static u32 __imr_flags_common(u32 iflags
return iflags & oflags & IMR_F_PLANES_MASK;
 }
 
-static const struct imr_format_info imr_lsx3_formats[] = {
+static const struct imr_format_info imr_lx3_formats[] = {
{
.name   = "YUV 4:2:2 semiplanar (NV16)",
.fourcc = V4L2_PIX_FMT_NV16,
@@ -377,10 +378,16 @@ static const struct imr_format_info imr_
},
 };
 
+static const struct imr_info imr_lx3 = {
+   .type   = IMR_LX3,
+   .formats= imr_lx3_formats,
+   .num_formats= ARRAY_SIZE(imr_lx3_formats),
+};
+
 static const struct imr_info imr_lsx3 = {
.type   = IMR_LSX3,
-   .formats= imr_lsx3_formats,
-   .num_formats= ARRAY_SIZE(imr_lsx3_formats),
+   .formats= imr_lx3_formats,
+   .num_formats= ARRAY_SIZE(imr_lx3_formats),
 };
 
 static const struct imr_info imr_lx4 = {
@@ -835,7 +842,8 @@ static void imr_dl_program_setup(struct
*dl++ = IMR_OP_WTS(IMR_CPDPOR, __imr_cpdp(type));
 
/* reset rendering mode registers */
-   *dl++ = IMR_OP_WTS(IMR_CMRCCR,  0xDBFE);
+   *dl++ = IMR_OP_WTS(IMR_CMRCCR, ctx->imr->info->type >= IMR_LSX3 ?
+  0xDBFE : 0xDB7E);
*dl++ = IMR_OP_WTS(IMR_CMRCCR2, ctx->imr->info->type == IMR_LX4 ?
   0x9065 : IMR_CMRCR2_LUTE);
 
@@ -1990,6 +1998,7 @@ static const struct dev_pm_ops imr_pm_op
 
 /* device table */
 static const struct of_device_id imr_of_match[] = {
+   { .compatible = "renesas,imr-lx3",  .data = _lx3, },
{ .compatible = "renesas,imr-lsx3", .data = _lsx3, },
{ .compatible = "renesas,imr-lx4",  .data = _lx4,  },
{ },
@@ -2011,5 +2020,5 @@ module_platform_driver(imr_platform_driv
 
 MODULE_ALIAS("imr");
 MODULE_AUTH

Re: [PATCH v2] media: platform: rcar_imr: add IMR-LSX3 support

[Sergei Shtylyov]

On 03/17/2017 05:33 PM, Hans Verkuil wrote:


Add support for the image renderer light SRAM extended 3 (IMR-LSX3) found
only in the R-Car V2H (R8A7792) SoC.  It differs  from IMR-LX4 in that it
supports only planar video formats but can use the video capture data for
the textures.

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>


[...]

Index: media_tree/drivers/media/platform/rcar_imr.c
===
--- media_tree.orig/drivers/media/platform/rcar_imr.c
+++ media_tree/drivers/media/platform/rcar_imr.c

[...]

@@ -282,6 +296,34 @@ static u32 __imr_flags_common(u32 iflags
return iflags & oflags & IMR_F_PLANES_MASK;
 }

+static const struct imr_format_info imr_lsx3_formats[] = {
+   {
+   .name   = "YUV 4:2:2 semiplanar (NV16)",
+   .fourcc = V4L2_PIX_FMT_NV16,
+   .flags  = IMR_F_Y8 | IMR_F_UV8 | IMR_F_PLANAR,
+   },
+   {
+   .name   = "Greyscale 8-bit",
+   .fourcc = V4L2_PIX_FMT_GREY,
+   .flags  = IMR_F_Y8 | IMR_F_PLANAR,
+   },
+   {
+   .name   = "Greyscale 10-bit",
+   .fourcc = V4L2_PIX_FMT_Y10,
+   .flags  = IMR_F_Y8 | IMR_F_Y10 | IMR_F_PLANAR,
+   },
+   {
+   .name   = "Greyscale 12-bit",
+   .fourcc = V4L2_PIX_FMT_Y12,
+   .flags  = IMR_F_Y8 | IMR_F_Y10 | IMR_F_Y12 | IMR_F_PLANAR,
+   },
+   {
+   .name   = "Chrominance UV 8-bit",
+   .fourcc = V4L2_PIX_FMT_UV8,
+   .flags  = IMR_F_UV8 | IMR_F_PLANAR,
+   },
+};
+
 static const struct imr_format_info imr_lx4_formats[] = {
{
.name   = "YUV 4:2:2 semiplanar (NV16)",
@@ -335,6 +377,18 @@ static const struct imr_format_info imr_
},
 };

+static const struct imr_info imr_lsx3 = {
+   .type   = IMR_LSX3,
+   .formats= imr_lsx3_formats,
+   .num_formats= ARRAY_SIZE(imr_lsx3_formats),
+};
+
+static const struct imr_info imr_lx4 = {
+   .type   = IMR_LX4,
+   .formats= imr_lx4_formats,
+   .num_formats= ARRAY_SIZE(imr_lx4_formats),
+};
+
 /* mesh configuration constructor */
 static struct imr_cfg *imr_cfg_create(struct imr_ctx *ctx,
  u32 dl_size, u32 dl_start)

[...]

@@ -823,7 +879,7 @@ static void imr_dl_program_setup(struct
*dl++ = IMR_OP_WTS(IMR_SSTR,
   w << (iflags & IMR_F_UV10 ? 1 : 0));
}
-   } else {
+   } else if (ctx->imr->info->type == IMR_LX4) {
u16 src_fmt = (iflags & IMR_F_UV_SWAP ? IMR_CMRCR2_UVFORM : 0) |
  (iflags & IMR_F_YUV_SWAP ?
   IMR_CMRCR2_YUV422FORM : 0);
@@ -864,6 +920,9 @@ static void imr_dl_program_setup(struct
*dl++ = IMR_OP_WTS(IMR_DSTR,
   W << (cflags & IMR_F_Y10 ? 2 : 1));
}
+   } else  {
+   /* this shouldn't happen! */
+   BUG();


Can you find a better way? The use of 'BUG' is frowned upon. It's better
to return an error here.


   OK, I'll try to return -EINVAL here...
   BTW, the main driver patch also has BUG_ON()...


Also, are you sure this can't happen?  At least for

> me it is not obvious from the code.

   Absolutely. Interleaved formats are not supported by IMR-L[S]X3, so the 
format array has IMR_F_PLANAR set for all formats supported by these cores. 
Interleaved formats are onlt supported by IMR-LX4 (for which we check above).


[...]


Regards,

Hans


MBR, Sergei

[PATCH v2] media: platform: rcar_imr: add IMR-LSX3 support

[Sergei Shtylyov]

Add support for the image renderer light SRAM extended 3 (IMR-LSX3) found
only in the R-Car V2H (R8A7792) SoC.  It differs  from IMR-LX4 in that it
supports only planar video formats but can use the video capture data for
the textures.

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch  is against the 'media_tree.git' repo's 'master' branch plus the
latest version of  the Renesas IMR driver...

Changes in version 2:
- renamed *enum* 'imr_gen' to 'imr_type' and the *struct* field of this type
  from 'gen' to 'type';
- rename *struct* 'imr_type' to 'imr_info' and the fields/variables of this type
  from 'type' to 'info';
- added comments to IMR-LX4 only CMRCR2 bits;
- added IMR type check to the WTS instruction writing to CMRCCR2.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   11 +
 drivers/media/platform/rcar_imr.c|  106 +++
 2 files changed, 97 insertions(+), 20 deletions(-)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- media_tree.orig/Documentation/devicetree/bindings/media/rcar_imr.txt
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -8,9 +8,14 @@ and drawing with respect to any shape th
 
 Required properties:
 
-- compatible: "renesas,-imr-lx4", "renesas,imr-lx4" as a fallback for
-  the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs,
-  where the examples with  are:
+- compatible:
+  "renesas,-imr-lsx3", "renesas,imr-lsx3" as a fallback for the image
+  renderer light SRAM extended 3 (IMR-LSX3) found in the R-Car gen2 SoCs, where
+  the examples with  are:
+  - "renesas,r8a7792-imr-lsx3" for R-Car V2H;
+  "renesas,-imr-lx4", "renesas,imr-lx4" as a fallback for the image
+  renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs, where the
+  examples with  are:
   - "renesas,r8a7795-imr-lx4" for R-Car H3,
   - "renesas,r8a7796-imr-lx4" for R-Car M3-W.
 - reg: offset and length of the register block;
Index: media_tree/drivers/media/platform/rcar_imr.c
===
--- media_tree.orig/drivers/media/platform/rcar_imr.c
+++ media_tree/drivers/media/platform/rcar_imr.c
@@ -1,5 +1,5 @@
 /*
- * rcar_imr.c -- R-Car IMR-LX4 Driver
+ * rcar_imr.c -- R-Car IMR-LSX3/LX4 Driver
  *
  * Copyright (C) 2015-2017 Cogent Embedded, Inc. <sou...@cogentembedded.com>
  *
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -81,8 +81,21 @@ struct imr_format_info {
u32 flags;
 };
 
+enum imr_type {
+   IMR_LSX3,
+   IMR_LX4,
+};
+
+/* IMR type specific data */
+struct imr_info {
+   enum imr_type   type;
+   const struct imr_format_info *formats;
+   unsigned intnum_formats;
+};
+
 /* per-device data */
 struct imr_device {
+   const struct imr_info   *info;
struct device   *dev;
struct clk  *clock;
void __iomem*mmio;
@@ -180,6 +193,7 @@ struct imr_ctx {
 #define IMR_IMR_IEMBIT(1)
 #define IMR_IMR_INMBIT(2)
 
+#define IMR_CMRCR_TXTM BIT(0)  /* IMR-LSX3 only */
 #define IMR_CMRCR_LUCE BIT(1)
 #define IMR_CMRCR_CLCE BIT(2)
 #define IMR_CMRCR_DUV_SHIFT3
@@ -219,11 +233,11 @@ struct imr_ctx {
 #define IMR_CPDPOR_YLDPO   GENMASK(10, 8)
 
 #define IMR_CMRCR2_LUTEBIT(0)
-#define IMR_CMRCR2_YUV422E BIT(2)
-#define IMR_CMRCR2_YUV422FORM  BIT(5)
-#define IMR_CMRCR2_UVFORM  BIT(6)
-#define IMR_CMRCR2_TCTEBIT(12)
-#define IMR_CMRCR2_DCTEBIT(15)
+#define IMR_CMRCR2_YUV422E BIT(2)  /* IMR-LX4 only */
+#define IMR_CMRCR2_YUV422FORM  BIT(5)  /* IMR-LX4 only */
+#define IMR_CMRCR2_UVFORM  BIT(6)  /* IMR-LX4 only */
+#define IMR_CMRCR2_TCTEBIT(12) /* IMR-LX4 only */
+#define IMR_CMRCR2_DCTEBIT(15) /* IMR-LX4 only */
 
 
/***
  * Display list commands
@@ -282,6 +296,34 @@ static u32 __imr_flags_common(u32 iflags
return iflags & oflags & IMR_F_PLANES_MASK;
 }
 
+static const struct imr_format_info imr_lsx3_formats[] = {
+   {
+   .name   = "YUV 4:2:2 semiplanar (NV16)",
+   .fourcc = V4L2_PIX_FMT_NV16,
+   .flags  = IMR_F_Y8 | IMR_F_UV8 | IMR_F_PLANAR,
+   },
+   {
+   .name   = "Greyscale 8-bit",
+   .fourcc = V4L2_PIX_FMT_GREY,
+   .flags  = IMR_F_Y8 | IMR_F_PLANAR,
+   },
+   {
+   .name   = "Greyscale 10-bit",
+   .fourcc = V4L2_

Re: [PATCH v3 06/27] rcar-vin: move max width and height information to chip information

[Sergei Shtylyov]

On 3/14/2017 10:02 PM, Niklas Söderlund wrote:


On Gen3 the max supported width and height will be different from Gen2.
Move the limits to the struct chip_info to prepare for Gen3 support.


   Maybe rvin_info?


Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 6 ++
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 6 ++
 drivers/media/platform/rcar-vin/rcar-vin.h  | 6 ++
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index ec1eb723d401fda2..998617711f1ad045 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -257,14 +257,20 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)

 static const struct rvin_info rcar_info_h1 = {
.chip = RCAR_H1,
+   .max_width = 2048,
+   .max_height = 2048,
 };

 static const struct rvin_info rcar_info_m1 = {
.chip = RCAR_M1,
+   .max_width = 2048,
+   .max_height = 2048,
 };

 static const struct rvin_info rcar_info_gen2 = {
.chip = RCAR_GEN2,
+   .max_width = 2048,
+   .max_height = 2048,
 };

 static const struct of_device_id rvin_of_id_table[] = {

[...]

MBR, Sergei

Re: [PATCH 03/16] rcar-vin: fix how pads are handled for v4l2 subdevice operations

[Sergei Shtylyov]

Hello!

On 3/14/2017 9:59 PM, Niklas Söderlund wrote:


The rcar-vin driver only uses one pad, pad number 0.

- All v4l2 operations that did not check that the requested operation
  was for pad 0 have been updated with a check to enforce this.

- All v4l2 operations that stored (and later restore) the requested pad


   Restored?


  before substituting it for the subdevice pad number have been updated
  to not store the incoming pad and simply restore it to 0 after the
  subdevice operation is complete.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 7ca27599b9982ffc..610f59e2a9142622 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -550,14 +550,16 @@ static int rvin_enum_dv_timings(struct file *file, void 
*priv_fh,
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int pad, ret;
+   int ret;
+
+   if (timings->pad)
+   return -EINVAL;

-   pad = timings->pad;
timings->pad = vin->sink_pad_idx;

ret = v4l2_subdev_call(sd, pad, enum_dv_timings, timings);


   Does this still compile after you removed 'pad'?



-   timings->pad = pad;
+   timings->pad = 0;

return ret;
 }
@@ -600,14 +602,16 @@ static int rvin_dv_timings_cap(struct file *file, void 
*priv_fh,
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int pad, ret;
+   int ret;
+
+   if (cap->pad)
+   return -EINVAL;

-   pad = cap->pad;
cap->pad = vin->sink_pad_idx;

ret = v4l2_subdev_call(sd, pad, dv_timings_cap, cap);


   And this?



-   cap->pad = pad;
+   cap->pad = 0;

return ret;
 }

[...]

MBR, Sergei

Re: [PATCH 01/16] rcar-vin: reset bytesperline and sizeimage when resetting format

[Sergei Shtylyov]

Hello!

On 3/14/2017 9:59 PM, Niklas Söderlund wrote:


These two where forgotten when refactoring the format reset code. If


   s/where/were/?


they are not also reset at the same time as width and height the format
returned from G_FMT will not match reality.

Signed-off-by: Niklas Söderlund 

[...]

MBR, Sergei

[PATCH] media: platform: rcar_imr: add IMR-LSX3 support

[Sergei Shtylyov]

Add support for the image renderer light SRAM extended 3 (IMR-LSX3) found
only in the R-Car V2H (R8A7792) SoC.  It differs  from IMR-LX4 in that it
supports only planar video formats but can use the video capture data for
the textures.

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch  is against the 'media_tree.git' repo's 'master' branch plus the
latest version of the  Renesas IMR driver...

 Documentation/devicetree/bindings/media/rcar_imr.txt |   11 +-
 drivers/media/platform/rcar_imr.c|   93 ---
 2 files changed, 90 insertions(+), 14 deletions(-)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- media_tree.orig/Documentation/devicetree/bindings/media/rcar_imr.txt
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -8,9 +8,14 @@ and drawing with respect to any shape th
 
 Required properties:
 
-- compatible: "renesas,-imr-lx4", "renesas,imr-lx4" as a fallback for
-  the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs,
-  where the examples with  are:
+- compatible:
+  "renesas,-imr-lsx3", "renesas,imr-lsx3" as a fallback for the image
+  renderer light SRAM extended 3 (IMR-LSX3) found in the R-Car gen2 SoCs, where
+  the examples with  are:
+  - "renesas,r8a7792-imr-lsx3" for R-Car V2H;
+  "renesas,-imr-lx4", "renesas,imr-lx4" as a fallback for the image
+  renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs, where the
+  examples with  are:
   - "renesas,r8a7795-imr-lx4" for R-Car H3,
   - "renesas,r8a7796-imr-lx4" for R-Car M3-W.
 - reg: offset and length of the register block;
Index: media_tree/drivers/media/platform/rcar_imr.c
===
--- media_tree.orig/drivers/media/platform/rcar_imr.c
+++ media_tree/drivers/media/platform/rcar_imr.c
@@ -1,5 +1,5 @@
 /*
- * rcar_imr.c -- R-Car IMR-LX4 Driver
+ * rcar_imr.c -- R-Car IMR-LSX3/LX4 Driver
  *
  * Copyright (C) 2015-2017 Cogent Embedded, Inc. <sou...@cogentembedded.com>
  *
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -81,8 +81,21 @@ struct imr_format_info {
u32 flags;
 };
 
+enum imr_gen {
+   IMR_LSX3,
+   IMR_LX4,
+};
+
+/* IMR type specific data */
+struct imr_type {
+   enum imr_gengen;
+   const struct imr_format_info *formats;
+   unsigned intnum_formats;
+};
+
 /* per-device data */
 struct imr_device {
+   const struct imr_type   *type;
struct device   *dev;
struct clk  *clock;
void __iomem*mmio;
@@ -180,6 +193,7 @@ struct imr_ctx {
 #define IMR_IMR_IEMBIT(1)
 #define IMR_IMR_INMBIT(2)
 
+#define IMR_CMRCR_TXTM BIT(0)  /* IMR-LSX3 only */
 #define IMR_CMRCR_LUCE BIT(1)
 #define IMR_CMRCR_CLCE BIT(2)
 #define IMR_CMRCR_DUV_SHIFT3
@@ -282,6 +296,34 @@ static u32 __imr_flags_common(u32 iflags
return iflags & oflags & IMR_F_PLANES_MASK;
 }
 
+static const struct imr_format_info imr_lsx3_formats[] = {
+   {
+   .name   = "YUV 4:2:2 semiplanar (NV16)",
+   .fourcc = V4L2_PIX_FMT_NV16,
+   .flags  = IMR_F_Y8 | IMR_F_UV8 | IMR_F_PLANAR,
+   },
+   {
+   .name   = "Greyscale 8-bit",
+   .fourcc = V4L2_PIX_FMT_GREY,
+   .flags  = IMR_F_Y8 | IMR_F_PLANAR,
+   },
+   {
+   .name   = "Greyscale 10-bit",
+   .fourcc = V4L2_PIX_FMT_Y10,
+   .flags  = IMR_F_Y8 | IMR_F_Y10 | IMR_F_PLANAR,
+   },
+   {
+   .name   = "Greyscale 12-bit",
+   .fourcc = V4L2_PIX_FMT_Y12,
+   .flags  = IMR_F_Y8 | IMR_F_Y10 | IMR_F_Y12 | IMR_F_PLANAR,
+   },
+   {
+   .name   = "Chrominance UV 8-bit",
+   .fourcc = V4L2_PIX_FMT_UV8,
+   .flags  = IMR_F_UV8 | IMR_F_PLANAR,
+   },
+};
+
 static const struct imr_format_info imr_lx4_formats[] = {
{
.name   = "YUV 4:2:2 semiplanar (NV16)",
@@ -335,6 +377,18 @@ static const struct imr_format_info imr_
},
 };
 
+static const struct imr_type imr_lsx3 = {
+   .gen= IMR_LSX3,
+   .formats= imr_lsx3_formats,
+   .num_formats= ARRAY_SIZE(imr_lsx3_formats),
+};
+
+static const struct imr_type imr_lx4 = {
+   .gen= IMR_LX4,
+   .formats= imr_lx4_formats,
+   .num_formats= ARRAY_SIZE(imr_lx4_formats),
+};
+
 /* mesh configuration constructor */
 static struct imr_cfg *imr_cfg_create(struct imr_ctx *ctx,
   

Re: [PATCH RESEND 1/1] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 02/22/2017 10:05 PM, Sergei Shtylyov wrote:


From: Konstantin Kozhevnikov <konstantin.kozhevni...@cogentembedded.com>

The image renderer light extended 4 (IMR-LX4) or the distortion correction
engine is a drawing processor with a simple  instruction system capable of
referencing data on an external memory as 2D texture data and performing
texture mapping and drawing with respect to any shape that is split into
triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer found
in the R-Car gen3 SoCs; the R-Car gen2 support  can be added later...

[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the guard  macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT()/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed IMR_DLSR to IMR_DLPR to match the manual,
separated the register offset/bit #define's, removed *inline* from .c file,
fixed lines over 80 columns, removed useless parens, operators, casts,
braces, variables, #include's, (commented out) statements, and even
function, inserted empty line after desclaration, removed extra empty
lines, reordered some local variable desclarations, removed calls to
4l2_err() on kmalloc() failure, fixed the error returned by imr_default(),
avoided code duplication in the IRQ handler, used '__packed' for the UAPI
structures, enclosed the macro parameters in parens, exchanged the values
of IMR_MAP_AUTO[SD]G macros.]

Signed-off-by: Konstantin Kozhevnikov
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   23
 drivers/media/platform/Kconfig   |   13
 drivers/media/platform/Makefile  |1
 drivers/media/platform/rcar_imr.c| 1923
+++
 include/uapi/linux/rcar_imr.h|   94
 5 files changed, 2054 insertions(+)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -0,0 +1,23 @@
+Renesas R-Car Image Renderer (Distortion Correction Engine)
+---

[...]

+
+Required properties:
+- compatible: must be "renesas,imr-lx4" for the image renderer light
extended 4
+  (IMR-LX4)  found in the R-Car gen3 SoCs;


Needs an SoC specific compatible string too.


   Strings, to be precise -- there are several SoCs but the IMR-LX4 core seems
the same among them. Well, if you say so...


The description is above, so you just need to list the compatible
strings.


   There's (most probably) gonna be other versions of the IMR core supported,
(this core can be forund in gen2 SoCs too)...


   Seriously, I strongly doubt that we need the SoC specific compatibles in 
this case -- they don't add any value and seem to only clutter the bindings 
(more so with adding support for the other variants of the IMR core). The 
manuals don't seem to have any real differences between the SoCs for any given 
variant of the IMR core...


MBR, Sergei

[PATCH v5] media: platform: Renesas IMR driver

[Sergei Shtylyov]

From: Konstantin Kozhevnikov <konstantin.kozhevni...@cogentembedded.com>

The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...

[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the  guard macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed DLSR, CMRCR.DY1{0|2}, and ICR bits to
match the manual, changed the prefixes of the CMRCR[2]/TRI{M|C}R bits/
fields to match the manual, removed non-existent TRIMR.D{Y|U}D{X|V}M bits,
added/used the IMR/{UV|CP}DPOR/SUSR bits/fields/shifts, separated the
register offset/bit #define's, sorted the instruction macros by opcode,
removed unsupported LINE instruction, masked the register address in
WTL[2]/WTS instruction macros, moved the display list #define's after
the register #define's, removing the redundant comment, avoided setting
reserved bits when writing CMRCCR[2]/TRIMCR, used the SR bits instead of
a bare number, used ALIGN() macro in imr_ioctl_map(), removed *inline*
from .c file, fixed lines over 80 columns, removed useless spaces,
comments, parens, operators, casts, braces, variables, #include's,
statements, and even 1 function, uppercased the abbreviations, made
comment wording more consistent/correct, fixed the comment typos,
reformatted some multiline comments, inserted empty line after declaration,
removed extra empty lines, reordered some local variable desclarations,
removed calls to 4l2_err() on kmalloc() failure, replaced '*' with 'x'
in some format strings for v4l2_dbg(), fixed the error returned by
imr_default(), avoided code duplication in the IRQ handler, used
'__packed' for the UAPI structures, enclosed the macro parameters in
parens, exchanged the values of IMR_MAP_AUTO{S|D}G macros.]

Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

Changes in version 5:
- used ALIGN() macro in imr_ioctl_map();
- moved the display list #define's after the register #define's, removing the
  redundant comment;
- uppercased the "tbd" abbreviation in the comments;
- made the TRI instruction types A/B/C named consistently;
- avoided quotes around the coordinate's names;
- avoided some  hyphens in the comments;
- removed spaces around / and before ? in the comments;
- reworded some comments;
- reformatted some multiline comments;
- fixed typos in the comments.

Changes in version 4:
- added/used the SUSR fields/shifts.

Changes in version 3:
- added/used the {UV|CP}DPOR fields/shifts;
- removed unsupported LINE instruction;
- replaced '*' with 'x' in the string passed to v4l2_dbg() in
  imr_dl_program_setup();
- switched to prepending the SoC model to "imr-lx4" in the "compatible" prop
  strings.

Changes in version 2:
- renamed the ICR bits to match the manual;
- added/used  the IMR bits;
- changed the prefixes of the CMRCR[2]/TRI{M|C}R bits/fields to match the
  manual;
- renamed the CMRCR.DY1{0|2} bits to match the manual;
- removed non-existent TRIMR.D{Y|U}D{X|V}M bits;
- used the SR bits instead of a bare number;
- sorted the instruction macros by opcode, removing redundant parens;
- masked the register address in WTL[2]/WTS instruction macros;
- avoided setting reserved bits when writing to CMRCCR[2]/TRIMCR;
- mentioned the video capture data as a texture source in the binding and the
  patch description;
- documented the SoC specific "compatible" values;
- clarified the "interrupts" and "clocks" property text;
- updated the patch description.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   27 
 drivers/media/platform/Kconfig   |   13 
 drivers/media/platform/Makefile  |1 
 drivers/media/platform/rcar_imr.c| 1943 +++
 include/uapi/linux/rcar_imr.h|   94 
 5 files changed, 2078 insertions(+)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.tx

[PATCH v4] media: platform: Renesas IMR driver

[Sergei Shtylyov]

From: Konstantin Kozhevnikov <konstantin.kozhevni...@cogentembedded.com>

The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...

[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the  guard macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed DLSR, CMRCR.DY1{0|2}, and ICR bits to
match the manual, changed the prefixes of the CMRCR[2]/TRI{M|C}R bits/
fields to match the manual, removed non-existent TRIMR.D{Y|U}D{X|V}M bits,
added/used the IMR/{UV|CP}DPOR/SUSR bits/fields/shifts, separated the
register offset/bit #define's, sorted the instruction macros by opcode,
removed unsupported LINE instruction, masked the register address in
WTL[2]/WTS instruction macros, avoided setting reserved bits when writing
to CMRCCR[2]/TRIMCR, used the SR bits instead of a bare number, removed
*inline* from .c file, fixed lines over 80 columns, removed useless parens,
operators, casts, braces, variables, #include's, statements, and even 1
function, inserted empty line after declaration, removed extra empty lines,
reordered some local variable desclarations, removed calls to 4l2_err() on
kmalloc() failure, replaced '*' with 'x' in some format strings for
v4l2_dbg(), fixed the error returned by imr_default(), avoided code
duplication in the IRQ handler, used '__packed' for the UAPI structures,
enclosed the macro parameters in parens, exchanged the values of
IMR_MAP_AUTO{S|D}G macros.]

Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

Changes in version 4:
- added/used SUSR fields/shifts.

Changes in version 3:
- added/used the {UV|CP}DPOR fields/shifts;
- removed unsupported LINE instruction;
- replaced '*' with 'x' in the string passed to v4l2_dbg() in
  imr_dl_program_setup();
- switched to prepending the SoC model to "imr-lx4" in the "compatible" prop
  strings.

Changes in version 2:
- renamed the ICR bits to match the manual;
- added/used the IMR bits;
- changed the prefixes of the CMRCR[2]/TRI{M|C}R bits/fields to match the
  manual;
- renamed the CMRCR.DY1{0|2} bits to match the manual;
- removed non-existent TRIMR.D{Y|U}D{X|V}M bits;
- used the SR bits instead of a bare number;
- sorted the instruction macros by opcode, removing redundant parens;
- masked the register address in WTL[2]/WTS instruction macros;
- avoided setting reserved bits when writing to CMRCCR[2]/TRIMCR;
- mentioned the video capture data as a texture source in the binding and the
  patch description;
- documented the SoC specific "compatible" values;
- clarified the "interrupts" and "clocks" property text;
- updated the patch description.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   27 
 drivers/media/platform/Kconfig   |   13 
 drivers/media/platform/Makefile  |1 
 drivers/media/platform/rcar_imr.c| 1944 +++
 include/uapi/linux/rcar_imr.h|   94 
 5 files changed, 2079 insertions(+)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -0,0 +1,27 @@
+Renesas R-Car Image Renderer (Distortion Correction Engine)
+---
+
+The image renderer, or the distortion correction engine, is a drawing processor
+with a simple instruction system capable of referencing video capture data or
+data in an external memory as 2D texture data and performing texture mapping
+and drawing with respect to any shape that is split into triangular objects.
+
+Required properties:
+
+- compatible: "renesas,-imr-lx4", "renesas,imr-lx4" as a fallback for
+  the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs,
+  where the examples with  are:
+  - "renesas,r8a7795-imr-lx4" for R-Car H3,
+  - "renesas,r8a7796-imr-lx4" for R-Car M3-W.
+- reg: offset and length of t

Re: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t

[Sergei Shtylyov]

On 3/7/2017 10:52 AM, Reshetova, Elena wrote:


refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Signed-off-by: Elena Reshetova 
Signed-off-by: Hans Liljestrand 
Signed-off-by: Kees Cook 
Signed-off-by: David Windsor 

[...]

diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index 115414c..16c1313 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h

[...]

@@ -339,7 +340,7 @@ struct cx8802_dev;

 struct cx88_core {
struct list_head   devlist;
-   atomic_t   refcount;
+   refcount_t   refcount;


Could you please keep the name aligned with above and below?


You mean "not aligned" to devlist, but with a shift like it was before?


   I mean aligned, like it was before. :-)


Sure, will fix. Is the patch ok otherwise?


   I haven't noticed anything else...


Best Regards,
Elena.

[...]

MBR, Sergei

[PATCH v3] media: platform: Renesas IMR driver

[Sergei Shtylyov]

From: Konstantin Kozhevnikov <konstantin.kozhevni...@cogentembedded.com>

The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...

[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the  guard macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed DLSR, CMRCR.DY1{0|2}, and ICR bits to
match the manual, changed the prefixes of the CMRCR[2]/TRI{M|C}R bits/
fields to match the manual, removed non-existent TRIMR.D{Y|U}D{X|V}M bits,
added/used the IMR/{UV|CP}DPOR bits/fields/shifts, separated the register
offset/bit #define's, removed unsupported LINE instruction,
sorted the instruction macros by opcode, masked the register address in
WTL[2]/WTS instruction macros, avoided setting reserved bits when writing
to CMRCCR[2]/TRIMCR, used the SR bits instead of a bare number, removed
*inline* from .c file, fixed lines over 80 columns, removed useless parens,
operators, casts, braces, variables, #include's, statements, and even 1
function, inserted empty line after declaration, removed extra empty lines,
reordered some local variable desclarations, removed calls to 4l2_err() on
kmalloc() failure, replaced '*' with 'x' in some format strings for
v4l2_dbg(), fixed the error returned by imr_default(), avoided code
duplication in the IRQ handler, used '__packed' for the UAPI structures,
enclosed the macro parameters in parens, exchanged the values of
IMR_MAP_AUTO{S|D}G macros.]

Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

Changes in version 2:
- renamed the ICR bits to match the manual;
- added/used the IMR bits;
- changed the prefixes of the CMRCR[2]/TRI{M|C}R bits/fields to match the
  manual;
- renamed the CMRCR.DY1{0|2} bits to match the manual;
- removed non-existent TRIMR.D{Y|U}D{X|V}M bits;
- used the SR bits instead of a bare number;
- sorted the instruction macros by opcode, removing redundant parens;
- masked the register address in WTL[2]/WTS instruction macros;
- avoided setting reserved bits when writing to CMRCCR[2]/TRIMCR;
- mentioned the video capture data as a texture source in the binding and the
  patch description;
- documented the SoC specific "compatible" values;
- clarified the "interrupts" and "clocks" property text;
- updated the patch description.

Changes in version 3:
- added/used the {UV|CP}DPOR fields/shifts;
- removed unsupported LINE instruction;
- replaced '*' with 'x' in the string passed to v4l2_dbg() in
  imr_dl_program_setup();
- switched to prepending the SoC model to "imr-lx4" in the "compatible" prop
  strings.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   27 
 drivers/media/platform/Kconfig   |   13 
 drivers/media/platform/Makefile  |1 
 drivers/media/platform/rcar_imr.c| 1938 +++
 include/uapi/linux/rcar_imr.h|   94 
 5 files changed, 2073 insertions(+)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -0,0 +1,27 @@
+Renesas R-Car Image Renderer (Distortion Correction Engine)
+---
+
+The image renderer, or the distortion correction engine, is a drawing processor
+with a simple instruction system capable of referencing video capture data or
+data in an external memory as 2D texture data and performing texture mapping
+and drawing with respect to any shape that is split into triangular objects.
+
+Required properties:
+
+- compatible: "renesas,-imr-lx4", "renesas,imr-lx4" as a fallback for
+  the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs,
+  where the examples with  are:
+  - "renesas,r8a7795-imr-lx4" for R-Car H3,
+  - "renesas,r8a7796-imr-lx4" for R-Car M3-W.
+- reg: offset and length of the register block;
+- interrupts: single

Re: [PATCH] media: platform: Renesas IMR driver

[Sergei Shtylyov]

On 03/05/2017 01:43 PM, Magnus Damm wrote:


Thanks for your efforts with this driver. Nice to see that V2 is
getting in better shape.

In the future, would it be possible for you to include the patch
version number in the [PATCH] tag somehow?


   Sorry, I'm still getting used to 'quilt mail'...


On Fri, Mar 3, 2017 at 9:03 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:

On 03/03/2017 02:58 PM, Geert Uytterhoeven wrote:


+  - "renesas,imr-lx4-v3m" for R-Car V3M.




"renesas,-EPROBE_DEFER-imr-lx4"




   Huh? :-)



Do you know the part number of V3M?



   No, but using the names from the manual I don't need it.


NAK, like Geert says, please follow the same style as other upstream
drivers. DT compat strings is not a place for random polices.


   Note that I don't think we need the SoC specific strings (like was done 
with the VSP1/2 driver). I'm not seeing any differences between the gen3 SoCs 
looking at the most current manual...



Thanks,

/ magnus


MBR, Sergei

Re: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t

[Sergei Shtylyov]

Hello.

On 03/06/2017 05:20 PM, Elena Reshetova wrote:


refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Signed-off-by: Elena Reshetova 
Signed-off-by: Hans Liljestrand 
Signed-off-by: Kees Cook 
Signed-off-by: David Windsor 

[...]

diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index 115414c..16c1313 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -339,7 +340,7 @@ struct cx8802_dev;

 struct cx88_core {
struct list_head   devlist;
-   atomic_t   refcount;
+   refcount_t   refcount;


   Could you please keep the name aligned with above and below?



/* board name */
intnr;



MBR, Sergei

Re: [PATCH v3 3/3] drm: rcar-du: Register a completion callback with VSP1

[Sergei Shtylyov]

Hello!

On 03/05/2017 07:00 PM, Kieran Bingham wrote:


Currently we process page flip events on every display interrupt,
however this does not take into consideration the processing time needed
by the VSP1 utilised in the pipeline.

Register a callback with the VSP driver to obtain completion events, and
track them so that we only perform page flips when the full display
pipeline has completed for the frame.

Signed-off-by: Kieran Bingham 

[...]

 #endif /* __RCAR_DU_CRTC_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b0ff304ce3dc..cbb6f54c99ef 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -28,6 +28,13 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"

+static void rcar_du_vsp_complete(void *private)
+{
+   struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;


   No need for explicit cast.


+
+   rcar_du_crtc_finish_page_flip(crtc);
+}
+
 void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 {
const struct drm_display_mode *mode = >crtc.state->adjusted_mode;

[...]

MBR, Sergei

Re: [PATCH] media: platform: Renesas IMR driver

[Sergei Shtylyov]

On 03/03/2017 02:58 PM, Geert Uytterhoeven wrote:


+  - "renesas,imr-lx4-v3m" for R-Car V3M.



"renesas,-EPROBE_DEFER-imr-lx4"



   Huh? :-)


Do you know the part number of V3M?


   No, but using the names from the manual I don't need it.


Gr{oetje,eeting}s,

Geert


MBR, Sergei

Re: [PATCH] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 03/03/2017 02:24 PM, Geert Uytterhoeven wrote:


--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt



+- compatible: "renesas,imr-lx4-", "renesas,imr-lx4" as a fallback for


"renesas,-imr-lx4"


+  the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs,
+  where the examples with  are:
+  - "renesas,imr-lx4-h3" for R-Car H3,


"renesas,r8a7795-imr-lx4"


   The IMR core names were copied from the manual verbatim (just in lower case).


+  - "renesas,imr-lx4-m3-w" for R-Car M3-W,


"renesas,r8a7796-imr-lx4"


+  - "renesas,imr-lx4-v3m" for R-Car V3M.


"renesas,-EPROBE_DEFER-imr-lx4"


   Huh? :-)


Gr{oetje,eeting}s,

Geert


MBR, Sergei

[PATCH] media: platform: Renesas IMR driver

[Sergei Shtylyov]

From: Konstantin Kozhevnikov <konstantin.kozhevni...@cogentembedded.com>

The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to any shape that is
split into triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer light
extended 4 (IMR-LX4) found in the R-Car gen3 SoCs; the R-Car gen2 support
can be added later...

[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the guard  macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT()/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed DLSR, CMRCR.DY1{0|2}, and ICR bits to
match the manual, changed the prefixes of the CMRCR[2]/TRI{M|C}R bits/
fields to match the manual, removed non-existent TRIMR.D{Y|U}D{X|V}M bits,
added/used the IMR bits, separated the register offset/bit #define's,
sorted the instruction macros by opcode, masked the register address in
WTL[2]/WTS instruction macros, avoided setting reserved bits when writing
to CMRCCR[2]/TRIMCR, used the SR bits instead of a bare number, removed
*inline* from .c file, fixed lines over 80 columns, removed useless parens,
operators, casts, braces, variables, #include's, statements, and even 1
function, inserted empty line after desclaration, removed extra empty
lines, reordered some local variable desclarations, removed calls to
4l2_err() on kmalloc() failure, fixed the error returned by imr_default(),
avoided code duplication in the IRQ handler, used '__packed' for the UAPI
structures, enclosed the macro parameters in parens, exchanged the values
of IMR_MAP_AUTO{S|D}G macros.]

Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
Changes in version 2:
- renamed the ICR bits to match the manual;
- added/used the IMR bits;
- changed the prefixes of the CMRCR[2]/TRI{M|C}R bits/fields to match the
  manual;
- renamed the CMRCR.DY1{0|2} bits to match the manual;
- removed non-existent TRIMR.D{Y|U}D{X|V}M bits;
- used the SR bits instead of a bare number;
- sorted the instruction macros by opcode, removing redundant parens;
- masked the register address in WTL[2]/WTS instruction macros;
- avoided setting reserved bits when writing to CMRCCR[2]/TRIMCR;
- mentioned the video capture data as a texture source in the binding and the
  patch description;
- documented the SoC specific "compatible" values;
- clarified the "interrupts" and "clocks" property text;
- updated the patch description.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   28 
 drivers/media/platform/Kconfig   |   13 
 drivers/media/platform/Makefile  |1 
 drivers/media/platform/rcar_imr.c| 1926 +++
 include/uapi/linux/rcar_imr.h|   94 
 5 files changed, 2062 insertions(+)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -0,0 +1,28 @@
+Renesas R-Car Image Renderer (Distortion Correction Engine)
+---
+
+The image renderer, or the distortion correction engine, is a drawing processor
+with a simple instruction system capable of referencing video capture data or
+data in an external memory as 2D texture data and performing texture mapping
+and drawing with respect to any shape that is split into triangular objects.
+
+Required properties:
+
+- compatible: "renesas,imr-lx4-", "renesas,imr-lx4" as a fallback for
+  the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3 SoCs,
+  where the examples with  are:
+  - "renesas,imr-lx4-h3" for R-Car H3,
+  - "renesas,imr-lx4-m3-w" for R-Car M3-W,
+  - "renesas,imr-lx4-v3m" for R-Car V3M.
+- reg: offset and length of the register block;
+- interrupts: single interrupt specifier;
+- clocks: single clock phandle/specifier pair.
+
+Example:
+
+   imr-lx4@fe86 {
+   compatible = "renesas,imr-lx4-h3", "renesas,imr-lx4";
+   reg = <0 0xfe86 0 0x2000>;
+   interrupts = ;
+   clocks = < CPG_MOD 823>;
+   };
Index: media_tree/drivers/media/platform/Kconfig
===
--- media_tr

Re: [PATCH RESEND 1/1] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 02/22/2017 05:25 PM, Rob Herring wrote:


From: Konstantin Kozhevnikov <konstantin.kozhevni...@cogentembedded.com>

The image renderer light extended 4 (IMR-LX4) or the distortion correction
engine is a drawing processor with a simple  instruction system capable of
referencing data on an external memory as 2D texture data and performing
texture mapping and drawing with respect to any shape that is split into
triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer found
in the R-Car gen3 SoCs; the R-Car gen2 support  can be added later...

[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the guard  macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT()/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed IMR_DLSR to IMR_DLPR to match the manual,
separated the register offset/bit #define's, removed *inline* from .c file,
fixed lines over 80 columns, removed useless parens, operators, casts,
braces, variables, #include's, (commented out) statements, and even
function, inserted empty line after desclaration, removed extra empty
lines, reordered some local variable desclarations, removed calls to
4l2_err() on kmalloc() failure, fixed the error returned by imr_default(),
avoided code duplication in the IRQ handler, used '__packed' for the UAPI
structures, enclosed the macro parameters in parens, exchanged the values
of IMR_MAP_AUTO[SD]G macros.]

Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   23
 drivers/media/platform/Kconfig   |   13
 drivers/media/platform/Makefile  |1
 drivers/media/platform/rcar_imr.c| 1923 +++
 include/uapi/linux/rcar_imr.h|   94
 5 files changed, 2054 insertions(+)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -0,0 +1,23 @@
+Renesas R-Car Image Renderer (Distortion Correction Engine)
+---
+
+The image renderer  or the distortion correction  engine is a drawing processor
+with a simple  instruction system capable of referencing data in external 
memory
+as  2D texture data and performing texture mapping and drawing with respect to
+any shape that is split into triangular objects.


Please fix extra spaces in here.


   OK. Seems to be your pet peeve? :-)


+
+Required properties:
+- compatible: must be "renesas,imr-lx4" for the image renderer light extended 4
+  (IMR-LX4)  found in the R-Car gen3 SoCs;


Needs an SoC specific compatible string too.


   Strings, to be precise -- there are several SoCs but the IMR-LX4 core 
seems the same among them. Well, if you say so...



The description is above, so you just need to list the compatible
strings.


   There's (most probably) gonna be other versions of the IMR core supported, 
(this core can be forund in gen2 SoCs too)...



+- reg: offset and length of the register block;
+- interrupts: interrupt specifier;


How many interrupts?


   I thought it was clear from using singular.


+- clocks: clock phandle and specifier pair.


How many clocks?


   Two, perhaps. I meant a single clock by using singular again.

[...]

MBR, Sergei

[PATCH RESEND 1/1] media: platform: Renesas IMR driver

[Sergei Shtylyov]

From: Konstantin Kozhevnikov <konstantin.kozhevni...@cogentembedded.com>

The image renderer light extended 4 (IMR-LX4) or the distortion correction
engine is a drawing processor with a simple  instruction system capable of
referencing data on an external memory as 2D texture data and performing
texture mapping and drawing with respect to any shape that is split into
triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer found
in the R-Car gen3 SoCs; the R-Car gen2 support  can be added later...

[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the guard  macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT()/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed IMR_DLSR to IMR_DLPR to match the manual,
separated the register offset/bit #define's, removed *inline* from .c file,
fixed lines over 80 columns, removed useless parens, operators, casts,
braces, variables, #include's, (commented out) statements, and even
function, inserted empty line after desclaration, removed extra empty
lines, reordered some local variable desclarations, removed calls to
4l2_err() on kmalloc() failure, fixed the error returned by imr_default(),
avoided code duplication in the IRQ handler, used '__packed' for the UAPI
structures, enclosed the macro parameters in parens, exchanged the values
of IMR_MAP_AUTO[SD]G macros.]

Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   23 
 drivers/media/platform/Kconfig   |   13 
 drivers/media/platform/Makefile  |1 
 drivers/media/platform/rcar_imr.c| 1923 +++
 include/uapi/linux/rcar_imr.h|   94 
 5 files changed, 2054 insertions(+)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -0,0 +1,23 @@
+Renesas R-Car Image Renderer (Distortion Correction Engine)
+---
+
+The image renderer  or the distortion correction  engine is a drawing processor
+with a simple  instruction system capable of referencing data in external 
memory
+as  2D texture data and performing texture mapping and drawing with respect to
+any shape that is split into triangular objects.
+
+Required properties:
+- compatible: must be "renesas,imr-lx4" for the image renderer light extended 4
+  (IMR-LX4)  found in the R-Car gen3 SoCs;
+- reg: offset and length of the register block;
+- interrupts: interrupt specifier;
+- clocks: clock phandle and specifier pair.
+
+Example:
+
+   imr-lx4@fe86 {
+   compatible = "renesas,imr-lx4";
+   reg = <0 0xfe86 0 0x2000>;
+   interrupts = ;
+   clocks = < CPG_MOD 823>;
+   };
Index: media_tree/drivers/media/platform/Kconfig
===
--- media_tree.orig/drivers/media/platform/Kconfig
+++ media_tree/drivers/media/platform/Kconfig
@@ -399,6 +399,19 @@ config VIDEO_RENESAS_FCP
  To compile this driver as a module, choose M here: the module
  will be called rcar-fcp.
 
+config VIDEO_RENESAS_IMR
+   tristate "Renesas Image Renderer (Distortion Correction Engine)"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_RENESAS || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ This is a V4L2 driver for the Renesas Image Renderer Light Extended 4
+ (IMR-LX4).
+
+ To compile this driver as a module, choose M here: the module
+ will be called rcar_imr.
+
 config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
Index: media_tree/drivers/media/platform/Makefile
===
--- media_tree.orig/drivers/media/platform/Makefile
+++ media_tree/drivers/media/platform/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_SOC_CAMERA)  += soc_camera/
 obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o
 obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
+obj-$(CONFIG_VIDEO_RENESAS_IMR) 

Re: [PATCH 1/1] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Just noticed that quilt has swallowed From: in the patch body while I meant to 
keep Konstantin as an author... will 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

[PATCH 1/1] media: platform: Renesas IMR driver

[Sergei Shtylyov]

The image renderer light extended 4 (IMR-LX4) or the distortion correction
engine is a drawing processor with a simple  instruction system capable of
referencing data on an external memory as 2D texture data and performing
texture mapping and drawing with respect to any shape that is split into
triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer found
in the R-Car gen3 SoCs; the R-Car gen2 support  can be added later...

[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the guard  macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT()/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed IMR_DLSR to IMR_DLPR to match the manual,
separated the register offset/bit #define's, removed *inline* from .c file,
fixed lines over 80 columns, removed useless parens, operators, casts,
braces, variables, #include's, (commented out) statements, and even
function, inserted empty line after desclaration, removed extra empty
lines, reordered some local variable desclarations, removed calls to
4l2_err() on kmalloc() failure, fixed the error returned by imr_default(),
avoided code duplication in the IRQ handler, used '__packed' for the UAPI
structures, enclosed the macro parameters in parens, exchanged the values
of IMR_MAP_AUTO[SD]G macros.]

Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   23 
 drivers/media/platform/Kconfig   |   13 
 drivers/media/platform/Makefile  |1 
 drivers/media/platform/rcar_imr.c| 1923 +++
 include/uapi/linux/rcar_imr.h|   94 
 5 files changed, 2054 insertions(+)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -0,0 +1,23 @@
+Renesas R-Car Image Renderer (Distortion Correction Engine)
+---
+
+The image renderer  or the distortion correction  engine is a drawing processor
+with a simple  instruction system capable of referencing data in external 
memory
+as  2D texture data and performing texture mapping and drawing with respect to
+any shape that is split into triangular objects.
+
+Required properties:
+- compatible: must be "renesas,imr-lx4" for the image renderer light extended 4
+  (IMR-LX4)  found in the R-Car gen3 SoCs;
+- reg: offset and length of the register block;
+- interrupts: interrupt specifier;
+- clocks: clock phandle and specifier pair.
+
+Example:
+
+   imr-lx4@fe86 {
+   compatible = "renesas,imr-lx4";
+   reg = <0 0xfe86 0 0x2000>;
+   interrupts = ;
+   clocks = < CPG_MOD 823>;
+   };
Index: media_tree/drivers/media/platform/Kconfig
===
--- media_tree.orig/drivers/media/platform/Kconfig
+++ media_tree/drivers/media/platform/Kconfig
@@ -399,6 +399,19 @@ config VIDEO_RENESAS_FCP
  To compile this driver as a module, choose M here: the module
  will be called rcar-fcp.
 
+config VIDEO_RENESAS_IMR
+   tristate "Renesas Image Renderer (Distortion Correction Engine)"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_RENESAS || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ This is a V4L2 driver for the Renesas Image Renderer Light Extended 4
+ (IMR-LX4).
+
+ To compile this driver as a module, choose M here: the module
+ will be called rcar_imr.
+
 config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
Index: media_tree/drivers/media/platform/Makefile
===
--- media_tree.orig/drivers/media/platform/Makefile
+++ media_tree/drivers/media/platform/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_SOC_CAMERA)  += soc_camera/
 obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o
 obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
+obj-$(CONFIG_VIDEO_RENESAS_IMR)+= rcar_imr.o
 obj-$(CONFIG_VIDEO_RENESAS_VSP

[PATCH 1/1] media: platform: Renesas IMR driver

[Sergei Shtylyov]

The image renderer light extended 4 (IMR-LX4) or the distortion correction
engine is a drawing processor with a simple  instruction system capable of
referencing data on an external memory as 2D texture data and performing
texture mapping and drawing with respect to any shape that is split into
triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer found
in the R-Car gen3 SoCs; the R-Car gen2 support  can be added later...

[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the guard  macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT()/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed IMR_DLSR to IMR_DLPR to match the manual,
separated the register offset/bit #define's, removed *inline* from .c file,
fixed lines over 80 columns, removed useless parens, operators, casts,
braces, variables, #include's, (commented out) statements, and even
function, inserted empty line after desclaration, removed extra empty
lines, reordered some local variable desclarations, removed calls to
4l2_err() on kmalloc() failure, fixed the error returned by imr_default(),
avoided code duplication in the IRQ handler, used '__packed' for the UAPI
structures, enclosed the macro parameters in parens, exchanged the values
of IMR_MAP_AUTO[SD]G macros.]

Signed-off-by: Konstantin Kozhevnikov 
<konstantin.kozhevni...@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

 Documentation/devicetree/bindings/media/rcar_imr.txt |   23 
 drivers/media/platform/Kconfig   |   13 
 drivers/media/platform/Makefile  |1 
 drivers/media/platform/rcar_imr.c| 1923 +++
 include/uapi/linux/rcar_imr.h|   94 
 5 files changed, 2054 insertions(+)

Index: media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
===
--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
@@ -0,0 +1,23 @@
+Renesas R-Car Image Renderer (Distortion Correction Engine)
+---
+
+The image renderer  or the distortion correction  engine is a drawing processor
+with a simple  instruction system capable of referencing data in external 
memory
+as  2D texture data and performing texture mapping and drawing with respect to
+any shape that is split into triangular objects.
+
+Required properties:
+- compatible: must be "renesas,imr-lx4" for the image renderer light extended 4
+  (IMR-LX4)  found in the R-Car gen3 SoCs;
+- reg: offset and length of the register block;
+- interrupts: interrupt specifier;
+- clocks: clock phandle and specifier pair.
+
+Example:
+
+   imr-lx4@fe86 {
+   compatible = "renesas,imr-lx4";
+   reg = <0 0xfe86 0 0x2000>;
+   interrupts = ;
+   clocks = < CPG_MOD 823>;
+   };
Index: media_tree/drivers/media/platform/Kconfig
===
--- media_tree.orig/drivers/media/platform/Kconfig
+++ media_tree/drivers/media/platform/Kconfig
@@ -399,6 +399,19 @@ config VIDEO_RENESAS_FCP
  To compile this driver as a module, choose M here: the module
  will be called rcar-fcp.
 
+config VIDEO_RENESAS_IMR
+   tristate "Renesas Image Renderer (Distortion Correction Engine)"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_RENESAS || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ This is a V4L2 driver for the Renesas Image Renderer Light Extended 4
+ (IMR-LX4).
+
+ To compile this driver as a module, choose M here: the module
+ will be called rcar_imr.
+
 config VIDEO_RENESAS_VSP1
tristate "Renesas VSP1 Video Processing Engine"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
Index: media_tree/drivers/media/platform/Makefile
===
--- media_tree.orig/drivers/media/platform/Makefile
+++ media_tree/drivers/media/platform/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_SOC_CAMERA)  += soc_camera/
 obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o
 obj-$(CONFIG_VIDEO_RENESAS_FDP1)   += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
+obj-$(CONFIG_VIDEO_RENESAS_IMR)+= rcar_imr.o
 obj-$(CONFIG_VIDEO_RENESAS_VSP

[PATCH] vsp1: remove UAPI support for R-Car gen2 VSPDs

[Sergei Shtylyov]

We  are going to use the  R-Car  gen2 VSPDs as the DU compositors, so will
have to disable  the UAPI support for them...

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

 drivers/media/platform/vsp1/vsp1_drv.c |1 -
 1 file changed, 1 deletion(-)

Index: media_tree/drivers/media/platform/vsp1/vsp1_drv.c
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_drv.c
+++ media_tree/drivers/media/platform/vsp1/vsp1_drv.c
@@ -588,7 +588,6 @@ static const struct vsp1_device_info vsp
.uds_count = 1,
.wpf_count = 1,
.num_bru_inputs = 4,
-   .uapi = true,
}, {
.version = VI6_IP_VERSION_MODEL_VSPS_M2,
.model = "VSP1-S",

--
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 20/32] media: rcar-vin: expose a sink pad if we are on Gen3

[Sergei Shtylyov]

On 11/02/2016 04:23 PM, Niklas Söderlund wrote:


Refactor the probe code path to look for the digital subdevice, if one
is found use it just like the driver did before (Gen2 mode) but if it's
not found prepare for a Gen3 mode by registering a pad for the media
controller API to use.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 21 -
 drivers/media/platform/rcar-vin/rcar-vin.h  |  9 +
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index f961957..ce8b59a 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -308,6 +308,25 @@ static const struct of_device_id rvin_of_id_table[] = {
 };
 MODULE_DEVICE_TABLE(of, rvin_of_id_table);

+static int rvin_graph_init(struct rvin_dev *vin)
+{
+   int ret;
+
+   /* Try to get digital video pipe */
+   ret = rvin_digital_graph_init(vin);
+
+   /* No digital pipe and we are on Gen3 try to joint CSI2 group */
+   if (ret == -ENODEV && vin->info->chip == RCAR_GEN3) {
+
+   vin->pads[RVIN_SINK].flags = MEDIA_PAD_FL_SINK;
+   ret = media_entity_pads_init(>vdev.entity, 1, vin->pads);
+   if (ret)
+   return ret;


   This *if* is not necessary, you'll return below anyway.


+   }
+
+   return ret;
+}
+
 static int rcar_vin_probe(struct platform_device *pdev)
 {
const struct of_device_id *match;

[...]

MBR, Sergei

--
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 03/32] media: rcar-vin: reset bytesperline and sizeimage when resetting format

[Sergei Shtylyov]

Hello.

On 11/02/2016 04:23 PM, Niklas Söderlund wrote:


These two fields where forgotten when refactoring the format reset code
path. If they are not also reset at the same time as width and hight the
format read using G_FMT will not match realty.


   Reality?


Signed-off-by: Niklas Söderlund 

[...]

MBR, Sergei

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

[Sergei Shtylyov]

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.

[...]

MBR, Sergei

--
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] vsp1: add R8A7792 VSP1V support

[Sergei Shtylyov]

Hello.

On 09/02/2016 01:47 AM, Laurent Pinchart wrote:


Add  support for the R8A7792 VSP1V cores which are different from the other
gen2 VSP1 cores...

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.


The vsp1/next branch of my media.git tree contains a few patches that conflict
with this patch. I've resolved the conflicts manually and pushed the result to

git://linuxtv.org/pinchartl/media.git vsp1/next

Could you please check the conflict resolution ?


   It seems alright. But I hate, hate, hate the forced branch updates! One 
wrong move and you're trapped with the changes you don't know how to resolve 
anyway... :-(



Could you please also give me the full 32-bit IP version number for the VSP1V-
D and VSP1V-S on R8A7792 ?


   As I told you on IRC:

[2.563823] vsp1 fe928000.vsp1: IP version 0x01011201
[2.574416] vsp1 fe93.vsp1: IP version 0x01011301
[2.583543] vsp1 fe938000.vsp1: IP version 0x01011301

MBR, Sergei

--
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: [PATCHv3 09/10] [media] rcar-vin: rework how subdeivce is found and bound

[Sergei Shtylyov]

Hello.

On 08/15/2016 06:06 PM, Niklas Söderlund wrote:


The original drivers code to find a subdevice by looking in the DT grpah


   s/grpah/graph/.


and how the callbacks to the v4l2 async bind framework where poorly
written. The most obvious example of badness was the duplication of data
in the struct rvin_graph_entity.

This patch removes the data duplication, simplifies the parsing of the
DT graph and add checks to the v4l2 callbacks.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 232 +---
 drivers/media/platform/rcar-vin/rcar-vin.h  |   8 +-
 2 files changed, 111 insertions(+), 129 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 3941134..39bf6fc 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c

[...]

@@ -94,89 +102,111 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
 {
struct rvin_dev *vin = notifier_to_vin(notifier);

-   vin_dbg(vin, "subdev %s bound\n", subdev->name);
+   v4l2_set_subdev_hostdata(subdev, vin);

-   vin->digital.entity = >entity;
-   vin->digital.subdev = subdev;
+   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;
+   }

-   return 0;
+   vin_err(vin, "no entity for subdev %s to bind\n", subdev->name);
+   return -EINVAL;
 }

-static int rvin_digital_parse(struct rvin_dev *vin,
- struct device_node *node)
+static int rvin_digitial_parse_v4l2(struct rvin_dev *vin,


   s/digitial/digital/.

[...]

diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 93daa05..edfe658 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -70,10 +70,12 @@ struct rvin_video_format {
u8 bpp;
 };

+/**
+ * struct rvin_graph_entity - Video endpoint from async framework
+ * @asd:   sub-device descriptor for async framework
+ * @subdev:subdevice matched using async framework
+ */


Looks like a materia for a separate patch...


 struct rvin_graph_entity {
-   struct device_node *node;
-   struct media_entity *entity;
-
struct v4l2_async_subdev asd;
struct v4l2_subdev *subdev;
 };


MBR, Sergei

--
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: [PATCHv3 05/10] [media] rcar-vin: return correct error from platform_get_irq()

[Sergei Shtylyov]

On 08/15/2016 06:06 PM, Niklas Söderlund wrote:


Fix a error from the original driver where the wrong error code is
returned if the driver fails to get a IRQ number from
platform_get_irq().

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index a1eb26b..3941134 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -282,8 +282,8 @@ static int rcar_vin_probe(struct platform_device *pdev)
return PTR_ERR(vin->base);

irq = platform_get_irq(pdev, 0);
-   if (irq <= 0)
-   return ret;
+   if (irq < 0)


   You don't explain this change. It's OK however (my patch fixing this 
function not to return 0 on error is in GregKH's driver-core-next tree).



+   return irq;

ret = rvin_dma_probe(vin, irq);
if (ret)


MBR, Sergei

--
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: [PATCHv3 06/10] [media] rcar-vin: do not use v4l2_device_call_until_err()

[Sergei Shtylyov]

On 08/15/2016 06:06 PM, Niklas Söderlund wrote:


Fix a error from the original driver where v4l2_device_call_until_err()
where used for the pad specific v4l2 operation set_fmt.  Also fix up the
error path from this fix so if there is an error it will be propagated
to the caller.



The error path label have also been renamed as a result from a
nitpicking review comment since we are fixing other issues here.


   This looks like a material for the 2 or even 3 separate patches...


Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 72fe6bc..3f80a0b 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -114,10 +114,9 @@ static int __rvin_try_format_source(struct rvin_dev *vin,

format.pad = vin->src_pad_idx;

-   ret = v4l2_device_call_until_err(sd->v4l2_dev, 0, pad, set_fmt,
-pad_cfg, );
-   if (ret < 0)
-   goto cleanup;
+   ret = v4l2_subdev_call(sd, pad, set_fmt, pad_cfg, );
+   if (ret < 0 && ret != -ENOIOCTLCMD)
+   goto done;

v4l2_fill_pix_format(pix, );

@@ -127,9 +126,9 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
vin_dbg(vin, "Source resolution: %ux%u\n", source->width,
source->height);

-cleanup:
+done:
v4l2_subdev_free_pad_config(pad_cfg);
-   return 0;
+   return ret;
 }

 static int __rvin_try_format(struct rvin_dev *vin,


MBR, Sergei

--
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: [PATCHv3 04/10] [media] rcar-vin: rename entity to digital

[Sergei Shtylyov]

Hello.

On 08/15/2016 06:06 PM, Niklas Söderlund wrote:


When Gen3 support is added to the driver more then one possible video


   s/then/than/.


source entity will be possible. Knowing that the name entity is a bad
one, rename it to digital since it will deal with the digital input
source.

Signed-off-by: Niklas Söderlund 

[...]

   Other than that, the patch looked OK to me.

MBR, Sergei

--
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] vsp1: add R8A7792 VSP1V support

[Sergei Shtylyov]

Add  support for the R8A7792 VSP1V cores which are different from the other
gen2 VSP1 cores...

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.

 drivers/media/platform/vsp1/vsp1_drv.c  |   20 
 drivers/media/platform/vsp1/vsp1_regs.h |2 ++
 2 files changed, 22 insertions(+)

Index: media_tree/drivers/media/platform/vsp1/vsp1_drv.c
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_drv.c
+++ media_tree/drivers/media/platform/vsp1/vsp1_drv.c
@@ -596,6 +596,26 @@ static const struct vsp1_device_info vsp
.num_bru_inputs = 4,
.uapi = true,
}, {
+   .version = VI6_IP_VERSION_MODEL_VSPS_V2H,
+   .gen = 2,
+   .features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_LUT |
+   VSP1_HAS_SRU | VSP1_HAS_WPF_VFLIP,
+   .rpf_count = 4,
+   .uds_count = 1,
+   .wpf_count = 4,
+   .num_bru_inputs = 4,
+   .uapi = true,
+   }, {
+   .version = VI6_IP_VERSION_MODEL_VSPD_V2H,
+   .gen = 2,
+   .features = VSP1_HAS_BRU | VSP1_HAS_CLU | VSP1_HAS_LUT |
+   VSP1_HAS_LIF,
+   .rpf_count = 4,
+   .uds_count = 1,
+   .wpf_count = 1,
+   .num_bru_inputs = 4,
+   .uapi = true,
+   }, {
.version = VI6_IP_VERSION_MODEL_VSPI_GEN3,
.gen = 3,
.features = VSP1_HAS_CLU | VSP1_HAS_LUT | VSP1_HAS_SRU
Index: media_tree/drivers/media/platform/vsp1/vsp1_regs.h
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_regs.h
+++ media_tree/drivers/media/platform/vsp1/vsp1_regs.h
@@ -660,6 +660,8 @@
 #define VI6_IP_VERSION_MODEL_VSPR_H2   (0x0a << 8)
 #define VI6_IP_VERSION_MODEL_VSPD_GEN2 (0x0b << 8)
 #define VI6_IP_VERSION_MODEL_VSPS_M2   (0x0c << 8)
+#define VI6_IP_VERSION_MODEL_VSPS_V2H  (0x12 << 8)
+#define VI6_IP_VERSION_MODEL_VSPD_V2H  (0x13 << 8)
 #define VI6_IP_VERSION_MODEL_VSPI_GEN3 (0x14 << 8)
 #define VI6_IP_VERSION_MODEL_VSPBD_GEN3(0x15 << 8)
 #define VI6_IP_VERSION_MODEL_VSPBC_GEN3(0x16 << 8)

--
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: [PATCHv2 4/7] media: rcar-vin: fix height for TOP and BOTTOM fields

[Sergei Shtylyov]

On 08/02/2016 05:51 PM, Niklas Söderlund wrote:


The height used for V4L2_FIELD_TOP and V4L2_FIELD_BOTTOM where wrong.
The frames only contain one filed so the height should be half of the


   s/filed/field/.


frame.

Signed-off-by: Niklas Söderlund 

[...]

MBR, Sergei

--
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: [PATCHv2 1/7] media: rcar-vin: make V4L2_FIELD_INTERLACED standard dependent

[Sergei Shtylyov]

On 08/02/2016 05:51 PM, Niklas Söderlund wrote:


The field V4L2_FIELD_INTERLACED is standard dependent and should not
unconditionally be equivalent to V4L2_FIELD_INTERLACED_TB.

This patch adds a check to see if the video standard can be obtained and
if it's a 60 Hz format. If the condition is meet V4L2_FIELD_INTERLACED


   s/meet/met/.


is treated as V4L2_FIELD_INTERLACED_BT if not as
V4L2_FIELD_INTERLACED_TB.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 496aa97..4063775 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -131,6 +131,7 @@ static u32 rvin_read(struct rvin_dev *vin, u32 offset)
 static int rvin_setup(struct rvin_dev *vin)
 {
u32 vnmc, dmr, dmr2, interrupts;
+   v4l2_std_id std;
bool progressive = false, output_is_yuv = false, input_is_yuv = false;

switch (vin->format.field) {
@@ -141,6 +142,13 @@ static int rvin_setup(struct rvin_dev *vin)
vnmc = VNMC_IM_EVEN;
break;
case V4L2_FIELD_INTERLACED:
+   /* Default to TB */
+   vnmc = VNMC_IM_FULL;
+   /* Use BT if video standard can be read and is 60 Hz format */
+   if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, ))
+   if (std & V4L2_STD_525_60)
+   vnmc = VNMC_IM_FULL | VNMC_FOC;


   I think you either need to fold 2 *if* statements, or add {} in the 1st one.

[...]

MBR, Sergei

--
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: [PATCHv2 5/7] media: rcar-vin: add support for V4L2_FIELD_ALTERNATE

[Sergei Shtylyov]

Hello.

On 08/02/2016 05:51 PM, Niklas Söderlund wrote:


The HW can capture both ODD and EVEN fields in separate buffers so it's
possible to support V4L2_FIELD_ALTERNATE. This patch add support for
this mode.

At probe time and when S_STD is called the driver will default to use
V4L2_FIELD_INTERLACED if the subdevice reports V4L2_FIELD_ALTERNATE. The
driver will only change the field type if the subdevice implements
G_STD, if not it will keep the default at V4L2_FIELD_ALTERNATE.

The user can always explicitly ask for V4L2_FIELD_ALTERNATE in S_FTM and


   S_FMT?


the driver will use that field format.

Signed-off-by: Niklas Söderlund 

[...]

MBR, Sergei

--
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_vin: add support for V4L2_FIELD_ALTERNATE

[Sergei Shtylyov]

The hardware  can capture both odd and even fields in  the separate buffers,
so  it's possible to support  this field mode. However, if the subdevice
presents data  in this mode,  we prefer to use the hardware deinterlacing...

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.
This patch needs to be merged before the following ADV7180 driver patch is
merged: http://www.mail-archive.com/linux-media@vger.kernel.org/msg100410.html

 drivers/media/platform/soc_camera/rcar_vin.c |2 ++
 1 file changed, 2 insertions(+)

Index: media_tree/drivers/media/platform/soc_camera/rcar_vin.c
===
--- media_tree.orig/drivers/media/platform/soc_camera/rcar_vin.c
+++ media_tree/drivers/media/platform/soc_camera/rcar_vin.c
@@ -585,6 +585,7 @@ static int rcar_vin_setup(struct rcar_vi
vnmc = VNMC_IM_FULL | VNMC_FOC;
break;
case V4L2_FIELD_NONE:
+   case V4L2_FIELD_ALTERNATE:
if (is_continuous_transfer(priv)) {
vnmc = VNMC_IM_ODD_EVEN;
progressive = true;
@@ -1595,6 +1596,7 @@ static int rcar_vin_set_fmt(struct soc_c
case V4L2_FIELD_INTERLACED_BT:
field = pix->field;
break;
+   case V4L2_FIELD_ALTERNATE:
case V4L2_FIELD_INTERLACED:
/* Query for standard if not explicitly mentioned _TB/_BT */
ret = v4l2_subdev_call(sd, video, querystd, );

--
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 4/6] media: rcar-vin: add support for V4L2_FIELD_ALTERNATE

[Sergei Shtylyov]

Hello.

On 07/29/2016 08:40 PM, Niklas Söderlund wrote:


The HW can capture both ODD and EVEN fields in separate buffers so it's
possible to support this field mode.

Signed-off-by: Niklas Söderlund 

   It's probably worth adding that if the subdevice presents the video data 
in this mode, we prefer to use the hardware de-interlacing.


MBR, Sergei

PS: I think I have a patch adding support for this mode to the old driver, so 
that it doesn't get borked with the patch #6 in this series.


--
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/6] media: rcar-vin: allow field to be changed

[Sergei Shtylyov]

On 07/29/2016 08:40 PM, Niklas Söderlund wrote:


The driver forced whatever field was set by the source subdevice to be
used. This patch allows the user to change from the default field.

Signed-off-by: Niklas Söderlund 


   I didn't apply this patch at first (thinking it was unnecessary), and the 
capture worked fine. The field order appeared swapped again after I did import 
this patch as well. :-(


MBR, Sergei

--
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 6/6] media: adv7180: fix field type

[Sergei Shtylyov]

On 07/29/2016 08:40 PM, Niklas Söderlund wrote:


From: Steve Longerbeam <slongerb...@gmail.com>

The ADV7180 and ADV7182 transmit whole fields, bottom field followed
by top (or vice-versa, depending on detected video standard). So
for chips that do not have support for explicitly setting the field
mode, set the field mode to V4L2_FIELD_ALTERNATE.

Signed-off-by: Steve Longerbeam <steve_longerb...@mentor.com>
[Niklas: changed filed type from V4L2_FIELD_SEQ_{TB,BT} to
V4L2_FIELD_ALTERNATE]
Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>


Tested-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

   IIUC, it's a 4th version of this patch; you should have kept the original 
change log (below --- tearline) and indicated that in the subject.


MBR, Sergei

--
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] rcar-vin: add R-Car gen2 fallback compatibility string

[Sergei Shtylyov]

On 7/26/2016 9:05 AM, Niklas Söderlund wrote:


Such fallback string is present in the 'soc_camera' version of the R-Car VIN
driver, so need  to add it here as well...

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>


Acked-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>


   Thanks and sorry for forgetting to CC you.

MBR, Sergei

--
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-vin: add R-Car gen2 fallback compatibility string

[Sergei Shtylyov]

Such fallback string is present in the 'soc_camera' version of the R-Car VIN
driver, so need  to add it here as well...

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'media_tree.git' repo's 'master' branch.
This patch conflicts with Niklas Soderlund's former patch "[media] rcar-vin:
add  Gen2 and Gen3 fallback compatibility strings"), I got his consent about
splitting the gen2 part  of that patch to a separate patch...

 drivers/media/platform/rcar-vin/rcar-core.c |1 +
 1 file changed, 1 insertion(+)

Index: media_tree/drivers/media/platform/rcar-vin/rcar-core.c
===
--- media_tree.orig/drivers/media/platform/rcar-vin/rcar-core.c
+++ media_tree/drivers/media/platform/rcar-vin/rcar-core.c
@@ -209,6 +209,7 @@ static const struct of_device_id rvin_of
{ .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-gen2-vin", .data = (void *)RCAR_GEN2 },
{ },
 };
 MODULE_DEVICE_TABLE(of, rvin_of_id_table);

--
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 v6 1/4] media: adv7604: automatic "default-input" selection

[Sergei Shtylyov]

On 07/22/2016 12:09 PM, Ulrich Hecht wrote:


Fall back to input 0 if "default-input" property is not present.

Additionally, documentation in commit bf9c82278c34 ("[media]
media: adv7604: ability to read default input port from DT") states
that the "default-input" property should reside directly in the node
for adv7612. Hence, also adjust the parsing to make the implementation
consistent with this.

Based on patch by William Towle .

Signed-off-by: Ulrich Hecht 
---
 drivers/media/i2c/adv7604.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 4003831..055c9df 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -3077,10 +3077,13 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
if (!of_property_read_u32(endpoint, "default-input", ))
state->pdata.default_input = v;
else
-   state->pdata.default_input = -1;
+   state->pdata.default_input = 0;

of_node_put(endpoint);

+   if (!of_property_read_u32(np, "default-input", ))
+   state->pdata.default_input = v;


of_property_read_u32(np, "default-input",
 >pdata.default_input));

should be equivalent...

MBR, Sergei

--
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: [PATCHv2 04/16] [media] rcar-vin: return correct error from platform_get_irq

[Sergei Shtylyov]

Hello.

On 07/19/2016 05:20 PM, Niklas Söderlund wrote:


Fix a error from the original driver where the wrong error code is
returned if the driver fails to get a IRQ number from
platform_get_irq().

Signed-off-by: Niklas Söderlund 
---
 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 481d82a..ff27d75 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -318,7 +318,7 @@ static int rcar_vin_probe(struct platform_device *pdev)

irq = platform_get_irq(pdev, 0);
if (irq <= 0)
-   return ret;
+   return irq;


   This is still wrong, i.e. it'll return 0 from the probe() method if 'irq' 
is 0 (and you consider that an error).


[...]

MBR, Sergei

--
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 8/8] [media] rcar-vin: add Gen2 and Gen3 fallback compatibility strings

[Sergei Shtylyov]

Hello.

On 05/27/2016 02:36 PM, Niklas Söderlund wrote:


From: Niklas Söderlund 

These are present in the soc-camera version of this driver and it's time
to add them to this driver as well.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 520690c..87041db 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -33,6 +33,8 @@ static const struct of_device_id rvin_of_id_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 },


   What's the point of adding the H3 specific compatibility string in the
previous patch then? The fallback stings were added not have to updated the
driver for every new SoC exactly.


Since this driver aims to replace the previous R-Car VIN driver which
uses soc-camera I think it also should contain all the compatibility
strings that the soc-camera driver do.


   Indeed. And I'm not seeing the gen2/3 strings there yet (I thought Simon 
had already pushed them there). Nevermind then.


MBR, Sergei

--
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 8/8] [media] rcar-vin: add Gen2 and Gen3 fallback compatibility strings

[Sergei Shtylyov]

On 05/25/2016 10:10 PM, Niklas Söderlund wrote:


From: Niklas Söderlund 

These are present in the soc-camera version of this driver and it's time
to add them to this driver as well.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 520690c..87041db 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -33,6 +33,8 @@ static const struct of_device_id rvin_of_id_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 },


   What's the point of adding the H3 specific compatibility string in the 
previous patch then? The fallback stings were added not have to updated the 
driver for every new SoC exactly.


MBR, Sergei

--
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 08/13] v4l: vsp1: Make vsp1_entity_get_pad_compose() more generic

[Sergei Shtylyov]

Hello.

On 04/26/2016 12:36 AM, Laurent Pinchart wrote:


Turn the helper into a function that can retrieve crop and compose
selection rectangles.

Signed-off-by: Laurent Pinchart 
---
  drivers/media/platform/vsp1/vsp1_entity.c | 24 
  drivers/media/platform/vsp1/vsp1_entity.h |  6 +++---
  drivers/media/platform/vsp1/vsp1_rpf.c|  7 ---
  3 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_entity.c 
b/drivers/media/platform/vsp1/vsp1_entity.c
index f60d7926d53f..8c49a74381a1 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.c
+++ b/drivers/media/platform/vsp1/vsp1_entity.c
@@ -87,12 +87,28 @@ vsp1_entity_get_pad_format(struct vsp1_entity *entity,
return v4l2_subdev_get_try_format(>subdev, cfg, pad);
  }

+/**
+ * vsp1_entity_get_pad_selection - Get a pad selection from storage for entity
+ * @entity: the entity
+ * @cfg: the configuration storage
+ * @pad: the pad number
+ * @target: the selection target
+ *
+ * Return the selection rectangle stored in the given configuration for an
+ * entity's pad. The configuration can be an ACTIVE or TRY configuration. The
+ * selection target can be COMPOSE or CROP.
+ */
  struct v4l2_rect *
-vsp1_entity_get_pad_compose(struct vsp1_entity *entity,
-   struct v4l2_subdev_pad_config *cfg,
-   unsigned int pad)
+vsp1_entity_get_pad_selection(struct vsp1_entity *entity,
+ struct v4l2_subdev_pad_config *cfg,
+ unsigned int pad, unsigned int target)
  {
-   return v4l2_subdev_get_try_compose(>subdev, cfg, pad);
+   if (target == V4L2_SEL_TGT_COMPOSE)
+   return v4l2_subdev_get_try_compose(>subdev, cfg, pad);
+   else if (target == V4L2_SEL_TGT_CROP)
+   return v4l2_subdev_get_try_crop(>subdev, cfg, pad);
+   else
+   return NULL;


   How about *switch* instead?

[...]

MBR, Sergei

--
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 8/9] ARM: shmobile: lager dts: Add entries for VIN HDMI input support

[Sergei Shtylyov]

The new way of writing the subject prefix is "ARM: dts: lager: ..."

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

[Sergei Shtylyov]

Hello.

On 3/2/2016 4:14 AM, 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.

Acked-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
Based on media-tree/master

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.


* Added Geert Uytterhoeven's Ack

[...]

MBR, Sergei

--
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] coccinelle: api: check for propagation of error from platform_get_irq

[Sergei Shtylyov]

On 12/27/2015 9:13 AM, Julia Lawall wrote:


Well, looking again, the patch should be good. I just thought its goal was
to fix the code as well...


I could do that for the irq < 0 case, but I think that in that case, kbuild
will only run the patch version, and the <= cases will not be reported on.
I don't have a general fix for the <= 0.  Is it even correct to have < in
some cases and <= in others?


   That's a good question...
   In my prior fixes of this case I preferred to consider IRQ0 valid and so 
used 'irq < 0'. I myself don't share the "IRQ0 is invalid" sentiment...



julia


MBR, Sergei

--
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] coccinelle: api: check for propagation of error from platform_get_irq

[Sergei Shtylyov]

On 12/27/2015 01:32 AM, Julia Lawall wrote:


The error return value of platform_get_irq seems to often get dropped.

Signed-off-by: Julia Lawall 

---

v2: Check for the direct return case also.  Added some mailing lists of
common offenders.

diff --git a/scripts/coccinelle/api/platform_get_irq_return.cocci
b/scripts/coccinelle/api/platform_get_irq_return.cocci
new file mode 100644
index 000..44680d0
--- /dev/null
+++ b/scripts/coccinelle/api/platform_get_irq_return.cocci
@@ -0,0 +1,58 @@
+/// Propagate the return value of platform_get_irq.
+//# Sometimes the return value of platform_get_irq is tested using <= 0,
but 0
+//# might not be an appropriate return value in an error case.
+///
+// Confidence: Moderate
+// Copyright: (C) 2015 Julia Lawall, Inria. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Options: --no-includes --include-headers
+
+virtual context
+virtual org
+virtual report
+
+//

+
+@r depends on context || org || report@
+constant C;
+statement S;
+expression e, ret;
+position j0, j1;
+@@
+
+* e@j0 = platform_get_irq(...);
+(
+if@j1 (...) {
+  ...
+  return -C;
+} else S
+|
+if@j1 (...) {
+  ...
+  ret = -C;
+  ...
+  return ret;
+} else S


Well, this seems to also cover the (e <= 0) checks which do make same sense
in the light of Linus considering IRQ0 invalid. So I'd be more specific about
the checks here -- 0 should indeed be overridden with something if it's
considered invalid.


That's what the limitations section says (lines with #).  This doesn't


   Ah, failed to notice those, only saw after replying.


make any changes, it only makes warnings, which should include the
limitations information, so perhaps people can consider what it is that
they really intend to do.

>

If you think this is not a good idea, then I can make the test more
specific.


   Well, looking again, the patch should be good. I just thought its goal was 
to fix the code as well...



julia


MBR, Sergei

--
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] coccinelle: api: check for propagation of error from platform_get_irq

[Sergei Shtylyov]

On 12/26/2015 11:58 PM, Julia Lawall wrote:


The error return value of platform_get_irq seems to often get dropped.

Signed-off-by: Julia Lawall 

---

v2: Check for the direct return case also.  Added some mailing lists of
common offenders.

diff --git a/scripts/coccinelle/api/platform_get_irq_return.cocci 
b/scripts/coccinelle/api/platform_get_irq_return.cocci
new file mode 100644
index 000..44680d0
--- /dev/null
+++ b/scripts/coccinelle/api/platform_get_irq_return.cocci
@@ -0,0 +1,58 @@
+/// Propagate the return value of platform_get_irq.
+//# Sometimes the return value of platform_get_irq is tested using <= 0, but 0
+//# might not be an appropriate return value in an error case.
+///
+// Confidence: Moderate
+// Copyright: (C) 2015 Julia Lawall, Inria. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Options: --no-includes --include-headers
+
+virtual context
+virtual org
+virtual report
+
+// 
+
+@r depends on context || org || report@
+constant C;
+statement S;
+expression e, ret;
+position j0, j1;
+@@
+
+* e@j0 = platform_get_irq(...);
+(
+if@j1 (...) {
+  ...
+  return -C;
+} else S
+|
+if@j1 (...) {
+  ...
+  ret = -C;
+  ...
+  return ret;
+} else S


   Well, this seems to also cover the (e <= 0) checks which do make same 
sense in the light of Linus considering IRQ0 invalid. So I'd be more specific 
about the checks here -- 0 should indeed be overridden with something if it's 
considered invalid.


MBR, Sergei

--
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] adv7604: add direct interrupt handling

[Sergei Shtylyov]

Hello.

On 12/22/2015 05:21 PM, Ulrich Hecht wrote:


When probed from device tree, the i2c client driver can handle the
interrupt on its own.

Signed-off-by: Ulrich Hecht 
Reviewed-by: Laurent Pinchart 
---
This revision implements the suggested style changes and drops the
IRQF_TRIGGER_LOW flag, which is handled in the device tree.

CU
Uli


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

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 5bd81bd..be5980c 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -1971,6 +1972,16 @@ static int adv76xx_isr(struct v4l2_subdev *sd, u32 
status, bool *handled)
return 0;
  }

+static irqreturn_t adv76xx_irq_handler(int irq, void *devid)
+{
+   struct adv76xx_state *state = devid;
+   bool handled;
+
+   adv76xx_isr(>sd, 0, );
+
+   return handled ? IRQ_HANDLED : IRQ_NONE;


   Just IRQ_RETVAL(handled), maybe?

[...]

MBR, Sergei

--
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 R-Car Gen3 support

[Sergei Shtylyov]

On 12/13/2015 06:27 PM, Yoshihiro Kaneko wrote:


From: Yoshihiko Mori 

Add chip identification for R-Car Gen3.

Signed-off-by: Yoshihiko Mori 
Signed-off-by: Yoshihiro Kaneko 

[...]

diff --git a/drivers/media/platform/soc_camera/rcar_vin.c 
b/drivers/media/platform/soc_camera/rcar_vin.c
index 5d90f39..29e7ca4 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -143,6 +143,7 @@
  #define RCAR_VIN_BT656(1 << 3)

  enum chip_id {
+   RCAR_GEN3,
RCAR_GEN2,
RCAR_H1,
RCAR_M1,
@@ -1846,6 +1847,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {

  #ifdef CONFIG_OF
  static const struct of_device_id rcar_vin_of_table[] = {
+   { .compatible = "renesas,vin-r8a7795", .data = (void *)RCAR_GEN3 },


   I don't see where this is checked in the driver. Shouldn't we just use gen2?

MBR, Sergei

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