On Wed, Jul 05, 2023 at 11:09:40PM +0300, Dmitry Baryshkov wrote: > On 05/07/2023 19:53, Maxime Ripard wrote: > > On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote: > > > On Wed, 5 Jul 2023 at 17:24, Maxime Ripard <mripard@xxxxxxxxxx> 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). > > > > I don't think we can get away without getting access to the atomic_state > > from 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? > > We are (somewhat) bound by the panel_bridge, but yeah, it seems possible. Bridges have access to the atomic state already, so it's another place to plumb this through but I guess it would still be doable? Maxime
Attachment:
signature.asc
Description: PGP signature
