ATMEL camera interface

ATMEL camera interface

[Sedji Gaouaou]

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?

Regards,
Sedji

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

Re: ATMEL camera interface

[Guennadi Liakhovetski]

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/

Re: ATMEL camera interface

[Sedji Gaouaou]

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-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ATMEL camera interface

[Guennadi Liakhovetski]

On Mon, 3 May 2010, Sedji Gaouaou wrote:

> Hi,
> 
> I will try to write a soc driver(it seems easier ;)).
> 
> Are the mx?_camera.c a good starting point?

In principle - yes. But think about one pretty important distinction - 
what videobuf implementation is your driver going to use? Are you going to 
support scatter-gather or only contiguous buffers? If SG - the only such 
example in the mainline is pxa_camera.c. If contiguous - feel free to use 
any one of the rest. Further, mx3_camera uses the dmaengine API, others 
don't. Hope, this will simplify your choice a bit;)

Thanks
Guennadi

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

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ATMEL camera interface

[Sedji Gaouaou]

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,
>>
>> I will try to write a soc driver(it seems easier ;)).
>>
>> Are the mx?_camera.c a good starting point?
>
> In principle - yes. But think about one pretty important distinction -
> what videobuf implementation is your driver going to use? Are you going to
> support scatter-gather or only contiguous buffers? If SG - the only such
> example in the mainline is pxa_camera.c. If contiguous - feel free to use
> any one of the rest. Further, mx3_camera uses the dmaengine API, others
> don't. Hope, this will simplify your choice a bit;)
>
> Thanks
> Guennadi
>
>> 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/
>>>
>>
>>
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>


--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ATMEL camera interface

[Guennadi Liakhovetski]

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/

Re: ATMEL camera interface

[Sedji Gaouaou]

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-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ATMEL camera interface

[Guennadi Liakhovetski]

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/

Re: ATMEL camera interface

[Sedji Gaouaou]

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-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html