From: Hugues FRUCHET <hugues.fruchet@st.com>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre TORGUE <alexandre.torgue@st.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
devicetree <devicetree@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"Benjamin Gaignard" <benjamin.gaignard@linaro.org>,
Yannick FERTRE <yannick.fertre@st.com>,
Discussions about the Letux Kernel
<letux-kernel@openphoenux.org>
Subject: Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module
Date: Mon, 26 Jun 2017 10:35:49 +0000 [thread overview]
Message-ID: <64e3005d-31df-71f2-762b-2c1b1152fc2d@st.com> (raw)
In-Reply-To: <D5629236-95D8-45B6-9719-E8B9796FEC90@goldelico.com>
On 06/23/2017 12:25 PM, H. Nikolaus Schaller wrote:
> Hi Hugues,
>
>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet <hugues.fruchet@st.com>:
>>
>> From: "H. Nikolaus Schaller" <hns@goldelico.com>
>>
>> This adds documentation of device tree bindings
>> for the OV965X family camera sensor module.
>>
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
>> ---
>> .../devicetree/bindings/media/i2c/ov965x.txt | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov965x.txt b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>> new file mode 100644
>> index 0000000..0e0de1f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov965x.txt
>> @@ -0,0 +1,37 @@
>> +* Omnivision OV9650/9652/9655 CMOS sensor
>> +
>> +The Omnivision OV965x sensor support multiple resolutions output, such as
>> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
>> +output format.
>> +
>> +Required Properties:
>> +- compatible: should be one of
>> + "ovti,ov9650"
>> + "ovti,ov9652"
>> + "ovti,ov9655"
>> +- clocks: reference to the mclk input clock.
>
> I wonder why you have removed the clock-frequency property?
>
> In some situations the camera driver must be able to tell the clock source
> which frequency it wants to see.
>
> For example we connect the camera to an OMAP3-ISP (image signal processor) and
> there it is assumed that camera modules know the frequency and set the clock, e.g.:
>
> http://elixir.free-electrons.com/linux/v4.4/source/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt#L52
> http://elixir.free-electrons.com/linux/v3.14/source/Documentation/devicetree/bindings/media/i2c/mt9p031.txt
>
> If your clock is constant and defined elsewhere we should make this
> property optional instead of required. But it should not be missing.
>
> Here is a hack to get it into your code:
>
> http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=drivers/media/i2c/ov9650.c;h=b7ab46c775b9e40087e427ae0777e9f7c283694a;hp=1846bcbb19ae71ce686dade320aa06ce2e429ca4;hb=ca85196f6fd9a77e5a0f796aeaf7aa2cde60ce91;hpb=8a71f21b75543a6d99102be1ae4677b28c478ac9
>
Here is how it is used on my DT, the camera clock is a fixed crystal 24M
clock:
+ clocks {
+ clk_ext_camera: clk-ext-camera {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ };
+ };
[...]
+ ov9655: camera@30 {
+ compatible = "ovti,ov9655";
+ reg = <0x30>;
+ pwdn-gpios = <&gpioh 13 GPIO_ACTIVE_HIGH>;
+ clocks = <&clk_ext_camera>;
+ status = "okay";
+
+ port {
+ ov9655_0: endpoint {
+ remote-endpoint = <&dcmi_0>;
+ };
+ };
+ };
>> +
>> +Optional Properties:
>> +- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
>> +- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
>
> Here I wonder why you did split that up into two gpios. Each "*-gpios" can have
> multiple entries and if one is not used, a 0 can be specified to make it being ignored.
>
> But it is up to DT maintainers what they prefer: separate single gpios or a single gpio array.
I have followed the ov2640 binding, which have the same pins naming
(resetb/pwdn).
As far as I see, separate single gpios are commonly used in
Documentation/devicetree/bindings/media/i2c/
>
>
> What I am missing to support the GTA04 camera is the control of the optional "vana-supply".
> So the driver does not power up the camera module when needed and therefore probing fails.
>
> - vana-supply: a regulator to power up the camera module.
>
> Driver code is not complex to add:
>
> http://git.goldelico.com/?p=gta04-kernel.git;a=blobdiff;f=drivers/media/i2c/ov9650.c;h=1846bcbb19ae71ce686dade320aa06ce2e429ca4;hp=c0819afdcefcb19da351741d51dad00aaf909254;hb=8a71f21b75543a6d99102be1ae4677b28c478ac9;hpb=6db55fc472eea2ec6db03833df027aecf6649f88
Yes, I saw it in your code, but as I don't have any programmable power
supply on my setup, I have not pushed this commit.
And I also don't have a clock to enable/disable -fixed clock-, I need to
check the behaviour when disabling/enabling a fixed clock, I will give
it a try.
>
>> +
>> +The device node must contain one 'port' child node for its digital output
>> +video port, in accordance with the video interface bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +Example:
>> +
>> +&i2c2 {
>> + ov9655: camera@30 {
>> + compatible = "ovti,ov9655";
>> + reg = <0x30>;
>> + pwdn-gpios = <&gpioh 13 GPIO_ACTIVE_HIGH>;
>> + clocks = <&clk_ext_camera>;
>> +
>> + port {
>> + ov9655: endpoint {
>> + remote-endpoint = <&dcmi_0>;
>> + };
>> + };
>> + };
>> +};
>> --
>> 1.9.1
>>
>
> BR and thanks,
> Nikolaus
>
next prev parent reply other threads:[~2017-06-26 10:36 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-22 15:05 [PATCH v1 0/6] Add support of OV9655 camera Hugues Fruchet
2017-06-22 15:05 ` [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module Hugues Fruchet
2017-06-23 10:25 ` H. Nikolaus Schaller
2017-06-23 10:46 ` Andreas Färber
2017-06-23 10:59 ` H. Nikolaus Schaller
2017-06-23 11:58 ` Laurent Pinchart
2017-06-23 14:53 ` H. Nikolaus Schaller
2017-06-23 14:57 ` Andreas Färber
2017-06-23 15:22 ` H. Nikolaus Schaller
2017-06-23 18:05 ` Suman Anna
2017-06-23 18:59 ` H. Nikolaus Schaller
2017-06-23 22:24 ` Suman Anna
2017-06-26 6:00 ` H. Nikolaus Schaller
2017-06-26 10:35 ` Hugues FRUCHET [this message]
2017-06-26 20:04 ` Sylwester Nawrocki
2017-06-27 5:48 ` H. Nikolaus Schaller
2017-06-27 22:57 ` Sylwester Nawrocki
2017-06-28 9:12 ` H. Nikolaus Schaller
2017-06-28 10:50 ` Sylwester Nawrocki
2017-06-28 11:24 ` H. Nikolaus Schaller
2017-06-28 12:28 ` Hugues FRUCHET
2017-06-26 18:56 ` Rob Herring
2017-06-26 18:54 ` Rob Herring
2017-06-22 15:05 ` [PATCH v1 2/6] [media] ov9650: add device tree support Hugues Fruchet
2017-06-26 16:31 ` Sakari Ailus
2017-06-26 17:46 ` H. Nikolaus Schaller
2017-06-27 5:36 ` Sakari Ailus
2017-06-27 10:14 ` Hugues FRUCHET
2017-06-22 15:05 ` [PATCH v1 3/6] [media] ov9650: select the nearest higher resolution Hugues Fruchet
2017-06-22 15:05 ` [PATCH v1 4/6] [media] ov9650: use write_array() for resolution sequences Hugues Fruchet
2017-06-26 16:33 ` Sakari Ailus
2017-06-29 13:59 ` Hugues FRUCHET
2017-06-22 15:05 ` [PATCH v1 5/6] [media] ov9650: add multiple variant support Hugues Fruchet
2017-06-25 12:36 ` kbuild test robot
2017-06-22 15:05 ` [PATCH v1 6/6] [media] ov9650: add support of OV9655 variant Hugues Fruchet
2017-06-25 16:07 ` [PATCH] ov9650: fix semicolon.cocci warnings kbuild test robot
2017-06-25 16:07 ` [PATCH v1 6/6] [media] ov9650: add support of OV9655 variant kbuild test robot
2017-06-26 6:03 ` H. Nikolaus Schaller
2017-06-26 11:49 ` Hugues FRUCHET
2017-06-22 15:41 ` [PATCH v1 0/6] Add support of OV9655 camera H. Nikolaus Schaller
2017-06-23 10:25 ` H. Nikolaus Schaller
2017-06-25 9:18 ` omap3isp camera was " Pavel Machek
2017-06-26 6:05 ` H. Nikolaus Schaller
2017-06-26 8:39 ` Pavel Machek
2017-06-26 9:53 ` H. Nikolaus Schaller
2017-06-26 11:16 ` Pavel Machek
2017-06-27 5:49 ` H. Nikolaus Schaller
2017-06-26 13:19 ` Hugues FRUCHET
[not found] ` <E4E1E683-9CD0-4F23-AB03-080C52D0D73B@goldelico.com>
2017-06-27 7:57 ` Hugues FRUCHET
[not found] ` <95B10899-9966-4844-9667-D2434968A492@goldelico.com>
[not found] ` <85e62c47-e319-c801-376c-95f4d9cbf75a@st.com>
[not found] ` <E183E921-B8F4-4F8A-A302-58297A874990@goldelico.com>
[not found] ` <77bd3b8fe52643d68ecc821ec22bc0e6@SFHDAG5NODE1.st.com>
2017-07-01 21:00 ` H. Nikolaus Schaller
2017-07-03 8:16 ` Hugues FRUCHET
2017-07-03 9:14 ` H. Nikolaus Schaller
2017-07-03 12:03 ` Hugues FRUCHET
2017-07-03 12:23 ` H. Nikolaus Schaller
2017-07-05 14:02 ` H. Nikolaus Schaller
2017-07-08 20:55 ` Sakari Ailus
2017-06-26 6:02 ` H. Nikolaus Schaller
2017-06-26 10:05 ` Hugues FRUCHET
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64e3005d-31df-71f2-762b-2c1b1152fc2d@st.com \
--to=hugues.fruchet@st.com \
--cc=alexandre.torgue@st.com \
--cc=benjamin.gaignard@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=g.liakhovetski@gmx.de \
--cc=hns@goldelico.com \
--cc=hverkuil@xs4all.nl \
--cc=letux-kernel@openphoenux.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mchehab@kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=robh+dt@kernel.org \
--cc=sylvester.nawrocki@gmail.com \
--cc=yannick.fertre@st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).