Re: [PATCH v5 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Ramiro,

On Mon, Dec 12, 2016 at 01:07:53PM +, Ramiro Oliveira wrote:
> Hi Sakari
> 
> On 12/12/2016 12:19 PM, Sakari Ailus wrote:
> > Hi Ramiro,
> > 
> > On Mon, Dec 12, 2016 at 12:15:04PM +, Ramiro Oliveira wrote:
> >> Hi Sakari
> >>
> >> On 12/12/2016 11:49 AM, Sakari Ailus wrote:
> >>> Hi Ramiro,
> >>>
> >>> On Mon, Dec 12, 2016 at 11:39:31AM +, Ramiro Oliveira wrote:
>  Hi Sakari,
> 
>  Thank you for the feedback.
> 
>  On 12/7/2016 10:33 PM, Sakari Ailus wrote:
> > Hi Ramiro,
> >
> > Thank you for the patch.
> >
> > On Mon, Dec 05, 2016 at 05:36:33PM +, Ramiro Oliveira wrote:
> >> Add device tree documentation.
> >>
> >> Signed-off-by: Ramiro Oliveira 
> >> ---
> >>  .../devicetree/bindings/media/i2c/ov5647.txt  | 19 
> >> +++
> >>  1 file changed, 19 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 000..4c91b3b
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >> @@ -0,0 +1,19 @@
> >> +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;
> >> +
> >> +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.
> >> +
> >> +Following properties are valid for the endpoint node:
> >> +
> >> +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered 
> >> in
> >> +  video-interfaces.txt.  The sensor supports only two data lanes.
> >
> > Doesn't this sensor require a external clock, a reset GPIO and / or a
> > regulator or a few? Do you need data-lanes, unless you can change the 
> > order
> > or the number?
> 
>  In the setup I'm using, I'm not aware of any reset GPIO or regulator. I 
>  do use a
>  external clock but it's fixed and not controlled by SW. Should I add a 
>  property
>  for this?
> >>>
> >>> The sensor datasheet defines a power-up and power-down sequence for the
> >>> device. If you don't implement these sequences in the driver on a DT based
> >>> system, nothing suggests that they're implemented correctly. Could it be
> >>> that the boot loader simply enables the regulators or another device
> >>> requires them to be enabled?
> >>>
> >>> I presume at least the reset GPIO should be controlled explicitly in order
> >>> to ensure correct function. Although hardware can be surprising: I have 
> >>> one
> >>> production system that has no reset GPIO for the sensor albeit the sensor
> >>> datasheet says that's part of the power up sequence.
> >>>
> >>
> >> Sorry for the misunderstanding. I wanted to say that, there is no SW 
> >> controlled
> >> reset. In the board we're using to connect the sensor to our D-PHY we have 
> >> a
> >> GPIO controller that when it receives power, it removes the sensor from 
> >> reset,
> >> so I have no control over that.
> > 
> > Do you mean to say that there's a GPIO controller but there's not (yet?) a
> > driver for that or that the reset line is actually hard-wired to something
> > else?
> > 
> 
> The reset line is hardwired to a GPIO controller that when powered-on removes
> the sensor from reset. However I have no control over the GPIO controller.

A GPIO controller is a piece of hardware that lets software to, typically,
both configure the direction and change and read the state of its input /
output pins. You seem to have something else on the board, such as chip
giving a power good signal.

If there really is no software control to to these resources, I suggest not
to implement the power up / down sequences as you can't test them anyway. We
can always add the DT properties (as optional) to the DT documentation.

You still should have the clock frequency in DT and check that in the
driver, even if you don't get a clock. Presumably your current register
lists assume a particular frequency but AFAIR that wasn't clearly visible
anywhere.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Sakari

On 12/12/2016 12:19 PM, Sakari Ailus wrote:
> Hi Ramiro,
> 
> On Mon, Dec 12, 2016 at 12:15:04PM +, Ramiro Oliveira wrote:
>> Hi Sakari
>>
>> On 12/12/2016 11:49 AM, Sakari Ailus wrote:
>>> Hi Ramiro,
>>>
>>> On Mon, Dec 12, 2016 at 11:39:31AM +, Ramiro Oliveira wrote:
 Hi Sakari,

 Thank you for the feedback.

 On 12/7/2016 10:33 PM, Sakari Ailus wrote:
> Hi Ramiro,
>
> Thank you for the patch.
>
> On Mon, Dec 05, 2016 at 05:36:33PM +, Ramiro Oliveira wrote:
>> Add device tree documentation.
>>
>> Signed-off-by: Ramiro Oliveira 
>> ---
>>  .../devicetree/bindings/media/i2c/ov5647.txt  | 19 
>> +++
>>  1 file changed, 19 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 000..4c91b3b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> @@ -0,0 +1,19 @@
>> +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;
>> +
>> +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.
>> +
>> +Following properties are valid for the endpoint node:
>> +
>> +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
>> +  video-interfaces.txt.  The sensor supports only two data lanes.
>
> Doesn't this sensor require a external clock, a reset GPIO and / or a
> regulator or a few? Do you need data-lanes, unless you can change the 
> order
> or the number?

 In the setup I'm using, I'm not aware of any reset GPIO or regulator. I do 
 use a
 external clock but it's fixed and not controlled by SW. Should I add a 
 property
 for this?
>>>
>>> The sensor datasheet defines a power-up and power-down sequence for the
>>> device. If you don't implement these sequences in the driver on a DT based
>>> system, nothing suggests that they're implemented correctly. Could it be
>>> that the boot loader simply enables the regulators or another device
>>> requires them to be enabled?
>>>
>>> I presume at least the reset GPIO should be controlled explicitly in order
>>> to ensure correct function. Although hardware can be surprising: I have one
>>> production system that has no reset GPIO for the sensor albeit the sensor
>>> datasheet says that's part of the power up sequence.
>>>
>>
>> Sorry for the misunderstanding. I wanted to say that, there is no SW 
>> controlled
>> reset. In the board we're using to connect the sensor to our D-PHY we have a
>> GPIO controller that when it receives power, it removes the sensor from 
>> reset,
>> so I have no control over that.
> 
> Do you mean to say that there's a GPIO controller but there's not (yet?) a
> driver for that or that the reset line is actually hard-wired to something
> else?
> 

The reset line is hardwired to a GPIO controller that when powered-on removes
the sensor from reset. However I have no control over the GPIO controller.

>>
>> Regarding the clock, should I create a new property?
> 
> Yes. The sensor does require a clock.
> 
>>
>> And also, regarding the data-lanes, AFAIK it isn't possible to change the 
>> order
>> of the data and clock lanes so should I remove that property?
> 
> Sounds good to me.
> 
>>

>
> An example DT snippet wouldn't hurt.

 Sure, I can add a example snippet.

>

>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Ramiro,

On Mon, Dec 12, 2016 at 12:15:04PM +, Ramiro Oliveira wrote:
> Hi Sakari
> 
> On 12/12/2016 11:49 AM, Sakari Ailus wrote:
> > Hi Ramiro,
> > 
> > On Mon, Dec 12, 2016 at 11:39:31AM +, Ramiro Oliveira wrote:
> >> Hi Sakari,
> >>
> >> Thank you for the feedback.
> >>
> >> On 12/7/2016 10:33 PM, Sakari Ailus wrote:
> >>> Hi Ramiro,
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Mon, Dec 05, 2016 at 05:36:33PM +, Ramiro Oliveira wrote:
>  Add device tree documentation.
> 
>  Signed-off-by: Ramiro Oliveira 
>  ---
>   .../devicetree/bindings/media/i2c/ov5647.txt  | 19 
>  +++
>   1 file changed, 19 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 000..4c91b3b
>  --- /dev/null
>  +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>  @@ -0,0 +1,19 @@
>  +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;
>  +
>  +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.
>  +
>  +Following properties are valid for the endpoint node:
>  +
>  +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
>  +  video-interfaces.txt.  The sensor supports only two data lanes.
> >>>
> >>> Doesn't this sensor require a external clock, a reset GPIO and / or a
> >>> regulator or a few? Do you need data-lanes, unless you can change the 
> >>> order
> >>> or the number?
> >>
> >> In the setup I'm using, I'm not aware of any reset GPIO or regulator. I do 
> >> use a
> >> external clock but it's fixed and not controlled by SW. Should I add a 
> >> property
> >> for this?
> > 
> > The sensor datasheet defines a power-up and power-down sequence for the
> > device. If you don't implement these sequences in the driver on a DT based
> > system, nothing suggests that they're implemented correctly. Could it be
> > that the boot loader simply enables the regulators or another device
> > requires them to be enabled?
> > 
> > I presume at least the reset GPIO should be controlled explicitly in order
> > to ensure correct function. Although hardware can be surprising: I have one
> > production system that has no reset GPIO for the sensor albeit the sensor
> > datasheet says that's part of the power up sequence.
> > 
> 
> Sorry for the misunderstanding. I wanted to say that, there is no SW 
> controlled
> reset. In the board we're using to connect the sensor to our D-PHY we have a
> GPIO controller that when it receives power, it removes the sensor from reset,
> so I have no control over that.

Do you mean to say that there's a GPIO controller but there's not (yet?) a
driver for that or that the reset line is actually hard-wired to something
else?

> 
> Regarding the clock, should I create a new property?

Yes. The sensor does require a clock.

> 
> And also, regarding the data-lanes, AFAIK it isn't possible to change the 
> order
> of the data and clock lanes so should I remove that property?

Sounds good to me.

> 
> >>
> >>>
> >>> An example DT snippet wouldn't hurt.
> >>
> >> Sure, I can add a example snippet.
> >>
> >>>
> >>
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Sakari

On 12/12/2016 11:49 AM, Sakari Ailus wrote:
> Hi Ramiro,
> 
> On Mon, Dec 12, 2016 at 11:39:31AM +, Ramiro Oliveira wrote:
>> Hi Sakari,
>>
>> Thank you for the feedback.
>>
>> On 12/7/2016 10:33 PM, Sakari Ailus wrote:
>>> Hi Ramiro,
>>>
>>> Thank you for the patch.
>>>
>>> On Mon, Dec 05, 2016 at 05:36:33PM +, Ramiro Oliveira wrote:
 Add device tree documentation.

 Signed-off-by: Ramiro Oliveira 
 ---
  .../devicetree/bindings/media/i2c/ov5647.txt  | 19 
 +++
  1 file changed, 19 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 000..4c91b3b
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
 @@ -0,0 +1,19 @@
 +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;
 +
 +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.
 +
 +Following properties are valid for the endpoint node:
 +
 +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
 +  video-interfaces.txt.  The sensor supports only two data lanes.
>>>
>>> Doesn't this sensor require a external clock, a reset GPIO and / or a
>>> regulator or a few? Do you need data-lanes, unless you can change the order
>>> or the number?
>>
>> In the setup I'm using, I'm not aware of any reset GPIO or regulator. I do 
>> use a
>> external clock but it's fixed and not controlled by SW. Should I add a 
>> property
>> for this?
> 
> The sensor datasheet defines a power-up and power-down sequence for the
> device. If you don't implement these sequences in the driver on a DT based
> system, nothing suggests that they're implemented correctly. Could it be
> that the boot loader simply enables the regulators or another device
> requires them to be enabled?
> 
> I presume at least the reset GPIO should be controlled explicitly in order
> to ensure correct function. Although hardware can be surprising: I have one
> production system that has no reset GPIO for the sensor albeit the sensor
> datasheet says that's part of the power up sequence.
> 

Sorry for the misunderstanding. I wanted to say that, there is no SW controlled
reset. In the board we're using to connect the sensor to our D-PHY we have a
GPIO controller that when it receives power, it removes the sensor from reset,
so I have no control over that.

Regarding the clock, should I create a new property?

And also, regarding the data-lanes, AFAIK it isn't possible to change the order
of the data and clock lanes so should I remove that property?

>>
>>>
>>> An example DT snippet wouldn't hurt.
>>
>> Sure, I can add a example snippet.
>>
>>>
>>
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Ramiro,

On Mon, Dec 12, 2016 at 11:39:31AM +, Ramiro Oliveira wrote:
> Hi Sakari,
> 
> Thank you for the feedback.
> 
> On 12/7/2016 10:33 PM, Sakari Ailus wrote:
> > Hi Ramiro,
> > 
> > Thank you for the patch.
> > 
> > On Mon, Dec 05, 2016 at 05:36:33PM +, Ramiro Oliveira wrote:
> >> Add device tree documentation.
> >>
> >> Signed-off-by: Ramiro Oliveira 
> >> ---
> >>  .../devicetree/bindings/media/i2c/ov5647.txt  | 19 
> >> +++
> >>  1 file changed, 19 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 000..4c91b3b
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >> @@ -0,0 +1,19 @@
> >> +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;
> >> +
> >> +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.
> >> +
> >> +Following properties are valid for the endpoint node:
> >> +
> >> +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
> >> +  video-interfaces.txt.  The sensor supports only two data lanes.
> > 
> > Doesn't this sensor require a external clock, a reset GPIO and / or a
> > regulator or a few? Do you need data-lanes, unless you can change the order
> > or the number?
> 
> In the setup I'm using, I'm not aware of any reset GPIO or regulator. I do 
> use a
> external clock but it's fixed and not controlled by SW. Should I add a 
> property
> for this?

The sensor datasheet defines a power-up and power-down sequence for the
device. If you don't implement these sequences in the driver on a DT based
system, nothing suggests that they're implemented correctly. Could it be
that the boot loader simply enables the regulators or another device
requires them to be enabled?

I presume at least the reset GPIO should be controlled explicitly in order
to ensure correct function. Although hardware can be surprising: I have one
production system that has no reset GPIO for the sensor albeit the sensor
datasheet says that's part of the power up sequence.

> 
> > 
> > An example DT snippet wouldn't hurt.
> 
> Sure, I can add a example snippet.
> 
> > 
> 

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Hi Sakari,

Thank you for the feedback.

On 12/7/2016 10:33 PM, Sakari Ailus wrote:
> Hi Ramiro,
> 
> Thank you for the patch.
> 
> On Mon, Dec 05, 2016 at 05:36:33PM +, Ramiro Oliveira wrote:
>> Add device tree documentation.
>>
>> Signed-off-by: Ramiro Oliveira 
>> ---
>>  .../devicetree/bindings/media/i2c/ov5647.txt  | 19 
>> +++
>>  1 file changed, 19 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 000..4c91b3b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>> @@ -0,0 +1,19 @@
>> +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;
>> +
>> +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.
>> +
>> +Following properties are valid for the endpoint node:
>> +
>> +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
>> +  video-interfaces.txt.  The sensor supports only two data lanes.
> 
> Doesn't this sensor require a external clock, a reset GPIO and / or a
> regulator or a few? Do you need data-lanes, unless you can change the order
> or the number?

In the setup I'm using, I'm not aware of any reset GPIO or regulator. I do use a
external clock but it's fixed and not controlled by SW. Should I add a property
for this?

> 
> An example DT snippet wouldn't hurt.

Sure, I can add a example snippet.

> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/2] Add OV5647 device tree documentation

