From: Kieran Bingham <kieran.bingham@ideasonboard.com>
To: Biju Das <biju.das.jz@bp.renesas.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Wolfram Sang <wsa@kernel.org>,
biju.das.au <biju.das.au@gmail.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org <linux-media@vger.kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>,
linux-renesas-soc@vger.kernel.org
<linux-renesas-soc@vger.kernel.org>
Subject: RE: [PATCH 1/2] media: i2c: ov5645: Move the register 0x3008 from ov5645_global_init_setting
Date: Wed, 14 Feb 2024 23:34:12 +0000 [thread overview]
Message-ID: <170795365234.2765369.4101452918614439944@ping.linuxembedded.co.uk> (raw)
In-Reply-To: <TYCPR01MB11269D1C9578F27DE69E732B6864E2@TYCPR01MB11269.jpnprd01.prod.outlook.com>
Quoting Biju Das (2024-02-14 20:57:36)
> Hi Sakari,
>
> > -----Original Message-----
> > From: Biju Das
> > Sent: Wednesday, February 14, 2024 8:55 PM
> > Subject: RE: [PATCH 1/2] media: i2c: ov5645: Move the register 0x3008 from
> > ov5645_global_init_setting
> >
> > Hi Sakari,
> >
> > Thanks for the feedback.
> >
> > > -----Original Message-----
> > > From: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > Sent: Wednesday, February 14, 2024 8:49 PM
> > > To: Biju Das <biju.das.jz@bp.renesas.com>
> > > Subject: Re: [PATCH 1/2] media: i2c: ov5645: Move the register 0x3008
> > > from ov5645_global_init_setting
> > >
> > > Hi Biju,
> > >
> > > On Wed, Feb 14, 2024 at 08:25:16PM +0000, Biju Das wrote:
> > > > Hi Wolfram,
> > > >
> > > > Thanks for the feedback.
> > > >
> > > > > -----Original Message-----
> > > > > From: Wolfram Sang <wsa@kernel.org>
> > > > > Sent: Wednesday, February 14, 2024 8:31 AM
> > > > > Subject: Re: [PATCH 1/2] media: i2c: ov5645: Move the register
> > > > > 0x3008 from ov5645_global_init_setting
> > > > >
> > > > > Hi Biju,
> > > > >
> > > > > > I think it is different here. That 1 msec is delay associated
> > > > > > with applying hardware power see [1]
> > > > >
> > > > > Okay, ack.
> > > > >
> > > > > > I will restore it.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > I had meanwhile another thought. What if we kind of merge the two
> > > > > patches, so the outcome is basically this:
> > > > >
> > > > > In ov5645_set_register_array:
> > > > >
> > > > > If (settings->reg == 0x3008 && settings->val == 0x82)
> > > > > usleep_range(1000, 2000)
> > > > >
> > > > > ?
> > > > >
> > > > > Then, we don't need to split the array and we are also future
> > > > > proof if we ever need to set the reset bit again somewhere else.
> > > > >
> > > > > Bonus points for replacing 0x82 with a define :)
Pulling up the datasheet OV5645-A66A v1.1 from the web:
(a little google-fu++ got there, let me know if you need hints if you
want to do a full clean up)
2.8 reset
The OV5645 sensor includes a RESETB pin that forces a complete hardware
reset when it is pulled low (GND). The OV5645 clears all registers and
resets them to their default values when a hardware reset occurs. A
reset can also be initiated through the SCCB interface by setting
register 0x3008[7] to high. Manually applying a hard reset upon power
up is required even though on-chip reset is included. The hard reset is
active low with an asynchronized design. The reset pulse width should be
greater than or equal to 1 ms.
2.9 hardware and software standby
Two suspend modes are available for the OV5645:
• hardware standby
• SCCB software standby
To initiate hardware standby mode, the PWDNB pin must be tied to low
(while in MIPI mode, set register 0x300E[4:3] to 2’b11 before the PWDNB
pin is set to low). When this occurs, the OV5645 internal device clock
is halted and all internal counters are reset and registers are
maintained. Executing a software standby through the SCCB interface
suspends internal circuit activity but does not halt the device clock.
All register content is maintained in standby mode.
Address: 0x3008
RegName: SYSTEM_CTROL0
Default: 0x02
R/W: RW
Description: System Control
Bit[7]: Software reset
Bit[6]: Software power down
Then later in the datasheet it also describes:
System Control
Bit[7]: Software reset
Bit[6]: Software power down
Bit[5]: Debug mode
Bit[4]: SRB clock sync enable
Bit[3]: Isolation suspend select
Bit[2]: MIPI reset mask
Bit[1]: MIPI suspend mask
Bit[0]: MIPI reset select
> > > > >
> > > > > What do you think?
> > > >
> > > >
> > > > OK, this will do check for all other registers.
> > > >
> > > > But from your power down clue and checking ov5640.c Looks like there
> > > > are 2 registers changes values after writing.
> > > >
> > > > [1] 0x3008, 0x82-->0x80
> > > > [2] 0x0601, 0x02-->0x00
> > > >
> > > > I think [1] is soft reset based on ov5640. Since there is a gpio
> > > > based hardware reset available, we can safely remove soft reset[1]
> > > > and like ov5640.c, if there is no gpio for reset, then do the soft
> > reset[1].
> > >
> > > I guess that would work. My understanding is that hard reset control
> > > is mandatory for the device, so there really should be no need for
> > > soft reset in the driver.
> >
> > OK.
> >
> > >
> > > >
> > > >
> > > > Then add 1msec delay for power down/up(0x3008: 0x42,0x02) and 0x0601
> > > > registers.
> > > >
> > > > With this looks like the Camera works ok @400kHz.
> > > >
> > > > The plans is to add a u8 variable for delay and enable delays for
> > > > the above registers and add a check like below
> > > >
> > > > static int ov5645_set_register_array(struct ov5645 *ov5645,
> > > > const struct reg_value *settings,
> > > > unsigned int num_settings)
> > > > {
> > > > unsigned int i;
> > > > int ret;
> > > >
> > > > for (i = 0; i < num_settings; ++i, ++settings) {
> > > > ret = ov5645_write_reg(ov5645, settings->reg, settings->val);
> > > > if (ret < 0)
> > > > return ret;
> > > >
> > > > if (settings->delay_ms)
> > > > usleep_range(1000 * settings->delay_ms, 2 * 1000 *
> > > > settings->delay_ms);
> > >
> > > I'd prefer checking the register address in the write function instead
> > > of this if you really need it. But it seems you don't.
> >
> > With delays in powerup/down registers (0x3008 : 0x42,0x02) it is not
> > stable.
>
> Typo: without delays in powerup/down registers (0x3008 : 0x42,0x02) it is not
> stable.
>
> You can see 0x42 followed by 0x02 which is an indication of power down/up procedure.
>
> Cheers,
> Biju
next prev parent reply other threads:[~2024-02-14 23:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-13 14:02 [PATCH 0/2] Fix OV5645 capture issue with 400kHz i2c bus frequency Biju Das
2024-02-13 14:02 ` [PATCH 1/2] media: i2c: ov5645: Move the register 0x3008 from ov5645_global_init_setting Biju Das
2024-02-13 22:27 ` Wolfram Sang
2024-02-14 7:44 ` Biju Das
2024-02-14 8:31 ` Wolfram Sang
2024-02-14 20:25 ` Biju Das
2024-02-14 20:49 ` Sakari Ailus
2024-02-14 20:54 ` Biju Das
2024-02-14 20:57 ` Biju Das
2024-02-14 23:34 ` Kieran Bingham [this message]
2024-02-13 14:02 ` [PATCH 2/2] media: i2c: ov5645: Add a small delay after writes in ov5645_set_register_array() Biju Das
2024-02-13 22:32 ` Wolfram Sang
2024-02-14 20:30 ` Biju Das
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=170795365234.2765369.4101452918614439944@ping.linuxembedded.co.uk \
--to=kieran.bingham@ideasonboard.com \
--cc=biju.das.au@gmail.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=wsa@kernel.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.