linux-samsung-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Inki Dae <inki.dae@samsung.com>
To: Michael Tretter <m.tretter@pengutronix.de>
Cc: dri-devel@lists.freedesktop.org,
	linux-samsung-soc@vger.kernel.org, kernel@pengutronix.de,
	Laurent.pinchart@ideasonboard.com, krzk@kernel.org,
	narmstrong@baylibre.com, b.zolnierkie@samsung.com,
	sylvester.nawrocki@gmail.com, a.hajda@samsung.com,
	jy0922.shim@samsung.com, sw0312.kim@samsung.com
Subject: Re: [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge
Date: Fri, 13 Nov 2020 18:34:07 +0900	[thread overview]
Message-ID: <b71c47f6-9c18-b778-4e50-01041e1c9291@samsung.com> (raw)
In-Reply-To: <20201111101808.GA16630@pengutronix.de>



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

      reply	other threads:[~2020-11-13  9:27 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200911165401epcas1p3c7ee84dd01db93f472d6fa21c1100f29@epcas1p3.samsung.com>
2020-09-11 13:53 ` [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge Michael Tretter
2020-09-11 13:53   ` [PATCH v2 01/16] drm/encoder: remove obsolete documentation of bridge Michael Tretter
2020-11-07 15:07     ` Adam Ford
2020-11-10  8:46       ` Michael Tretter
2020-11-07 22:17     ` Sam Ravnborg
2020-09-11 13:53   ` [PATCH v2 02/16] drm/exynos: remove in_bridge_node from exynos_dsi Michael Tretter
2020-11-07 22:19     ` Sam Ravnborg
2020-09-11 13:54   ` [PATCH v2 03/16] drm/exynos: use exynos_dsi as drvdata Michael Tretter
2020-11-07 22:24     ` Sam Ravnborg
2020-11-09  2:24       ` Inki Dae
2020-09-11 13:54   ` [PATCH v2 04/16] drm/exynos: extract helper functions for probe Michael Tretter
2020-11-07 22:27     ` Sam Ravnborg
2020-11-09  2:52       ` Inki Dae
2020-09-11 13:54   ` [PATCH v2 05/16] drm/exynos: move dsi host registration to probe Michael Tretter
2020-09-11 13:54   ` [PATCH v2 06/16] drm/exynos: shift register values to fields on write Michael Tretter
2020-11-07 22:39     ` Sam Ravnborg
2020-11-10  8:28       ` Michael Tretter
2020-09-11 13:54   ` [PATCH v2 07/16] drm/exynos: use identifier instead of register offsets Michael Tretter
2020-09-11 13:54   ` [PATCH v2 08/16] drm/exynos: add host_ops callback for platform drivers Michael Tretter
2020-09-15 17:07     ` Andrzej Hajda
2020-09-15 18:02       ` Michael Tretter
2020-09-16 22:01         ` Andrzej Hajda
2020-09-11 13:54   ` [PATCH v2 09/16] drm/exynos: add callback for tearing effect handler Michael Tretter
2020-09-11 13:54   ` [PATCH v2 10/16] drm/exynos: implement a drm bridge Michael Tretter
2020-09-14  8:29     ` Marek Szyprowski
2020-09-14 12:31       ` Marek Szyprowski
2020-09-14 20:01         ` Michael Tretter
2020-09-14 21:19           ` Andrzej Hajda
2020-09-15 19:40             ` Andrzej Hajda
2021-02-01 16:33               ` Michael Tretter
2021-02-03 20:31                 ` Michael Tretter
2021-02-04 10:17                   ` Daniel Vetter
2021-02-04 10:56                     ` Michael Tretter
2021-02-04 16:05                       ` Daniel Vetter
2021-02-04 16:28                         ` Andrzej Hajda
2021-02-04 17:19                           ` Daniel Vetter
2021-02-04 17:26                             ` Laurent Pinchart
2021-02-04 17:46                               ` Daniel Vetter
2021-02-10  9:10                                 ` Frieder Schrempf
2021-02-18  8:04                                   ` Michael Tretter
2021-02-18 16:02                                     ` Andrzej Hajda
2021-02-23 12:07                                       ` Daniel Vetter
2021-04-20 11:42                                         ` Frieder Schrempf
2021-04-20 14:27                                           ` Laurent Pinchart
2020-09-11 13:54   ` [PATCH v2 11/16] drm/exynos: convert encoder functions to bridge function Michael Tretter
2020-09-11 13:54   ` [PATCH v2 12/16] drm/exynos: configure mode on drm bridge Michael Tretter
2020-09-11 13:54   ` [PATCH v2 13/16] drm/exynos: get encoder from bridge whenever possible Michael Tretter
2020-09-11 13:54   ` [PATCH v2 14/16] drm/exynos: add API functions for platform drivers Michael Tretter
2020-09-11 13:54   ` [PATCH v2 15/16] drm/exynos: split out platform specific code Michael Tretter
2020-11-09  3:15   ` [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge Inki Dae
2020-11-10  8:13     ` Michael Tretter
2020-11-10 12:34       ` Marek Szyprowski
2020-11-10 18:52         ` Sam Ravnborg
2020-11-11  3:04       ` Inki Dae
2020-11-11  3:11         ` Inki Dae
2020-11-11 10:18           ` Michael Tretter
2020-11-13  9:34             ` Inki Dae [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b71c47f6-9c18-b778-4e50-01041e1c9291@samsung.com \
    --to=inki.dae@samsung.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jy0922.shim@samsung.com \
    --cc=kernel@pengutronix.de \
    --cc=krzk@kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.tretter@pengutronix.de \
    --cc=narmstrong@baylibre.com \
    --cc=sw0312.kim@samsung.com \
    --cc=sylvester.nawrocki@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).