Re: module_mipi_dsi_driver panel with omapdrm?

["H. Nikolaus Schaller" <hns@goldelico.com>]

> Am 05.08.2020 um 13:07 schrieb Sebastian Reichel <sebastian.reichel@collabora.com>:
> 
> 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.

Yes I know. But the symptom and the -rc or patch set where it appears for the first time
seems to be the same. So it may have a similar common reason.

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

Ah, ok. There is no venc on omap5 but HDMI... Good thing to test.

BR,
Nikolaus