Re: [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge

[Sam Ravnborg <sam@ravnborg.org>]

Hi Marek,

On Tue, Nov 10, 2020 at 01:34:26PM +0100, Marek Szyprowski wrote:
> Hi Michael,
> 
> On 10.11.2020 09:13, Michael Tretter wrote:
> > On Mon, 09 Nov 2020 12:15:39 +0900, Inki Dae wrote:
> >> 20. 9. 11. 오후 10:53에 Michael Tretter 이(가) 쓴 글:
> >>> This is v2 of the series to convert the Exynos MIPI DSI driver into a drm
> >>> bridge and make it usable with other drivers. Although the driver is
> >>> converted, it still supports the component framework API to stay compliant
> >>> with the Exynos DRM driver.
> >>>
> >>> The Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the
> >>> i.MX8M Mini, the bridge is driven by an LCDIF display controller instead of
> >>> the Exynos Decon. The driver for the LCDIF does not use the component
> >>> framework, but uses drm bridges.
> >>>
> >>> I don't have any Exynos SoC to actually test the series. I build a dummy to
> >>> test the bridge with a component driver, to make sure that at least the
> >>> initialization is working. Furthermore, tested the driver as a bridge with a
> >>> few additional unfinished patches on the i.MX8M Mini EVK. However, somebody
> >>> should verify that the driver is still working on Exynos hardware.
> >>>
> >>> I also changed the order of the patches to first make the driver more platform
> >>> independent (patches 2 to 8), then convert to a drm bridge driver (patches 10
> >> Just a fundamental question, A MIPI-DSI(Display Serial Interface) bus device
> >> would be one of an encoder type of devices not bridge such as DSI to LVDS
> >> and LVDS to DSI bridge devices, and also image enhancer and image compressor
> >> in case of Exynos.
> > I don't understand, why the MIPI-DSI bus device would be an encoder type and
> > DSI to LVDS or MIPI-DSI to HDMI would be bridges. For example, the device tree
> > documentation for the DSIM states that the DSIM receives RGB video as input
> > and produces MIPI-DSI as output. Thus, the DSIM is basically a parallel RGB to
> > MIPI-DSI bridge and the encoder is the LCD controller that encodes the video
> > data as parallel RGB.
> >
> > On the i.MX8MM, the LCDIF is already the encoder. On Exynos, the series
> > implements the encoder in the platform glue, but in the end the encoder can
> > probably be moved to the DECON.
> 
> This is probably the historical decision. That time when Exynos DSI 
> driver has been implemented, support for DRM bridges wasn't ready enough 
> to use to for such purpose.
> 
> Frankly, I'm still not convinced that the current DRM bridge framework 
> provides everything needed to reimplement the Exynos DSI driver with all 
> its features. There are a lots of corner cases and order-specific bits 
> in turning on/off the display pipeline, which don't map nicely to the 
> bridge pre_enable (called in post-order) and enable (called in 
> pre-order) callbacks. Especially if you consider that there might be 
> another bridge before and after.
> 
> I think that Andrzej Hajda already pointed those drawbacks of the 
> current design. Last week I've spent some significant amount of time 
> playing with exynos dsi code to check how to match its operations 
> (especially the runtime power management) to this design with the 
> current boards (Arndale with additional DSI->LVDS bridge and panel, 
> Trats2 with DSI panel and TM2e with MIC 'in-bridge' and DSI panel), but 
> without a success.

Can you help by iterating the missing pieces in the current bridge
infrastructure? Maybe it is something we can work out in a way that
benefits more than one bridge driver.

It would be nice with specific issues to look into.

Thanks in advance,

	Sam