Message ID | 20240221160215.484151-9-panikiel@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-75071-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp1132233dyc; Wed, 21 Feb 2024 08:06:02 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVWOH58VnA5GdLP6WNIglPYMIh2E4CyNIUyWYn1gdqBlAQw8OfhV4G7m4E+4iZJ1DnD4EtRSPAEkBB+OD8mg+/2R+BFOw== X-Google-Smtp-Source: AGHT+IGnewSifcsDhWgyrHGLb2CsVCOPd1LeYuZXmPtwYzcokVD9B1mii5Rcqu77f1PUkSArefwW X-Received: by 2002:ac8:5753:0:b0:42e:3c13:c412 with SMTP id 19-20020ac85753000000b0042e3c13c412mr1767940qtx.26.1708531562029; Wed, 21 Feb 2024 08:06:02 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708531562; cv=pass; d=google.com; s=arc-20160816; b=ugMO5XdO3qmUWGO+Durl4dsw0x5NL2ZqBpzMyGK6Ocf0mGoWDHJ0UWSnXcFa8zTDgy vtGS3vrsyON5IREVVra52qtQxaHAK8t+pvvQpB5SCV0EbGTdq+P5z7z0tiMu2LaEHbEL YV8IjlnTi9HFmpiE8e+yrK60zHzJ0tgNn9NO9SdGF68dhicoTM3dOyi05GQ1FKqew2ZH y2sJZejGurKfdYPWU6xDs6Y1bFe5EDaCTm/QSklvvz2x9bpoJIWaeSDN+JHbGybBRtxJ v4RMn0I5Lfu95uhkEcT8umuQ0L2qF+tNx8V9WP5FGk06dGTZ88/dG89cs+KTnCJbJ64M wK+A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :in-reply-to:date:dkim-signature; bh=QG+lYn+WRJAXK2sPNs+WXBXseOQ/XIK++bgwEo6870E=; fh=3dGoQ2uYhwnwPEmlzI/o+0hVAbvnBHzRPvA/tfrV/mw=; b=P5UzqaL4U9l8szmnLpqKT9Bl/sWPTTCaWwmBdDgk9ROfUt6rVd4HLpBXctw+OAuMsn hGOj+HkVktQwqzMj/zZZ+Efo1kj0mF81mpSJkVOk1dFG3eJmz9O6i9FMwDQxBmda9ytl GfGls+Ysr9sQZtrD2O3rIWt0cF642jUgVz6xWTO1SAEb6Ng60SqLpEi3nKqRB8NwSJpV YZezYK2cNq5xtbTCbLNJWKjoaRhfavgxKB4M6HDaUWja7hT911XpmFvMs6yWd+RPh8ko YVBprVy79+28lTOKd/KY76offv9hNKgexE8nh2iRs2IJ5H17AER5JjISF9xQALhL1mRv NqFQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=Riuf3B+4; arc=pass (i=1 spf=pass spfdomain=flex--panikiel.bounces.google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-75071-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-75071-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id x12-20020ac8730c000000b0042e3c7eec61si935072qto.241.2024.02.21.08.06.01 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 08:06:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-75071-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=Riuf3B+4; arc=pass (i=1 spf=pass spfdomain=flex--panikiel.bounces.google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-75071-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-75071-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id E70271C22B41 for <ouuuleilei@gmail.com>; Wed, 21 Feb 2024 16:05:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D936285641; Wed, 21 Feb 2024 16:02:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Riuf3B+4" Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 898FA84FDF for <linux-kernel@vger.kernel.org>; Wed, 21 Feb 2024 16:02:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708531372; cv=none; b=j4xTzW2ioE6VwX5Rsb3T/SaBAiSMz0XMaNduLwWT7iFtl56rWoXq7/YTGeFiP1D+6LT4Szpu35E9yJEWDEonfOqi394NAQATwZpsKnq+n/DAj5nKY57UZjRigpBhMt0H3jdyX0Jk62LDJAmZfymsxlhB+8arl3CSQGIojB6w4a8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708531372; c=relaxed/simple; bh=fWYaejhZnKdcmqr+oOjmexoKsVVg8E2AtDrI2rkeAoA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=U7DA8yLArLH46jOMXYXNN38fGXGeV3sQdll+hMiwfZeSRFFEJ/Aqszy8YeoEajvYZBi/rzp0A0DdKDc+SCHMfOI/wFM2xB9wdM+dBhLmxpn3Q0S17RGKqBdQWhUmFLdbZzz8cjVkAVttCD8Mono/jwcQGE1WXMiT6UqWdHX6l6s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--panikiel.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Riuf3B+4; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--panikiel.bounces.google.com Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-410422e8cd1so28523405e9.3 for <linux-kernel@vger.kernel.org>; Wed, 21 Feb 2024 08:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708531368; x=1709136168; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=QG+lYn+WRJAXK2sPNs+WXBXseOQ/XIK++bgwEo6870E=; b=Riuf3B+4taQ76UllgzJGzlkPOHcvIxsN4QV2bwEPUV08vDXdY5Zs9Ffrl4Co3iaVFe Pd4gfRyiuIQBznDlOuKn8ADCMMZkMUaaMxAizFqm1Zk+u5/eIWYr4NMUx1c28jDB+dwE ZDOUcTPU32FuL9fzzBKVLCZTYf7IWTTqF8PZwfsMg/m1xqa8kHFJNifvmrEINEirLRVe rxplWp7W3pGtROjGYMfopFwPFW6fRT+4kochBcDfO3NXhSIlZ6HQJB/bAIBeAUx5z9UH sbQe9I4K7aV0JevxYvs7F6ie1KKiwKhA7YOGIXIJRbhb+EIJdAoAuKiVTC7i0U63Du3O alaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708531368; x=1709136168; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=QG+lYn+WRJAXK2sPNs+WXBXseOQ/XIK++bgwEo6870E=; b=gsMD9V/8zrwlxS2RET/19FrwfZSeVLhIlXTLKKl9JZdRjjTxw/1EuIA3cR1zCTVMwN pTyBs8AYJPodH8vkzAQgGVZiBunL23/S0/LdG/Hn4rBPig+WytYghvytxFMvbjFLUjc5 lXgE0mtcWdIrGtzRaTDmXKsxlLJFjWN8tCf9g3QiyO8s8UlUaJwwuDWTQIU8HbM7EKCv uKlONNmLT8FbgznhsoevCP2ZT5VmY+Rkrn48vPBSz+CKx0DI0gKUi/8F/9pxa+HH5Z56 nWOnf5xu+WfQirsCZ0Ec8J49GUQbMhZDlJA2YxhPJBfLodVdIPXV5kSIOkxDrowXMhEq T7Ag== X-Forwarded-Encrypted: i=1; AJvYcCVT73ZjGWandF1MlZKnBhy5KH9WSDNwzRq++nS7OXwOElbC2ZP7KqtePFqVs89c1JlvQW2MpWEojqyOAwkbXhfr7FGkJ3x/fuAp/l4Z X-Gm-Message-State: AOJu0YxQPNgbXmA3te8m9noWi5mh8cv9tpM8ibuhnPB1ml00b4M2wfK2 OTRnjAo4/W/iYYL/i5luabjbep612JNV6rChQYQvlfFHKHPJ8GHUrjPfndJTZybikpJ4A988nbA F5Z86c/WavA== X-Received: from szatan.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:2d83]) (user=panikiel job=sendgmr) by 2002:a05:600c:a383:b0:412:1500:beb4 with SMTP id hn3-20020a05600ca38300b004121500beb4mr159646wmb.7.1708531367605; Wed, 21 Feb 2024 08:02:47 -0800 (PST) Date: Wed, 21 Feb 2024 16:02:14 +0000 In-Reply-To: <20240221160215.484151-1-panikiel@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> Mime-Version: 1.0 References: <20240221160215.484151-1-panikiel@google.com> X-Mailer: git-send-email 2.44.0.rc0.258.g7320e95886-goog Message-ID: <20240221160215.484151-9-panikiel@google.com> Subject: [PATCH v2 8/9] media: dt-bindings: Add Intel Displayport RX IP From: " =?utf-8?q?Pawe=C5=82_Anikiel?= " <panikiel@google.com> To: airlied@gmail.com, akpm@linux-foundation.org, conor+dt@kernel.org, daniel@ffwll.ch, dinguyen@kernel.org, hverkuil-cisco@xs4all.nl, krzysztof.kozlowski+dt@linaro.org, maarten.lankhorst@linux.intel.com, mchehab@kernel.org, mripard@kernel.org, robh+dt@kernel.org, tzimmermann@suse.de Cc: devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, chromeos-krk-upstreaming@google.com, ribalda@chromium.org, " =?utf-8?q?Pawe?= =?utf-8?q?=C5=82_Anikiel?= " <panikiel@google.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791525191601724672 X-GMAIL-MSGID: 1791525191601724672 |
Series |
Add Chameleon v3 video support
|
|
Commit Message
Paweł Anikiel
Feb. 21, 2024, 4:02 p.m. UTC
The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP
Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video
capture and Multi-Stream Transport. The user guide can be found here:
https://www.intel.com/programmable/technical-pdfs/683273.pdf
Signed-off-by: Paweł Anikiel <panikiel@google.com>
---
.../devicetree/bindings/media/intel,dprx.yaml | 160 ++++++++++++++++++
1 file changed, 160 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/intel,dprx.yaml
Comments
On 21/02/2024 17:02, Paweł Anikiel wrote: > The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > capture and Multi-Stream Transport. The user guide can be found here: > > https://www.intel.com/programmable/technical-pdfs/683273.pdf > > Signed-off-by: Paweł Anikiel <panikiel@google.com> > --- > .../devicetree/bindings/media/intel,dprx.yaml | 160 ++++++++++++++++++ > 1 file changed, 160 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/intel,dprx.yaml > > diff --git a/Documentation/devicetree/bindings/media/intel,dprx.yaml b/Documentation/devicetree/bindings/media/intel,dprx.yaml > new file mode 100644 > index 000000000000..31025f2d5dcd > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml > @@ -0,0 +1,160 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Intel DisplayPort RX IP > + > +maintainers: > + - Paweł Anikiel <panikiel@google.com> > + > +description: | > + The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > + capture and Multi-Stream Transport. > + > + The IP features a large number of configuration parameters, found at: > + https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html > + > + The following parameters have to be enabled: > + - Support DisplayPort sink > + - Enable GPU control > + The following parameters' values have to be set in the devicetree: > + - RX maximum link rate > + - Maximum lane count > + - Support MST > + - Max stream count (only if Support MST is enabled) > + > +properties: > + compatible: > + const: intel,dprx-20.0.1 > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + intel,max-link-rate: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: Max link rate configuration parameter Please do not duplicate property name in description. It's useless. Instead explain what is this responsible for. Why max-link-rate would differ for the same dprx-20.0.1? And why standard properties cannot be used? Same for all questions below. > + > + intel,max-lane-count: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: Max lane count configuration parameter > + > + intel,multi-stream-support: > + type: boolean > + description: Multi-Stream Transport support configuration parameter > + > + intel,max-stream-count: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: Max stream count configuration parameter > + > + port: > + $ref: /schemas/graph.yaml#/properties/port > + description: SST main link I don't understand why you have both port and ports. Shouldn't this be under ports? > + > + ports: > + $ref: /schemas/graph.yaml#/properties/ports > + > + properties: > + port@0: > + $ref: /schemas/graph.yaml#/properties/port > + description: MST virtual channel 0 or SST main link > + > + port@1: > + $ref: /schemas/graph.yaml#/properties/port > + description: MST virtual channel 1 > + > + port@2: > + $ref: /schemas/graph.yaml#/properties/port > + description: MST virtual channel 2 > + > + port@3: > + $ref: /schemas/graph.yaml#/properties/port > + description: MST virtual channel 3 > + > +required: > + - compatible > + - reg > + - interrupts > + > +allOf: > + - if: > + required: > + - intel,multi-stream-support > + then: > + required: > + - intel,max-stream-count > + - ports > + else: > + required: > + - port Best regards, Krzysztof
On Mon, Feb 26, 2024 at 10:13 AM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 21/02/2024 17:02, Paweł Anikiel wrote: > > The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > > Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > > capture and Multi-Stream Transport. The user guide can be found here: > > > > https://www.intel.com/programmable/technical-pdfs/683273.pdf > > > > Signed-off-by: Paweł Anikiel <panikiel@google.com> > > --- > > .../devicetree/bindings/media/intel,dprx.yaml | 160 ++++++++++++++++++ > > 1 file changed, 160 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/media/intel,dprx.yaml > > > > diff --git a/Documentation/devicetree/bindings/media/intel,dprx.yaml b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > new file mode 100644 > > index 000000000000..31025f2d5dcd > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > @@ -0,0 +1,160 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Intel DisplayPort RX IP > > + > > +maintainers: > > + - Paweł Anikiel <panikiel@google.com> > > + > > +description: | > > + The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > > + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > > + capture and Multi-Stream Transport. > > + > > + The IP features a large number of configuration parameters, found at: > > + https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html > > + > > + The following parameters have to be enabled: > > + - Support DisplayPort sink > > + - Enable GPU control > > + The following parameters' values have to be set in the devicetree: > > + - RX maximum link rate > > + - Maximum lane count > > + - Support MST > > + - Max stream count (only if Support MST is enabled) > > + > > +properties: > > + compatible: > > + const: intel,dprx-20.0.1 > > + > > + reg: > > + maxItems: 1 > > + > > + interrupts: > > + maxItems: 1 > > + > > + intel,max-link-rate: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: Max link rate configuration parameter > > Please do not duplicate property name in description. It's useless. > Instead explain what is this responsible for. > > Why max-link-rate would differ for the same dprx-20.0.1? And why > standard properties cannot be used? > > Same for all questions below. These four properties are the IP configuration parameters mentioned in the device description. When generating the IP core you can set these parameters, which could make them differ for the same dprx-20.0.1. They are documented in the user guide, for which I also put a link in the description. Is that enough? Or should I also document these parameters here? > > > + > > + intel,max-lane-count: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: Max lane count configuration parameter > > + > > + intel,multi-stream-support: > > + type: boolean > > + description: Multi-Stream Transport support configuration parameter > > + > > + intel,max-stream-count: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: Max stream count configuration parameter > > + > > + port: > > + $ref: /schemas/graph.yaml#/properties/port > > + description: SST main link > > I don't understand why you have both port and ports. Shouldn't this be > under ports? I put both so that you can use the shorter port property when the device only has one port (i.e. no MST support). It would work fine without it. If you think that's unnecessary, I can remove it (and use the ports property even if there is only one).
On 26/02/2024 11:59, Paweł Anikiel wrote: >>> +properties: >>> + compatible: >>> + const: intel,dprx-20.0.1 >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + interrupts: >>> + maxItems: 1 >>> + >>> + intel,max-link-rate: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + description: Max link rate configuration parameter >> >> Please do not duplicate property name in description. It's useless. >> Instead explain what is this responsible for. >> >> Why max-link-rate would differ for the same dprx-20.0.1? And why >> standard properties cannot be used? >> >> Same for all questions below. > > These four properties are the IP configuration parameters mentioned in > the device description. When generating the IP core you can set these > parameters, which could make them differ for the same dprx-20.0.1. > They are documented in the user guide, for which I also put a link in > the description. Is that enough? Or should I also document these > parameters here? user-guide is something for users, like user-space programmers or end-users. I would never open it to look for any information related to hardware. Anyway, external resources are a no-go. We have it clearly in submitting patches: https://elixir.bootlin.com/linux/v6.8-rc6/source/Documentation/process/submitting-patches.rst#L130 > >> >>> + >>> + intel,max-lane-count: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + description: Max lane count configuration parameter >>> + >>> + intel,multi-stream-support: >>> + type: boolean >>> + description: Multi-Stream Transport support configuration parameter >>> + >>> + intel,max-stream-count: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + description: Max stream count configuration parameter >>> + >>> + port: >>> + $ref: /schemas/graph.yaml#/properties/port >>> + description: SST main link >> >> I don't understand why you have both port and ports. Shouldn't this be >> under ports? > > I put both so that you can use the shorter port property when the > device only has one port (i.e. no MST support). It would work fine > without it. If you think that's unnecessary, I can remove it (and use > the ports property even if there is only one). No, it is fine, but then you need allOf: which will restrict to only one of them: either port or ports. Best regards, Krzysztof
On Mon, Feb 26, 2024 at 1:06 PM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 26/02/2024 11:59, Paweł Anikiel wrote: > >>> +properties: > >>> + compatible: > >>> + const: intel,dprx-20.0.1 > >>> + > >>> + reg: > >>> + maxItems: 1 > >>> + > >>> + interrupts: > >>> + maxItems: 1 > >>> + > >>> + intel,max-link-rate: > >>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>> + description: Max link rate configuration parameter > >> > >> Please do not duplicate property name in description. It's useless. > >> Instead explain what is this responsible for. > >> > >> Why max-link-rate would differ for the same dprx-20.0.1? And why > >> standard properties cannot be used? > >> > >> Same for all questions below. > > > > These four properties are the IP configuration parameters mentioned in > > the device description. When generating the IP core you can set these > > parameters, which could make them differ for the same dprx-20.0.1. > > They are documented in the user guide, for which I also put a link in > > the description. Is that enough? Or should I also document these > > parameters here? > > user-guide is something for users, like user-space programmers or > end-users. I would never open it to look for any information related to > hardware. > > Anyway, external resources are a no-go. We have it clearly in submitting > patches: > > https://elixir.bootlin.com/linux/v6.8-rc6/source/Documentation/process/submitting-patches.rst#L130 Okay, I will describe these properties in the bindings as well. > > > > >> > >>> + > >>> + intel,max-lane-count: > >>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>> + description: Max lane count configuration parameter > >>> + > >>> + intel,multi-stream-support: > >>> + type: boolean > >>> + description: Multi-Stream Transport support configuration parameter > >>> + > >>> + intel,max-stream-count: > >>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>> + description: Max stream count configuration parameter > >>> + > >>> + port: > >>> + $ref: /schemas/graph.yaml#/properties/port > >>> + description: SST main link > >> > >> I don't understand why you have both port and ports. Shouldn't this be > >> under ports? > > > > I put both so that you can use the shorter port property when the > > device only has one port (i.e. no MST support). It would work fine > > without it. If you think that's unnecessary, I can remove it (and use > > the ports property even if there is only one). > > No, it is fine, but then you need allOf: which will restrict to only one > of them: either port or ports. There already is an allOf below that says that ports is required for MST support and port is required otherwise. Isn't this enough?
On 26/02/2024 13:43, Paweł Anikiel wrote: >>>>> + intel,max-stream-count: >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + description: Max stream count configuration parameter >>>>> + >>>>> + port: >>>>> + $ref: /schemas/graph.yaml#/properties/port >>>>> + description: SST main link >>>> >>>> I don't understand why you have both port and ports. Shouldn't this be >>>> under ports? >>> >>> I put both so that you can use the shorter port property when the >>> device only has one port (i.e. no MST support). It would work fine >>> without it. If you think that's unnecessary, I can remove it (and use >>> the ports property even if there is only one). >> >> No, it is fine, but then you need allOf: which will restrict to only one >> of them: either port or ports. > > There already is an allOf below that says that ports is required for > MST support and port is required otherwise. Isn't this enough? Add both port and ports and see if it is enough. Best regards, Krzysztof
On Mon, Feb 26, 2024 at 6:29 PM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 26/02/2024 13:43, Paweł Anikiel wrote: > >>>>> + intel,max-stream-count: > >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>>>> + description: Max stream count configuration parameter > >>>>> + > >>>>> + port: > >>>>> + $ref: /schemas/graph.yaml#/properties/port > >>>>> + description: SST main link > >>>> > >>>> I don't understand why you have both port and ports. Shouldn't this be > >>>> under ports? > >>> > >>> I put both so that you can use the shorter port property when the > >>> device only has one port (i.e. no MST support). It would work fine > >>> without it. If you think that's unnecessary, I can remove it (and use > >>> the ports property even if there is only one). > >> > >> No, it is fine, but then you need allOf: which will restrict to only one > >> of them: either port or ports. > > > > There already is an allOf below that says that ports is required for > > MST support and port is required otherwise. Isn't this enough? > > Add both port and ports and see if it is enough. Ok, I see. I tried and this seems to work: oneOf: - required: - port - required: - ports And that would make the if/else with port and ports below not needed. What do you think?
On Tue, Feb 27, 2024 at 02:11:27PM +0100, Paweł Anikiel wrote: > On Mon, Feb 26, 2024 at 6:29 PM Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: > > > > On 26/02/2024 13:43, Paweł Anikiel wrote: > > >>>>> + intel,max-stream-count: > > >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 > > >>>>> + description: Max stream count configuration parameter > > >>>>> + > > >>>>> + port: > > >>>>> + $ref: /schemas/graph.yaml#/properties/port > > >>>>> + description: SST main link > > >>>> > > >>>> I don't understand why you have both port and ports. Shouldn't this be > > >>>> under ports? > > >>> > > >>> I put both so that you can use the shorter port property when the > > >>> device only has one port (i.e. no MST support). It would work fine > > >>> without it. If you think that's unnecessary, I can remove it (and use > > >>> the ports property even if there is only one). > > >> > > >> No, it is fine, but then you need allOf: which will restrict to only one > > >> of them: either port or ports. > > > > > > There already is an allOf below that says that ports is required for > > > MST support and port is required otherwise. Isn't this enough? > > > > Add both port and ports and see if it is enough. > > Ok, I see. I tried and this seems to work: > > oneOf: > - required: > - port > - required: > - ports > > And that would make the if/else with port and ports below not needed. > What do you think? Just always use 'ports' rather than complicate things. Rob
On Mon, Feb 26, 2024 at 11:59:42AM +0100, Paweł Anikiel wrote: > On Mon, Feb 26, 2024 at 10:13 AM Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: > > > > On 21/02/2024 17:02, Paweł Anikiel wrote: > > > The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > > > Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > > > capture and Multi-Stream Transport. The user guide can be found here: > > > > > > https://www.intel.com/programmable/technical-pdfs/683273.pdf > > > > > > Signed-off-by: Paweł Anikiel <panikiel@google.com> > > > --- > > > .../devicetree/bindings/media/intel,dprx.yaml | 160 ++++++++++++++++++ > > > 1 file changed, 160 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/media/intel,dprx.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/media/intel,dprx.yaml b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > > new file mode 100644 > > > index 000000000000..31025f2d5dcd > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > > @@ -0,0 +1,160 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Intel DisplayPort RX IP > > > + > > > +maintainers: > > > + - Paweł Anikiel <panikiel@google.com> > > > + > > > +description: | > > > + The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > > > + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > > > + capture and Multi-Stream Transport. > > > + > > > + The IP features a large number of configuration parameters, found at: > > > + https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html > > > + > > > + The following parameters have to be enabled: > > > + - Support DisplayPort sink > > > + - Enable GPU control > > > + The following parameters' values have to be set in the devicetree: > > > + - RX maximum link rate > > > + - Maximum lane count > > > + - Support MST > > > + - Max stream count (only if Support MST is enabled) > > > + > > > +properties: > > > + compatible: > > > + const: intel,dprx-20.0.1 > > > + > > > + reg: > > > + maxItems: 1 > > > + > > > + interrupts: > > > + maxItems: 1 > > > + > > > + intel,max-link-rate: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: Max link rate configuration parameter > > > > Please do not duplicate property name in description. It's useless. > > Instead explain what is this responsible for. > > > > Why max-link-rate would differ for the same dprx-20.0.1? And why > > standard properties cannot be used? > > > > Same for all questions below. > > These four properties are the IP configuration parameters mentioned in > the device description. When generating the IP core you can set these > parameters, which could make them differ for the same dprx-20.0.1. > They are documented in the user guide, for which I also put a link in > the description. Is that enough? Or should I also document these > parameters here? Use the standard properties: link-frequencies and data-lanes. Those go under the port(s) because they are inheritly per logical link. Rob
On Tue, Feb 27, 2024 at 3:29 PM Rob Herring <robh@kernel.org> wrote: > > On Mon, Feb 26, 2024 at 11:59:42AM +0100, Paweł Anikiel wrote: > > On Mon, Feb 26, 2024 at 10:13 AM Krzysztof Kozlowski > > <krzysztof.kozlowski@linaro.org> wrote: > > > > > > On 21/02/2024 17:02, Paweł Anikiel wrote: > > > > The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > > > > Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > > > > capture and Multi-Stream Transport. The user guide can be found here: > > > > > > > > https://www.intel.com/programmable/technical-pdfs/683273.pdf > > > > > > > > Signed-off-by: Paweł Anikiel <panikiel@google.com> > > > > --- > > > > .../devicetree/bindings/media/intel,dprx.yaml | 160 ++++++++++++++++++ > > > > 1 file changed, 160 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/media/intel,dprx.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/media/intel,dprx.yaml b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > > > new file mode 100644 > > > > index 000000000000..31025f2d5dcd > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > > > @@ -0,0 +1,160 @@ > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Intel DisplayPort RX IP > > > > + > > > > +maintainers: > > > > + - Paweł Anikiel <panikiel@google.com> > > > > + > > > > +description: | > > > > + The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > > > > + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > > > > + capture and Multi-Stream Transport. > > > > + > > > > + The IP features a large number of configuration parameters, found at: > > > > + https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html > > > > + > > > > + The following parameters have to be enabled: > > > > + - Support DisplayPort sink > > > > + - Enable GPU control > > > > + The following parameters' values have to be set in the devicetree: > > > > + - RX maximum link rate > > > > + - Maximum lane count > > > > + - Support MST > > > > + - Max stream count (only if Support MST is enabled) > > > > + > > > > +properties: > > > > + compatible: > > > > + const: intel,dprx-20.0.1 > > > > + > > > > + reg: > > > > + maxItems: 1 > > > > + > > > > + interrupts: > > > > + maxItems: 1 > > > > + > > > > + intel,max-link-rate: > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > + description: Max link rate configuration parameter > > > > > > Please do not duplicate property name in description. It's useless. > > > Instead explain what is this responsible for. > > > > > > Why max-link-rate would differ for the same dprx-20.0.1? And why > > > standard properties cannot be used? > > > > > > Same for all questions below. > > > > These four properties are the IP configuration parameters mentioned in > > the device description. When generating the IP core you can set these > > parameters, which could make them differ for the same dprx-20.0.1. > > They are documented in the user guide, for which I also put a link in > > the description. Is that enough? Or should I also document these > > parameters here? > > Use the standard properties: link-frequencies and data-lanes. Those go > under the port(s) because they are inheritly per logical link. The DP receiver has one input interface (a deserialized DP stream), and up to four output interfaces (the decoded video streams). The "max link rate" and "max lane count" parameters only describe the input interface to the receiver. However, the port(s) I am using here are for the output streams. They are not affected by those parameters, so I don't think these properties should go under the output port(s). The receiver doesn't have an input port in the DT, because there isn't any controllable entity on the other side - the deserializer doesn't have any software interface. Since these standard properties (link-frequencies and data-lanes) are only defined in video-interfaces.yaml (which IIUC describes a graph endpoint), I can't use them directly in the device node. Do you see a way to use these standard properties here?
On 28/02/2024 12:05, Paweł Anikiel wrote: > On Tue, Feb 27, 2024 at 3:29 PM Rob Herring <robh@kernel.org> wrote: >> >> On Mon, Feb 26, 2024 at 11:59:42AM +0100, Paweł Anikiel wrote: >>> On Mon, Feb 26, 2024 at 10:13 AM Krzysztof Kozlowski >>> <krzysztof.kozlowski@linaro.org> wrote: >>>> >>>> On 21/02/2024 17:02, Paweł Anikiel wrote: >>>>> The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP >>>>> Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video >>>>> capture and Multi-Stream Transport. The user guide can be found here: >>>>> >>>>> https://www.intel.com/programmable/technical-pdfs/683273.pdf >>>>> >>>>> Signed-off-by: Paweł Anikiel <panikiel@google.com> >>>>> --- >>>>> .../devicetree/bindings/media/intel,dprx.yaml | 160 ++++++++++++++++++ >>>>> 1 file changed, 160 insertions(+) >>>>> create mode 100644 Documentation/devicetree/bindings/media/intel,dprx.yaml >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/media/intel,dprx.yaml b/Documentation/devicetree/bindings/media/intel,dprx.yaml >>>>> new file mode 100644 >>>>> index 000000000000..31025f2d5dcd >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml >>>>> @@ -0,0 +1,160 @@ >>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >>>>> +%YAML 1.2 >>>>> +--- >>>>> +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>> + >>>>> +title: Intel DisplayPort RX IP >>>>> + >>>>> +maintainers: >>>>> + - Paweł Anikiel <panikiel@google.com> >>>>> + >>>>> +description: | >>>>> + The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP >>>>> + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video >>>>> + capture and Multi-Stream Transport. >>>>> + >>>>> + The IP features a large number of configuration parameters, found at: >>>>> + https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html >>>>> + >>>>> + The following parameters have to be enabled: >>>>> + - Support DisplayPort sink >>>>> + - Enable GPU control >>>>> + The following parameters' values have to be set in the devicetree: >>>>> + - RX maximum link rate >>>>> + - Maximum lane count >>>>> + - Support MST >>>>> + - Max stream count (only if Support MST is enabled) >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + const: intel,dprx-20.0.1 >>>>> + >>>>> + reg: >>>>> + maxItems: 1 >>>>> + >>>>> + interrupts: >>>>> + maxItems: 1 >>>>> + >>>>> + intel,max-link-rate: >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + description: Max link rate configuration parameter >>>> >>>> Please do not duplicate property name in description. It's useless. >>>> Instead explain what is this responsible for. >>>> >>>> Why max-link-rate would differ for the same dprx-20.0.1? And why >>>> standard properties cannot be used? >>>> >>>> Same for all questions below. >>> >>> These four properties are the IP configuration parameters mentioned in >>> the device description. When generating the IP core you can set these >>> parameters, which could make them differ for the same dprx-20.0.1. >>> They are documented in the user guide, for which I also put a link in >>> the description. Is that enough? Or should I also document these >>> parameters here? >> >> Use the standard properties: link-frequencies and data-lanes. Those go >> under the port(s) because they are inheritly per logical link. > > The DP receiver has one input interface (a deserialized DP stream), > and up to four output interfaces (the decoded video streams). The "max > link rate" and "max lane count" parameters only describe the input > interface to the receiver. However, the port(s) I am using here are > for the output streams. They are not affected by those parameters, so > I don't think these properties should go under the output port(s). > > The receiver doesn't have an input port in the DT, because there isn't > any controllable entity on the other side - the deserializer doesn't > have any software interface. Since these standard properties > (link-frequencies and data-lanes) are only defined in > video-interfaces.yaml (which IIUC describes a graph endpoint), I can't > use them directly in the device node. DT describes the hardware, so where does the input come? From something, right? Regardless if you have a driver or not. There is dp-connector binding, if this is physical port. > > Do you see a way to use these standard properties here? Best regards, Krzysztof
On Wed, Feb 28, 2024 at 1:18 PM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 28/02/2024 12:05, Paweł Anikiel wrote: > > On Tue, Feb 27, 2024 at 3:29 PM Rob Herring <robh@kernel.org> wrote: > >> > >> On Mon, Feb 26, 2024 at 11:59:42AM +0100, Paweł Anikiel wrote: > >>> On Mon, Feb 26, 2024 at 10:13 AM Krzysztof Kozlowski > >>> <krzysztof.kozlowski@linaro.org> wrote: > >>>> > >>>> On 21/02/2024 17:02, Paweł Anikiel wrote: > >>>>> The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > >>>>> Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > >>>>> capture and Multi-Stream Transport. The user guide can be found here: > >>>>> > >>>>> https://www.intel.com/programmable/technical-pdfs/683273.pdf > >>>>> > >>>>> Signed-off-by: Paweł Anikiel <panikiel@google.com> > >>>>> --- > >>>>> .../devicetree/bindings/media/intel,dprx.yaml | 160 ++++++++++++++++++ > >>>>> 1 file changed, 160 insertions(+) > >>>>> create mode 100644 Documentation/devicetree/bindings/media/intel,dprx.yaml > >>>>> > >>>>> diff --git a/Documentation/devicetree/bindings/media/intel,dprx.yaml b/Documentation/devicetree/bindings/media/intel,dprx.yaml > >>>>> new file mode 100644 > >>>>> index 000000000000..31025f2d5dcd > >>>>> --- /dev/null > >>>>> +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml > >>>>> @@ -0,0 +1,160 @@ > >>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > >>>>> +%YAML 1.2 > >>>>> +--- > >>>>> +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# > >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>>> + > >>>>> +title: Intel DisplayPort RX IP > >>>>> + > >>>>> +maintainers: > >>>>> + - Paweł Anikiel <panikiel@google.com> > >>>>> + > >>>>> +description: | > >>>>> + The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > >>>>> + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > >>>>> + capture and Multi-Stream Transport. > >>>>> + > >>>>> + The IP features a large number of configuration parameters, found at: > >>>>> + https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html > >>>>> + > >>>>> + The following parameters have to be enabled: > >>>>> + - Support DisplayPort sink > >>>>> + - Enable GPU control > >>>>> + The following parameters' values have to be set in the devicetree: > >>>>> + - RX maximum link rate > >>>>> + - Maximum lane count > >>>>> + - Support MST > >>>>> + - Max stream count (only if Support MST is enabled) > >>>>> + > >>>>> +properties: > >>>>> + compatible: > >>>>> + const: intel,dprx-20.0.1 > >>>>> + > >>>>> + reg: > >>>>> + maxItems: 1 > >>>>> + > >>>>> + interrupts: > >>>>> + maxItems: 1 > >>>>> + > >>>>> + intel,max-link-rate: > >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>>>> + description: Max link rate configuration parameter > >>>> > >>>> Please do not duplicate property name in description. It's useless. > >>>> Instead explain what is this responsible for. > >>>> > >>>> Why max-link-rate would differ for the same dprx-20.0.1? And why > >>>> standard properties cannot be used? > >>>> > >>>> Same for all questions below. > >>> > >>> These four properties are the IP configuration parameters mentioned in > >>> the device description. When generating the IP core you can set these > >>> parameters, which could make them differ for the same dprx-20.0.1. > >>> They are documented in the user guide, for which I also put a link in > >>> the description. Is that enough? Or should I also document these > >>> parameters here? > >> > >> Use the standard properties: link-frequencies and data-lanes. Those go > >> under the port(s) because they are inheritly per logical link. > > > > The DP receiver has one input interface (a deserialized DP stream), > > and up to four output interfaces (the decoded video streams). The "max > > link rate" and "max lane count" parameters only describe the input > > interface to the receiver. However, the port(s) I am using here are > > for the output streams. They are not affected by those parameters, so > > I don't think these properties should go under the output port(s). > > > > The receiver doesn't have an input port in the DT, because there isn't > > any controllable entity on the other side - the deserializer doesn't > > have any software interface. Since these standard properties > > (link-frequencies and data-lanes) are only defined in > > video-interfaces.yaml (which IIUC describes a graph endpoint), I can't > > use them directly in the device node. > > DT describes the hardware, so where does the input come? From something, > right? Regardless if you have a driver or not. There is dp-connector > binding, if this is physical port. Yes, it is a physical port. I agree adding a DT node for the physical DP input connector would let us add link-frequencies to the input port of the receiver. However, dp-connector seems to be a binding for an output port - it's under schemas/display/connector, and DP_PWR can be a power supply only for an output port (looking at the dp-pwr-supply property). Also, the driver for this binding is a DRM bridge driver (display-connector.c) which would not be compatible with a v4l2 (sub)device.
On Wed, Feb 28, 2024 at 02:09:33PM +0100, Paweł Anikiel wrote: > On Wed, Feb 28, 2024 at 1:18 PM Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: > > > > On 28/02/2024 12:05, Paweł Anikiel wrote: > > > On Tue, Feb 27, 2024 at 3:29 PM Rob Herring <robh@kernel.org> wrote: > > >> > > >> On Mon, Feb 26, 2024 at 11:59:42AM +0100, Paweł Anikiel wrote: > > >>> On Mon, Feb 26, 2024 at 10:13 AM Krzysztof Kozlowski > > >>> <krzysztof.kozlowski@linaro.org> wrote: > > >>>> > > >>>> On 21/02/2024 17:02, Paweł Anikiel wrote: > > >>>>> The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > > >>>>> Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > > >>>>> capture and Multi-Stream Transport. The user guide can be found here: > > >>>>> > > >>>>> https://www.intel.com/programmable/technical-pdfs/683273.pdf > > >>>>> > > >>>>> Signed-off-by: Paweł Anikiel <panikiel@google.com> > > >>>>> --- > > >>>>> .../devicetree/bindings/media/intel,dprx.yaml | 160 ++++++++++++++++++ > > >>>>> 1 file changed, 160 insertions(+) > > >>>>> create mode 100644 Documentation/devicetree/bindings/media/intel,dprx.yaml > > >>>>> > > >>>>> diff --git a/Documentation/devicetree/bindings/media/intel,dprx.yaml b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > >>>>> new file mode 100644 > > >>>>> index 000000000000..31025f2d5dcd > > >>>>> --- /dev/null > > >>>>> +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml > > >>>>> @@ -0,0 +1,160 @@ > > >>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > >>>>> +%YAML 1.2 > > >>>>> +--- > > >>>>> +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# > > >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > > >>>>> + > > >>>>> +title: Intel DisplayPort RX IP > > >>>>> + > > >>>>> +maintainers: > > >>>>> + - Paweł Anikiel <panikiel@google.com> > > >>>>> + > > >>>>> +description: | > > >>>>> + The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP > > >>>>> + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video > > >>>>> + capture and Multi-Stream Transport. > > >>>>> + > > >>>>> + The IP features a large number of configuration parameters, found at: > > >>>>> + https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html > > >>>>> + > > >>>>> + The following parameters have to be enabled: > > >>>>> + - Support DisplayPort sink > > >>>>> + - Enable GPU control > > >>>>> + The following parameters' values have to be set in the devicetree: > > >>>>> + - RX maximum link rate > > >>>>> + - Maximum lane count > > >>>>> + - Support MST > > >>>>> + - Max stream count (only if Support MST is enabled) > > >>>>> + > > >>>>> +properties: > > >>>>> + compatible: > > >>>>> + const: intel,dprx-20.0.1 > > >>>>> + > > >>>>> + reg: > > >>>>> + maxItems: 1 > > >>>>> + > > >>>>> + interrupts: > > >>>>> + maxItems: 1 > > >>>>> + > > >>>>> + intel,max-link-rate: > > >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 > > >>>>> + description: Max link rate configuration parameter > > >>>> > > >>>> Please do not duplicate property name in description. It's useless. > > >>>> Instead explain what is this responsible for. > > >>>> > > >>>> Why max-link-rate would differ for the same dprx-20.0.1? And why > > >>>> standard properties cannot be used? > > >>>> > > >>>> Same for all questions below. > > >>> > > >>> These four properties are the IP configuration parameters mentioned in > > >>> the device description. When generating the IP core you can set these > > >>> parameters, which could make them differ for the same dprx-20.0.1. > > >>> They are documented in the user guide, for which I also put a link in > > >>> the description. Is that enough? Or should I also document these > > >>> parameters here? > > >> > > >> Use the standard properties: link-frequencies and data-lanes. Those go > > >> under the port(s) because they are inheritly per logical link. > > > > > > The DP receiver has one input interface (a deserialized DP stream), > > > and up to four output interfaces (the decoded video streams). The "max > > > link rate" and "max lane count" parameters only describe the input > > > interface to the receiver. However, the port(s) I am using here are > > > for the output streams. They are not affected by those parameters, so > > > I don't think these properties should go under the output port(s). > > > > > > The receiver doesn't have an input port in the DT, because there isn't > > > any controllable entity on the other side - the deserializer doesn't > > > have any software interface. Since these standard properties > > > (link-frequencies and data-lanes) are only defined in > > > video-interfaces.yaml (which IIUC describes a graph endpoint), I can't > > > use them directly in the device node. > > > > DT describes the hardware, so where does the input come? From something, > > right? Regardless if you have a driver or not. There is dp-connector > > binding, if this is physical port. > > Yes, it is a physical port. I agree adding a DT node for the physical > DP input connector would let us add link-frequencies to the input port > of the receiver. > > However, dp-connector seems to be a binding for an output port - it's > under schemas/display/connector, and DP_PWR can be a power supply only > for an output port (looking at the dp-pwr-supply property). Also, the > driver for this binding is a DRM bridge driver (display-connector.c) > which would not be compatible with a v4l2 (sub)device. So then we should add 'dp-input-connector' because they are different. When we haven't defined connectors, properties of the connector have been shoved in whatever node is associated with a connector like you have done. That works for a while, but then becomes unmanageable. DP on USB-C connectors for example. OTOH, maybe your use here is niche enough to not be worth the trouble. Depends if we see the need for video input connectors in general. Rob
diff --git a/Documentation/devicetree/bindings/media/intel,dprx.yaml b/Documentation/devicetree/bindings/media/intel,dprx.yaml new file mode 100644 index 000000000000..31025f2d5dcd --- /dev/null +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/intel,dprx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel DisplayPort RX IP + +maintainers: + - Paweł Anikiel <panikiel@google.com> + +description: | + The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP + Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video + capture and Multi-Stream Transport. + + The IP features a large number of configuration parameters, found at: + https://www.intel.com/content/www/us/en/docs/programmable/683273/23-3-20-0-1/sink-parameters.html + + The following parameters have to be enabled: + - Support DisplayPort sink + - Enable GPU control + The following parameters' values have to be set in the devicetree: + - RX maximum link rate + - Maximum lane count + - Support MST + - Max stream count (only if Support MST is enabled) + +properties: + compatible: + const: intel,dprx-20.0.1 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + intel,max-link-rate: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Max link rate configuration parameter + + intel,max-lane-count: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Max lane count configuration parameter + + intel,multi-stream-support: + type: boolean + description: Multi-Stream Transport support configuration parameter + + intel,max-stream-count: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Max stream count configuration parameter + + port: + $ref: /schemas/graph.yaml#/properties/port + description: SST main link + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: MST virtual channel 0 or SST main link + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: MST virtual channel 1 + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: MST virtual channel 2 + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: MST virtual channel 3 + +required: + - compatible + - reg + - interrupts + +allOf: + - if: + required: + - intel,multi-stream-support + then: + required: + - intel,max-stream-count + - ports + else: + required: + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + dp-receiver@c0062000 { + compatible = "intel,dprx-20.0.1"; + reg = <0xc0062000 0x800>; + interrupt-parent = <&dprx_mst_irq>; + interrupts = <0 IRQ_TYPE_EDGE_RISING>; + intel,max-link-rate = <0x1e>; + intel,max-lane-count = <4>; + intel,multi-stream-support; + intel,max-stream-count = <4>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dprx_mst_0: endpoint { + remote-endpoint = <&fb_mst0_0>; + }; + }; + + port@1 { + reg = <1>; + dprx_mst_1: endpoint { + remote-endpoint = <&fb_mst1_0>; + }; + }; + + port@2 { + reg = <2>; + dprx_mst_2: endpoint { + remote-endpoint = <&fb_mst2_0>; + }; + }; + + port@3 { + reg = <3>; + dprx_mst_3: endpoint { + remote-endpoint = <&fb_mst3_0>; + }; + }; + }; + }; + + - | + dp-receiver@c0064000 { + compatible = "intel,dprx-20.0.1"; + reg = <0xc0064000 0x800>; + interrupt-parent = <&dprx_sst_irq>; + interrupts = <0 IRQ_TYPE_EDGE_RISING>; + intel,max-link-rate = <0x1e>; + intel,max-lane-count = <4>; + + port { + dprx_sst_0: endpoint { + remote-endpoint = <&fb_sst_0>; + }; + }; + };