Hi Tomi,
> Am 04.08.2020 um 14:43 schrieb Tomi Valkeinen <tomi.valkeinen@xxxxxx>:
>
> 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.
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.
>
> 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.
BR,
Nikolaus
