From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 717C4C47DA2 for ; Wed, 17 Jan 2024 20:14:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=PdXqTudt509KimTcYXBzQaVV8/r7ffgRXfx99h0Ed8A=; b=1dl3G2WKke/6DN EnqpQ+B0gMQiTwDezMKEP1YBjoo5gGoUnU55cBD7ydpdk60HE1H1O+e8/grH+Axix9egSSaNqAAgT tj9e/7KrKmvEcEkj45ES1h/6pGAg2jJ4BsgO8SVwkSMPSERkO9nclEQwPvPVIhkAplbmZx/sJnWPD duTCxW1PqohI2xNtItFcaUeR7q2gz0yPl8WCAFxI/5Sdxju+BY1nAcfx1FeL/NSpO/2PS5RiViNLN 6iOZg4FmuKh6ZW3grLfGCkGvCf0OK+Tvs/O22spGx9/vHnWuLgw8X9o83rkV6n1lWbgX7FMQhuvxi K2/iOoBzXzyrv4FuYPWQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rQCIK-000ceK-24; Wed, 17 Jan 2024 20:13:52 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rQCIG-000cbZ-1N for linux-arm-kernel@lists.infradead.org; Wed, 17 Jan 2024 20:13:50 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 83653CE1D0B; Wed, 17 Jan 2024 20:13:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 856F1C43390; Wed, 17 Jan 2024 20:13:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705522424; bh=6WmOXhgilmcsgUCOS2c4XBXJqOkmHdcKb8pFyCDU1hQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KHroEQ/VOkN0bdYFQZeY1hjdwMXvlHza2D0rfIpl4phtMUBS1cHC2qWP+eWyrCH12 kMo9CmciJOLvKG97/AsO+i/KebOhEHElnmtAA5nCOlEmRKziVEB2pfA4ICvSi6u/Aq UtVoZG2uNxb0qAkRhIcwX23QWsgKQ4mU9cfOEb0waNd0/HTwI6JrtTLrx2fTmiGXaO WQgXm9ZlB67eA6+A6fbu5xBR1Oyo5sEzIuk7kZkGwIfrDemsrKfzqguR+60XvjiKQU eFo2P+LmQI84qCK436hh7OcbY9F24Izpe0HxZ/PhLwQw5IpFUQSvtJYyjApFcFHp07 OKqxjpXspzVAw== Date: Wed, 17 Jan 2024 14:13:42 -0600 From: Rob Herring To: Devarsh Thakkar Cc: jyri.sarha@iki.fi, tomi.valkeinen@ideasonboard.com, airlied@gmail.com, daniel@ffwll.ch, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, nm@ti.com, vigneshr@ti.com, kristo@kernel.org, praneeth@ti.com, a-bhatia1@ti.com, j-luthra@ti.com Subject: Re: [RFC PATCH 1/3] dt-bindings: display: ti,am65x-dss: Add support for display sharing mode Message-ID: <20240117201342.GA3041972-robh@kernel.org> References: <20240116134142.2092483-1-devarsht@ti.com> <20240116134142.2092483-2-devarsht@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240116134142.2092483-2-devarsht@ti.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240117_121348_815178_883FB1D1 X-CRM114-Status: GOOD ( 35.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jan 16, 2024 at 07:11:40PM +0530, Devarsh Thakkar wrote: > Add support for using TI Keystone DSS hardware present in display > sharing mode. > > TI Keystone DSS hardware supports partitioning of resources between > multiple hosts as it provides separate register space and unique > interrupt line to each host. > > The DSS hardware can be used in shared mode in such a way that one or > more of video planes can be owned by Linux wherease other planes can be > owned by remote cores. > > One or more of the video ports can be dedicated exclusively to a > processing core, wherease some of the video ports can be shared between > two hosts too with only one of them having write access. > > Signed-off-by: Devarsh Thakkar > --- > .../bindings/display/ti/ti,am65x-dss.yaml | 82 +++++++++++++++++++ > 1 file changed, 82 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > index 55e3e490d0e6..d9bc69fbf1fb 100644 > --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml > @@ -112,6 +112,86 @@ properties: > Input memory (from main memory to dispc) bandwidth limit in > bytes per second > > + ti,dss-shared-mode: > + type: boolean > + description: > + TI DSS7 supports sharing of display between multiple hosts > + as it provides separate register space for display configuration and > + unique interrupt line to each host. If you care about line breaks, you need '|'. > + One of the host is provided access to the global display > + configuration labelled as "common" region of DSS allows that host > + exclusive access to global registers of DSS while other host can > + configure the display for it's usage using a separate register > + space labelled as "common1". > + The DSS resources can be partitioned in such a way that one or more > + of the video planes are owned by Linux whereas other video planes Your h/w can only run Linux? What if you want to use this same binding to define the configuration to the 'remote processor'? You can easily s/Linux/the OS/, but it all should be reworded to describe things in terms of the local processor. > + can be owned by a remote core. > + The video port controlling these planes acts as a shared video port > + and it can be configured with write access either by Linux or the > + remote core in which case Linux only has read-only access to that > + video port. What is the purpose of this property when all the other properties are required? > + > + ti,dss-shared-mode-planes: > + description: > + The video layer that is owned by processing core running Linux. > + The display driver running from Linux has exclusive write access to > + this video layer. > + $ref: /schemas/types.yaml#/definitions/string > + enum: [vidl, vid] > + > + ti,dss-shared-mode-vp: > + description: > + The video port that is being used in context of processing core > + running Linux with display susbsytem being used in shared mode. > + This can be owned either by the processing core running Linux in > + which case Linux has the write access and the responsibility to > + configure this video port and the associated overlay manager or > + it can be shared between core running Linux and a remote core > + with remote core provided with write access to this video port and > + associated overlay managers and remote core configures and drives > + this video port also feeding data from one or more of the > + video planes owned by Linux, with Linux only having read-only access > + to this video port and associated overlay managers. > + > + $ref: /schemas/types.yaml#/definitions/string > + enum: [vp1, vp2] > + > + ti,dss-shared-mode-common: > + description: > + The DSS register region owned by processing core running Linux. > + $ref: /schemas/types.yaml#/definitions/string > + enum: [common, common1] > + > + ti,dss-shared-mode-vp-owned: > + description: > + This tells whether processing core running Linux has write access to > + the video ports enlisted in ti,dss-shared-mode-vps. > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 1] This can be boolean. Do writes abort or just get ignored? The latter can be probed and doesn't need a property. > + > + ti,dss-shared-mode-plane-zorder: > + description: > + The zorder of the planes owned by Linux. > + For the scenario where Linux is not having write access to associated > + video port, this field is just for > + informational purpose to enumerate the zorder configuration > + being used by remote core. > + > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 1] I don't understand how 0 or 1 defines Z-order. > + > +dependencies: > + ti,dss-shared-mode: [ 'ti,dss-shared-mode-planes', 'ti,dss-shared-mode-vp', > + 'ti,dss-shared-mode-plane-zorder', 'ti,dss-shared-mode-vp-owned'] > + ti,dss-shared-mode-vp: ['ti,dss-shared-mode', 'ti,dss-shared-mode-planes', > + 'ti,dss-shared-mode-plane-zorder', 'ti,dss-shared-mode-vp-owned'] > + ti,dss-shared-mode-planes: ['ti,dss-shared-mode', 'ti,dss-shared-mode-vp', > + 'ti,dss-shared-mode-plane-zorder', 'ti,dss-shared-mode-vp-owned'] > + ti,dss-shared-mode-plane-zorder: ['ti,dss-shared-mode-planes', 'ti,dss-shared-mode-vp', > + 'ti,dss-shared-mode', 'ti,dss-shared-mode-vp-owned'] > + ti,dss-shared-mode-vp-owned: ['ti,dss-shared-mode-planes', 'ti,dss-shared-mode-vp', > + 'ti,dss-shared-mode', 'ti,dss-shared-mode-plane-zorder'] > + > allOf: > - if: > properties: > @@ -123,6 +203,8 @@ allOf: > ports: > properties: > port@0: false > + ti,dss-shared-mode-vp: > + enum: [vp2] This should throw a warning. You just defined a property called 'enum'. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel