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 X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB327C43381 for ; Thu, 4 Mar 2021 09:11:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D96F464EED for ; Thu, 4 Mar 2021 09:11:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236170AbhCDJL1 (ORCPT ); Thu, 4 Mar 2021 04:11:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233126AbhCDJLI (ORCPT ); Thu, 4 Mar 2021 04:11:08 -0500 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F29DC061756 for ; Thu, 4 Mar 2021 01:10:28 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id ci14so28869215ejc.7 for ; Thu, 04 Mar 2021 01:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gynRsFiEHgePHyaarQ8hzDU1xilkr7SD/fM6H3+AlvU=; b=Ubk+98S/cBq11/zbb9HafDOhME3HEcJiiJ9bhN0cmVHvYm+yV1zUxk0XEoHEOILs2U IsQvDjENTdrE5Qd6gE3jWnmlU4Bwz4XdeOL+0PXqWiisZKTwlfjlo3vM3gTcLKsBpWk+ Rvg2jE/LhIV2dt4MSiRaFrasfcMztTaMte5s8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gynRsFiEHgePHyaarQ8hzDU1xilkr7SD/fM6H3+AlvU=; b=qSvzfdiePlj9v6jkinXnkd3aOBkj0xciyS9V00Bz/94Ly0BOWmWERGJzpijzvAyUut jlZVe0z4hLubXxw0M95shGzKTb+5K0yKoPs7EEyGjw3fASr54VoI4BFhvmpz8RV49SZx QR77tGrvQEV40vm052pchYzdTfgbMYEXcPsoWru1ZfLjcBZ+NhGVVE+XE5Vb+DqbfDPs 3mW7oCnagVHO44zIRzwuqjK72grznjbgmzhszQBJ2GIQyA9CRBU2kbSVtwYRdz0X939z 6iOT9szemJ9KbNiuVZM/Hn/74Ha5Ll4OUT3Ok9cPbOwQueQ7/yQiAiwjqEB9pgh7ynsy ZdYA== X-Gm-Message-State: AOAM532KNc8BJ5enl7vPDGzMFUvQdcH0L5z6qOn+vyY74OIQgjKuFXuc IRC3NQbUsmK32ZguYNbXuZicKsT3SoHbVtaThOgBRA== X-Google-Smtp-Source: ABdhPJzSTAn6jTvFpWH0XRgSeuhut8parDgXEnI2p1Z+Nx534TlGSdgNeTzbFxrQs/g2tJzgq9KJrXI9ySKVZuruQc4= X-Received: by 2002:a17:906:3fc3:: with SMTP id k3mr3172834ejj.522.1614849026928; Thu, 04 Mar 2021 01:10:26 -0800 (PST) MIME-Version: 1.0 References: <20210214175211.105107-1-jagan@amarulasolutions.com> In-Reply-To: From: Jagan Teki Date: Thu, 4 Mar 2021 14:40:15 +0530 Message-ID: Subject: Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add bindings for Chipone ICN6211 To: Laurent Pinchart Cc: Rob Herring , Andrzej Hajda , Neil Armstrong , Jonas Karlman , Jernej Skrabec , Sam Ravnborg , dri-devel , linux-kernel , devicetree , linux-amarula Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Laurent, On Thu, Mar 4, 2021 at 4:29 AM Laurent Pinchart wrote: > > Hi Jagan, > > On Wed, Mar 03, 2021 at 08:08:35PM +0530, Jagan Teki wrote: > > On Wed, Feb 24, 2021 at 6:44 PM Laurent Pinchart wrote: > > > On Wed, Feb 24, 2021 at 06:07:43PM +0530, Jagan Teki wrote: > > > > On Mon, Feb 15, 2021 at 5:48 PM Laurent Pinchart wrote: > > > > > On Sun, Feb 14, 2021 at 11:22:10PM +0530, Jagan Teki wrote: > > > > > > ICN6211 is MIPI-DSI to RGB Convertor bridge from Chipone. > > > > > > > > > > > > It has a flexible configuration of MIPI DSI signal input and > > > > > > produce RGB565, RGB666, RGB888 output format. > > > > > > > > > > > > Add dt-bingings for it. > > > > > > > > > > > > Signed-off-by: Jagan Teki > > > > > > --- > > > > > > Changes for v3: > > > > > > - updated to new dt-bindings style > > > > > > > > > > > > .../display/bridge/chipone,icn6211.yaml | 90 +++++++++++++++++++ > > > > > > 1 file changed, 90 insertions(+) > > > > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml > > > > > > new file mode 100644 > > > > > > index 000000000000..13764f13fe46 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml > > > > > > @@ -0,0 +1,90 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: http://devicetree.org/schemas/display/bridge/chipone,icn6211.yaml# > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > + > > > > > > +title: Chipone ICN6211 MIPI-DSI to RGB Converter bridge > > > > > > + > > > > > > +maintainers: > > > > > > + - Jagan Teki > > > > > > + > > > > > > +description: | > > > > > > + ICN6211 is MIPI-DSI to RGB Convertor bridge from chipone. > > > > > > + > > > > > > + It has a flexible configuration of MIPI DSI signal input and > > > > > > + produce RGB565, RGB666, RGB888 output format. > > > > > > > > > > How does one select between the output formats ? Should the output > > > > > connection option be described in the device tree ? > > > > > > > > I think that is a good option to select output formats via dts. what > > > > if it makes it a generic property like data-lanes? since it is common > > > > across many other bridges. > > > > > > Describing the output connection in the device tree sounds like a good > > > idea indeed. The bus-width property could be used for this, maybe along > > > the lines of > > > https://lore.kernel.org/dri-devel/20201013020619.GG3942@pendragon.ideasonboard.com/. > > > > I have seen an issue by passing bus-width where the same bus-with 24 > > can use by RGB888 and RGB666 according to > > mipi_dsi_pixel_format_to_bpp. Having a default RGB888 format now and > > update it when it supports properly, can be a good Idea I thought of. > > Let me know if you have any comments? > > I'm fine with hardcoding a default for now. If a given bus wiring (which > is described in DT by bus-width) can transport different formats, that's > something that should be configured dynamically, either by querying what > format a sink (such as a panel) requires, or if both the source and the > sink can support different formats, possibly by involving userspace in > the selection. Not sure how we can get userspace involvement in DRM here, but if source and sink can have different formats then having precedence to the source would be a good option as it handles low-level configuration for formats. Look like it is worth trying-feature. Maybe we can come up with some RFC and have a discussion. Jagan. 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 X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D4A5C433E6 for ; Thu, 4 Mar 2021 09:10:30 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1470F64EDF for ; Thu, 4 Mar 2021 09:10:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1470F64EDF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amarulasolutions.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6DB6388065; Thu, 4 Mar 2021 09:10:29 +0000 (UTC) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5F82D88065 for ; Thu, 4 Mar 2021 09:10:28 +0000 (UTC) Received: by mail-ej1-x631.google.com with SMTP id ci14so28869214ejc.7 for ; Thu, 04 Mar 2021 01:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gynRsFiEHgePHyaarQ8hzDU1xilkr7SD/fM6H3+AlvU=; b=Ubk+98S/cBq11/zbb9HafDOhME3HEcJiiJ9bhN0cmVHvYm+yV1zUxk0XEoHEOILs2U IsQvDjENTdrE5Qd6gE3jWnmlU4Bwz4XdeOL+0PXqWiisZKTwlfjlo3vM3gTcLKsBpWk+ Rvg2jE/LhIV2dt4MSiRaFrasfcMztTaMte5s8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gynRsFiEHgePHyaarQ8hzDU1xilkr7SD/fM6H3+AlvU=; b=UbpVTUd/1KGHNRQc4tlGEAXBrvBb1aIr/w1c1s7HdS+0CIds7Z+44wd68pjJCq2IRG Ur7kchb/hWbfnQdGMKUsh3lv7U2xkoITrUWmVygjdJ+pk7mjIdzTAaMMyEx15tKNqkKE 5VX4g4tP3dUjwIMzwmsg44J8B/in3I89bE3lt3owiahP9yeyfa58ApAJ03GhfiQiLBys 0mwrG1PDPZDiV/fqC6kE8YthTM5fYoZKmzlt6z/t3eRQJjfsCyhBY46hoUu6j+IEgwpj dzemgKzuJaqy4xNJbHcrLfc8sn3oTeLVUcT8Ow/whGuODRG4MT+01SXwF3xLlVdt7FWn TD9w== X-Gm-Message-State: AOAM5322NKp0ME/69sJt7CceQabg+yzFhVZNZ1luaoXQlItzIpZaJ93s 7KhJDknE/ZDKndjOPM2+VsSBI+hEUd7dkNGUXy0IQ/Ou4weFEQ== X-Google-Smtp-Source: ABdhPJzSTAn6jTvFpWH0XRgSeuhut8parDgXEnI2p1Z+Nx534TlGSdgNeTzbFxrQs/g2tJzgq9KJrXI9ySKVZuruQc4= X-Received: by 2002:a17:906:3fc3:: with SMTP id k3mr3172834ejj.522.1614849026928; Thu, 04 Mar 2021 01:10:26 -0800 (PST) MIME-Version: 1.0 References: <20210214175211.105107-1-jagan@amarulasolutions.com> In-Reply-To: From: Jagan Teki Date: Thu, 4 Mar 2021 14:40:15 +0530 Message-ID: Subject: Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add bindings for Chipone ICN6211 To: Laurent Pinchart X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree , Jernej Skrabec , Jonas Karlman , linux-amarula , Neil Armstrong , linux-kernel , dri-devel , Andrzej Hajda , Rob Herring , Sam Ravnborg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Laurent, On Thu, Mar 4, 2021 at 4:29 AM Laurent Pinchart wrote: > > Hi Jagan, > > On Wed, Mar 03, 2021 at 08:08:35PM +0530, Jagan Teki wrote: > > On Wed, Feb 24, 2021 at 6:44 PM Laurent Pinchart wrote: > > > On Wed, Feb 24, 2021 at 06:07:43PM +0530, Jagan Teki wrote: > > > > On Mon, Feb 15, 2021 at 5:48 PM Laurent Pinchart wrote: > > > > > On Sun, Feb 14, 2021 at 11:22:10PM +0530, Jagan Teki wrote: > > > > > > ICN6211 is MIPI-DSI to RGB Convertor bridge from Chipone. > > > > > > > > > > > > It has a flexible configuration of MIPI DSI signal input and > > > > > > produce RGB565, RGB666, RGB888 output format. > > > > > > > > > > > > Add dt-bingings for it. > > > > > > > > > > > > Signed-off-by: Jagan Teki > > > > > > --- > > > > > > Changes for v3: > > > > > > - updated to new dt-bindings style > > > > > > > > > > > > .../display/bridge/chipone,icn6211.yaml | 90 +++++++++++++++++++ > > > > > > 1 file changed, 90 insertions(+) > > > > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml > > > > > > new file mode 100644 > > > > > > index 000000000000..13764f13fe46 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml > > > > > > @@ -0,0 +1,90 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: http://devicetree.org/schemas/display/bridge/chipone,icn6211.yaml# > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > + > > > > > > +title: Chipone ICN6211 MIPI-DSI to RGB Converter bridge > > > > > > + > > > > > > +maintainers: > > > > > > + - Jagan Teki > > > > > > + > > > > > > +description: | > > > > > > + ICN6211 is MIPI-DSI to RGB Convertor bridge from chipone. > > > > > > + > > > > > > + It has a flexible configuration of MIPI DSI signal input and > > > > > > + produce RGB565, RGB666, RGB888 output format. > > > > > > > > > > How does one select between the output formats ? Should the output > > > > > connection option be described in the device tree ? > > > > > > > > I think that is a good option to select output formats via dts. what > > > > if it makes it a generic property like data-lanes? since it is common > > > > across many other bridges. > > > > > > Describing the output connection in the device tree sounds like a good > > > idea indeed. The bus-width property could be used for this, maybe along > > > the lines of > > > https://lore.kernel.org/dri-devel/20201013020619.GG3942@pendragon.ideasonboard.com/. > > > > I have seen an issue by passing bus-width where the same bus-with 24 > > can use by RGB888 and RGB666 according to > > mipi_dsi_pixel_format_to_bpp. Having a default RGB888 format now and > > update it when it supports properly, can be a good Idea I thought of. > > Let me know if you have any comments? > > I'm fine with hardcoding a default for now. If a given bus wiring (which > is described in DT by bus-width) can transport different formats, that's > something that should be configured dynamically, either by querying what > format a sink (such as a panel) requires, or if both the source and the > sink can support different formats, possibly by involving userspace in > the selection. Not sure how we can get userspace involvement in DRM here, but if source and sink can have different formats then having precedence to the source would be a good option as it handles low-level configuration for formats. Look like it is worth trying-feature. Maybe we can come up with some RFC and have a discussion. Jagan. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel