Re: [PATCH 02/22] [media] v4l2-async: allow subdevices to add further subdevices to the notifier waiting list

[Philipp Zabel <p.zabel@pengutronix.de>]

Am Donnerstag, den 13.10.2016, 14:56 +0300 schrieb Sakari Ailus:
> Hi Philipp,
> 
> On Wed, Oct 12, 2016 at 03:26:48PM +0200, Philipp Zabel wrote:
> > On Fri, Oct 7, 2016 at 11:52 PM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
> > > Hi Philipp,
> > >
> > > On Fri, Oct 07, 2016 at 06:00:47PM +0200, Philipp Zabel wrote:
> > >> Currently the v4l2_async_notifier needs to be given a list of matches
> > >> for all expected subdevices on creation. When chaining subdevices that
> > >> are asynchronously probed via device tree, the bridge device that sets
> > >> up the notifier does not know the complete list of subdevices, as it
> > >> can only parse its own device tree node to obtain information about
> > >> the nearest neighbor subdevices.
> > >> To support indirectly connected subdevices, we need to support amending
> > >> the existing notifier waiting list with newly found neighbor subdevices
> > >> with each registered subdevice.
> > >
> > > Could you elaborate a little what's the exact use case for this? What kind
> > > of a device?
> > 
> > On i.MX6 there's a
> > 
> > DW MIPI CSI2 host -> Mux -> IPU/CSI
> > 
> > path and all three are asynchronous subdevices in my patchset and only
> > the last one is directly known to the media device from the device
> > tree, since each driver should only parse its own device tree node an
> > can not follow the of_graph over multiple steps.
> 
> Ok. Are all these devices part of the SoC? Is the mux doing something else
> than just sitting in between the two? :-)

Yes, in this case the muxes are part of the SoC. Depending on the SoC
variant they have a different number of inputs, and they are controlled
via the IOMUXC block that also controls the pin configuration. They
don't have any additional functionality beyond selecting one active
input.

regards
Philipp