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 E689CEB64DD for ; Wed, 5 Jul 2023 16:54:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231252AbjGEQyD (ORCPT ); Wed, 5 Jul 2023 12:54:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60662 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229700AbjGEQyC (ORCPT ); Wed, 5 Jul 2023 12:54:02 -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 2913F10C3; Wed, 5 Jul 2023 09:54:01 -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 8C2E961617; Wed, 5 Jul 2023 16:54:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70C1BC433C7; Wed, 5 Jul 2023 16:53:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688576039; bh=zpe36HvtOC/2p5wIUyWgUxwi/FgRT6PIqt/x3SW+BlU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Lhcjd5O0YYRww4U/sAWx3osP7tPsKy2GtadQHpt8Xvd68qxHov1MBqb1hvExtYqmu 57pCmTMtoeH7+YoKCjhGqsrRwf3AuApbNcSOi2IuKIDkLlPqCgBKrrcQVY3BbkNDBl 7fE6teIAijQKdKAFQkay4mC1IMCS9wgNUBQIgd0k4PoYbeoNRIuSxBC9Lf3t08ZeSK QY0GzCPdtabD0qZxBHcefUWAgp4FSjPNMFflYi9BasI5oPFwwAC1lO89UwdNP/hd9S aNOpsq+nn+dYqke0EHIJDsIkS8SKct8S9SJRKMjFaioHyndCXqukQNDCgwE0xlwhuL bE0J0klj4h8oA== Date: Wed, 5 Jul 2023 18:53:57 +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="a5bose7t54notcfz" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org --a5bose7t54notcfz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote: > On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote: > > > > 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. > > > > > > > > > > Except some panels supports DSC & non-DSC, Video and Command mode= , and > > > > > all that is runtime configurable. How do you handle that ? > > > > > > > > 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 i= t, > > > > and thus we still don't really need to expose the host capabilities. > > > > > > This is an interesting perspective. This means that we can and actual= ly have > > > 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 sho= uld > > > export several modes: > > > > > > 1920x1080-command > > > 1920x1080-command-DSC > > > 1920x1080-video > > > 1920x1080-video-DSC > > > > > > where video/command and DSC are some kinds of flags and/or informatio= n in > > > the drm_display_mode? Ideally DSC also has several sub-flags, which d= enote > > > what kind of configuration is supported by the DSC sink (e.g. bpp, yu= v, > > > 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. >=20 > This is definitely something we need. Marijn has been stuck with the > panels that support different models ([1]). >=20 > Would you prefer a separate API for this kind of information or > abusing atomic_enable() is fine from your point of view? >=20 > My vote would be for going with existing operations, with the slight > fear of ending up with another DSI-specific hack (like > pre_enable_prev_first). I don't think we can get away without getting access to the atomic_state =66rom the panel at least. Choosing one setup over another is likely going to depend on the mode, and that's only available in the state. We don't have to go the whole way though and create the sub-classes of drm_connector_state, but I think we should at least provide it to the panel. What do you think of creating a new set of atomic_* callbacks for panels, call that new set of functions from msm and start from there? Maxime --a5bose7t54notcfz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZKWgJQAKCRDj7w1vZxhR xQatAP90pD1NWuIrbVbvIO18HW7Hgb8Mr+kSmow/0XcZKKtjowEA01wiFrcPQBdZ 3zxMfQ8Rm5KcDNCKe6hW3cZCvQ+t+gw= =EWmy -----END PGP SIGNATURE----- --a5bose7t54notcfz-- 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 63A65C001DE for ; Wed, 5 Jul 2023 16:54:04 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6ED5210E180; Wed, 5 Jul 2023 16:54:03 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by gabe.freedesktop.org (Postfix) with ESMTPS id 91FD110E180; Wed, 5 Jul 2023 16:54:01 +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 8EEE761628; Wed, 5 Jul 2023 16:54:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70C1BC433C7; Wed, 5 Jul 2023 16:53:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688576039; bh=zpe36HvtOC/2p5wIUyWgUxwi/FgRT6PIqt/x3SW+BlU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Lhcjd5O0YYRww4U/sAWx3osP7tPsKy2GtadQHpt8Xvd68qxHov1MBqb1hvExtYqmu 57pCmTMtoeH7+YoKCjhGqsrRwf3AuApbNcSOi2IuKIDkLlPqCgBKrrcQVY3BbkNDBl 7fE6teIAijQKdKAFQkay4mC1IMCS9wgNUBQIgd0k4PoYbeoNRIuSxBC9Lf3t08ZeSK QY0GzCPdtabD0qZxBHcefUWAgp4FSjPNMFflYi9BasI5oPFwwAC1lO89UwdNP/hd9S aNOpsq+nn+dYqke0EHIJDsIkS8SKct8S9SJRKMjFaioHyndCXqukQNDCgwE0xlwhuL bE0J0klj4h8oA== Date: Wed, 5 Jul 2023 18:53:57 +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="a5bose7t54notcfz" 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: "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" --a5bose7t54notcfz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote: > On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote: > > > > 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. > > > > > > > > > > Except some panels supports DSC & non-DSC, Video and Command mode= , and > > > > > all that is runtime configurable. How do you handle that ? > > > > > > > > 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 i= t, > > > > and thus we still don't really need to expose the host capabilities. > > > > > > This is an interesting perspective. This means that we can and actual= ly have > > > 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 sho= uld > > > export several modes: > > > > > > 1920x1080-command > > > 1920x1080-command-DSC > > > 1920x1080-video > > > 1920x1080-video-DSC > > > > > > where video/command and DSC are some kinds of flags and/or informatio= n in > > > the drm_display_mode? Ideally DSC also has several sub-flags, which d= enote > > > what kind of configuration is supported by the DSC sink (e.g. bpp, yu= v, > > > 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. >=20 > This is definitely something we need. Marijn has been stuck with the > panels that support different models ([1]). >=20 > Would you prefer a separate API for this kind of information or > abusing atomic_enable() is fine from your point of view? >=20 > My vote would be for going with existing operations, with the slight > fear of ending up with another DSI-specific hack (like > pre_enable_prev_first). I don't think we can get away without getting access to the atomic_state =66rom the panel at least. Choosing one setup over another is likely going to depend on the mode, and that's only available in the state. We don't have to go the whole way though and create the sub-classes of drm_connector_state, but I think we should at least provide it to the panel. What do you think of creating a new set of atomic_* callbacks for panels, call that new set of functions from msm and start from there? Maxime --a5bose7t54notcfz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZKWgJQAKCRDj7w1vZxhR xQatAP90pD1NWuIrbVbvIO18HW7Hgb8Mr+kSmow/0XcZKKtjowEA01wiFrcPQBdZ 3zxMfQ8Rm5KcDNCKe6hW3cZCvQ+t+gw= =EWmy -----END PGP SIGNATURE----- --a5bose7t54notcfz--