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@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. :)
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
--
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
