From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
"open list:DRM DRIVER FOR MSM ADRENO GPU"
<dri-devel@lists.freedesktop.org>,
Caleb Connolly <caleb@connolly.tech>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@somainline.org>,
Marijn Suijten <marijn.suijten@somainline.org>,
Sam Ravnborg <sam@ravnborg.org>,
Kuogee Hsieh <quic_khsieh@quicinc.com>,
Andy Gross <agross@kernel.org>,
Jessica Zhang <quic_jesszhan@quicinc.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, Conor Dooley <conor+dt@kernel.org>,
"open list:DRM DRIVER FOR MSM ADRENO GPU"
<linux-arm-msm@vger.kernel.org>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Rob Herring <robh+dt@kernel.org>,
Martin Botka <martin.botka@somainline.org>,
~postmarketos/upstreaming@lists.sr.ht,
Jami Kettunen <jami.kettunen@somainline.org>,
Bjorn Andersson <andersson@kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
freedreno <freedreno@lists.freedesktop.org>
Subject: Re: RFC: DSI host capabilities (was: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3)
Date: Wed, 5 Jul 2023 18:20:13 +0300 [thread overview]
Message-ID: <CAA8EJpq_VeY=44FqYm7QAT32AR=rmMOV0RtAfNFkb1hpSp29dw@mail.gmail.com> (raw)
In-Reply-To: <lidknise4copce3vb2wth4z3fl2p4npsc4u6ajqb6zsp6lnpca@rp6wxcmy2aa4>
On Wed, 5 Jul 2023 at 17:24, Maxime Ripard <mripard@kernel.org> 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 it,
> > > and thus we still don't really need to expose the host capabilities.
> >
> > This is an interesting perspective. This means that we can and actually 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 should
> > 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 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.
This is definitely something we need. Marijn has been stuck with the
panels that support different models ([1]).
Would you prefer a separate API for this kind of information or
abusing atomic_enable() is fine from your point of view?
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).
>
> > Another option would be to get this handled via the bus format negotiation,
> > but that sounds like worse idea to me.
>
> Yeah, I'm not really fond of the format negociation stuff either.
[1] https://lore.kernel.org/linux-arm-msm/20230521-drm-panels-sony-v1-8-541c341d6bee@somainline.org/
--
With best wishes
Dmitry
next prev parent reply other threads:[~2023-07-05 15:20 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-21 21:23 [PATCH RFC 00/10] drm/panel: Drivers for four Sony CMD-mode (and DSC) panels Marijn Suijten
2023-05-21 21:23 ` [PATCH RFC 01/10] drm/panel: Clean up SOFEF00 config dependencies Marijn Suijten
2023-05-22 9:01 ` Neil Armstrong
2023-05-28 22:00 ` Caleb Connolly
2023-05-21 21:23 ` [PATCH RFC 02/10] dt-bindings: display: panel: Describe Sony Xperia XZ3's LGD panel Marijn Suijten
2023-05-22 0:10 ` Dmitry Baryshkov
2023-05-21 21:23 ` [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3 Marijn Suijten
2023-05-22 1:16 ` Dmitry Baryshkov
2023-05-22 9:04 ` Neil Armstrong
2023-05-22 12:58 ` Dmitry Baryshkov
2023-05-29 21:07 ` Marijn Suijten
2023-05-29 22:18 ` Dmitry Baryshkov
2023-05-29 22:37 ` Marijn Suijten
2023-05-29 22:39 ` Dmitry Baryshkov
2023-05-30 8:27 ` Marijn Suijten
2023-05-30 11:11 ` Dmitry Baryshkov
2023-05-30 18:19 ` Marijn Suijten
2023-05-30 17:54 ` Abhinav Kumar
2023-05-30 18:13 ` Marijn Suijten
2023-05-30 23:16 ` Dmitry Baryshkov
2023-05-29 21:11 ` Marijn Suijten
2023-05-29 22:17 ` Dmitry Baryshkov
2023-05-29 22:36 ` Dmitry Baryshkov
2023-05-30 7:24 ` Neil Armstrong
2023-05-30 8:41 ` Marijn Suijten
2023-05-30 9:29 ` Konrad Dybcio
2023-05-30 11:44 ` RFC: DSI host capabilities (was: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3) Dmitry Baryshkov
2023-05-30 12:15 ` AngeloGioacchino Del Regno
2023-05-30 12:36 ` Dmitry Baryshkov
2023-05-30 15:44 ` Neil Armstrong
2023-05-31 8:02 ` AngeloGioacchino Del Regno
2023-07-05 12:04 ` Maxime Ripard
2023-07-05 13:05 ` Neil Armstrong
2023-07-05 13:29 ` Maxime Ripard
2023-07-05 13:37 ` Dmitry Baryshkov
2023-07-05 14:24 ` Maxime Ripard
2023-07-05 15:20 ` Dmitry Baryshkov [this message]
2023-07-05 16:53 ` Maxime Ripard
2023-07-05 20:09 ` Dmitry Baryshkov
2023-07-06 7:24 ` Maxime Ripard
2023-07-06 7:33 ` Neil Armstrong
2023-07-06 7:59 ` Maxime Ripard
2023-07-06 8:03 ` Neil Armstrong
2023-07-05 15:58 ` Neil Armstrong
2023-05-21 21:23 ` [PATCH RFC 04/10] arm64: dts: qcom: sdm845-akatsuki: Configure OLED panel Marijn Suijten
2023-05-21 21:23 ` [PATCH RFC 05/10] dt-bindings: display: panel: Describe Samsung SOFEF01-M Display-IC Marijn Suijten
2023-05-21 22:23 ` Rob Herring
2023-05-21 21:23 ` [PATCH RFC 06/10] drm/panel/samsung-sofef01: Add panel driver for Sony Xperia 5 / 10 II Marijn Suijten
2023-05-22 1:19 ` Dmitry Baryshkov
2023-05-22 16:30 ` Konrad Dybcio
2023-05-22 22:38 ` Marijn Suijten
2023-05-22 22:32 ` Marijn Suijten
2023-05-22 22:56 ` Dmitry Baryshkov
2023-05-29 20:58 ` Marijn Suijten
2023-05-29 22:20 ` Dmitry Baryshkov
2023-05-29 22:35 ` Marijn Suijten
2023-05-21 21:23 ` [PATCH RFC 07/10] dt-bindings: display: panel: Describe Samsung SOFEF03-M Display-IC Marijn Suijten
2023-06-08 19:43 ` Rob Herring
2023-05-21 21:23 ` [PATCH RFC 08/10] drm/panel/samsung-sofef03: Add panel driver for Sony Xperia 5 II Marijn Suijten
2023-05-22 1:23 ` Dmitry Baryshkov
2023-05-22 9:08 ` Neil Armstrong
2023-05-22 12:57 ` Dmitry Baryshkov
2023-05-29 21:21 ` Marijn Suijten
2023-05-29 21:29 ` Konrad Dybcio
2023-05-29 22:22 ` Dmitry Baryshkov
2023-05-29 22:33 ` Marijn Suijten
2023-05-22 16:31 ` Konrad Dybcio
2023-05-21 21:23 ` [PATCH RFC 09/10] dt-bindings: display: panel: Describe Sony Xperia 1 display Marijn Suijten
2023-05-21 22:23 ` Rob Herring
2023-05-21 21:23 ` [PATCH RFC 10/10] drm/panel/sony-griffin-samsung: Add panel driver for Sony Xperia 1 Marijn Suijten
2023-06-28 9:22 ` Linus Walleij
2023-06-28 14:20 ` Marijn Suijten
2023-06-28 19:18 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA8EJpq_VeY=44FqYm7QAT32AR=rmMOV0RtAfNFkb1hpSp29dw@mail.gmail.com' \
--to=dmitry.baryshkov@linaro.org \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=angelogioacchino.delregno@somainline.org \
--cc=caleb@connolly.tech \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jami.kettunen@somainline.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=martin.botka@somainline.org \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_jesszhan@quicinc.com \
--cc=quic_khsieh@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=sam@ravnborg.org \
--cc=~postmarketos/upstreaming@lists.sr.ht \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).