Video Common Controls don't seem to work when using 8bit registers and 8 bit data.

[mjs513]

@KurtE - @josuah for info

Recently while trying to convert the ov7670.c video driver over to using the video common commands such using video_read_cci _reg and video_write_cci_reg strange things are happening, i.e., no video images are generated from the camera, yet when using i2c commands for reading and writing regs it works no issues. So I tried to do a little debugging.

From what I understand you first have to define a macro for the using reg and data in 8 bits, i.e.

#define OV7670_REG8(addr)   ((addr) | VIDEO_REG_ADDR8_DATA8)

Then when using say for reading the pid register (note this is test)

	uint8_t cmd = OV7670_PID;
  
	ret = video_read_cci_reg(&config->bus, OV7670_REG8(cmd), &pid);

	if (ret < 0) {
		LOG_ERR("Could not read product ID: %d", ret);
		return ret;
	}

	if (pid != OV7670_PROD_ID) {
		LOG_ERR("Incorrect product ID: 0x%02X", pid);
		return -ENODEV;
	}

where I have for PID

	uint32_t pid;

I am not seeing an error so guess it works but probably should have checked to see what what returned.

Anyway it compiles and I can load it. However, when I run the image I am seeing on the giga display shield

Just for reference when I dont use video_cci_read I get a good image.

As a further note if I don't use the macro

video_read_cci_reg(&config->bus, (cmd), &pid);

I will get a good video.

So the question of the day:

Is there a bug in the video_common api or am I doing something wrong.

The only other thing i notice is that all the cameras that use 8bit reg/8bit data dont use the video_common commands.

Either way some guidance would be appreciated.

[KurtE]

So far in the drivers\video directories I only see a couple of places that use it:

Searching 49 files for "video_read_cci_reg"

