From patchwork Sun Nov 3 20:54:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 178376 Delivered-To: patch@linaro.org Received: by 2002:a92:38d5:0:0:0:0:0 with SMTP id g82csp651271ilf; Sun, 3 Nov 2019 12:57:10 -0800 (PST) X-Google-Smtp-Source: APXvYqyHgLmf6vs3UwrdrVYfoaraGe5Yc2aJDeIlcsmrtVJ+zfaxh/Vy3W9DvHL9m3sNESitIU3M X-Received: by 2002:a17:90a:3b0d:: with SMTP id d13mr19273104pjc.86.1572814630827; Sun, 03 Nov 2019 12:57:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572814630; cv=none; d=google.com; s=arc-20160816; b=FrI2ECv0g8qM8kDPxMuOSt6/BZdTtugJo6m15aUXA992tfpIET9MQJD6aenr+oFuNp RTLqTokmKLJ5sm+4iEHXEg5BW1IUKeaUeShsLpgdSNERP2ly30PnwbzjFYlLigAne+zl l8hNRHDeDU7nCBv+M8vHLEPKH2/VmHkqXXkwumhRyndruNbarU/QCRys9RZigm2jjom6 jU+CAH8E31GBuC9NYexxxFtNNLtm6bGUb1Bgr2EvMBbAhKOe+PBQToJH5c/eWFh+Dlr7 DJWzJb6yuKyMWRpTqATbieH7La8zwv8IZB2byXz/ISZUVlqfC9LiWc9IFvPjPNZ/nbTD rxxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:cc:list-subscribe :list-help:list-post:list-archive:list-unsubscribe:list-id :precedence:mime-version:message-id:date:subject:to:from :delivered-to; bh=dbeaArTnIYM0epBcll1NcelhtAe43Fxuc9LDvVKFavw=; b=yB+O7vVMLjuCcQWFjdgikpTx9kRw8V5xi0r+h1CqqNhxeA7KgbBsbCt0D4l4T+H2dl hzhyKJDAEg/W1Ynts0Hj8/gWqiWn43r1RQL8VY2T+hPVq1TlLl/kM8WdtVKbYCaVd8dN L8Fb75EllyPCM7H/grnFHLwqhqqgZhpC6CM1sa7zOLh3BJIjptHXRA9CdmPBcw7ZB1tA K5lrrUNY1z6li551LZ0zz5x/r3eswqTz/ljTWiKL2oeniZsjqogcYovSUYJmTkCRoPI5 NVwO6RjQvsebwMbg3HaSQvlcTOt4BV96RUc//pxB7Hf8sA6V0tHRF3wgZVTX8IM2djpB bAYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of dri-devel-bounces@lists.freedesktop.org designates 2610:10:20:722:a800:ff:fe36:1795 as permitted sender) smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from gabe.freedesktop.org (gabe.freedesktop.org. [2610:10:20:722:a800:ff:fe36:1795]) by mx.google.com with ESMTPS id m99si18089042pjb.76.2019.11.03.12.57.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 03 Nov 2019 12:57:10 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of dri-devel-bounces@lists.freedesktop.org designates 2610:10:20:722:a800:ff:fe36:1795 as permitted sender) client-ip=2610:10:20:722:a800:ff:fe36:1795; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of dri-devel-bounces@lists.freedesktop.org designates 2610:10:20:722:a800:ff:fe36:1795 as permitted sender) smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4E52B6E072; Sun, 3 Nov 2019 20:57:08 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0A5066E072 for ; Sun, 3 Nov 2019 20:57:06 +0000 (UTC) Received: by mail-lj1-x244.google.com with SMTP id t5so15433522ljk.0 for ; Sun, 03 Nov 2019 12:57:06 -0800 (PST) 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=d7KdH5c11vgvcfbrUMRZBwK/wj3iQHTOBDUEMgbBF7o=; b=D2SUL9nilO/MFcTszQCgvqPXbUEPYqrTNl8Uh22nKOX5B9Ek3uBYb4G8lkznLdakdv fUGZBtT0YBheh9Ltc14TvmC9nypV8RX2SG+OHs6dhxxy3CcyBmihkJ97S6QLznCsK6tc 9O08c6k6nEqFvtTP4fWkIy8+Npq8+7DPfKDTEDrqPpDWtu2QTZi+4F3bCRJ4hxMicbDY 1B9WZrmixk9QaR9p9R7m33Oe0qIAX8Goad1n1wr6Aq7FzZwYFHrtYaE1LF5IcK4Z2XCR gi3jfZUP9xJGVUcboxaIEb6FHDGIkuCIb9aiA1ZhDh4+070T1PfPcWoUUTDMIMZZzUWE tKkA== X-Gm-Message-State: APjAAAUjUYU6dIQfTH541ikiNeNfykXugjaAYNejXfuHcYIfHtV4mXgS hAjazDY0aUPPRrRRvZ8+imZ9zg== X-Received: by 2002:a2e:8082:: with SMTP id i2mr15757021ljg.211.1572814625205; Sun, 03 Nov 2019 12:57:05 -0800 (PST) Received: from localhost.localdomain (c-79c8225c.014-348-6c756e10.bbcust.telenor.se. [92.34.200.121]) by smtp.gmail.com with ESMTPSA id v203sm6936784lfa.25.2019.11.03.12.57.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Nov 2019 12:57:03 -0800 (PST) From: Linus Walleij To: Thierry Reding , Sam Ravnborg , dri-devel@lists.freedesktop.org, Rob Herring Subject: [PATCH 1/2 v5] drm/panel: Add generic DSI panel YAML bindings Date: Sun, 3 Nov 2019 21:54:58 +0100 Message-Id: <20191103205459.24965-1-linus.walleij@linaro.org> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 X-Mailman-Original-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=d7KdH5c11vgvcfbrUMRZBwK/wj3iQHTOBDUEMgbBF7o=; b=TYPPMa+QYBVpd5yocUJ15KTLnkA83UNRK08a4/DeZ7HUpLZuH84eBxzF2jKBWvvNPj gHkwO/HlTGwlHp3+4BOdFaNp2Pteoah1dZ1krh8UZamKrQODmGPd97g6hQ8IgvgIAWxw xQuXdii8SbD9zSVU4tKYJ+avPF4+DmBMTTZfNUOCRLCKdX3T7H72VZy9uTlOoomImJSl kxmWMAtI3lhhKb9HaA/XJL6n9K2YdrklYXK4xYkpyqNvKN6bgEhUikmonDV63nNjlsoa +sXi7CcDSLmREezRs+lxGWRwHFIGW+OCG4O6zkkxwNJzz+RyKoeQwJ1bhjckQQ4L1znL f3bg== X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 v4->v5: - Drop the example. - I still have a vert annoying error message in the Sony panel bindings that uses this schema: sony,acx424akp.example.dt.yaml: panel@0: $nodename:0: 'panel@0' does not match '^dsi-controller(@.*)?$' As this is modeled very closely to Documentation/devicetree/bindings/net/mdio.yaml and that one doesn't emit this type of warning for its ethernet-phy@0 etc I am pretty much clueless and just can't see what the problem is. - If I can't figure this out the only viable next step is to drop the ambition to create yaml bindings simply because I'm unable to do it, and go back to traditional text bindings :( ChangeLog v3->v4: - Rename into display/dsi-controller.yaml - Require a virtual channel number for the DSI panel, as DSI have this 2-bit virtual address field. - Bring in some but not all properties from the existing MIPI DSI bindings. This schema can be used with simpler panels but not complex panels with multiple virtual channels for the moment. Let's handle it when we get there. - Add an example. 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. --- .../bindings/display/dsi-controller.yaml | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/dsi-controller.yaml diff --git a/Documentation/devicetree/bindings/display/dsi-controller.yaml b/Documentation/devicetree/bindings/display/dsi-controller.yaml new file mode 100644 index 000000000000..9e2bf7776c15 --- /dev/null +++ b/Documentation/devicetree/bindings/display/dsi-controller.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/dsi-controller.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(@.*)?$" + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^panel@[0-3]$": + description: Panels connected to the DSI link + type: object + + properties: + reg: + minimum: 0 + maximum: 3 + description: + The virtual channel number of a DSI peripheral. Must be in the range + from 0 to 3, as DSI uses a 2-bit addressing scheme. Some DSI + peripherals respond to more than a single virtual channel. In that + case the reg property can take multiple entries, one for each virtual + channel that the peripheral responds to. + + clock-master: + type: boolean + description: + Should be enabled if the host is being used in conjunction with + another DSI host to drive the same peripheral. Hardware supporting + such a configuration generally requires the data on both the busses + to be driven by the same clock. Only the DSI host instance + controlling this clock should contain this property. + + 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. + + required: + - reg + +...