From patchwork Fri Oct 18 18:24:44 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 1179564 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="auHZttj8"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 46vvZz19pHz9sPK for ; Sat, 19 Oct 2019 05:24:58 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2502853AbfJRSY5 (ORCPT ); Fri, 18 Oct 2019 14:24:57 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:37068 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2502836AbfJRSY5 (ORCPT ); Fri, 18 Oct 2019 14:24:57 -0400 Received: by mail-lj1-f196.google.com with SMTP id l21so7180839lje.4 for ; Fri, 18 Oct 2019 11:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=IYHZuLGg+JGJBwHO1m+JSuqR2RXOf2t8ywlY3WZdrN0=; b=auHZttj89zTTWX6QMDr8blBfC+K/EgSELf0teDHp1pkUjxV63etpiqa9A4Qd08STM7 IMiiWsXaiMaKzdHmXylAP/bj3ts9LRBL5qbSIkL5L6XuGEQTaU7icGOQxSQRzVj1vDur Aikyb2mwMmucPPWhTjD58iPhEhZ/lXlMHmosULz+j1kpV7F5ApvX9Wx5jYn90HQLANJ/ bnABKygJfUUocd53BiIh/CGwCslYNIaQFMGBQgzl9eUt0bTDZnKgEZofPPgyRB/0pg+V E/HYvP8i/wFhI1bTBvgv9nObxFtsvTVGdHo0XI6+ZT7CJBL2LAsgViiImxxu8NUsMlA3 3LxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=IYHZuLGg+JGJBwHO1m+JSuqR2RXOf2t8ywlY3WZdrN0=; b=l9aqMxNMQb0z12OS5DxrrHmnGD/tE72MQmS9PTv5uWJNucojsfAtOmCjAD2pSbiF9D NqBu7NFmkv/2PsPRDp1MlZLK3AgGHda30B/iSx9xIXiP7YjMwfeLrSeky51sixKGNpEB /ylG9aWeQXwV6n2GFekhkvIZ0+N02+NqFs90hxAbdjy9cjilM8T1ehBUqG2gTsdAtp/7 yTWDTMQgZdPYvlXURLY0Kd7p2fQfjqFrL0eaWMY2EVJtGOCTLQDr/WrefYUhDgJxTvH1 6+dNSQrW5NqTMdaTJIczVVheT+uUH6eI/QpfdL+EOeMvhr7YY0lynOVB6+Cj+YnqheZW Jupw== X-Gm-Message-State: APjAAAX0slPXmn8bH0JOaFeXIZQvrtoE9LyXEHrvD7G6ezBDuWKOwv6F JRL2OYm35gGnjyVB5mj/x3knuw== X-Google-Smtp-Source: APXvYqzBKy427jd3dlIZ/D555Svg4NIKOAkSrJwvldFXaPFjPxfgRskBmEv1lPaMhwTVADRpb5luKQ== X-Received: by 2002:a2e:8684:: with SMTP id l4mr7425517lji.87.1571423095129; Fri, 18 Oct 2019 11:24:55 -0700 (PDT) Received: from genomnajs.ideon.se ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id g26sm3020617lje.80.2019.10.18.11.24.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Oct 2019 11:24:51 -0700 (PDT) From: Linus Walleij To: Thierry Reding , Sam Ravnborg , dri-devel@lists.freedesktop.org, Andrzej Hajda Cc: Linus Walleij , devicetree@vger.kernel.org, Rob Herring Subject: [PATCH 1/3 v3] drm/panel: Add generic DSI panel YAML bindings Date: Fri, 18 Oct 2019 20:24:44 +0200 Message-Id: <20191018182446.26131-1-linus.walleij@linaro.org> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org 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@vger.kernel.org Suggested-by: Rob Herring Signed-off-by: Linus Walleij --- 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 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 + +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]+)?$" + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^panel$": + type: object + + properties: + reg: + const: 0 + description: + Only one panel can be connected to each DSI controller, but for + 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.