Hi Suman,

Am 23.06.2017 um 20:05 schrieb Suman Anna [off-list ref]:

quoted

quoted

quoted

Or does it just mean that it defines the property name?

Please read the documentation link I sent - it's in the very bottom and
should have an example.

I have seen it but it does not give me a good clue how to translate that into
correct omap3isp node setup in a specific DT. Rather it raises more questions.
Maybe because I don't understand completely what it is talking about.

The fundamental question is if this "assigned-clock-rates" is already
handled by ov965x->clk = devm_clk_get(&client->dev, NULL); ?

Or should we define that for the omap3isp node?

Then of course we need no new code and just use the right property names.
And N900, N9 camera DTs should be updated.

Look up of_clk_set_defaults() function in drivers/clk/clk-conf.c. This
function gets invoked usually during clock registration, and also gets
called in platform_drv_probe(), so the parents and clocks do get
configured before your driver gets probed. So, this provides a default
configuration if these properties are supplied (in either clock nodes or
actual device nodes), and if your driver needs to change the rates at
runtime, then you would have to do that in the driver itself.

Ok, now I understand. Thanks!

Quite hidden, but nice feature. I would never have thought that it exists.
Especially as there are no examples around omap3isp cameras...

And an fgrep assigned-clock-rates shows not many use cases outside CPU/SoC
include files.

But interestingly arch/arm/boot/dts/at91sam9g25ek.dts uses it for an ovti,ov2640 camera...

So it seems that we just have to write:

	ov9655 at 30 {
		compatible = "ovti,ov9655";
		reg = <0x30>;
		clocks = <&isp 0>;	/* cam_clka */
		assigned-clocks = <&isp 0>;
		assigned-clock-rates = <24000000>;
	};

instead of introducing a new clock-frequency property and code to handle it.

Or do I misinterpret what "parents" and "clocks" are in this context?

BR and thanks,
Nikolaus