[PATCH 1/3 v3] drm/panel: Add generic DSI panel YAML bindings

[Rob Herring]

On Fri, Oct 18, 2019 at 1:24 PM Linus Walleij <linus.walleij at linaro.org> wrote:
>
> This adds a starting point for processing and defining generic
> bindings used by DSI panels. We just define one single bool
> property to force the panel into video mode for now.
>
> Cc: devicetree at vger.kernel.org
> Suggested-by: Rob Herring <robh at kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> ChangeLog v2->v3:
> - Make a more complete DSI panel binding including the controller
>   and its address-cells and size-cells and a pattern for the panel
>   nodes. The panel is one per DSI master, the reg property is
>   compulsory but should always be 0 (as far as I can tell) as
>   only one panel can be connected. The bus doesn't really have
>   any addresses for the panel, the address/reg notation seems
>   to be cargo-culted from the port graphs and is not necessary
>   to parse some device trees, it is used to tell whether the
>   node is a panel or not rather than any addressing.
> - I have no idea how many displays you can daisychain on a single
>   DSI master, I just guess 15 will be enough. The MIPI-specs
>   are memberwalled. Someone who knows can tell perhaps?
> ChangeLog v1->v2:
> - New patch after feedback.
> ---
>  .../display/panel/panel-dsi-common.yaml       | 58 +++++++++++++++++++
>  1 file changed, 58 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml

Perhaps should be display/dsi-controller.yaml now?

>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml
> new file mode 100644
> index 000000000000..d63f597eff9c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-dsi-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common Properties for DSI Display Panels
> +
> +maintainers:
> +  - Linus Walleij <linus.walleij at linaro.org>
> +
> +description: |
> +  This document defines device tree properties common to DSI, Display
> +  Serial Interface panels. It doesn't constitute a device tree binding
> +  specification by itself but is meant to be referenced by device tree
> +  bindings.
> +
> +  When referenced from panel device tree bindings the properties defined in
> +  this document are defined as follows. The panel device tree bindings are
> +  responsible for defining whether each property is required or optional.
> +
> +  Notice: this binding concerns DSI panels connected directly to a master
> +  without any intermediate port graph to the panel. Each DSI master
> +  can control exactly one panel. They should all just have a node "panel"
> +  for their panel with their reg-property set to 0.
> +
> +properties:
> +  $nodename:
> +    pattern: "^dsi-controller(@[0-9a-f]+)?$"

You're assuming a certain unit-address format when a dsi-controller
could be on any bus. So use '^dsi-controller(@.*)?$

> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 0
> +
> +patternProperties:
> +  "^panel$":

But here we want to define the unit-address format. The address is the
virtual channel # which can be 0-3:

^panel@[0-3]$

> +    type: object
> +
> +    properties:
> +      reg:
> +        const: 0

minimum: 0
maximum: 3

> +        description:
> +          Only one panel can be connected to each DSI controller, but for

I thought it was up to 4 virtual channels?

> +          historical reasons, the reg property must be specified, as the
> +          DSI controller can contain other child nodes, and operating
> +          systems will identify which child node is the panel by looking
> +          for the reg property. It should however always be set to 0.
> +
> +      enforce-video-mode:
> +        type: boolean
> +        description:
> +          The best option is usually to run a panel in command mode, as this
> +          gives better control over the panel hardware. However for different
> +          reasons like broken hardware, missing features or testing, it may be
> +          useful to be able to force a command mode-capable panel into video
> +          mode.

'reg' should be required?

Rob