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

From: Andreas Kemnade <andreas@kemnade.info>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: kernel@collabora.com, Tony Lindgren <tony@atomide.com>,
	"H. Nikolaus Schaller" <hns@goldelico.com>,
	Merlijn Wajer <merlijn@wizzup.org>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	dri-devel@lists.freedesktop.org,
	Sebastian Reichel <sre@kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	linux-omap@vger.kernel.org
Subject: Re: [RFCv1 33/42] drm/omap: dsi: use atomic helper for dirtyfb
Date: Tue, 19 Nov 2019 19:46:28 +0100	[thread overview]
Message-ID: <20191119194628.7709b1fe@aktux> (raw)
In-Reply-To: <46aba805-1d3a-2efc-23f6-d957bf6a44c3@ti.com>

On Tue, 19 Nov 2019 17:55:57 +0200
Tomi Valkeinen <tomi.valkeinen@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel