mbox series

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

Message ID 20200911135413.3654800-1-m.tretter@pengutronix.de (mailing list archive)
Headers show
Series drm/exynos: Convert driver to drm bridge | expand

Message

Michael Tretter Sept. 11, 2020, 1:53 p.m. UTC
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
to 13) and finally expose the API, split the code and move the platform
independent driver to the bridges (patches 14 - 16). Hopefully this simplifies
testing/bisecting and helps me to understand potential error reports.

Also I added host_ops for attach/detach and the tearing effect handler to make
the calls into the platform code more visible.

Furthermore, the series should now apply to linux-next and correctly build the
exynos_defconfig.

Thanks,

Michael

Changelog:

v2:
- rebase on linux-next
- verify with exynos_defconfig
- fix crashes reported by Marek Szyprowski Exynos3250-based Rinato
- reorder patches
- add host_ops for platform specific code
- roughly test component framework integration with dummy

Michael Tretter (16):
  drm/encoder: remove obsolete documentation of bridge
  drm/exynos: remove in_bridge_node from exynos_dsi
  drm/exynos: use exynos_dsi as drvdata
  drm/exynos: extract helper functions for probe
  drm/exynos: move dsi host registration to probe
  drm/exynos: shift register values to fields on write
  drm/exynos: use identifier instead of register offsets
  drm/exynos: add host_ops callback for platform drivers
  drm/exynos: add callback for tearing effect handler
  drm/exynos: implement a drm bridge
  drm/exynos: convert encoder functions to bridge function
  drm/exynos: configure mode on drm bridge
  drm/exynos: get encoder from bridge whenever possible
  drm/exynos: add API functions for platform drivers
  drm/exynos: split out platform specific code
  drm/exynos: move bridge driver to bridges

 drivers/gpu/drm/bridge/Kconfig          |    9 +
 drivers/gpu/drm/bridge/Makefile         |    1 +
 drivers/gpu/drm/bridge/samsung-dsim.c   | 1790 +++++++++++++++++++++
 drivers/gpu/drm/exynos/Kconfig          |    5 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1927 ++---------------------
 include/drm/bridge/samsung-dsim.h       |   64 +
 include/drm/drm_encoder.h               |    1 -
 7 files changed, 2027 insertions(+), 1770 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

Comments

Inki Dae Nov. 9, 2020, 3:15 a.m. UTC | #1
Hi Michael,

Thanks for your contribution.

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.
Why do you want to convert such MIPI-DSI driver to bridge type of driver? Seems not sensible. The reason would be just to share MIPI-DSI phy driver for Exynos with i.MX8M Mini?

Thanks,
Inki Dae


> to 13) and finally expose the API, split the code and move the platform
> independent driver to the bridges (patches 14 - 16). Hopefully this simplifies
> testing/bisecting and helps me to understand potential error reports.
> 
> Also I added host_ops for attach/detach and the tearing effect handler to make
> the calls into the platform code more visible.
> 
> Furthermore, the series should now apply to linux-next and correctly build the
> exynos_defconfig.
> 
> Thanks,
> 
> Michael
> 
> Changelog:
> 
> v2:
> - rebase on linux-next
> - verify with exynos_defconfig
> - fix crashes reported by Marek Szyprowski Exynos3250-based Rinato
> - reorder patches
> - add host_ops for platform specific code
> - roughly test component framework integration with dummy
> 
> Michael Tretter (16):
>   drm/encoder: remove obsolete documentation of bridge
>   drm/exynos: remove in_bridge_node from exynos_dsi
>   drm/exynos: use exynos_dsi as drvdata
>   drm/exynos: extract helper functions for probe
>   drm/exynos: move dsi host registration to probe
>   drm/exynos: shift register values to fields on write
>   drm/exynos: use identifier instead of register offsets
>   drm/exynos: add host_ops callback for platform drivers
>   drm/exynos: add callback for tearing effect handler
>   drm/exynos: implement a drm bridge
>   drm/exynos: convert encoder functions to bridge function
>   drm/exynos: configure mode on drm bridge
>   drm/exynos: get encoder from bridge whenever possible
>   drm/exynos: add API functions for platform drivers
>   drm/exynos: split out platform specific code
>   drm/exynos: move bridge driver to bridges
> 
>  drivers/gpu/drm/bridge/Kconfig          |    9 +
>  drivers/gpu/drm/bridge/Makefile         |    1 +
>  drivers/gpu/drm/bridge/samsung-dsim.c   | 1790 +++++++++++++++++++++
>  drivers/gpu/drm/exynos/Kconfig          |    5 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1927 ++---------------------
>  include/drm/bridge/samsung-dsim.h       |   64 +
>  include/drm/drm_encoder.h               |    1 -
>  7 files changed, 2027 insertions(+), 1770 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>  create mode 100644 include/drm/bridge/samsung-dsim.h
>
Michael Tretter Nov. 10, 2020, 8:13 a.m. UTC | #2
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.

