Sorry for typo.
2014-03-28 19:46 GMT+09:00 Inki Dae <inki.dae@xxxxxxxxxxx>:
> Hi Philipp,
>
>
> 2014-03-27 23:46 GMT+09:00 Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>:
>> 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@xxxxxxxxxxxxxxxxxxxxx
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
