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

From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Andreas Kemnade <andreas@kemnade.info>
Cc: kernel@collabora.com, Tony Lindgren <tony@atomide.com>,
	"H. Nikolaus Schaller" <hns@goldelico.com>,
	Merlijn Wajer <merlijn@wizzup.org>,
	dri-devel@lists.freedesktop.org,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	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 22:15:06 +0100	[thread overview]
Message-ID: <20191119211506.pvcnmgrfy5wa7kkf@earth.universe> (raw)
In-Reply-To: <20191119194628.7709b1fe@aktux>

[-- Attachment #1.1: Type: text/plain, Size: 3203 bytes --]

Hi,

On Tue, Nov 19, 2019 at 07:46:28PM +0100, Andreas Kemnade wrote:
> 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.

You can do exactly this using the dirtyfb ioctl, which tells the
kernel, that some parts of the framebuffer are "dirty" and should
be send to the hardware. This is being used by the kernel console
and X.org. For omapdrm this triggers a full refresh of DSI command
mode panels.

The second method (which only supports full framebuffer for obvious
reasons) is double buffering. If you toggle from first to second
framebuffer, the driver will send the framebuffer to hardware. This
is being used by Weston when the DRM backend is selected.

-- Sebastian

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel