Hi Sakari, On Mon, Apr 06, 2020 at 11:35:07AM +0300, Sakari Ailus wrote: > > But that 19.2MHz is not a limitation of the device itself, it's a > > limitation of our implementation, so we can instead implement > > something equivalent in Linux using a clk_set_rate to 19.2MHz (to make > > sure that our parent clock is configured at the right rate) and the > > clk_get_rate and compare that to 19.2MHz (to make sure that it's not > > been rounded too far apart from the frequency we expect). > > > > This is doing exactly the same thing, except that we don't encode our > > implementation limitations in the DT, but in the driver instead. > > What I really wanted to say that a driver that doesn't get the clock > frequency from DT but still sets that frequency is broken. > > This frequency is highly system specific, and in many cases only a certain > frequency is usable, for a few reasons: On many SoCs, not all common > frequencies can be used (e.g. 9,6 MHz, 19,2 MHz and 24 MHz; while others > are being used as well), and then that frequency affects the usable CSI-2 > bus frequencies directly --- and of those, only safe, known-good ones > should be used. IOW, getting the external clock frequency wrong typically > has an effect that that none of the known-good CSI-2 bus clock frequencies > are available. So clock-frequency is not about the "Frequency of the xvclk clock in Hertz", but the frequency at which that clock must run on this particular SoC / board to be functional? If so, then yeah, we should definitely keep it, but the documentation of the binding should be made clearer as well. assigned-clock-rates should still go away though. Maxime
Attachment:
signature.asc
Description: PGP signature
