On 12/20/2016 07:10 PM, Maarten Lankhorst wrote: > 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 at codeaurora.org> >>>> --- >>>> - 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. :)
Yeah, makes sense when you put it that way :). Will make sure the hack commit comes after the cursor planes are supported the regular atomic way. Archit > > ~Maarten > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
