[PATCH 02/33] HACK: drm/omap: always use blocking DMM fill
tomi.valkeinen at ti.com
Tue Feb 23 13:09:58 UTC 2016
On 23/02/16 12:27, Laurent Pinchart wrote:
> Hi Tomi,
> Thank you for the patch.
> On Friday 19 February 2016 11:47:37 Tomi Valkeinen wrote:
>> The current driver uses non-blocking DMM fill when releasing memory.
>> This gives us a small performance increase as we don't have to wait for
>> the fill operation to finish.
>> However, the driver does not have any error handling for non-blocking
>> fill. In case of an error, the fill operation may silently fail, leading
>> to leaking DMM engines, which may eventually lead to deadlock if we run
>> out of DMM engines.
>> This patch makes the DMM driver always use blocking fills, so that we
>> can catch the errors. A more complex option would be to allow
>> non-blocking fills, and implement proper error handling, but that is
>> left for the future.
>> This patch is a HACK, as the proper fix is to either decide to always
>> use sync fills and remove all the async related code, or fix the async
> Could you capture this in the comment in the source code below ? I'd also
> replace XXXX with either FIXME or TODO.
Yes, the comment was a bit lacking. Here's an updated comment:
* Asynchronous fill does not work reliably, as the driver does not
* handle errors in the async code paths. The fill operation may
* silently fail, leading to leaking DMM engines, which may eventually
* lead to deadlock if we run out of DMM engines.
* For now, always set 'wait' so that we only use sync fills. Async
* fills should be fixed, or alternatively we could decide to only
* support sync fills and so the whole async code path could be removed.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the dri-devel