Re: question about v4l2_subdev
Hi, Look at drivers/media/video/cafe_ccic.c And examine cafe_pci_probe() and the definition and use of the sensor_call() macro. Also note $ grep -Ril ov7670 drivers/media/video/* will show you in what drivers, the ov7670 might be used. I had a look at cafe_ccic.c and also at vpif_capture.c. I tried to use v4l2_i2c_new_subdev_board, but at boot time I have the following error: i2c i2c-0: Failed to register i2c client ov2640 at 0x30 (-16) I don't understand where it could come from, I pass the proper i2c_board_info struct, and it seems to check the proper i2c address, since it is not working. Basically I do like cafe_ccic.c execpt that I use the v4l2_i2c_new_subdev_board instead of v4l2_i2c_new_subdev... Any idea why I can't detect the sensor here? Regards, Sedji -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question about v4l2_subdev
Hi, 1. Something first should call v4l2_device_register() on a v4l2_device object. (Typically there is only one v4l2_device object per bridge chip between the PCI, PCIe, or USB bus and the subdevices, even if that bridge chip has more than one I2C master implementation.) 2. Then, for subdevices connected to the bridge chip via I2C, something needs to call v4l2_i2c_new_subdev() with the v4l2_device pointer as one of the arguments, to get back a v4l2_subdevice instance pointer. 3. After that, v4l2_subdev_call() with the v4l2_subdev pointer as one of the arguments can be used to invoke the subdevice methods. TV Video capture drivers do this work themselves. Drivers using a camera framework may have the framework doing some of the work for them. Regards, Andy Is there a sensor driver which is using this method? To write the ov2640 driver I have just copied the ov7670.c file, and I didn't find the v4l2_i2c_new_subdev in it... Regards, Sedji -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question about v4l2_subdev
Hi, Sorry to bother you again, but here is the situation: I have 2 drivers: an ov2640 driver and my atmel driver. Basically the ov2640 driver is the same as the ov7670 driver. So what I don't know is how to call the ov2640 functions(such as set format) in my atmel driver. In the ov2640 I used the function: v4l2_i2c_subdev_init, and in the atmel driver I used v4l2_device_register. But I don't know where I should use the v4l2_i2c_new_subdev function, and how to link my atmel video struct to the i2c sensor. Is there any examples in linux? Regards, Sedji Le 6/1/2010 10:14 AM, Sedji Gaouaou a écrit : Hi, 1. Something first should call v4l2_device_register() on a v4l2_device object. (Typically there is only one v4l2_device object per bridge chip between the PCI, PCIe, or USB bus and the subdevices, even if that bridge chip has more than one I2C master implementation.) 2. Then, for subdevices connected to the bridge chip via I2C, something needs to call v4l2_i2c_new_subdev() with the v4l2_device pointer as one of the arguments, to get back a v4l2_subdevice instance pointer. 3. After that, v4l2_subdev_call() with the v4l2_subdev pointer as one of the arguments can be used to invoke the subdevice methods. TV Video capture drivers do this work themselves. Drivers using a camera framework may have the framework doing some of the work for them. Regards, Andy Is there a sensor driver which is using this method? To write the ov2640 driver I have just copied the ov7670.c file, and I didn't find the v4l2_i2c_new_subdev in it... Regards, Sedji -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
question about v4l2_subdev
that the board generates a suitable
* master clock some other way, which is fine by us.
*
* We need to do this before probing the i2c bus, as the
* camera won't ack any messages when it doesn't have a clock.
*/
mclk = clk_get(NULL, mclk_name);
if (!IS_ERR(mclk)) {
clk_enable(mclk);
pr_debug(isi_clk enable\n);
}
else {
mclk = NULL;
pr_debug(no isi clock enable\n);
}
info = kzalloc(sizeof(struct ov2640), GFP_KERNEL);
if (info == NULL)
return -ENOMEM;
sd = info-sd;
v4l2_i2c_subdev_init(sd, client, ov2640_ops);
/* Make sure it's an ov2640 */
ret =ov2640_detect(sd);
if (ret) {
pr_debug(chip found @ 0x%x (%s) is not an ov2640 chip.\n,
client-addr 1, client-adapter-name);
kfree(info);
return ret;
}
/* default config */
ov2640_write_regs(sd, vga_yuv);
v4l_info(client, chip found @ 0x%02x (%s)\n,
client-addr 1, client-adapter-name);
return 0;
}
static int ov2640_remove(struct i2c_client *client)
{
struct v4l2_subdev *sd = i2c_get_clientdata(client);
v4l2_device_unregister_subdev(sd);
kfree(to_state(sd));
return 0;
}
static const struct i2c_device_id ov2640_i2c_id[] = {
{ ov2640, 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, ov2640_i2c_id);
static struct v4l2_i2c_driver_data v4l2_i2c_data = {
.name = ov2640,
.probe = ov2640_probe,
.remove = ov2640_remove,
.id_table = ov2640_i2c_id,
};
MODULE_AUTHOR(Sedji Gaouaou sedji.gaou...@atmel.com);
MODULE_DESCRIPTION(Omnivision ov955 Image Sensor driver);
MODULE_LICENSE(GPL);
Re: ATMEL camera interface
Hi, So I have decided to go with the v4l2-subdev API. I have taken the omapxxcam and vivi.c as exemple, but I have some questions... I still don't understand how to register a v4l2 device. I tried to copy the method from vivi.c using v4l2_device_register but it is not working? If I just use video_regiter_device, then it is trying to use the default ioctl and open/close functions from v4l2(v4l2_open) instead of the one I hae in my driver... What am I doing wrong? BR, Sedji Le 5/3/2010 6:40 PM, Guennadi Liakhovetski a écrit : On Mon, 3 May 2010, Sedji Gaouaou wrote: Well sorry to bother you again but I am looking at the mx1_camera.c file, and I wonder where are implemented the queue and dqueue functions? The atmel IP is using linked list for the buffers, and previously I was managing it in the queue and dqueue functions. I am not sure where I should take care of it now? qbuf and dqbuf are implemented by soc-camera in soc_camera_qbuf() and soc_camera_dqbuf() respectively, drivers only implement methods from struct videobuf_queue_ops, e.g., a .buf_queue method, which for mx1_camera is implemented by mx1_videobuf_queue(). Thanks Guennadi Regards, Sedji Le 5/3/2010 4:26 PM, Guennadi Liakhovetski a écrit : On Mon, 3 May 2010, Sedji Gaouaou wrote: Well I need contiguous memory, so I guess I will have a look at mx1_camera.c? Is there another example? What do you mean by videobuf implementation? As I said I just need a contiguous memory. I mean, whether you're gping to use videobuf-dma-contig.c or videobuf-dma-sg.c, respectively, whether you'll be calling videobuf_queue_dma_contig_init() or videobuf_queue_sg_init() in your driver. Regards Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ATMEL camera interface
Hi, I will try to write a soc driver(it seems easier ;)). Are the mx?_camera.c a good starting point? Regards, Sedji Le 4/29/2010 6:35 PM, Guennadi Liakhovetski a écrit : Hi Sedji On Thu, 29 Apr 2010, Sedji Gaouaou wrote: Hi, I need to re-work my driver so I could commit it to the community. Is there a git tree that I can use? Nice to hear that! As far as soc-camera is concerned, the present APIs are pretty stable. Just use the Linus' git tree, or, if you like, you can use the v4l-dvb git tree at git://linuxtv.org/v4l-dvb.git. In fact, you don't have to use the soc-camera API these days, you can just write a complete v4l2-device driver, using the v4l2-subdev API to interface to video clients (sensors, decoders, etc.) However, you can still write your driver as an soc-camera host driver, which would make your task a bit easier at the cost of some reduced flexibility, it's up to you to decide. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ATMEL camera interface
Well sorry to bother you again but I am looking at the mx1_camera.c file, and I wonder where are implemented the queue and dqueue functions? The atmel IP is using linked list for the buffers, and previously I was managing it in the queue and dqueue functions. I am not sure where I should take care of it now? Regards, Sedji Le 5/3/2010 4:26 PM, Guennadi Liakhovetski a écrit : On Mon, 3 May 2010, Sedji Gaouaou wrote: Well I need contiguous memory, so I guess I will have a look at mx1_camera.c? Is there another example? What do you mean by videobuf implementation? As I said I just need a contiguous memory. I mean, whether you're gping to use videobuf-dma-contig.c or videobuf-dma-sg.c, respectively, whether you'll be calling videobuf_queue_dma_contig_init() or videobuf_queue_sg_init() in your driver. Regards Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atmel v4l2 soc driver
Guennadi Liakhovetski a écrit : Wouldn't ov9655 be similar enough to ov9650 as used in stk-sensor.c? Hans, would that one also be converted to v4l2-device? If so, Sedji, you don't need to write yet another driver for it. I had a look at the stk-sensor file. Does it follow the soc arch? Regards, sedji -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atmel v4l2 soc driver
Well I am confused now...Should I still convert the atmel ISI driver to a soc driver? My concern was not to release a driver for the ov9655, but to have one which is working so I could test my atmel-soc driver :) Because I only have an ov9655 sensor here... Regards Sedji Guennadi Liakhovetski a écrit : On Mon, 23 Mar 2009, Sedji Gaouaou wrote: Guennadi Liakhovetski a écrit : Wouldn't ov9655 be similar enough to ov9650 as used in stk-sensor.c? Hans, would that one also be converted to v4l2-device? If so, Sedji, you don't need to write yet another driver for it. I had a look at the stk-sensor file. Does it follow the soc arch? No, it does not. But soc-camera is going to be converted to v4l2-device, so, if stkweb is going to be converted too, then the driver will be re-used. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
atmel v4l2 soc driver
Hi, I am currently porting an atmel isi driver to the soc layer, and I encounter some problems. I have based my driver on pax-camera. and sh_mobile_ceu_camera.c. The point is I can't see any video entry in /dev when I do ls dev/ on my board... So I wonder when is soc_camera_video_start(which call video_register_device) called? Is that at the probe? Regards, Sedji -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New v4l2 driver for atmel boards
Hi Guennadi, what hardware is it for? avr32 or at91 (ARM)? I am working on AT91(ARM). And what API are you using to communicate with sensors? I am using the ISI IP. Currently there are two APIs in the kernel - int-device and soc-camera, and they both should at some point (soon) converge to the new V4L2 driver framework. They all have (one of) the goal(s) to reuse sensor (or whatever subdevice) drivers with various hosts. Which of them are you using? I've recently got test hardware from Atmel for an AP7000 board (NGW100), and was planning to convert the existing external ISI driver from Atmel to the soc-camera API, but I have no idea when I find time for that. I have a driver which is not using the soc-camera layer... Which driver is currently using this soc-camera layer so I can have a look at it and maybe I could try to convert mine. Regards, Sedji -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
