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 94041EB64DD for ; Wed, 5 Jul 2023 14:24:56 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BBEB410E375; Wed, 5 Jul 2023 14:24:55 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by gabe.freedesktop.org (Postfix) with ESMTPS id BBF2610E375; Wed, 5 Jul 2023 14:24:53 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 132C76159F; Wed, 5 Jul 2023 14:24:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F4061C433C8; Wed, 5 Jul 2023 14:24:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688567092; bh=b4T3vn8kUIesSYDyBrDxM+Xd4flNAla2ptcHctnOz3M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kL3h2m+KfHxmeb+EDxQeM6WzEklBm9lA8n9NV/hKmczejEZaDq0P3LKU+3/vLI15P 9OHzCa9VxKsubz4dd/Y0C89/upnfVqBNV7H5l8qZ0HnKlLe/kerspdmAwVCG0x917q lAirmN5Tzao7sBNDfiC4mOkOGL5d1ZI5j/rr1SBqyF+wlPDn2YmDD9NBRqtOt7CwVG 4/Pp7pU2vlaYx6ljtM+5w3p6YrPzTgyEBE5kU92VVaJilSYJyuVGRGscwb/uTVo2S6 KiTMTasEY5z+GnI+xJ73tTLgBJPH8WQVVSUiXE6su5JEN0Xs67sEUXN0HTLyZVz4yP +sX8rmG6eStig== Date: Wed, 5 Jul 2023 16:24:49 +0200 From: Maxime Ripard To: Dmitry Baryshkov Subject: Re: RFC: DSI host capabilities (was: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3) Message-ID: References: <617c8f8a-1fc7-c6a0-eaa5-ce75ff2adc1b@linaro.org> <739a8bd9-9ff0-5072-fdae-b64efdf86842@collabora.com> <47a5678c-1eb3-dfc2-a9ac-f8e497455d11@linaro.org> <6e070141-8c0e-59ed-8a08-58c3fadb17df@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ee54vq7zgkfrit3g" Content-Disposition: inline In-Reply-To: <6e070141-8c0e-59ed-8a08-58c3fadb17df@linaro.org> 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: "open list:DRM DRIVER FOR MSM ADRENO GPU" , Caleb Connolly , Krzysztof Kozlowski , AngeloGioacchino Del Regno , Marijn Suijten , Sam Ravnborg , Kuogee Hsieh , Andy Gross , Jessica Zhang , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Conor Dooley , "open list:DRM DRIVER FOR MSM ADRENO GPU" , Abhinav Kumar , Rob Herring , Martin Botka , ~postmarketos/upstreaming@lists.sr.ht, AngeloGioacchino Del Regno , Neil Armstrong , Jami Kettunen , Bjorn Andersson , open list , Konrad Dybcio , freedreno Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --ee54vq7zgkfrit3g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote: > > > > > > > > Either way, I'm not really sure it's a good idea to multiply the > > > > capabilities flags of the DSI host, and we should just stick to the > > > > spec. If the spec says that we have to support DSC while video is > > > > output, then that's what the panels should expect. > > >=20 > > > Except some panels supports DSC & non-DSC, Video and Command mode, and > > > all that is runtime configurable. How do you handle that ? > >=20 > > In this case, most of the constraints are going to be on the encoder > > still so it should be the one driving it. The panel will only care about > > which mode has been selected, but it shouldn't be the one driving it, > > and thus we still don't really need to expose the host capabilities. >=20 > This is an interesting perspective. This means that we can and actually h= ave > to extend the drm_display_mode with the DSI data and compression > information. I wouldn't extend drm_display_mode, but extending one of the state structures definitely. We already have some extra variables in drm_connector_state for HDMI, I don't think it would be a big deal to add a few for MIPI-DSI. We also floated the idea for a while to create bus-specific states, with helpers to match. Maybe it would be a good occasion to start doing it? > For example, the panel that supports all four types for the 1080p should > export several modes: >=20 > 1920x1080-command > 1920x1080-command-DSC > 1920x1080-video > 1920x1080-video-DSC > > where video/command and DSC are some kinds of flags and/or information in > the drm_display_mode? Ideally DSC also has several sub-flags, which denote > what kind of configuration is supported by the DSC sink (e.g. bpp, yuv, > etc). So we have two things to do, right? We need to expose what the panel can take (ie, EDID for HDMI), and then we need to tell it what we picked (infoframes). We already express the former in mipi_dsi_device, so we could extend the flags stored there. And then, we need to tie what the DSI host chose to a given atomic state so the panel knows what was picked and how it should set everything up. > Another option would be to get this handled via the bus format negotiatio= n, > but that sounds like worse idea to me. Yeah, I'm not really fond of the format negociation stuff either. Maxime --ee54vq7zgkfrit3g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZKV9MQAKCRDj7w1vZxhR xSs7AQCC8eWrt4gxYNxVJGe1FnjK6alg2IQI4jyWNyUnc7bBNgD+PJHSXUPBnb+n +z33D23kQsS5sBnGpgFWmyznIOmGJA0= =evV5 -----END PGP SIGNATURE----- --ee54vq7zgkfrit3g-- 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5EBA1EB64DD for ; Wed, 5 Jul 2023 14:26:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232538AbjGEOZ5 (ORCPT ); Wed, 5 Jul 2023 10:25:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232633AbjGEOZl (ORCPT ); Wed, 5 Jul 2023 10:25:41 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 19D75171B; Wed, 5 Jul 2023 07:24:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 19BE2615AA; Wed, 5 Jul 2023 14:24:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F4061C433C8; Wed, 5 Jul 2023 14:24:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688567092; bh=b4T3vn8kUIesSYDyBrDxM+Xd4flNAla2ptcHctnOz3M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kL3h2m+KfHxmeb+EDxQeM6WzEklBm9lA8n9NV/hKmczejEZaDq0P3LKU+3/vLI15P 9OHzCa9VxKsubz4dd/Y0C89/upnfVqBNV7H5l8qZ0HnKlLe/kerspdmAwVCG0x917q lAirmN5Tzao7sBNDfiC4mOkOGL5d1ZI5j/rr1SBqyF+wlPDn2YmDD9NBRqtOt7CwVG 4/Pp7pU2vlaYx6ljtM+5w3p6YrPzTgyEBE5kU92VVaJilSYJyuVGRGscwb/uTVo2S6 KiTMTasEY5z+GnI+xJ73tTLgBJPH8WQVVSUiXE6su5JEN0Xs67sEUXN0HTLyZVz4yP +sX8rmG6eStig== Date: Wed, 5 Jul 2023 16:24:49 +0200 From: Maxime Ripard To: Dmitry Baryshkov Cc: Neil Armstrong , AngeloGioacchino Del Regno , "open list:DRM DRIVER FOR MSM ADRENO GPU" , Caleb Connolly , Krzysztof Kozlowski , AngeloGioacchino Del Regno , Marijn Suijten , Sam Ravnborg , Kuogee Hsieh , Andy Gross , Jessica Zhang , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Conor Dooley , "open list:DRM DRIVER FOR MSM ADRENO GPU" , Abhinav Kumar , Rob Herring , Martin Botka , ~postmarketos/upstreaming@lists.sr.ht, Jami Kettunen , Bjorn Andersson , open list , Konrad Dybcio , freedreno Subject: Re: RFC: DSI host capabilities (was: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3) Message-ID: References: <617c8f8a-1fc7-c6a0-eaa5-ce75ff2adc1b@linaro.org> <739a8bd9-9ff0-5072-fdae-b64efdf86842@collabora.com> <47a5678c-1eb3-dfc2-a9ac-f8e497455d11@linaro.org> <6e070141-8c0e-59ed-8a08-58c3fadb17df@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ee54vq7zgkfrit3g" Content-Disposition: inline In-Reply-To: <6e070141-8c0e-59ed-8a08-58c3fadb17df@linaro.org> Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org --ee54vq7zgkfrit3g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote: > > > > > > > > Either way, I'm not really sure it's a good idea to multiply the > > > > capabilities flags of the DSI host, and we should just stick to the > > > > spec. If the spec says that we have to support DSC while video is > > > > output, then that's what the panels should expect. > > >=20 > > > Except some panels supports DSC & non-DSC, Video and Command mode, and > > > all that is runtime configurable. How do you handle that ? > >=20 > > In this case, most of the constraints are going to be on the encoder > > still so it should be the one driving it. The panel will only care about > > which mode has been selected, but it shouldn't be the one driving it, > > and thus we still don't really need to expose the host capabilities. >=20 > This is an interesting perspective. This means that we can and actually h= ave > to extend the drm_display_mode with the DSI data and compression > information. I wouldn't extend drm_display_mode, but extending one of the state structures definitely. We already have some extra variables in drm_connector_state for HDMI, I don't think it would be a big deal to add a few for MIPI-DSI. We also floated the idea for a while to create bus-specific states, with helpers to match. Maybe it would be a good occasion to start doing it? > For example, the panel that supports all four types for the 1080p should > export several modes: >=20 > 1920x1080-command > 1920x1080-command-DSC > 1920x1080-video > 1920x1080-video-DSC > > where video/command and DSC are some kinds of flags and/or information in > the drm_display_mode? Ideally DSC also has several sub-flags, which denote > what kind of configuration is supported by the DSC sink (e.g. bpp, yuv, > etc). So we have two things to do, right? We need to expose what the panel can take (ie, EDID for HDMI), and then we need to tell it what we picked (infoframes). We already express the former in mipi_dsi_device, so we could extend the flags stored there. And then, we need to tie what the DSI host chose to a given atomic state so the panel knows what was picked and how it should set everything up. > Another option would be to get this handled via the bus format negotiatio= n, > but that sounds like worse idea to me. Yeah, I'm not really fond of the format negociation stuff either. Maxime --ee54vq7zgkfrit3g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZKV9MQAKCRDj7w1vZxhR xSs7AQCC8eWrt4gxYNxVJGe1FnjK6alg2IQI4jyWNyUnc7bBNgD+PJHSXUPBnb+n +z33D23kQsS5sBnGpgFWmyznIOmGJA0= =evV5 -----END PGP SIGNATURE----- --ee54vq7zgkfrit3g--