D:\zephyrproject\zephyr\drivers\video\gc2145.c:
  961  	int ret;
  962  
  963: 	ret = video_read_cci_reg(&cfg->i2c, GC2145_REG_CHIP_ID, &chip_id);
  964  	if (ret < 0) {
  965  		return ret;

D:\zephyrproject\zephyr\drivers\video\ov9655.c:
  375  
  376  	/* Read Product ID & Version ID */
  377: 	ret = video_read_cci_reg(&config->i2c, OV9655_PID, &pid);
  378  	if (ret < 0) {
  379  		LOG_ERR("Could not request product ID: %d", ret);

D:\zephyrproject\zephyr\drivers\video\video_common.c:
  219  }
  220  
  221: int video_read_cci_reg(const struct i2c_dt_spec *i2c, uint32_t reg_addr, uint32_t *reg_data)
  222  {
  223  	size_t addr_size = FIELD_GET(VIDEO_REG_ADDR_SIZE_MASK, reg_addr);
  ...
  342  	int ret;
  343  
  344: 	ret = video_read_cci_reg(i2c, reg_addr, &reg);
  345  	if (ret < 0) {
  346  		return ret;

D:\zephyrproject\zephyr\drivers\video\video_common.h:
  189   *                  This is a 32-bit integer pointer even when reading 8-bit or 16 bits value.
  190   */
  191: int video_read_cci_reg(const struct i2c_dt_spec *i2c, uint32_t reg_addr, uint32_t *reg_data);
  192  
  193  /**

5 matches across 4 files

The place that uses it in video_common.c is the function: video_modify_cci_reg which is only used within gc2145.c

Searching 49 files for "video_modify_cci_reg"

D:\zephyrproject\zephyr\drivers\video\gc2145.c:
  833  	}
  834  
  835: 	ret = video_modify_cci_reg(&cfg->i2c, GC2145_REG8(GC2145_REG_OUTPUT_FMT),
  836  				   GC2145_REG_OUTPUT_FMT_MASK, output_format);
  837  	if (ret < 0) {
  ...
 1159  	case VIDEO_CID_HFLIP:
 1160  		/* Set the horizontal mirror state */
 1161: 		return video_modify_cci_reg(&cfg->i2c, GC2145_REG_AMODE1, GC2145_REG_AMODE1_MIRROR,
 1162  					    drv_data->ctrls.hflip.val ?
 1163  					    GC2145_REG_AMODE1_MIRROR : 0);
 1164  	case VIDEO_CID_VFLIP:
 1165  		/* Set the vertical flip state */
 1166: 		return video_modify_cci_reg(&cfg->i2c, GC2145_REG_AMODE1, GC2145_REG_AMODE1_UPDOWN,
 1167  					    drv_data->ctrls.vflip.val ?
 1168  					    GC2145_REG_AMODE1_UPDOWN : 0);

D:\zephyrproject\zephyr\drivers\video\video_common.c:
  336  }
  337  
  338: int video_modify_cci_reg(const struct i2c_dt_spec *i2c, uint32_t reg_addr, uint32_t field_mask,
  339  			 uint32_t field_value)
  340  {

D:\zephyrproject\zephyr\drivers\video\video_common.h:
  175   * @brief field_value Value to write at this address, the size to write is encoded in the address.
  176   */
  177: int video_modify_cci_reg(const struct i2c_dt_spec *i2c, uint32_t reg_addr, uint32_t field_mask,
  178  			 uint32_t field_value);
  179  

5 matches across 3 files

Maybe best to stick with the functions that work?

[mjs513]

@KurtE

Maybe best to stick with the functions that work?

Think you are going to turn out right but that implies there is something fundamentally wrong with video common for 8bit data/regs. Either that or I am doing it wrong.

Right now I just want to see what would happen if I left reading the PID and resetting the camera as I2C reads/writes. What happens is the the rest of the driver works except for when I set vflip and hflp which uses:

video_modify_cci_reg(

you get errored out

Starting  capture
[00:00:05.022,000] <err> video_common: failed to write-read to I2C register
                                       1e                                               |.
[00:00:05.039,000] <err> video_common: Failed to read from register 0x1e

Now if I comment out vflip and hflip in the sketch as a test of the other functions. Well camera show started

height: 480, width: 800, rotated: 1
INFO:   RGBP width [176; 176; 0] height [144; 144; 0]
INFO:   RGBP width [320; 320; 0] height [240; 240; 0]
BSIZE: 153600
Starting  capture

but no frames are grabed to display!!!!

CONCLUSION: Stick with I2c commons when dealing with 8bit regs and 8 bit data

[mjs513]

Decided to hook up a LA to the 0v7670 and look at the traces when using video common commands.

1 On reading the PID and writing a reset you can see using video read/write cci commands seem to be failing:

as opposed to using i2c commands as it is currently

Basically its exiting after failing to read the PID register.

[mjs513]

Today decided to try to reading pid using standard 12c calls

	ret = i2c_write_dt(&config->bus, &cmd, sizeof(cmd));
	if (ret < 0) {
		LOG_ERR("Could not request product ID: %d", ret);
		return ret;
	}
	ret = i2c_read_dt(&config->bus, &pid, sizeof(pid));
	if (ret < 0) {
		LOG_ERR("Could not read product ID: %d", ret);
		return ret;
	}

	if (pid != OV7670_PROD_ID) {
		LOG_ERR("Incorrect product ID: 0x%02X", pid);
		return -ENODEV;
	}

to see what happens. However since I am also sending flip commands and as @KurtE pointed it, those commands use the read cci reg command through the modify_reg command flip threw an error

[00:00:05.032,000] <err> video_common: failed to write-read to I2C register
                                       1e                                               |.
[00:00:05.051,000] <err> video_common: Failed to read from register 0x1e

but you will still get a good image.

[mjs513]

UPDATE:
On the off chance the issue was with arduinocore-zephyr I ran @KurtE capture to usb app with ov7670 driver using video_read_cci_reg and the error persists:

[00:00:00.103,000] <err> video_common: failed to write-read to I2C register
                                       0a                                               |.
[00:00:00.103,000] <err> video_common: Failed to read from register 0xa
[00:00:00.103,000] <err> video_ov7670: Could not request product ID: -5
*** Booting Zephyr OS build v4.2.0-21-g277ebb69af4a ***
[00:00:00.104,000] <inf> main: Video device: dcmi@48020000
[00:00:00.104,000] <inf> main: - Capabilities:
[00:00:00.104,000] <inf> main:  RGBP width [176; 176; 0] height [144; 144; 0]
[00:00:00.104,000] <inf> main:  RGBP width [320; 320; 0] height [240; 240; 0]
[00:00:00.104,000] <inf> main:  RGBP width [352; 352; 0] height [288; 288; 0]
[00:00:00.104,000] <inf> main:  RGBP width [640; 640; 0] height [480; 480; 0]
[00:00:00.104,000] <inf> main:  YUYV width [176; 176; 0] height [144; 144; 0]
[00:00:00.104,000] <inf> main:  YUYV width [320; 320; 0] height [240; 240; 0]
[00:00:00.104,000] <inf> main:  YUYV width [352; 352; 0] height [288; 288; 0]
[00:00:00.104,000] <inf> main:  YUYV width [640; 640; 0] height [480; 480; 0]
[00:00:00.104,000] <inf> main: video_get_format(1): ret w:0 h:0 fmt:0
[00:00:00.104,000] <inf> main: - Video format:  0x0
[00:00:00.104,000] <err> video_ov7670: Only RGB565 and YUYV supported!
[00:00:00.104,000] <err> main: Unable to set format

at least using zephyr directly got a lot more info.

Now if I try to do it the ov9565.c drive does it:

#define OV7670_REG16(addr)  ((uint32_t)(addr) | VIDEO_REG_ADDR8_DATA16_BE)

/* OV7670 registers */
#define OV7670_PID                OV7670_REG16(0x0A)
.....
	/* Read Product ID & Version ID */
	ret = video_read_cci_reg(&config->bus, OV7670_PID, &pid);
	if (ret < 0) {
		LOG_ERR("Could not request product ID: %d", ret);
		return ret;
	}

	if (pid != 0x7673) {
		LOG_ERR("Incorrect product ID: 0x%04X", pid);
		return -ENODEV;
	}

I get the exact same error message!

[josuah]

It is known that some OmniVision devices have some divergence with the I2C protocol. This could be something like requiring individual I2C transaction rather than chaining them one after the other... I will try to look where I last saw this.

Sorry for the long wait as I'm still catching-up with the backlog of reviews and answers!

[mjs513]

@josuah

It is known that some OmniVision devices have some divergence with the I2C protocol. This could be something like requiring individual I2C transaction rather than chaining them one after the other... I will try to look where I last saw this.

Sorry for the long wait as I'm still catching-up with the backlog of reviews and answers!

Not a problem. Figured you all were busy with other things.

PS. Thought I was going crazy that it didn't work. So looks like I am better off sticking with standard I2C commands since mixing and matching seems is going to be an issue. This is not a problem.

[avolmat-st]

@mjs513, I read the whole thread. I think I understand that so far the two errors you've been facing is either reading the PID (very very read to the sensor) or the address 0xA which is the first one done right after performing the reset of the sensor via COM7. Is that correct ?

[avolmat-st]

As a further note if I don't use the macro

video_read_cci_reg(&config->bus, (cmd), &pid);

I will get a good video.

Considering that here cmd is equal to the PID register address (aka 0x0A), I do not understand how this would even compile or run ?

Below is part of the code of video_read_cci_reg

int video_read_cci_reg(const struct i2c_dt_spec *i2c, uint32_t reg_addr, uint32_t *reg_data)
{
        size_t addr_size = FIELD_GET(VIDEO_REG_ADDR_SIZE_MASK, reg_addr);
        size_t data_size = FIELD_GET(VIDEO_REG_DATA_SIZE_MASK, reg_addr);
        bool big_endian = FIELD_GET(VIDEO_REG_ENDIANNESS_MASK, reg_addr);
        uint16_t addr = FIELD_GET(VIDEO_REG_ADDR_MASK, reg_addr);
        uint8_t buf_w[sizeof(uint16_t)] = {0};
        uint8_t *data_ptr;
        int ret;

        __ASSERT_NO_MSG(i2c != NULL);
        __ASSERT_NO_MSG(reg_data != NULL);
        __ASSERT(addr_size > 0, "The address must have a address size flag");
        __ASSERT(data_size > 0, "The address must have a data size flag");

So here, reg_addr = 0x0A I think, but from it, the function tries to figure out the register addr / data size as well as endianness.

Considering that the bitfields are

#define VIDEO_REG_ENDIANNESS_MASK               (uint32_t)(GENMASK(24, 24))
#define VIDEO_REG_ADDR_SIZE_MASK                (uint32_t)(GENMASK(23, 20))
#define VIDEO_REG_DATA_SIZE_MASK                (uint32_t)(GENMASK(19, 16))
#define VIDEO_REG_ADDR_MASK                     (uint32_t)(GENMASK(15, 0))

basically they are all 0 since the reg_addr = 0x0A.

So, the function should fail on the last 2 ASSERT shown above...

Aka thoses:

        __ASSERT(addr_size > 0, "The address must have a address size flag");
        __ASSERT(data_size > 0, "The address must have a data size flag");

Do you have __ASSERT disabled on your system ?

[mjs513]

@avolmat-st

Considering that here cmd is equal to the PID register address (aka 0x0A), I do not understand how this would even compile or run ?
Thats a bit of old code that I changed after your comments in the pr. Currently I have

	/* Read Product ID & Version ID */
	ret = video_read_cci_reg(&config->bus, OV7670_REG8(OV7670_PID), &pid);
	if (ret < 0) {
		LOG_ERR("Could not request product ID: %d", ret);
		return ret;
	}

	if (pid != 0x76) {
		LOG_ERR("Incorrect product ID: 0x%04X", pid);
		return -ENODEV;
	}

where:

#define OV7670_REG8(addr)   ((uint32_t)(addr) | VIDEO_REG_ADDR8_DATA8)
and
	uint32_t pid;

Using the giga overlay didn't notice it was enabled or not so just added

CONFIG_ASSERT=y

and reran the app. Same error messages are received

[00:00:00.103,000] <err> video_common: failed to write-read to I2C register
                                       0a                                               |.
[00:00:00.103,000] <err> video_common: Failed to read from register 0xa
[00:00:00.103,000] <err> video_ov7670: Could not request product ID: -5
*** Booting Zephyr OS build v4.2.0-21-g277ebb69af4a ***
[00:00:00.104,000] <inf> main: Video device: dcmi@48020000
[00:00:00.104,000] <inf> main: - Capabilities:
[00:00:00.104,000] <inf> main:  RGBP width [176; 176; 0] height [144; 144; 0]
[00:00:00.104,000] <inf> main:  RGBP width [320; 320; 0] height [240; 240; 0]
[00:00:00.104,000] <inf> main:  RGBP width [352; 352; 0] height [288; 288; 0]
[00:00:00.104,000] <inf> main:  RGBP width [640; 640; 0] height [480; 480; 0]
[00:00:00.104,000] <inf> main:  YUYV width [176; 176; 0] height [144; 144; 0]
[00:00:00.104,000] <inf> main:  YUYV width [320; 320; 0] height [240; 240; 0]
[00:00:00.104,000] <inf> main:  YUYV width [352; 352; 0] height [288; 288; 0]
[00:00:00.104,000] <inf> main:  YUYV width [640; 640; 0] height [480; 480; 0]
[00:00:00.104,000] <inf> main: video_get_format(1): ret w:0 h:0 fmt:0
[00:00:00.104,000] <inf> main: - Video format:  0x0
[00:00:00.104,000] <err> video_ov7670: Only RGB565 and YUYV supported!
[00:00:00.104,000] <err> main: Unable to set format

[avolmat-st]

I don't expect it to work better with ASSERT enabled, but this should rise an ASSERT in fact and application should stop with a big assert trace.

[josuah]

In some cases it is necessary to delete ./build/ and start from clean.
To check if a Kconfig option is effectively set or not, it is possible to review the ./build/zephyr/.config file which will list all applied options.

[josuah]

If you called it like this:
ret = video_read_cci_reg(&config->bus, OV7670_REG8(OV7670_PID), &pid);
Then it should work, no problem.

[mjs513]

@josuah
Took a look at the .config config_assert=y is set but there seem to be other assert options that are not - not sure if they need to be. Here is a zip of the config if you want to take a look

config.zip

But as a quick and dirty test i decided to do a i2c_write_read command as a hack:

    uint8_t reg = OV7670_PID;
    uint8_t pid1 = 0;

    ret = i2c_write_read(dev, 0x21, &reg, 1, &pid1, 1);
    if (ret == 0) {
        printk("OV7670 PID: 0x%02X\n", pid);  // Expect 0x76
    } else {
        printk("Failed to read OV7670 PID: %d\n", ret);
    }

and it seemed to work without issue:

[mjs513]

@josuah
Did a clean build and not seeing any differences regarding assert trace.

[00:00:00.103,000] <err> video_common: failed to write-read to I2C register
                                       0a                                               |.
[00:00:00.103,000] <err> video_common: Failed to read from register 0xa
[00:00:00.103,000] <err> video_ov7670: Could not request product ID: -5

[mjs513]

@josuah

Would you have a branch that has all the code you tried with? It would be easier than snippets of code gathered around. Or is it with an unmodified OV7670 driver? Thanks.

I just created a branch with my code for the methods - right now nothing fancy
https://github.com/mjs513/zephyr/tree/video_read_cci_experiments

[mjs513]

You might also want to enable the CONFIG_I2C_DUMP_MESSAGES option. That done, we will be able to see what is being transfered.

Cf to doc/develop/debug/index.rst for explanation about how to use and what to expect when using this option.

This won't fix the issue but hopefully make us understand better what is being sent to the sensor. When using video_read_cci_reg(&config->bus, OV7670_REG8(OV7670_PID), &pid) => I expect to get the right address / offset being accessed while if OV7670_REG8 is not mentioned, address / offset won't be correct.

Per your suggestion I ran it for using video_read_cci_reg.

Hello world

--- 5 messages dropped ---
[00:00:00.103,000] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@58001c00, addr=21
[00:00:00.103,000] <dbg> i2c: i2c_dump_msgs_rw:    W Sr   len=01: 0a
[00:00:00.103,000] <dbg> i2c: i2c_dump_msgs_rw:    R Sr P len=01: 00
[00:00:00.103,000] <err> video_common: failed to write-read to I2C register
                                       0a                                               |.
[00:00:00.103,000] <err> video_common: Failed to read from register 0xa
[00:00:00.103,000] <err> video_ov7670: Could not request product ID: -5
*** Booting Zephyr OS build v4.2.0-21-g277ebb69af4a ***
[00:00:00.104,000] <inf> main: Video device: dcmi@48020000
[00:00:00.104,000] <inf> main: - Capabilities:
[00:00:00.104,000] <inf> main:  RGBP width [176; 176; 0] height [144; 144; 0]
[00:00:00.104,000] <inf> main:  RGBP width [320; 320; 0] height [240; 240; 0]
[00:00:00.104,000] <inf> main:  RGBP width [352; 352; 0] height [288; 288; 0]
[00:00:00.104,000] <inf> main:  RGBP width [640; 640; 0] height [480; 480; 0]
[00:00:00.104,000] <inf> main:  YUYV width [176; 176; 0] height [144; 144; 0]
[00:00:00.104,000] <inf> main:  YUYV width [320; 320; 0] height [240; 240; 0]
[00:00:00.104,000] <inf> main:  YUYV width [352; 352; 0] height [288; 288; 0]
[00:00:00.104,000] <inf> main:  YUYV width [640; 640; 0] height [480; 480; 0]
[00:00:00.104,000] <inf> main: video_get_format(1): ret w:0 h:0 fmt:0
[00:00:00.104,000] <inf> main: - Video format:  0x0
[00:00:00.104,000] <err> video_ov7670: Only RGB565 and YUYV supported!
[00:00:00.104,000] <err> main: Unable to set format

Not sure its going to be of much help.

[avolmat-st]

You might also want to enable the CONFIG_I2C_DUMP_MESSAGES option. That done, we will be able to see what is being transfered.
Cf to doc/develop/debug/index.rst for explanation about how to use and what to expect when using this option.
This won't fix the issue but hopefully make us understand better what is being sent to the sensor. When using video_read_cci_reg(&config->bus, OV7670_REG8(OV7670_PID), &pid) => I expect to get the right address / offset being accessed while if OV7670_REG8 is not mentioned, address / offset won't be correct.

Per your suggestion I ran it for using video_read_cci_reg.

Hello world

--- 5 messages dropped ---
[00:00:00.103,000] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@58001c00, addr=21
[00:00:00.103,000] <dbg> i2c: i2c_dump_msgs_rw:    W Sr   len=01: 0a
[00:00:00.103,000] <dbg> i2c: i2c_dump_msgs_rw:    R Sr P len=01: 00
[00:00:00.103,000] <err> video_common: failed to write-read to I2C register
                                       0a                                               |.
[00:00:00.103,000] <err> video_common: Failed to read from register 0xa
[00:00:00.103,000] <err> video_ov7670: Could not request product ID: -5
*** Booting Zephyr OS build v4.2.0-21-g277ebb69af4a ***
[00:00:00.104,000] <inf> main: Video device: dcmi@48020000
[00:00:00.104,000] <inf> main: - Capabilities:
[00:00:00.104,000] <inf> main:  RGBP width [176; 176; 0] height [144; 144; 0]
[00:00:00.104,000] <inf> main:  RGBP width [320; 320; 0] height [240; 240; 0]
[00:00:00.104,000] <inf> main:  RGBP width [352; 352; 0] height [288; 288; 0]
[00:00:00.104,000] <inf> main:  RGBP width [640; 640; 0] height [480; 480; 0]
[00:00:00.104,000] <inf> main:  YUYV width [176; 176; 0] height [144; 144; 0]
[00:00:00.104,000] <inf> main:  YUYV width [320; 320; 0] height [240; 240; 0]
[00:00:00.104,000] <inf> main:  YUYV width [352; 352; 0] height [288; 288; 0]
[00:00:00.104,000] <inf> main:  YUYV width [640; 640; 0] height [480; 480; 0]
[00:00:00.104,000] <inf> main: video_get_format(1): ret w:0 h:0 fmt:0
[00:00:00.104,000] <inf> main: - Video format:  0x0
[00:00:00.104,000] <err> video_ov7670: Only RGB565 and YUYV supported!
[00:00:00.104,000] <err> main: Unable to set format

Not sure its going to be of much help.

What is the video_read_cci_reg command used corresponding to this dump ? With or without the OV7670_xx macro ? I'd say that this one has the macro being used.
What about when NOT using the macro ?

[avolmat-st]

Having a look again at the OV7670 driver, there is a comment within the driver which states:

	/*
	 * Read product ID from camera. This camera implements the SCCB,
	 * spec- which *should* be I2C compatible, but in practice does
	 * not seem to respond when I2C repeated start commands are used.
	 * To work around this, use a write then a read to interface with
	 * registers.
	 */

Or, the video_read_cci_reg IS doing repeated start, aka the log below:

[00:00:00.103,000] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@58001c00, addr=21
[00:00:00.103,000] <dbg> i2c: i2c_dump_msgs_rw:    W Sr   len=01: 0a
[00:00:00.103,000] <dbg> i2c: i2c_dump_msgs_rw:    R Sr P len=01: 00
[00:00:00.103,000] <err> video_common: failed to write-read to I2C register
                                       0a                       

So, basically, we might want to consider that ov7670 is just not a candidate for moving to the video_read_cci_reg api.

In the log you provided above, the command seems to be correct, however there is a transfer error at lower level, maybe a NACK or timeout at the I2C level, probably simply because the sensor does not want to accept this way a communication.

[josuah]

I suppose this is the root cause, so just for the first I2C command that checks the ID, it might need to be a manual I2C API like what is done now, and then can switch to CCI.
Hopefully this is solving this problem, if not, it's possible to remove the "answer" flag.
Thanks all for such investigation!

[mjs513]

@avolmat-st - @josuah

Have no problem mixing and matching since using video_write_multireg_cci seems to be working no issue. However, when using video_modify_cci_reg has the same issue since it eventually calls video_read_cci_reg to modify the register.

So at this point can I mix and match i2c commands with the video_common commands in the drivers espescially if we are merging the the ov7670 and the ov7675 drivers. The ov7675 does not seem to have this issue but going to retest again just to be sure.

[josuah]

Maybe this is an errata that ov7670 has, and that got fixed in the ov7675... Not sure at all.

It seems to all be boiling down to video_read_cci_reg()... at least all the configuration tables are write-only.
It makes sense to keep a local implementation of the 'read' command to work around a bug specific to that sensor.

Thanks for tracing that down and improving these drivers!

[mjs513]

It seems to all be boiling down to video_read_cci_reg()... at least all the configuration tables are write-only. It makes sense to keep a local implementation of the 'read' command to work around a bug specific to that sensor.

Thanks for tracing that down and improving these drivers!

@josuah
Thanks - will play with the ov7670 driver changes now.