On 05/07/2023 16: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 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.
Yep this looks like a good plan
Neil
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.
Maxime
