Op 20-12-16 om 07:23 schreef Archit Taneja: > > > On 12/19/2016 06:20 PM, Maarten Lankhorst wrote: >> Op 19-12-16 om 13:08 schreef Archit Taneja: >>> This code has been more or less picked up from the vc4 and intel >>> implementations of update_plane() funcs for cursor planes. >>> >>> The update_plane() func is usually the drm_atomic_helper_update_plane >>> func that will issue an atomic commit with the plane updates. Such >>> commits are not intended to be done faster than the vsync rate. >>> >>> The legacy cursor userspace API, on the other hand, expects the kernel >>> to handle cursor updates immediately. >>> >>> Create a fast path in update_plane, which updates the cursor registers >>> and flushes the configuration. The fast path is taken when there is only >>> a change in the cursor's position in the crtc, or a change in the >>> cursor's crop co-ordinates. For anything else, we go via the slow path. >>> >>> We take the slow path even whenever the fb changes, and even when there >>> is currently no fb tied to the plane. This should hopefully ensure that >>> we always take a slow path for every new fb. The slow path will ensure >>> that the fb is prepared/pinned etc. >>> >>> Cc: >>> Signed-off-by: Archit Taneja <architt@xxxxxxxxxxxxxx> >>> --- >>> - Don't know what to do for locking here :/ >> Shouldn't patch 9 be done first before 8? > > Patch 9 introduces cursor drm_planes for the first time, so > anything done in 8 doesn't really take effect until we add > the planes in patch 9. So it's safe to have this order. The other way around will allow you to test with the normal atomic helpers first, and then if the hack breaks you're able to bisect it correctly and revert it, that's why I think it should be the other way around. :) ~Maarten -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
