* [PATCH v9 0/2] Add support for Omnivision OV5647 @ 2017-02-17 13:14 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-17 13:14 UTC (permalink / raw) To: linux-kernel, linux-media, devicetree Cc: vladimir_zapolskiy, CARLOS.PALMINHA, Ramiro Oliveira, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hello, This patchset adds support for the Omnivision OV5647 sensor. At the moment it only supports 640x480 in RAW 8. This is the ninth version of the OV5647 camera driver patchset. v9: - Remove unused struct - Remove comments - Refactor error handling in i2c r/w functions - Change declarations to single line. - Remove value assignment in variable declarion - Refactor configurion write loop - Change the variable type that received ov5647_read() read value - Remove print from probe function - Remove unused device struct - Remove OF dependency from Kconfig Suggested-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> v8: - Remove a part of the initialization procedure which wasn't doing anything - Check for i2c read/writes return values - Add stream_on/off functions Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> v7: - Remove "0x" and leading 0 from DT documentation examples v6: - Add example to DT documentation - Remove data-lanes and clock-lane property from DT - Add external clock property to DT - Order includes - Remove unused variables and functions - Add external clock handling - Add power on counter - Change from g/s_parm to g/s_frame_interval v5: - Refactor code - Change comments - Add missing error handling in some functions v4: - Add correct license - Revert debugging info to generic infrastructure - Turn defines into enums - Correct code style issues - Remove unused defines - Make sure all errors where being handled - Rename some functions to make code more readable - Add some debugging info v3: - No changes. Re-submitted due to lack of responses v2: - Corrections in DT documentation Ramiro Oliveira (2): Add OV5647 device tree documentation Add support for OV5647 sensor. .../devicetree/bindings/media/i2c/ov5647.txt | 35 ++ MAINTAINERS | 7 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile | 1 + drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++ 5 files changed, 692 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt create mode 100644 drivers/media/i2c/ov5647.c -- 2.11.0 ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v9 0/2] Add support for Omnivision OV5647 @ 2017-02-17 13:14 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-17 13:14 UTC (permalink / raw) To: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Ramiro Oliveira, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hello, This patchset adds support for the Omnivision OV5647 sensor. At the moment it only supports 640x480 in RAW 8. This is the ninth version of the OV5647 camera driver patchset. v9: - Remove unused struct - Remove comments - Refactor error handling in i2c r/w functions - Change declarations to single line. - Remove value assignment in variable declarion - Refactor configurion write loop - Change the variable type that received ov5647_read() read value - Remove print from probe function - Remove unused device struct - Remove OF dependency from Kconfig Suggested-by: Vladimir Zapolskiy <vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> v8: - Remove a part of the initialization procedure which wasn't doing anything - Check for i2c read/writes return values - Add stream_on/off functions Suggested-by: Sakari Ailus <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> v7: - Remove "0x" and leading 0 from DT documentation examples v6: - Add example to DT documentation - Remove data-lanes and clock-lane property from DT - Add external clock property to DT - Order includes - Remove unused variables and functions - Add external clock handling - Add power on counter - Change from g/s_parm to g/s_frame_interval v5: - Refactor code - Change comments - Add missing error handling in some functions v4: - Add correct license - Revert debugging info to generic infrastructure - Turn defines into enums - Correct code style issues - Remove unused defines - Make sure all errors where being handled - Rename some functions to make code more readable - Add some debugging info v3: - No changes. Re-submitted due to lack of responses v2: - Corrections in DT documentation Ramiro Oliveira (2): Add OV5647 device tree documentation Add support for OV5647 sensor. .../devicetree/bindings/media/i2c/ov5647.txt | 35 ++ MAINTAINERS | 7 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile | 1 + drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++ 5 files changed, 692 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt create mode 100644 drivers/media/i2c/ov5647.c -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v9 1/2] Add OV5647 device tree documentation 2017-02-17 13:14 ` Ramiro Oliveira (?) @ 2017-02-17 13:14 ` Ramiro Oliveira 2017-02-21 11:57 ` Sakari Ailus 2017-02-21 15:58 ` Vladimir Zapolskiy -1 siblings, 2 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-17 13:14 UTC (permalink / raw) To: linux-kernel, linux-media, devicetree Cc: vladimir_zapolskiy, CARLOS.PALMINHA, Ramiro Oliveira, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Create device tree bindings documentation. Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> Acked-by: Rob Herring <robh@kernel.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. +- clock-names : Should be "xclk". +- clock-frequency : Frequency of the xclk clock. + +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@2000 { + ... + ov: camera@36 { + compatible = "ovti,ov5647"; + reg = <0x36>; + clocks = <&camera_clk>; + clock-names = "xclk"; + clock-frequency = <25000000>; + port { + camera_1: endpoint { + remote-endpoint = <&csi1_ep1>; + }; + }; + }; + }; -- 2.11.0 ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 11:57 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-21 11:57 UTC (permalink / raw) To: Ramiro Oliveira Cc: linux-kernel, linux-media, devicetree, vladimir_zapolskiy, CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, On Fri, Feb 17, 2017 at 01:14:15PM +0000, Ramiro Oliveira wrote: > Create device tree bindings documentation. > > Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> > Acked-by: Rob Herring <robh@kernel.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. > +- clock-names : Should be "xclk". > +- clock-frequency : Frequency of the xclk clock. > + > +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. The remote-endpoint property in endpoint nodes should be mandatory, shouldn't it? Otherwise the sensor isn't connected to anything and hardly useful as such. The list of optional endpoint properties is a long one and it should be documented here which ones are recognised, either as optional or mandatory. > + > +Example: > + > + i2c@2000 { > + ... > + ov: camera@36 { > + compatible = "ovti,ov5647"; > + reg = <0x36>; > + clocks = <&camera_clk>; > + clock-names = "xclk"; > + clock-frequency = <25000000>; > + port { > + camera_1: endpoint { > + remote-endpoint = <&csi1_ep1>; > + }; > + }; > + }; > + }; -- Kind regards, Sakari Ailus e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 11:57 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-21 11:57 UTC (permalink / raw) To: Ramiro Oliveira Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, On Fri, Feb 17, 2017 at 01:14:15PM +0000, Ramiro Oliveira wrote: > Create device tree bindings documentation. > > Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. > +- clock-names : Should be "xclk". > +- clock-frequency : Frequency of the xclk clock. > + > +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. The remote-endpoint property in endpoint nodes should be mandatory, shouldn't it? Otherwise the sensor isn't connected to anything and hardly useful as such. The list of optional endpoint properties is a long one and it should be documented here which ones are recognised, either as optional or mandatory. > + > +Example: > + > + i2c@2000 { > + ... > + ov: camera@36 { > + compatible = "ovti,ov5647"; > + reg = <0x36>; > + clocks = <&camera_clk>; > + clock-names = "xclk"; > + clock-frequency = <25000000>; > + port { > + camera_1: endpoint { > + remote-endpoint = <&csi1_ep1>; > + }; > + }; > + }; > + }; -- Kind regards, Sakari Ailus e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation 2017-02-21 11:57 ` Sakari Ailus (?) @ 2017-02-21 14:30 ` Ramiro Oliveira 2017-02-21 14:40 ` Sakari Ailus -1 siblings, 1 reply; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-21 14:30 UTC (permalink / raw) To: Sakari Ailus, Ramiro Oliveira Cc: linux-kernel, linux-media, devicetree, vladimir_zapolskiy, CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Sakari, Thank you for your feedback. On 2/21/2017 11:57 AM, Sakari Ailus wrote: > Hi Ramiro, > > On Fri, Feb 17, 2017 at 01:14:15PM +0000, Ramiro Oliveira wrote: >> Create device tree bindings documentation. >> >> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> >> Acked-by: Rob Herring <robh@kernel.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. >> +- clock-names : Should be "xclk". >> +- clock-frequency : Frequency of the xclk clock. >> + >> +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. > > The remote-endpoint property in endpoint nodes should be mandatory, > shouldn't it? Otherwise the sensor isn't connected to anything and hardly > useful as such. The list of optional endpoint properties is a long one and > it should be documented here which ones are recognised, either as optional > or mandatory. > I guess you're right, it should be mandatory, although at the moment I'm not checking for it's presence in the driver so I'll add it to the driver. At the moment that's the only property I think it should be mandatory, and I don't believe I need any optional one. Do you have a suggestion for any new property I should use? >> + >> +Example: >> + >> + i2c@2000 { >> + ... >> + ov: camera@36 { >> + compatible = "ovti,ov5647"; >> + reg = <0x36>; >> + clocks = <&camera_clk>; >> + clock-names = "xclk"; >> + clock-frequency = <25000000>; >> + port { >> + camera_1: endpoint { >> + remote-endpoint = <&csi1_ep1>; >> + }; >> + }; >> + }; >> + }; > -- Best Regards Ramiro Oliveira Ramiro.Oliveira@synopsys.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 14:40 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-21 14:40 UTC (permalink / raw) To: Ramiro Oliveira Cc: linux-kernel, linux-media, devicetree, vladimir_zapolskiy, CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, On Tue, Feb 21, 2017 at 02:30:16PM +0000, Ramiro Oliveira wrote: > Hi Sakari, > > Thank you for your feedback. > > On 2/21/2017 11:57 AM, Sakari Ailus wrote: > > Hi Ramiro, > > > > On Fri, Feb 17, 2017 at 01:14:15PM +0000, Ramiro Oliveira wrote: > >> Create device tree bindings documentation. > >> > >> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> > >> Acked-by: Rob Herring <robh@kernel.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. > >> +- clock-names : Should be "xclk". > >> +- clock-frequency : Frequency of the xclk clock. > >> + > >> +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. > > > > The remote-endpoint property in endpoint nodes should be mandatory, > > shouldn't it? Otherwise the sensor isn't connected to anything and hardly > > useful as such. The list of optional endpoint properties is a long one and > > it should be documented here which ones are recognised, either as optional > > or mandatory. > > > > I guess you're right, it should be mandatory, although at the moment I'm not > checking for it's presence in the driver so I'll add it to the driver. > > At the moment that's the only property I think it should be mandatory, and I > don't believe I need any optional one. > > Do you have a suggestion for any new property I should use? As you don't need any in the driver for the driver to work, you can omit them. -- Regards, Sakari Ailus e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 14:40 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-21 14:40 UTC (permalink / raw) To: Ramiro Oliveira Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, On Tue, Feb 21, 2017 at 02:30:16PM +0000, Ramiro Oliveira wrote: > Hi Sakari, > > Thank you for your feedback. > > On 2/21/2017 11:57 AM, Sakari Ailus wrote: > > Hi Ramiro, > > > > On Fri, Feb 17, 2017 at 01:14:15PM +0000, Ramiro Oliveira wrote: > >> Create device tree bindings documentation. > >> > >> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> > >> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. > >> +- clock-names : Should be "xclk". > >> +- clock-frequency : Frequency of the xclk clock. > >> + > >> +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. > > > > The remote-endpoint property in endpoint nodes should be mandatory, > > shouldn't it? Otherwise the sensor isn't connected to anything and hardly > > useful as such. The list of optional endpoint properties is a long one and > > it should be documented here which ones are recognised, either as optional > > or mandatory. > > > > I guess you're right, it should be mandatory, although at the moment I'm not > checking for it's presence in the driver so I'll add it to the driver. > > At the moment that's the only property I think it should be mandatory, and I > don't believe I need any optional one. > > Do you have a suggestion for any new property I should use? As you don't need any in the driver for the driver to work, you can omit them. -- Regards, Sakari Ailus e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 15:58 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-21 15:58 UTC (permalink / raw) To: Ramiro Oliveira, linux-kernel, linux-media, devicetree Cc: CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: > Create device tree bindings documentation. > > Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> > Acked-by: Rob Herring <robh@kernel.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? > +- clock-names : Should be "xclk". You can remove this property, because there is only one source clock. > +- clock-frequency : Frequency of the xclk clock. And after the last updates in the driver this property can be removed as well. > + > +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@2000 { > + ... > + 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. > + port { > + camera_1: endpoint { > + remote-endpoint = <&csi1_ep1>; > + }; > + }; > + }; > + }; > -- With best wishes, Vladimir ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 15:58 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-21 15:58 UTC (permalink / raw) To: Ramiro Oliveira, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: > Create device tree bindings documentation. > > Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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? > +- clock-names : Should be "xclk". You can remove this property, because there is only one source clock. > +- clock-frequency : Frequency of the xclk clock. And after the last updates in the driver this property can be removed as well. > + > +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@2000 { > + ... > + 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. > + port { > + camera_1: endpoint { > + remote-endpoint = <&csi1_ep1>; > + }; > + }; > + }; > + }; > -- With best wishes, Vladimir -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 20:13 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-21 20:13 UTC (permalink / raw) To: Vladimir Zapolskiy, Ramiro Oliveira, linux-kernel, linux-media, devicetree Cc: CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam 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@synopsys.com> >> Acked-by: Rob Herring <robh@kernel.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. >> +- 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. >> + >> +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@2000 { >> + ... >> + 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 > -- Best Regards Ramiro Oliveira Ramiro.Oliveira@synopsys.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 20:13 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-21 20:13 UTC (permalink / raw) To: Vladimir Zapolskiy, Ramiro Oliveira, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam 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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> >> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. >> +- 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. >> + >> +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@2000 { >> + ... >> + 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 > -- Best Regards Ramiro Oliveira Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation 2017-02-21 20:13 ` Ramiro Oliveira @ 2017-02-21 20:48 ` Vladimir Zapolskiy -1 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-21 20:48 UTC (permalink / raw) To: Ramiro Oliveira, linux-kernel, linux-media, devicetree Cc: CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam 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@synopsys.com> >>> Acked-by: Rob Herring <robh@kernel.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@2000 { >>> + ... >>> + 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 20:48 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-21 20:48 UTC (permalink / raw) To: Ramiro Oliveira, linux-kernel, linux-media, devicetree Cc: CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam 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@synopsys.com> >>> Acked-by: Rob Herring <robh@kernel.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@2000 { >>> + ... >>> + 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>; >>> + }; >>> + }; >>> + }; >>> + }; >>> >> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 21:48 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-21 21:48 UTC (permalink / raw) To: Vladimir Zapolskiy Cc: Ramiro Oliveira, linux-kernel, linux-media, devicetree, CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi, Vladimir! How do you do? :-) On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: > 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@synopsys.com> > >>> Acked-by: Rob Herring <robh@kernel.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. Any clock source could be used I presume. > > Can you please describe what for does ov5647 sensor need this clock, what > is its function? Camera modules (sensors) quite commonly require an external clock as they do not have an oscillator on their own. A lot of devices under Documentation/devicetree/bindings/media/i2c/ have similar properties. > > > > >>> +- 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 purpose is to make sure the clock frequency is really usable for the device, in this particular case the driver can work with one particular frequency. That said, the driver does not appear to use the property at the moment. It should. It'd be good to verify that the rate matches: clk_set_rate() is not guaranteed to produce the requested clock rate, and the driver could conceivably be updated with support for more frequencies. There are typically a few frequencies that a SoC such a sensor is connected can support, and 25 MHz is not one of the common frequencies. With this property, the frequency would be always there explicitly. > > >>> + > >>> +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@2000 { > >>> + ... > >>> + 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>; > >>> + }; > >>> + }; > >>> + }; > >>> + }; > >>> > >> > > -- ^ There's a space missing here. > With best wishes, > Vladimir -- Kind regards, Sakari Ailus e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 21:48 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-21 21:48 UTC (permalink / raw) To: Vladimir Zapolskiy Cc: Ramiro Oliveira, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi, Vladimir! How do you do? :-) On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: > 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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> > >>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. Any clock source could be used I presume. > > Can you please describe what for does ov5647 sensor need this clock, what > is its function? Camera modules (sensors) quite commonly require an external clock as they do not have an oscillator on their own. A lot of devices under Documentation/devicetree/bindings/media/i2c/ have similar properties. > > > > >>> +- 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 purpose is to make sure the clock frequency is really usable for the device, in this particular case the driver can work with one particular frequency. That said, the driver does not appear to use the property at the moment. It should. It'd be good to verify that the rate matches: clk_set_rate() is not guaranteed to produce the requested clock rate, and the driver could conceivably be updated with support for more frequencies. There are typically a few frequencies that a SoC such a sensor is connected can support, and 25 MHz is not one of the common frequencies. With this property, the frequency would be always there explicitly. > > >>> + > >>> +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@2000 { > >>> + ... > >>> + 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>; > >>> + }; > >>> + }; > >>> + }; > >>> + }; > >>> > >> > > -- ^ There's a space missing here. > With best wishes, > Vladimir -- Kind regards, Sakari Ailus e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 22:37 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-21 22:37 UTC (permalink / raw) To: Sakari Ailus Cc: Ramiro Oliveira, linux-kernel, linux-media, devicetree, CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Sakari, On 02/21/2017 11:48 PM, Sakari Ailus wrote: > Hi, Vladimir! > > How do you do? :-) deferring execution of boring tasks by doing code review :) > On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: >> 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@synopsys.com> >>>>> Acked-by: Rob Herring <robh@kernel.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. > > Any clock source could be used I presume. > That's exactly my point, and it is a reason to rename "xclk" to something more generic. >> >> Can you please describe what for does ov5647 sensor need this clock, what >> is its function? > > Camera modules (sensors) quite commonly require an external clock as they do > not have an oscillator on their own. A lot of devices under > Documentation/devicetree/bindings/media/i2c/ have similar properties. > So, what should be a better replacement of "xclk" in the description above? E.g. - clocks : Phandle to a device supply clock. >> >>> >>>>> +- clock-names : Should be "xclk". We got an agreement that "clock-names" property is removed, nevertheless if it is added back, is should not 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 purpose is to make sure the clock frequency is really usable for the > device, in this particular case the driver can work with one particular > frequency. > > That said, the driver does not appear to use the property at the moment. It > should. > > It'd be good to verify that the rate matches: clk_set_rate() is not > guaranteed to produce the requested clock rate, and the driver could > conceivably be updated with support for more frequencies. There are > typically a few frequencies that a SoC such a sensor is connected can > support, and 25 MHz is not one of the common frequencies. With this > property, the frequency would be always there explicitly. > I can provide my arguments given at v8 review time again, since I don't see a contradiction with my older comments. Briefly "clock-frequency" as a device tree property on a consumer side can be considered as redundant, because there is a mechanism to specify a wanted clock frequency on a clock provider side right in a board DTB. So, the clock frequency set up is delegated to CCF, and when any other than 25 MHz frequencies are got supported, that's only the matter of driver updates, DTBs won't be touched. -- With best wishes, Vladimir ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-21 22:37 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-21 22:37 UTC (permalink / raw) To: Sakari Ailus Cc: Ramiro Oliveira, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus Hi Sakari, On 02/21/2017 11:48 PM, Sakari Ailus wrote: > Hi, Vladimir! > > How do you do? :-) deferring execution of boring tasks by doing code review :) > On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: >> 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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> >>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. > > Any clock source could be used I presume. > That's exactly my point, and it is a reason to rename "xclk" to something more generic. >> >> Can you please describe what for does ov5647 sensor need this clock, what >> is its function? > > Camera modules (sensors) quite commonly require an external clock as they do > not have an oscillator on their own. A lot of devices under > Documentation/devicetree/bindings/media/i2c/ have similar properties. > So, what should be a better replacement of "xclk" in the description above? E.g. - clocks : Phandle to a device supply clock. >> >>> >>>>> +- clock-names : Should be "xclk". We got an agreement that "clock-names" property is removed, nevertheless if it is added back, is should not 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 purpose is to make sure the clock frequency is really usable for the > device, in this particular case the driver can work with one particular > frequency. > > That said, the driver does not appear to use the property at the moment. It > should. > > It'd be good to verify that the rate matches: clk_set_rate() is not > guaranteed to produce the requested clock rate, and the driver could > conceivably be updated with support for more frequencies. There are > typically a few frequencies that a SoC such a sensor is connected can > support, and 25 MHz is not one of the common frequencies. With this > property, the frequency would be always there explicitly. > I can provide my arguments given at v8 review time again, since I don't see a contradiction with my older comments. Briefly "clock-frequency" as a device tree property on a consumer side can be considered as redundant, because there is a mechanism to specify a wanted clock frequency on a clock provider side right in a board DTB. So, the clock frequency set up is delegated to CCF, and when any other than 25 MHz frequencies are got supported, that's only the matter of driver updates, DTBs won't be touched. -- With best wishes, Vladimir -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-22 10:57 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-22 10:57 UTC (permalink / raw) To: Vladimir Zapolskiy, Sakari Ailus Cc: Ramiro Oliveira, linux-kernel, linux-media, devicetree, CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Vladimir On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote: > Hi Sakari, > > On 02/21/2017 11:48 PM, Sakari Ailus wrote: >> Hi, Vladimir! >> >> How do you do? :-) > > deferring execution of boring tasks by doing code review :) > >> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: >>> 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@synopsys.com> >>>>>> Acked-by: Rob Herring <robh@kernel.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. >> >> Any clock source could be used I presume. >> > > That's exactly my point, and it is a reason to rename "xclk" to something > more generic. > xclk it's the name being used in the camera datasheet, but I can change it to something more generic >>> >>> Can you please describe what for does ov5647 sensor need this clock, what >>> is its function? >> >> Camera modules (sensors) quite commonly require an external clock as they do >> not have an oscillator on their own. A lot of devices under >> Documentation/devicetree/bindings/media/i2c/ have similar properties. >> > > So, what should be a better replacement of "xclk" in the description above? > > E.g. > > - clocks : Phandle to a device supply clock. > >>> >>>> >>>>>> +- clock-names : Should be "xclk". > > We got an agreement that "clock-names" property is removed, nevertheless > if it is added back, is should not 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 purpose is to make sure the clock frequency is really usable for the >> device, in this particular case the driver can work with one particular >> frequency. >> >> That said, the driver does not appear to use the property at the moment. It >> should. >> >> It'd be good to verify that the rate matches: clk_set_rate() is not >> guaranteed to produce the requested clock rate, and the driver could >> conceivably be updated with support for more frequencies. There are >> typically a few frequencies that a SoC such a sensor is connected can >> support, and 25 MHz is not one of the common frequencies. With this >> property, the frequency would be always there explicitly. >> > > I can provide my arguments given at v8 review time again, since I don't > see a contradiction with my older comments. > > Briefly "clock-frequency" as a device tree property on a consumer side > can be considered as redundant, because there is a mechanism to specify > a wanted clock frequency on a clock provider side right in a board DTB. > > So, the clock frequency set up is delegated to CCF, and when any other > than 25 MHz frequencies are got supported, that's only the matter of > driver updates, DTBs won't be touched. > In the driver, I'm using this piece of code to check that the frequency is 25Mhz xclk_freq = clk_get_rate(sensor->xclk); if (xclk_freq != 25000000) { dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq); return -EINVAL; } So if I don't define it here the probing will fail. Do you have another suggestion for this? -- Best Regards Ramiro Oliveira Ramiro.Oliveira@synopsys.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-22 10:57 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-22 10:57 UTC (permalink / raw) To: Vladimir Zapolskiy, Sakari Ailus Cc: Ramiro Oliveira, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus Hi Vladimir On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote: > Hi Sakari, > > On 02/21/2017 11:48 PM, Sakari Ailus wrote: >> Hi, Vladimir! >> >> How do you do? :-) > > deferring execution of boring tasks by doing code review :) > >> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: >>> 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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> >>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. >> >> Any clock source could be used I presume. >> > > That's exactly my point, and it is a reason to rename "xclk" to something > more generic. > xclk it's the name being used in the camera datasheet, but I can change it to something more generic >>> >>> Can you please describe what for does ov5647 sensor need this clock, what >>> is its function? >> >> Camera modules (sensors) quite commonly require an external clock as they do >> not have an oscillator on their own. A lot of devices under >> Documentation/devicetree/bindings/media/i2c/ have similar properties. >> > > So, what should be a better replacement of "xclk" in the description above? > > E.g. > > - clocks : Phandle to a device supply clock. > >>> >>>> >>>>>> +- clock-names : Should be "xclk". > > We got an agreement that "clock-names" property is removed, nevertheless > if it is added back, is should not 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 purpose is to make sure the clock frequency is really usable for the >> device, in this particular case the driver can work with one particular >> frequency. >> >> That said, the driver does not appear to use the property at the moment. It >> should. >> >> It'd be good to verify that the rate matches: clk_set_rate() is not >> guaranteed to produce the requested clock rate, and the driver could >> conceivably be updated with support for more frequencies. There are >> typically a few frequencies that a SoC such a sensor is connected can >> support, and 25 MHz is not one of the common frequencies. With this >> property, the frequency would be always there explicitly. >> > > I can provide my arguments given at v8 review time again, since I don't > see a contradiction with my older comments. > > Briefly "clock-frequency" as a device tree property on a consumer side > can be considered as redundant, because there is a mechanism to specify > a wanted clock frequency on a clock provider side right in a board DTB. > > So, the clock frequency set up is delegated to CCF, and when any other > than 25 MHz frequencies are got supported, that's only the matter of > driver updates, DTBs won't be touched. > In the driver, I'm using this piece of code to check that the frequency is 25Mhz xclk_freq = clk_get_rate(sensor->xclk); if (xclk_freq != 25000000) { dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq); return -EINVAL; } So if I don't define it here the probing will fail. Do you have another suggestion for this? -- Best Regards Ramiro Oliveira Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-22 11:39 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-22 11:39 UTC (permalink / raw) To: Ramiro Oliveira, Sakari Ailus Cc: linux-kernel, linux-media, devicetree, CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, On 02/22/2017 12:57 PM, Ramiro Oliveira wrote: > Hi Vladimir > > On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote: >> Hi Sakari, >> >> On 02/21/2017 11:48 PM, Sakari Ailus wrote: >>> Hi, Vladimir! >>> >>> How do you do? :-) >> >> deferring execution of boring tasks by doing code review :) >> >>> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: >>>> 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@synopsys.com> >>>>>>> Acked-by: Rob Herring <robh@kernel.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. >>> >>> Any clock source could be used I presume. >>> >> >> That's exactly my point, and it is a reason to rename "xclk" to something >> more generic. >> > > xclk it's the name being used in the camera datasheet, but I can change it to > something more generic > Ah, if the name comes from the sensor datasheet, then it should be okay to keep it. >>>> >>>> Can you please describe what for does ov5647 sensor need this clock, what >>>> is its function? >>> >>> Camera modules (sensors) quite commonly require an external clock as they do >>> not have an oscillator on their own. A lot of devices under >>> Documentation/devicetree/bindings/media/i2c/ have similar properties. >>> >> >> So, what should be a better replacement of "xclk" in the description above? >> >> E.g. >> >> - clocks : Phandle to a device supply clock. >> >>>> >>>>> >>>>>>> +- clock-names : Should be "xclk". >> >> We got an agreement that "clock-names" property is removed, nevertheless >> if it is added back, is should not 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 purpose is to make sure the clock frequency is really usable for the >>> device, in this particular case the driver can work with one particular >>> frequency. >>> >>> That said, the driver does not appear to use the property at the moment. It >>> should. >>> >>> It'd be good to verify that the rate matches: clk_set_rate() is not >>> guaranteed to produce the requested clock rate, and the driver could >>> conceivably be updated with support for more frequencies. There are >>> typically a few frequencies that a SoC such a sensor is connected can >>> support, and 25 MHz is not one of the common frequencies. With this >>> property, the frequency would be always there explicitly. >>> >> >> I can provide my arguments given at v8 review time again, since I don't >> see a contradiction with my older comments. >> >> Briefly "clock-frequency" as a device tree property on a consumer side >> can be considered as redundant, because there is a mechanism to specify >> a wanted clock frequency on a clock provider side right in a board DTB. >> >> So, the clock frequency set up is delegated to CCF, and when any other >> than 25 MHz frequencies are got supported, that's only the matter of >> driver updates, DTBs won't be touched. >> > > In the driver, I'm using this piece of code to check that the frequency is 25Mhz > > xclk_freq = clk_get_rate(sensor->xclk); > if (xclk_freq != 25000000) { > dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq); > return -EINVAL; > } > > So if I don't define it here the probing will fail. Do you have another > suggestion for this? > I don't completely understand, why does it fail? "clock-frequency" property is not a standard device node property on a clock consumer side, so, if we're still talking about v9 version of the driver, adding the property or removing it should have no effect. Let's consider the simplest possible situation, when "xclk" is actually a fixed rate 25MHz oscillator (the clock device node is "fixed-clock" compatible), for such a clock clk_get_rate() returns 25MHz rate, the assert has to be passed. In case of a more complex scenario please reference to clock-bindings.txt documentation, in particular please take a look at "assigned-clocks" and "assigned-clock-rates" properties. -- With best wishes, Vladimir ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-22 11:39 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-22 11:39 UTC (permalink / raw) To: Ramiro Oliveira, Sakari Ailus Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, On 02/22/2017 12:57 PM, Ramiro Oliveira wrote: > Hi Vladimir > > On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote: >> Hi Sakari, >> >> On 02/21/2017 11:48 PM, Sakari Ailus wrote: >>> Hi, Vladimir! >>> >>> How do you do? :-) >> >> deferring execution of boring tasks by doing code review :) >> >>> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: >>>> 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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> >>>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. >>> >>> Any clock source could be used I presume. >>> >> >> That's exactly my point, and it is a reason to rename "xclk" to something >> more generic. >> > > xclk it's the name being used in the camera datasheet, but I can change it to > something more generic > Ah, if the name comes from the sensor datasheet, then it should be okay to keep it. >>>> >>>> Can you please describe what for does ov5647 sensor need this clock, what >>>> is its function? >>> >>> Camera modules (sensors) quite commonly require an external clock as they do >>> not have an oscillator on their own. A lot of devices under >>> Documentation/devicetree/bindings/media/i2c/ have similar properties. >>> >> >> So, what should be a better replacement of "xclk" in the description above? >> >> E.g. >> >> - clocks : Phandle to a device supply clock. >> >>>> >>>>> >>>>>>> +- clock-names : Should be "xclk". >> >> We got an agreement that "clock-names" property is removed, nevertheless >> if it is added back, is should not 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 purpose is to make sure the clock frequency is really usable for the >>> device, in this particular case the driver can work with one particular >>> frequency. >>> >>> That said, the driver does not appear to use the property at the moment. It >>> should. >>> >>> It'd be good to verify that the rate matches: clk_set_rate() is not >>> guaranteed to produce the requested clock rate, and the driver could >>> conceivably be updated with support for more frequencies. There are >>> typically a few frequencies that a SoC such a sensor is connected can >>> support, and 25 MHz is not one of the common frequencies. With this >>> property, the frequency would be always there explicitly. >>> >> >> I can provide my arguments given at v8 review time again, since I don't >> see a contradiction with my older comments. >> >> Briefly "clock-frequency" as a device tree property on a consumer side >> can be considered as redundant, because there is a mechanism to specify >> a wanted clock frequency on a clock provider side right in a board DTB. >> >> So, the clock frequency set up is delegated to CCF, and when any other >> than 25 MHz frequencies are got supported, that's only the matter of >> driver updates, DTBs won't be touched. >> > > In the driver, I'm using this piece of code to check that the frequency is 25Mhz > > xclk_freq = clk_get_rate(sensor->xclk); > if (xclk_freq != 25000000) { > dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq); > return -EINVAL; > } > > So if I don't define it here the probing will fail. Do you have another > suggestion for this? > I don't completely understand, why does it fail? "clock-frequency" property is not a standard device node property on a clock consumer side, so, if we're still talking about v9 version of the driver, adding the property or removing it should have no effect. Let's consider the simplest possible situation, when "xclk" is actually a fixed rate 25MHz oscillator (the clock device node is "fixed-clock" compatible), for such a clock clk_get_rate() returns 25MHz rate, the assert has to be passed. In case of a more complex scenario please reference to clock-bindings.txt documentation, in particular please take a look at "assigned-clocks" and "assigned-clock-rates" properties. -- With best wishes, Vladimir -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-22 14:39 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-22 14:39 UTC (permalink / raw) To: Vladimir Zapolskiy, Ramiro Oliveira, Sakari Ailus Cc: linux-kernel, linux-media, devicetree, CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Vladimir On 2/22/2017 11:39 AM, Vladimir Zapolskiy wrote: > Hi Ramiro, > > On 02/22/2017 12:57 PM, Ramiro Oliveira wrote: >> Hi Vladimir >> >> On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote: >>> Hi Sakari, >>> >>> On 02/21/2017 11:48 PM, Sakari Ailus wrote: >>>> Hi, Vladimir! >>>> >>>> How do you do? :-) >>> >>> deferring execution of boring tasks by doing code review :) >>> >>>> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: >>>>> 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@synopsys.com> >>>>>>>> Acked-by: Rob Herring <robh@kernel.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. >>>> >>>> Any clock source could be used I presume. >>>> >>> >>> That's exactly my point, and it is a reason to rename "xclk" to something >>> more generic. >>> >> >> xclk it's the name being used in the camera datasheet, but I can change it to >> something more generic >> > > Ah, if the name comes from the sensor datasheet, then it should be okay > to keep it. > >>>>> >>>>> Can you please describe what for does ov5647 sensor need this clock, what >>>>> is its function? >>>> >>>> Camera modules (sensors) quite commonly require an external clock as they do >>>> not have an oscillator on their own. A lot of devices under >>>> Documentation/devicetree/bindings/media/i2c/ have similar properties. >>>> >>> >>> So, what should be a better replacement of "xclk" in the description above? >>> >>> E.g. >>> >>> - clocks : Phandle to a device supply clock. >>> >>>>> >>>>>> >>>>>>>> +- clock-names : Should be "xclk". >>> >>> We got an agreement that "clock-names" property is removed, nevertheless >>> if it is added back, is should not 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 purpose is to make sure the clock frequency is really usable for the >>>> device, in this particular case the driver can work with one particular >>>> frequency. >>>> >>>> That said, the driver does not appear to use the property at the moment. It >>>> should. >>>> >>>> It'd be good to verify that the rate matches: clk_set_rate() is not >>>> guaranteed to produce the requested clock rate, and the driver could >>>> conceivably be updated with support for more frequencies. There are >>>> typically a few frequencies that a SoC such a sensor is connected can >>>> support, and 25 MHz is not one of the common frequencies. With this >>>> property, the frequency would be always there explicitly. >>>> >>> >>> I can provide my arguments given at v8 review time again, since I don't >>> see a contradiction with my older comments. >>> >>> Briefly "clock-frequency" as a device tree property on a consumer side >>> can be considered as redundant, because there is a mechanism to specify >>> a wanted clock frequency on a clock provider side right in a board DTB. >>> >>> So, the clock frequency set up is delegated to CCF, and when any other >>> than 25 MHz frequencies are got supported, that's only the matter of >>> driver updates, DTBs won't be touched. >>> >> >> In the driver, I'm using this piece of code to check that the frequency is 25Mhz >> >> xclk_freq = clk_get_rate(sensor->xclk); >> if (xclk_freq != 25000000) { >> dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq); >> return -EINVAL; >> } >> >> So if I don't define it here the probing will fail. Do you have another >> suggestion for this? >> > > I don't completely understand, why does it fail? "clock-frequency" property > is not a standard device node property on a clock consumer side, so, if we're > still talking about v9 version of the driver, adding the property or removing > it should have no effect. > > Let's consider the simplest possible situation, when "xclk" is actually > a fixed rate 25MHz oscillator (the clock device node is "fixed-clock" > compatible), for such a clock clk_get_rate() returns 25MHz rate, the assert > has to be passed. In case of a more complex scenario please reference to > clock-bindings.txt documentation, in particular please take a look at > "assigned-clocks" and "assigned-clock-rates" properties. > You're right, I was forgetting about the frequency being defined in the fixed clock declaration. I'll remove clock-frequency from the example. -- Best Regards Ramiro Oliveira Ramiro.Oliveira@synopsys.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-22 14:39 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-22 14:39 UTC (permalink / raw) To: Vladimir Zapolskiy, Ramiro Oliveira, Sakari Ailus Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Vladimir On 2/22/2017 11:39 AM, Vladimir Zapolskiy wrote: > Hi Ramiro, > > On 02/22/2017 12:57 PM, Ramiro Oliveira wrote: >> Hi Vladimir >> >> On 2/21/2017 10:37 PM, Vladimir Zapolskiy wrote: >>> Hi Sakari, >>> >>> On 02/21/2017 11:48 PM, Sakari Ailus wrote: >>>> Hi, Vladimir! >>>> >>>> How do you do? :-) >>> >>> deferring execution of boring tasks by doing code review :) >>> >>>> On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: >>>>> 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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> >>>>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. >>>> >>>> Any clock source could be used I presume. >>>> >>> >>> That's exactly my point, and it is a reason to rename "xclk" to something >>> more generic. >>> >> >> xclk it's the name being used in the camera datasheet, but I can change it to >> something more generic >> > > Ah, if the name comes from the sensor datasheet, then it should be okay > to keep it. > >>>>> >>>>> Can you please describe what for does ov5647 sensor need this clock, what >>>>> is its function? >>>> >>>> Camera modules (sensors) quite commonly require an external clock as they do >>>> not have an oscillator on their own. A lot of devices under >>>> Documentation/devicetree/bindings/media/i2c/ have similar properties. >>>> >>> >>> So, what should be a better replacement of "xclk" in the description above? >>> >>> E.g. >>> >>> - clocks : Phandle to a device supply clock. >>> >>>>> >>>>>> >>>>>>>> +- clock-names : Should be "xclk". >>> >>> We got an agreement that "clock-names" property is removed, nevertheless >>> if it is added back, is should not 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 purpose is to make sure the clock frequency is really usable for the >>>> device, in this particular case the driver can work with one particular >>>> frequency. >>>> >>>> That said, the driver does not appear to use the property at the moment. It >>>> should. >>>> >>>> It'd be good to verify that the rate matches: clk_set_rate() is not >>>> guaranteed to produce the requested clock rate, and the driver could >>>> conceivably be updated with support for more frequencies. There are >>>> typically a few frequencies that a SoC such a sensor is connected can >>>> support, and 25 MHz is not one of the common frequencies. With this >>>> property, the frequency would be always there explicitly. >>>> >>> >>> I can provide my arguments given at v8 review time again, since I don't >>> see a contradiction with my older comments. >>> >>> Briefly "clock-frequency" as a device tree property on a consumer side >>> can be considered as redundant, because there is a mechanism to specify >>> a wanted clock frequency on a clock provider side right in a board DTB. >>> >>> So, the clock frequency set up is delegated to CCF, and when any other >>> than 25 MHz frequencies are got supported, that's only the matter of >>> driver updates, DTBs won't be touched. >>> >> >> In the driver, I'm using this piece of code to check that the frequency is 25Mhz >> >> xclk_freq = clk_get_rate(sensor->xclk); >> if (xclk_freq != 25000000) { >> dev_err(dev, "Unsupported clock frequency: %u\n", xclk_freq); >> return -EINVAL; >> } >> >> So if I don't define it here the probing will fail. Do you have another >> suggestion for this? >> > > I don't completely understand, why does it fail? "clock-frequency" property > is not a standard device node property on a clock consumer side, so, if we're > still talking about v9 version of the driver, adding the property or removing > it should have no effect. > > Let's consider the simplest possible situation, when "xclk" is actually > a fixed rate 25MHz oscillator (the clock device node is "fixed-clock" > compatible), for such a clock clk_get_rate() returns 25MHz rate, the assert > has to be passed. In case of a more complex scenario please reference to > clock-bindings.txt documentation, in particular please take a look at > "assigned-clocks" and "assigned-clock-rates" properties. > You're right, I was forgetting about the frequency being defined in the fixed clock declaration. I'll remove clock-frequency from the example. -- Best Regards Ramiro Oliveira Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-25 14:50 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-25 14:50 UTC (permalink / raw) To: Vladimir Zapolskiy Cc: Ramiro Oliveira, linux-kernel, linux-media, devicetree, CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Vladimir, On Wed, Feb 22, 2017 at 12:37:51AM +0200, Vladimir Zapolskiy wrote: > Hi Sakari, > > On 02/21/2017 11:48 PM, Sakari Ailus wrote: > > Hi, Vladimir! > > > > How do you do? :-) > > deferring execution of boring tasks by doing code review :) X-) > > > On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: > >> 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@synopsys.com> > >>>>> Acked-by: Rob Herring <robh@kernel.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. > > > > Any clock source could be used I presume. > > > > That's exactly my point, and it is a reason to rename "xclk" to something > more generic. That's a sensor specific name, the one in the hardware datasheet should be used if there's one, shouldn't it? An alternative is not to use a name, as there's just a single clock. > > >> > >> Can you please describe what for does ov5647 sensor need this clock, what > >> is its function? > > > > Camera modules (sensors) quite commonly require an external clock as they do > > not have an oscillator on their own. A lot of devices under > > Documentation/devicetree/bindings/media/i2c/ have similar properties. > > > > So, what should be a better replacement of "xclk" in the description above? > > E.g. > > - clocks : Phandle to a device supply clock. > > >> > >>> > >>>>> +- clock-names : Should be "xclk". > > We got an agreement that "clock-names" property is removed, nevertheless > if it is added back, is should not 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 purpose is to make sure the clock frequency is really usable for the > > device, in this particular case the driver can work with one particular > > frequency. > > > > That said, the driver does not appear to use the property at the moment. It > > should. > > > > It'd be good to verify that the rate matches: clk_set_rate() is not > > guaranteed to produce the requested clock rate, and the driver could > > conceivably be updated with support for more frequencies. There are > > typically a few frequencies that a SoC such a sensor is connected can > > support, and 25 MHz is not one of the common frequencies. With this > > property, the frequency would be always there explicitly. > > > > I can provide my arguments given at v8 review time again, since I don't > see a contradiction with my older comments. > > Briefly "clock-frequency" as a device tree property on a consumer side > can be considered as redundant, because there is a mechanism to specify > a wanted clock frequency on a clock provider side right in a board DTB. You can, but there's no guarantee that the frequency what you get is going to be what you asked for. Although, the driver could try to work on the actual obtained frequency. This is unlikely to work though, but it won't be very easy to figure out why the device isn't working. Having the frequency in DT accessible for the driver to check makes failing early with a clear error message possible. > > So, the clock frequency set up is delegated to CCF, and when any other > than 25 MHz frequencies are got supported, that's only the matter of > driver updates, DTBs won't be touched. Indeed. The new supported frequencies in this case will be additional single values; there won't be ranges or such. The register lists the driver contains are more or less dependent on that frequency. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-25 14:50 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-25 14:50 UTC (permalink / raw) To: Vladimir Zapolskiy Cc: Ramiro Oliveira, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Vladimir, On Wed, Feb 22, 2017 at 12:37:51AM +0200, Vladimir Zapolskiy wrote: > Hi Sakari, > > On 02/21/2017 11:48 PM, Sakari Ailus wrote: > > Hi, Vladimir! > > > > How do you do? :-) > > deferring execution of boring tasks by doing code review :) X-) > > > On Tue, Feb 21, 2017 at 10:48:09PM +0200, Vladimir Zapolskiy wrote: > >> 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-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> > >>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. > > > > Any clock source could be used I presume. > > > > That's exactly my point, and it is a reason to rename "xclk" to something > more generic. That's a sensor specific name, the one in the hardware datasheet should be used if there's one, shouldn't it? An alternative is not to use a name, as there's just a single clock. > > >> > >> Can you please describe what for does ov5647 sensor need this clock, what > >> is its function? > > > > Camera modules (sensors) quite commonly require an external clock as they do > > not have an oscillator on their own. A lot of devices under > > Documentation/devicetree/bindings/media/i2c/ have similar properties. > > > > So, what should be a better replacement of "xclk" in the description above? > > E.g. > > - clocks : Phandle to a device supply clock. > > >> > >>> > >>>>> +- clock-names : Should be "xclk". > > We got an agreement that "clock-names" property is removed, nevertheless > if it is added back, is should not 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 purpose is to make sure the clock frequency is really usable for the > > device, in this particular case the driver can work with one particular > > frequency. > > > > That said, the driver does not appear to use the property at the moment. It > > should. > > > > It'd be good to verify that the rate matches: clk_set_rate() is not > > guaranteed to produce the requested clock rate, and the driver could > > conceivably be updated with support for more frequencies. There are > > typically a few frequencies that a SoC such a sensor is connected can > > support, and 25 MHz is not one of the common frequencies. With this > > property, the frequency would be always there explicitly. > > > > I can provide my arguments given at v8 review time again, since I don't > see a contradiction with my older comments. > > Briefly "clock-frequency" as a device tree property on a consumer side > can be considered as redundant, because there is a mechanism to specify > a wanted clock frequency on a clock provider side right in a board DTB. You can, but there's no guarantee that the frequency what you get is going to be what you asked for. Although, the driver could try to work on the actual obtained frequency. This is unlikely to work though, but it won't be very easy to figure out why the device isn't working. Having the frequency in DT accessible for the driver to check makes failing early with a clear error message possible. > > So, the clock frequency set up is delegated to CCF, and when any other > than 25 MHz frequencies are got supported, that's only the matter of > driver updates, DTBs won't be touched. Indeed. The new supported frequencies in this case will be additional single values; there won't be ranges or such. The register lists the driver contains are more or less dependent on that frequency. -- Kind regards, Sakari Ailus e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-25 14:55 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-25 14:55 UTC (permalink / raw) To: Vladimir Zapolskiy Cc: Ramiro Oliveira, linux-kernel, linux-media, devicetree, CARLOS.PALMINHA, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam On Sat, Feb 25, 2017 at 04:50:53PM +0200, Sakari Ailus wrote: > Although, the driver could try to work on the actual obtained frequency. > This is unlikely to work though, but it won't be very easy to figure out > why the device isn't working. Having the frequency in DT accessible for the > driver to check makes failing early with a clear error message possible. The below point actually makes the above matter a non-issue: this driver will contain a list of supported frequencies. A SMIA driver that I typically work with, for instance, does not. So I think your suggestion of having the CCF handle setting the frequency is a good one. > > > > > So, the clock frequency set up is delegated to CCF, and when any other > > than 25 MHz frequencies are got supported, that's only the matter of > > driver updates, DTBs won't be touched. > > Indeed. The new supported frequencies in this case will be additional > single values; there won't be ranges or such. The register lists the > driver contains are more or less dependent on that frequency. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 1/2] Add OV5647 device tree documentation @ 2017-02-25 14:55 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-25 14:55 UTC (permalink / raw) To: Vladimir Zapolskiy Cc: Ramiro Oliveira, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Arnd Bergmann, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Lars-Peter Clausen, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam On Sat, Feb 25, 2017 at 04:50:53PM +0200, Sakari Ailus wrote: > Although, the driver could try to work on the actual obtained frequency. > This is unlikely to work though, but it won't be very easy to figure out > why the device isn't working. Having the frequency in DT accessible for the > driver to check makes failing early with a clear error message possible. The below point actually makes the above matter a non-issue: this driver will contain a list of supported frequencies. A SMIA driver that I typically work with, for instance, does not. So I think your suggestion of having the CCF handle setting the frequency is a good one. > > > > > So, the clock frequency set up is delegated to CCF, and when any other > > than 25 MHz frequencies are got supported, that's only the matter of > > driver updates, DTBs won't be touched. > > Indeed. The new supported frequencies in this case will be additional > single values; there won't be ranges or such. The register lists the > driver contains are more or less dependent on that frequency. -- Kind regards, Sakari Ailus e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH v9 2/2] Add support for OV5647 sensor. 2017-02-17 13:14 ` Ramiro Oliveira (?) (?) @ 2017-02-17 13:14 ` Ramiro Oliveira 2017-02-21 12:09 ` Sakari Ailus 2017-02-21 15:54 ` Vladimir Zapolskiy -1 siblings, 2 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-17 13:14 UTC (permalink / raw) To: linux-kernel, linux-media, devicetree Cc: vladimir_zapolskiy, CARLOS.PALMINHA, Ramiro Oliveira, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 and RAW 10 output formats, and MIPI CSI-2 interface. The driver adds support for 640x480 RAW 8. Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> --- MAINTAINERS | 7 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile | 1 + drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 657 insertions(+) create mode 100644 drivers/media/i2c/ov5647.c diff --git a/MAINTAINERS b/MAINTAINERS index 8e7e8d7855ee..7bbca271acc8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9109,6 +9109,13 @@ M: Harald Welte <laforge@gnumonks.org> S: Maintained F: drivers/char/pcmcia/cm4040_cs.* +OMNIVISION OV5647 SENSOR DRIVER +M: Ramiro Oliveira <roliveir@synopsys.com> +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: drivers/media/i2c/ov5647.c + OMNIVISION OV7670 SENSOR DRIVER M: Jonathan Corbet <corbet@lwn.net> L: linux-media@vger.kernel.org diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index cee1dae6e014..8435b99f38bc 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -531,6 +531,17 @@ config VIDEO_OV2659 To compile this driver as a module, choose M here: the module will be called ov2659. +config VIDEO_OV5647 + tristate "OmniVision OV5647 sensor support" + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + depends on MEDIA_CAMERA_SUPPORT + ---help--- + This is a Video4Linux2 sensor-level driver for the OmniVision + OV5647 camera. + + To compile this driver as a module, choose M here: the + module will be called ov5647. + config VIDEO_OV7640 tristate "OmniVision OV7640 sensor support" depends on I2C && VIDEO_V4L2 diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 5bc7bbeb5499..ef2ccf65f94c 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o obj-$(CONFIG_VIDEO_OV2659) += ov2659.o obj-$(CONFIG_VIDEO_TC358743) += tc358743.o +obj-$(CONFIG_VIDEO_OV5647) += ov5647.o diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c new file mode 100644 index 000000000000..34e620fabbaf --- /dev/null +++ b/drivers/media/i2c/ov5647.c @@ -0,0 +1,638 @@ +/* + * A V4L2 driver for OmniVision OV5647 cameras. + * + * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver + * Copyright (C) 2011 Sylwester Nawrocki <s.nawrocki@samsung.com> + * + * Based on Omnivision OV7670 Camera Driver + * Copyright (C) 2006-7 Jonathan Corbet <corbet@lwn.net> + * + * Copyright (C) 2016, Synopsys, Inc. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed .as is. WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include <linux/clk.h> +#include <linux/delay.h> +#include <linux/i2c.h> +#include <linux/init.h> +#include <linux/io.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/videodev2.h> +#include <media/v4l2-ctrls.h> +#include <media/v4l2-device.h> +#include <media/v4l2-image-sizes.h> +#include <media/v4l2-mediabus.h> +#include <media/v4l2-of.h> + +#define SENSOR_NAME "ov5647" + +#define OV5647_SW_RESET 0x1003 +#define OV5647_REG_CHIPID_H 0x300A +#define OV5647_REG_CHIPID_L 0x300B + +#define REG_TERM 0xfffe +#define VAL_TERM 0xfe +#define REG_DLY 0xffff + +#define OV5647_ROW_START 0x01 +#define OV5647_ROW_START_MIN 0 +#define OV5647_ROW_START_MAX 2004 +#define OV5647_ROW_START_DEF 54 + +#define OV5647_COLUMN_START 0x02 +#define OV5647_COLUMN_START_MIN 0 +#define OV5647_COLUMN_START_MAX 2750 +#define OV5647_COLUMN_START_DEF 16 + +#define OV5647_WINDOW_HEIGHT 0x03 +#define OV5647_WINDOW_HEIGHT_MIN 2 +#define OV5647_WINDOW_HEIGHT_MAX 2006 +#define OV5647_WINDOW_HEIGHT_DEF 1944 + +#define OV5647_WINDOW_WIDTH 0x04 +#define OV5647_WINDOW_WIDTH_MIN 2 +#define OV5647_WINDOW_WIDTH_MAX 2752 +#define OV5647_WINDOW_WIDTH_DEF 2592 + +struct regval_list { + u16 addr; + u8 data; +}; + +struct ov5647 { + struct v4l2_subdev sd; + struct media_pad pad; + struct mutex lock; + struct v4l2_mbus_framefmt format; + unsigned int width; + unsigned int height; + int power_count; + struct clk *xclk; + /* External clock frequency currently supported is 30MHz */ + u32 xclk_freq; +}; + +static inline struct ov5647 *to_state(struct v4l2_subdev *sd) +{ + return container_of(sd, struct ov5647, sd); +} + +static struct regval_list sensor_oe_disable_regs[] = { + {0x3000, 0x00}, + {0x3001, 0x00}, + {0x3002, 0x00}, +}; + +static struct regval_list sensor_oe_enable_regs[] = { + {0x3000, 0x0f}, + {0x3001, 0xff}, + {0x3002, 0xe4}, +}; + +static struct regval_list ov5647_640x480[] = { + {0x0100, 0x00}, + {0x0103, 0x01}, + {0x3034, 0x08}, + {0x3035, 0x21}, + {0x3036, 0x46}, + {0x303c, 0x11}, + {0x3106, 0xf5}, + {0x3821, 0x07}, + {0x3820, 0x41}, + {0x3827, 0xec}, + {0x370c, 0x0f}, + {0x3612, 0x59}, + {0x3618, 0x00}, + {0x5000, 0x06}, + {0x5001, 0x01}, + {0x5002, 0x41}, + {0x5003, 0x08}, + {0x5a00, 0x08}, + {0x3000, 0x00}, + {0x3001, 0x00}, + {0x3002, 0x00}, + {0x3016, 0x08}, + {0x3017, 0xe0}, + {0x3018, 0x44}, + {0x301c, 0xf8}, + {0x301d, 0xf0}, + {0x3a18, 0x00}, + {0x3a19, 0xf8}, + {0x3c01, 0x80}, + {0x3b07, 0x0c}, + {0x380c, 0x07}, + {0x380d, 0x68}, + {0x380e, 0x03}, + {0x380f, 0xd8}, + {0x3814, 0x31}, + {0x3815, 0x31}, + {0x3708, 0x64}, + {0x3709, 0x52}, + {0x3808, 0x02}, + {0x3809, 0x80}, + {0x380a, 0x01}, + {0x380b, 0xE0}, + {0x3801, 0x00}, + {0x3802, 0x00}, + {0x3803, 0x00}, + {0x3804, 0x0a}, + {0x3805, 0x3f}, + {0x3806, 0x07}, + {0x3807, 0xa1}, + {0x3811, 0x08}, + {0x3813, 0x02}, + {0x3630, 0x2e}, + {0x3632, 0xe2}, + {0x3633, 0x23}, + {0x3634, 0x44}, + {0x3636, 0x06}, + {0x3620, 0x64}, + {0x3621, 0xe0}, + {0x3600, 0x37}, + {0x3704, 0xa0}, + {0x3703, 0x5a}, + {0x3715, 0x78}, + {0x3717, 0x01}, + {0x3731, 0x02}, + {0x370b, 0x60}, + {0x3705, 0x1a}, + {0x3f05, 0x02}, + {0x3f06, 0x10}, + {0x3f01, 0x0a}, + {0x3a08, 0x01}, + {0x3a09, 0x27}, + {0x3a0a, 0x00}, + {0x3a0b, 0xf6}, + {0x3a0d, 0x04}, + {0x3a0e, 0x03}, + {0x3a0f, 0x58}, + {0x3a10, 0x50}, + {0x3a1b, 0x58}, + {0x3a1e, 0x50}, + {0x3a11, 0x60}, + {0x3a1f, 0x28}, + {0x4001, 0x02}, + {0x4004, 0x02}, + {0x4000, 0x09}, + {0x4837, 0x24}, + {0x4050, 0x6e}, + {0x4051, 0x8f}, + {0x0100, 0x01}, +}; + +static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val) +{ + int ret; + unsigned char data[3] = { reg >> 8, reg & 0xff, val}; + struct i2c_client *client = v4l2_get_subdevdata(sd); + + ret = i2c_master_send(client, data, 3); + if (ret < 0) + dev_dbg(&client->dev, "%s: i2c write error, reg: %x\n", + __func__, reg); + + return ret; +} + +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) +{ + int ret; + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; + struct i2c_client *client = v4l2_get_subdevdata(sd); + + ret = i2c_master_send(client, data_w, 2); + if (ret < 0) { + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", + __func__, reg); + return ret; + } + + ret = i2c_master_recv(client, val, 1); + if (ret < 0) + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", + __func__, reg); + + return ret; + +} + +static int ov5647_write_array(struct v4l2_subdev *sd, + struct regval_list *regs, int array_size) +{ + int i = 0, ret; + + for (i = 0; i < array_size; i++) { + ret = ov5647_write(sd, regs[i].addr, regs[i].data); + if (ret < 0) + return ret; + } + + return 0; +} + +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel) +{ + u8 channel_id; + int ret; + + ret = ov5647_read(sd, 0x4814, &channel_id); + if (ret < 0) + return ret; + + channel_id &= ~(3 << 6); + return ov5647_write(sd, 0x4814, channel_id | (channel << 6)); +} + +static int ov5647_stream_on(struct v4l2_subdev *sd) +{ + struct i2c_client *client = v4l2_get_subdevdata(sd); + + ov5647_write(sd, 0x4202, 0x00); + + dev_dbg(&client->dev, "Stream on"); + + return ov5647_write(sd, 0x300D, 0x00); +} + +static int ov5647_stream_off(struct v4l2_subdev *sd) +{ + struct i2c_client *client = v4l2_get_subdevdata(sd); + + ov5647_write(sd, 0x4202, 0x0f); + + dev_dbg(&client->dev, "Stream off"); + + return ov5647_write(sd, 0x300D, 0x01); +} + +static int set_sw_standby(struct v4l2_subdev *sd, bool standby) +{ + int ret; + u8 rdval; + + ret = ov5647_read(sd, 0x0100, &rdval); + if (ret < 0) + return ret; + + if (standby) + rdval &= ~0x01; + else + rdval |= 0x01; + + return ov5647_write(sd, 0x0100, rdval); +} + +static int __sensor_init(struct v4l2_subdev *sd) +{ + int ret; + u8 resetval; + u8 rdval; + struct i2c_client *client = v4l2_get_subdevdata(sd); + + dev_dbg(&client->dev, "sensor init\n"); + + ret = ov5647_read(sd, 0x0100, &rdval); + if (ret < 0) + return ret; + + ret = ov5647_write_array(sd, ov5647_640x480, + ARRAY_SIZE(ov5647_640x480)); + if (ret < 0) { + dev_err(&client->dev, "write sensor default regs error\n"); + return ret; + } + + ret = ov5647_set_virtual_channel(sd, 0); + if (ret < 0) + return ret; + + ret = ov5647_read(sd, 0x0100, &resetval); + if (ret < 0) + return ret; + + if (!(resetval & 0x01)) { + dev_err(&client->dev, "Device was in SW standby"); + ret = ov5647_write(sd, 0x0100, 0x01); + if (ret < 0) + return ret; + } + + return ov5647_write(sd, 0x4800, 0x04); +} + +static int sensor_power(struct v4l2_subdev *sd, int on) +{ + int ret; + struct ov5647 *ov5647 = to_state(sd); + struct i2c_client *client = v4l2_get_subdevdata(sd); + + ret = 0; + mutex_lock(&ov5647->lock); + + if (on && !ov5647->power_count) { + dev_dbg(&client->dev, "OV5647 power on\n"); + + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); + + ret = clk_prepare_enable(ov5647->xclk); + if (ret < 0) { + dev_err(&client->dev, "clk prepare enable failed\n"); + goto out; + } + + ret = ov5647_write_array(sd, sensor_oe_enable_regs, + ARRAY_SIZE(sensor_oe_enable_regs)); + if (ret < 0) { + clk_disable_unprepare(ov5647->xclk); + dev_err(&client->dev, + "write sensor_oe_enable_regs error\n"); + goto out; + } + + ret = __sensor_init(sd); + if (ret < 0) { + clk_disable_unprepare(ov5647->xclk); + dev_err(&client->dev, + "Camera not available, check Power\n"); + goto out; + } + } else if (!on && ov5647->power_count == 1) { + dev_dbg(&client->dev, "OV5647 power off\n"); + + dev_dbg(&client->dev, "disable oe\n"); + ret = ov5647_write_array(sd, sensor_oe_disable_regs, + ARRAY_SIZE(sensor_oe_disable_regs)); + + if (ret < 0) + dev_dbg(&client->dev, "disable oe failed\n"); + + ret = set_sw_standby(sd, true); + + if (ret < 0) + dev_dbg(&client->dev, "soft stby failed\n"); + + clk_disable_unprepare(ov5647->xclk); + } + + /* Update the power count. */ + ov5647->power_count += on ? 1 : -1; + WARN_ON(ov5647->power_count < 0); + +out: + mutex_unlock(&ov5647->lock); + + return ret; +} + +#ifdef CONFIG_VIDEO_ADV_DEBUG +static int sensor_get_register(struct v4l2_subdev *sd, + struct v4l2_dbg_register *reg) +{ + u8 val; + int ret; + + ret = ov5647_read(sd, reg->reg & 0xff, &val); + if (ret < 0) + return ret; + + reg->val = val; + reg->size = 1; + + return 0; +} + +static int sensor_set_register(struct v4l2_subdev *sd, + const struct v4l2_dbg_register *reg) +{ + return ov5647_write(sd, reg->reg & 0xff, reg->val & 0xff); +} +#endif + +/** + * @short Subdev core operations registration + */ +static const struct v4l2_subdev_core_ops subdev_core_ops = { + .s_power = sensor_power, +#ifdef CONFIG_VIDEO_ADV_DEBUG + .g_register = sensor_get_register, + .s_register = sensor_set_register, +#endif +}; + +static int s_stream(struct v4l2_subdev *sd, int enable) +{ + if (enable) + return ov5647_stream_on(sd); + else + return ov5647_stream_off(sd); +} + +static const struct v4l2_subdev_video_ops subdev_video_ops = { + .s_stream = s_stream, +}; + +static int enum_mbus_code(struct v4l2_subdev *sd, + struct v4l2_subdev_pad_config *cfg, + struct v4l2_subdev_mbus_code_enum *code) +{ + if (code->index > 0) + return -EINVAL; + + code->code = MEDIA_BUS_FMT_SBGGR8_1X8; + + return 0; +} + +static const struct v4l2_subdev_pad_ops subdev_pad_ops = { + .enum_mbus_code = enum_mbus_code, +}; + +/** + * @short Subdev operations registration + * + */ +static const struct v4l2_subdev_ops subdev_ops = { + .core = &subdev_core_ops, + .video = &subdev_video_ops, + .pad = &subdev_pad_ops, +}; + +static int ov5647_detect(struct v4l2_subdev *sd) +{ + u8 read; + int ret; + struct i2c_client *client = v4l2_get_subdevdata(sd); + + ret = ov5647_write(sd, OV5647_SW_RESET, 0x01); + if (ret < 0) + return ret; + + ret = ov5647_read(sd, OV5647_REG_CHIPID_H, &read); + if (ret < 0) + return ret; + + if (read != 0x56) { + dev_err(&client->dev, "Wrong model version detected"); + return -ENODEV; + } + + ret = ov5647_read(sd, OV5647_REG_CHIPID_L, &read); + if (ret < 0) + return ret; + + if (read != 0x47) { + dev_err(&client->dev, "Wrong model version detected"); + return -ENODEV; + } + + return ov5647_write(sd, OV5647_SW_RESET, 0x00); +} + +static int ov5647_registered(struct v4l2_subdev *sd) +{ + return 0; +} + +static int ov5647_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) +{ + struct v4l2_mbus_framefmt *format = + v4l2_subdev_get_try_format(sd, fh->pad, 0); + struct v4l2_rect *crop = + v4l2_subdev_get_try_crop(sd, fh->pad, 0); + + crop->left = OV5647_COLUMN_START_DEF; + crop->top = OV5647_ROW_START_DEF; + crop->width = OV5647_WINDOW_WIDTH_DEF; + crop->height = OV5647_WINDOW_HEIGHT_DEF; + + format->code = MEDIA_BUS_FMT_SBGGR8_1X8; + + format->width = OV5647_WINDOW_WIDTH_DEF; + format->height = OV5647_WINDOW_HEIGHT_DEF; + format->field = V4L2_FIELD_NONE; + format->colorspace = V4L2_COLORSPACE_SRGB; + + return sensor_power(sd, true); +} + +static int ov5647_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) +{ + return sensor_power(sd, false); +} + +/** + * @short Subdev internal operations registration + * + */ +static const struct v4l2_subdev_internal_ops ov5647_subdev_internal_ops = { + .registered = ov5647_registered, + .open = ov5647_open, + .close = ov5647_close, +}; + +static int ov5647_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct device *dev = &client->dev; + struct ov5647 *sensor; + int ret; + struct v4l2_subdev *sd; + + sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL); + if (sensor == NULL) + return -ENOMEM; + + /* get system clock (xclk) */ + sensor->xclk = devm_clk_get(dev, "xclk"); + if (IS_ERR(sensor->xclk)) { + dev_err(dev, "could not get xclk"); + return PTR_ERR(sensor->xclk); + } + + sensor->xclk_freq = clk_get_rate(sensor->xclk); + if (sensor->xclk_freq != 25000000) { + dev_err(dev, "Unsupported clock frequency: %u\n", + sensor->xclk_freq); + return -EINVAL; + } + + mutex_init(&sensor->lock); + + sd = &sensor->sd; + v4l2_i2c_subdev_init(sd, client, &subdev_ops); + sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; + + sensor->pad.flags = MEDIA_PAD_FL_SOURCE; + sd->entity.function = MEDIA_ENT_F_CAM_SENSOR; + ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad); + if (ret < 0) + goto mutex_remove; + + ret = ov5647_detect(sd); + if (ret < 0) + goto error; + + ret = v4l2_async_register_subdev(sd); + if (ret < 0) + goto error; + + dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n"); + return 0; +error: + media_entity_cleanup(&sd->entity); +mutex_remove: + mutex_destroy(&sensor->lock); + return ret; +} + +static int ov5647_remove(struct i2c_client *client) +{ + struct v4l2_subdev *sd = i2c_get_clientdata(client); + struct ov5647 *ov5647 = to_state(sd); + + v4l2_async_unregister_subdev(&ov5647->sd); + media_entity_cleanup(&ov5647->sd.entity); + v4l2_device_unregister_subdev(sd); + mutex_destroy(&ov5647->lock); + + return 0; +} + +static const struct i2c_device_id ov5647_id[] = { + { "ov5647", 0 }, + { } +}; +MODULE_DEVICE_TABLE(i2c, ov5647_id); + +#if IS_ENABLED(CONFIG_OF) +static const struct of_device_id ov5647_of_match[] = { + { .compatible = "ovti,ov5647" }, + { /* sentinel */ }, +}; +MODULE_DEVICE_TABLE(of, ov5647_of_match); +#endif + +static struct i2c_driver ov5647_driver = { + .driver = { + .of_match_table = of_match_ptr(ov5647_of_match), + .name = SENSOR_NAME, + }, + .probe = ov5647_probe, + .remove = ov5647_remove, + .id_table = ov5647_id, +}; + +module_i2c_driver(ov5647_driver); + +MODULE_AUTHOR("Ramiro Oliveira <roliveir@synopsys.com>"); +MODULE_DESCRIPTION("A low-level driver for OmniVision ov5647 sensors"); +MODULE_LICENSE("GPL v2"); -- 2.11.0 ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-21 12:09 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-21 12:09 UTC (permalink / raw) To: Ramiro Oliveira Cc: linux-kernel, linux-media, devicetree, vladimir_zapolskiy, CARLOS.PALMINHA, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, A few minor comments below. On Fri, Feb 17, 2017 at 01:14:16PM +0000, Ramiro Oliveira wrote: > The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 > and RAW 10 output formats, and MIPI CSI-2 interface. > > The driver adds support for 640x480 RAW 8. > > Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> > --- > MAINTAINERS | 7 + > drivers/media/i2c/Kconfig | 11 + > drivers/media/i2c/Makefile | 1 + > drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 657 insertions(+) > create mode 100644 drivers/media/i2c/ov5647.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8e7e8d7855ee..7bbca271acc8 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9109,6 +9109,13 @@ M: Harald Welte <laforge@gnumonks.org> > S: Maintained > F: drivers/char/pcmcia/cm4040_cs.* > > +OMNIVISION OV5647 SENSOR DRIVER > +M: Ramiro Oliveira <roliveir@synopsys.com> > +L: linux-media@vger.kernel.org > +T: git git://linuxtv.org/media_tree.git > +S: Maintained > +F: drivers/media/i2c/ov5647.c > + > OMNIVISION OV7670 SENSOR DRIVER > M: Jonathan Corbet <corbet@lwn.net> > L: linux-media@vger.kernel.org > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig > index cee1dae6e014..8435b99f38bc 100644 > --- a/drivers/media/i2c/Kconfig > +++ b/drivers/media/i2c/Kconfig > @@ -531,6 +531,17 @@ config VIDEO_OV2659 > To compile this driver as a module, choose M here: the > module will be called ov2659. > > +config VIDEO_OV5647 > + tristate "OmniVision OV5647 sensor support" > + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > + depends on MEDIA_CAMERA_SUPPORT > + ---help--- > + This is a Video4Linux2 sensor-level driver for the OmniVision > + OV5647 camera. > + > + To compile this driver as a module, choose M here: the > + module will be called ov5647. > + > config VIDEO_OV7640 > tristate "OmniVision OV7640 sensor support" > depends on I2C && VIDEO_V4L2 > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile > index 5bc7bbeb5499..ef2ccf65f94c 100644 > --- a/drivers/media/i2c/Makefile > +++ b/drivers/media/i2c/Makefile > @@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o > obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o > obj-$(CONFIG_VIDEO_OV2659) += ov2659.o > obj-$(CONFIG_VIDEO_TC358743) += tc358743.o > +obj-$(CONFIG_VIDEO_OV5647) += ov5647.o > diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c > new file mode 100644 > index 000000000000..34e620fabbaf > --- /dev/null > +++ b/drivers/media/i2c/ov5647.c > @@ -0,0 +1,638 @@ > +/* > + * A V4L2 driver for OmniVision OV5647 cameras. > + * > + * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver > + * Copyright (C) 2011 Sylwester Nawrocki <s.nawrocki@samsung.com> > + * > + * Based on Omnivision OV7670 Camera Driver > + * Copyright (C) 2006-7 Jonathan Corbet <corbet@lwn.net> > + * > + * Copyright (C) 2016, Synopsys, Inc. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation version 2. > + * > + * This program is distributed .as is. WITHOUT ANY WARRANTY of any > + * kind, whether express or implied; without even the implied warranty > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include <linux/clk.h> > +#include <linux/delay.h> > +#include <linux/i2c.h> > +#include <linux/init.h> > +#include <linux/io.h> > +#include <linux/module.h> > +#include <linux/slab.h> > +#include <linux/videodev2.h> > +#include <media/v4l2-ctrls.h> You don't seem to implement any controls. The sensor likely supports exposure time (and maybe also gain) the user might want to control. Is there an intent to add that? Otherwise the header should be removed. > +#include <media/v4l2-device.h> > +#include <media/v4l2-image-sizes.h> > +#include <media/v4l2-mediabus.h> > +#include <media/v4l2-of.h> > + > +#define SENSOR_NAME "ov5647" > + > +#define OV5647_SW_RESET 0x1003 > +#define OV5647_REG_CHIPID_H 0x300A > +#define OV5647_REG_CHIPID_L 0x300B > + > +#define REG_TERM 0xfffe > +#define VAL_TERM 0xfe > +#define REG_DLY 0xffff > + > +#define OV5647_ROW_START 0x01 > +#define OV5647_ROW_START_MIN 0 > +#define OV5647_ROW_START_MAX 2004 > +#define OV5647_ROW_START_DEF 54 > + > +#define OV5647_COLUMN_START 0x02 > +#define OV5647_COLUMN_START_MIN 0 > +#define OV5647_COLUMN_START_MAX 2750 > +#define OV5647_COLUMN_START_DEF 16 > + > +#define OV5647_WINDOW_HEIGHT 0x03 > +#define OV5647_WINDOW_HEIGHT_MIN 2 > +#define OV5647_WINDOW_HEIGHT_MAX 2006 > +#define OV5647_WINDOW_HEIGHT_DEF 1944 > + > +#define OV5647_WINDOW_WIDTH 0x04 > +#define OV5647_WINDOW_WIDTH_MIN 2 > +#define OV5647_WINDOW_WIDTH_MAX 2752 > +#define OV5647_WINDOW_WIDTH_DEF 2592 > + > +struct regval_list { > + u16 addr; > + u8 data; > +}; > + > +struct ov5647 { > + struct v4l2_subdev sd; > + struct media_pad pad; > + struct mutex lock; > + struct v4l2_mbus_framefmt format; > + unsigned int width; > + unsigned int height; > + int power_count; > + struct clk *xclk; > + /* External clock frequency currently supported is 30MHz */ > + u32 xclk_freq; > +}; > + > +static inline struct ov5647 *to_state(struct v4l2_subdev *sd) > +{ > + return container_of(sd, struct ov5647, sd); > +} > + > +static struct regval_list sensor_oe_disable_regs[] = { > + {0x3000, 0x00}, > + {0x3001, 0x00}, > + {0x3002, 0x00}, > +}; > + > +static struct regval_list sensor_oe_enable_regs[] = { > + {0x3000, 0x0f}, > + {0x3001, 0xff}, > + {0x3002, 0xe4}, > +}; > + > +static struct regval_list ov5647_640x480[] = { > + {0x0100, 0x00}, > + {0x0103, 0x01}, > + {0x3034, 0x08}, > + {0x3035, 0x21}, > + {0x3036, 0x46}, > + {0x303c, 0x11}, > + {0x3106, 0xf5}, > + {0x3821, 0x07}, > + {0x3820, 0x41}, > + {0x3827, 0xec}, > + {0x370c, 0x0f}, > + {0x3612, 0x59}, > + {0x3618, 0x00}, > + {0x5000, 0x06}, > + {0x5001, 0x01}, > + {0x5002, 0x41}, > + {0x5003, 0x08}, > + {0x5a00, 0x08}, > + {0x3000, 0x00}, > + {0x3001, 0x00}, > + {0x3002, 0x00}, > + {0x3016, 0x08}, > + {0x3017, 0xe0}, > + {0x3018, 0x44}, > + {0x301c, 0xf8}, > + {0x301d, 0xf0}, > + {0x3a18, 0x00}, > + {0x3a19, 0xf8}, > + {0x3c01, 0x80}, > + {0x3b07, 0x0c}, > + {0x380c, 0x07}, > + {0x380d, 0x68}, > + {0x380e, 0x03}, > + {0x380f, 0xd8}, > + {0x3814, 0x31}, > + {0x3815, 0x31}, > + {0x3708, 0x64}, > + {0x3709, 0x52}, > + {0x3808, 0x02}, > + {0x3809, 0x80}, > + {0x380a, 0x01}, > + {0x380b, 0xE0}, > + {0x3801, 0x00}, > + {0x3802, 0x00}, > + {0x3803, 0x00}, > + {0x3804, 0x0a}, > + {0x3805, 0x3f}, > + {0x3806, 0x07}, > + {0x3807, 0xa1}, > + {0x3811, 0x08}, > + {0x3813, 0x02}, > + {0x3630, 0x2e}, > + {0x3632, 0xe2}, > + {0x3633, 0x23}, > + {0x3634, 0x44}, > + {0x3636, 0x06}, > + {0x3620, 0x64}, > + {0x3621, 0xe0}, > + {0x3600, 0x37}, > + {0x3704, 0xa0}, > + {0x3703, 0x5a}, > + {0x3715, 0x78}, > + {0x3717, 0x01}, > + {0x3731, 0x02}, > + {0x370b, 0x60}, > + {0x3705, 0x1a}, > + {0x3f05, 0x02}, > + {0x3f06, 0x10}, > + {0x3f01, 0x0a}, > + {0x3a08, 0x01}, > + {0x3a09, 0x27}, > + {0x3a0a, 0x00}, > + {0x3a0b, 0xf6}, > + {0x3a0d, 0x04}, > + {0x3a0e, 0x03}, > + {0x3a0f, 0x58}, > + {0x3a10, 0x50}, > + {0x3a1b, 0x58}, > + {0x3a1e, 0x50}, > + {0x3a11, 0x60}, > + {0x3a1f, 0x28}, > + {0x4001, 0x02}, > + {0x4004, 0x02}, > + {0x4000, 0x09}, > + {0x4837, 0x24}, > + {0x4050, 0x6e}, > + {0x4051, 0x8f}, > + {0x0100, 0x01}, > +}; > + > +static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val) > +{ > + int ret; > + unsigned char data[3] = { reg >> 8, reg & 0xff, val}; > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = i2c_master_send(client, data, 3); > + if (ret < 0) > + dev_dbg(&client->dev, "%s: i2c write error, reg: %x\n", > + __func__, reg); > + > + return ret; > +} > + > +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) > +{ > + int ret; > + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = i2c_master_send(client, data_w, 2); > + if (ret < 0) { > + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", > + __func__, reg); > + return ret; > + } > + > + ret = i2c_master_recv(client, val, 1); > + if (ret < 0) > + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", > + __func__, reg); > + > + return ret; > + > +} > + > +static int ov5647_write_array(struct v4l2_subdev *sd, > + struct regval_list *regs, int array_size) > +{ > + int i = 0, ret; > + > + for (i = 0; i < array_size; i++) { > + ret = ov5647_write(sd, regs[i].addr, regs[i].data); > + if (ret < 0) > + return ret; > + } > + > + return 0; > +} > + > +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel) > +{ > + u8 channel_id; > + int ret; > + > + ret = ov5647_read(sd, 0x4814, &channel_id); > + if (ret < 0) > + return ret; > + > + channel_id &= ~(3 << 6); > + return ov5647_write(sd, 0x4814, channel_id | (channel << 6)); > +} > + > +static int ov5647_stream_on(struct v4l2_subdev *sd) > +{ > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ov5647_write(sd, 0x4202, 0x00); > + > + dev_dbg(&client->dev, "Stream on"); > + > + return ov5647_write(sd, 0x300D, 0x00); > +} > + > +static int ov5647_stream_off(struct v4l2_subdev *sd) > +{ > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ov5647_write(sd, 0x4202, 0x0f); > + > + dev_dbg(&client->dev, "Stream off"); > + > + return ov5647_write(sd, 0x300D, 0x01); > +} > + > +static int set_sw_standby(struct v4l2_subdev *sd, bool standby) > +{ > + int ret; > + u8 rdval; > + > + ret = ov5647_read(sd, 0x0100, &rdval); > + if (ret < 0) > + return ret; > + > + if (standby) > + rdval &= ~0x01; > + else > + rdval |= 0x01; > + > + return ov5647_write(sd, 0x0100, rdval); > +} > + > +static int __sensor_init(struct v4l2_subdev *sd) > +{ > + int ret; > + u8 resetval; > + u8 rdval; > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + dev_dbg(&client->dev, "sensor init\n"); > + > + ret = ov5647_read(sd, 0x0100, &rdval); > + if (ret < 0) > + return ret; > + > + ret = ov5647_write_array(sd, ov5647_640x480, > + ARRAY_SIZE(ov5647_640x480)); > + if (ret < 0) { > + dev_err(&client->dev, "write sensor default regs error\n"); > + return ret; > + } > + > + ret = ov5647_set_virtual_channel(sd, 0); > + if (ret < 0) > + return ret; > + > + ret = ov5647_read(sd, 0x0100, &resetval); > + if (ret < 0) > + return ret; > + > + if (!(resetval & 0x01)) { > + dev_err(&client->dev, "Device was in SW standby"); > + ret = ov5647_write(sd, 0x0100, 0x01); > + if (ret < 0) > + return ret; > + } > + > + return ov5647_write(sd, 0x4800, 0x04); > +} > + > +static int sensor_power(struct v4l2_subdev *sd, int on) > +{ > + int ret; > + struct ov5647 *ov5647 = to_state(sd); > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = 0; You can assign in variable declaration. > + mutex_lock(&ov5647->lock); > + > + if (on && !ov5647->power_count) { > + dev_dbg(&client->dev, "OV5647 power on\n"); > + > + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); > + > + ret = clk_prepare_enable(ov5647->xclk); > + if (ret < 0) { > + dev_err(&client->dev, "clk prepare enable failed\n"); > + goto out; > + } > + > + ret = ov5647_write_array(sd, sensor_oe_enable_regs, > + ARRAY_SIZE(sensor_oe_enable_regs)); > + if (ret < 0) { > + clk_disable_unprepare(ov5647->xclk); > + dev_err(&client->dev, > + "write sensor_oe_enable_regs error\n"); > + goto out; > + } > + > + ret = __sensor_init(sd); > + if (ret < 0) { > + clk_disable_unprepare(ov5647->xclk); > + dev_err(&client->dev, > + "Camera not available, check Power\n"); > + goto out; > + } > + } else if (!on && ov5647->power_count == 1) { > + dev_dbg(&client->dev, "OV5647 power off\n"); > + > + dev_dbg(&client->dev, "disable oe\n"); > + ret = ov5647_write_array(sd, sensor_oe_disable_regs, > + ARRAY_SIZE(sensor_oe_disable_regs)); > + > + if (ret < 0) > + dev_dbg(&client->dev, "disable oe failed\n"); > + > + ret = set_sw_standby(sd, true); > + > + if (ret < 0) > + dev_dbg(&client->dev, "soft stby failed\n"); > + > + clk_disable_unprepare(ov5647->xclk); > + } > + > + /* Update the power count. */ > + ov5647->power_count += on ? 1 : -1; > + WARN_ON(ov5647->power_count < 0); > + > +out: > + mutex_unlock(&ov5647->lock); > + > + return ret; > +} > + > +#ifdef CONFIG_VIDEO_ADV_DEBUG > +static int sensor_get_register(struct v4l2_subdev *sd, > + struct v4l2_dbg_register *reg) > +{ > + u8 val; > + int ret; > + > + ret = ov5647_read(sd, reg->reg & 0xff, &val); > + if (ret < 0) > + return ret; > + > + reg->val = val; > + reg->size = 1; > + > + return 0; > +} > + > +static int sensor_set_register(struct v4l2_subdev *sd, > + const struct v4l2_dbg_register *reg) > +{ > + return ov5647_write(sd, reg->reg & 0xff, reg->val & 0xff); > +} > +#endif > + > +/** > + * @short Subdev core operations registration > + */ > +static const struct v4l2_subdev_core_ops subdev_core_ops = { > + .s_power = sensor_power, > +#ifdef CONFIG_VIDEO_ADV_DEBUG > + .g_register = sensor_get_register, > + .s_register = sensor_set_register, > +#endif > +}; > + > +static int s_stream(struct v4l2_subdev *sd, int enable) > +{ > + if (enable) > + return ov5647_stream_on(sd); > + else > + return ov5647_stream_off(sd); > +} > + > +static const struct v4l2_subdev_video_ops subdev_video_ops = { > + .s_stream = s_stream, > +}; > + > +static int enum_mbus_code(struct v4l2_subdev *sd, > + struct v4l2_subdev_pad_config *cfg, > + struct v4l2_subdev_mbus_code_enum *code) > +{ > + if (code->index > 0) > + return -EINVAL; > + > + code->code = MEDIA_BUS_FMT_SBGGR8_1X8; > + > + return 0; > +} > + > +static const struct v4l2_subdev_pad_ops subdev_pad_ops = { > + .enum_mbus_code = enum_mbus_code, > +}; > + > +/** > + * @short Subdev operations registration > + * > + */ > +static const struct v4l2_subdev_ops subdev_ops = { > + .core = &subdev_core_ops, > + .video = &subdev_video_ops, > + .pad = &subdev_pad_ops, > +}; > + > +static int ov5647_detect(struct v4l2_subdev *sd) > +{ > + u8 read; > + int ret; > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = ov5647_write(sd, OV5647_SW_RESET, 0x01); > + if (ret < 0) > + return ret; > + > + ret = ov5647_read(sd, OV5647_REG_CHIPID_H, &read); > + if (ret < 0) > + return ret; > + > + if (read != 0x56) { > + dev_err(&client->dev, "Wrong model version detected"); You might want to tell whether it's high or low ID register that fails the check. And possibly the bad value. Up to you. > + return -ENODEV; > + } > + > + ret = ov5647_read(sd, OV5647_REG_CHIPID_L, &read); > + if (ret < 0) > + return ret; > + > + if (read != 0x47) { > + dev_err(&client->dev, "Wrong model version detected"); > + return -ENODEV; > + } > + > + return ov5647_write(sd, OV5647_SW_RESET, 0x00); > +} > + > +static int ov5647_registered(struct v4l2_subdev *sd) > +{ > + return 0; > +} The registered() callback is optional, i.e. you can drop an empty callback. > + > +static int ov5647_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) > +{ > + struct v4l2_mbus_framefmt *format = > + v4l2_subdev_get_try_format(sd, fh->pad, 0); > + struct v4l2_rect *crop = > + v4l2_subdev_get_try_crop(sd, fh->pad, 0); > + > + crop->left = OV5647_COLUMN_START_DEF; > + crop->top = OV5647_ROW_START_DEF; > + crop->width = OV5647_WINDOW_WIDTH_DEF; > + crop->height = OV5647_WINDOW_HEIGHT_DEF; > + > + format->code = MEDIA_BUS_FMT_SBGGR8_1X8; > + > + format->width = OV5647_WINDOW_WIDTH_DEF; > + format->height = OV5647_WINDOW_HEIGHT_DEF; > + format->field = V4L2_FIELD_NONE; > + format->colorspace = V4L2_COLORSPACE_SRGB; > + > + return sensor_power(sd, true); > +} > + > +static int ov5647_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) > +{ > + return sensor_power(sd, false); > +} > + > +/** > + * @short Subdev internal operations registration > + * > + */ > +static const struct v4l2_subdev_internal_ops ov5647_subdev_internal_ops = { > + .registered = ov5647_registered, > + .open = ov5647_open, > + .close = ov5647_close, > +}; > + > +static int ov5647_probe(struct i2c_client *client, > + const struct i2c_device_id *id) > +{ > + struct device *dev = &client->dev; > + struct ov5647 *sensor; > + int ret; > + struct v4l2_subdev *sd; > + > + sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL); > + if (sensor == NULL) > + return -ENOMEM; > + > + /* get system clock (xclk) */ > + sensor->xclk = devm_clk_get(dev, "xclk"); > + if (IS_ERR(sensor->xclk)) { > + dev_err(dev, "could not get xclk"); > + return PTR_ERR(sensor->xclk); > + } > + > + sensor->xclk_freq = clk_get_rate(sensor->xclk); > + if (sensor->xclk_freq != 25000000) { > + dev_err(dev, "Unsupported clock frequency: %u\n", > + sensor->xclk_freq); > + return -EINVAL; > + } > + > + mutex_init(&sensor->lock); > + > + sd = &sensor->sd; > + v4l2_i2c_subdev_init(sd, client, &subdev_ops); > + sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; > + > + sensor->pad.flags = MEDIA_PAD_FL_SOURCE; > + sd->entity.function = MEDIA_ENT_F_CAM_SENSOR; > + ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad); > + if (ret < 0) > + goto mutex_remove; > + > + ret = ov5647_detect(sd); > + if (ret < 0) > + goto error; > + > + ret = v4l2_async_register_subdev(sd); > + if (ret < 0) > + goto error; > + > + dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n"); > + return 0; > +error: > + media_entity_cleanup(&sd->entity); > +mutex_remove: > + mutex_destroy(&sensor->lock); > + return ret; > +} > + > +static int ov5647_remove(struct i2c_client *client) > +{ > + struct v4l2_subdev *sd = i2c_get_clientdata(client); > + struct ov5647 *ov5647 = to_state(sd); > + > + v4l2_async_unregister_subdev(&ov5647->sd); > + media_entity_cleanup(&ov5647->sd.entity); > + v4l2_device_unregister_subdev(sd); > + mutex_destroy(&ov5647->lock); > + > + return 0; > +} > + > +static const struct i2c_device_id ov5647_id[] = { > + { "ov5647", 0 }, > + { } > +}; > +MODULE_DEVICE_TABLE(i2c, ov5647_id); > + > +#if IS_ENABLED(CONFIG_OF) > +static const struct of_device_id ov5647_of_match[] = { > + { .compatible = "ovti,ov5647" }, > + { /* sentinel */ }, > +}; > +MODULE_DEVICE_TABLE(of, ov5647_of_match); > +#endif > + > +static struct i2c_driver ov5647_driver = { > + .driver = { > + .of_match_table = of_match_ptr(ov5647_of_match), > + .name = SENSOR_NAME, > + }, > + .probe = ov5647_probe, > + .remove = ov5647_remove, > + .id_table = ov5647_id, > +}; > + > +module_i2c_driver(ov5647_driver); > + > +MODULE_AUTHOR("Ramiro Oliveira <roliveir@synopsys.com>"); > +MODULE_DESCRIPTION("A low-level driver for OmniVision ov5647 sensors"); > +MODULE_LICENSE("GPL v2"); -- Kind regards, Sakari Ailus e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-21 12:09 ` Sakari Ailus 0 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-21 12:09 UTC (permalink / raw) To: Ramiro Oliveira Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, A few minor comments below. On Fri, Feb 17, 2017 at 01:14:16PM +0000, Ramiro Oliveira wrote: > The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 > and RAW 10 output formats, and MIPI CSI-2 interface. > > The driver adds support for 640x480 RAW 8. > > Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> > --- > MAINTAINERS | 7 + > drivers/media/i2c/Kconfig | 11 + > drivers/media/i2c/Makefile | 1 + > drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 657 insertions(+) > create mode 100644 drivers/media/i2c/ov5647.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8e7e8d7855ee..7bbca271acc8 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9109,6 +9109,13 @@ M: Harald Welte <laforge-TgoAw6mPHtdg9hUCZPvPmw@public.gmane.org> > S: Maintained > F: drivers/char/pcmcia/cm4040_cs.* > > +OMNIVISION OV5647 SENSOR DRIVER > +M: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> > +L: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > +T: git git://linuxtv.org/media_tree.git > +S: Maintained > +F: drivers/media/i2c/ov5647.c > + > OMNIVISION OV7670 SENSOR DRIVER > M: Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org> > L: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig > index cee1dae6e014..8435b99f38bc 100644 > --- a/drivers/media/i2c/Kconfig > +++ b/drivers/media/i2c/Kconfig > @@ -531,6 +531,17 @@ config VIDEO_OV2659 > To compile this driver as a module, choose M here: the > module will be called ov2659. > > +config VIDEO_OV5647 > + tristate "OmniVision OV5647 sensor support" > + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > + depends on MEDIA_CAMERA_SUPPORT > + ---help--- > + This is a Video4Linux2 sensor-level driver for the OmniVision > + OV5647 camera. > + > + To compile this driver as a module, choose M here: the > + module will be called ov5647. > + > config VIDEO_OV7640 > tristate "OmniVision OV7640 sensor support" > depends on I2C && VIDEO_V4L2 > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile > index 5bc7bbeb5499..ef2ccf65f94c 100644 > --- a/drivers/media/i2c/Makefile > +++ b/drivers/media/i2c/Makefile > @@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o > obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o > obj-$(CONFIG_VIDEO_OV2659) += ov2659.o > obj-$(CONFIG_VIDEO_TC358743) += tc358743.o > +obj-$(CONFIG_VIDEO_OV5647) += ov5647.o > diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c > new file mode 100644 > index 000000000000..34e620fabbaf > --- /dev/null > +++ b/drivers/media/i2c/ov5647.c > @@ -0,0 +1,638 @@ > +/* > + * A V4L2 driver for OmniVision OV5647 cameras. > + * > + * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver > + * Copyright (C) 2011 Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> > + * > + * Based on Omnivision OV7670 Camera Driver > + * Copyright (C) 2006-7 Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org> > + * > + * Copyright (C) 2016, Synopsys, Inc. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation version 2. > + * > + * This program is distributed .as is. WITHOUT ANY WARRANTY of any > + * kind, whether express or implied; without even the implied warranty > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include <linux/clk.h> > +#include <linux/delay.h> > +#include <linux/i2c.h> > +#include <linux/init.h> > +#include <linux/io.h> > +#include <linux/module.h> > +#include <linux/slab.h> > +#include <linux/videodev2.h> > +#include <media/v4l2-ctrls.h> You don't seem to implement any controls. The sensor likely supports exposure time (and maybe also gain) the user might want to control. Is there an intent to add that? Otherwise the header should be removed. > +#include <media/v4l2-device.h> > +#include <media/v4l2-image-sizes.h> > +#include <media/v4l2-mediabus.h> > +#include <media/v4l2-of.h> > + > +#define SENSOR_NAME "ov5647" > + > +#define OV5647_SW_RESET 0x1003 > +#define OV5647_REG_CHIPID_H 0x300A > +#define OV5647_REG_CHIPID_L 0x300B > + > +#define REG_TERM 0xfffe > +#define VAL_TERM 0xfe > +#define REG_DLY 0xffff > + > +#define OV5647_ROW_START 0x01 > +#define OV5647_ROW_START_MIN 0 > +#define OV5647_ROW_START_MAX 2004 > +#define OV5647_ROW_START_DEF 54 > + > +#define OV5647_COLUMN_START 0x02 > +#define OV5647_COLUMN_START_MIN 0 > +#define OV5647_COLUMN_START_MAX 2750 > +#define OV5647_COLUMN_START_DEF 16 > + > +#define OV5647_WINDOW_HEIGHT 0x03 > +#define OV5647_WINDOW_HEIGHT_MIN 2 > +#define OV5647_WINDOW_HEIGHT_MAX 2006 > +#define OV5647_WINDOW_HEIGHT_DEF 1944 > + > +#define OV5647_WINDOW_WIDTH 0x04 > +#define OV5647_WINDOW_WIDTH_MIN 2 > +#define OV5647_WINDOW_WIDTH_MAX 2752 > +#define OV5647_WINDOW_WIDTH_DEF 2592 > + > +struct regval_list { > + u16 addr; > + u8 data; > +}; > + > +struct ov5647 { > + struct v4l2_subdev sd; > + struct media_pad pad; > + struct mutex lock; > + struct v4l2_mbus_framefmt format; > + unsigned int width; > + unsigned int height; > + int power_count; > + struct clk *xclk; > + /* External clock frequency currently supported is 30MHz */ > + u32 xclk_freq; > +}; > + > +static inline struct ov5647 *to_state(struct v4l2_subdev *sd) > +{ > + return container_of(sd, struct ov5647, sd); > +} > + > +static struct regval_list sensor_oe_disable_regs[] = { > + {0x3000, 0x00}, > + {0x3001, 0x00}, > + {0x3002, 0x00}, > +}; > + > +static struct regval_list sensor_oe_enable_regs[] = { > + {0x3000, 0x0f}, > + {0x3001, 0xff}, > + {0x3002, 0xe4}, > +}; > + > +static struct regval_list ov5647_640x480[] = { > + {0x0100, 0x00}, > + {0x0103, 0x01}, > + {0x3034, 0x08}, > + {0x3035, 0x21}, > + {0x3036, 0x46}, > + {0x303c, 0x11}, > + {0x3106, 0xf5}, > + {0x3821, 0x07}, > + {0x3820, 0x41}, > + {0x3827, 0xec}, > + {0x370c, 0x0f}, > + {0x3612, 0x59}, > + {0x3618, 0x00}, > + {0x5000, 0x06}, > + {0x5001, 0x01}, > + {0x5002, 0x41}, > + {0x5003, 0x08}, > + {0x5a00, 0x08}, > + {0x3000, 0x00}, > + {0x3001, 0x00}, > + {0x3002, 0x00}, > + {0x3016, 0x08}, > + {0x3017, 0xe0}, > + {0x3018, 0x44}, > + {0x301c, 0xf8}, > + {0x301d, 0xf0}, > + {0x3a18, 0x00}, > + {0x3a19, 0xf8}, > + {0x3c01, 0x80}, > + {0x3b07, 0x0c}, > + {0x380c, 0x07}, > + {0x380d, 0x68}, > + {0x380e, 0x03}, > + {0x380f, 0xd8}, > + {0x3814, 0x31}, > + {0x3815, 0x31}, > + {0x3708, 0x64}, > + {0x3709, 0x52}, > + {0x3808, 0x02}, > + {0x3809, 0x80}, > + {0x380a, 0x01}, > + {0x380b, 0xE0}, > + {0x3801, 0x00}, > + {0x3802, 0x00}, > + {0x3803, 0x00}, > + {0x3804, 0x0a}, > + {0x3805, 0x3f}, > + {0x3806, 0x07}, > + {0x3807, 0xa1}, > + {0x3811, 0x08}, > + {0x3813, 0x02}, > + {0x3630, 0x2e}, > + {0x3632, 0xe2}, > + {0x3633, 0x23}, > + {0x3634, 0x44}, > + {0x3636, 0x06}, > + {0x3620, 0x64}, > + {0x3621, 0xe0}, > + {0x3600, 0x37}, > + {0x3704, 0xa0}, > + {0x3703, 0x5a}, > + {0x3715, 0x78}, > + {0x3717, 0x01}, > + {0x3731, 0x02}, > + {0x370b, 0x60}, > + {0x3705, 0x1a}, > + {0x3f05, 0x02}, > + {0x3f06, 0x10}, > + {0x3f01, 0x0a}, > + {0x3a08, 0x01}, > + {0x3a09, 0x27}, > + {0x3a0a, 0x00}, > + {0x3a0b, 0xf6}, > + {0x3a0d, 0x04}, > + {0x3a0e, 0x03}, > + {0x3a0f, 0x58}, > + {0x3a10, 0x50}, > + {0x3a1b, 0x58}, > + {0x3a1e, 0x50}, > + {0x3a11, 0x60}, > + {0x3a1f, 0x28}, > + {0x4001, 0x02}, > + {0x4004, 0x02}, > + {0x4000, 0x09}, > + {0x4837, 0x24}, > + {0x4050, 0x6e}, > + {0x4051, 0x8f}, > + {0x0100, 0x01}, > +}; > + > +static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val) > +{ > + int ret; > + unsigned char data[3] = { reg >> 8, reg & 0xff, val}; > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = i2c_master_send(client, data, 3); > + if (ret < 0) > + dev_dbg(&client->dev, "%s: i2c write error, reg: %x\n", > + __func__, reg); > + > + return ret; > +} > + > +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) > +{ > + int ret; > + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = i2c_master_send(client, data_w, 2); > + if (ret < 0) { > + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", > + __func__, reg); > + return ret; > + } > + > + ret = i2c_master_recv(client, val, 1); > + if (ret < 0) > + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", > + __func__, reg); > + > + return ret; > + > +} > + > +static int ov5647_write_array(struct v4l2_subdev *sd, > + struct regval_list *regs, int array_size) > +{ > + int i = 0, ret; > + > + for (i = 0; i < array_size; i++) { > + ret = ov5647_write(sd, regs[i].addr, regs[i].data); > + if (ret < 0) > + return ret; > + } > + > + return 0; > +} > + > +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel) > +{ > + u8 channel_id; > + int ret; > + > + ret = ov5647_read(sd, 0x4814, &channel_id); > + if (ret < 0) > + return ret; > + > + channel_id &= ~(3 << 6); > + return ov5647_write(sd, 0x4814, channel_id | (channel << 6)); > +} > + > +static int ov5647_stream_on(struct v4l2_subdev *sd) > +{ > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ov5647_write(sd, 0x4202, 0x00); > + > + dev_dbg(&client->dev, "Stream on"); > + > + return ov5647_write(sd, 0x300D, 0x00); > +} > + > +static int ov5647_stream_off(struct v4l2_subdev *sd) > +{ > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ov5647_write(sd, 0x4202, 0x0f); > + > + dev_dbg(&client->dev, "Stream off"); > + > + return ov5647_write(sd, 0x300D, 0x01); > +} > + > +static int set_sw_standby(struct v4l2_subdev *sd, bool standby) > +{ > + int ret; > + u8 rdval; > + > + ret = ov5647_read(sd, 0x0100, &rdval); > + if (ret < 0) > + return ret; > + > + if (standby) > + rdval &= ~0x01; > + else > + rdval |= 0x01; > + > + return ov5647_write(sd, 0x0100, rdval); > +} > + > +static int __sensor_init(struct v4l2_subdev *sd) > +{ > + int ret; > + u8 resetval; > + u8 rdval; > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + dev_dbg(&client->dev, "sensor init\n"); > + > + ret = ov5647_read(sd, 0x0100, &rdval); > + if (ret < 0) > + return ret; > + > + ret = ov5647_write_array(sd, ov5647_640x480, > + ARRAY_SIZE(ov5647_640x480)); > + if (ret < 0) { > + dev_err(&client->dev, "write sensor default regs error\n"); > + return ret; > + } > + > + ret = ov5647_set_virtual_channel(sd, 0); > + if (ret < 0) > + return ret; > + > + ret = ov5647_read(sd, 0x0100, &resetval); > + if (ret < 0) > + return ret; > + > + if (!(resetval & 0x01)) { > + dev_err(&client->dev, "Device was in SW standby"); > + ret = ov5647_write(sd, 0x0100, 0x01); > + if (ret < 0) > + return ret; > + } > + > + return ov5647_write(sd, 0x4800, 0x04); > +} > + > +static int sensor_power(struct v4l2_subdev *sd, int on) > +{ > + int ret; > + struct ov5647 *ov5647 = to_state(sd); > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = 0; You can assign in variable declaration. > + mutex_lock(&ov5647->lock); > + > + if (on && !ov5647->power_count) { > + dev_dbg(&client->dev, "OV5647 power on\n"); > + > + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); > + > + ret = clk_prepare_enable(ov5647->xclk); > + if (ret < 0) { > + dev_err(&client->dev, "clk prepare enable failed\n"); > + goto out; > + } > + > + ret = ov5647_write_array(sd, sensor_oe_enable_regs, > + ARRAY_SIZE(sensor_oe_enable_regs)); > + if (ret < 0) { > + clk_disable_unprepare(ov5647->xclk); > + dev_err(&client->dev, > + "write sensor_oe_enable_regs error\n"); > + goto out; > + } > + > + ret = __sensor_init(sd); > + if (ret < 0) { > + clk_disable_unprepare(ov5647->xclk); > + dev_err(&client->dev, > + "Camera not available, check Power\n"); > + goto out; > + } > + } else if (!on && ov5647->power_count == 1) { > + dev_dbg(&client->dev, "OV5647 power off\n"); > + > + dev_dbg(&client->dev, "disable oe\n"); > + ret = ov5647_write_array(sd, sensor_oe_disable_regs, > + ARRAY_SIZE(sensor_oe_disable_regs)); > + > + if (ret < 0) > + dev_dbg(&client->dev, "disable oe failed\n"); > + > + ret = set_sw_standby(sd, true); > + > + if (ret < 0) > + dev_dbg(&client->dev, "soft stby failed\n"); > + > + clk_disable_unprepare(ov5647->xclk); > + } > + > + /* Update the power count. */ > + ov5647->power_count += on ? 1 : -1; > + WARN_ON(ov5647->power_count < 0); > + > +out: > + mutex_unlock(&ov5647->lock); > + > + return ret; > +} > + > +#ifdef CONFIG_VIDEO_ADV_DEBUG > +static int sensor_get_register(struct v4l2_subdev *sd, > + struct v4l2_dbg_register *reg) > +{ > + u8 val; > + int ret; > + > + ret = ov5647_read(sd, reg->reg & 0xff, &val); > + if (ret < 0) > + return ret; > + > + reg->val = val; > + reg->size = 1; > + > + return 0; > +} > + > +static int sensor_set_register(struct v4l2_subdev *sd, > + const struct v4l2_dbg_register *reg) > +{ > + return ov5647_write(sd, reg->reg & 0xff, reg->val & 0xff); > +} > +#endif > + > +/** > + * @short Subdev core operations registration > + */ > +static const struct v4l2_subdev_core_ops subdev_core_ops = { > + .s_power = sensor_power, > +#ifdef CONFIG_VIDEO_ADV_DEBUG > + .g_register = sensor_get_register, > + .s_register = sensor_set_register, > +#endif > +}; > + > +static int s_stream(struct v4l2_subdev *sd, int enable) > +{ > + if (enable) > + return ov5647_stream_on(sd); > + else > + return ov5647_stream_off(sd); > +} > + > +static const struct v4l2_subdev_video_ops subdev_video_ops = { > + .s_stream = s_stream, > +}; > + > +static int enum_mbus_code(struct v4l2_subdev *sd, > + struct v4l2_subdev_pad_config *cfg, > + struct v4l2_subdev_mbus_code_enum *code) > +{ > + if (code->index > 0) > + return -EINVAL; > + > + code->code = MEDIA_BUS_FMT_SBGGR8_1X8; > + > + return 0; > +} > + > +static const struct v4l2_subdev_pad_ops subdev_pad_ops = { > + .enum_mbus_code = enum_mbus_code, > +}; > + > +/** > + * @short Subdev operations registration > + * > + */ > +static const struct v4l2_subdev_ops subdev_ops = { > + .core = &subdev_core_ops, > + .video = &subdev_video_ops, > + .pad = &subdev_pad_ops, > +}; > + > +static int ov5647_detect(struct v4l2_subdev *sd) > +{ > + u8 read; > + int ret; > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = ov5647_write(sd, OV5647_SW_RESET, 0x01); > + if (ret < 0) > + return ret; > + > + ret = ov5647_read(sd, OV5647_REG_CHIPID_H, &read); > + if (ret < 0) > + return ret; > + > + if (read != 0x56) { > + dev_err(&client->dev, "Wrong model version detected"); You might want to tell whether it's high or low ID register that fails the check. And possibly the bad value. Up to you. > + return -ENODEV; > + } > + > + ret = ov5647_read(sd, OV5647_REG_CHIPID_L, &read); > + if (ret < 0) > + return ret; > + > + if (read != 0x47) { > + dev_err(&client->dev, "Wrong model version detected"); > + return -ENODEV; > + } > + > + return ov5647_write(sd, OV5647_SW_RESET, 0x00); > +} > + > +static int ov5647_registered(struct v4l2_subdev *sd) > +{ > + return 0; > +} The registered() callback is optional, i.e. you can drop an empty callback. > + > +static int ov5647_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) > +{ > + struct v4l2_mbus_framefmt *format = > + v4l2_subdev_get_try_format(sd, fh->pad, 0); > + struct v4l2_rect *crop = > + v4l2_subdev_get_try_crop(sd, fh->pad, 0); > + > + crop->left = OV5647_COLUMN_START_DEF; > + crop->top = OV5647_ROW_START_DEF; > + crop->width = OV5647_WINDOW_WIDTH_DEF; > + crop->height = OV5647_WINDOW_HEIGHT_DEF; > + > + format->code = MEDIA_BUS_FMT_SBGGR8_1X8; > + > + format->width = OV5647_WINDOW_WIDTH_DEF; > + format->height = OV5647_WINDOW_HEIGHT_DEF; > + format->field = V4L2_FIELD_NONE; > + format->colorspace = V4L2_COLORSPACE_SRGB; > + > + return sensor_power(sd, true); > +} > + > +static int ov5647_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) > +{ > + return sensor_power(sd, false); > +} > + > +/** > + * @short Subdev internal operations registration > + * > + */ > +static const struct v4l2_subdev_internal_ops ov5647_subdev_internal_ops = { > + .registered = ov5647_registered, > + .open = ov5647_open, > + .close = ov5647_close, > +}; > + > +static int ov5647_probe(struct i2c_client *client, > + const struct i2c_device_id *id) > +{ > + struct device *dev = &client->dev; > + struct ov5647 *sensor; > + int ret; > + struct v4l2_subdev *sd; > + > + sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL); > + if (sensor == NULL) > + return -ENOMEM; > + > + /* get system clock (xclk) */ > + sensor->xclk = devm_clk_get(dev, "xclk"); > + if (IS_ERR(sensor->xclk)) { > + dev_err(dev, "could not get xclk"); > + return PTR_ERR(sensor->xclk); > + } > + > + sensor->xclk_freq = clk_get_rate(sensor->xclk); > + if (sensor->xclk_freq != 25000000) { > + dev_err(dev, "Unsupported clock frequency: %u\n", > + sensor->xclk_freq); > + return -EINVAL; > + } > + > + mutex_init(&sensor->lock); > + > + sd = &sensor->sd; > + v4l2_i2c_subdev_init(sd, client, &subdev_ops); > + sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; > + > + sensor->pad.flags = MEDIA_PAD_FL_SOURCE; > + sd->entity.function = MEDIA_ENT_F_CAM_SENSOR; > + ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad); > + if (ret < 0) > + goto mutex_remove; > + > + ret = ov5647_detect(sd); > + if (ret < 0) > + goto error; > + > + ret = v4l2_async_register_subdev(sd); > + if (ret < 0) > + goto error; > + > + dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n"); > + return 0; > +error: > + media_entity_cleanup(&sd->entity); > +mutex_remove: > + mutex_destroy(&sensor->lock); > + return ret; > +} > + > +static int ov5647_remove(struct i2c_client *client) > +{ > + struct v4l2_subdev *sd = i2c_get_clientdata(client); > + struct ov5647 *ov5647 = to_state(sd); > + > + v4l2_async_unregister_subdev(&ov5647->sd); > + media_entity_cleanup(&ov5647->sd.entity); > + v4l2_device_unregister_subdev(sd); > + mutex_destroy(&ov5647->lock); > + > + return 0; > +} > + > +static const struct i2c_device_id ov5647_id[] = { > + { "ov5647", 0 }, > + { } > +}; > +MODULE_DEVICE_TABLE(i2c, ov5647_id); > + > +#if IS_ENABLED(CONFIG_OF) > +static const struct of_device_id ov5647_of_match[] = { > + { .compatible = "ovti,ov5647" }, > + { /* sentinel */ }, > +}; > +MODULE_DEVICE_TABLE(of, ov5647_of_match); > +#endif > + > +static struct i2c_driver ov5647_driver = { > + .driver = { > + .of_match_table = of_match_ptr(ov5647_of_match), > + .name = SENSOR_NAME, > + }, > + .probe = ov5647_probe, > + .remove = ov5647_remove, > + .id_table = ov5647_id, > +}; > + > +module_i2c_driver(ov5647_driver); > + > +MODULE_AUTHOR("Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>"); > +MODULE_DESCRIPTION("A low-level driver for OmniVision ov5647 sensors"); > +MODULE_LICENSE("GPL v2"); -- Kind regards, Sakari Ailus e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-21 14:49 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-21 14:49 UTC (permalink / raw) To: Sakari Ailus, Ramiro Oliveira Cc: linux-kernel, linux-media, devicetree, vladimir_zapolskiy, CARLOS.PALMINHA, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Sakari, Thank you for your feedback. On 2/21/2017 12:09 PM, Sakari Ailus wrote: > Hi Ramiro, > > A few minor comments below. > > On Fri, Feb 17, 2017 at 01:14:16PM +0000, Ramiro Oliveira wrote: >> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 >> and RAW 10 output formats, and MIPI CSI-2 interface. >> >> The driver adds support for 640x480 RAW 8. >> >> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> >> --- >> MAINTAINERS | 7 + >> drivers/media/i2c/Kconfig | 11 + >> drivers/media/i2c/Makefile | 1 + >> drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++++++++++++++++++++++++++ >> 4 files changed, 657 insertions(+) >> create mode 100644 drivers/media/i2c/ov5647.c >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 8e7e8d7855ee..7bbca271acc8 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -9109,6 +9109,13 @@ M: Harald Welte <laforge@gnumonks.org> >> S: Maintained >> F: drivers/char/pcmcia/cm4040_cs.* >> >> +OMNIVISION OV5647 SENSOR DRIVER >> +M: Ramiro Oliveira <roliveir@synopsys.com> >> +L: linux-media@vger.kernel.org >> +T: git git://linuxtv.org/media_tree.git >> +S: Maintained >> +F: drivers/media/i2c/ov5647.c >> + >> OMNIVISION OV7670 SENSOR DRIVER >> M: Jonathan Corbet <corbet@lwn.net> >> L: linux-media@vger.kernel.org >> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig >> index cee1dae6e014..8435b99f38bc 100644 >> --- a/drivers/media/i2c/Kconfig >> +++ b/drivers/media/i2c/Kconfig >> @@ -531,6 +531,17 @@ config VIDEO_OV2659 >> To compile this driver as a module, choose M here: the >> module will be called ov2659. >> >> +config VIDEO_OV5647 >> + tristate "OmniVision OV5647 sensor support" >> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API >> + depends on MEDIA_CAMERA_SUPPORT >> + ---help--- >> + This is a Video4Linux2 sensor-level driver for the OmniVision >> + OV5647 camera. >> + >> + To compile this driver as a module, choose M here: the >> + module will be called ov5647. >> + >> config VIDEO_OV7640 >> tristate "OmniVision OV7640 sensor support" >> depends on I2C && VIDEO_V4L2 >> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile >> index 5bc7bbeb5499..ef2ccf65f94c 100644 >> --- a/drivers/media/i2c/Makefile >> +++ b/drivers/media/i2c/Makefile >> @@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o >> obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o >> obj-$(CONFIG_VIDEO_OV2659) += ov2659.o >> obj-$(CONFIG_VIDEO_TC358743) += tc358743.o >> +obj-$(CONFIG_VIDEO_OV5647) += ov5647.o >> diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c >> new file mode 100644 >> index 000000000000..34e620fabbaf >> --- /dev/null >> +++ b/drivers/media/i2c/ov5647.c >> @@ -0,0 +1,638 @@ >> +/* >> + * A V4L2 driver for OmniVision OV5647 cameras. >> + * >> + * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver >> + * Copyright (C) 2011 Sylwester Nawrocki <s.nawrocki@samsung.com> >> + * >> + * Based on Omnivision OV7670 Camera Driver >> + * Copyright (C) 2006-7 Jonathan Corbet <corbet@lwn.net> >> + * >> + * Copyright (C) 2016, Synopsys, Inc. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License as >> + * published by the Free Software Foundation version 2. >> + * >> + * This program is distributed .as is. WITHOUT ANY WARRANTY of any >> + * kind, whether express or implied; without even the implied warranty >> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + */ >> + >> +#include <linux/clk.h> >> +#include <linux/delay.h> >> +#include <linux/i2c.h> >> +#include <linux/init.h> >> +#include <linux/io.h> >> +#include <linux/module.h> >> +#include <linux/slab.h> >> +#include <linux/videodev2.h> >> +#include <media/v4l2-ctrls.h> > > You don't seem to implement any controls. > > The sensor likely supports exposure time (and maybe also gain) the user > might want to control. Is there an intent to add that? Otherwise the header > should be removed. > I plan to add them in the future but for now I think I'll just remove the header. >> +#include <media/v4l2-device.h> >> +#include <media/v4l2-image-sizes.h> >> +#include <media/v4l2-mediabus.h> >> +#include <media/v4l2-of.h> >> + >> +#define SENSOR_NAME "ov5647" >> + >> +#define OV5647_SW_RESET 0x1003 >> +#define OV5647_REG_CHIPID_H 0x300A >> +#define OV5647_REG_CHIPID_L 0x300B >> + >> +#define REG_TERM 0xfffe >> +#define VAL_TERM 0xfe >> +#define REG_DLY 0xffff >> + >> +#define OV5647_ROW_START 0x01 >> +#define OV5647_ROW_START_MIN 0 >> +#define OV5647_ROW_START_MAX 2004 >> +#define OV5647_ROW_START_DEF 54 >> + >> +#define OV5647_COLUMN_START 0x02 >> +#define OV5647_COLUMN_START_MIN 0 >> +#define OV5647_COLUMN_START_MAX 2750 >> +#define OV5647_COLUMN_START_DEF 16 >> + >> +#define OV5647_WINDOW_HEIGHT 0x03 >> +#define OV5647_WINDOW_HEIGHT_MIN 2 >> +#define OV5647_WINDOW_HEIGHT_MAX 2006 >> +#define OV5647_WINDOW_HEIGHT_DEF 1944 >> + >> +#define OV5647_WINDOW_WIDTH 0x04 >> +#define OV5647_WINDOW_WIDTH_MIN 2 >> +#define OV5647_WINDOW_WIDTH_MAX 2752 >> +#define OV5647_WINDOW_WIDTH_DEF 2592 >> + >> +struct regval_list { >> + u16 addr; >> + u8 data; >> +}; >> + >> +struct ov5647 { >> + struct v4l2_subdev sd; >> + struct media_pad pad; >> + struct mutex lock; >> + struct v4l2_mbus_framefmt format; >> + unsigned int width; >> + unsigned int height; >> + int power_count; >> + struct clk *xclk; >> + /* External clock frequency currently supported is 30MHz */ >> + u32 xclk_freq; >> +}; >> + >> +static inline struct ov5647 *to_state(struct v4l2_subdev *sd) >> +{ >> + return container_of(sd, struct ov5647, sd); >> +} >> + >> +static struct regval_list sensor_oe_disable_regs[] = { >> + {0x3000, 0x00}, >> + {0x3001, 0x00}, >> + {0x3002, 0x00}, >> +}; >> + >> +static struct regval_list sensor_oe_enable_regs[] = { >> + {0x3000, 0x0f}, >> + {0x3001, 0xff}, >> + {0x3002, 0xe4}, >> +}; >> + >> +static struct regval_list ov5647_640x480[] = { >> + {0x0100, 0x00}, >> + {0x0103, 0x01}, >> + {0x3034, 0x08}, >> + {0x3035, 0x21}, >> + {0x3036, 0x46}, >> + {0x303c, 0x11}, >> + {0x3106, 0xf5}, >> + {0x3821, 0x07}, >> + {0x3820, 0x41}, >> + {0x3827, 0xec}, >> + {0x370c, 0x0f}, >> + {0x3612, 0x59}, >> + {0x3618, 0x00}, >> + {0x5000, 0x06}, >> + {0x5001, 0x01}, >> + {0x5002, 0x41}, >> + {0x5003, 0x08}, >> + {0x5a00, 0x08}, >> + {0x3000, 0x00}, >> + {0x3001, 0x00}, >> + {0x3002, 0x00}, >> + {0x3016, 0x08}, >> + {0x3017, 0xe0}, >> + {0x3018, 0x44}, >> + {0x301c, 0xf8}, >> + {0x301d, 0xf0}, >> + {0x3a18, 0x00}, >> + {0x3a19, 0xf8}, >> + {0x3c01, 0x80}, >> + {0x3b07, 0x0c}, >> + {0x380c, 0x07}, >> + {0x380d, 0x68}, >> + {0x380e, 0x03}, >> + {0x380f, 0xd8}, >> + {0x3814, 0x31}, >> + {0x3815, 0x31}, >> + {0x3708, 0x64}, >> + {0x3709, 0x52}, >> + {0x3808, 0x02}, >> + {0x3809, 0x80}, >> + {0x380a, 0x01}, >> + {0x380b, 0xE0}, >> + {0x3801, 0x00}, >> + {0x3802, 0x00}, >> + {0x3803, 0x00}, >> + {0x3804, 0x0a}, >> + {0x3805, 0x3f}, >> + {0x3806, 0x07}, >> + {0x3807, 0xa1}, >> + {0x3811, 0x08}, >> + {0x3813, 0x02}, >> + {0x3630, 0x2e}, >> + {0x3632, 0xe2}, >> + {0x3633, 0x23}, >> + {0x3634, 0x44}, >> + {0x3636, 0x06}, >> + {0x3620, 0x64}, >> + {0x3621, 0xe0}, >> + {0x3600, 0x37}, >> + {0x3704, 0xa0}, >> + {0x3703, 0x5a}, >> + {0x3715, 0x78}, >> + {0x3717, 0x01}, >> + {0x3731, 0x02}, >> + {0x370b, 0x60}, >> + {0x3705, 0x1a}, >> + {0x3f05, 0x02}, >> + {0x3f06, 0x10}, >> + {0x3f01, 0x0a}, >> + {0x3a08, 0x01}, >> + {0x3a09, 0x27}, >> + {0x3a0a, 0x00}, >> + {0x3a0b, 0xf6}, >> + {0x3a0d, 0x04}, >> + {0x3a0e, 0x03}, >> + {0x3a0f, 0x58}, >> + {0x3a10, 0x50}, >> + {0x3a1b, 0x58}, >> + {0x3a1e, 0x50}, >> + {0x3a11, 0x60}, >> + {0x3a1f, 0x28}, >> + {0x4001, 0x02}, >> + {0x4004, 0x02}, >> + {0x4000, 0x09}, >> + {0x4837, 0x24}, >> + {0x4050, 0x6e}, >> + {0x4051, 0x8f}, >> + {0x0100, 0x01}, >> +}; >> + >> +static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val) >> +{ >> + int ret; >> + unsigned char data[3] = { reg >> 8, reg & 0xff, val}; >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = i2c_master_send(client, data, 3); >> + if (ret < 0) >> + dev_dbg(&client->dev, "%s: i2c write error, reg: %x\n", >> + __func__, reg); >> + >> + return ret; >> +} >> + >> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) >> +{ >> + int ret; >> + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = i2c_master_send(client, data_w, 2); >> + if (ret < 0) { >> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >> + __func__, reg); >> + return ret; >> + } >> + >> + ret = i2c_master_recv(client, val, 1); >> + if (ret < 0) >> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >> + __func__, reg); >> + >> + return ret; >> + >> +} >> + >> +static int ov5647_write_array(struct v4l2_subdev *sd, >> + struct regval_list *regs, int array_size) >> +{ >> + int i = 0, ret; >> + >> + for (i = 0; i < array_size; i++) { >> + ret = ov5647_write(sd, regs[i].addr, regs[i].data); >> + if (ret < 0) >> + return ret; >> + } >> + >> + return 0; >> +} >> + >> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel) >> +{ >> + u8 channel_id; >> + int ret; >> + >> + ret = ov5647_read(sd, 0x4814, &channel_id); >> + if (ret < 0) >> + return ret; >> + >> + channel_id &= ~(3 << 6); >> + return ov5647_write(sd, 0x4814, channel_id | (channel << 6)); >> +} >> + >> +static int ov5647_stream_on(struct v4l2_subdev *sd) >> +{ >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ov5647_write(sd, 0x4202, 0x00); >> + >> + dev_dbg(&client->dev, "Stream on"); >> + >> + return ov5647_write(sd, 0x300D, 0x00); >> +} >> + >> +static int ov5647_stream_off(struct v4l2_subdev *sd) >> +{ >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ov5647_write(sd, 0x4202, 0x0f); >> + >> + dev_dbg(&client->dev, "Stream off"); >> + >> + return ov5647_write(sd, 0x300D, 0x01); >> +} >> + >> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby) >> +{ >> + int ret; >> + u8 rdval; >> + >> + ret = ov5647_read(sd, 0x0100, &rdval); >> + if (ret < 0) >> + return ret; >> + >> + if (standby) >> + rdval &= ~0x01; >> + else >> + rdval |= 0x01; >> + >> + return ov5647_write(sd, 0x0100, rdval); >> +} >> + >> +static int __sensor_init(struct v4l2_subdev *sd) >> +{ >> + int ret; >> + u8 resetval; >> + u8 rdval; >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + dev_dbg(&client->dev, "sensor init\n"); >> + >> + ret = ov5647_read(sd, 0x0100, &rdval); >> + if (ret < 0) >> + return ret; >> + >> + ret = ov5647_write_array(sd, ov5647_640x480, >> + ARRAY_SIZE(ov5647_640x480)); >> + if (ret < 0) { >> + dev_err(&client->dev, "write sensor default regs error\n"); >> + return ret; >> + } >> + >> + ret = ov5647_set_virtual_channel(sd, 0); >> + if (ret < 0) >> + return ret; >> + >> + ret = ov5647_read(sd, 0x0100, &resetval); >> + if (ret < 0) >> + return ret; >> + >> + if (!(resetval & 0x01)) { >> + dev_err(&client->dev, "Device was in SW standby"); >> + ret = ov5647_write(sd, 0x0100, 0x01); >> + if (ret < 0) >> + return ret; >> + } >> + >> + return ov5647_write(sd, 0x4800, 0x04); >> +} >> + >> +static int sensor_power(struct v4l2_subdev *sd, int on) >> +{ >> + int ret; >> + struct ov5647 *ov5647 = to_state(sd); >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = 0; > > You can assign in variable declaration. > Yes, you're right. >> + mutex_lock(&ov5647->lock); >> + >> + if (on && !ov5647->power_count) { >> + dev_dbg(&client->dev, "OV5647 power on\n"); >> + >> + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); >> + >> + ret = clk_prepare_enable(ov5647->xclk); >> + if (ret < 0) { >> + dev_err(&client->dev, "clk prepare enable failed\n"); >> + goto out; >> + } >> + >> + ret = ov5647_write_array(sd, sensor_oe_enable_regs, >> + ARRAY_SIZE(sensor_oe_enable_regs)); >> + if (ret < 0) { >> + clk_disable_unprepare(ov5647->xclk); >> + dev_err(&client->dev, >> + "write sensor_oe_enable_regs error\n"); >> + goto out; >> + } >> + >> + ret = __sensor_init(sd); >> + if (ret < 0) { >> + clk_disable_unprepare(ov5647->xclk); >> + dev_err(&client->dev, >> + "Camera not available, check Power\n"); >> + goto out; >> + } >> + } else if (!on && ov5647->power_count == 1) { >> + dev_dbg(&client->dev, "OV5647 power off\n"); >> + >> + dev_dbg(&client->dev, "disable oe\n"); >> + ret = ov5647_write_array(sd, sensor_oe_disable_regs, >> + ARRAY_SIZE(sensor_oe_disable_regs)); >> + >> + if (ret < 0) >> + dev_dbg(&client->dev, "disable oe failed\n"); >> + >> + ret = set_sw_standby(sd, true); >> + >> + if (ret < 0) >> + dev_dbg(&client->dev, "soft stby failed\n"); >> + >> + clk_disable_unprepare(ov5647->xclk); >> + } >> + >> + /* Update the power count. */ >> + ov5647->power_count += on ? 1 : -1; >> + WARN_ON(ov5647->power_count < 0); >> + >> +out: >> + mutex_unlock(&ov5647->lock); >> + >> + return ret; >> +} >> + >> +#ifdef CONFIG_VIDEO_ADV_DEBUG >> +static int sensor_get_register(struct v4l2_subdev *sd, >> + struct v4l2_dbg_register *reg) >> +{ >> + u8 val; >> + int ret; >> + >> + ret = ov5647_read(sd, reg->reg & 0xff, &val); >> + if (ret < 0) >> + return ret; >> + >> + reg->val = val; >> + reg->size = 1; >> + >> + return 0; >> +} >> + >> +static int sensor_set_register(struct v4l2_subdev *sd, >> + const struct v4l2_dbg_register *reg) >> +{ >> + return ov5647_write(sd, reg->reg & 0xff, reg->val & 0xff); >> +} >> +#endif >> + >> +/** >> + * @short Subdev core operations registration >> + */ >> +static const struct v4l2_subdev_core_ops subdev_core_ops = { >> + .s_power = sensor_power, >> +#ifdef CONFIG_VIDEO_ADV_DEBUG >> + .g_register = sensor_get_register, >> + .s_register = sensor_set_register, >> +#endif >> +}; >> + >> +static int s_stream(struct v4l2_subdev *sd, int enable) >> +{ >> + if (enable) >> + return ov5647_stream_on(sd); >> + else >> + return ov5647_stream_off(sd); >> +} >> + >> +static const struct v4l2_subdev_video_ops subdev_video_ops = { >> + .s_stream = s_stream, >> +}; >> + >> +static int enum_mbus_code(struct v4l2_subdev *sd, >> + struct v4l2_subdev_pad_config *cfg, >> + struct v4l2_subdev_mbus_code_enum *code) >> +{ >> + if (code->index > 0) >> + return -EINVAL; >> + >> + code->code = MEDIA_BUS_FMT_SBGGR8_1X8; >> + >> + return 0; >> +} >> + >> +static const struct v4l2_subdev_pad_ops subdev_pad_ops = { >> + .enum_mbus_code = enum_mbus_code, >> +}; >> + >> +/** >> + * @short Subdev operations registration >> + * >> + */ >> +static const struct v4l2_subdev_ops subdev_ops = { >> + .core = &subdev_core_ops, >> + .video = &subdev_video_ops, >> + .pad = &subdev_pad_ops, >> +}; >> + >> +static int ov5647_detect(struct v4l2_subdev *sd) >> +{ >> + u8 read; >> + int ret; >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = ov5647_write(sd, OV5647_SW_RESET, 0x01); >> + if (ret < 0) >> + return ret; >> + >> + ret = ov5647_read(sd, OV5647_REG_CHIPID_H, &read); >> + if (ret < 0) >> + return ret; >> + >> + if (read != 0x56) { >> + dev_err(&client->dev, "Wrong model version detected"); > > You might want to tell whether it's high or low ID register that fails the > check. And possibly the bad value. Up to you. > I'll change the message and print the value that was read. >> + return -ENODEV; >> + } >> + >> + ret = ov5647_read(sd, OV5647_REG_CHIPID_L, &read); >> + if (ret < 0) >> + return ret; >> + >> + if (read != 0x47) { >> + dev_err(&client->dev, "Wrong model version detected"); >> + return -ENODEV; >> + } >> + >> + return ov5647_write(sd, OV5647_SW_RESET, 0x00); >> +} >> + >> +static int ov5647_registered(struct v4l2_subdev *sd) >> +{ >> + return 0; >> +} > > The registered() callback is optional, i.e. you can drop an empty callback. > This is legacy code I was keeping in order to do something in the future with the registered() callback, but I'll remove it. >> + >> +static int ov5647_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) >> +{ >> + struct v4l2_mbus_framefmt *format = >> + v4l2_subdev_get_try_format(sd, fh->pad, 0); >> + struct v4l2_rect *crop = >> + v4l2_subdev_get_try_crop(sd, fh->pad, 0); >> + >> + crop->left = OV5647_COLUMN_START_DEF; >> + crop->top = OV5647_ROW_START_DEF; >> + crop->width = OV5647_WINDOW_WIDTH_DEF; >> + crop->height = OV5647_WINDOW_HEIGHT_DEF; >> + >> + format->code = MEDIA_BUS_FMT_SBGGR8_1X8; >> + >> + format->width = OV5647_WINDOW_WIDTH_DEF; >> + format->height = OV5647_WINDOW_HEIGHT_DEF; >> + format->field = V4L2_FIELD_NONE; >> + format->colorspace = V4L2_COLORSPACE_SRGB; >> + >> + return sensor_power(sd, true); >> +} >> + >> +static int ov5647_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) >> +{ >> + return sensor_power(sd, false); >> +} >> + >> +/** >> + * @short Subdev internal operations registration >> + * >> + */ >> +static const struct v4l2_subdev_internal_ops ov5647_subdev_internal_ops = { >> + .registered = ov5647_registered, >> + .open = ov5647_open, >> + .close = ov5647_close, >> +}; >> + >> +static int ov5647_probe(struct i2c_client *client, >> + const struct i2c_device_id *id) >> +{ >> + struct device *dev = &client->dev; >> + struct ov5647 *sensor; >> + int ret; >> + struct v4l2_subdev *sd; >> + >> + sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL); >> + if (sensor == NULL) >> + return -ENOMEM; >> + >> + /* get system clock (xclk) */ >> + sensor->xclk = devm_clk_get(dev, "xclk"); >> + if (IS_ERR(sensor->xclk)) { >> + dev_err(dev, "could not get xclk"); >> + return PTR_ERR(sensor->xclk); >> + } >> + >> + sensor->xclk_freq = clk_get_rate(sensor->xclk); >> + if (sensor->xclk_freq != 25000000) { >> + dev_err(dev, "Unsupported clock frequency: %u\n", >> + sensor->xclk_freq); >> + return -EINVAL; >> + } >> + >> + mutex_init(&sensor->lock); >> + >> + sd = &sensor->sd; >> + v4l2_i2c_subdev_init(sd, client, &subdev_ops); >> + sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; >> + >> + sensor->pad.flags = MEDIA_PAD_FL_SOURCE; >> + sd->entity.function = MEDIA_ENT_F_CAM_SENSOR; >> + ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad); >> + if (ret < 0) >> + goto mutex_remove; >> + >> + ret = ov5647_detect(sd); >> + if (ret < 0) >> + goto error; >> + >> + ret = v4l2_async_register_subdev(sd); >> + if (ret < 0) >> + goto error; >> + >> + dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n"); >> + return 0; >> +error: >> + media_entity_cleanup(&sd->entity); >> +mutex_remove: >> + mutex_destroy(&sensor->lock); >> + return ret; >> +} >> + >> +static int ov5647_remove(struct i2c_client *client) >> +{ >> + struct v4l2_subdev *sd = i2c_get_clientdata(client); >> + struct ov5647 *ov5647 = to_state(sd); >> + >> + v4l2_async_unregister_subdev(&ov5647->sd); >> + media_entity_cleanup(&ov5647->sd.entity); >> + v4l2_device_unregister_subdev(sd); >> + mutex_destroy(&ov5647->lock); >> + >> + return 0; >> +} >> + >> +static const struct i2c_device_id ov5647_id[] = { >> + { "ov5647", 0 }, >> + { } >> +}; >> +MODULE_DEVICE_TABLE(i2c, ov5647_id); >> + >> +#if IS_ENABLED(CONFIG_OF) >> +static const struct of_device_id ov5647_of_match[] = { >> + { .compatible = "ovti,ov5647" }, >> + { /* sentinel */ }, >> +}; >> +MODULE_DEVICE_TABLE(of, ov5647_of_match); >> +#endif >> + >> +static struct i2c_driver ov5647_driver = { >> + .driver = { >> + .of_match_table = of_match_ptr(ov5647_of_match), >> + .name = SENSOR_NAME, >> + }, >> + .probe = ov5647_probe, >> + .remove = ov5647_remove, >> + .id_table = ov5647_id, >> +}; >> + >> +module_i2c_driver(ov5647_driver); >> + >> +MODULE_AUTHOR("Ramiro Oliveira <roliveir@synopsys.com>"); >> +MODULE_DESCRIPTION("A low-level driver for OmniVision ov5647 sensors"); >> +MODULE_LICENSE("GPL v2"); > -- Best Regards Ramiro Oliveira Ramiro.Oliveira@synopsys.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-21 14:49 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-21 14:49 UTC (permalink / raw) To: Sakari Ailus, Ramiro Oliveira Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Sakari, Thank you for your feedback. On 2/21/2017 12:09 PM, Sakari Ailus wrote: > Hi Ramiro, > > A few minor comments below. > > On Fri, Feb 17, 2017 at 01:14:16PM +0000, Ramiro Oliveira wrote: >> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 >> and RAW 10 output formats, and MIPI CSI-2 interface. >> >> The driver adds support for 640x480 RAW 8. >> >> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> >> --- >> MAINTAINERS | 7 + >> drivers/media/i2c/Kconfig | 11 + >> drivers/media/i2c/Makefile | 1 + >> drivers/media/i2c/ov5647.c | 638 +++++++++++++++++++++++++++++++++++++++++++++ >> 4 files changed, 657 insertions(+) >> create mode 100644 drivers/media/i2c/ov5647.c >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 8e7e8d7855ee..7bbca271acc8 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -9109,6 +9109,13 @@ M: Harald Welte <laforge-TgoAw6mPHtdg9hUCZPvPmw@public.gmane.org> >> S: Maintained >> F: drivers/char/pcmcia/cm4040_cs.* >> >> +OMNIVISION OV5647 SENSOR DRIVER >> +M: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> >> +L: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >> +T: git git://linuxtv.org/media_tree.git >> +S: Maintained >> +F: drivers/media/i2c/ov5647.c >> + >> OMNIVISION OV7670 SENSOR DRIVER >> M: Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org> >> L: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig >> index cee1dae6e014..8435b99f38bc 100644 >> --- a/drivers/media/i2c/Kconfig >> +++ b/drivers/media/i2c/Kconfig >> @@ -531,6 +531,17 @@ config VIDEO_OV2659 >> To compile this driver as a module, choose M here: the >> module will be called ov2659. >> >> +config VIDEO_OV5647 >> + tristate "OmniVision OV5647 sensor support" >> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API >> + depends on MEDIA_CAMERA_SUPPORT >> + ---help--- >> + This is a Video4Linux2 sensor-level driver for the OmniVision >> + OV5647 camera. >> + >> + To compile this driver as a module, choose M here: the >> + module will be called ov5647. >> + >> config VIDEO_OV7640 >> tristate "OmniVision OV7640 sensor support" >> depends on I2C && VIDEO_V4L2 >> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile >> index 5bc7bbeb5499..ef2ccf65f94c 100644 >> --- a/drivers/media/i2c/Makefile >> +++ b/drivers/media/i2c/Makefile >> @@ -83,3 +83,4 @@ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o >> obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o >> obj-$(CONFIG_VIDEO_OV2659) += ov2659.o >> obj-$(CONFIG_VIDEO_TC358743) += tc358743.o >> +obj-$(CONFIG_VIDEO_OV5647) += ov5647.o >> diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c >> new file mode 100644 >> index 000000000000..34e620fabbaf >> --- /dev/null >> +++ b/drivers/media/i2c/ov5647.c >> @@ -0,0 +1,638 @@ >> +/* >> + * A V4L2 driver for OmniVision OV5647 cameras. >> + * >> + * Based on Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor driver >> + * Copyright (C) 2011 Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> >> + * >> + * Based on Omnivision OV7670 Camera Driver >> + * Copyright (C) 2006-7 Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org> >> + * >> + * Copyright (C) 2016, Synopsys, Inc. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License as >> + * published by the Free Software Foundation version 2. >> + * >> + * This program is distributed .as is. WITHOUT ANY WARRANTY of any >> + * kind, whether express or implied; without even the implied warranty >> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + */ >> + >> +#include <linux/clk.h> >> +#include <linux/delay.h> >> +#include <linux/i2c.h> >> +#include <linux/init.h> >> +#include <linux/io.h> >> +#include <linux/module.h> >> +#include <linux/slab.h> >> +#include <linux/videodev2.h> >> +#include <media/v4l2-ctrls.h> > > You don't seem to implement any controls. > > The sensor likely supports exposure time (and maybe also gain) the user > might want to control. Is there an intent to add that? Otherwise the header > should be removed. > I plan to add them in the future but for now I think I'll just remove the header. >> +#include <media/v4l2-device.h> >> +#include <media/v4l2-image-sizes.h> >> +#include <media/v4l2-mediabus.h> >> +#include <media/v4l2-of.h> >> + >> +#define SENSOR_NAME "ov5647" >> + >> +#define OV5647_SW_RESET 0x1003 >> +#define OV5647_REG_CHIPID_H 0x300A >> +#define OV5647_REG_CHIPID_L 0x300B >> + >> +#define REG_TERM 0xfffe >> +#define VAL_TERM 0xfe >> +#define REG_DLY 0xffff >> + >> +#define OV5647_ROW_START 0x01 >> +#define OV5647_ROW_START_MIN 0 >> +#define OV5647_ROW_START_MAX 2004 >> +#define OV5647_ROW_START_DEF 54 >> + >> +#define OV5647_COLUMN_START 0x02 >> +#define OV5647_COLUMN_START_MIN 0 >> +#define OV5647_COLUMN_START_MAX 2750 >> +#define OV5647_COLUMN_START_DEF 16 >> + >> +#define OV5647_WINDOW_HEIGHT 0x03 >> +#define OV5647_WINDOW_HEIGHT_MIN 2 >> +#define OV5647_WINDOW_HEIGHT_MAX 2006 >> +#define OV5647_WINDOW_HEIGHT_DEF 1944 >> + >> +#define OV5647_WINDOW_WIDTH 0x04 >> +#define OV5647_WINDOW_WIDTH_MIN 2 >> +#define OV5647_WINDOW_WIDTH_MAX 2752 >> +#define OV5647_WINDOW_WIDTH_DEF 2592 >> + >> +struct regval_list { >> + u16 addr; >> + u8 data; >> +}; >> + >> +struct ov5647 { >> + struct v4l2_subdev sd; >> + struct media_pad pad; >> + struct mutex lock; >> + struct v4l2_mbus_framefmt format; >> + unsigned int width; >> + unsigned int height; >> + int power_count; >> + struct clk *xclk; >> + /* External clock frequency currently supported is 30MHz */ >> + u32 xclk_freq; >> +}; >> + >> +static inline struct ov5647 *to_state(struct v4l2_subdev *sd) >> +{ >> + return container_of(sd, struct ov5647, sd); >> +} >> + >> +static struct regval_list sensor_oe_disable_regs[] = { >> + {0x3000, 0x00}, >> + {0x3001, 0x00}, >> + {0x3002, 0x00}, >> +}; >> + >> +static struct regval_list sensor_oe_enable_regs[] = { >> + {0x3000, 0x0f}, >> + {0x3001, 0xff}, >> + {0x3002, 0xe4}, >> +}; >> + >> +static struct regval_list ov5647_640x480[] = { >> + {0x0100, 0x00}, >> + {0x0103, 0x01}, >> + {0x3034, 0x08}, >> + {0x3035, 0x21}, >> + {0x3036, 0x46}, >> + {0x303c, 0x11}, >> + {0x3106, 0xf5}, >> + {0x3821, 0x07}, >> + {0x3820, 0x41}, >> + {0x3827, 0xec}, >> + {0x370c, 0x0f}, >> + {0x3612, 0x59}, >> + {0x3618, 0x00}, >> + {0x5000, 0x06}, >> + {0x5001, 0x01}, >> + {0x5002, 0x41}, >> + {0x5003, 0x08}, >> + {0x5a00, 0x08}, >> + {0x3000, 0x00}, >> + {0x3001, 0x00}, >> + {0x3002, 0x00}, >> + {0x3016, 0x08}, >> + {0x3017, 0xe0}, >> + {0x3018, 0x44}, >> + {0x301c, 0xf8}, >> + {0x301d, 0xf0}, >> + {0x3a18, 0x00}, >> + {0x3a19, 0xf8}, >> + {0x3c01, 0x80}, >> + {0x3b07, 0x0c}, >> + {0x380c, 0x07}, >> + {0x380d, 0x68}, >> + {0x380e, 0x03}, >> + {0x380f, 0xd8}, >> + {0x3814, 0x31}, >> + {0x3815, 0x31}, >> + {0x3708, 0x64}, >> + {0x3709, 0x52}, >> + {0x3808, 0x02}, >> + {0x3809, 0x80}, >> + {0x380a, 0x01}, >> + {0x380b, 0xE0}, >> + {0x3801, 0x00}, >> + {0x3802, 0x00}, >> + {0x3803, 0x00}, >> + {0x3804, 0x0a}, >> + {0x3805, 0x3f}, >> + {0x3806, 0x07}, >> + {0x3807, 0xa1}, >> + {0x3811, 0x08}, >> + {0x3813, 0x02}, >> + {0x3630, 0x2e}, >> + {0x3632, 0xe2}, >> + {0x3633, 0x23}, >> + {0x3634, 0x44}, >> + {0x3636, 0x06}, >> + {0x3620, 0x64}, >> + {0x3621, 0xe0}, >> + {0x3600, 0x37}, >> + {0x3704, 0xa0}, >> + {0x3703, 0x5a}, >> + {0x3715, 0x78}, >> + {0x3717, 0x01}, >> + {0x3731, 0x02}, >> + {0x370b, 0x60}, >> + {0x3705, 0x1a}, >> + {0x3f05, 0x02}, >> + {0x3f06, 0x10}, >> + {0x3f01, 0x0a}, >> + {0x3a08, 0x01}, >> + {0x3a09, 0x27}, >> + {0x3a0a, 0x00}, >> + {0x3a0b, 0xf6}, >> + {0x3a0d, 0x04}, >> + {0x3a0e, 0x03}, >> + {0x3a0f, 0x58}, >> + {0x3a10, 0x50}, >> + {0x3a1b, 0x58}, >> + {0x3a1e, 0x50}, >> + {0x3a11, 0x60}, >> + {0x3a1f, 0x28}, >> + {0x4001, 0x02}, >> + {0x4004, 0x02}, >> + {0x4000, 0x09}, >> + {0x4837, 0x24}, >> + {0x4050, 0x6e}, >> + {0x4051, 0x8f}, >> + {0x0100, 0x01}, >> +}; >> + >> +static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val) >> +{ >> + int ret; >> + unsigned char data[3] = { reg >> 8, reg & 0xff, val}; >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = i2c_master_send(client, data, 3); >> + if (ret < 0) >> + dev_dbg(&client->dev, "%s: i2c write error, reg: %x\n", >> + __func__, reg); >> + >> + return ret; >> +} >> + >> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) >> +{ >> + int ret; >> + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = i2c_master_send(client, data_w, 2); >> + if (ret < 0) { >> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >> + __func__, reg); >> + return ret; >> + } >> + >> + ret = i2c_master_recv(client, val, 1); >> + if (ret < 0) >> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >> + __func__, reg); >> + >> + return ret; >> + >> +} >> + >> +static int ov5647_write_array(struct v4l2_subdev *sd, >> + struct regval_list *regs, int array_size) >> +{ >> + int i = 0, ret; >> + >> + for (i = 0; i < array_size; i++) { >> + ret = ov5647_write(sd, regs[i].addr, regs[i].data); >> + if (ret < 0) >> + return ret; >> + } >> + >> + return 0; >> +} >> + >> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel) >> +{ >> + u8 channel_id; >> + int ret; >> + >> + ret = ov5647_read(sd, 0x4814, &channel_id); >> + if (ret < 0) >> + return ret; >> + >> + channel_id &= ~(3 << 6); >> + return ov5647_write(sd, 0x4814, channel_id | (channel << 6)); >> +} >> + >> +static int ov5647_stream_on(struct v4l2_subdev *sd) >> +{ >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ov5647_write(sd, 0x4202, 0x00); >> + >> + dev_dbg(&client->dev, "Stream on"); >> + >> + return ov5647_write(sd, 0x300D, 0x00); >> +} >> + >> +static int ov5647_stream_off(struct v4l2_subdev *sd) >> +{ >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ov5647_write(sd, 0x4202, 0x0f); >> + >> + dev_dbg(&client->dev, "Stream off"); >> + >> + return ov5647_write(sd, 0x300D, 0x01); >> +} >> + >> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby) >> +{ >> + int ret; >> + u8 rdval; >> + >> + ret = ov5647_read(sd, 0x0100, &rdval); >> + if (ret < 0) >> + return ret; >> + >> + if (standby) >> + rdval &= ~0x01; >> + else >> + rdval |= 0x01; >> + >> + return ov5647_write(sd, 0x0100, rdval); >> +} >> + >> +static int __sensor_init(struct v4l2_subdev *sd) >> +{ >> + int ret; >> + u8 resetval; >> + u8 rdval; >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + dev_dbg(&client->dev, "sensor init\n"); >> + >> + ret = ov5647_read(sd, 0x0100, &rdval); >> + if (ret < 0) >> + return ret; >> + >> + ret = ov5647_write_array(sd, ov5647_640x480, >> + ARRAY_SIZE(ov5647_640x480)); >> + if (ret < 0) { >> + dev_err(&client->dev, "write sensor default regs error\n"); >> + return ret; >> + } >> + >> + ret = ov5647_set_virtual_channel(sd, 0); >> + if (ret < 0) >> + return ret; >> + >> + ret = ov5647_read(sd, 0x0100, &resetval); >> + if (ret < 0) >> + return ret; >> + >> + if (!(resetval & 0x01)) { >> + dev_err(&client->dev, "Device was in SW standby"); >> + ret = ov5647_write(sd, 0x0100, 0x01); >> + if (ret < 0) >> + return ret; >> + } >> + >> + return ov5647_write(sd, 0x4800, 0x04); >> +} >> + >> +static int sensor_power(struct v4l2_subdev *sd, int on) >> +{ >> + int ret; >> + struct ov5647 *ov5647 = to_state(sd); >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = 0; > > You can assign in variable declaration. > Yes, you're right. >> + mutex_lock(&ov5647->lock); >> + >> + if (on && !ov5647->power_count) { >> + dev_dbg(&client->dev, "OV5647 power on\n"); >> + >> + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); >> + >> + ret = clk_prepare_enable(ov5647->xclk); >> + if (ret < 0) { >> + dev_err(&client->dev, "clk prepare enable failed\n"); >> + goto out; >> + } >> + >> + ret = ov5647_write_array(sd, sensor_oe_enable_regs, >> + ARRAY_SIZE(sensor_oe_enable_regs)); >> + if (ret < 0) { >> + clk_disable_unprepare(ov5647->xclk); >> + dev_err(&client->dev, >> + "write sensor_oe_enable_regs error\n"); >> + goto out; >> + } >> + >> + ret = __sensor_init(sd); >> + if (ret < 0) { >> + clk_disable_unprepare(ov5647->xclk); >> + dev_err(&client->dev, >> + "Camera not available, check Power\n"); >> + goto out; >> + } >> + } else if (!on && ov5647->power_count == 1) { >> + dev_dbg(&client->dev, "OV5647 power off\n"); >> + >> + dev_dbg(&client->dev, "disable oe\n"); >> + ret = ov5647_write_array(sd, sensor_oe_disable_regs, >> + ARRAY_SIZE(sensor_oe_disable_regs)); >> + >> + if (ret < 0) >> + dev_dbg(&client->dev, "disable oe failed\n"); >> + >> + ret = set_sw_standby(sd, true); >> + >> + if (ret < 0) >> + dev_dbg(&client->dev, "soft stby failed\n"); >> + >> + clk_disable_unprepare(ov5647->xclk); >> + } >> + >> + /* Update the power count. */ >> + ov5647->power_count += on ? 1 : -1; >> + WARN_ON(ov5647->power_count < 0); >> + >> +out: >> + mutex_unlock(&ov5647->lock); >> + >> + return ret; >> +} >> + >> +#ifdef CONFIG_VIDEO_ADV_DEBUG >> +static int sensor_get_register(struct v4l2_subdev *sd, >> + struct v4l2_dbg_register *reg) >> +{ >> + u8 val; >> + int ret; >> + >> + ret = ov5647_read(sd, reg->reg & 0xff, &val); >> + if (ret < 0) >> + return ret; >> + >> + reg->val = val; >> + reg->size = 1; >> + >> + return 0; >> +} >> + >> +static int sensor_set_register(struct v4l2_subdev *sd, >> + const struct v4l2_dbg_register *reg) >> +{ >> + return ov5647_write(sd, reg->reg & 0xff, reg->val & 0xff); >> +} >> +#endif >> + >> +/** >> + * @short Subdev core operations registration >> + */ >> +static const struct v4l2_subdev_core_ops subdev_core_ops = { >> + .s_power = sensor_power, >> +#ifdef CONFIG_VIDEO_ADV_DEBUG >> + .g_register = sensor_get_register, >> + .s_register = sensor_set_register, >> +#endif >> +}; >> + >> +static int s_stream(struct v4l2_subdev *sd, int enable) >> +{ >> + if (enable) >> + return ov5647_stream_on(sd); >> + else >> + return ov5647_stream_off(sd); >> +} >> + >> +static const struct v4l2_subdev_video_ops subdev_video_ops = { >> + .s_stream = s_stream, >> +}; >> + >> +static int enum_mbus_code(struct v4l2_subdev *sd, >> + struct v4l2_subdev_pad_config *cfg, >> + struct v4l2_subdev_mbus_code_enum *code) >> +{ >> + if (code->index > 0) >> + return -EINVAL; >> + >> + code->code = MEDIA_BUS_FMT_SBGGR8_1X8; >> + >> + return 0; >> +} >> + >> +static const struct v4l2_subdev_pad_ops subdev_pad_ops = { >> + .enum_mbus_code = enum_mbus_code, >> +}; >> + >> +/** >> + * @short Subdev operations registration >> + * >> + */ >> +static const struct v4l2_subdev_ops subdev_ops = { >> + .core = &subdev_core_ops, >> + .video = &subdev_video_ops, >> + .pad = &subdev_pad_ops, >> +}; >> + >> +static int ov5647_detect(struct v4l2_subdev *sd) >> +{ >> + u8 read; >> + int ret; >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = ov5647_write(sd, OV5647_SW_RESET, 0x01); >> + if (ret < 0) >> + return ret; >> + >> + ret = ov5647_read(sd, OV5647_REG_CHIPID_H, &read); >> + if (ret < 0) >> + return ret; >> + >> + if (read != 0x56) { >> + dev_err(&client->dev, "Wrong model version detected"); > > You might want to tell whether it's high or low ID register that fails the > check. And possibly the bad value. Up to you. > I'll change the message and print the value that was read. >> + return -ENODEV; >> + } >> + >> + ret = ov5647_read(sd, OV5647_REG_CHIPID_L, &read); >> + if (ret < 0) >> + return ret; >> + >> + if (read != 0x47) { >> + dev_err(&client->dev, "Wrong model version detected"); >> + return -ENODEV; >> + } >> + >> + return ov5647_write(sd, OV5647_SW_RESET, 0x00); >> +} >> + >> +static int ov5647_registered(struct v4l2_subdev *sd) >> +{ >> + return 0; >> +} > > The registered() callback is optional, i.e. you can drop an empty callback. > This is legacy code I was keeping in order to do something in the future with the registered() callback, but I'll remove it. >> + >> +static int ov5647_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) >> +{ >> + struct v4l2_mbus_framefmt *format = >> + v4l2_subdev_get_try_format(sd, fh->pad, 0); >> + struct v4l2_rect *crop = >> + v4l2_subdev_get_try_crop(sd, fh->pad, 0); >> + >> + crop->left = OV5647_COLUMN_START_DEF; >> + crop->top = OV5647_ROW_START_DEF; >> + crop->width = OV5647_WINDOW_WIDTH_DEF; >> + crop->height = OV5647_WINDOW_HEIGHT_DEF; >> + >> + format->code = MEDIA_BUS_FMT_SBGGR8_1X8; >> + >> + format->width = OV5647_WINDOW_WIDTH_DEF; >> + format->height = OV5647_WINDOW_HEIGHT_DEF; >> + format->field = V4L2_FIELD_NONE; >> + format->colorspace = V4L2_COLORSPACE_SRGB; >> + >> + return sensor_power(sd, true); >> +} >> + >> +static int ov5647_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) >> +{ >> + return sensor_power(sd, false); >> +} >> + >> +/** >> + * @short Subdev internal operations registration >> + * >> + */ >> +static const struct v4l2_subdev_internal_ops ov5647_subdev_internal_ops = { >> + .registered = ov5647_registered, >> + .open = ov5647_open, >> + .close = ov5647_close, >> +}; >> + >> +static int ov5647_probe(struct i2c_client *client, >> + const struct i2c_device_id *id) >> +{ >> + struct device *dev = &client->dev; >> + struct ov5647 *sensor; >> + int ret; >> + struct v4l2_subdev *sd; >> + >> + sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL); >> + if (sensor == NULL) >> + return -ENOMEM; >> + >> + /* get system clock (xclk) */ >> + sensor->xclk = devm_clk_get(dev, "xclk"); >> + if (IS_ERR(sensor->xclk)) { >> + dev_err(dev, "could not get xclk"); >> + return PTR_ERR(sensor->xclk); >> + } >> + >> + sensor->xclk_freq = clk_get_rate(sensor->xclk); >> + if (sensor->xclk_freq != 25000000) { >> + dev_err(dev, "Unsupported clock frequency: %u\n", >> + sensor->xclk_freq); >> + return -EINVAL; >> + } >> + >> + mutex_init(&sensor->lock); >> + >> + sd = &sensor->sd; >> + v4l2_i2c_subdev_init(sd, client, &subdev_ops); >> + sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; >> + >> + sensor->pad.flags = MEDIA_PAD_FL_SOURCE; >> + sd->entity.function = MEDIA_ENT_F_CAM_SENSOR; >> + ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad); >> + if (ret < 0) >> + goto mutex_remove; >> + >> + ret = ov5647_detect(sd); >> + if (ret < 0) >> + goto error; >> + >> + ret = v4l2_async_register_subdev(sd); >> + if (ret < 0) >> + goto error; >> + >> + dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n"); >> + return 0; >> +error: >> + media_entity_cleanup(&sd->entity); >> +mutex_remove: >> + mutex_destroy(&sensor->lock); >> + return ret; >> +} >> + >> +static int ov5647_remove(struct i2c_client *client) >> +{ >> + struct v4l2_subdev *sd = i2c_get_clientdata(client); >> + struct ov5647 *ov5647 = to_state(sd); >> + >> + v4l2_async_unregister_subdev(&ov5647->sd); >> + media_entity_cleanup(&ov5647->sd.entity); >> + v4l2_device_unregister_subdev(sd); >> + mutex_destroy(&ov5647->lock); >> + >> + return 0; >> +} >> + >> +static const struct i2c_device_id ov5647_id[] = { >> + { "ov5647", 0 }, >> + { } >> +}; >> +MODULE_DEVICE_TABLE(i2c, ov5647_id); >> + >> +#if IS_ENABLED(CONFIG_OF) >> +static const struct of_device_id ov5647_of_match[] = { >> + { .compatible = "ovti,ov5647" }, >> + { /* sentinel */ }, >> +}; >> +MODULE_DEVICE_TABLE(of, ov5647_of_match); >> +#endif >> + >> +static struct i2c_driver ov5647_driver = { >> + .driver = { >> + .of_match_table = of_match_ptr(ov5647_of_match), >> + .name = SENSOR_NAME, >> + }, >> + .probe = ov5647_probe, >> + .remove = ov5647_remove, >> + .id_table = ov5647_id, >> +}; >> + >> +module_i2c_driver(ov5647_driver); >> + >> +MODULE_AUTHOR("Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>"); >> +MODULE_DESCRIPTION("A low-level driver for OmniVision ov5647 sensors"); >> +MODULE_LICENSE("GPL v2"); > -- Best Regards Ramiro Oliveira Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. 2017-02-21 14:49 ` Ramiro Oliveira (?) @ 2017-02-21 14:58 ` Sakari Ailus -1 siblings, 0 replies; 44+ messages in thread From: Sakari Ailus @ 2017-02-21 14:58 UTC (permalink / raw) To: Ramiro Oliveira Cc: linux-kernel, linux-media, devicetree, vladimir_zapolskiy, CARLOS.PALMINHA, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, On Tue, Feb 21, 2017 at 02:49:12PM +0000, Ramiro Oliveira wrote: > Hi Sakari, > > Thank you for your feedback. You're welcome. An additional note as you don't implement any controls --- some CSI-2 receivers may need to know the link frequency to know how to program the receiver; they'll simply fail to start streaming if you don't. <URL:http://hverkuil.home.xs4all.nl/spec/uapi/v4l/extended-controls.html#image-process-control-reference> -- Regards, Sakari Ailus e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-21 15:54 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-21 15:54 UTC (permalink / raw) To: Ramiro Oliveira, linux-kernel, linux-media, devicetree Cc: CARLOS.PALMINHA, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, please find some review comments below. On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: > The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 > and RAW 10 output formats, and MIPI CSI-2 interface. > > The driver adds support for 640x480 RAW 8. > > Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> > --- [snip] > + > +struct ov5647 { > + struct v4l2_subdev sd; > + struct media_pad pad; > + struct mutex lock; > + struct v4l2_mbus_framefmt format; > + unsigned int width; > + unsigned int height; > + int power_count; > + struct clk *xclk; > + /* External clock frequency currently supported is 30MHz */ > + u32 xclk_freq; See a comment about 25MHz vs 30MHz below. Also I assume you can remove 'xclk_freq' from the struct fields, it can be replaced by a local variable. > +}; [snip] > + > +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) > +{ > + int ret; > + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = i2c_master_send(client, data_w, 2); > + if (ret < 0) { > + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", s/i2c read error/i2c write error/ > + __func__, reg); > + return ret; > + } > + > + ret = i2c_master_recv(client, val, 1); > + if (ret < 0) > + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", > + __func__, reg); > + > + return ret; > + Please remove the empty line above. > +} > + > +static int ov5647_write_array(struct v4l2_subdev *sd, > + struct regval_list *regs, int array_size) > +{ > + int i = 0, ret; Assignment of 'i' on declaration is not needed, please remove. > + > + for (i = 0; i < array_size; i++) { > + ret = ov5647_write(sd, regs[i].addr, regs[i].data); > + if (ret < 0) > + return ret; > + } > + > + return 0; > +} > + > +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel) > +{ > + u8 channel_id; > + int ret; > + > + ret = ov5647_read(sd, 0x4814, &channel_id); > + if (ret < 0) > + return ret; > + > + channel_id &= ~(3 << 6); > + return ov5647_write(sd, 0x4814, channel_id | (channel << 6)); > +} > + > +static int ov5647_stream_on(struct v4l2_subdev *sd) > +{ > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ov5647_write(sd, 0x4202, 0x00); Should you add a check of the returned value? > + > + dev_dbg(&client->dev, "Stream on"); I would suggest to remove dev_dbg(), because ftrace will report to a user, when this function is called. Also dev_dbg() in the middle of two I2C transfers in a row looks as being placed improperly. > + > + return ov5647_write(sd, 0x300D, 0x00); > +} > + > +static int ov5647_stream_off(struct v4l2_subdev *sd) > +{ > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ov5647_write(sd, 0x4202, 0x0f); Should you add a check of the returned value? > + > + dev_dbg(&client->dev, "Stream off"); I would suggest to remove dev_dbg(), because ftrace will report to a user, when this function is called. Also dev_dbg() in the middle of two I2C transfers in a row looks as being placed improperly. > + > + return ov5647_write(sd, 0x300D, 0x01); > +} > + > +static int set_sw_standby(struct v4l2_subdev *sd, bool standby) > +{ > + int ret; > + u8 rdval; > + > + ret = ov5647_read(sd, 0x0100, &rdval); > + if (ret < 0) > + return ret; > + > + if (standby) > + rdval &= ~0x01; > + else > + rdval |= 0x01; > + > + return ov5647_write(sd, 0x0100, rdval); > +} > + > +static int __sensor_init(struct v4l2_subdev *sd) > +{ > + int ret; > + u8 resetval; > + u8 rdval; It could be possible to put declarations of 'resetval' and 'rdval' on the same line. > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + dev_dbg(&client->dev, "sensor init\n"); > + > + ret = ov5647_read(sd, 0x0100, &rdval); > + if (ret < 0) > + return ret; > + > + ret = ov5647_write_array(sd, ov5647_640x480, > + ARRAY_SIZE(ov5647_640x480)); > + if (ret < 0) { > + dev_err(&client->dev, "write sensor default regs error\n"); > + return ret; > + } > + > + ret = ov5647_set_virtual_channel(sd, 0); > + if (ret < 0) > + return ret; > + > + ret = ov5647_read(sd, 0x0100, &resetval); > + if (ret < 0) > + return ret; > + > + if (!(resetval & 0x01)) { > + dev_err(&client->dev, "Device was in SW standby"); > + ret = ov5647_write(sd, 0x0100, 0x01); > + if (ret < 0) > + return ret; > + } > + > + return ov5647_write(sd, 0x4800, 0x04); > +} > + > +static int sensor_power(struct v4l2_subdev *sd, int on) > +{ > + int ret; > + struct ov5647 *ov5647 = to_state(sd); > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = 0; > + mutex_lock(&ov5647->lock); > + > + if (on && !ov5647->power_count) { > + dev_dbg(&client->dev, "OV5647 power on\n"); > + > + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); Now clk_set_rate() is redundant, please remove it. If once it is needed again, please move it to the .probe function, so it is called only once in the runtime. > + > + ret = clk_prepare_enable(ov5647->xclk); I wonder would it be possible to unload the driver or to unbind the device and leave the clock unintentionally enabled? If yes, then this is a bug. > + if (ret < 0) { > + dev_err(&client->dev, "clk prepare enable failed\n"); > + goto out; > + } > + > + ret = ov5647_write_array(sd, sensor_oe_enable_regs, > + ARRAY_SIZE(sensor_oe_enable_regs)); > + if (ret < 0) { > + clk_disable_unprepare(ov5647->xclk); > + dev_err(&client->dev, > + "write sensor_oe_enable_regs error\n"); > + goto out; > + } > + > + ret = __sensor_init(sd); > + if (ret < 0) { > + clk_disable_unprepare(ov5647->xclk); > + dev_err(&client->dev, > + "Camera not available, check Power\n"); > + goto out; > + } > + } else if (!on && ov5647->power_count == 1) { > + dev_dbg(&client->dev, "OV5647 power off\n"); > + > + dev_dbg(&client->dev, "disable oe\n"); One of two dev_dbg()'s above is apparently redundant. > + ret = ov5647_write_array(sd, sensor_oe_disable_regs, > + ARRAY_SIZE(sensor_oe_disable_regs)); > + > + if (ret < 0) > + dev_dbg(&client->dev, "disable oe failed\n"); > + > + ret = set_sw_standby(sd, true); > + > + if (ret < 0) > + dev_dbg(&client->dev, "soft stby failed\n"); > + > + clk_disable_unprepare(ov5647->xclk); > + } > + > + /* Update the power count. */ > + ov5647->power_count += on ? 1 : -1; > + WARN_ON(ov5647->power_count < 0); > + > +out: > + mutex_unlock(&ov5647->lock); > + > + return ret; > +} > + [snip] > + > +static int ov5647_probe(struct i2c_client *client, > + const struct i2c_device_id *id) > +{ > + struct device *dev = &client->dev; > + struct ov5647 *sensor; > + int ret; > + struct v4l2_subdev *sd; > + > + sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL); > + if (sensor == NULL) if (!sensor) is a bit shorter. > + return -ENOMEM; > + > + /* get system clock (xclk) */ > + sensor->xclk = devm_clk_get(dev, "xclk"); > + if (IS_ERR(sensor->xclk)) { > + dev_err(dev, "could not get xclk"); > + return PTR_ERR(sensor->xclk); > + } > + > + sensor->xclk_freq = clk_get_rate(sensor->xclk); > + if (sensor->xclk_freq != 25000000) { A comment in "struct ov5647" declaration says about 30MHz, which one is correct? > + dev_err(dev, "Unsupported clock frequency: %u\n", > + sensor->xclk_freq); > + return -EINVAL; > + } > + > + mutex_init(&sensor->lock); > + > + sd = &sensor->sd; > + v4l2_i2c_subdev_init(sd, client, &subdev_ops); > + sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; > + > + sensor->pad.flags = MEDIA_PAD_FL_SOURCE; > + sd->entity.function = MEDIA_ENT_F_CAM_SENSOR; > + ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad); > + if (ret < 0) > + goto mutex_remove; > + > + ret = ov5647_detect(sd); > + if (ret < 0) > + goto error; > + > + ret = v4l2_async_register_subdev(sd); > + if (ret < 0) > + goto error; > + > + dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n"); > + return 0; > +error: > + media_entity_cleanup(&sd->entity); > +mutex_remove: > + mutex_destroy(&sensor->lock); > + return ret; > +} > + [snip] The driver looks good in general IMO. -- With best wishes, Vladimir ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-21 15:54 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-21 15:54 UTC (permalink / raw) To: Ramiro Oliveira, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, please find some review comments below. On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: > The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 > and RAW 10 output formats, and MIPI CSI-2 interface. > > The driver adds support for 640x480 RAW 8. > > Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> > --- [snip] > + > +struct ov5647 { > + struct v4l2_subdev sd; > + struct media_pad pad; > + struct mutex lock; > + struct v4l2_mbus_framefmt format; > + unsigned int width; > + unsigned int height; > + int power_count; > + struct clk *xclk; > + /* External clock frequency currently supported is 30MHz */ > + u32 xclk_freq; See a comment about 25MHz vs 30MHz below. Also I assume you can remove 'xclk_freq' from the struct fields, it can be replaced by a local variable. > +}; [snip] > + > +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) > +{ > + int ret; > + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = i2c_master_send(client, data_w, 2); > + if (ret < 0) { > + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", s/i2c read error/i2c write error/ > + __func__, reg); > + return ret; > + } > + > + ret = i2c_master_recv(client, val, 1); > + if (ret < 0) > + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", > + __func__, reg); > + > + return ret; > + Please remove the empty line above. > +} > + > +static int ov5647_write_array(struct v4l2_subdev *sd, > + struct regval_list *regs, int array_size) > +{ > + int i = 0, ret; Assignment of 'i' on declaration is not needed, please remove. > + > + for (i = 0; i < array_size; i++) { > + ret = ov5647_write(sd, regs[i].addr, regs[i].data); > + if (ret < 0) > + return ret; > + } > + > + return 0; > +} > + > +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel) > +{ > + u8 channel_id; > + int ret; > + > + ret = ov5647_read(sd, 0x4814, &channel_id); > + if (ret < 0) > + return ret; > + > + channel_id &= ~(3 << 6); > + return ov5647_write(sd, 0x4814, channel_id | (channel << 6)); > +} > + > +static int ov5647_stream_on(struct v4l2_subdev *sd) > +{ > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ov5647_write(sd, 0x4202, 0x00); Should you add a check of the returned value? > + > + dev_dbg(&client->dev, "Stream on"); I would suggest to remove dev_dbg(), because ftrace will report to a user, when this function is called. Also dev_dbg() in the middle of two I2C transfers in a row looks as being placed improperly. > + > + return ov5647_write(sd, 0x300D, 0x00); > +} > + > +static int ov5647_stream_off(struct v4l2_subdev *sd) > +{ > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ov5647_write(sd, 0x4202, 0x0f); Should you add a check of the returned value? > + > + dev_dbg(&client->dev, "Stream off"); I would suggest to remove dev_dbg(), because ftrace will report to a user, when this function is called. Also dev_dbg() in the middle of two I2C transfers in a row looks as being placed improperly. > + > + return ov5647_write(sd, 0x300D, 0x01); > +} > + > +static int set_sw_standby(struct v4l2_subdev *sd, bool standby) > +{ > + int ret; > + u8 rdval; > + > + ret = ov5647_read(sd, 0x0100, &rdval); > + if (ret < 0) > + return ret; > + > + if (standby) > + rdval &= ~0x01; > + else > + rdval |= 0x01; > + > + return ov5647_write(sd, 0x0100, rdval); > +} > + > +static int __sensor_init(struct v4l2_subdev *sd) > +{ > + int ret; > + u8 resetval; > + u8 rdval; It could be possible to put declarations of 'resetval' and 'rdval' on the same line. > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + dev_dbg(&client->dev, "sensor init\n"); > + > + ret = ov5647_read(sd, 0x0100, &rdval); > + if (ret < 0) > + return ret; > + > + ret = ov5647_write_array(sd, ov5647_640x480, > + ARRAY_SIZE(ov5647_640x480)); > + if (ret < 0) { > + dev_err(&client->dev, "write sensor default regs error\n"); > + return ret; > + } > + > + ret = ov5647_set_virtual_channel(sd, 0); > + if (ret < 0) > + return ret; > + > + ret = ov5647_read(sd, 0x0100, &resetval); > + if (ret < 0) > + return ret; > + > + if (!(resetval & 0x01)) { > + dev_err(&client->dev, "Device was in SW standby"); > + ret = ov5647_write(sd, 0x0100, 0x01); > + if (ret < 0) > + return ret; > + } > + > + return ov5647_write(sd, 0x4800, 0x04); > +} > + > +static int sensor_power(struct v4l2_subdev *sd, int on) > +{ > + int ret; > + struct ov5647 *ov5647 = to_state(sd); > + struct i2c_client *client = v4l2_get_subdevdata(sd); > + > + ret = 0; > + mutex_lock(&ov5647->lock); > + > + if (on && !ov5647->power_count) { > + dev_dbg(&client->dev, "OV5647 power on\n"); > + > + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); Now clk_set_rate() is redundant, please remove it. If once it is needed again, please move it to the .probe function, so it is called only once in the runtime. > + > + ret = clk_prepare_enable(ov5647->xclk); I wonder would it be possible to unload the driver or to unbind the device and leave the clock unintentionally enabled? If yes, then this is a bug. > + if (ret < 0) { > + dev_err(&client->dev, "clk prepare enable failed\n"); > + goto out; > + } > + > + ret = ov5647_write_array(sd, sensor_oe_enable_regs, > + ARRAY_SIZE(sensor_oe_enable_regs)); > + if (ret < 0) { > + clk_disable_unprepare(ov5647->xclk); > + dev_err(&client->dev, > + "write sensor_oe_enable_regs error\n"); > + goto out; > + } > + > + ret = __sensor_init(sd); > + if (ret < 0) { > + clk_disable_unprepare(ov5647->xclk); > + dev_err(&client->dev, > + "Camera not available, check Power\n"); > + goto out; > + } > + } else if (!on && ov5647->power_count == 1) { > + dev_dbg(&client->dev, "OV5647 power off\n"); > + > + dev_dbg(&client->dev, "disable oe\n"); One of two dev_dbg()'s above is apparently redundant. > + ret = ov5647_write_array(sd, sensor_oe_disable_regs, > + ARRAY_SIZE(sensor_oe_disable_regs)); > + > + if (ret < 0) > + dev_dbg(&client->dev, "disable oe failed\n"); > + > + ret = set_sw_standby(sd, true); > + > + if (ret < 0) > + dev_dbg(&client->dev, "soft stby failed\n"); > + > + clk_disable_unprepare(ov5647->xclk); > + } > + > + /* Update the power count. */ > + ov5647->power_count += on ? 1 : -1; > + WARN_ON(ov5647->power_count < 0); > + > +out: > + mutex_unlock(&ov5647->lock); > + > + return ret; > +} > + [snip] > + > +static int ov5647_probe(struct i2c_client *client, > + const struct i2c_device_id *id) > +{ > + struct device *dev = &client->dev; > + struct ov5647 *sensor; > + int ret; > + struct v4l2_subdev *sd; > + > + sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL); > + if (sensor == NULL) if (!sensor) is a bit shorter. > + return -ENOMEM; > + > + /* get system clock (xclk) */ > + sensor->xclk = devm_clk_get(dev, "xclk"); > + if (IS_ERR(sensor->xclk)) { > + dev_err(dev, "could not get xclk"); > + return PTR_ERR(sensor->xclk); > + } > + > + sensor->xclk_freq = clk_get_rate(sensor->xclk); > + if (sensor->xclk_freq != 25000000) { A comment in "struct ov5647" declaration says about 30MHz, which one is correct? > + dev_err(dev, "Unsupported clock frequency: %u\n", > + sensor->xclk_freq); > + return -EINVAL; > + } > + > + mutex_init(&sensor->lock); > + > + sd = &sensor->sd; > + v4l2_i2c_subdev_init(sd, client, &subdev_ops); > + sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; > + > + sensor->pad.flags = MEDIA_PAD_FL_SOURCE; > + sd->entity.function = MEDIA_ENT_F_CAM_SENSOR; > + ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad); > + if (ret < 0) > + goto mutex_remove; > + > + ret = ov5647_detect(sd); > + if (ret < 0) > + goto error; > + > + ret = v4l2_async_register_subdev(sd); > + if (ret < 0) > + goto error; > + > + dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n"); > + return 0; > +error: > + media_entity_cleanup(&sd->entity); > +mutex_remove: > + mutex_destroy(&sensor->lock); > + return ret; > +} > + [snip] The driver looks good in general IMO. -- With best wishes, Vladimir -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. 2017-02-21 15:54 ` Vladimir Zapolskiy @ 2017-02-21 16:42 ` Ramiro Oliveira -1 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-21 16:42 UTC (permalink / raw) To: Vladimir Zapolskiy, Ramiro Oliveira, linux-kernel, linux-media, devicetree Cc: CARLOS.PALMINHA, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Vladimir, Thank you for your feedback On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote: > Hi Ramiro, > > please find some review comments below. > > On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: >> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 >> and RAW 10 output formats, and MIPI CSI-2 interface. >> >> The driver adds support for 640x480 RAW 8. >> >> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> >> --- > > [snip] > >> + >> +struct ov5647 { >> + struct v4l2_subdev sd; >> + struct media_pad pad; >> + struct mutex lock; >> + struct v4l2_mbus_framefmt format; >> + unsigned int width; >> + unsigned int height; >> + int power_count; >> + struct clk *xclk; >> + /* External clock frequency currently supported is 30MHz */ >> + u32 xclk_freq; > > See a comment about 25MHz vs 30MHz below. > > Also I assume you can remove 'xclk_freq' from the struct fields, > it can be replaced by a local variable. > I'll do that. >> +}; > > [snip] > >> + >> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) >> +{ >> + int ret; >> + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = i2c_master_send(client, data_w, 2); >> + if (ret < 0) { >> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", > > s/i2c read error/i2c write error/ > I'm not sure I understand what you mean. >> + __func__, reg); >> + return ret; >> + } >> + >> + ret = i2c_master_recv(client, val, 1); >> + if (ret < 0) >> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >> + __func__, reg); >> + >> + return ret; >> + > > Please remove the empty line above. > Ok. >> +} >> + >> +static int ov5647_write_array(struct v4l2_subdev *sd, >> + struct regval_list *regs, int array_size) >> +{ >> + int i = 0, ret; > > Assignment of 'i' on declaration is not needed, please remove. > Ok. >> + >> + for (i = 0; i < array_size; i++) { >> + ret = ov5647_write(sd, regs[i].addr, regs[i].data); >> + if (ret < 0) >> + return ret; >> + } >> + >> + return 0; >> +} >> + >> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel) >> +{ >> + u8 channel_id; >> + int ret; >> + >> + ret = ov5647_read(sd, 0x4814, &channel_id); >> + if (ret < 0) >> + return ret; >> + >> + channel_id &= ~(3 << 6); >> + return ov5647_write(sd, 0x4814, channel_id | (channel << 6)); >> +} >> + >> +static int ov5647_stream_on(struct v4l2_subdev *sd) >> +{ >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ov5647_write(sd, 0x4202, 0x00); > > Should you add a check of the returned value? > I'll add it. >> + >> + dev_dbg(&client->dev, "Stream on"); > > I would suggest to remove dev_dbg(), because ftrace will report to a user, > when this function is called. > > Also dev_dbg() in the middle of two I2C transfers in a row looks as being > placed improperly. > I'll remove it. >> + >> + return ov5647_write(sd, 0x300D, 0x00); >> +} >> + >> +static int ov5647_stream_off(struct v4l2_subdev *sd) >> +{ >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ov5647_write(sd, 0x4202, 0x0f); > > Should you add a check of the returned value? > I'll add it. >> + >> + dev_dbg(&client->dev, "Stream off"); > > I would suggest to remove dev_dbg(), because ftrace will report to a user, > when this function is called. > > Also dev_dbg() in the middle of two I2C transfers in a row looks as being > placed improperly. > I'll remove it. >> + >> + return ov5647_write(sd, 0x300D, 0x01); >> +} >> + >> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby) >> +{ >> + int ret; >> + u8 rdval; >> + >> + ret = ov5647_read(sd, 0x0100, &rdval); >> + if (ret < 0) >> + return ret; >> + >> + if (standby) >> + rdval &= ~0x01; >> + else >> + rdval |= 0x01; >> + >> + return ov5647_write(sd, 0x0100, rdval); >> +} >> + >> +static int __sensor_init(struct v4l2_subdev *sd) >> +{ >> + int ret; >> + u8 resetval; >> + u8 rdval; > > It could be possible to put declarations of 'resetval' and 'rdval' on the same line. > Sure. >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + dev_dbg(&client->dev, "sensor init\n"); >> + >> + ret = ov5647_read(sd, 0x0100, &rdval); >> + if (ret < 0) >> + return ret; >> + >> + ret = ov5647_write_array(sd, ov5647_640x480, >> + ARRAY_SIZE(ov5647_640x480)); >> + if (ret < 0) { >> + dev_err(&client->dev, "write sensor default regs error\n"); >> + return ret; >> + } >> + >> + ret = ov5647_set_virtual_channel(sd, 0); >> + if (ret < 0) >> + return ret; >> + >> + ret = ov5647_read(sd, 0x0100, &resetval); >> + if (ret < 0) >> + return ret; >> + >> + if (!(resetval & 0x01)) { >> + dev_err(&client->dev, "Device was in SW standby"); >> + ret = ov5647_write(sd, 0x0100, 0x01); >> + if (ret < 0) >> + return ret; >> + } >> + >> + return ov5647_write(sd, 0x4800, 0x04); >> +} >> + >> +static int sensor_power(struct v4l2_subdev *sd, int on) >> +{ >> + int ret; >> + struct ov5647 *ov5647 = to_state(sd); >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = 0; >> + mutex_lock(&ov5647->lock); >> + >> + if (on && !ov5647->power_count) { >> + dev_dbg(&client->dev, "OV5647 power on\n"); >> + >> + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); > > Now clk_set_rate() is redundant, please remove it. > > If once it is needed again, please move it to the .probe function, so > it is called only once in the runtime. > Ok. I'll remove it for now. >> + >> + ret = clk_prepare_enable(ov5647->xclk); > > I wonder would it be possible to unload the driver or to unbind the device > and leave the clock unintentionally enabled? If yes, then this is a bug. > You're saying that if the driver was unloaded and the clock was left enabled when the driver was loaded again this line would cause an error? Should I disable the clock when the driver is removed? >> + if (ret < 0) { >> + dev_err(&client->dev, "clk prepare enable failed\n"); >> + goto out; >> + } >> + >> + ret = ov5647_write_array(sd, sensor_oe_enable_regs, >> + ARRAY_SIZE(sensor_oe_enable_regs)); >> + if (ret < 0) { >> + clk_disable_unprepare(ov5647->xclk); >> + dev_err(&client->dev, >> + "write sensor_oe_enable_regs error\n"); >> + goto out; >> + } >> + >> + ret = __sensor_init(sd); >> + if (ret < 0) { >> + clk_disable_unprepare(ov5647->xclk); >> + dev_err(&client->dev, >> + "Camera not available, check Power\n"); >> + goto out; >> + } >> + } else if (!on && ov5647->power_count == 1) { >> + dev_dbg(&client->dev, "OV5647 power off\n"); >> + >> + dev_dbg(&client->dev, "disable oe\n"); > > One of two dev_dbg()'s above is apparently redundant. > I'll remove one. >> + ret = ov5647_write_array(sd, sensor_oe_disable_regs, >> + ARRAY_SIZE(sensor_oe_disable_regs)); >> + >> + if (ret < 0) >> + dev_dbg(&client->dev, "disable oe failed\n"); >> + >> + ret = set_sw_standby(sd, true); >> + >> + if (ret < 0) >> + dev_dbg(&client->dev, "soft stby failed\n"); >> + >> + clk_disable_unprepare(ov5647->xclk); >> + } >> + >> + /* Update the power count. */ >> + ov5647->power_count += on ? 1 : -1; >> + WARN_ON(ov5647->power_count < 0); >> + >> +out: >> + mutex_unlock(&ov5647->lock); >> + >> + return ret; >> +} >> + > > [snip] > >> + >> +static int ov5647_probe(struct i2c_client *client, >> + const struct i2c_device_id *id) >> +{ >> + struct device *dev = &client->dev; >> + struct ov5647 *sensor; >> + int ret; >> + struct v4l2_subdev *sd; >> + >> + sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL); >> + if (sensor == NULL) > > if (!sensor) is a bit shorter. > I'll change it. >> + return -ENOMEM; >> + >> + /* get system clock (xclk) */ >> + sensor->xclk = devm_clk_get(dev, "xclk"); >> + if (IS_ERR(sensor->xclk)) { >> + dev_err(dev, "could not get xclk"); >> + return PTR_ERR(sensor->xclk); >> + } >> + >> + sensor->xclk_freq = clk_get_rate(sensor->xclk); >> + if (sensor->xclk_freq != 25000000) { > > A comment in "struct ov5647" declaration says about 30MHz, which one is correct? > 25 MHz is the correct one. >> + dev_err(dev, "Unsupported clock frequency: %u\n", >> + sensor->xclk_freq); >> + return -EINVAL; >> + } >> + >> + mutex_init(&sensor->lock); >> + >> + sd = &sensor->sd; >> + v4l2_i2c_subdev_init(sd, client, &subdev_ops); >> + sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; >> + >> + sensor->pad.flags = MEDIA_PAD_FL_SOURCE; >> + sd->entity.function = MEDIA_ENT_F_CAM_SENSOR; >> + ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad); >> + if (ret < 0) >> + goto mutex_remove; >> + >> + ret = ov5647_detect(sd); >> + if (ret < 0) >> + goto error; >> + >> + ret = v4l2_async_register_subdev(sd); >> + if (ret < 0) >> + goto error; >> + >> + dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n"); >> + return 0; >> +error: >> + media_entity_cleanup(&sd->entity); >> +mutex_remove: >> + mutex_destroy(&sensor->lock); >> + return ret; >> +} >> + > > [snip] > > The driver looks good in general IMO. > > -- > With best wishes, > Vladimir > -- Best Regards Ramiro Oliveira Ramiro.Oliveira@synopsys.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-21 16:42 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-21 16:42 UTC (permalink / raw) To: Vladimir Zapolskiy, Ramiro Oliveira, linux-kernel, linux-media, devicetree Cc: CARLOS.PALMINHA, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Vladimir, Thank you for your feedback On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote: > Hi Ramiro, > > please find some review comments below. > > On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: >> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 >> and RAW 10 output formats, and MIPI CSI-2 interface. >> >> The driver adds support for 640x480 RAW 8. >> >> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> >> --- > > [snip] > >> + >> +struct ov5647 { >> + struct v4l2_subdev sd; >> + struct media_pad pad; >> + struct mutex lock; >> + struct v4l2_mbus_framefmt format; >> + unsigned int width; >> + unsigned int height; >> + int power_count; >> + struct clk *xclk; >> + /* External clock frequency currently supported is 30MHz */ >> + u32 xclk_freq; > > See a comment about 25MHz vs 30MHz below. > > Also I assume you can remove 'xclk_freq' from the struct fields, > it can be replaced by a local variable. > I'll do that. >> +}; > > [snip] > >> + >> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) >> +{ >> + int ret; >> + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = i2c_master_send(client, data_w, 2); >> + if (ret < 0) { >> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", > > s/i2c read error/i2c write error/ > I'm not sure I understand what you mean. >> + __func__, reg); >> + return ret; >> + } >> + >> + ret = i2c_master_recv(client, val, 1); >> + if (ret < 0) >> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >> + __func__, reg); >> + >> + return ret; >> + > > Please remove the empty line above. > Ok. >> +} >> + >> +static int ov5647_write_array(struct v4l2_subdev *sd, >> + struct regval_list *regs, int array_size) >> +{ >> + int i = 0, ret; > > Assignment of 'i' on declaration is not needed, please remove. > Ok. >> + >> + for (i = 0; i < array_size; i++) { >> + ret = ov5647_write(sd, regs[i].addr, regs[i].data); >> + if (ret < 0) >> + return ret; >> + } >> + >> + return 0; >> +} >> + >> +static int ov5647_set_virtual_channel(struct v4l2_subdev *sd, int channel) >> +{ >> + u8 channel_id; >> + int ret; >> + >> + ret = ov5647_read(sd, 0x4814, &channel_id); >> + if (ret < 0) >> + return ret; >> + >> + channel_id &= ~(3 << 6); >> + return ov5647_write(sd, 0x4814, channel_id | (channel << 6)); >> +} >> + >> +static int ov5647_stream_on(struct v4l2_subdev *sd) >> +{ >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ov5647_write(sd, 0x4202, 0x00); > > Should you add a check of the returned value? > I'll add it. >> + >> + dev_dbg(&client->dev, "Stream on"); > > I would suggest to remove dev_dbg(), because ftrace will report to a user, > when this function is called. > > Also dev_dbg() in the middle of two I2C transfers in a row looks as being > placed improperly. > I'll remove it. >> + >> + return ov5647_write(sd, 0x300D, 0x00); >> +} >> + >> +static int ov5647_stream_off(struct v4l2_subdev *sd) >> +{ >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ov5647_write(sd, 0x4202, 0x0f); > > Should you add a check of the returned value? > I'll add it. >> + >> + dev_dbg(&client->dev, "Stream off"); > > I would suggest to remove dev_dbg(), because ftrace will report to a user, > when this function is called. > > Also dev_dbg() in the middle of two I2C transfers in a row looks as being > placed improperly. > I'll remove it. >> + >> + return ov5647_write(sd, 0x300D, 0x01); >> +} >> + >> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby) >> +{ >> + int ret; >> + u8 rdval; >> + >> + ret = ov5647_read(sd, 0x0100, &rdval); >> + if (ret < 0) >> + return ret; >> + >> + if (standby) >> + rdval &= ~0x01; >> + else >> + rdval |= 0x01; >> + >> + return ov5647_write(sd, 0x0100, rdval); >> +} >> + >> +static int __sensor_init(struct v4l2_subdev *sd) >> +{ >> + int ret; >> + u8 resetval; >> + u8 rdval; > > It could be possible to put declarations of 'resetval' and 'rdval' on the same line. > Sure. >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + dev_dbg(&client->dev, "sensor init\n"); >> + >> + ret = ov5647_read(sd, 0x0100, &rdval); >> + if (ret < 0) >> + return ret; >> + >> + ret = ov5647_write_array(sd, ov5647_640x480, >> + ARRAY_SIZE(ov5647_640x480)); >> + if (ret < 0) { >> + dev_err(&client->dev, "write sensor default regs error\n"); >> + return ret; >> + } >> + >> + ret = ov5647_set_virtual_channel(sd, 0); >> + if (ret < 0) >> + return ret; >> + >> + ret = ov5647_read(sd, 0x0100, &resetval); >> + if (ret < 0) >> + return ret; >> + >> + if (!(resetval & 0x01)) { >> + dev_err(&client->dev, "Device was in SW standby"); >> + ret = ov5647_write(sd, 0x0100, 0x01); >> + if (ret < 0) >> + return ret; >> + } >> + >> + return ov5647_write(sd, 0x4800, 0x04); >> +} >> + >> +static int sensor_power(struct v4l2_subdev *sd, int on) >> +{ >> + int ret; >> + struct ov5647 *ov5647 = to_state(sd); >> + struct i2c_client *client = v4l2_get_subdevdata(sd); >> + >> + ret = 0; >> + mutex_lock(&ov5647->lock); >> + >> + if (on && !ov5647->power_count) { >> + dev_dbg(&client->dev, "OV5647 power on\n"); >> + >> + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); > > Now clk_set_rate() is redundant, please remove it. > > If once it is needed again, please move it to the .probe function, so > it is called only once in the runtime. > Ok. I'll remove it for now. >> + >> + ret = clk_prepare_enable(ov5647->xclk); > > I wonder would it be possible to unload the driver or to unbind the device > and leave the clock unintentionally enabled? If yes, then this is a bug. > You're saying that if the driver was unloaded and the clock was left enabled when the driver was loaded again this line would cause an error? Should I disable the clock when the driver is removed? >> + if (ret < 0) { >> + dev_err(&client->dev, "clk prepare enable failed\n"); >> + goto out; >> + } >> + >> + ret = ov5647_write_array(sd, sensor_oe_enable_regs, >> + ARRAY_SIZE(sensor_oe_enable_regs)); >> + if (ret < 0) { >> + clk_disable_unprepare(ov5647->xclk); >> + dev_err(&client->dev, >> + "write sensor_oe_enable_regs error\n"); >> + goto out; >> + } >> + >> + ret = __sensor_init(sd); >> + if (ret < 0) { >> + clk_disable_unprepare(ov5647->xclk); >> + dev_err(&client->dev, >> + "Camera not available, check Power\n"); >> + goto out; >> + } >> + } else if (!on && ov5647->power_count == 1) { >> + dev_dbg(&client->dev, "OV5647 power off\n"); >> + >> + dev_dbg(&client->dev, "disable oe\n"); > > One of two dev_dbg()'s above is apparently redundant. > I'll remove one. >> + ret = ov5647_write_array(sd, sensor_oe_disable_regs, >> + ARRAY_SIZE(sensor_oe_disable_regs)); >> + >> + if (ret < 0) >> + dev_dbg(&client->dev, "disable oe failed\n"); >> + >> + ret = set_sw_standby(sd, true); >> + >> + if (ret < 0) >> + dev_dbg(&client->dev, "soft stby failed\n"); >> + >> + clk_disable_unprepare(ov5647->xclk); >> + } >> + >> + /* Update the power count. */ >> + ov5647->power_count += on ? 1 : -1; >> + WARN_ON(ov5647->power_count < 0); >> + >> +out: >> + mutex_unlock(&ov5647->lock); >> + >> + return ret; >> +} >> + > > [snip] > >> + >> +static int ov5647_probe(struct i2c_client *client, >> + const struct i2c_device_id *id) >> +{ >> + struct device *dev = &client->dev; >> + struct ov5647 *sensor; >> + int ret; >> + struct v4l2_subdev *sd; >> + >> + sensor = devm_kzalloc(dev, sizeof(*sensor), GFP_KERNEL); >> + if (sensor == NULL) > > if (!sensor) is a bit shorter. > I'll change it. >> + return -ENOMEM; >> + >> + /* get system clock (xclk) */ >> + sensor->xclk = devm_clk_get(dev, "xclk"); >> + if (IS_ERR(sensor->xclk)) { >> + dev_err(dev, "could not get xclk"); >> + return PTR_ERR(sensor->xclk); >> + } >> + >> + sensor->xclk_freq = clk_get_rate(sensor->xclk); >> + if (sensor->xclk_freq != 25000000) { > > A comment in "struct ov5647" declaration says about 30MHz, which one is correct? > 25 MHz is the correct one. >> + dev_err(dev, "Unsupported clock frequency: %u\n", >> + sensor->xclk_freq); >> + return -EINVAL; >> + } >> + >> + mutex_init(&sensor->lock); >> + >> + sd = &sensor->sd; >> + v4l2_i2c_subdev_init(sd, client, &subdev_ops); >> + sensor->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; >> + >> + sensor->pad.flags = MEDIA_PAD_FL_SOURCE; >> + sd->entity.function = MEDIA_ENT_F_CAM_SENSOR; >> + ret = media_entity_pads_init(&sd->entity, 1, &sensor->pad); >> + if (ret < 0) >> + goto mutex_remove; >> + >> + ret = ov5647_detect(sd); >> + if (ret < 0) >> + goto error; >> + >> + ret = v4l2_async_register_subdev(sd); >> + if (ret < 0) >> + goto error; >> + >> + dev_dbg(&client->dev, "OmniVision OV5647 camera driver probed\n"); >> + return 0; >> +error: >> + media_entity_cleanup(&sd->entity); >> +mutex_remove: >> + mutex_destroy(&sensor->lock); >> + return ret; >> +} >> + > > [snip] > > The driver looks good in general IMO. > > -- > With best wishes, > Vladimir > -- Best Regards Ramiro Oliveira Ramiro.Oliveira@synopsys.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-21 20:36 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-21 20:36 UTC (permalink / raw) To: Ramiro Oliveira, linux-kernel, linux-media, devicetree Cc: CARLOS.PALMINHA, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, On 02/21/2017 06:42 PM, Ramiro Oliveira wrote: > Hi Vladimir, > > Thank you for your feedback > > On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote: >> Hi Ramiro, >> >> please find some review comments below. >> >> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: >>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 >>> and RAW 10 output formats, and MIPI CSI-2 interface. >>> >>> The driver adds support for 640x480 RAW 8. >>> >>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> >>> --- >> >> [snip] >> >>> + >>> +struct ov5647 { >>> + struct v4l2_subdev sd; >>> + struct media_pad pad; >>> + struct mutex lock; >>> + struct v4l2_mbus_framefmt format; >>> + unsigned int width; >>> + unsigned int height; >>> + int power_count; >>> + struct clk *xclk; >>> + /* External clock frequency currently supported is 30MHz */ >>> + u32 xclk_freq; >> >> See a comment about 25MHz vs 30MHz below. >> >> Also I assume you can remove 'xclk_freq' from the struct fields, >> it can be replaced by a local variable. >> > > I'll do that. > >>> +}; >> >> [snip] >> >>> + >>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) >>> +{ >>> + int ret; >>> + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; >>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>> + >>> + ret = i2c_master_send(client, data_w, 2); >>> + if (ret < 0) { >>> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >> >> s/i2c read error/i2c write error/ >> > > I'm not sure I understand what you mean. That's a sed expression for string substitution. Here you do i2c_master_send() but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix. >>> + __func__, reg); >>> + return ret; >>> + } >>> + [snip] >>> + >>> +static int sensor_power(struct v4l2_subdev *sd, int on) On the caller's side (functions ov5647_open() and ov5647_close()) the second argument of the function is of 'bool' type, however .s_power callback from struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as 'int'. It's just a nitpicking, please feel free to ignore the comment above or please consider to change the arguments on callers' side to integers. Also you may consider to add 'ov5647_' prefix to the function name to distinguish it from a potentially added in future sensor_power() function, the original name sounds too generic. >>> +{ >>> + int ret; >>> + struct ov5647 *ov5647 = to_state(sd); >>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>> + >>> + ret = 0; >>> + mutex_lock(&ov5647->lock); >>> + >>> + if (on && !ov5647->power_count) { >>> + dev_dbg(&client->dev, "OV5647 power on\n"); >>> + >>> + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); >> >> Now clk_set_rate() is redundant, please remove it. >> >> If once it is needed again, please move it to the .probe function, so >> it is called only once in the runtime. >> > > Ok. I'll remove it for now. > >>> + >>> + ret = clk_prepare_enable(ov5647->xclk); >> >> I wonder would it be possible to unload the driver or to unbind the device >> and leave the clock unintentionally enabled? If yes, then this is a bug. >> > > You're saying that if the driver was unloaded and the clock was left enabled > when the driver was loaded again this line would cause an error? Not exactly, here I saw a potential resource leak, namely a potentially left prepared/enabled clock. > > Should I disable the clock when the driver is removed? > The driver (and framework) shall guarantee that when it is detached from device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device), all acquired resources are released. But in this particular case most probably I've been overly alert, I believe that V4L2 framework correcly handles device power states, so please ignore my comment. To add something valuable to the review, could you please confirm that ov5647_subdev_internal_ops data is in use by the driver? E.g. shouldn't it be registered by sd->internal_ops = &ov5647_subdev_internal_ops; before calling v4l2_async_register_subdev(sd) ? -- With best wishes, Vladimir ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-21 20:36 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-21 20:36 UTC (permalink / raw) To: Ramiro Oliveira, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Ramiro, On 02/21/2017 06:42 PM, Ramiro Oliveira wrote: > Hi Vladimir, > > Thank you for your feedback > > On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote: >> Hi Ramiro, >> >> please find some review comments below. >> >> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: >>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 >>> and RAW 10 output formats, and MIPI CSI-2 interface. >>> >>> The driver adds support for 640x480 RAW 8. >>> >>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> >>> --- >> >> [snip] >> >>> + >>> +struct ov5647 { >>> + struct v4l2_subdev sd; >>> + struct media_pad pad; >>> + struct mutex lock; >>> + struct v4l2_mbus_framefmt format; >>> + unsigned int width; >>> + unsigned int height; >>> + int power_count; >>> + struct clk *xclk; >>> + /* External clock frequency currently supported is 30MHz */ >>> + u32 xclk_freq; >> >> See a comment about 25MHz vs 30MHz below. >> >> Also I assume you can remove 'xclk_freq' from the struct fields, >> it can be replaced by a local variable. >> > > I'll do that. > >>> +}; >> >> [snip] >> >>> + >>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) >>> +{ >>> + int ret; >>> + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; >>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>> + >>> + ret = i2c_master_send(client, data_w, 2); >>> + if (ret < 0) { >>> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >> >> s/i2c read error/i2c write error/ >> > > I'm not sure I understand what you mean. That's a sed expression for string substitution. Here you do i2c_master_send() but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix. >>> + __func__, reg); >>> + return ret; >>> + } >>> + [snip] >>> + >>> +static int sensor_power(struct v4l2_subdev *sd, int on) On the caller's side (functions ov5647_open() and ov5647_close()) the second argument of the function is of 'bool' type, however .s_power callback from struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as 'int'. It's just a nitpicking, please feel free to ignore the comment above or please consider to change the arguments on callers' side to integers. Also you may consider to add 'ov5647_' prefix to the function name to distinguish it from a potentially added in future sensor_power() function, the original name sounds too generic. >>> +{ >>> + int ret; >>> + struct ov5647 *ov5647 = to_state(sd); >>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>> + >>> + ret = 0; >>> + mutex_lock(&ov5647->lock); >>> + >>> + if (on && !ov5647->power_count) { >>> + dev_dbg(&client->dev, "OV5647 power on\n"); >>> + >>> + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); >> >> Now clk_set_rate() is redundant, please remove it. >> >> If once it is needed again, please move it to the .probe function, so >> it is called only once in the runtime. >> > > Ok. I'll remove it for now. > >>> + >>> + ret = clk_prepare_enable(ov5647->xclk); >> >> I wonder would it be possible to unload the driver or to unbind the device >> and leave the clock unintentionally enabled? If yes, then this is a bug. >> > > You're saying that if the driver was unloaded and the clock was left enabled > when the driver was loaded again this line would cause an error? Not exactly, here I saw a potential resource leak, namely a potentially left prepared/enabled clock. > > Should I disable the clock when the driver is removed? > The driver (and framework) shall guarantee that when it is detached from device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device), all acquired resources are released. But in this particular case most probably I've been overly alert, I believe that V4L2 framework correcly handles device power states, so please ignore my comment. To add something valuable to the review, could you please confirm that ov5647_subdev_internal_ops data is in use by the driver? E.g. shouldn't it be registered by sd->internal_ops = &ov5647_subdev_internal_ops; before calling v4l2_async_register_subdev(sd) ? -- With best wishes, Vladimir -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-22 10:51 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-22 10:51 UTC (permalink / raw) To: Vladimir Zapolskiy, Ramiro Oliveira, linux-kernel, linux-media, devicetree Cc: CARLOS.PALMINHA, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Zakari, On 2/21/2017 8:36 PM, Vladimir Zapolskiy wrote: > Hi Ramiro, > > On 02/21/2017 06:42 PM, Ramiro Oliveira wrote: >> Hi Vladimir, >> >> Thank you for your feedback >> >> On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote: >>> Hi Ramiro, >>> >>> please find some review comments below. >>> >>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: >>>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 >>>> and RAW 10 output formats, and MIPI CSI-2 interface. >>>> >>>> The driver adds support for 640x480 RAW 8. >>>> >>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> >>>> --- >>> >>> [snip] >>> >>>> + >>>> +struct ov5647 { >>>> + struct v4l2_subdev sd; >>>> + struct media_pad pad; >>>> + struct mutex lock; >>>> + struct v4l2_mbus_framefmt format; >>>> + unsigned int width; >>>> + unsigned int height; >>>> + int power_count; >>>> + struct clk *xclk; >>>> + /* External clock frequency currently supported is 30MHz */ >>>> + u32 xclk_freq; >>> >>> See a comment about 25MHz vs 30MHz below. >>> >>> Also I assume you can remove 'xclk_freq' from the struct fields, >>> it can be replaced by a local variable. >>> >> >> I'll do that. >> >>>> +}; >>> >>> [snip] >>> >>>> + >>>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) >>>> +{ >>>> + int ret; >>>> + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; >>>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>>> + >>>> + ret = i2c_master_send(client, data_w, 2); >>>> + if (ret < 0) { >>>> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >>> >>> s/i2c read error/i2c write error/ >>> >> >> I'm not sure I understand what you mean. > > That's a sed expression for string substitution. Here you do i2c_master_send() > but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix. > Ohh... now I see. I'll change it. >>>> + __func__, reg); >>>> + return ret; >>>> + } >>>> + > > [snip] > >>>> + >>>> +static int sensor_power(struct v4l2_subdev *sd, int on) > > On the caller's side (functions ov5647_open() and ov5647_close()) the second > argument of the function is of 'bool' type, however .s_power callback from > struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as > 'int'. > > It's just a nitpicking, please feel free to ignore the comment above or > please consider to change the arguments on callers' side to integers. > > Also you may consider to add 'ov5647_' prefix to the function name to > distinguish it from a potentially added in future sensor_power() function, > the original name sounds too generic. > OK. I'll add the prefix and change the variable type from int to bool. >>>> +{ >>>> + int ret; >>>> + struct ov5647 *ov5647 = to_state(sd); >>>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>>> + >>>> + ret = 0; >>>> + mutex_lock(&ov5647->lock); >>>> + >>>> + if (on && !ov5647->power_count) { >>>> + dev_dbg(&client->dev, "OV5647 power on\n"); >>>> + >>>> + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); >>> >>> Now clk_set_rate() is redundant, please remove it. >>> >>> If once it is needed again, please move it to the .probe function, so >>> it is called only once in the runtime. >>> >> >> Ok. I'll remove it for now. >> >>>> + >>>> + ret = clk_prepare_enable(ov5647->xclk); >>> >>> I wonder would it be possible to unload the driver or to unbind the device >>> and leave the clock unintentionally enabled? If yes, then this is a bug. >>> >> >> You're saying that if the driver was unloaded and the clock was left enabled >> when the driver was loaded again this line would cause an error? > > Not exactly, here I saw a potential resource leak, namely a potentially left > prepared/enabled clock. > >> >> Should I disable the clock when the driver is removed? >> > > The driver (and framework) shall guarantee that when it is detached from > device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device), > all acquired resources are released. > > But in this particular case most probably I've been overly alert, I believe > that V4L2 framework correcly handles device power states, so please ignore my > comment. > > To add something valuable to the review, could you please confirm that > ov5647_subdev_internal_ops data is in use by the driver? > > E.g. shouldn't it be registered by > > sd->internal_ops = &ov5647_subdev_internal_ops; > > before calling v4l2_async_register_subdev(sd) ? > You're right, it's not being registered. I think I'll remove them since they aren't being used. > -- > With best wishes, > Vladimir > -- Best Regards Ramiro Oliveira Ramiro.Oliveira@synopsys.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-22 10:51 ` Ramiro Oliveira 0 siblings, 0 replies; 44+ messages in thread From: Ramiro Oliveira @ 2017-02-22 10:51 UTC (permalink / raw) To: Vladimir Zapolskiy, Ramiro Oliveira, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam Hi Zakari, On 2/21/2017 8:36 PM, Vladimir Zapolskiy wrote: > Hi Ramiro, > > On 02/21/2017 06:42 PM, Ramiro Oliveira wrote: >> Hi Vladimir, >> >> Thank you for your feedback >> >> On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote: >>> Hi Ramiro, >>> >>> please find some review comments below. >>> >>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: >>>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 >>>> and RAW 10 output formats, and MIPI CSI-2 interface. >>>> >>>> The driver adds support for 640x480 RAW 8. >>>> >>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> >>>> --- >>> >>> [snip] >>> >>>> + >>>> +struct ov5647 { >>>> + struct v4l2_subdev sd; >>>> + struct media_pad pad; >>>> + struct mutex lock; >>>> + struct v4l2_mbus_framefmt format; >>>> + unsigned int width; >>>> + unsigned int height; >>>> + int power_count; >>>> + struct clk *xclk; >>>> + /* External clock frequency currently supported is 30MHz */ >>>> + u32 xclk_freq; >>> >>> See a comment about 25MHz vs 30MHz below. >>> >>> Also I assume you can remove 'xclk_freq' from the struct fields, >>> it can be replaced by a local variable. >>> >> >> I'll do that. >> >>>> +}; >>> >>> [snip] >>> >>>> + >>>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) >>>> +{ >>>> + int ret; >>>> + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; >>>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>>> + >>>> + ret = i2c_master_send(client, data_w, 2); >>>> + if (ret < 0) { >>>> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >>> >>> s/i2c read error/i2c write error/ >>> >> >> I'm not sure I understand what you mean. > > That's a sed expression for string substitution. Here you do i2c_master_send() > but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix. > Ohh... now I see. I'll change it. >>>> + __func__, reg); >>>> + return ret; >>>> + } >>>> + > > [snip] > >>>> + >>>> +static int sensor_power(struct v4l2_subdev *sd, int on) > > On the caller's side (functions ov5647_open() and ov5647_close()) the second > argument of the function is of 'bool' type, however .s_power callback from > struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as > 'int'. > > It's just a nitpicking, please feel free to ignore the comment above or > please consider to change the arguments on callers' side to integers. > > Also you may consider to add 'ov5647_' prefix to the function name to > distinguish it from a potentially added in future sensor_power() function, > the original name sounds too generic. > OK. I'll add the prefix and change the variable type from int to bool. >>>> +{ >>>> + int ret; >>>> + struct ov5647 *ov5647 = to_state(sd); >>>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>>> + >>>> + ret = 0; >>>> + mutex_lock(&ov5647->lock); >>>> + >>>> + if (on && !ov5647->power_count) { >>>> + dev_dbg(&client->dev, "OV5647 power on\n"); >>>> + >>>> + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); >>> >>> Now clk_set_rate() is redundant, please remove it. >>> >>> If once it is needed again, please move it to the .probe function, so >>> it is called only once in the runtime. >>> >> >> Ok. I'll remove it for now. >> >>>> + >>>> + ret = clk_prepare_enable(ov5647->xclk); >>> >>> I wonder would it be possible to unload the driver or to unbind the device >>> and leave the clock unintentionally enabled? If yes, then this is a bug. >>> >> >> You're saying that if the driver was unloaded and the clock was left enabled >> when the driver was loaded again this line would cause an error? > > Not exactly, here I saw a potential resource leak, namely a potentially left > prepared/enabled clock. > >> >> Should I disable the clock when the driver is removed? >> > > The driver (and framework) shall guarantee that when it is detached from > device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device), > all acquired resources are released. > > But in this particular case most probably I've been overly alert, I believe > that V4L2 framework correcly handles device power states, so please ignore my > comment. > > To add something valuable to the review, could you please confirm that > ov5647_subdev_internal_ops data is in use by the driver? > > E.g. shouldn't it be registered by > > sd->internal_ops = &ov5647_subdev_internal_ops; > > before calling v4l2_async_register_subdev(sd) ? > You're right, it's not being registered. I think I'll remove them since they aren't being used. > -- > With best wishes, > Vladimir > -- Best Regards Ramiro Oliveira Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-22 11:43 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-22 11:43 UTC (permalink / raw) To: Ramiro Oliveira, linux-kernel, linux-media, devicetree Cc: CARLOS.PALMINHA, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam On 02/22/2017 12:51 PM, Ramiro Oliveira wrote: > Hi Zakari, > > On 2/21/2017 8:36 PM, Vladimir Zapolskiy wrote: >> Hi Ramiro, >> >> On 02/21/2017 06:42 PM, Ramiro Oliveira wrote: >>> Hi Vladimir, >>> >>> Thank you for your feedback >>> >>> On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote: >>>> Hi Ramiro, >>>> >>>> please find some review comments below. >>>> >>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: >>>>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 >>>>> and RAW 10 output formats, and MIPI CSI-2 interface. >>>>> >>>>> The driver adds support for 640x480 RAW 8. >>>>> >>>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com> >>>>> --- >>>> >>>> [snip] >>>> >>>>> + >>>>> +struct ov5647 { >>>>> + struct v4l2_subdev sd; >>>>> + struct media_pad pad; >>>>> + struct mutex lock; >>>>> + struct v4l2_mbus_framefmt format; >>>>> + unsigned int width; >>>>> + unsigned int height; >>>>> + int power_count; >>>>> + struct clk *xclk; >>>>> + /* External clock frequency currently supported is 30MHz */ >>>>> + u32 xclk_freq; >>>> >>>> See a comment about 25MHz vs 30MHz below. >>>> >>>> Also I assume you can remove 'xclk_freq' from the struct fields, >>>> it can be replaced by a local variable. >>>> >>> >>> I'll do that. >>> >>>>> +}; >>>> >>>> [snip] >>>> >>>>> + >>>>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) >>>>> +{ >>>>> + int ret; >>>>> + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; >>>>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>>>> + >>>>> + ret = i2c_master_send(client, data_w, 2); >>>>> + if (ret < 0) { >>>>> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >>>> >>>> s/i2c read error/i2c write error/ >>>> >>> >>> I'm not sure I understand what you mean. >> >> That's a sed expression for string substitution. Here you do i2c_master_send() >> but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix. >> > > Ohh... now I see. I'll change it. > >>>>> + __func__, reg); >>>>> + return ret; >>>>> + } >>>>> + >> >> [snip] >> >>>>> + >>>>> +static int sensor_power(struct v4l2_subdev *sd, int on) >> >> On the caller's side (functions ov5647_open() and ov5647_close()) the second >> argument of the function is of 'bool' type, however .s_power callback from >> struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as >> 'int'. >> >> It's just a nitpicking, please feel free to ignore the comment above or >> please consider to change the arguments on callers' side to integers. >> >> Also you may consider to add 'ov5647_' prefix to the function name to >> distinguish it from a potentially added in future sensor_power() function, >> the original name sounds too generic. >> > > OK. I'll add the prefix and change the variable type from int to bool. > Just to eliminate any potential misunderstanding, if you consider to reuse the current sensor_power() function, please change variables from bool to int on a caller's side, the signature of the function shall not be changed to match .s_power type. >>>>> +{ >>>>> + int ret; >>>>> + struct ov5647 *ov5647 = to_state(sd); >>>>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>>>> + >>>>> + ret = 0; >>>>> + mutex_lock(&ov5647->lock); >>>>> + >>>>> + if (on && !ov5647->power_count) { >>>>> + dev_dbg(&client->dev, "OV5647 power on\n"); >>>>> + >>>>> + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); >>>> >>>> Now clk_set_rate() is redundant, please remove it. >>>> >>>> If once it is needed again, please move it to the .probe function, so >>>> it is called only once in the runtime. >>>> >>> >>> Ok. I'll remove it for now. >>> >>>>> + >>>>> + ret = clk_prepare_enable(ov5647->xclk); >>>> >>>> I wonder would it be possible to unload the driver or to unbind the device >>>> and leave the clock unintentionally enabled? If yes, then this is a bug. >>>> >>> >>> You're saying that if the driver was unloaded and the clock was left enabled >>> when the driver was loaded again this line would cause an error? >> >> Not exactly, here I saw a potential resource leak, namely a potentially left >> prepared/enabled clock. >> >>> >>> Should I disable the clock when the driver is removed? >>> >> >> The driver (and framework) shall guarantee that when it is detached from >> device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device), >> all acquired resources are released. >> >> But in this particular case most probably I've been overly alert, I believe >> that V4L2 framework correcly handles device power states, so please ignore my >> comment. >> >> To add something valuable to the review, could you please confirm that >> ov5647_subdev_internal_ops data is in use by the driver? >> >> E.g. shouldn't it be registered by >> >> sd->internal_ops = &ov5647_subdev_internal_ops; >> >> before calling v4l2_async_register_subdev(sd) ? >> > > You're right, it's not being registered. I think I'll remove them since they > aren't being used. > -- With best wishes, Vladimir ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH v9 2/2] Add support for OV5647 sensor. @ 2017-02-22 11:43 ` Vladimir Zapolskiy 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Zapolskiy @ 2017-02-22 11:43 UTC (permalink / raw) To: Ramiro Oliveira, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, David S. Miller, Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck, Hans Verkuil, Ivaylo Dimitrov, Mark Rutland, Mauro Carvalho Chehab, Pali Rohár, Pavel Machek, Robert Jarzmik, Rob Herring, Sakari Ailus, Steve Longerbeam On 02/22/2017 12:51 PM, Ramiro Oliveira wrote: > Hi Zakari, > > On 2/21/2017 8:36 PM, Vladimir Zapolskiy wrote: >> Hi Ramiro, >> >> On 02/21/2017 06:42 PM, Ramiro Oliveira wrote: >>> Hi Vladimir, >>> >>> Thank you for your feedback >>> >>> On 2/21/2017 3:54 PM, Vladimir Zapolskiy wrote: >>>> Hi Ramiro, >>>> >>>> please find some review comments below. >>>> >>>> On 02/17/2017 03:14 PM, Ramiro Oliveira wrote: >>>>> The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 >>>>> and RAW 10 output formats, and MIPI CSI-2 interface. >>>>> >>>>> The driver adds support for 640x480 RAW 8. >>>>> >>>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> >>>>> --- >>>> >>>> [snip] >>>> >>>>> + >>>>> +struct ov5647 { >>>>> + struct v4l2_subdev sd; >>>>> + struct media_pad pad; >>>>> + struct mutex lock; >>>>> + struct v4l2_mbus_framefmt format; >>>>> + unsigned int width; >>>>> + unsigned int height; >>>>> + int power_count; >>>>> + struct clk *xclk; >>>>> + /* External clock frequency currently supported is 30MHz */ >>>>> + u32 xclk_freq; >>>> >>>> See a comment about 25MHz vs 30MHz below. >>>> >>>> Also I assume you can remove 'xclk_freq' from the struct fields, >>>> it can be replaced by a local variable. >>>> >>> >>> I'll do that. >>> >>>>> +}; >>>> >>>> [snip] >>>> >>>>> + >>>>> +static int ov5647_read(struct v4l2_subdev *sd, u16 reg, u8 *val) >>>>> +{ >>>>> + int ret; >>>>> + unsigned char data_w[2] = { reg >> 8, reg & 0xff }; >>>>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>>>> + >>>>> + ret = i2c_master_send(client, data_w, 2); >>>>> + if (ret < 0) { >>>>> + dev_dbg(&client->dev, "%s: i2c read error, reg: %x\n", >>>> >>>> s/i2c read error/i2c write error/ >>>> >>> >>> I'm not sure I understand what you mean. >> >> That's a sed expression for string substitution. Here you do i2c_master_send() >> but dev_dbg() comment says "i2c read error". It's a simple copy-paste typo to fix. >> > > Ohh... now I see. I'll change it. > >>>>> + __func__, reg); >>>>> + return ret; >>>>> + } >>>>> + >> >> [snip] >> >>>>> + >>>>> +static int sensor_power(struct v4l2_subdev *sd, int on) >> >> On the caller's side (functions ov5647_open() and ov5647_close()) the second >> argument of the function is of 'bool' type, however .s_power callback from >> struct v4l2_subdev_core_ops (see include/media/v4l2-subdev.h) defines it as >> 'int'. >> >> It's just a nitpicking, please feel free to ignore the comment above or >> please consider to change the arguments on callers' side to integers. >> >> Also you may consider to add 'ov5647_' prefix to the function name to >> distinguish it from a potentially added in future sensor_power() function, >> the original name sounds too generic. >> > > OK. I'll add the prefix and change the variable type from int to bool. > Just to eliminate any potential misunderstanding, if you consider to reuse the current sensor_power() function, please change variables from bool to int on a caller's side, the signature of the function shall not be changed to match .s_power type. >>>>> +{ >>>>> + int ret; >>>>> + struct ov5647 *ov5647 = to_state(sd); >>>>> + struct i2c_client *client = v4l2_get_subdevdata(sd); >>>>> + >>>>> + ret = 0; >>>>> + mutex_lock(&ov5647->lock); >>>>> + >>>>> + if (on && !ov5647->power_count) { >>>>> + dev_dbg(&client->dev, "OV5647 power on\n"); >>>>> + >>>>> + clk_set_rate(ov5647->xclk, ov5647->xclk_freq); >>>> >>>> Now clk_set_rate() is redundant, please remove it. >>>> >>>> If once it is needed again, please move it to the .probe function, so >>>> it is called only once in the runtime. >>>> >>> >>> Ok. I'll remove it for now. >>> >>>>> + >>>>> + ret = clk_prepare_enable(ov5647->xclk); >>>> >>>> I wonder would it be possible to unload the driver or to unbind the device >>>> and leave the clock unintentionally enabled? If yes, then this is a bug. >>>> >>> >>> You're saying that if the driver was unloaded and the clock was left enabled >>> when the driver was loaded again this line would cause an error? >> >> Not exactly, here I saw a potential resource leak, namely a potentially left >> prepared/enabled clock. >> >>> >>> Should I disable the clock when the driver is removed? >>> >> >> The driver (and framework) shall guarantee that when it is detached from >> device(s) (e.g. by unloading "ov5647" kernel module or unbinding ov5647 device), >> all acquired resources are released. >> >> But in this particular case most probably I've been overly alert, I believe >> that V4L2 framework correcly handles device power states, so please ignore my >> comment. >> >> To add something valuable to the review, could you please confirm that >> ov5647_subdev_internal_ops data is in use by the driver? >> >> E.g. shouldn't it be registered by >> >> sd->internal_ops = &ov5647_subdev_internal_ops; >> >> before calling v4l2_async_register_subdev(sd) ? >> > > You're right, it's not being registered. I think I'll remove them since they > aren't being used. > -- With best wishes, Vladimir -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2017-02-25 15:33 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-17 13:14 [PATCH v9 0/2] Add support for Omnivision OV5647 Ramiro Oliveira 2017-02-17 13:14 ` Ramiro Oliveira 2017-02-17 13:14 ` [PATCH v9 1/2] Add OV5647 device tree documentation Ramiro Oliveira 2017-02-21 11:57 ` Sakari Ailus 2017-02-21 11:57 ` Sakari Ailus 2017-02-21 14:30 ` Ramiro Oliveira 2017-02-21 14:40 ` Sakari Ailus 2017-02-21 14:40 ` Sakari Ailus 2017-02-21 15:58 ` Vladimir Zapolskiy 2017-02-21 15:58 ` Vladimir Zapolskiy 2017-02-21 20:13 ` Ramiro Oliveira 2017-02-21 20:13 ` Ramiro Oliveira 2017-02-21 20:48 ` Vladimir Zapolskiy 2017-02-21 20:48 ` Vladimir Zapolskiy 2017-02-21 21:48 ` Sakari Ailus 2017-02-21 21:48 ` Sakari Ailus 2017-02-21 22:37 ` Vladimir Zapolskiy 2017-02-21 22:37 ` Vladimir Zapolskiy 2017-02-22 10:57 ` Ramiro Oliveira 2017-02-22 10:57 ` Ramiro Oliveira 2017-02-22 11:39 ` Vladimir Zapolskiy 2017-02-22 11:39 ` Vladimir Zapolskiy 2017-02-22 14:39 ` Ramiro Oliveira 2017-02-22 14:39 ` Ramiro Oliveira 2017-02-25 14:50 ` Sakari Ailus 2017-02-25 14:50 ` Sakari Ailus 2017-02-25 14:55 ` Sakari Ailus 2017-02-25 14:55 ` Sakari Ailus 2017-02-17 13:14 ` [PATCH v9 2/2] Add support for OV5647 sensor Ramiro Oliveira 2017-02-21 12:09 ` Sakari Ailus 2017-02-21 12:09 ` Sakari Ailus 2017-02-21 14:49 ` Ramiro Oliveira 2017-02-21 14:49 ` Ramiro Oliveira 2017-02-21 14:58 ` Sakari Ailus 2017-02-21 15:54 ` Vladimir Zapolskiy 2017-02-21 15:54 ` Vladimir Zapolskiy 2017-02-21 16:42 ` Ramiro Oliveira 2017-02-21 16:42 ` Ramiro Oliveira 2017-02-21 20:36 ` Vladimir Zapolskiy 2017-02-21 20:36 ` Vladimir Zapolskiy 2017-02-22 10:51 ` Ramiro Oliveira 2017-02-22 10:51 ` Ramiro Oliveira 2017-02-22 11:43 ` Vladimir Zapolskiy 2017-02-22 11:43 ` Vladimir Zapolskiy
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.