Message ID | 20230330095941.428122-4-francesco@dolcini.it |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1017786vqo; Thu, 30 Mar 2023 03:16:48 -0700 (PDT) X-Google-Smtp-Source: AKy350ZoVDCfvffaKjCtgEtsfOuHtCUeHheQpxaLrFrnM0UamlOo7hBf1X15ky6AS3JCXqYkcs1i X-Received: by 2002:aa7:981c:0:b0:625:e3c0:8a58 with SMTP id e28-20020aa7981c000000b00625e3c08a58mr23815484pfl.4.1680171408503; Thu, 30 Mar 2023 03:16:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680171408; cv=none; d=google.com; s=arc-20160816; b=R6NP+QIfSO0AXf7iObIjFfPISwLNSEwlwICOARAQGVKGRvg5oMD+yPYVZODFqmZzmc cUX+GV2fnalK6A/zaHMaB3CXjiYf0eE14oQHTIPNTqk1Z7KeTUvpXiny4WXD6N7PXTuV Ux9c4IkDow7smswKuhuiBAiNnupbnLy8WCBnps2+ZsAPDADnCJqZoBQEpBbcXUBHUgA3 44PRUS7Sc3yGLMUeU5ZB8BlVLh62s8I53wPi5U04dO53hiB7aGA1JAh25rXmp2ISYOHM J1GDBsurLXjsTp2tours/z2metHVPzChj3nr1uxX99s9+oBAKDZiA884jSeQZZE/PNsJ K5GA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=sNqdNIwnIBEzrQBOyjwR8yOuKU3u61t7If70w1sY1+w=; b=gF3koQpTXO2H00ZyKgaFcTLk/IRrRX2zAo0uMbnd30K/hl/TOhsK1mLjE11cilBXjg WTYJoBdEk1iZE312/MZqKqQD5bN/R8lR+z+2wQ2/VqD06+oEud1rHwfVaLS+V7DSZnEh wrhwKTduBJLNL3qX9ERAE/WTfdJHaobgPOWRgW7IXc9RD2vKHtrOrV9WfhJYByyzgtp8 0m088KVpPkpGeZIDC2Zyqab5KkmoFc2KybrkeQTTNhxtJ5e4D935TuMxwmrj9ZQ3CXPG gHTHnMPt9kyo9Nku9OiWpzfmqc8CxNZH9Ei29L7N5ubNKjtgSylnaZVJzQpS/wB+BA+u 5W2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c12-20020a624e0c000000b0062abc2c2a40si14363865pfb.89.2023.03.30.03.16.35; Thu, 30 Mar 2023 03:16:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230492AbjC3KAD (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Thu, 30 Mar 2023 06:00:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230303AbjC3J7v (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 30 Mar 2023 05:59:51 -0400 Received: from mail11.truemail.it (mail11.truemail.it [217.194.8.81]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1872AB; Thu, 30 Mar 2023 02:59:50 -0700 (PDT) Received: from francesco-nb.pivistrello.it (93-49-2-63.ip317.fastwebnet.it [93.49.2.63]) by mail11.truemail.it (Postfix) with ESMTPA id C49C320F5A; Thu, 30 Mar 2023 11:59:48 +0200 (CEST) From: Francesco Dolcini <francesco@dolcini.it> To: Andrzej Hajda <andrzej.hajda@intel.com>, Neil Armstrong <neil.armstrong@linaro.org>, Robert Foss <rfoss@kernel.org>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jonas Karlman <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@gmail.com>, dri-devel@lists.freedesktop.org, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Peter Ujfalusi <peter.ujfalusi@ti.com>, devicetree@vger.kernel.org Cc: Francesco Dolcini <francesco.dolcini@toradex.com>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, linux-kernel@vger.kernel.org Subject: [PATCH v1 3/6] dt-bindings: display: bridge: toshiba,tc358768: add parallel input mode Date: Thu, 30 Mar 2023 11:59:38 +0200 Message-Id: <20230330095941.428122-4-francesco@dolcini.it> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230330095941.428122-1-francesco@dolcini.it> References: <20230330095941.428122-1-francesco@dolcini.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761787414736899648?= X-GMAIL-MSGID: =?utf-8?q?1761787414736899648?= |
Series |
drm/bridge: tc358768: Improve parallel RGB input configuration
|
|
Commit Message
Francesco Dolcini
March 30, 2023, 9:59 a.m. UTC
From: Francesco Dolcini <francesco.dolcini@toradex.com> Add new toshiba,input-rgb-mode property to describe the actual signal connection on the parallel RGB input interface. Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> --- .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
Comments
On 30/03/2023 11:59, Francesco Dolcini wrote: > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > Add new toshiba,input-rgb-mode property to describe the actual signal > connection on the parallel RGB input interface. > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > --- > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > index 8f22093b61ae..2638121a2223 100644 > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > @@ -42,6 +42,21 @@ properties: > clock-names: > const: refclk > > + toshiba,input-rgb-mode: > + description: | > + Parallel Input (RGB) Mode. > + > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > + and in the table below. > + > + 0 = R[7:0], G[7:0], B[7:0] RGB888? > + 1 = R[1:0], G[1:0], B[1:0], R[7:2], G[7:2], B[7:2] > + 2 = 8’b0, R[4:0], G[5:0], B[4:0] Isn't this RGB565? Don't we have already properties like this? e.g. colorspace? Best regards, Krzysztof
On Fri, Mar 31, 2023 at 10:48:15AM +0200, Krzysztof Kozlowski wrote: > On 30/03/2023 11:59, Francesco Dolcini wrote: > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > Add new toshiba,input-rgb-mode property to describe the actual signal > > connection on the parallel RGB input interface. > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > --- > > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > > 1 file changed, 15 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > index 8f22093b61ae..2638121a2223 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > @@ -42,6 +42,21 @@ properties: > > clock-names: > > const: refclk > > > > + toshiba,input-rgb-mode: > > + description: | > > + Parallel Input (RGB) Mode. > > + > > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > > + and in the table below. > > + > > + 0 = R[7:0], G[7:0], B[7:0] > > RGB888? Or anything else - like a RGB666 - just connecting to GND the unused pins. > > + 1 = R[1:0], G[1:0], B[1:0], R[7:2], G[7:2], B[7:2] > > + 2 = 8’b0, R[4:0], G[5:0], B[4:0] > > Isn't this RGB565? > > Don't we have already properties like this? e.g. colorspace? It's not really the colorspace this property. tc358768 is a parallel RGB to DSI bridge, it has 24 bit parallel input line. The way this lines are connected is configurable with this parameter, if you look at mode 0 and 1 they all allow to have a RGB888 or a RGB666 or a RGB565 mapping. This just configure some internal mux, it's not strictly about the RGB mode. The description for mode 2 was copied from the datasheet, and I agree this is really about having a RGB565 on the first 16 parallel input pins. Honestly I do not know what is going to happen with PD[23-16] if they are not connected to GND, given that the component does not know the parallel input bus width it might as well sample those pins in some un-documented way. Francesco
On Fri, Mar 31, 2023 at 11:40:01AM +0200, Francesco Dolcini wrote: > On Fri, Mar 31, 2023 at 10:48:15AM +0200, Krzysztof Kozlowski wrote: > > On 30/03/2023 11:59, Francesco Dolcini wrote: > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > > > Add new toshiba,input-rgb-mode property to describe the actual signal > > > connection on the parallel RGB input interface. > > > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > > --- > > > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > > > 1 file changed, 15 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > index 8f22093b61ae..2638121a2223 100644 > > > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > @@ -42,6 +42,21 @@ properties: > > > clock-names: > > > const: refclk > > > > > > + toshiba,input-rgb-mode: > > > + description: | > > > + Parallel Input (RGB) Mode. > > > + > > > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > > > + and in the table below. > > > + > > > + 0 = R[7:0], G[7:0], B[7:0] > > > > RGB888? > > Or anything else - like a RGB666 - just connecting to GND the unused > pins. If the bridge is configured for RGB666, then that's fine. If not, the unused pins should be driven with either the MSB of each component. Otherwise, you'd can't fully saturate the colors. > > > + 1 = R[1:0], G[1:0], B[1:0], R[7:2], G[7:2], B[7:2] > > > + 2 = 8’b0, R[4:0], G[5:0], B[4:0] > > > > Isn't this RGB565? > > > > Don't we have already properties like this? e.g. colorspace? > > It's not really the colorspace this property. > > tc358768 is a parallel RGB to DSI bridge, it has 24 bit parallel input > line. > > The way this lines are connected is configurable with this parameter, if you > look at mode 0 and 1 they all allow to have a RGB888 or a RGB666 or a > RGB565 mapping. This just configure some internal mux, it's not strictly > about the RGB mode. This is the same as other cases. There's a need for describing the interface. It keeps coming up and I keep saying to go create something common. Rob
On Mon, Apr 03, 2023 at 04:01:17PM -0500, Rob Herring wrote: > On Fri, Mar 31, 2023 at 11:40:01AM +0200, Francesco Dolcini wrote: > > On Fri, Mar 31, 2023 at 10:48:15AM +0200, Krzysztof Kozlowski wrote: > > > On 30/03/2023 11:59, Francesco Dolcini wrote: > > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > > > > > Add new toshiba,input-rgb-mode property to describe the actual signal > > > > connection on the parallel RGB input interface. > > > > > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > --- > > > > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > > > > 1 file changed, 15 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > index 8f22093b61ae..2638121a2223 100644 > > > > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > @@ -42,6 +42,21 @@ properties: > > > > clock-names: > > > > const: refclk > > > > > > > > + toshiba,input-rgb-mode: > > > > + description: | > > > > + Parallel Input (RGB) Mode. > > > > + > > > > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > > > > + and in the table below. > > > > + > > > > + 0 = R[7:0], G[7:0], B[7:0] > > > > > > RGB888? > > > > Or anything else - like a RGB666 - just connecting to GND the unused > > pins. > > If the bridge is configured for RGB666, then that's fine. If not, the > unused pins should be driven with either the MSB of each component. > Otherwise, you'd can't fully saturate the colors. > > > > + 1 = R[1:0], G[1:0], B[1:0], R[7:2], G[7:2], B[7:2] > > > > + 2 = 8’b0, R[4:0], G[5:0], B[4:0] > > > > > > Isn't this RGB565? > > > > > > Don't we have already properties like this? e.g. colorspace? > > > > It's not really the colorspace this property. > > > > tc358768 is a parallel RGB to DSI bridge, it has 24 bit parallel input > > line. > > > > The way this lines are connected is configurable with this parameter, if you > > look at mode 0 and 1 they all allow to have a RGB888 or a RGB666 or a > > RGB565 mapping. This just configure some internal mux, it's not strictly > > about the RGB mode. > > This is the same as other cases. There's a need for describing the > interface. It keeps coming up and I keep saying to go create something > common. I am not aware of other discussion on the topic, do you have any pointer I can look at? What I'd like to re-iterate here once more is that this configuration is about how the external 24-bit parallel RGB lines are mapped withing this bridge. It's not mapping the linux media bus format (e.g. not MEDIA_BUS_FMT_RBG888_1X24 or alike). This bridge allow for a limited set of combination (3) as described in this binding. Francesco
On Mon, Apr 03, 2023 at 04:01:17PM -0500, Rob Herring wrote: > On Fri, Mar 31, 2023 at 11:40:01AM +0200, Francesco Dolcini wrote: > > On Fri, Mar 31, 2023 at 10:48:15AM +0200, Krzysztof Kozlowski wrote: > > > On 30/03/2023 11:59, Francesco Dolcini wrote: > > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > > > > > Add new toshiba,input-rgb-mode property to describe the actual signal > > > > connection on the parallel RGB input interface. > > > > > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > --- > > > > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > > > > 1 file changed, 15 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > index 8f22093b61ae..2638121a2223 100644 > > > > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > @@ -42,6 +42,21 @@ properties: > > > > clock-names: > > > > const: refclk > > > > > > > > + toshiba,input-rgb-mode: > > > > + description: | > > > > + Parallel Input (RGB) Mode. > > > > + > > > > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > > > > + and in the table below. > > > > + > > > > + 0 = R[7:0], G[7:0], B[7:0] > > > > > > RGB888? > > > > Or anything else - like a RGB666 - just connecting to GND the unused > > pins. > > If the bridge is configured for RGB666, then that's fine. If not, the > unused pins should be driven with either the MSB of each component. > Otherwise, you'd can't fully saturate the colors. maybe a detail and maybe not really relevant, but this specific bridge has no know-how on the actual RGB inputs width. While I understand what you are saying here, in the end this is about the actual hardware design that can be in any way, including having pins to gnd and have the issue you just described. Francesco
Hello Rob and Krzysztof On Mon, Apr 03, 2023 at 04:01:17PM -0500, Rob Herring wrote: > On Fri, Mar 31, 2023 at 11:40:01AM +0200, Francesco Dolcini wrote: > > On Fri, Mar 31, 2023 at 10:48:15AM +0200, Krzysztof Kozlowski wrote: > > > On 30/03/2023 11:59, Francesco Dolcini wrote: > > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > > > > > Add new toshiba,input-rgb-mode property to describe the actual signal > > > > connection on the parallel RGB input interface. > > > > > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > --- > > > > .../bindings/display/bridge/toshiba,tc358768.yaml | 15 +++++++++++++++ > > > > 1 file changed, 15 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > index 8f22093b61ae..2638121a2223 100644 > > > > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml > > > > @@ -42,6 +42,21 @@ properties: > > > > clock-names: > > > > const: refclk > > > > > > > > + toshiba,input-rgb-mode: > > > > + description: | > > > > + Parallel Input (RGB) Mode. > > > > + > > > > + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet > > > > + and in the table below. > > > > + > > > > + 0 = R[7:0], G[7:0], B[7:0] > > tc358768 is a parallel RGB to DSI bridge, it has 24 bit parallel input > > line. > > > > The way this lines are connected is configurable with this parameter, if you > > look at mode 0 and 1 they all allow to have a RGB888 or a RGB666 or a > > RGB565 mapping. This just configure some internal mux, it's not strictly > > about the RGB mode. > > This is the same as other cases. There's a need for describing the > interface. It keeps coming up and I keep saying to go create something > common. Rob, Krzysztof: you both had concerns on this change and I am not sure how to progress. Let me summarize my current understanding. 1. I do not think that this change is related to the media bus format topic, this is more like the internal bridge RGB pins mux configuration. This `input-rgb-mode` field I am proposing here is orthogonal to the bus format (e.g. linux media-bus-format.h). I can change the name, if we think this is the reason of the confusion, I just used something similar to the words used in the datasheet. Do we have agreement on that or not? 2. Rob asked for a generic solution, since according to him this is a recurring need. I would appreciate some pointer where to look at so I can propose something more generic. Thanks, Francesco
diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml index 8f22093b61ae..2638121a2223 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml @@ -42,6 +42,21 @@ properties: clock-names: const: refclk + toshiba,input-rgb-mode: + description: | + Parallel Input (RGB) Mode. + + RGB inputs (PD[23:0]) color arrangement as documented in the datasheet + and in the table below. + + 0 = R[7:0], G[7:0], B[7:0] + 1 = R[1:0], G[1:0], B[1:0], R[7:2], G[7:2], B[7:2] + 2 = 8’b0, R[4:0], G[5:0], B[4:0] + + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2 ] + default: 0 + ports: $ref: /schemas/graph.yaml#/properties/ports