Hi, On Sat, Aug 01, 2020 at 03:43:22PM +0200, H. Nikolaus Schaller wrote: > > Am 24.07.2020 um 03:24 schrieb Laurent Pinchart : > > 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 : > >>>> Am 07.07.2020 um 21:04 schrieb H. Nikolaus Schaller : > >>>> > >>>> 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 > 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. > 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? The purpose of the whole patchset is to move to drm_panel instead of the omapdrm specific panel code. 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 2. all the way to mipi_dsi (but not yet drm_panel) -- Sebastian