[RFC][PATCH 4/4 v2] drm_hwcomposer: Try to fallback if GLCompisition fails

[John Stultz]

On Tue, Feb 13, 2018 at 2:45 AM, Alexandru-Cosmin Gheorghe
<Alexandru-Cosmin.Gheorghe at arm.com> wrote:
> On Mon, Feb 12, 2018 at 08:43:10PM -0800, John Stultz wrote:
>> On Wed, Jan 31, 2018 at 11:03 AM, John Stultz <john.stultz at linaro.org> wrote:
>> > On Wed, Jan 31, 2018 at 10:51 AM, Alexandru-Cosmin Gheorghe
>> > <Alexandru-Cosmin.Gheorghe at arm.com> wrote:
>> >> It seems that we don't pass any explicit fences to the kernel for
>> >> IN_FENCE_FD property. This particular line seems wrong.
>> >>
>> >> @@ -593,14 +594,17 @@ int
>> >> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>> >>        else
>> >>          rotation |= DRM_MODE_ROTATE_0;
>> >>
>> >> -      if (fence_fd < 0) {
>> >> +      if (fence_fd >= 0) {
>> >
>> > I'll give that a whirl.
>>
>> So I did give that a whirl after you suggested it, but it ended up
>> causing nothing to be displayed, and I unfortunately didn't have time
>> right then to dig much further.
>>
>> Rob however re-found this issue today, and I've been digging a bit
>> more. At least with the HiKey board, it seem the trouble is when the
>> IN_FENCE_FD is added to the pset, the atomic commit calls start to
>> fail. I dug in and it seems we're catching in the kernel on the  if
>> (file->f_op != &sync_file_fops) check in sync_file_fdget().
>>
>> I'm now trying to trace back to where the in fence was provided from
>> to see what might be going wrong there.
> I would be surprised if this fence is not created by the GPU driver.
> But, the whole Android stack is new to me, so I might be wrong.

Yes, I went digging on this last night and it ends up the utgard
driver we use (r7p0) isn't giving us a dmabuf fence, instead we're
getting a mali_sync_fence.

There's a newer kernel driver release (r8p1), which seems to correct
this, but it also is version tied to the binary blob, which I don't
have a matching update for. I spent a bit of time trying to hack out
just the dmabuf fence bits, but it rarely boots all the way and
frequently locks the board up, so I'm probably mucking the library
driver interface in some way.

Its a well known sad song.

>> Curious if this is anything you ran across in your attempts?
> Sorry, on Hikey960, I don't have this problem. Are you using the
> same 4.9 kernel from your branch(hikey-hwcomposer-deps)?

Thanks for confirming! I'll be double checking on the hikey960 soon. I
suspect the bifrost driver is giving back the right structure if it
was working for you.

thanks
-john