I have some (preliminary) media control graphs for the two suggested 
topologies (a and b) which you outline above.

https://www.ragnatech.se/~neg/adv7482-a.pdf
https://www.ragnatech.se/~neg/adv7482-b.pdf

Currently I'm working with topology B since supporting A is not possible 
with my use-case without having more pad aware V4L2 video operations.  
Note that in the B topology both ADV7482 nodes represent the same chip 
but are two nodes in OF (and two driver instances are created..) so it's 
a obvious hack and I do not intend to try to get a ADV7482 driver 
upstream which looks like this, this simply lets me test the Renesas 
CSI2 and Gen3 VIN drivers which is my primary concern.

Making V4L2 more video operations pad aware is out of scope for this 
async framework discussion. The reason I bring up the graphs is that I 
would like to explore the possibility for the async framework to allow a 
subdevice to be bound to more then one consumer. In both topology A and 
B each VIN (/dev/videoX) node is a separate instance of the rcar-vin 
driver yet they share common subdevices, e.g. rcar_csi2.fea80000.csi2 
can be used by all VIN instances.

Currently I have a VIN group concept where data is shared between all 
VIN instances, where if a subdev have already been added to a VIN 
v4l2_async_notifier list the other simply ignores it and gets the 
subdevice reference from the group global list once it is bound to that 
VIN instance. This works but I feel this can be handled in a more 
generic way by the async framework.

A quick look at drivers/media/v4l2-core/v4l2-async.c and
v4l2_async_test_notify() shows that once a subdevice is matched it's 
taken of the global subdevice and moved to the notifier's done list.

I don't know much about the async framework and the ramifications of 
changing this behavior or if there already exists way to achieve this 
some other way or maybe this is just a bad idea (TM). In any case I 
would like to know so I don't lose more sleep over this :-)

> 
> Philipp: would you be able to provide a description of the problem on your
> side for Niklas's and Laurent's benefit?
> 

-- 
Regards,
Niklas Söderlund