[PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
Christopher Spinrath
christopher.spinrath at rwth-aachen.de
Wed Jan 18 14:20:17 PST 2017
Hi Philipp,
turns out I have a question on your comment after all:
On 01/17/2017 07:35 PM, Christopher Spinrath wrote:
> Hi Philipp,
>
> thanks for the review!
>
> On 01/17/2017 09:57 AM, Philipp Zabel wrote:
>> [...]
>>> +
>>> + parallel-display {
>>> + compatible = "fsl,imx-parallel-display";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_ipu1>;
>>> +
>>> + interface-pix-fmt = "rgb24";
>>
>> This is not necessary if the connector created by the tpf410 has the
>> correct media bus format set in its display_info structure. This can be
>> done in tfp410_attach, before calling drm_mode_connector_attach_encoder:
>>
>> u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>>
>> drm_display_info_set_bus_formats(&dvi->connector.display_info,
>> &bus_format, 1);
>>
>> After this is done, the above line should be removed in a follow-up
>> patch.
On closer inspection the tfp410 can handle rgb12, rgb24, and DVI
formats. Considering this it feels wrong to hardcode the bus format to
rgb24 (isn't it?).
So a solution might be to add a property specifying the bus format to
the tfp410 binding. But then we would effectively just move this
property from one node to another. I wonder if this is still desireable...?
Cheers,
Christopher
> Ok, I will send a mini follow-up series doing that with your
> Suggested-by (unless you object) in the next few days.
>
> Cheers,
> Christopher
>
>>> + port at 0 {
>>> + reg = <0>;
>>> +
>>> + parallel_display_in: endpoint {
>>> + remote-endpoint = <&ipu1_di0_disp0>;
>>> + };
>>> + };
>>> +
>>> + port at 1 {
>>> + reg = <1>;
>>> +
>>> + parallel_display_out: endpoint {
>>> + remote-endpoint = <&tfp410_in>;
>>> + };
>>> + };
>>> + };
>>> };
>>> [...]
More information about the linux-arm-kernel
mailing list