> Why do you want to convert such MIPI-DSI driver to bridge type of driver?
> Seems not sensible. The reason would be just to share MIPI-DSI phy driver
> for Exynos with i.MX8M Mini?

Yes, the reason is that the driver should be shared between Exynos and
i.MX8MM. It is the same IP and I don't see a reason why we should introduce
another driver for the same IP if the driver works for both SoCs.

Michael
Marek Szyprowski Nov. 10, 2020, 12:34 p.m. UTC | #3
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.

>> Why do you want to convert such MIPI-DSI driver to bridge type of driver?
>> Seems not sensible. The reason would be just to share MIPI-DSI phy driver
>> for Exynos with i.MX8M Mini?
> Yes, the reason is that the driver should be shared between Exynos and
> i.MX8MM. It is the same IP and I don't see a reason why we should introduce
> another driver for the same IP if the driver works for both SoCs.

I think that the easiest way to share this driver between Exynos and iMX 
would be to extract the low-level code (the code that plays with 
hardware registers) to the common plane, while keeping the separate DRM 
glue, device component and platform device parts. This way the Exynos 
will continue to use it in the current form, while iMX can start using 
it as DRM bridge. A bit similar approach is used with exynos_dp driver 
and analogix_dp bridge shared with other SoCs.

I hope that later, when the bridge related issue are resolved, the 
Exynos can be converted too, so the encoder creation moved to FIMD and 
Decon.

Best regards
Sam Ravnborg Nov. 10, 2020, 6:52 p.m. UTC | #4
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
Inki Dae Nov. 11, 2020, 3:04 a.m. UTC | #5
20. 11. 10. 오후 5:13에 Michael Tretter 이(가) 쓴 글:
> 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 receives RGB video as input and encodes it to MIPI packet and then transfers the packet to MIPI panel.
And finally, MIPI panel decodes the packet and updates it - RGB data - on its SRAM.

MIPI-DSI driver programs how the RGB video should be made as MIPI packet. For more detail, you could refer to MIPI-DSI spec.
This would be why we handle MIPI-DSI driver as an encoder like other ARM SoC DRM drivers did.

> 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.

As you know, Display controller can transfer RGB video to various devices such as RGB panel, CPU panel, LVDS panel via LVDS bridge, MIPI panel via MIPI-DSI bus device, and so on like below,

Display Controller --> RGB panel or CPU panel.
Display Controller --> LVDS bridge --> LVDS panel.
Display Controller --> MIPI DSI bus device --> MIPI Panel.
...

Display controller drivers such as FIMD and DECON series in case of Exynos don't create an encoder driver-internally instead of it depends on Display pipeline configuration - what kind of Display panel is used.
In fact, if the Display pipeline uses RGB panel or CPU panel without Display bus device such as MIPI-DSI, then FIMD and DECON drivers create an encoder for it internally - just we separated the code to consider other type of panels.

