[PATCH 02/33] HACK: drm/omap: always use blocking DMM fill

Tomi Valkeinen 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
>> code.
> 
> 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:

/*
 * FIXME
 *
 * 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.
 */

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160223/8dd16c2a/attachment.sig>


More information about the dri-devel mailing list