drm/sun4i: add components in breadth first traversal order

drm/sun4i: add components in breadth first traversal order

The encoder drivers use drm_of_find_possible_crtcs to get upstream
crtcs from the device tree using of_graph. For the results to be
correct, encoders must be probed/bound after _all_ crtcs have been
created. The existing code uses a depth first recursive traversal
of the of_graph, which means the encoders downstream of the TCON
get add right after the first TCON. The second TCON or CRTC will
never be properly associated with encoders connected to it.

Other platforms, such as Rockchip, deal with this by probing all
CRTCs first, then all subsequent components. This is easy to do
since the CRTCs correspond to just one device node, and are the
first nodes in the pipeline.

However with Allwinner SoCs, the function of the CRTC is split
between the display backend (DE 1.0) or mixer (DE 2.0), which does
scan-out and compositing, and the TCON, which generates the display
timing signals. Further complicating the process, there may be a
Dynamic Range Controller between the backend and the TCON. Also, the
backend is preceded by the frontend, with a Display Enhancement Unit
possibly in between.

In a dual display pipeline setup, both frontends can feed either
backend, and both backends can feed either TCON. We want all
components of the same type to be added before the next type in the
pipeline. Fortunately, the pipelines are perfectly symmetric, i.e.
components of the same type are at the same depth when counted from
the frontend. The only exception is the third pipeline in the A80
SoC, which we do not support anyway.

Hence we can use a breadth first search traversal order to add
components. We do not need to check for duplicates. The component
matching system handles this for us.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170908075016.18657-3-wens@csie.org