On the I.MX8MM, could you share how to handle an encoder if some board has only MIPI-DSI panel, and in this case, where is an encoder for it created? I looked into I.MX8MM DRM driver but didn't find MIPI-DSI driver.
Seems that they support only parallel display, HDMI and LVDS panel.

Thanks,
Inki Dae

> 
>> Why do you want to convert such MIPI-DSI driver to bridge type of driver?
>> Seems not sensible. The reason would be just to share MIPI-DSI phy driver
>> for Exynos with i.MX8M Mini?
> 
> Yes, the reason is that the driver should be shared between Exynos and
> i.MX8MM. It is the same IP and I don't see a reason why we should introduce
> another driver for the same IP if the driver works for both SoCs.
> 
> Michael
>
Inki Dae Nov. 11, 2020, 3:11 a.m. UTC | #6
20. 11. 11. 오후 12:04에 Inki Dae 이(가) 쓴 글:
> 
> 
> 20. 11. 10. 오후 5:13에 Michael Tretter 이(가) 쓴 글:
>> 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 receives RGB video as input and encodes it to MIPI packet and then transfers the packet to MIPI panel.
> And finally, MIPI panel decodes the packet and updates it - RGB data - on its SRAM.
> 
> MIPI-DSI driver programs how the RGB video should be made as MIPI packet. For more detail, you could refer to MIPI-DSI spec.
> This would be why we handle MIPI-DSI driver as an encoder like other ARM SoC DRM drivers did.
> 
>> 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.
> 
> As you know, Display controller can transfer RGB video to various devices such as RGB panel, CPU panel, LVDS panel via LVDS bridge, MIPI panel via MIPI-DSI bus device, and so on like below,
> 
> Display Controller --> RGB panel or CPU panel.
> Display Controller --> LVDS bridge --> LVDS panel.
> Display Controller --> MIPI DSI bus device --> MIPI Panel.
> ...
> 
> Display controller drivers such as FIMD and DECON series in case of Exynos don't create an encoder driver-internally instead of it depends on Display pipeline configuration - what kind of Display panel is used.
> In fact, if the Display pipeline uses RGB panel or CPU panel without Display bus device such as MIPI-DSI, then FIMD and DECON drivers create an encoder for it internally - just we separated the code to consider other type of panels.
> 
> On the I.MX8MM, could you share how to handle an encoder if some board has only MIPI-DSI panel, and in this case, where is an encoder for it created? I looked into I.MX8MM DRM driver but didn't find MIPI-DSI driver.
> Seems that they support only parallel display, HDMI and LVDS panel.

One more thing, If I saw correctly, the LVDS driver of IMX DRM - lmx_ldb - creates an encoder internally like MIPI-DSI driver of Exynos DRM did.

