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
