On Tue, Jan 23, 2018 at 12:44 PM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote:
> 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?
Ah. Sounds like I've been mixing up the kernel's state of the hardware
with the requested state to be committed.
Many thanks for the clarification. I'll dig a bit further.
thanks
-john
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
