Hi Jacopo and Laurent, On 2018-08-28 13:40:34 +0300, Laurent Pinchart wrote: [snip] > > >>> - The media_device_ops or at least the .link_notify() callback > > >>> of that > > >>> struct must be changed so not one driver in the media graph is > > >>> responsible for all links. In this case rcar-vin provides the > > >>> callback and rcar-vin should not judge which links between the > > >>> adv748x subdevices are OK to enable/disable. Currently the links > > >>> between the adv748x subdevices are immutably enabled to avoid this > > >>> particular problem. > > >> > > >> Uh, I didn't get this :/ Care to elaborate more? > > > > > > I'm thinking if it is not enough to just provide a .link_setup() > > > callback to the (enabled) csi-2 sink pads of the adv748x and handle > > > routing between the afe/hdmi sources and that sink, without the vin's > > > registered link_notify playing any role in that. > > > > That is my point, the v4l2 framework needs work to allow all drivers to > > provide a .link_setup() callback. And this as you describe will conflict > > with the current solution where there is only one possible such > > callback. So in addition to being able to have multiple such callbacks > > the current drivers implementing one would need to be updated to ignore > > links which it do not care about. > > Isn't this already possible ? We have a single top-level .link_notify() > operation at the media device level, but also .link_setup() operations for > each entity. You are both right this is possible today, my bad. I had confused link_notify() and link_setup() and thought they where the same and that there could be only one implementation in struct media_device_ops which handled all link changes. I'm happy to be proven wrong here as it will allow the adv748x to change links between its subdevices :-) Jacopo thanks for being persistent here! -- Regards, Niklas Söderlund
