question about SoC Camera driver (Micron)

question about SoC Camera driver (Micron)

[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...?

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: question about SoC Camera driver (Micron)

[Guennadi Liakhovetski]

On Mon, 12 May 2008, Darius wrote:

> 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:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: question about SoC Camera driver (Micron)

[Darius]

Guennadi Liakhovetski wrote:
> On Mon, 12 May 2008, Darius wrote:
> 
>> 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

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:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: question about SoC Camera driver (Micron)

[Guennadi Liakhovetski]

On Tue, 13 May 2008, Darius wrote:

> 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:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: question about SoC Camera driver (Micron)

[Darius]

Guennadi Liakhovetski wrote:
> On Tue, 13 May 2008, Darius wrote:
> 
>> 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:video4linux-list-request@redhat.com?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:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: question about SoC Camera driver (Micron)

[Guennadi Liakhovetski]

On Thu, 15 May 2008, Darius wrote:

> 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;

> 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:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: question about SoC Camera driver (Micron)

[Darius]

Guennadi Liakhovetski wrote:
> On Thu, 15 May 2008, Darius wrote:
> 
>> 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;
> 

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?

> 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:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: question about SoC Camera driver (Micron)

[Guennadi Liakhovetski]

On Thu, 22 May 2008, Darius wrote:

> Guennadi Liakhovetski wrote:
> > On Thu, 15 May 2008, Darius wrote:
> > 
> > > 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;
> > 
> 
> 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.

> > 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().

> 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:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: question about SoC Camera driver (Micron)

[Darius]

> 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.

> 
>> 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:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list