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@xxxxxxxxxxxxxxxx>
> 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.
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.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
