Hi Sebastian,
> Am 02.08.2020 um 01:22 schrieb Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxx>:
>
>>
>> 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;
>> + }
>> +
>
> The DSI code calls omapdss_device_init_output with
> local_bridge=NULL, so this is no called.
Ok. That is very likely.
Unfortuantely I currently can't do printk tests on real hardware.
>>
>> This is consistent with that our (old omapdrm) panel driver is no longer probed.
>>
>>>> an experimental gpu/drm/panel driver does not probe. And I assume that
>>>> omapdrm/display will disappear completely soon.
>>>
>>> Not before Sebastian's series gets integrated.
>>
>> Is there a simple patch (either from Sebastian's series or other source)
>> that fixes this regression until Sebastian's series is fully merged and we
>> can move to a module_mipi_dsi_driver based driver?
>
> The purpose of the whole patchset is to move to drm_panel instead of
> the omapdrm specific panel code.
Indeed. But it should not break the omapdrm/dss/dsi.c driver which is not moved.
> Some of the review feedback, that I
> received implies that my patchset breaks your usecase (video model
> DSI panel). The plan is to send it in smaller parts, which makes the
> review process a bit simpler and also the rebasing work of the
> series itself. The *.txt -> *.yaml binding patch has been queued
> for 5.9 and the DT patches are currently waiting to be queued by
> Tony. Next step is preparing for mipi_dsi. I will do this in two
> steps:
>
> 1. patches up to the point creating problems for video mode
The problem is that our dsi video mode panel is already broken since
v5.7-rc1. Before any of your patches is merged.
What I do not yet understand is how Laurent's patch should be able to break it.
> 2. all the way to mipi_dsi (but not yet drm_panel)
Yes, that will be the next step. Before I can help there with testing
we need to fix dsi with v5.7ff
BR and thanks,
Nikolaus
