[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
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>
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
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