[RFCv1 33/42] drm/omap: dsi: use atomic helper for dirtyfb

[Andreas Kemnade]

On Tue, 19 Nov 2019 17:55:57 +0200
Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:

> On 19/11/2019 17:06, Tony Lindgren wrote:
> 
> >> The userspace apps need to do this. If they're using single-buffering, then
> >> using the dirtyfb ioctl should do the trick, after the SGX has finished
> >> drawing.  
> > 
> > Sounds like that's not happening.
> > 
> > But why would the userspace app need to know this might be needed for
> > a DSI command mode display and that it's not needed for HDMI?  
> 
> When double-buffering, the userspace doesn't need to care, as the 
> page-flip ioctl explicitly tells that the buffer is ready.
> 
> When single buffering, either the userspace has to tell that the buffer 
> is now ready, or the kernel has to guess based on something. But afaics, 
> the latter is always a guess, and may not be a good guess.
> 
> The kernel could trigger a delayed update based on, say, page fault if 
> drawing with CPU. But how much delayed... And with this scenario, we 
> would somehow need to find a way to catch the writes from any IP to the 
> buffer, and afaik there's no such thing.
> 
> >> It's probably somewhat difficult if EGL is controlling the display, as,
> >> afaik, SGX EGL is closed source, and that's probably where it should be
> >> done.
> >>
> >> But adding back the hacky omap gem sync stuff, and then somehow guessing
> >> from the sync finish that some display needs to be updated... It just does
> >> not sound right to me.  
> > 
> > Right it's ugly. Still sounds like we need something in the kernel
> > that knows "this is a DSI command mode LCD and needs to be updated".  
> 
well, if we look broader around and not only at the remaining displays
to be converted from omapdrm to generic and look at more displays, there
are also EPDs.

> I think one option is to refresh the command mode display all the time. 
> Either using a timer, or trigger updates based on the previous update 
> being finished.
> 
> Of course, that's kind of against the whole point of manual update 
> display, but then it should effectively behave like a conventional 
> always-updating display (except your HW is more expensive and consumes 
> more power than a conventional display).
> 
And again as an extreme example about power consumption: EPDs.
So I guess we need a generic interface for userspace-triggered
refreshes anyways. And in that case that are only partly refreshes.

Regards,
Andreas