> 
> Thanks,
> Inki Dae
> 
>>
>>> Why do you want to convert such MIPI-DSI driver to bridge type of driver?
>>> Seems not sensible. The reason would be just to share MIPI-DSI phy driver
>>> for Exynos with i.MX8M Mini?
>>
>> Yes, the reason is that the driver should be shared between Exynos and
>> i.MX8MM. It is the same IP and I don't see a reason why we should introduce
>> another driver for the same IP if the driver works for both SoCs.
>>
>> Michael
>>
>
Michael Tretter Nov. 11, 2020, 10:18 a.m. UTC | #7
On Wed, 11 Nov 2020 12:11:15 +0900, Inki Dae wrote:
> 20. 11. 11. 오후 12:04에 Inki Dae 이(가) 쓴 글:
> > 20. 11. 10. 오후 5:13에 Michael Tretter 이(가) 쓴 글:
> >> 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 receives RGB video as input and encodes it to MIPI packet and then transfers the packet to MIPI panel.
> > And finally, MIPI panel decodes the packet and updates it - RGB data - on its SRAM.
> > 
> > MIPI-DSI driver programs how the RGB video should be made as MIPI packet. For more detail, you could refer to MIPI-DSI spec.
> > This would be why we handle MIPI-DSI driver as an encoder like other ARM SoC DRM drivers did.
> > 
> >> 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.
> > 
> > As you know, Display controller can transfer RGB video to various devices such as RGB panel, CPU panel, LVDS panel via LVDS bridge, MIPI panel via MIPI-DSI bus device, and so on like below,
> > 
> > Display Controller --> RGB panel or CPU panel.
> > Display Controller --> LVDS bridge --> LVDS panel.
> > Display Controller --> MIPI DSI bus device --> MIPI Panel.
> > ...
> > 
> > Display controller drivers such as FIMD and DECON series in case of Exynos don't create an encoder driver-internally instead of it depends on Display pipeline configuration - what kind of Display panel is used.
> > In fact, if the Display pipeline uses RGB panel or CPU panel without Display bus device such as MIPI-DSI, then FIMD and DECON drivers create an encoder for it internally - just we separated the code to consider other type of panels.

What happens if I add a MIPI-DSI --> HDMI bridge to the Display pipeline? Then
the Pipeline is

Display Controller --> MIPI DSI bus device --> HDMI bridge --> HDMI Panel

If the type of the Display panel decides which part of the pipeline provides
the encoder, the HDMI bridge driver would be responsible for creating the
encoder, right? Thus, the MIPI-DSI driver would not be responsible for
creating the encoder and would also get the encoder from another driver.
Therefore, I prefer to think of the Display Controller as the encoder and
other bridges are just bridges.

BTW, this is exactly the Display pipeline that is used on the i.MX8MM EVK.

> > 
> > On the I.MX8MM, could you share how to handle an encoder if some board has only MIPI-DSI panel, and in this case, where is an encoder for it created? I looked into I.MX8MM DRM driver but didn't find MIPI-DSI driver.
> > Seems that they support only parallel display, HDMI and LVDS panel.
> 
> One more thing, If I saw correctly, the LVDS driver of IMX DRM - lmx_ldb - creates an encoder internally like MIPI-DSI driver of Exynos DRM did.

Yes, but the IMX DRM driver is not used on the i.MX8MM. The i.MX8MM uses the
LCDIF display controller instead of the IPU of the i.MX6. The driver for the
LCDIF is the mxsfb driver, which in turn uses the drm_simple_display_pipe,
which already provides the encoder. Therefore, to use a bridge driver with a
driver based on a drm_simple_display_pipe, the bridge driver must accept other
encoders.

Michael

