From: Rob Herring <robh+dt@kernel.org>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org,
Maxime Jourdan <mjourdan@baylibre.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Hans de Goede <hdegoede@redhat.com>, Chen-Yu Tsai <wens@csie.org>,
Frank Rowand <frowand.list@gmail.com>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] dt-bindings: Add schemas for simple-framebuffer
Date: Mon, 25 Mar 2019 11:27:36 -0500 [thread overview]
Message-ID: <CAL_JsqKep7B6LKUMRRxonKV48YEHtYow9TjKJwDUVN0S2BX3Ww@mail.gmail.com> (raw)
In-Reply-To: <20190325135414.9728-1-maxime.ripard@bootlin.com>
On Mon, Mar 25, 2019 at 8:54 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> The simple framebuffer is a binding that allows the bootloader to setup a
> framebuffer, describe it in the Device Tree for the OS to pick it up and
> use it as is.
>
> Replace the current binding by a schema to allow the validation tools to
> check those nodes.
>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Maxime Jourdan <mjourdan@baylibre.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> ---
>
> Rob,
>
> Even though the node itself is properly described, I still end up with some
> validation warnings when the chosen node is validated (basically
> complaining that ranges, and the framebuffer nodes shouldn't be here, since
> we haven't described them in the chosen schemas).
Having 'ranges' is a bit strange because 'chosen' doesn't have an
address. We can add #address-cells, #size-cells and framebuffer child
node to the base chosen schema.
> I've tried to expand it, but I failed, using that patch:
> http://code.bulix.org/mimu5z-634661?raw
That should work, but you will still get warnings from the core
schema. Also, I guess you really want to match on the child compatible
which isn't possible with the current tools. I think for now at least,
we don't need to validate that simple-fb is a child of chosen.
Maybe we could add a '$parent' property which the tools add like
$nodename. I'd rather wait and see how frequently we need something
like this.
> I'm a bit lost right now about how to make those nodes being validated and
> not report any warning anymore. I guess one way would be to expand the
> chosen schemas instead. Let me know what you prefer.
> ---
> .../display/amlogic,simple-framebuffer.txt | 33 ----
> .../display/simple-framebuffer-sunxi.txt | 36 ----
> .../bindings/display/simple-framebuffer.txt | 91 ----------
> .../bindings/display/simple-framebuffer.yaml | 164 ++++++++++++++++++
> 4 files changed, 164 insertions(+), 160 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/amlogic,simple-framebuffer.txt
> delete mode 100644 Documentation/devicetree/bindings/display/simple-framebuffer-sunxi.txt
> delete mode 100644 Documentation/devicetree/bindings/display/simple-framebuffer.txt
> create mode 100644 Documentation/devicetree/bindings/display/simple-framebuffer.yaml
[...]
> diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> new file mode 100644
> index 000000000000..9f2245e3f5ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> @@ -0,0 +1,164 @@
> +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
Keep in mind the old files were implicitly GPL2 only. I imagine some
of this is copied.
Also, as gregkh says, are you sure you are okay with GPLv9?
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/simple-framebuffer.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Simple Framebuffer Device Tree Bindings
> +
> +maintainers:
> + - Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> + - Hans de Goede <hdegoede@redhat.com>
> +
> +description: |+
> + A simple frame-buffer describes a frame-buffer setup by firmware or
> + the bootloader, with the assumption that the display hardware has
> + already been set up to scan out from the memory pointed to by the
> + reg property.
> +
> + Since simplefb nodes represent runtime information they must be
> + sub-nodes of the chosen node (*). Simplefb nodes must be named
> + framebuffer@<address>.
> +
> + If the devicetree contains nodes for the display hardware used by a
> + simplefb, then the simplefb node must contain a property called
> + display, which contains a phandle pointing to the primary display
> + hw node, so that the OS knows which simplefb to disable when handing
> + over control to a driver for the real hardware. The bindings for the
> + hw nodes must specify which node is considered the primary node.
> +
> + It is advised to add display# aliases to help the OS determine how
> + to number things. If display# aliases are used, then if the simplefb
> + node contains a display property then the /aliases/display# path
> + must point to the display hw node the display property points to,
> + otherwise it must point directly to the simplefb node.
> +
> + If a simplefb node represents the preferred console for user
> + interaction, then the chosen node stdout-path property should point
> + to it, or to the primary display hw node, as with display#
> + aliases. If display aliases are used then it should be set to the
> + alias instead.
> +
> + It is advised that devicetree files contain pre-filled, disabled
> + framebuffer nodes, so that the firmware only needs to update the
> + mode information and enable them. This way if e.g. later on support
> + for more display clocks get added, the simplefb nodes will already
> + contain this info and the firmware does not need to be updated.
> +
> + If pre-filled framebuffer nodes are used, the firmware may need
> + extra information to find the right node. In that case an extra
> + platform specific compatible and platform specific properties should
> + be used and documented.
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - const: allwinner,simple-framebuffer
> + - const: simple-framebuffer
> +
> + - items:
> + - const: amlogic,simple-framebuffer
> + - const: simple-framebuffer
I'd write this as:
- enum:
- allwinner,simple-framebuffer
- amlogic,simple-framebuffer
- const: simple-framebuffer
> +
> + - const: simple-framebuffer
> +
> + reg:
> + description: Location and size of the framebuffer memory
> +
> + clocks:
> + description: List of clocks used by the framebuffer.
> +
> + power-domains:
> + description: List of power domains used by the framebuffer.
> +
> + width:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Width of the framebuffer in pixels
> +
> + height:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Height of the framebuffer in pixels
> +
> + stride:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Number of bytes of a line in the framebuffer
> +
> + format:
> + description: Format of the framebuffer
> + oneOf:
> + - const: r5g6b5
> + description: 16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b
> + - const: a8b8g8r8
> + description: 32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r
This can be an enum rather than oneOf and a bunch of const.
> +
> + display:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: Primary display hardware node
> +
> + allwinner,pipeline:
> + description: Pipeline used by the framebuffer on Allwinner SoCs
> + oneOf:
> + - const: de_be0-lcd0
> + - const: de_be0-lcd0-hdmi
> + - const: de_be0-lcd0-tve0
> + - const: de_be1-lcd0
> + - const: de_be1-lcd1-hdmi
> + - const: de_fe0-de_be0-lcd0
> + - const: de_fe0-de_be0-lcd0-hdmi
> + - const: de_fe0-de_be0-lcd0-tve0
> + - const: mixer0-lcd0
> + - const: mixer0-lcd0-hdmi
> + - const: mixer1-lcd1-hdmi
> + - const: mixer1-lcd1-tve
Same here.
> +
> + amlogic,pipeline:
> + description: Pipeline used by the framebuffer on Amlogic SoCs
> + oneOf:
> + - const: vpu-cvbs
> + - const: vpu-hdmi
Same here.
> +
> +patternProperties:
> + "^[a-zA-Z0-9-]+-supply$":
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Regulators used by the framebuffer. These should be named
> + according to the names in the device design.
> +
> +required:
> + # The binding requires also reg, width, height, stride and format,
> + # but usually they will be filled by the bootloader.
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + aliases {
> + display0 = &lcdc0;
> + };
> +
> + chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + stdout-path = "display0";
> + framebuffer0: framebuffer@1d385000 {
> + compatible = "simple-framebuffer";
> + reg = <0x1d385000 3840000>;
> + width = <1600>;
> + height = <1200>;
> + stride = <3200>;
> + format = "r5g6b5";
> + clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
> + lcd-supply = <®_dc1sw>;
> + display = <&lcdc0>;
> + };
> + };
> +
> + soc@1c00000 {
> + lcdc0: lcdc@1c0c000 {
> + compatible = "allwinner,sun4i-a10-lcdc";
> + };
> + };
> +
> +...
> --
> 2.20.1
>
next prev parent reply other threads:[~2019-03-25 16:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 13:54 [PATCH] dt-bindings: Add schemas for simple-framebuffer Maxime Ripard
2019-03-25 16:27 ` Rob Herring [this message]
2019-03-26 21:35 ` Maxime Ripard
2019-03-27 13:20 ` Rob Herring
2019-04-01 10:52 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAL_JsqKep7B6LKUMRRxonKV48YEHtYow9TjKJwDUVN0S2BX3Ww@mail.gmail.com \
--to=robh+dt@kernel.org \
--cc=b.zolnierkie@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=hdegoede@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=maxime.ripard@bootlin.com \
--cc=mjourdan@baylibre.com \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).