On Tue, Jan 23, 2018 at 7:58 AM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote:
> On Tue, Jan 23, 2018 at 12:30:58AM -0800, John Stultz wrote:
>> In trying to use the drm_hwcomposer on HiKey, I found things
>> wouldn't initialize due to the following check in
>> drm_atomic_crtc_check() failing:
>>
>> if (state->event && !state->active && !crtc->state->active) {
>> DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
>> crtc->base.id, crtc->name);
>> return -EINVAL;
>> }
>
> I think the answer is in the comment directly above this code. Having an event
> present while the crtc _stays_ off is the problem. So drm_hwc is requesting an
> event (or providing a fence) for a crtc which it does not turn on. So I think
> you should go back into hwc and find out how this situation arises.
So in this case, its providing a fence which causes the event to be set.
I'll look some more, but it seems that we call this check
(drm_atomic_check_only) before we do the commit apply the modeset that
would turn on the crtc.
Thus the check fails and we don't do the commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_atomic.c#n1659
Just commenting out the EINVAL in the snippet above causes the crtc to
start up fine.
So it seems like either the first modeset/plane update shouldn't be
done along w/ a fence, or the kernel should maybe skip setting the
event?
> AFAIK, requesting an event in a commit with both a modeset and plane update
> should work.
That's what it looks like to me too, which is why I'm confused.
thanks
-john
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
