[PATCH 1/3] drm/exynos: add super device support

Inki Dae inki.dae at samsung.com
Fri Mar 28 03:49:13 PDT 2014


Sorry for typo.

2014-03-28 19:46 GMT+09:00 Inki Dae <inki.dae at samsung.com>:
> Hi Philipp,
>
>
> 2014-03-27 23:46 GMT+09:00 Philipp Zabel <p.zabel at pengutronix.de>:
>> Hi Inki,
>>
>> Am Donnerstag, den 27.03.2014, 21:43 +0900 schrieb Inki Dae:
>>> This patch adds super device support to bind sub drivers
>>> using device tree.
>>>
>>> For this, you should add a super device node to each machine dt files
>>> like belows,
>>>
>>> In case of using MIPI-DSI,
>>>       exynos-drm {
>>>               compatible = "samsung,exynos-drm";
>>>               crtcs = <&fimd>;
>>>               connectors = <&dsi>;
>>>       };
>>
>> Russell had suggested a similar binding for i.MX, but we have since
>> changed it to look like this instead:
>>
>> -       imx-drm {
>> -               compatible = "fsl,imx-drm";
>> -               crtcs = <&ipu 0>, <&ipu 1>;
>> -               connectors = <&hdmi>, <&ldb>;
>> -       };
>> +       display-subsystem {
>> +               compatible = "fsl,imx-display-subsystem";
>> +               ports = <&ipu_di0>, <&ipu_di1>;
>> +       };
>>
>> The ports are the two display output port nodes of the image processing
>> unit (corresponding to a drm_crtc each), and the imx-drm driver that
>> binds to the compatible value "fsl,imx-display-subsystem" automatically
>> collects all encoders that hang off of those via the OF graph bindings
>> (as documented in Documentation/devicetree/bindings/graph.txt in the
>> staging tree). I don't know how well those bindings would fit on Exynos,
>> maybe you could consider aligning your bindings with those.
>>
>> Either way, the generic term 'display-subsystem' is preferable to 'drm',
>> as the latter is Linux specific, which the device tree bindings
>> shouldn't be. The same goes for the 'crtcs' property. I'd prefer to
>> avoid Linux specific legacy names in new device tree bindings.
>
> Agree. I also thought that using property names, drm, crtcs and
> connectors,  specific to Linux is not reasonable. It looks good to use
> 'display-subsystem' instead of 'drm'.
> But only using 'ports' property for only crtc device is not clear to me.
>
> In case of Exynos SoC, there are various types of bridge device, image
> enhancer between crtc and encoder device, and lvds device between
> encoder and panel device.
> So I think Exynos drm core would be complicated with some binding
> codes if we use only 'ports' property.
> I guess 'imx_drm_components' list specific to imx drm would be among
> them, and that would be because you could resolve the probe order

s/could/couldn't

> issue only using existing component framework.
>
> Below link shows how we are trying to handle such various bridge devices in drm,
>         http://www.spinics.net/lists/dri-devel/msg55555.html
>
> And this patch series is first step for it.
>
> I'd like to use only component framework without specific list somehow
> but we should find generic property names for encoder/connector and
> bridge devices.
>
> Thanks,
> Inki Dae
>
>>
>> Also, since this adds new bindings, it should probably be sent to the
>> devicetree mailing list and include some documentation.
>>
>> If you are interested in the previous discussion on the imx-drm
>> supernode, here is the thread history:
>>     "[PATCH v5 00/11] imx-drm dt bindings"
>>     http://www.spinics.net/lists/arm-kernel/msg313112.html
>>     "[PATCH v4 00/11] imx-drm dt bindings"
>>     http://www.spinics.net/lists/dri-devel/msg54353.html
>>     "[RFC PATCH v3 0/9] imx-drm dt bindings"
>>     http://www.spinics.net/lists/arm-kernel/msg308529.html
>>     "[RFC PATCH v2 0/4] imx-drm dt bindings"
>>     http://www.spinics.net/lists/arm-kernel/msg306649.html
>>     "[RFC PATCH 0/3] imx-drm dt bindings"
>>     http://www.spinics.net/lists/arm-kernel/msg298290.html
>>
>> regards
>> Philipp
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel


More information about the dri-devel mailing list