Hi Laurent,
> Am 24.07.2020 um 03:24 schrieb Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>:
>
> Hi Nikolaus,
>
> On Thu, Jul 23, 2020 at 09:03:49AM +0200, H. Nikolaus Schaller wrote:
>>> Am 08.07.2020 um 09:52 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>:
>>>> Am 07.07.2020 um 21:04 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>:
>>>>
>>>> And what I would need to know before I start to write new code is
>>>> if is possible to operate a video mipi dsi panel with driver from
>>>> gpu/drm/panel together with omapdrm (v5.7 and later).
>>>
>>> I did a quick test on a 5.7.6 kernel with the sysc fixes as
>>> suggested by Tony.
>>>
>>> Then I overwrote the compatible entry of our display to be
>>> orisetech,otm8009a and configured to build the otm8009a panel driver.
>>>
>>> The panel driver is loaded, but not probed (no call to otm8009a_probe).
>>> It is shown in /sys/bus/mipi-dsi/drivers (and lsmod) but not /sys/bus/mipi-dsi/devices.
>>>
>>> So what should I try next?
>>
>> Any suggestions if and how it is possible to use a gpu/drm/panel MIPI DSI
>> video mode panel with omapdrm (on OMAP5)?
>
> For the DSI panel to probe, the display driver needs to register a DSI
> host with mipi_dsi_host_register(). omapdrm doesn't do so yet, we need
> to integrate Sebastian's "[PATCHv2 00/56] drm/omap: Convert DSI code to
> use drm_mipi_dsi and drm_panel" series first. I'll try to review it in
> the near future.
>
>> The problem is that our old omapdrm/display driver is broken since v5.7 and
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.
>> 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?
BR and thanks,
Nikolaus
