question about SoC Camera driver (Micron)

DISCUSSION Darius 2 participants 9 messages May 12, 2008 – May 23, 2008 Media (V4L/DVB)

Share & tools

Darius

author

2008-05-12 14:09 UTC #0 lore raw

I have question regarding both camera drivers for mt9v022 and mt9m001.
How does attach these drivers to i2c adapter? In i2c_driver structure there are neither .attach_adapter nor .detach_client members. So, how does these drivers comunicate via i2c bus? Have I something missed...?

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Guennadi Liakhovetski

2008-05-12 18:32 UTC #1 lore raw

Quoted 4 lines · Darius

I have question regarding both camera drivers for mt9v022 and mt9m001. How does attach these drivers to i2c adapter? In i2c_driver structure there are neither .attach_adapter nor .detach_client members. So, how does these drivers comunicate via i2c bus? Have I something missed...?

They are, so called, new style i2c drivers. They use .probe and .remove members, see source code for details.

Thanks
Guennadi
---
Guennadi Liakhovetski

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Darius

author

2008-05-13 08:36 UTC #2 lore raw

Quoted 7 lines · Guennadi Liakhovetski

Quoted 4 lines · Darius
I have question regarding both camera drivers for mt9v022 and mt9m001. How does attach these drivers to i2c adapter? In i2c_driver structure there are neither .attach_adapter nor .detach_client members. So, how does these drivers comunicate via i2c bus? Have I something missed...?

Quoted 6 lines

They are, so called, new style i2c drivers. They use .probe and .remove members, see source code for details.
Thanks
Guennadi
---
Guennadi Liakhovetski

Now I see how it works. I2C devices should be created before driver loading. There was my mistake, and driver does not call probe() function. Maybe would be better to create I2C devices by driver itself, not by the board specific config code? Now sensor driver is useless itself, without board specific configuration... Would be correct to do so?

Thanks,
Darius.

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Guennadi Liakhovetski

2008-05-13 20:20 UTC #3 lore raw

Quoted 5 lines · Darius

Now I see how it works. I2C devices should be created before driver loading. There was my mistake, and driver does not call probe() function. Maybe would be better to create I2C devices by driver itself, not by the board specific config code? Now sensor driver is useless itself, without board specific configuration... Would be correct to do so?

No. This is not how the driver model works. PCI drivers do not register PCI devices. The PCI host controller scans the PCI bus and adds devices into the system, to be later matched against PCI drivers. Similar for USB devices, etc. The problem with i2c you cannot reliably scan the bus. Therefore the information about devices present on the system has to come from elsewhere: when it is an i2c device embedded into a USB web-camera, its driver "knows", there's an i2c device and registers it. On embedded systems the platform knows what i2c devices are onboard, and registers them using i2c_register_board_info(), on powerpc (and sparc?) you can register i2c devices in your device tree, etc.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Darius

author

2008-05-15 14:37 UTC #4 lore raw

Quoted 16 lines · Guennadi Liakhovetski

Quoted 5 lines · Darius
Now I see how it works. I2C devices should be created before driver loading. There was my mistake, and driver does not call probe() function. Maybe would be better to create I2C devices by driver itself, not by the board specific config code? Now sensor driver is useless itself, without board specific configuration... Would be correct to do so?
No. This is not how the driver model works. PCI drivers do not register PCI devices. The PCI host controller scans the PCI bus and adds devices into the system, to be later matched against PCI drivers. Similar for USB devices, etc. The problem with i2c you cannot reliably scan the bus. Therefore the information about devices present on the system has to come from elsewhere: when it is an i2c device embedded into a USB web-camera, its driver "knows", there's an i2c device and registers it. On embedded systems the platform knows what i2c devices are onboard, and registers them using i2c_register_board_info(), on powerpc (and sparc?) you can register i2c devices in your device tree, etc.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

Quoted 5 lines

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Guennadi, can you please describe more detailed struct soc_camera_device structure? All these members xmin, ymin, etc... Also soc_camera_data_format structure has member depht. Should this member fit sensor bus bit count or pixel format depht in videodev2.h? Because most pixel formats are 16 bit and camera sensor interface in most cases is 8 bit.

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Guennadi Liakhovetski

2008-05-15 19:39 UTC #5 lore raw

Quoted 2 lines · Darius

Guennadi, can you please describe more detailed struct soc_camera_device structure? All these members xmin, ymin, etc...

The main point is, that the unit is 1 pixel. The rest is pretty much implementation specific. Just see your datasheet and select some natural values for allowed frame sizes and location. As the struct declaration says:

unsigned short width; /* Current window */
unsigned short height; /* sizes */
unsigned short x_min; /* Camera capabilities */
unsigned short y_min;
unsigned short x_current; /* Current window location */
unsigned short y_current;

The vales below are again min and max allowed values.

	unsigned short width_min;
	unsigned short width_max;
	unsigned short height_min;
	unsigned short height_max;

This is just to skip a few lines at the top, in case they are always corrupted, as was the case with Micron cameras. Soon there should be ab extra x_skip_left parameter.

