Re: module_mipi_dsi_driver panel with omapdrm?

[Sebastian Reichel <sebastian.reichel@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 3499 bytes --]

Hi,

On Wed, Aug 05, 2020 at 11:25:58AM +0200, H. Nikolaus Schaller wrote:
> > Am 04.08.2020 um 14:43 schrieb Tomi Valkeinen <tomi.valkeinen@ti.com>:
> > On 01/08/2020 16:43, H. Nikolaus Schaller wrote:
> >> Fortunately David did fix the broken "reboot" for OMAP5 (when using timer8).
> >> Now I could run an unattended bisect session for the MIPI DSI panel driver
> >> to find as 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
> >> 
> >> This was merged through v5.7-rc1. The problem persists since then up
> >> to v5.8-rc7 and likely also to v5.9.
> >> 
> >> What I guess from the change hunks is that this is the critical one:
> >> 
> >> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c b/drivers/gpu/drm/omapdrm/dss/output.c
> >> index 9ba7cc8539a1..ce21c798cca6 100644
> >> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> >> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> >> @@ -60,6 +60,11 @@ int omapdss_device_init_output(struct omap_dss_device *out,
> >> 	}
> >> 
> >> 	if (local_bridge) {
> >> +		if (!out->bridge) {
> >> +			ret = -EPROBE_DEFER;
> >> +			goto error;
> >> +		}
> >> +
> >> 		out->next_bridge = out->bridge;
> >> 		out->bridge = local_bridge;
> >> 	}
> >> 
> >> Since I have not seen a reference to an omap DSI bridge driver in upstream kernels
> >> I would assume that out->bridge is NULL and therefore probing is deferred forever
> >> and the old MIPI DSI driver (which is still there) is no longer operational.
> >> 
> >> This is consistent with that our (old omapdrm) panel driver is no longer probed.
> > 
> > What happens? Do you get any displays? Or no displays at all? Do
> > you get an error print?
> > 
> > As Sebastian said, this shouldn't prevent DSI from probing. I
> > don't see anything in the commit that might affect DSI.
> 
> Yes, that is indeed strange. The only potential direct reason I could imagine is the
> additional test for out-bridge, but with Sebastian's explanation it is not
> even called for DSI.
> 
> Maybe it is a false report by git bisect because this patch enables a change somewhere
> else for the first time, which affects the DSI setup indirectly.
> 
> I have seen that there now is a similar, but not identical report for the N900 panel.

Note, that the N900 has an SDI panel, which is different from DSI.

> > Does the board have other display outputs? HDMI? If yes, could
> > you try with HDMI disabled, e.g. set its status to "disabled" in
> > the .dts.
> 
> My good/bad indicator is that there is no /dev/fb0 created any more. I have not
> checked for HDMI but it is likely also missing then. Basically it stopped working
> with v5.7-rc1 (as the basis where we add our private panel driver, some PMU/charger
> driver, DTS on top) and bisect did report this commit.
> 
> Unfortunately I currently can't do tests on real hardware and play around with printk
> in the code for the next weeks. Or partially reverting the patch step by step to see
> which change has an influence.

So it might be HDMI (or VENC) not probing successfully and
then resulting in -EPROBE_DEFER for omapdrm with no connection to
DSI at all. I suggest to disable all non-DSI video devices in
devicetree and check if this results in DSI panel coming up.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]