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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
