AW: imx-drm: master bind failed: -517 with parallel_display (on i.MX6DL)

[Stefan Birkholz]

Hi Daniel,

actually git bisection yielded two subsequent commits 5bf7295fe34a525 and 80acbed9f8fca1db3f, both were bad, but I wasn't clear about what changed in the imx-drm subsystem in those commits; bisection stopped then. I noticed there was a transition from using <drm/drm_crtc_helper.h> to <drm/drm_atomic_helper.h> in that timespan, but I didn't want to assume that's the source of the problem. 

Regards,
 Stefan

-----Ursprüngliche Nachricht-----
Von: Daniel Vetter [mailto:daniel at ffwll.ch] 
Gesendet: Dienstag, 11. August 2020 17:17
An: Stefan Birkholz <Birkholz at systecnet.com>
Cc: Philipp Zabel <p.zabel at pengutronix.de>; dri-devel at lists.freedesktop.org
Betreff: Re: imx-drm: master bind failed: -517 with parallel_display (on i.MX6DL)

On Tue, Aug 11, 2020 at 5:07 PM Stefan Birkholz <Birkholz at systecnet.com> wrote:
>
> Hello,
>
> we are using the mainline kernel (currently on 4.19.128) successfully on an i.MX6DL-based system, but when we try to upgrade to any more recent kernel (>5.1) the display output stops working (screen is blank, backlight works).
>
> The relevant entries from the kernel log seem to be:
> [    8.954942] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops imx_drm_exit [imxdrm])
> [    9.028406] imx-drm display-subsystem: failed to bind disp0 (ops imx_pd_ops [parallel_display]): -517
> [    9.037873] imx-drm display-subsystem: master bind failed: -517
>
> (I can reproduce those by un-/reloading the parallel-display.ko 
> module.)
>
> On a working 4.19.128 the corresponding entries are:
> [    8.879050] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops imx_drm_exit [imxdrm])
> [    8.887361] imx-drm display-subsystem: bound disp0 (ops imx_pd_ops [parallel_display])
> [    9.131288] imx-drm display-subsystem: fb0: DRM emulated frame buffer device
> [    9.139618] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 2
>
> Via git bisection I found the last "good" commit at [044175a06706d516aa42874bb44dbbfc3c4d20eb], and the next "bad" commit at [228cd2dba27cee9956c1af97e6445be056881e41].

There's over 8k commits in that range, what's the reason git bisect didn't continue to further drill down into what the bad commit is?
This range contains an entire drm merge window pull request, so pretty hard to guess what broke.

> I tested both these versions with exactly the same .dtb and our .config (adapted via "make olddefconfig" for both versions) from the 4.19.128 kernel.
>
> Do you have any suggestions what we can do to try and fix this problem?

Further reducing the range of suspect commits should help. Maybe imx maintainers have some guess, but I definitely don't have much idea what's missing among that big a pile of commits.

Thanks, Daniel

>
> Kind regards,
>  Stefan Birkholz
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch