A driver in RaspberryPi BSP kernel uses v4l2_get_link_freq(), but instead of just calling it in the source device, it walks the graph upstream until it finds a subdev that has V4L2_CID_LINK_FREQ or V4L2_CID_PIXEL_RATE. Apparently this is used to handle the case where there's a simple mux subdevice between the csi2 rx and the sensor, and the mux doesn't implement much at all in terms of v4l2 functionality so it's skipped for the
v4l2_get_link_freq().
I think either 1) the mux subdev should implement the required controls, as it is a csi-2 source, or 2) the framework should have a helper function that does all the graph walk for you. I'd go with 1). Thoughts?
tomba, I think we'll see this more often on other platforms which may need a helper. Isn't the mux-subdev just a passthrough device though ?
Aha except - I think your point is - the MUX should check it's connected device right?
Now I wonder what happens if the mux has multiple devices connected with different rates ...
(Hopefully that would get handled when switching/reconfiguring the pipeline)
yes, in 1) the mux would implement the required controls, and basically just forward the call to its source. And it's not only about link_freq. Also get_frame_desc needs similar treatment. Either we need to walk the graph (somehow. how to decide which pad to follow if there are multiple?) or the driver should forward the get_frame_desc call.
tomba, Sounds like the responsibility of the mux driver to me.
Is that driver upstream?
(I assume this is the Arducam video mux in RPi's tree at a guess)
Hmm I don't think so. Yes, some arducam mux.
either we need to fix /all/ CSI2 receivers to do the same walk, or we need to fix ... the one mux ;-)
when you put it that way, the 1) sounds like the only sensible option =)