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@xxxxxxxxx> 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
