All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	drinkcat@chromium.org, srv_heupstream@mediatek.com,
	shengnan.wang@mediatek.com, louis.kuo@mediatek.com,
	sj.huang@mediatek.com, robh+dt@kernel.org,
	linux-mediatek@lists.infradead.org, dongchun.zhu@mediatek.com,
	matthias.bgg@gmail.com, bingbu.cao@intel.com, mchehab@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver
Date: Wed, 21 Aug 2019 14:05:43 +0300	[thread overview]
Message-ID: <20190821110542.GD31967@paasikivi.fi.intel.com> (raw)
In-Reply-To: <20190821103038.GA148543@chromium.org>

Hi Tomasz,

On Wed, Aug 21, 2019 at 07:30:38PM +0900, Tomasz Figa wrote:
...
> > +
> > +/*
> > + * xvclk 24Mhz
> 
> This seems to assume 24MHz, but the driver allows a range in probe. Is that
> correct?

I think it'd be better to check for an exact frequency: this is board
specific and its exact value is known.

...

> > +static int __ov02a10_power_on(struct ov02a10 *ov02a10)
> > +{
> > +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> > +	struct device *dev = &client->dev;
> > +	int ret;
> > +
> > +	ret = clk_prepare_enable(ov02a10->xvclk);
> > +	if (ret < 0) {
> > +		dev_err(dev, "Failed to enable xvclk\n");
> > +		return ret;
> > +	}
> 
> Is it really correct to enable the clock before the regulators?
> 
> According to the datasheet, it should be:
>  - PD pin HIGH,
>  - nRST pin LOW,
>  - DVDDIO and AVDD28 power up and stabilize,
>  - clock enabled,
>  - min 5 ms delay,
>  - PD pin LOW,
>  - min 4 ms delay,
>  - nRST pin HIGH,
>  - min 5 ms delay,
>  - I2C interface ready.
> 
> > +
> > +	/* Note: set 0 is high, set 1 is low */
> 
> Why is that? If there is some inverter on the way that should be handled
> outside of this driver. (GPIO DT bindings have flags for this purpose.
> 
> If the pins are nRESET and nPOWERDOWN in the hardware datasheet, we should
> call them like this in the driver too (+/- the lowercase and underscore
> convention).
> 
> According to the datasheet, the reset pin is called RST and inverted, so we should
> call it n_rst, but the powerdown signal, called PD, is not inverted, so pd
> would be the right name.

For what it's worth sensors generally have xshutdown (or reset) pin that is
active high. Looking at the code, it is not the case here. It's a bit odd
since the usual arrangement saves power when the camera is not in use; it's
not a lot but still. Oh well.

...

> > +static struct i2c_driver ov02a10_i2c_driver = {
> > +	.driver = {
> > +		.name = "ov02a10",
> > +		.pm = &ov02a10_pm_ops,
> > +		.of_match_table = ov02a10_of_match,
> 
> Please use of_match_ptr() wrapper.

Not really needed; the driver does expect regulators, GPIOs etc., but by
leaving out of_match_ptr(), the driver will also probe on ACPI based
systems.

-- 
Regards,

Sakari Ailus
sakari.ailus@linux.intel.com

WARNING: multiple messages have this Message-ID (diff)
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: dongchun.zhu@mediatek.com, mchehab@kernel.org,
	robh+dt@kernel.org, mark.rutland@arm.com, drinkcat@chromium.org,
	matthias.bgg@gmail.com, bingbu.cao@intel.com,
	srv_heupstream@mediatek.com, linux-mediatek@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, sj.huang@mediatek.com,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	louis.kuo@mediatek.com, shengnan.wang@mediatek.com
Subject: Re: [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver
Date: Wed, 21 Aug 2019 14:05:43 +0300	[thread overview]
Message-ID: <20190821110542.GD31967@paasikivi.fi.intel.com> (raw)
In-Reply-To: <20190821103038.GA148543@chromium.org>

Hi Tomasz,

On Wed, Aug 21, 2019 at 07:30:38PM +0900, Tomasz Figa wrote:
...
> > +
> > +/*
> > + * xvclk 24Mhz
> 
> This seems to assume 24MHz, but the driver allows a range in probe. Is that
> correct?

I think it'd be better to check for an exact frequency: this is board
specific and its exact value is known.

...

> > +static int __ov02a10_power_on(struct ov02a10 *ov02a10)
> > +{
> > +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> > +	struct device *dev = &client->dev;
> > +	int ret;
> > +
> > +	ret = clk_prepare_enable(ov02a10->xvclk);
> > +	if (ret < 0) {
> > +		dev_err(dev, "Failed to enable xvclk\n");
> > +		return ret;
> > +	}
> 
> Is it really correct to enable the clock before the regulators?
> 
> According to the datasheet, it should be:
>  - PD pin HIGH,
>  - nRST pin LOW,
>  - DVDDIO and AVDD28 power up and stabilize,
>  - clock enabled,
>  - min 5 ms delay,
>  - PD pin LOW,
>  - min 4 ms delay,
>  - nRST pin HIGH,
>  - min 5 ms delay,
>  - I2C interface ready.
> 
> > +
> > +	/* Note: set 0 is high, set 1 is low */
> 
> Why is that? If there is some inverter on the way that should be handled
> outside of this driver. (GPIO DT bindings have flags for this purpose.
> 
> If the pins are nRESET and nPOWERDOWN in the hardware datasheet, we should
> call them like this in the driver too (+/- the lowercase and underscore
> convention).
> 
> According to the datasheet, the reset pin is called RST and inverted, so we should
> call it n_rst, but the powerdown signal, called PD, is not inverted, so pd
> would be the right name.

For what it's worth sensors generally have xshutdown (or reset) pin that is
active high. Looking at the code, it is not the case here. It's a bit odd
since the usual arrangement saves power when the camera is not in use; it's
not a lot but still. Oh well.

...

> > +static struct i2c_driver ov02a10_i2c_driver = {
> > +	.driver = {
> > +		.name = "ov02a10",
> > +		.pm = &ov02a10_pm_ops,
> > +		.of_match_table = ov02a10_of_match,
> 
> Please use of_match_ptr() wrapper.

Not really needed; the driver does expect regulators, GPIOs etc., but by
leaving out of_match_ptr(), the driver will also probe on ACPI based
systems.

-- 
Regards,

Sakari Ailus
sakari.ailus@linux.intel.com

WARNING: multiple messages have this Message-ID (diff)
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	drinkcat@chromium.org, srv_heupstream@mediatek.com,
	shengnan.wang@mediatek.com, louis.kuo@mediatek.com,
	sj.huang@mediatek.com, robh+dt@kernel.org,
	linux-mediatek@lists.infradead.org, dongchun.zhu@mediatek.com,
	matthias.bgg@gmail.com, bingbu.cao@intel.com, mchehab@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver
Date: Wed, 21 Aug 2019 14:05:43 +0300	[thread overview]
Message-ID: <20190821110542.GD31967@paasikivi.fi.intel.com> (raw)
In-Reply-To: <20190821103038.GA148543@chromium.org>

Hi Tomasz,

On Wed, Aug 21, 2019 at 07:30:38PM +0900, Tomasz Figa wrote:
...
> > +
> > +/*
> > + * xvclk 24Mhz
> 
> This seems to assume 24MHz, but the driver allows a range in probe. Is that
> correct?

I think it'd be better to check for an exact frequency: this is board
specific and its exact value is known.

...

> > +static int __ov02a10_power_on(struct ov02a10 *ov02a10)
> > +{
> > +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> > +	struct device *dev = &client->dev;
> > +	int ret;
> > +
> > +	ret = clk_prepare_enable(ov02a10->xvclk);
> > +	if (ret < 0) {
> > +		dev_err(dev, "Failed to enable xvclk\n");
> > +		return ret;
> > +	}
> 
> Is it really correct to enable the clock before the regulators?
> 
> According to the datasheet, it should be:
>  - PD pin HIGH,
>  - nRST pin LOW,
>  - DVDDIO and AVDD28 power up and stabilize,
>  - clock enabled,
>  - min 5 ms delay,
>  - PD pin LOW,
>  - min 4 ms delay,
>  - nRST pin HIGH,
>  - min 5 ms delay,
>  - I2C interface ready.
> 
> > +
> > +	/* Note: set 0 is high, set 1 is low */
> 
> Why is that? If there is some inverter on the way that should be handled
> outside of this driver. (GPIO DT bindings have flags for this purpose.
> 
> If the pins are nRESET and nPOWERDOWN in the hardware datasheet, we should
> call them like this in the driver too (+/- the lowercase and underscore
> convention).
> 
> According to the datasheet, the reset pin is called RST and inverted, so we should
> call it n_rst, but the powerdown signal, called PD, is not inverted, so pd
> would be the right name.

For what it's worth sensors generally have xshutdown (or reset) pin that is
active high. Looking at the code, it is not the case here. It's a bit odd
since the usual arrangement saves power when the camera is not in use; it's
not a lot but still. Oh well.

...

> > +static struct i2c_driver ov02a10_i2c_driver = {
> > +	.driver = {
> > +		.name = "ov02a10",
> > +		.pm = &ov02a10_pm_ops,
> > +		.of_match_table = ov02a10_of_match,
> 
> Please use of_match_ptr() wrapper.

Not really needed; the driver does expect regulators, GPIOs etc., but by
leaving out of_match_ptr(), the driver will also probe on ACPI based
systems.

-- 
Regards,

Sakari Ailus
sakari.ailus@linux.intel.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-08-21 11:05 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-19  3:43 [V3, 0/2] media: Add support for OV02A10 sensor dongchun.zhu
2019-08-19  3:43 ` dongchun.zhu
2019-08-19  3:43 ` dongchun.zhu
2019-08-19  3:43 ` [V3, 1/2] media: dt-bindings: media: i2c: Add bindings for OV02A10 dongchun.zhu
2019-08-19  3:43   ` dongchun.zhu
2019-08-19  3:43   ` dongchun.zhu
     [not found]   ` <20190819034331.13098-2-dongchun.zhu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2019-08-27 16:48     ` Rob Herring
2019-08-27 16:48       ` Rob Herring
2019-08-27 16:48       ` Rob Herring
2019-08-19  3:43 ` [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver dongchun.zhu
2019-08-19  3:43   ` dongchun.zhu
2019-08-19  3:43   ` dongchun.zhu
2019-08-19  8:30   ` Sakari Ailus
2019-08-19  8:30     ` Sakari Ailus
2019-08-19  8:30     ` Sakari Ailus
2019-09-05  9:41     ` Dongchun Zhu
2019-09-05  9:41       ` Dongchun Zhu
2019-09-05  9:41       ` Dongchun Zhu
2019-09-05 10:45       ` Sakari Ailus
2019-09-05 10:45         ` Sakari Ailus
2019-09-05 10:45         ` Sakari Ailus
2019-09-05 10:53         ` Tomasz Figa
2019-09-05 10:53           ` Tomasz Figa
2019-09-05 10:53           ` Tomasz Figa
2019-09-05 16:05           ` Sakari Ailus
2019-09-05 16:05             ` Sakari Ailus
2019-09-05 16:05             ` Sakari Ailus
2019-09-05 22:58             ` Nicolas Boichat
2019-09-05 22:58               ` Nicolas Boichat
2019-09-05 22:58               ` Nicolas Boichat
2019-09-06  1:33               ` Dongchun Zhu
2019-09-06  1:33                 ` Dongchun Zhu
2019-09-06  1:33                 ` Dongchun Zhu
2019-09-07  3:51                 ` Tomasz Figa
2019-09-07  3:51                   ` Tomasz Figa
2019-09-07  3:51                   ` Tomasz Figa
2019-08-21 10:30   ` Tomasz Figa
2019-08-21 10:30     ` Tomasz Figa
2019-08-21 10:30     ` Tomasz Figa
2019-08-21 11:05     ` Sakari Ailus [this message]
2019-08-21 11:05       ` Sakari Ailus
2019-08-21 11:05       ` Sakari Ailus
     [not found]       ` <20190821110542.GD31967-z7MJbOB4PBP+e+fPlCVrcFDQ4js95KgL@public.gmane.org>
2019-08-26  6:54         ` Tomasz Figa
2019-08-26  6:54           ` Tomasz Figa
2019-08-26  6:54           ` Tomasz Figa
     [not found]     ` <20190821103038.GA148543-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2019-09-05 15:54       ` Dongchun Zhu
2019-09-05 15:54         ` Dongchun Zhu
2019-09-05 15:54         ` Dongchun Zhu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190821110542.GD31967@paasikivi.fi.intel.com \
    --to=sakari.ailus@linux.intel.com \
    --cc=bingbu.cao@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dongchun.zhu@mediatek.com \
    --cc=drinkcat@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=louis.kuo@mediatek.com \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=shengnan.wang@mediatek.com \
    --cc=sj.huang@mediatek.com \
    --cc=srv_heupstream@mediatek.com \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is 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.