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,<soctype>-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 <soctype> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
