[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqLMS2y5ZR4SH6TVwnaTDhnGwk2_C_81DTz9J=ypDdBd4w@mail.gmail.com>
Date: Mon, 5 Aug 2019 16:19:10 -0600
From: Rob Herring <robh+dt@...nel.org>
To: Neil Armstrong <narmstrong@...libre.com>
Cc: devicetree@...r.kernel.org,
dri-devel <dri-devel@...ts.freedesktop.org>,
linux-amlogic@...ts.infradead.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] dt-bindings: display: amlogic,meson-vpu: convert to yaml
On Mon, Aug 5, 2019 at 7:43 AM Neil Armstrong <narmstrong@...libre.com> wrote:
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for the Amlogic Display Controller over to YAML schemas.
>
> The original example has a leftover "dmc" memory cell, that has been
> removed in the yaml rewrite.
>
> Signed-off-by: Neil Armstrong <narmstrong@...libre.com>
> ---
> .../bindings/display/amlogic,meson-vpu.txt | 121 --------------
> .../bindings/display/amlogic,meson-vpu.yaml | 153 ++++++++++++++++++
> 2 files changed, 153 insertions(+), 121 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
> create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
> diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
> new file mode 100644
> index 000000000000..9eba13031998
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
> @@ -0,0 +1,153 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 BayLibre, SAS
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Amlogic Meson Display Controller
> +
> +maintainers:
> + - Neil Armstrong <narmstrong@...libre.com>
> +
> +description: |
> + The Amlogic Meson Display controller is composed of several components
> + that are going to be documented below
> +
> + DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
> + | vd1 _______ _____________ _________________ | |
> + D |-------| |----| | | | | HDMI PLL |
> + D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK |
> + R |-------| |----| Processing | | | | |
> + | osd2 | | | |---| Enci ----------|----|-----VDAC------|
> + R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----|
> + A | osd1 | | | Blenders | | Encl ----------|----|---------------|
> + M |-------|______|----|____________| |________________| | |
> + ___|__________________________________________________________|_______________|
> +
> +
> + VIU: Video Input Unit
> + ---------------------
> +
> + The Video Input Unit is in charge of the pixel scanout from the DDR memory.
> + It fetches the frames addresses, stride and parameters from the "Canvas" memory.
> + This part is also in charge of the CSC (Colorspace Conversion).
> + It can handle 2 OSD Planes and 2 Video Planes.
> +
> + VPP: Video Post Processing
> + --------------------------
> +
> + The Video Post Processing is in charge of the scaling and blending of the
> + various planes into a single pixel stream.
> + There is a special "pre-blending" used by the video planes with a dedicated
> + scaler and a "post-blending" to merge with the OSD Planes.
> + The OSD planes also have a dedicated scaler for one of the OSD.
> +
> + VENC: Video Encoders
> + --------------------
> +
> + The VENC is composed of the multiple pixel encoders
> + - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
> + - ENCP : Progressive Video Encoder for HDMI
> + - ENCL : LCD LVDS Encoder
> + The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
> + tree and provides the scanout clock to the VPP and VIU.
> + The ENCI is connected to a single VDAC for Composite Output.
> + The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
> +
> + The following table lists for each supported model the port number
> + corresponding to each VPU output.
> +
> + Port 0 Port 1
> + -----------------------------------------
> + S905 (GXBB) CVBS VDAC HDMI-TX
> + S905X (GXL) CVBS VDAC HDMI-TX
> + S905D (GXL) CVBS VDAC HDMI-TX
> + S912 (GXM) CVBS VDAC HDMI-TX
> + S905X2 (G12A) CVBS VDAC HDMI-TX
> + S905Y2 (G12A) CVBS VDAC HDMI-TX
> + S905D2 (G12A) CVBS VDAC HDMI-TX
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - amlogic,meson-gxbb-vpu # GXBB (S905)
> + - amlogic,meson-gxl-vpu # GXL (S905X, S905D)
> + - amlogic,meson-gxm-vpu # GXM (S912)
> + - const: amlogic,meson-gx-vpu
> + - enum:
> + - amlogic,meson-g12a-vpu # G12A (S905X2, S905Y2, S905D2)
> +
> + reg:
> + maxItems: 2
> +
> + reg-names:
> + items:
> + - const: vpu
> + - const: hhi
> +
> + interrupts:
> + maxItems: 1
> +
> + power-domains:
> + description: phandle to the associated power domain
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/phandle
Common properties don't need a type definition. As this can be an
array, you just need 'maxItems: 1'.
Same comments on patch 1 apply here too.
Rob
Powered by blists - more mailing lists