On Tue, Jan 23, 2018 at 2:23 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
> 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?
>
I'd tend to focus more on why the crtc is not active in the new state.
Which is something that's specified in the atomic commit coming from
hwc, right?
Sean
>> 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
