The v4l2_async changes in the above mentioned patchset allow to support
longer chains of async subdevices connected to each other via OF graph
bindings without the final bridge node having to know about them all in
advance, like chains containing external GPIO controlled parallel
bus multiplexers or LVDS serializer/deserializer pairs:

-->,-------.
   |  MUX  |-->
-->`-------'

    serializer       deserializer
   ,------------.   ,------------.
-->| DS92LX1621 |-->| DS92LX1622 |-->
   `------------'   `------------'

For example:

 camera
,---------.
| MT9V024 |-->,-------.
`---------'   |  MUX  |--> SoC
,---------.   |       |
| MT9V024 |-->`-------'
`---------'

,---------.   ,------------.   ,------------.
| MT9V024 |-->| DS92LX1621 |-->| DS92LX1622 |--> SoC
`---------'   `------------'   `------------'

The SoC drivers only can look at their input port's directly connected
neighbors (MUX, DS92LX1622 in the above example) via the OF graph
bindings and add those to the initial v4l2_async_notifier list.
The indirectly connected subdevices (MT9V024, DS92LX1621) can not be
known to the SoC drivers in advance because only the subdevice drivers
themselves can parse their device tree nodes containing the OF graph
bindings that connect to their sources.

Further, I'd also like to use the same mechanism SoC internally, as for
some SoC variants the internal components are also be described in the
device tree.

The MIPI CSI-2 receiver on i.MX6 is a Synopsys DesignWare IP core with
some SoC glue added to the back to distribute the virtual channels onto
four separate parallel buses:

   ,-------.--> vc0
-->| MIPI  |--> vc1
   | CSI-2 |--> vc2
   `-------'--> vc3

which then may go through another, SoC internal mux (depending on the
i.MX6 variant) before arriving at one of the parallel CSI subdevices

   ,-------.
-->|  CSI  |-->
   `-------'

which sample video data into FIFOs that are then handed off to either
the IC for scaling / colorspace conversion or directly to the IDMAC to
write to memory:

   ,--------.
-->|  CSI0  |--------------------> IDMAC CH0
   `--------' \
               \    ,-------.----> IDMAC CH20
                `-->|  IC   |
                /   `-------'----> IDMAC CH21
   ,--------.  /
-->|  CSI1  |--------------------> IDMAC CH2
   `--------'

The above is contained in one Image Processing Unit (IPU) of which there
are one or two depending on SoC variant, and they are described in the
device tree as one device node with two input ports (one for each CSI):

-->,------.
   | IPU1 |
-->`------'

-->,------.
   | IPU2 |
-->`------'

given the existing device tree bindings, the i.MX6 media driver can at
most get to the sources connected directly to those four inputs via OF
graph bindings, and add them to the initial v4l2_async_notifier list.
That's the MIPI CSI-2 receiver and two two-port muxes on i.MX6D/Q/QP:

(CSI0 pads)--->,------.
               | MUX0 |-->,------.
   ,-------.-->`------'   | IPU1 |
-->| MIPI  |------------->`------'
   | CSI-2 |------------->,------.
   `-------'-->,------.   | IPU2 |
               | MUX1 |-->`------'
(CSI1 pads)--->`------'

And two 5-port muxes on i.MX6S/DL:

(CSI0 pads)--->,------.
               | MUX0 |-->,-----.
   ,-------.-->,------.   |     |
-->| MIPI  |-->|      |   | IPU |
   | CSI-2 |-->|      |   |     |
   `-------'-->`------'   |     |
               | MUX1 |-->`-----'
(CSI1 pads)--->`-----'

And whatever is connected directly to the external pads on i.MX5:

(CSI0 pads)-->,-----.
              | IPU |
(CSI1 pads)-->`-----'

That means that even in the simple case of a MIPI CSI-2 source connected
directly to the i.MX6 CSI-2 input pads:

,----------.   ,------------.   ,------.   ,-----------.
| TC358743 |-->| MIPI CSI-2 |-->| MUX0 |-->| IPU1 CSI0 |
`----------'   `------------'   `------'   `-----------'

the TC358743 async subdevice needs to be brought to the subdevice list
by the MIPI CSI-2 subdevice, because the bridge driver can only parse
the IPU input ports, which only directly connect to the mux.

regards
Philipp