[Sakari Ailus]

Hi Ramiro,

Thank you for the patch.

On Mon, Dec 05, 2016 at 05:36:33PM +, Ramiro Oliveira wrote:
> Add device tree documentation.
> 
> Signed-off-by: Ramiro Oliveira 
> ---
>  .../devicetree/bindings/media/i2c/ov5647.txt  | 19 
> +++
>  1 file changed, 19 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 000..4c91b3b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> @@ -0,0 +1,19 @@
> +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;
> +
> +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.
> +
> +Following properties are valid for the endpoint node:
> +
> +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
> +  video-interfaces.txt.  The sensor supports only two data lanes.

Doesn't this sensor require a external clock, a reset GPIO and / or a
regulator or a few? Do you need data-lanes, unless you can change the order
or the number?

An example DT snippet wouldn't hurt.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/2] Add OV5647 device tree documentation

[Ramiro Oliveira]

Add device tree documentation.

Signed-off-by: Ramiro Oliveira 
---
 .../devicetree/bindings/media/i2c/ov5647.txt  | 19 +++
 1 file changed, 19 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 000..4c91b3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
@@ -0,0 +1,19 @@
+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;
+
+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.
+
+Following properties are valid for the endpoint node:
+
+- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
+  video-interfaces.txt.  The sensor supports only two data lanes.
-- 
2.10.2


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html