Received: by 10.192.165.148 with SMTP id m20csp384527imm; Fri, 20 Apr 2018 00:25:28 -0700 (PDT) X-Google-Smtp-Source: AIpwx48JrZd0sq3k791fAuMV8uJC6ZyZeVmQi6e8wPGdr1qj0v794Pr6ITGZYf4ujO8yWo9qiIsV X-Received: by 10.98.228.13 with SMTP id r13mr8667671pfh.51.1524209128193; Fri, 20 Apr 2018 00:25:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524209128; cv=none; d=google.com; s=arc-20160816; b=g7jHheQx/H2HZ2HGtKoIpqdx2LP+2LIWjD+kTkb8O6g4HbGxuOUIiDrqZ/rltamJ7Q pk0YMICRIi3OJV4hIaWrXFWEzCltGjHWylaowEHf97+U3Alj9x/ORMLIAC7mTUqrGHYS 9sXOt4i0GzEL7/Q0Eu6SeL5OCpM+z3YYyC2dW8xYV7tYFzNYFg4nxfGxZQRQIJ+83zea V8/tfIYfjUndK+XM5o54s8uMGMLEwq5AxxvVbsX+HtrcpsJlAkNhj65i6rsB6++Uvryn Xg0ywRADDhVbX7GhKydZplLsBTBONl5HX6bT7BbwVfl7LgkaM5mM1/Z/iFXT16GacVrk wgVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:organization:references :in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=MA05Oo3kpqgRKuTSpjh4evgCdv3icjOCiXiN+FKIcyw=; b=Ba7cShg3pC28twAMqbdrUwwJyBhz5IGle0yS5sAJaRp7lv2VPAo+a42FRkevSAUy7u 4RCFRcbEqBc7BG6FYgksRNcyiBYZ/bXUoEA3NmlD3XHjQ0xDh55Xa5bqbdR+1xtAcaeo izRdfTxXq017+TZvlE9s/TRGy7CYFqEMBOmki8SLOJL3woORQiPxN2g84gEj97Gagucl e2NuS5QfUhpHcH9ljaQi0kxpSW1qD4fKyhky5upxON9rK4z8hIMOCOFj2dXrjF0QIObf nyMWIxbwnsPn4N7KZISMaRI0MZO+r3a1bItZVFVE/gPePsOum1OqD06Wfs1UTEmxinar Anzw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z24si1136373pge.161.2018.04.20.00.25.13; Fri, 20 Apr 2018 00:25:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754064AbeDTHXs (ORCPT + 99 others); Fri, 20 Apr 2018 03:23:48 -0400 Received: from mail.bootlin.com ([62.4.15.54]:54932 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753539AbeDTHXq (ORCPT ); Fri, 20 Apr 2018 03:23:46 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 4AD05207D2; Fri, 20 Apr 2018 09:23:44 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from aptenodytes (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.bootlin.com (Postfix) with ESMTPSA id CBD4C207B7; Fri, 20 Apr 2018 09:23:33 +0200 (CEST) Message-ID: <5fa80b1e88ad2a215f51ea3a2b9b62274fa9b1ec.camel@bootlin.com> Subject: Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver From: Paul Kocialkowski To: Tomasz Figa , Philipp Zabel Cc: Linux Media Mailing List , devicetree@vger.kernel.org, "list@263.net:IOMMU DRIVERS , Joerg " "Roedel ," , Linux Kernel Mailing List , linux-sunxi@googlegroups.com, Mauro Carvalho Chehab , Rob Herring , Mark Rutland , Maxime Ripard , wens@csie.org, Pawel Osciak , Marek Szyprowski , Kyungmin Park , Hans Verkuil , Sakari Ailus , Arnd Bergmann , Alexandre Courbot Date: Fri, 20 Apr 2018 09:22:20 +0200 In-Reply-To: References: <20180419154124.17512-1-paul.kocialkowski@bootlin.com> <20180419154536.17846-4-paul.kocialkowski@bootlin.com> <1524153860.3416.9.camel@pengutronix.de> Organization: Bootlin Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-9FZvfMmIQIhuBv3NJwWK" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-9FZvfMmIQIhuBv3NJwWK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi and thanks for the review, On Fri, 2018-04-20 at 01:31 +0000, Tomasz Figa wrote: > Hi Paul, Philipp, >=20 > On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel > wrote: >=20 > > Hi Paul, > > On Thu, 2018-04-19 at 17:45 +0200, Paul Kocialkowski wrote: > > > This adds a device-tree binding document that specifies the > > > properties > > > used by the Sunxi-Cedurs VPU driver, as well as examples. > > >=20 > > > Signed-off-by: Paul Kocialkowski > > > --- > > > .../devicetree/bindings/media/sunxi-cedrus.txt | 50 >=20 > ++++++++++++++++++++++ > > > 1 file changed, 50 insertions(+) > > > create mode 100644 >=20 > Documentation/devicetree/bindings/media/sunxi-cedrus.txt > > >=20 > > > diff --git a/Documentation/devicetree/bindings/media/sunxi- > > > cedrus.txt >=20 > b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt > > > new file mode 100644 > > > index 000000000000..71ad3f9c3352 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/media/sunxi-cedrus.txt > > > @@ -0,0 +1,50 @@ > > > +Device-tree bindings for the VPU found in Allwinner SoCs, > > > referred to >=20 > as the > > > +Video Engine (VE) in Allwinner literature. > > > + > > > +The VPU can only access the first 256 MiB of DRAM, that are DMA- > > > mapped >=20 > starting > > > +from the DRAM base. This requires specific memory allocation and >=20 > handling. >=20 > And no IOMMU? Brings back memories. Exactly, no IOMMU so we don't have much choice but cope with that hardware limitation... > > > + > > > +Required properties: > > > +- compatible : "allwinner,sun4i-a10-video-engine"; > > > +- memory-region : DMA pool for buffers allocation; > > > +- clocks : list of clock specifiers, corresponding to >=20 > entries in > > > + the clock-names property; > > > +- clock-names : should contain "ahb", "mod" and > > > "ram" >=20 > entries; > > > +- assigned-clocks : list of clocks assigned to the VE; > > > +- assigned-clocks-rates : list of clock rates for the clocks > > > assigned >=20 > to the VE; > > > +- resets : phandle for reset; > > > +- interrupts : should contain VE interrupt number; > > > +- reg : should contain register base and > > > length >=20 > of VE. > > > + > > > +Example: > > > + > > > +reserved-memory { > > > + #address-cells =3D <1>; > > > + #size-cells =3D <1>; > > > + ranges; > > > + > > > + /* Address must be kept in the lower 256 MiBs of DRAM for > > > VE. */ > > > + ve_memory: cma@4a000000 { > > > + compatible =3D "shared-dma-pool"; > > > + reg =3D <0x4a000000 0x6000000>; > > > + no-map; > > > + linux,cma-default; > > > + }; > > > +}; > > > + > > > +video-engine@1c0e000 { > > This is not really required by any specification, and not as common > > as > > gpu@..., but could this reasonably be called "vpu@1c0e000" to follow > > somewhat-common practice? >=20 > AFAIR the name is supposed to be somewhat readable for someone that > doesn't know the hardware. To me, "video-engine" sounds more obvious > than "vpu", but we actually use "codec" already, in case of MFC and > JPEG codec on Exynos. If encode/decode is the only functionality of > this block, I'd personally go with "codec". If it can do other things, > e.g. scaling/rotation without encode/decode, I'd probably call it > "video-processor". I agree that the term VPU is more commonly associated with video decoding, while video engine could mean a number of things. The reason I went with "video-engine" here (while still presenting the driver as a VPU driver) is that Video Engine is the term used in Allwinner's litterature. Other nodes in Allwinner device-trees generally stick to these terms (for instance, we have "display-engine" nodes). This also makes it easier to find the matching parts in the documentation. Cheers, --=20 Paul Kocialkowski, Bootlin (formerly Free Electrons) Embedded Linux and kernel engineering https://bootlin.com --=-9FZvfMmIQIhuBv3NJwWK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEJZpWjZeIetVBefti3cLmz3+fv9EFAlrZlSwACgkQ3cLmz3+f v9Hy3ggAnk4HQUzPACB7k5/RwBMiSycikYulTkmhVcK+LnVj5b9Mq2z83uyPj0pp TdeyYi4zNHQYPrEFoK+s45leqrfJUaI4Nr24qJAVz5tia7zgFnKrW12KoPeOO2vI ijcAEy2dypRajYxjUxW3KqRwbomJcpTbNHAb0JQBP60FuWlq3hjfsaH/DRr66AzP gvCg/o2L9Cosd/mmWupmdwH92zWNMrS5r7f+XyouKaoxZuUm3QJXVttBtGxx/XXE hBtgj+2BFYgeN5shsXCO0kasjcJC3TkQyxhfd/BrrMxvbRDhOogeBJXGe/mlY1Xu JIjjIGANMCsARw9Uyeyh/Kc/ktwi5Q== =OpZH -----END PGP SIGNATURE----- --=-9FZvfMmIQIhuBv3NJwWK--