[PATCH v4 00/34] drm/exynos: Refactor parts of the exynos driver

[Inki Dae]

Hi Andrzej,


2014-03-04 20:03 GMT+09:00 Andrzej Hajda <a.hajda at samsung.com>:
> Hi Inki,
>
> On 02/28/2014 03:28 AM, Inki Dae wrote:
> (...)
>>
>> Andrzej Hajda from our team is already working on addressing remaining
>> issues with Sean's series, including fixing removed parallel display
>> support. Earlier this month he sent a series restoring support for DSI
>> panels: http://thread.gmane.org/gmane.
>>
>>  Already merged to internal kernel for test.
>>
>>> linux.kernel.samsung-soc/27044 . Now he's also trying to make the design
>>> more modular. He will give you more information on Monday, as he's on
>>> holiday for next two days.
> Thanks Tomasz for pointing it out. I try to properly restore parallel
> panel support.
> I have come to the conclusion that the most natural way is to implement
> crtc/encoder/connector in FIMD, as the FIMD directly produces
> parallel RGB stream (or I80 in command mode).
> I think implementing crtc/encoder/connector in FIMD in case of DSI and
> eDP panel
> is also more natural. In such case I would convert DSIM, eDP and ptn3460
> to drm_panel
> framework similarly as I already did for TC358764 DSI/LVDS bridge.

In case of some machines without MIPI-DSI like below,
        FIMD------>Parallel Panel

There wouldn't be proper place for implementing a connector and a
encoder. I guess your conclusion results from such cases.

But how should we handle eDP if connector and encoder are implemented
only in FIMD driver?
eDP can be hot-plugged and the hot-plug function will be handled by
interrupt handler of eDP driver. This would mean that the hardware
resource to the hot-plug belongs to eDP ip, and also its own connector
should be implemented in eDP driver to detect the connection.

>
> Here are different scenarios of HW pipelines:
> 1. Parallel panel:
>     FIMD ---> Parallel Panel
> 2. DSI panel:
>     FIMD ---> DSIM ---> DSI Panel
> 3. Arndale:
>     FIMD ---> DSIM ---> DSI/LVDS bridge ---> LVDS panel
> 4. Snow:
>     FIMD ---> eDP ---> eDP/LVDS bridge ---> LVDS panel
> 5. In case mobile image enhancer(MIE) will be used pipeline can be
> extended to:
>     FIMD ---> MIE ---> DSIM ---> .....
>     or
>     FIMD ---> MIE ---> eDP ---> .....
>

Other scenarios,
      FIMD----->LVDS bridge----->LVDS panel

Actually, I had used above machine, Geminus.


And in case of Exynos4 series, it's more complicated,

      FIMD----->mDNIe------>FIMD-Lite------>Parallel Panel
      FIMD----->mDNIe------>FIMD-Lite------>MIPI-DSI------>DSI Panel
      ...

However, mDNIe ip isn't opened in public and also maybe continue so I
think Exynos drm driver doesn't need to cover such cases.

> Pros of implementing all drm components (crtc,encoder,connector) in
> FIMD, and using
> drm_panel framework for panels, DSIM, eDP and external bridges:
> - it is natural, FIMD produces already encoded stream, DSIM and eDP are
> just optional
>   converters,
> - easy to extend, adding/removing image processors or bridges will
> require only changing
>   video paths in DTS (in addition to adding device nodes),
> - consistency.
>
> What do you think about it?
>

I think it's a good idea but corner case still exists as mentioned
earlier. How about implementing connector and encoder in panel driver
in case of machines not using MIPI-DSI and eDP? And in case of
machines using MIPI-DSI and eDP, connector and encoder are implemented
in their drivers as now.

In case of using parallel panel, we could declare super device node
for Exynos drm like below,

        exynos-drm {
                compatible = "samsung,exynos-drm";
                crtcs = <&fimd>;
                connectors = <&panel>;
        };

connectors could be Panel, eDP, HDMI, and MIPI-DSI.

Current Exynos drm driver would assume that parallel panel is always
on so we could find a good way somehow.

Thanks,
Inki Dae

> Anyway the patch adding parallel support with current design should be
> ready soon.
>
>
> Regards
> Andrzej
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel