* question about SoC Camera driver (Micron) @ 2008-05-12 14:03 Darius 2008-05-12 18:32 ` Guennadi Liakhovetski 0 siblings, 1 reply; 9+ messages in thread From: Darius @ 2008-05-12 14:03 UTC (permalink / raw) To: video4linux-list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: question about SoC Camera driver (Micron) 2008-05-12 14:03 question about SoC Camera driver (Micron) Darius @ 2008-05-12 18:32 ` Guennadi Liakhovetski 2008-05-13 8:31 ` Darius 0 siblings, 1 reply; 9+ messages in thread From: Guennadi Liakhovetski @ 2008-05-12 18:32 UTC (permalink / raw) To: Darius; +Cc: video4linux-list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: question about SoC Camera driver (Micron) 2008-05-12 18:32 ` Guennadi Liakhovetski @ 2008-05-13 8:31 ` Darius 2008-05-13 20:19 ` Guennadi Liakhovetski 0 siblings, 1 reply; 9+ messages in thread From: Darius @ 2008-05-13 8:31 UTC (permalink / raw) To: video4linux-list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: question about SoC Camera driver (Micron) 2008-05-13 8:31 ` Darius @ 2008-05-13 20:19 ` Guennadi Liakhovetski 2008-05-15 14:31 ` Darius 0 siblings, 1 reply; 9+ messages in thread From: Guennadi Liakhovetski @ 2008-05-13 20:19 UTC (permalink / raw) To: Darius; +Cc: video4linux-list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: question about SoC Camera driver (Micron) 2008-05-13 20:19 ` Guennadi Liakhovetski @ 2008-05-15 14:31 ` Darius 2008-05-15 19:39 ` Guennadi Liakhovetski 0 siblings, 1 reply; 9+ messages in thread From: Darius @ 2008-05-15 14:31 UTC (permalink / raw) To: video4linux-list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: question about SoC Camera driver (Micron) 2008-05-15 14:31 ` Darius @ 2008-05-15 19:39 ` Guennadi Liakhovetski 2008-05-22 13:19 ` Darius 0 siblings, 1 reply; 9+ messages in thread From: Guennadi Liakhovetski @ 2008-05-15 19:39 UTC (permalink / raw) To: Darius; +Cc: video4linux-list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: question about SoC Camera driver (Micron) 2008-05-15 19:39 ` Guennadi Liakhovetski @ 2008-05-22 13:19 ` Darius 2008-05-22 19:19 ` Guennadi Liakhovetski 0 siblings, 1 reply; 9+ messages in thread From: Darius @ 2008-05-22 13:19 UTC (permalink / raw) To: video4linux-list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: question about SoC Camera driver (Micron) 2008-05-22 13:19 ` Darius @ 2008-05-22 19:19 ` Guennadi Liakhovetski 2008-05-23 9:05 ` Darius 0 siblings, 1 reply; 9+ messages in thread From: Guennadi Liakhovetski @ 2008-05-22 19:19 UTC (permalink / raw) To: Darius; +Cc: video4linux-list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: question about SoC Camera driver (Micron) 2008-05-22 19:19 ` Guennadi Liakhovetski @ 2008-05-23 9:05 ` Darius 0 siblings, 0 replies; 9+ messages in thread From: Darius @ 2008-05-23 9:05 UTC (permalink / raw) To: video4linux-list > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-05-23 9:11 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-05-12 14:03 question about SoC Camera driver (Micron) Darius 2008-05-12 18:32 ` Guennadi Liakhovetski 2008-05-13 8:31 ` Darius 2008-05-13 20:19 ` Guennadi Liakhovetski 2008-05-15 14:31 ` Darius 2008-05-15 19:39 ` Guennadi Liakhovetski 2008-05-22 13:19 ` Darius 2008-05-22 19:19 ` Guennadi Liakhovetski 2008-05-23 9:05 ` Darius
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox