On Thu, Jul 06, 2023 at 09:33:15AM +0200, Neil Armstrong wrote:
> On 06/07/2023 09:24, Maxime Ripard wrote:
> > 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?
>
> It's definitely doable, but I fear we won't be able to test most of the
> panel drivers, should we introduce a new atomic set of panel callbacks ?
That was my original intent yeah :)
Creating an atomic_enable/disable/ etc. and then switch
drm_panel_enable() to take the state (and fixing up all the callers), or
create a drm_panel_enable_atomic() function.
The latter is probably simpler, something like:
int drm_panel_enable_atomic(struct drm_panel *panel,
struct drm_atomic_state *state)
{
struct drm_panel_funcs *funcs = panel->funcs;
if (funcs->atomic_enable)
return funcs->atomic_enable(panel, state);
return funcs->enable(panel);
}
And we should probably mention that it supersedes/deprecates
drm_panel_enable.
We've switched most of the other atomic hooks to take the full
drm_atomic_state so I'd prefer to use it. However, for it to be somewhat
useful we'd need to have access to the connector assigned to that panel.
drm_panel doesn't store the drm_connector it's connected to at all, and
of_drm_find_panel() doesn't take it as an argument so we can't fill it
when we retrieve it either.
So I guess we can go for:
- Create a new set of atomic hooks
- Create a new set of functions to call those hooks, that we would
document as deprecating the former functions. Those functions would
take a pointer to the drm_connector_state of the drm_connector it's
connected to.
- We add a TODO item to add a pointer to the connector in drm_panel
- We add a TODO item that depend on the first one to switch the new
functions and hooks to drm_atomic_state
- We add a TODO item to convert callers of drm_panel_enable et al. to
our new functions.
It should work in all setups, paves a nice way forward and documents the
trade-offs we had to take and eventually address. And without creating a
dependency on 30+ patches series.
Does it sound like a plan?
> Or shall be simply move the "new" panel driver supporting atomic to bridge
> and only use panel_bridge for basic panels ?
I don't think we can expect panel_bridge to be used all the time any
time soon, so I'd rather avoid to rely on it.
Maxime
Attachment:
signature.asc
Description: PGP signature