unsigned short y_skip_top; /* Lines to skip at the top */

These are current gain and exposure values again. I selected them scaled to some more or less natural for humans ranges. See arrays of struct v4l2_queryctrl in mt9m001.c and mt9v022.c for examples

	unsigned short gain;
	unsigned short exposure;

Quoted 4 lines

Also soc_camera_data_format structure has member depht. Should this member fit sensor bus bit count or pixel format depht in videodev2.h? Because most pixel formats are 16 bit and camera sensor interface in most cases is 8 bit.

This is pixel format bit-depth, as provided by the sensor.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Darius

author

2008-05-22 13:25 UTC #6 lore raw

Quoted 5 lines · Guennadi Liakhovetski

Quoted 2 lines · Darius
Guennadi, can you please describe more detailed struct soc_camera_device structure? All these members xmin, ymin, etc...

Quoted 9 lines

The main point is, that the unit is 1 pixel. The rest is pretty much implementation specific. Just see your datasheet and select some natural values for allowed frame sizes and location. As the struct declaration says:
unsigned short width; /* Current window */
unsigned short height; /* sizes */
unsigned short x_min; /* Camera capabilities */
unsigned short y_min;
unsigned short x_current; /* Current window location */
unsigned short y_current;

where they are used? as I can see, in *_try_fmt_cap() and *__set_fmt_cap() you are using hard coded constants. in video_probe you are setting this structure, but these values are never used?

Quoted 6 lines

The vales below are again min and max allowed values.
	unsigned short width_min;
	unsigned short width_max;
	unsigned short height_min;
	unsigned short height_max;

should they be used in *_try_fmt_cap() function to inform v4l2 driver about sensor posibilities? now in *_try_fmt_cap() you are using hard coded constants. values from soc_camera_device *icd struct are not used?

btw, can you tell something about frame rate setting? how to implement that? for example, I want from user space adjust frame rate (4, 15, 25, 30fps...). Should I pass these setting to sensor driver via *_set_fmt_cap()?

Thanks,

Darius.

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Guennadi Liakhovetski

2008-05-22 19:19 UTC #7 lore raw

Quoted 18 lines · Darius

Quoted 9 lines · Guennadi Liakhovetski
Quoted 2 lines · Darius
Guennadi, can you please describe more detailed struct soc_camera_device structure? All these members xmin, ymin, etc...
The main point is, that the unit is 1 pixel. The rest is pretty much implementation specific. Just see your datasheet and select some natural values for allowed frame sizes and location. As the struct declaration says:
Quoted 7 lines
unsigned short width; /* Current window */
unsigned short height; /* sizes */
unsigned short x_min; /* Camera capabilities */
unsigned short y_min;
unsigned short x_current; /* Current window location */
unsigned short y_current;

Quoted 4 lines

where they are used? as I can see, in *_try_fmt_cap() and *__set_fmt_cap() you are using hard coded constants.
in video_probe you are setting this structure, but these values are never used?

Which of them you don't see being used? The ones I checked are used.

Quoted 11 lines

Quoted 6 lines
The vales below are again min and max allowed values.
	unsigned short width_min;
	unsigned short width_max;
	unsigned short height_min;
	unsigned short height_max;
should they be used in *_try_fmt_cap() function to inform v4l2 driver about sensor posibilities?
now in *_try_fmt_cap() you are using hard coded constants. values from soc_camera_device *icd struct are not used?

Please, tell me exactly where you suspect bugs. soc_camera.c, pxa_camera.c, mt9?0??.c all have *try_fmt_cap().

Quoted 3 lines

btw, can you tell something about frame rate setting? how to implement that? for example, I want from user space adjust frame rate (4, 15, 25, 30fps...). Should I pass these setting to sensor driver via *_set_fmt_cap()?

This is not supported.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Darius

author

2008-05-23 09:11 UTC #8 lore raw

Quoted 2 lines

Please, tell me exactly where you suspect bugs. soc_camera.c, pxa_camera.c, mt9?0??.c all have *try_fmt_cap().

I see, but try_fmt_cap does not return camera capabilities, it only tries pixel format, without driver state changing. Maybe it is good idea to implement additional g_fmt_cap ioctl handler in soc_camera? Or instead try_fmt_cap? Because s_fmt_cap is for fmt setting, g_fmt_cap for getting camera fmt capabilities, and try_fmt_cap is for what? For getting fmt too? v4l2 documentation recommends not implement this ioctl in the driver.

Quoted 7 lines

Quoted 4 lines
btw, can you tell something about frame rate setting? how to implement that? for example, I want from user space adjust frame rate (4, 15, 25, 30fps...). Should I pass these setting to sensor driver via *_set_fmt_cap()?
This is not supported.

I think should be not hard to implement vidioc_g_parm and vidioc_s_parm in soc_camera to support frame rate setting? Now I'm writing driver for OV7670, and I plan to add these features (frame rate setting and g_fmt_cap) to soc_camera driver. What is your opinion?

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list