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 

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 

Signed-off-by: Sergei Shtylyov 


[...]


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)
+{
+   struct imr_ctx  *ctx = fh_to_ctx(priv);
+   struct vb2_queue   

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

[Hans Verkuil]

Any progress on this?

There where a bunch of comments, but I haven't seen anything since.

Regards,

Hans

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

[Kuninori Morimoto]

Hi Laurent

> > >> Laurent: what do you think about the need for SoC-specific compatible
> > >> values for the various IM* blocks?
> > > 
> > > There's no documented IP core version register, but when dumping all
> > > configuration registers on H3 and M3-W I noticed that register 0x002c, not
> > > documented in the datasheet, reads 0x14060514 on all four IMR instances in
> > > H3, and 0x20150505 on both instances in M3-W.
> > > 
> > > This looks like a version register to me. If my assumption is correct, we
> > > could do without any SoC-specific compatible string.
> > 
> > I read this assumed version registers on all R-Car SoCs, after writing
> > zero to 0xe6150990 (SMSTPCR8).
> > 
> > IMR-X2 on R-Car H2: 0x12072009
> > IMR-LSX2 on R-Car H2:   0x12072009
> > IMR-LSX3 on R-Car V2H:  0x13052617
> > IMR-LX2 on R-Car M2-W:  0x12072009
> > IMR-LX2 on R-Car M2-N:  0x12072009
> > IMR-LX2 on R-Car E2:0x13091909
> > IMR-LX3 on R-Car V2H:   0x13052617
> > 
> > Note that several IDs are the same, but you know the type from the
> > compatible value.
> > 
> > It would be good to get confirmation from the hardware team that this is
> > indeed a version register.
> 
> Thank you for checking.
> 
> Morimoto-san, do you think there are still people alive in the Gen2 hardware 
> team who could provide the information ? :-) If not, information restricted 
> to 
> Gen3 would still be useful.

Hmm.. I will try to ask to HW team.
My assumption is "No answer for no documented register".
Thus, we have 5% chance (?)
Please wait

Best regards
---
Kuninori Morimoto

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

[Laurent Pinchart]

Hi Geert,

On Wednesday 03 May 2017 09:22:00 Geert Uytterhoeven wrote:
> On Tue, May 2, 2017 at 11:17 PM, Laurent Pinchart wrote:
> > On Wednesday 22 Mar 2017 10:34:16 Geert Uytterhoeven wrote:
> >> On Thu, Mar 9, 2017 at 9:08 PM, Sergei Shtylyov wrote:
> >>> --- /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.
> >> 
> >> Laurent: what do you think about the need for SoC-specific compatible
> >> values for the various IM* blocks?
> > 
> > There's no documented IP core version register, but when dumping all
> > configuration registers on H3 and M3-W I noticed that register 0x002c, not
> > documented in the datasheet, reads 0x14060514 on all four IMR instances in
> > H3, and 0x20150505 on both instances in M3-W.
> > 
> > This looks like a version register to me. If my assumption is correct, we
> > could do without any SoC-specific compatible string.
> 
> I read this assumed version registers on all R-Car SoCs, after writing
> zero to 0xe6150990 (SMSTPCR8).
> 
> IMR-X2 on R-Car H2: 0x12072009
> IMR-LSX2 on R-Car H2:   0x12072009
> IMR-LSX3 on R-Car V2H:  0x13052617
> IMR-LX2 on R-Car M2-W:  0x12072009
> IMR-LX2 on R-Car M2-N:  0x12072009
> IMR-LX2 on R-Car E2:0x13091909
> IMR-LX3 on R-Car V2H:   0x13052617
> 
> Note that several IDs are the same, but you know the type from the
> compatible value.
> 
> It would be good to get confirmation from the hardware team that this is
> indeed a version register.

Thank you for checking.

Morimoto-san, do you think there are still people alive in the Gen2 hardware 
team who could provide the information ? :-) If not, information restricted to 
Gen3 would still be useful.

-- 
Regards,

Laurent Pinchart

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

[Geert Uytterhoeven]

Hi Laurent,

On Tue, May 2, 2017 at 11:17 PM, Laurent Pinchart
 wrote:
> On Wednesday 22 Mar 2017 10:34:16 Geert Uytterhoeven wrote:
>> On Thu, Mar 9, 2017 at 9:08 PM, Sergei Shtylyov wrote:
>> > --- /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.
>>
>> Laurent: what do you think about the need for SoC-specific compatible
>> values for the various IM* blocks?
>
> There's no documented IP core version register, but when dumping all
> configuration registers on H3 and M3-W I noticed that register 0x002c, not
> documented in the datasheet, reads 0x14060514 on all four IMR instances in H3,
> and 0x20150505 on both instances in M3-W.
>
> This looks like a version register to me. If my assumption is correct, we
> could do without any SoC-specific compatible string.

I read this assumed version registers on all R-Car SoCs, after writing
zero to 0xe6150990 (SMSTPCR8).

IMR-X2 on R-Car H2: 0x12072009
IMR-LSX2 on R-Car H2:   0x12072009
IMR-LSX3 on R-Car V2H:  0x13052617
IMR-LX2 on R-Car M2-W:  0x12072009
IMR-LX2 on R-Car M2-N:  0x12072009
IMR-LX2 on R-Car E2:0x13091909
IMR-LX3 on R-Car V2H:   0x13052617

Note that several IDs are the same, but you know the type from the
compatible value.

It would be good to get confirmation from the hardware team that this is
indeed a version register.

Gr{oetje,eeting}s,

Geert

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

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

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

[Laurent Pinchart]

Hi Geert,

On Wednesday 22 Mar 2017 10:34:16 Geert Uytterhoeven wrote:
> On Thu, Mar 9, 2017 at 9:08 PM, Sergei Shtylyov wrote:
> > --- /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.
> 
> Laurent: what do you think about the need for SoC-specific compatible
> values for the various IM* blocks?

There's no documented IP core version register, but when dumping all 
configuration registers on H3 and M3-W I noticed that register 0x002c, not 
documented in the datasheet, reads 0x14060514 on all four IMR instances in H3, 
and 0x20150505 on both instances in M3-W.

This looks like a version register to me. If my assumption is correct, we 
could do without any SoC-specific compatible string.

-- 
Regards,

Laurent Pinchart

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

[Geert Uytterhoeven]

On Thu, Mar 9, 2017 at 9:08 PM, Sergei Shtylyov
 wrote:
> --- /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.

Laurent: what do you think about the need for SoC-specific compatible
values for the various IM* blocks?

Gr{oetje,eeting}s,

Geert

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

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

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

[Hans Verkuil]

Hi Sergei,

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

On 03/09/17 21:08, Sergei Shtylyov 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, 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 
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> 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 
>  

[PATCH v5] media: platform: Renesas IMR driver

[Sergei Shtylyov]

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

Signed-off-by: Sergei Shtylyov 

---
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.txt
@@ -0,0 +1,27 @@
+Renesas R-Car Image Renderer (Distortion Correction Engine)