On 02/08/2013 03:29 PM, Sylwester Nawrocki wrote:

On 02/07/2013 12:36 AM, Stephen Warren wrote:

quoted

On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote:

quoted

s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC
device. This patch support for binding the driver to the MIPI-CSIS
devices instantiated from device tree and for parsing all SoC and
board specific properties.

quoted

diff --git
a/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt

b/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt

quoted

+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock frequency in
Hz, default
+            value when this property is not specified is 166 MHz;

Shouldn't this be a "clocks" property, so that the driver can call
clk_get(), clk_prepare_enable(), clk_get_rate(), etc. on it?

Hi Stephen,

Thanks for your review!

I also use "clocks" and "clock-names" property, but didn't specify
it here, because the Exynos SoCs clocks driver is not in the mainline yet.

I'm a bit sympathetic to this, since I've been trying to push Tegra
towards the common clock framework and describing clock connectivity in
DT, before adding new drivers that need clocks, specifically to avoid
this kind of situation.

The problem here is that if this gets merged now, then the clock driver
comes along later, you'll have to change this binding definition to
account for it, and DT bindings aren't supposed to be changed...

Do you have any clock driver at all upstream yet? Or, could you add a
dummy clock driver to satisfy the driver's clkl_get() needs? If you do,
you can always set up some AUXDATA so that clk_get() works for your
driver right now, and then remove that once the complete clock driver is
in place with full device tree support. That's how we've ended up
handling this for Tegra drivers.

Anyway, this is all mainly food-for-thought rather than an objection to
the patch; I'd leave that to Grant/Rob if applicable.