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

From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: kernel@collabora.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 17:55:57 +0200	[thread overview]
Message-ID: <46aba805-1d3a-2efc-23f6-d957bf6a44c3@ti.com> (raw)
In-Reply-To: <20191119150643.GI35479@atomide.com>

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".

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).

There's this Panel Self Refresh feature in DisplayPort (which I think is 
implemented in drm_self_refresh_helper.c), which has some similarities 
to this case. But if I read it right, that also expects some kind of 
trigger from userspace (any DRM commit) to start the refresh.

Afaik, Weston and X both handle page flips and/or dirtying the fb, so 
they should work. Are there applications that do not work, and cannot be 
made to work, except the few SGX test apps?

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel