Nevermind that thought, presumably it's a bit more complicated than that as we aren't actually using the drm_panel API yet.
On Sat, 2020-08-01 at 18:40 +0100, David Shah wrote:
Thanks for working this one out! Seems like the "panel" bridge driver might be what we want?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
Haven't looked in detail though. I can confirm that HDMI was working fine on the uEVM with v5.7, so it is definitely a DSI-panel-specific problem.
Best
David
On Sat, 2020-08-01 at 14:51 +0200, H. Nikolaus Schaller wrote:
Hi, 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@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@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-40-laurent.pinchart@ideasonboard.comarch/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:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h...
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...
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel