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].
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?
Kind regards, Stefan Birkholz
On Tue, Aug 11, 2020 at 5:07 PM Stefan Birkholz Birkholz@systecnet.com wrote:
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
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@ffwll.ch] Gesendet: Dienstag, 11. August 2020 17:17 An: Stefan Birkholz Birkholz@systecnet.com Cc: Philipp Zabel p.zabel@pengutronix.de; dri-devel@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@systecnet.com wrote:
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
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On Tue, 2020-08-11 at 14:50 +0000, Stefan Birkholz wrote:
The only call in imx_pd_bind() I would expect to return -EPROBE_DEFER is drm_of_find_panel_or_bridge(), maybe parallel-display node's port@1 is connected to a panel that is not registered. Are the drivers for the panel and all its dependencies (power supply regulator, backlight) enabled and probed?
regards Philipp
On the working system I get: [ 3.359749] pwm-backlight backlight: Linked as a consumer to regulator.7 [ 8.789867] panel-lvds panel: Linked as a consumer to regulator.8
Non-working: [ 3.362822] pwm-backlight backlight: Linked as a consumer to regulator.7 [ 3.362907] pwm-backlight backlight: Dropping the link to regulator.7 [ 5.441029] pwm-backlight backlight: Linked as a consumer to regulator.7 [ 5.447941] pwm-backlight backlight: Dropping the link to regulator.7 ... [ 8.810651] panel-lvds panel: Linked as a consumer to regulator.8 [ 8.816878] panel-lvds panel: Dropping the link to regulator.8 [ 8.976370] panel-lvds panel: Linked as a consumer to regulator.8 [ 9.063164] panel-lvds panel: Dropping the link to regulator.8 [ 9.208480] panel-lvds panel: Linked as a consumer to regulator.8 [ 9.214729] panel-lvds panel: Dropping the link to regulator.8
You are right, I didn't notice that before! Thank you for having a look!
Regards, Stefan
On Tue, 2020-08-11 at 14:50 +0000, Stefan Birkholz wrote:
The only call in imx_pd_bind() I would expect to return -EPROBE_DEFER is drm_of_find_panel_or_bridge(), maybe parallel-display node's port@1 is connected to a panel that is not registered. Are the drivers for the panel and all its dependencies (power supply regulator, backlight) enabled and probed?
regards Philipp
dri-devel@lists.freedesktop.org