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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 8066DC433EF for ; Fri, 18 Mar 2022 16:35:56 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7506010E035; Fri, 18 Mar 2022 16:35:55 +0000 (UTC) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5BF3810E035 for ; Fri, 18 Mar 2022 16:35:54 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3CEF932003C0; Fri, 18 Mar 2022 12:35:52 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 18 Mar 2022 12:35:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; bh=Lkir1zse4kqeDzUeV3bPm0yeNpW0sGfYaTwEzB NrcOI=; b=aXY9sk3erwxTrvmERqB3UPyYTS+vAg6ZAUdx/BBA7r6LqFGh5uQv+X zwax3XfwE2Ud2a/nhV5O4tcsqqolvqBlVmyJIu5oft67cn8Vlb8bvIwKCV5D3mnW 6T0gTvB8icrLNwaMY+C3MjcbPvgihFEchcGBnARiNmIILzRYuqypEXGuJ1numm2U Yd8hLo1np+YtYQaXUREE5ToX0ufb0/jXZNTb3fVNYfXwtWi+lC9ATRhg5BdbSiWK lStAFDT4dEtkQtZZyLOsoDW7bacJjc7uTozoq4OJuRsDB7Ch4jp7IHxBXbThQHq7 5TbXG1z7UTb++U6M58ih28v4AvhhBJfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Lkir1zse4kqeDzUeV 3bPm0yeNpW0sGfYaTwEzBNrcOI=; b=SHpuTAvv9k451GxRACDUEdiaUeVKKyeCW cBa6VOhjqdMZim7a5gbn5m9fQFl5TqH+zSStBoD4sP19tmKAsgbFuMkaD9fyYiJx CsyucB5NxdmIAPWBRx4f+57VMBuubyf+YEcRnytuLqx0tTDaJqoX7kiQHPkWM7rG 6q11lTvW+3203LUx5akNj68nl2U55VtS+V+R7xiSKsH0NW1PtitAbr3FPd7Gkkus 7AWByXqj6xVxtVLsQu/cI1eTASLnLLAt4vadTulQNpjsxkK0/EKwiIlhX75d/gxl gNec/VQDnjykAugJKKkoB698N9KWorwV3zNq4KSr714ylfc8X0awg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudefiedgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepveevfeffudeviedtgeethffhteeuffetfeffvdehvedvheetteehvdelfffg jedvnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Mar 2022 12:35:50 -0400 (EDT) Date: Fri, 18 Mar 2022 17:35:49 +0100 From: Maxime Ripard To: Max Krummenacher Subject: Re: [RFC PATCH] drm/panel: simple: panel-dpi: use bus-format to set bpc and bus_format Message-ID: <20220318163549.5a5v3lex4btnnvgb@houat> References: <20220222084723.14310-1-max.krummenacher@toradex.com> <20220223134154.oo7xhf37bgtvm3ai@houat> <20220302142142.zroy464l5etide2g@houat> <9c9a10ca-e6a1-c310-c0a5-37d4fed6efd6@denx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wtrkjvqibu6qw3m4" Content-Disposition: inline In-Reply-To: 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: Marek Vasut , Christoph Niedermaier , Max Krummenacher , Pengutronix Kernel Team , David Airlie , Sam Ravnborg , Sascha Hauer , dri-devel@lists.freedesktop.org, DenysDrozdov , Laurent Pinchart , Shawn Guo , Linux ARM , NXP Linux Team Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --wtrkjvqibu6qw3m4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 07, 2022 at 04:26:56PM +0100, Max Krummenacher wrote: > On Wed, Mar 2, 2022 at 5:22 PM Marek Vasut wrote: > > > > On 3/2/22 15:21, Maxime Ripard wrote: > > > Hi, > > > > Hi, > > > > > Please try to avoid top posting > Sorry. >=20 > > > > > > On Wed, Feb 23, 2022 at 04:25:19PM +0100, Max Krummenacher wrote: > > >> The goal here is to set the element bus_format in the struct > > >> panel_desc. This is an enum with the possible values defined in > > >> include/uapi/linux/media-bus-format.h. > > >> > > >> The enum values are not constructed in a way that you could calculate > > >> the value from color channel width/shift/mapping/whatever. You rather > > >> would have to check if the combination of color channel > > >> width/shift/mapping/whatever maps to an existing value and otherwise > > >> EINVAL out. > > >> > > >> I don't see the value in having yet another way of how this > > >> information can be specified and then having to write a more > > >> complicated parser which maps the dt data to bus_format. > > > > > > Generally speaking, sending an RFC without explicitly stating what you > > > want a comment on isn't very efficient. > > > > Isn't that what RFC stands for -- Request For Comment ? >=20 > I hoped that the link to the original discussion was enough. >=20 > panel-simple used to have a finite number of hardcoded panels selected > by their compatible. > The following patchsets added a compatible 'panel-dpi' which should > allow to specify the panel in the device tree with timing etc. > https://patchwork.kernel.org/project/dri-devel/patch/20200216181513.281= 09-6-sam@ravnborg.org/ > In the same release cycle part of it got reverted: > https://patchwork.kernel.org/project/dri-devel/patch/20200314153047.248= 6-3-sam@ravnborg.org/ > With this it is no longer possible to set bus_format. > > The explanation what makes the use of a property "data-mapping" not a > suitable way in that revert > is a bit vague. Indeed, but I can only guess. BGR666 in itself doesn't mean much for example. Chances are the DPI interface will use a 24 bit bus, so where is the padding? I think that's what Sam and Laurent were talking about: there wasn't enough information encoded in that property to properly describe the format, hence the revert. > The RFC revert of the revert > https://patchwork.kernel.org/project/dri-devel/patch/20220201110717.358= 5-1-cniedermaier@dh-electronics.com/ > tried to get feedback what would be a way forward. This RFC tries the > same by giving a possible solution should > the property name and/or the a bit short strings of the original be > the reason why it is not suitable. >=20 > So the requested comments would be about what was not good enough with > 'data-mapping' and what would be a way forward. >=20 > Especially since in my limited view it is not clear why in panel-lvds > 'data-mapping' is used to state how the bits representing colour are > mapped to the 21 or 28 possible bit position in the LVDS lanes vs. > here where we want to say how the bits representing colour are mapped > to the 16/18/24 lines of the parallel interface would need a different > binding pattern. There's only a few data format in LVDS, so it's ok. A DPI interface is much more free-form, so you need to be a bit more accurate than what is done for LVDS. Maxime --wtrkjvqibu6qw3m4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYjS05QAKCRDj7w1vZxhR xfSvAQD6BoX/ZM1XxmLViA2wxXFC6UTgdG2lltDF7pSrIqNQngEA5uq/6+jaqyjd KPbDzm34EvO9ki73CwnPA5DucStmgAg= =giWM -----END PGP SIGNATURE----- --wtrkjvqibu6qw3m4-- 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 9C9F1C433EF for ; Fri, 18 Mar 2022 16:37:25 +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-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-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BtQ3lRv6oZ9/1GdMoiZ/G6qwsZWOCpWdfvUsoel5Xic=; b=R3fkDyH4OZaYoH3vLzhGbXUkCj AttHPWDJJZ0bcCG/gmUigQyNResF29aCN/sXwEN6PebRQw4OGZMEtMV2XduuQl9r5LOhbNrEtFrpZ JZh+lOqi49HAFEv6GWifpeIW+ND+a6SseHkIC8k4+twLhrRYgOpchcinZ8YilGZvAnF7t+/gYqgn0 U71DSWwbJUN9L1aXedh+g5umokRsxHzy0anuiolpl0C2HexnD1FgLz7dl7iKBfM4yBW4hfngVl3qb qCVzlY366GIG2kpF2dfn6vaGTThbzTBuLeK7CDYk+S0YYlLSwLo7yy3a7l2AWp0azAjTKtqIWQLKB OtkzAP0Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nVFa5-002PrJ-69; Fri, 18 Mar 2022 16:36:01 +0000 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nVFa2-002PqB-6D for linux-arm-kernel@lists.infradead.org; Fri, 18 Mar 2022 16:35:59 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3CEF932003C0; Fri, 18 Mar 2022 12:35:52 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 18 Mar 2022 12:35:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; bh=Lkir1zse4kqeDzUeV3bPm0yeNpW0sGfYaTwEzB NrcOI=; b=aXY9sk3erwxTrvmERqB3UPyYTS+vAg6ZAUdx/BBA7r6LqFGh5uQv+X zwax3XfwE2Ud2a/nhV5O4tcsqqolvqBlVmyJIu5oft67cn8Vlb8bvIwKCV5D3mnW 6T0gTvB8icrLNwaMY+C3MjcbPvgihFEchcGBnARiNmIILzRYuqypEXGuJ1numm2U Yd8hLo1np+YtYQaXUREE5ToX0ufb0/jXZNTb3fVNYfXwtWi+lC9ATRhg5BdbSiWK lStAFDT4dEtkQtZZyLOsoDW7bacJjc7uTozoq4OJuRsDB7Ch4jp7IHxBXbThQHq7 5TbXG1z7UTb++U6M58ih28v4AvhhBJfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Lkir1zse4kqeDzUeV 3bPm0yeNpW0sGfYaTwEzBNrcOI=; b=SHpuTAvv9k451GxRACDUEdiaUeVKKyeCW cBa6VOhjqdMZim7a5gbn5m9fQFl5TqH+zSStBoD4sP19tmKAsgbFuMkaD9fyYiJx CsyucB5NxdmIAPWBRx4f+57VMBuubyf+YEcRnytuLqx0tTDaJqoX7kiQHPkWM7rG 6q11lTvW+3203LUx5akNj68nl2U55VtS+V+R7xiSKsH0NW1PtitAbr3FPd7Gkkus 7AWByXqj6xVxtVLsQu/cI1eTASLnLLAt4vadTulQNpjsxkK0/EKwiIlhX75d/gxl gNec/VQDnjykAugJKKkoB698N9KWorwV3zNq4KSr714ylfc8X0awg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudefiedgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepveevfeffudeviedtgeethffhteeuffetfeffvdehvedvheetteehvdelfffg jedvnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Mar 2022 12:35:50 -0400 (EDT) Date: Fri, 18 Mar 2022 17:35:49 +0100 From: Maxime Ripard To: Max Krummenacher Cc: Marek Vasut , dri-devel@lists.freedesktop.org, Sascha Hauer , Philipp Zabel , Laurent Pinchart , Fabio Estevam , Linux ARM , DenysDrozdov , David Airlie , Christoph Niedermaier , Pengutronix Kernel Team , Sam Ravnborg , Shawn Guo , Daniel Vetter , NXP Linux Team , Max Krummenacher Subject: Re: [RFC PATCH] drm/panel: simple: panel-dpi: use bus-format to set bpc and bus_format Message-ID: <20220318163549.5a5v3lex4btnnvgb@houat> References: <20220222084723.14310-1-max.krummenacher@toradex.com> <20220223134154.oo7xhf37bgtvm3ai@houat> <20220302142142.zroy464l5etide2g@houat> <9c9a10ca-e6a1-c310-c0a5-37d4fed6efd6@denx.de> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220318_093558_304888_28D8CAF0 X-CRM114-Status: GOOD ( 38.18 ) 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: multipart/mixed; boundary="===============3227161704482180584==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============3227161704482180584== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wtrkjvqibu6qw3m4" Content-Disposition: inline --wtrkjvqibu6qw3m4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 07, 2022 at 04:26:56PM +0100, Max Krummenacher wrote: > On Wed, Mar 2, 2022 at 5:22 PM Marek Vasut wrote: > > > > On 3/2/22 15:21, Maxime Ripard wrote: > > > Hi, > > > > Hi, > > > > > Please try to avoid top posting > Sorry. >=20 > > > > > > On Wed, Feb 23, 2022 at 04:25:19PM +0100, Max Krummenacher wrote: > > >> The goal here is to set the element bus_format in the struct > > >> panel_desc. This is an enum with the possible values defined in > > >> include/uapi/linux/media-bus-format.h. > > >> > > >> The enum values are not constructed in a way that you could calculate > > >> the value from color channel width/shift/mapping/whatever. You rather > > >> would have to check if the combination of color channel > > >> width/shift/mapping/whatever maps to an existing value and otherwise > > >> EINVAL out. > > >> > > >> I don't see the value in having yet another way of how this > > >> information can be specified and then having to write a more > > >> complicated parser which maps the dt data to bus_format. > > > > > > Generally speaking, sending an RFC without explicitly stating what you > > > want a comment on isn't very efficient. > > > > Isn't that what RFC stands for -- Request For Comment ? >=20 > I hoped that the link to the original discussion was enough. >=20 > panel-simple used to have a finite number of hardcoded panels selected > by their compatible. > The following patchsets added a compatible 'panel-dpi' which should > allow to specify the panel in the device tree with timing etc. > https://patchwork.kernel.org/project/dri-devel/patch/20200216181513.281= 09-6-sam@ravnborg.org/ > In the same release cycle part of it got reverted: > https://patchwork.kernel.org/project/dri-devel/patch/20200314153047.248= 6-3-sam@ravnborg.org/ > With this it is no longer possible to set bus_format. > > The explanation what makes the use of a property "data-mapping" not a > suitable way in that revert > is a bit vague. Indeed, but I can only guess. BGR666 in itself doesn't mean much for example. Chances are the DPI interface will use a 24 bit bus, so where is the padding? I think that's what Sam and Laurent were talking about: there wasn't enough information encoded in that property to properly describe the format, hence the revert. > The RFC revert of the revert > https://patchwork.kernel.org/project/dri-devel/patch/20220201110717.358= 5-1-cniedermaier@dh-electronics.com/ > tried to get feedback what would be a way forward. This RFC tries the > same by giving a possible solution should > the property name and/or the a bit short strings of the original be > the reason why it is not suitable. >=20 > So the requested comments would be about what was not good enough with > 'data-mapping' and what would be a way forward. >=20 > Especially since in my limited view it is not clear why in panel-lvds > 'data-mapping' is used to state how the bits representing colour are > mapped to the 21 or 28 possible bit position in the LVDS lanes vs. > here where we want to say how the bits representing colour are mapped > to the 16/18/24 lines of the parallel interface would need a different > binding pattern. There's only a few data format in LVDS, so it's ok. A DPI interface is much more free-form, so you need to be a bit more accurate than what is done for LVDS. Maxime --wtrkjvqibu6qw3m4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYjS05QAKCRDj7w1vZxhR xfSvAQD6BoX/ZM1XxmLViA2wxXFC6UTgdG2lltDF7pSrIqNQngEA5uq/6+jaqyjd KPbDzm34EvO9ki73CwnPA5DucStmgAg= =giWM -----END PGP SIGNATURE----- --wtrkjvqibu6qw3m4-- --===============3227161704482180584== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============3227161704482180584==--