linux-kernel - Re: [PATCH v9 1/2] Add OV5647 device tree documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cc6c914e-c3e7-7703-0405-104e701610cf@mentor.com>
Date:   Tue, 21 Feb 2017 22:48:09 +0200
From:   Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
To:     Ramiro Oliveira <Ramiro.Oliveira@...opsys.com>,
        <linux-kernel@...r.kernel.org>, <linux-media@...r.kernel.org>,
        <devicetree@...r.kernel.org>
CC:     <CARLOS.PALMINHA@...opsys.com>, Arnd Bergmann <arnd@...db.de>,
        "David S. Miller" <davem@...emloft.net>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Mark Rutland <mark.rutland@....com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Pali Rohár <pali.rohar@...il.com>,
        Pavel Machek <pavel@....cz>,
        Robert Jarzmik <robert.jarzmik@...e.fr>,
        Rob Herring <robh+dt@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Steve Longerbeam <slongerbeam@...il.com>
Subject: Re: [PATCH v9 1/2] Add OV5647 device tree documentation

Hi Ramiro,

On 02/21/2017 10:13 PM, Ramiro Oliveira wrote:
> Hi Vladimir,
> 
> Thank you for your feedback
> 
> On 2/21/2017 3:58 PM, Vladimir Zapolskiy wrote:
>> Hi Ramiro,
>>
>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote:
>>> Create device tree bindings documentation.
>>>
>>> Signed-off-by: Ramiro Oliveira <roliveir@...opsys.com>
>>> Acked-by: Rob Herring <robh@...nel.org>
>>> ---
>>>  .../devicetree/bindings/media/i2c/ov5647.txt       | 35 ++++++++++++++++++++++
>>>  1 file changed, 35 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>> new file mode 100644
>>> index 000000000000..31956426d3b9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>> @@ -0,0 +1,35 @@
>>> +Omnivision OV5647 raw image sensor
>>> +---------------------------------
>>> +
>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>> +and CCI (I2C compatible) control bus.
>>> +
>>> +Required properties:
>>> +
>>> +- compatible		: "ovti,ov5647".
>>> +- reg			: I2C slave address of the sensor.
>>> +- clocks		: Reference to the xclk clock.
>>
>> Is "xclk" clock a pixel clock or something else?
>>
> 
> It's an external oscillator.

hmm, I suppose a clock of any type could serve as a clock for the sensor.
It can be an external oscillator on a particular board, or it can be
something else on another board.

Can you please describe what for does ov5647 sensor need this clock, what
is its function?

> 
>>> +- clock-names		: Should be "xclk".
>>
>> You can remove this property, because there is only one source clock.
>>
> 
> Ok.
> 
>>> +- clock-frequency	: Frequency of the xclk clock.
>>
>> And after the last updates in the driver this property can be removed as well.
>>
> 
> But I'm still using clk_get_rate in the driver, if I remove the frequency here
> the probing will fail.
> 

I doubt it, there should be no connection between a custom "clock-frequency"
device tree property in a clock consumer device node and clk_get_rate() function
from the CCF, which takes a clock provider as its argument.

>>> +
>>> +The common video interfaces bindings (see video-interfaces.txt) should be
>>> +used to specify link to the image data receiver. The OV5647 device
>>> +node should contain one 'port' child node with an 'endpoint' subnode.
>>> +
>>> +Example:
>>> +
>>> +	i2c@...0 {
>>> +		...
>>> +		ov: camera@36 {
>>> +			compatible = "ovti,ov5647";
>>> +			reg = <0x36>;
>>> +			clocks = <&camera_clk>;
>>> +			clock-names = "xclk";
>>> +			clock-frequency = <25000000>;
>>
>> When you remove two unused properties, please don't forget to update the
>> example.
>>
> 
> Ok.
> 
>>> +			port {
>>> +				camera_1: endpoint {
>>> +					remote-endpoint = <&csi1_ep1>;
>>> +				};
>>> +			};
>>> +		};
>>> +	};
>>>
>>

--
With best wishes,
Vladimir