jstephan: I proposed this patch late last year but the discussion was inconclusive: 
https://lore.kernel.org/linux-media/20231017105630.558089-2-sakari.ailus@linux.intel.com/
sailus: thank you for the link! Unfortunately I must admit that I am kind of new in this and I don't know what I should put into link-frequencies :/ 
jstephan: Which sensor do you have?
sailus: an AP1302. it's a standalone ISP chip
Does its documentation say which frequencies it uses?
I suppose this is for just R&D, not for production use. Otherwise you'd get this information from the hardware designers.
no the documentation doesn't tell
there's a PLL clock tree and FIFOs, so you can use pretty much any link frequency (within limits of course)
(and taking rounding into account)
and it's for R&D, yes
Could you just pick a PLL configuration with a frequency high enough?
although in the general case, I would consider that hardware developers may also struggle to pick one or a few particular link frequencies within the ranges that are fine EMI-wise
I think what Julien need is help to do just that :-)
to understand what "high enough" is
and what information he has to take into account to figure that out
a practical example of how that would be done for a real sensor would help a lot
Right, for individual devices' PLL trees we can't add documentation but we could document better the data rate of the CSI-2 link depending on the frequency. 
We probably have documentation for pixel rate only which isn't the same thing.
Although, in practice it's also the pixel rate that generally is available, so it's actually there already.
Pointers to the formula may not be conveniently located though.
https://hverkuil.home.xs4all.nl/spec/driver-api/tx-rx.html#pixel-rate
can we pick one device that has a standard clock tree, and use that as an example to show how the computation is done ?