[PATCH 1/2] drm/panel: Add DT bindings for Sony ACX424AKP
Rob Herring
robh at kernel.org
Mon Sep 2 15:31:41 UTC 2019
On Mon, Sep 02, 2019 at 04:40:06PM +0200, Thierry Reding wrote:
> On Mon, Sep 02, 2019 at 01:44:38PM +0200, Linus Walleij wrote:
> > On Mon, Sep 2, 2019 at 11:35 AM Thierry Reding <thierry.reding at gmail.com> wrote:
> >
> > > > + dsi-command-mode:
> > > > + type: boolean
> > > > + description:
> > > > + If this is specified, the panel will be used in command
> > > > + mode instead of video mode.
> > >
> > > I'm not sure there's concensus on this one yet. I think so far the
> > > driver decides which mode to use the panel in. Technically this falls
> > > into the category of configuration, so it doesn't really belong in the
> > > DT.
> >
> > The way we've used DT is for a bit of both hardware description
> > and configuration I'd say, but I'm no authority on the subject.
I'm okay with this if there's consensus, but it should be in a common
doc. We probably need a dsi-commom schema with this, reg, ??.
> >
> > > I vaguely recall from discussions I've had on this subject that there's
> > > usually no reason to do video mode if you can do command mode because
> > > command mode is more power efficient. This was a long time ago, so I may
> > > be misremembering. Perhaps you have different information on this?
30 or 60fps updates tend to be impossible because you have less b/w and
it's async to the refresh.
I think most panels that can do both, always need command mode too for
initialization.
> > No idea. I was under the impression that video mode was preferred
> > but I have no idea why.
>
> Hm... my recollection is that command mode is only supported on "smart"
> panels that have an internal framebuffer. So the commands actually
> instruct the panel to update their internal framebuffer, which means you
> can technically switch off the display engine when there are no updates.
>
> Under those circumstances I think it'd make sense to default to command
> mode if both the panel and the host support it and stick with video mode
> if for example the host can't do command mode.
>
> Or perhaps this is something that could be set from some userspace
> policy maker via a connector property? A compositor for instance would
> have a pretty good idea of what kind of activity is going on, so it
> could at some point decide to switch between video mode and command mode
> if one of them is more appropriate for the given workload.
>
> Command mode can also be used to do partial updates, if I remember
> correctly, which again would make it possible for a compositor to send
> only a subset of a screen update.
All makes sense to me.
Rob
More information about the dri-devel
mailing list