[Letux-kernel] LetuxOS: Kernel: bisect result for Pyra display not working since v5.7-rc1

H. Nikolaus Schaller hns at goldelico.com
Sat Aug 1 14:51:53 CEST 2020

thanks to David's reboot patch I was finally able to bisect the v5.7-rc1 display problem (no display, no /dev/fb0), because the Pyra can now run (almost) automatically and reboot unattended.

Well it still needs quite some time to make a setup. The reason is that we have to cherry-pick a minimal set of private patches on top of any bisect base commit (from linus/master) that is to be tested. And there are API changes to be tracked and worked around which influence our patch set.

Automatic bisecting also needs a script that can determine a good or bad kernel. Fortunately this is easy here since /dev/fb0 either exists or does not. so a simple ssh into the Pyra and checking for /dev/fb0 gives a "good" or "bad".

Only, if all that is set up and works properly for both, the bad and the good end, the bisect session can start.

Now, the bisect result between v5.6-rc1 and v5.7-rc1 for the display issue is:

e7e67d9a2f1dd2f938adcc219b3769f5cc3f0df7 is the first bad commit
commit e7e67d9a2f1dd2f938adcc219b3769f5cc3f0df7
Author: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Date:   Wed Feb 26 13:24:59 2020 +0200

    drm/omap: Switch the HDMI and VENC outputs to drm_bridge
    The TPD12S015, OPA362 and analog and HDMI connectors are now supported
    by DRM bridge drivers, and the omapdrm HDMI and VENC outputs can be
    handled through the drm_bridge API. Switch the outputs to drm_bridge by
    making the next bridge mandatory and removing the related
    omapdrm-specific display drivers.
    Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
    Reviewed-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
    Tested-by: Sebastian Reichel <sebastian.reichel at collabora.com>
    Reviewed-by: Sebastian Reichel <sebastian.reichel at collabora.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-40-laurent.pinchart@ideasonboard.com

 arch/arm/configs/omap2plus_defconfig               |   7 +-
 drivers/gpu/drm/omapdrm/displays/Kconfig           |  22 ---
 drivers/gpu/drm/omapdrm/displays/Makefile          |   4 -
 .../gpu/drm/omapdrm/displays/connector-analog-tv.c |  97 ---------
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  | 183 -----------------
 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c  | 137 -------------
 .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   | 217 ---------------------
 drivers/gpu/drm/omapdrm/dss/hdmi4.c                |   4 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c                |   4 +-
 drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c    |   5 -
 drivers/gpu/drm/omapdrm/dss/output.c               |   5 +
 drivers/gpu/drm/omapdrm/dss/venc.c                 |   4 +-
 12 files changed, 14 insertions(+), 675 deletions(-)
 delete mode 100644 drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
 delete mode 100644 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
 delete mode 100644 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
 delete mode 100644 drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c

Better readable:


Unfortunately it is not obvious how this breaks our MIPI DSI panel driver.

Only some files are related to this at all. Our letux_defconfig includes
all changes done to omap2plus_defconfig. Kconfig&Makefile are certainly not
the issue. drm/omapdrm/displays/* have just been removed.

So it might be a change to omapdss-boot-init.c, hdmi*.c output.c or venc.c
which requires our display driver to be updated. Changes to hdmi* and venc.c
do not look influencing MIPI DSI...

My first guess now is that the change to output.c now reqires out->bridge to
be !NULL. This may not be the case for our MIPI DSI panel and probing
is therefore deferred forever. Which is consistent with that the boe driver
is not loaded.

This would mean that a simple DSI bridge driver is missing. Maybe a stub bridge
can already help.

Room for further study in the coming days...


More information about the Letux-kernel mailing list