[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <74EE8B20-84A2-4579-ACBE-32E55CECE1C5@goldelico.com>
Date: Fri, 23 Jun 2017 20:59:28 +0200
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Suman Anna <s-anna@...com>,
Andreas Färber <afaerber@...e.de>,
Hugues Fruchet <hugues.fruchet@...com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Mark Rutland <mark.rutland@....com>,
devicetree <devicetree@...r.kernel.org>,
Benjamin Gaignard <benjamin.gaignard@...aro.org>,
Discussions about the Letux Kernel
<letux-kernel@...nphoenux.org>,
Alexandre Torgue <alexandre.torgue@...com>,
LKML <linux-kernel@...r.kernel.org>,
Hans Verkuil <hverkuil@...all.nl>,
Rob Herring <robh+dt@...nel.org>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Yannick Fertre <yannick.fertre@...com>,
Sylwester Nawrocki <sylvester.nawrocki@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Guennadi Liakhovetski <g.liakhovetski@....de>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
linux-media@...r.kernel.org
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Hi Suman,
> Am 23.06.2017 um 20:05 schrieb Suman Anna <s-anna@...com>:
>
>>>>
>>>> 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@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
Powered by blists - more mailing lists