> 
> > 
> > Thanks,
> > Inki Dae
> > 
> >>
> >>> Why do you want to convert such MIPI-DSI driver to bridge type of driver?
> >>> Seems not sensible. The reason would be just to share MIPI-DSI phy driver
> >>> for Exynos with i.MX8M Mini?
> >>
> >> Yes, the reason is that the driver should be shared between Exynos and
> >> i.MX8MM. It is the same IP and I don't see a reason why we should introduce
> >> another driver for the same IP if the driver works for both SoCs.
> >>
> >> Michael
> >>
> > 
>
Inki Dae Nov. 13, 2020, 9:34 a.m. UTC | #8
20. 11. 11. 오후 7:18에 Michael Tretter 이(가) 쓴 글:
> On Wed, 11 Nov 2020 12:11:15 +0900, Inki Dae wrote:
>> 20. 11. 11. 오후 12:04에 Inki Dae 이(가) 쓴 글:
>>> 20. 11. 10. 오후 5:13에 Michael Tretter 이(가) 쓴 글:
>>>> 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 receives RGB video as input and encodes it to MIPI packet and then transfers the packet to MIPI panel.
>>> And finally, MIPI panel decodes the packet and updates it - RGB data - on its SRAM.
>>>
>>> MIPI-DSI driver programs how the RGB video should be made as MIPI packet. For more detail, you could refer to MIPI-DSI spec.
>>> This would be why we handle MIPI-DSI driver as an encoder like other ARM SoC DRM drivers did.
>>>
>>>> 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.
>>>
>>> As you know, Display controller can transfer RGB video to various devices such as RGB panel, CPU panel, LVDS panel via LVDS bridge, MIPI panel via MIPI-DSI bus device, and so on like below,
>>>
>>> Display Controller --> RGB panel or CPU panel.
>>> Display Controller --> LVDS bridge --> LVDS panel.
>>> Display Controller --> MIPI DSI bus device --> MIPI Panel.
>>> ...
>>>
>>> Display controller drivers such as FIMD and DECON series in case of Exynos don't create an encoder driver-internally instead of it depends on Display pipeline configuration - what kind of Display panel is used.
>>> In fact, if the Display pipeline uses RGB panel or CPU panel without Display bus device such as MIPI-DSI, then FIMD and DECON drivers create an encoder for it internally - just we separated the code to consider other type of panels.
> 
> What happens if I add a MIPI-DSI --> HDMI bridge to the Display pipeline? Then
> the Pipeline is
> 
> Display Controller --> MIPI DSI bus device --> HDMI bridge --> HDMI Panel
> 
> If the type of the Display panel decides which part of the pipeline provides
> the encoder, the HDMI bridge driver would be responsible for creating the

HDMI bridge driver will create only an bridge because this is not encoder device but bridge device such as LVDS bridge.

Display Controller(CRTC) --> MIPI DSI bus device(Encoder) --> HDMI bridge(Bridge) --> HDMI Panel(Connector)

> encoder, right? Thus, the MIPI-DSI driver would not be responsible for
> creating the encoder and would also get the encoder from another driver.

I think MIPI-DSI is an encoder device as I mentioned earlier so MIPI-DSI driver would be responsible for creating the encoder.

> Therefore, I prefer to think of the Display Controller as the encoder and
> other bridges are just bridges.

So crtc driver will create an encoder internally in case of parallel RGB Panel *because encoder device isn't used*. On the other hand, each encoder driver will be an encoder in case of other type of panel - which is needed for Display bus device such as MIPI-DSI device.

Thanks,
Inki Dae

> 
> BTW, this is exactly the Display pipeline that is used on the i.MX8MM EVK.
> 
>>>
>>> On the I.MX8MM, could you share how to handle an encoder if some board has only MIPI-DSI panel, and in this case, where is an encoder for it created? I looked into I.MX8MM DRM driver but didn't find MIPI-DSI driver.
>>> Seems that they support only parallel display, HDMI and LVDS panel.
>>
>> One more thing, If I saw correctly, the LVDS driver of IMX DRM - lmx_ldb - creates an encoder internally like MIPI-DSI driver of Exynos DRM did.
> 
> Yes, but the IMX DRM driver is not used on the i.MX8MM. The i.MX8MM uses the
> LCDIF display controller instead of the IPU of the i.MX6. The driver for the
> LCDIF is the mxsfb driver, which in turn uses the drm_simple_display_pipe,
> which already provides the encoder. Therefore, to use a bridge driver with a
> driver based on a drm_simple_display_pipe, the bridge driver must accept other
> encoders.
> 
> Michael
> 
>>
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>>>
>>>>> Why do you want to convert such MIPI-DSI driver to bridge type of driver?
>>>>> Seems not sensible. The reason would be just to share MIPI-DSI phy driver
>>>>> for Exynos with i.MX8M Mini?
>>>>
>>>> Yes, the reason is that the driver should be shared between Exynos and
>>>> i.MX8MM. It is the same IP and I don't see a reason why we should introduce
>>>> another driver for the same IP if the driver works for both SoCs.
>>>>
>>>> Michael
>>>>
>>>
>>
>