Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755376AbcDJPZ5 (ORCPT ); Sun, 10 Apr 2016 11:25:57 -0400 Received: from down.free-electrons.com ([37.187.137.238]:40471 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754291AbcDJPZz (ORCPT ); Sun, 10 Apr 2016 11:25:55 -0400 Date: Sun, 10 Apr 2016 02:02:11 -0700 From: Maxime Ripard To: Rob Herring Cc: Mike Turquette , Stephen Boyd , David Airlie , Thierry Reding , Chen-Yu Tsai , Daniel Vetter , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-sunxi@googlegroups.com, Laurent Pinchart , Hans de Goede , Alexander Kaplan , Boris Brezillon , Thomas Petazzoni , Rob Clark Subject: Re: [PATCH v3 13/19] drm: sun4i: Add DT bindings documentation Message-ID: <20160410090211.GU4227@lukather> References: <1458751122-23976-1-git-send-email-maxime.ripard@free-electrons.com> <1458751122-23976-14-git-send-email-maxime.ripard@free-electrons.com> <20160325141118.GA26927@rob-hp-laptop> <20160329103314.GL30977@lukather> <20160329185035.GA8445@rob-hp-laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NAmHCRPXNp23hR9r" Content-Disposition: inline In-Reply-To: <20160329185035.GA8445@rob-hp-laptop> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 9268 Lines: 234 --NAmHCRPXNp23hR9r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Rob, On Tue, Mar 29, 2016 at 01:50:35PM -0500, Rob Herring wrote: > On Tue, Mar 29, 2016 at 12:33:14PM +0200, Maxime Ripard wrote: > > Hi Rob, > >=20 > > On Fri, Mar 25, 2016 at 09:11:18AM -0500, Rob Herring wrote: > > > On Wed, Mar 23, 2016 at 05:38:36PM +0100, Maxime Ripard wrote: > > > > The display pipeline of the Allwinner A10 is involving several loos= ely > > > > coupled components. > > > >=20 > > > > Add a documentation for the bindings. > > > >=20 > > > > Signed-off-by: Maxime Ripard > > > > --- > > > > .../bindings/display/sunxi/sun4i-drm.txt | 254 +++++++++= ++++++++++++ > > > > 1 file changed, 254 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/display/sunxi= /sun4i-drm.txt > > > >=20 > > > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-= drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > > new file mode 100644 > > > > index 000000000000..378edb919eae > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > > @@ -0,0 +1,254 @@ > > > > +Allwinner A10 Display Pipeline > > > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > + > > > > +The Allwinner A10 Display pipeline is composed of several componen= ts > > > > +that are going to be documented below: > > > > + > > > > +TV Encoder > > > > +---------- > > > > + > > > > +The TV Encoder supports the composite and VGA output. It is one en= d of > > > > +the pipeline. > > > > + > > > > +Required properties: > > > > + - compatible: value should be "allwinner,sun4i-a10-tv-encoder". > > > > + - reg: base address and size of memory-mapped region > > > > + - clocks: the clocks driving the TV encoder > > > > + - resets: phandle to the reset controller driving the encoder > > > > + > > > > +- ports: A ports node with endpoint definitions as defined in > > > > + Documentation/devicetree/bindings/media/video-interfaces.txt. The > > > > + first port should be the input endpoint. > > > > + > > > > +TCON > > > > +---- > > > > + > > > > +The TCON acts as a timing controller for RGB, LVDS and TV interfac= es. > > > > + > > > > +Required properties: > > > > + - compatible: value should be "allwinner,sun5i-a13-tcon". > > > > + - reg: base address and size of memory-mapped region > > > > + - interrupts: interrupt associated to this IP > > > > + - clocks: phandles to the clocks feeding the TCON. Three are need= ed: > > > > + - 'ahb': the interface clocks > > > > + - 'tcon-ch0': The clock driving the TCON channel 0 > > > > + - 'tcon-ch1': The clock driving the TCON channel 1 > > > > + - resets: phandles to the reset controllers driving the encoder > > > > + - "lcd": the reset line for the TCON channel 0 > > > > + > > > > + - clock-names: the clock names mentioned above > > > > + - reset-names: the reset names mentioned above > > > > + - clock-output-names: Name of the pixel clock created > > > > + > > > > +- ports: A ports node with endpoint definitions as defined in > > > > + Documentation/devicetree/bindings/media/video-interfaces.txt. The > > > > + first port should be the input endpoint, the second one the outp= ut > > >=20 > > > The example shows 2 output endpoints. Your diagram shows up to 4=20 > > > outputs. The number should be how ever many could coexist in a given = h/w=20 > > > design. In other words, I'm assuming all 4 can't be used simultaneous= ly,=20 > > > but can all 4 be wired up in a h/w design and switched in s/w?=20 > > >=20 > > > Just be clear on the numbering. > >=20 > > Yes, each TCON has two channels, the first one being usable for > > RGB/LVDS, the second one for TV/VGA. HDMI is basically implemented > > using an in-SoC RGB-to-HDMI bridge, so it would use the first channel > > as well. >=20 > So I think you should have 2 ports (1 per channel) and then 2 endpoints= =20 > for 1st (RGB/LVDS/ExtBridge and HDMI) and 1 endpoint (TV/VGA) for 2nd=20 > port. Yes, that makes sense. > > I don't see how a particular design could use several devices on the > > first channel, because they would share the same timings, and I don't > > really see how it would work out. > >=20 > > > > + > > > > +Endpoints optional property: > > > > + - allwinner,panel: boolean to indicate that the endpoint is a pa= nel > > >=20 > > > This can be determined by the endpoint not being TV Encoder (or HDMI). > >=20 > > It wouldn't really scale if you start to consider the bridges > > too. Then, you would have to duplicate and maintain a list of all the > > bridges supported in Linux and a list of all the panels supported in > > Linux, and try to match that to see if it's a panel, a bridge or an > > element of our pipeline. >=20 > So my concern is that no one else has needed this, so why do you? Based= =20 > on the above, you know that a panel is always connected to port 0,=20 > endpoint 0. If it is an external bridge instead, then that can be=20 > determined when the bridge driver is bound. Indeed, I'll try to use the panel and bridge API to retrieve the panel and bridges drivers, and try to derive the information from that instead of this DT property. > > > > +Display Engine Backend > > > > +---------------------- > > > > + > > > > +The display engine backend exposes layers and sprites to the > > > > +system. > > > > + > > > > +Required properties: > > > > + - compatible: value must be one of: > > > > + * allwinner,sun5i-a13-display-backend > > > > + - reg: base address and size of the memory-mapped region. > > > > + - clocks: phandles to the clocks feeding the frontend and backend > > > > + * ahb: the backend interface clock > > > > + * mod: the backend module clock > > > > + * ram: the backend DRAM clock > > > > + - clock-names: the clock names mentioned above > > > > + - resets: phandles to the reset controllers driving the backend > > > > + > > > > +- ports: A ports node with endpoint definitions as defined in > > > > + Documentation/devicetree/bindings/media/video-interfaces.txt. The > > > > + first port should be the input endpoints, the second one the out= put > > > > + > > > > +Display Engine Frontend > > > > +----------------------- > > > > + > > > > +The display engine frontend does formats conversion, scaling, > > > > +deinterlacing and color space conversion. > > > > + > > > > +Required properties: > > > > + - compatible: value must be one of: > > > > + * allwinner,sun5i-a13-display-frontend > > > > + - reg: base address and size of the memory-mapped region. > > > > + - interrupts: interrupt associated to this IP > > > > + - clocks: phandles to the clocks feeding the frontend and backend > > > > + * ahb: the backend interface clock > > > > + * mod: the backend module clock > > > > + * ram: the backend DRAM clock > > > > + - clock-names: the clock names mentioned above > > > > + - resets: phandles to the reset controllers driving the backend > > > > + > > > > +Display Engine Pipeline > > > > +----------------------- > > > > + > > > > +The display engine pipeline (and its entry point, since it can be > > > > +either directly the backend or the frontend) is represented as an > > > > +extra node. > > > > + > > > > +Required properties: > > > > + - compatible: value must be one of: > > > > + * allwinner,sun5i-a13-display-engine > > > > + - allwinner,pipelines: list of phandle to the entry points of the > > > > + pipelines (either to the frontend or backend) > > >=20 > > > Seems like using FE or BE would be a function of your framebuffers'= =20 > > > formats and shouldn't be defined in DT. > >=20 > > Well, they are different IP blocks, so it should be defined in DT, > > shouldn't it? >=20 > They should, but allwinner,sun5i-a13-display-engine is not really an IP= =20 > block. Again, what decides if you use the FE or not? I'd say we would always want to use it, but we don't have support for it right now. You can use the backend directly, and this is what we're doing right now. Thanks! Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --NAmHCRPXNp23hR9r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXChaSAAoJEBx+YmzsjxAgxWcQAJwoXkap44vXu7d3qvI9EoO2 QQB3FHGqwk8SN0uPC83VLdmDz7HbY3NwKsq7w1QQUXrF3i7cL46Hl3hzR+jzy9Ng rAL3OvOCP0sV+WEVAR2leo4lCRx8X9xtJHK2Ma2DF+RZ4zSfjiBAFIOSLGnwu7jl Av9z+EhQSAk0W3bDOp6Bzjd7VxBu541nJgnkdCzbQ0Grj49nkvircQ3imrTO174O KZcoHStnu1L2EjpaietEFd2pR3YGgng8HnbIkte1JkdPz+TdY8tme73drnb2iUzE 9plAm6yfNhyZtsvVlZitoRucKZHP2lZvBb4XQtz2yGBRaSsLN/rlk4YUOYucpqrj piCBbYdZA5Ur2mtVbWOUjh3y2DriB5GNtIGehIKeCP6qEnnHnbK0SrS9ZbP62CBM /6Yu8Fb7tdZmVVOs7iv7X7ijgXhW3xAdpQHCl63TP0iKV1F0zNsZ/yOR6hxgeXaz o6xuHID602UL0rBP7TiSXXLDkvy4LkDuAzCmxqwNz6hmTH6swDIqzQ/l7rjNn5Bu DOrNDVxYNWPMNgwOHDm5uxI4wU9pQdFdl1Bouu/XLpg7k3uccsdxnwB1mXtN6eRm UW+CEsk6FxOjSujyiRR27uNGGZbDcxcDR3mHOly7VKIMUd6Bbzhb/MzpzSY0mlBs X80MbedGp5Fqs/e/PFS7 =OhQ8 -----END PGP SIGNATURE----- --NAmHCRPXNp23hR9r--