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 <laurent.pinchart@xxxxxxxxxxxxxxxx>:
> > 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;
> + }
> +
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
Attachment:
signature.asc
Description: PGP signature
