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
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.
Le 5/3/2010 4:03 PM, Guennadi Liakhovetski a écrit :
On Mon, 3 May 2010, Sedji Gaouaou wrote:
Hi
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
t 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 sor
t;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 },
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 subde
640 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
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 vpi
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
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 c
onfig?
Regards,
Sedji
Guennadi Liakhovetski a écrit :
On Wed, 11 Mar 2009, Sedji Gaouaou wrote:
I am currently porting an atmel isi driver to the soc layer,
This is good!
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
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?
Reg
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 l
13 matches
Mail list logo
