Integrating v4l2_device/v4l2_subdev into the soc_camera framework

Integrating v4l2_device/v4l2_subdev into the soc_camera framework

[Hans Verkuil]

Hi Guennadi,

Now that the v4l2_device and v4l2_subdev structs are merged into the 
master v4l-dvb repository it is time to look at what needs to be done 
to integrate it into the soc-camera framework.

The goal is to make the i2c sub-device drivers independent from how they 
are used. That is, whether a sensor is used in an embedded device or in 
a USB webcam or something else should not matter for the sensor driver.

I would really appreciate it if you can take a good look at what would 
be needed to achieve this. We can then discuss that and make a plan on 
how to proceed.

I'll be happy to answer any questions you have or help you in whatever 
way you want.

Thank you,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

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

Re: Integrating v4l2_device/v4l2_subdev into the soc_camera framework

[Antonio Ospite]

[-- Attachment #1.1: Type: text/plain, Size: 906 bytes --]

On Mon, 15 Dec 2008 11:45:54 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> Hi Guennadi,
> 
> Now that the v4l2_device and v4l2_subdev structs are merged into the 
> master v4l-dvb repository it is time to look at what needs to be done 
> to integrate it into the soc-camera framework.
> 
> The goal is to make the i2c sub-device drivers independent from how they 
> are used. That is, whether a sensor is used in an embedded device or in 
> a USB webcam or something else should not matter for the sensor driver.
>

Is something like this planned for gspca as well?

Thanks,
   Antonio

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

  Web site: http://www.studenti.unina.it/~ospite
Public key: http://www.studenti.unina.it/~ospite/aopubkey.asc

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 164 bytes --]

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

Re: Integrating v4l2_device/v4l2_subdev into the soc_camera framework

[Hans Verkuil]

On Monday 15 December 2008 15:57:14 Antonio Ospite wrote:
> On Mon, 15 Dec 2008 11:45:54 +0100
>
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > Hi Guennadi,
> >
> > Now that the v4l2_device and v4l2_subdev structs are merged into
> > the master v4l-dvb repository it is time to look at what needs to
> > be done to integrate it into the soc-camera framework.
> >
> > The goal is to make the i2c sub-device drivers independent from how
> > they are used. That is, whether a sensor is used in an embedded
> > device or in a USB webcam or something else should not matter for
> > the sensor driver.
>
> Is something like this planned for gspca as well?

My understanding is that most if not all of the 'subdevices' used in 
gspca are reversed engineered and as such can by definition only work 
within gspca.

So in this case I see no need to move to the new structs. That said, 
there is nothing that prevents gspca to start using these structs as 
well, in particular since they will be extended over time to take care 
of e.g. control processing, etc.

Note that it is easy (although not yet implemented since nobody needs it 
right now) to add driver-specific ops to v4l2_subdev. This could be 
ideal for gspca. So it is still possible to use the gspca-specific ops 
while also being able at the same time to use the standard ops and 
other features that the framework will offer in the future.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

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

Re: Integrating v4l2_device/v4l2_subdev into the soc_camera framework

[Guennadi Liakhovetski]

Hi Hans,

On Mon, 15 Dec 2008, Hans Verkuil wrote:

> Hi Guennadi,
> 
> Now that the v4l2_device and v4l2_subdev structs are merged into the 
> master v4l-dvb repository it is time to look at what needs to be done 
> to integrate it into the soc-camera framework.
> 
> The goal is to make the i2c sub-device drivers independent from how they 
> are used. That is, whether a sensor is used in an embedded device or in 
> a USB webcam or something else should not matter for the sensor driver.
> 
> I would really appreciate it if you can take a good look at what would 
> be needed to achieve this. We can then discuss that and make a plan on 
> how to proceed.
> 
> I'll be happy to answer any questions you have or help you in whatever 
> way you want.

Wow, that's a generous offer, perhaps, the most generous I've got in my 
entire life!:-)

Yes, I'll have a look at it (again) and will think how we can best 
integrate the two APIs. Although, I will not have too much time for this 
work, so, I'll be looking for the easiest / cheapest acceptible 
solution:-)

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: Integrating v4l2_device/v4l2_subdev into the soc_camera framework

[Hans Verkuil]

On Tuesday 16 December 2008 10:37:02 Guennadi Liakhovetski wrote:
> Hi Hans,
>
> On Mon, 15 Dec 2008, Hans Verkuil wrote:
> > Hi Guennadi,
> >
> > Now that the v4l2_device and v4l2_subdev structs are merged into
> > the master v4l-dvb repository it is time to look at what needs to
> > be done to integrate it into the soc-camera framework.
> >
> > The goal is to make the i2c sub-device drivers independent from how
> > they are used. That is, whether a sensor is used in an embedded
> > device or in a USB webcam or something else should not matter for
> > the sensor driver.
> >
> > I would really appreciate it if you can take a good look at what
> > would be needed to achieve this. We can then discuss that and make
> > a plan on how to proceed.
> >
> > I'll be happy to answer any questions you have or help you in
> > whatever way you want.
>
> Wow, that's a generous offer, perhaps, the most generous I've got in
> my entire life!:-)

Perhaps I should have added: 'as long as it relates to the new 
framework' :-)

> Yes, I'll have a look at it (again) and will think how we can best
> integrate the two APIs. Although, I will not have too much time for
> this work, so, I'll be looking for the easiest / cheapest acceptible
> solution:-)

Well, the end result should be a reusable sensor driver, otherwise there 
is no point. I can help in converting drivers, but obviously not with 
testing.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

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