New Driver for DaVinci DM355/DM365/DM6446

New Driver for DaVinci DM355/DM365/DM6446

[Paulraj, Sandeep]

Hello,

WE have a module(H3A) on Davinci DM6446,DM355 and DM365.

Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in
an imaging/video system.

Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager.

This modules collects statistics and we currently implement it as a character driver.

Which mailing list would be the most appropriate mailing list to submit patches for review?

Thanks,
Sandeep

Re: New Driver for DaVinci DM355/DM365/DM6446

[Mauro Carvalho Chehab]

Em Mon, 1 Jun 2009 09:56:40 -0500
"Paulraj, Sandeep" <s-paulraj@ti.com> escreveu:

> 
> Hello,
> 
> WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
> 
> Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in
> an imaging/video system.
> 
> Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager.
> 
> This modules collects statistics and we currently implement it as a character driver.
> 
> Which mailing list would be the most appropriate mailing list to submit patches for review?

You should send they to:
	LMML <linux-media@vger.kernel.org>

If you are proposing API changes, please submit they first.

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




Cheers,
Mauro

RE: New Driver for DaVinci DM355/DM365/DM6446

[Paulraj, Sandeep]

> -----Original Message-----
> From: Mauro Carvalho Chehab [mailto:mchehab@infradead.org]
> Sent: Monday, June 01, 2009 12:35 PM
> To: Paulraj, Sandeep
> Cc: linux-media@vger.kernel.org; linux-kernel@vger.kernel.org; Grosen,
> Mark
> Subject: Re: New Driver for DaVinci DM355/DM365/DM6446
> 
> Em Mon, 1 Jun 2009 09:56:40 -0500
> "Paulraj, Sandeep" <s-paulraj@ti.com> escreveu:
> 
> >
> > Hello,
> >
> > WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
> >
> > Customers require a way to collect the data required to perform the Auto
> Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as
> opposed to software. This is primarily for performance reasons as there is
> not enough software processing MIPS (to do 3A statistics) available in
> > an imaging/video system.
> >
> > Including this block in hardware reduces the load on the processor and
> bandwidth to the memory as the data is collected on the fly from the
> imager.
> >
> > This modules collects statistics and we currently implement it as a
> character driver.
> >
> > Which mailing list would be the most appropriate mailing list to submit
> patches for review?
> 
> You should send they to:
> 	LMML <linux-media@vger.kernel.org>
> 
> If you are proposing API changes, please submit they first.
[Sandeep] WE don't propose any API changes. This module for which we want to submit patches is a TI proprietary IP. We currently implement this as a character device and have a few IOCTL's.
We do not follow the V4L2 framework and do not use any V4L2 IOCTLs.

Can we continue to use it as a character driver?
> 
> >
> > Thanks,
> > Sandeep
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
> 
> Cheers,
> Mauro

Re: New Driver for DaVinci DM355/DM365/DM6446

[Mauro Carvalho Chehab]

Em Mon, 1 Jun 2009 11:54:37 -0500
"Paulraj, Sandeep" <s-paulraj@ti.com> escreveu:

> 
> 
> > -----Original Message-----
> > From: Mauro Carvalho Chehab [mailto:mchehab@infradead.org]
> > Sent: Monday, June 01, 2009 12:35 PM
> > To: Paulraj, Sandeep
> > Cc: linux-media@vger.kernel.org; linux-kernel@vger.kernel.org; Grosen,
> > Mark
> > Subject: Re: New Driver for DaVinci DM355/DM365/DM6446
> > 
> > Em Mon, 1 Jun 2009 09:56:40 -0500
> > "Paulraj, Sandeep" <s-paulraj@ti.com> escreveu:
> > 
> > >
> > > Hello,
> > >
> > > WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
> > >
> > > Customers require a way to collect the data required to perform the Auto
> > Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as
> > opposed to software. This is primarily for performance reasons as there is
> > not enough software processing MIPS (to do 3A statistics) available in
> > > an imaging/video system.
> > >
> > > Including this block in hardware reduces the load on the processor and
> > bandwidth to the memory as the data is collected on the fly from the
> > imager.
> > >
> > > This modules collects statistics and we currently implement it as a
> > character driver.
> > >
> > > Which mailing list would be the most appropriate mailing list to submit
> > patches for review?
> > 
> > You should send they to:
> > 	LMML <linux-media@vger.kernel.org>
> > 
> > If you are proposing API changes, please submit they first.
> [Sandeep] WE don't propose any API changes. This module for which we want to submit patches is a TI proprietary IP. We currently implement this as a character device and have a few IOCTL's.
> We do not follow the V4L2 framework and do not use any V4L2 IOCTLs.
> 
> Can we continue to use it as a character driver?

In this case, I don't see why you want it to be upstream.



Cheers,
Mauro

RE: New Driver for DaVinci DM355/DM365/DM6446

[Paulraj, Sandeep]

Mauro,
      Please see inline

> -----Original Message-----
> From: Mauro Carvalho Chehab [mailto:mchehab@infradead.org]
> Sent: Monday, June 01, 2009 1:57 PM
> To: Paulraj, Sandeep
> Cc: linux-media@vger.kernel.org; linux-kernel@vger.kernel.org; Grosen,
> Mark
> Subject: Re: New Driver for DaVinci DM355/DM365/DM6446
> 
> Em Mon, 1 Jun 2009 11:54:37 -0500
> "Paulraj, Sandeep" <s-paulraj@ti.com> escreveu:
> 
> >
> >
> > > -----Original Message-----
> > > From: Mauro Carvalho Chehab [mailto:mchehab@infradead.org]
> > > Sent: Monday, June 01, 2009 12:35 PM
> > > To: Paulraj, Sandeep
> > > Cc: linux-media@vger.kernel.org; linux-kernel@vger.kernel.org; Grosen,
> > > Mark
> > > Subject: Re: New Driver for DaVinci DM355/DM365/DM6446
> > >
> > > Em Mon, 1 Jun 2009 09:56:40 -0500
> > > "Paulraj, Sandeep" <s-paulraj@ti.com> escreveu:
> > >
> > > >
> > > > Hello,
> > > >
> > > > WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
> > > >
> > > > Customers require a way to collect the data required to perform the
> Auto
> > > Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in
> hardware as
> > > opposed to software. This is primarily for performance reasons as
> there is
> > > not enough software processing MIPS (to do 3A statistics) available in
> > > > an imaging/video system.
> > > >
> > > > Including this block in hardware reduces the load on the processor
> and
> > > bandwidth to the memory as the data is collected on the fly from the
> > > imager.
> > > >
> > > > This modules collects statistics and we currently implement it as a
> > > character driver.
> > > >
> > > > Which mailing list would be the most appropriate mailing list to
> submit
> > > patches for review?
> > >
> > > You should send they to:
> > > 	LMML <linux-media@vger.kernel.org>
> > >
> > > If you are proposing API changes, please submit they first.
> > [Sandeep] WE don't propose any API changes. This module for which we
> want to submit patches is a TI proprietary IP. We currently implement this
> as a character device and have a few IOCTL's.
> > We do not follow the V4L2 framework and do not use any V4L2 IOCTLs.
> >
> > Can we continue to use it as a character driver?
> 
> In this case, I don't see why you want it to be upstream.
[Sandeep] TI customers and TI itself want to see this driver part of open source trees. Considering this we would like to submit our patches to the linux-media mailing list.
IS this OK?
> 
> 
> 
> Cheers,
> Mauro

Re: New Driver for DaVinci DM355/DM365/DM6446

[Mauro Carvalho Chehab]

Em Mon, 1 Jun 2009 13:39:17 -0500
"Paulraj, Sandeep" <s-paulraj@ti.com> escreveu:

> > > [Sandeep] WE don't propose any API changes. This module for which we  
> > want to submit patches is a TI proprietary IP. We currently implement this
> > as a character device and have a few IOCTL's.  
> > > We do not follow the V4L2 framework and do not use any V4L2 IOCTLs.
> > >
> > > Can we continue to use it as a character driver?  
> > 
> > In this case, I don't see why you want it to be upstream.  
> [Sandeep] TI customers and TI itself want to see this driver part of open source trees. Considering this we would like to submit our patches to the linux-media mailing list.
> IS this OK?

If you're just providing a character API with some protocol protected by IP,
you're not providing the source code of the driver, but something else. 

It is not ok to provide such driver. 

Also, even if you disclosure your protocol, it makes no sense to create another
API for userspace communication, for features that already exists or can easily
expand to accommodate your needs. 

So, you should really use the V4L2 API for the driver, expanding it where
required, if you want it to be considered for upstream addition.



Cheers,
Mauro

RE: New Driver for DaVinci DM355/DM365/DM6446

[Aguirre Rodriguez, Sergio Alberto]

> From: linux-media-owner@vger.kernel.org [linux-media-owner@vger.kernel.org] On Behalf Of Paulraj, Sandeep
> Sent: Monday, June 01, 2009 5:56 PM
> To: linux-media@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Grosen, Mark
> Subject: New Driver for DaVinci DM355/DM365/DM6446
> 
> Hello,
> 
> WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
> 
> Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. > This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in
> an imaging/video system.
> 
> Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager.
> 
> This modules collects statistics and we currently implement it as a character driver.

This also exists in OMAP3 chips, and is part of the ISP module.

I maintain, along with Sakari Ailus, a V4L2 camera driver, which is currently just shared through a gitorious repository:

http://gitorious.org/omap3camera

The way we offer an interface for the user to be able to request this statistics is with the usage of private IOCTLs declared inside the same V4L2 capturing device driver.

So, that way we have a V4L2 driver which has a private call, instead of having it separately from the capture driver.

Regards,
Sergio
> 
> Which mailing list would be the most appropriate mailing list to submit patches for review?
> 
> Thanks,
> Sandeep
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: New Driver for DaVinci DM355/DM365/DM6446

[Karicheri, Muralidharan]

Sergio,

Is it part of the patches Vaibhav & others from TI are submitting to open source ? I know that there is an ongoing effort at TI India to submit the resizer driver to open source for OMAP3? As per the email exchanges I had with Vaibhav (TI India) on this, it is part of the ISP module. We plan to submit the patches to open source for H3A and was trying to see which is the right way to do it. We will investigate the tree you mentioned below and let you know if we have additional questions. The plan is to align with OMAP3 for the implementation.

regards,

Murali Karicheri
email: m-karicheri2@ti.com

>-----Original Message-----
>From: linux-media-owner@vger.kernel.org [mailto:linux-media-
>owner@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
>Sent: Monday, June 01, 2009 2:39 PM
>To: Paulraj, Sandeep; linux-media@vger.kernel.org
>Cc: linux-kernel@vger.kernel.org; Grosen, Mark
>Subject: RE: New Driver for DaVinci DM355/DM365/DM6446
>
>> From: linux-media-owner@vger.kernel.org [linux-media-
>owner@vger.kernel.org] On Behalf Of Paulraj, Sandeep
>> Sent: Monday, June 01, 2009 5:56 PM
>> To: linux-media@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org; Grosen, Mark
>> Subject: New Driver for DaVinci DM355/DM365/DM6446
>>
>> Hello,
>>
>> WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
>>
>> Customers require a way to collect the data required to perform the Auto
>Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as
>opposed to software. > This is primarily for performance reasons as there
>is not enough software processing MIPS (to do 3A statistics) available in
>> an imaging/video system.
>>
>> Including this block in hardware reduces the load on the processor and
>bandwidth to the memory as the data is collected on the fly from the imager.
>>
>> This modules collects statistics and we currently implement it as a
>character driver.
>
>This also exists in OMAP3 chips, and is part of the ISP module.
>
>I maintain, along with Sakari Ailus, a V4L2 camera driver, which is
>currently just shared through a gitorious repository:
>
>http://gitorious.org/omap3camera
>
>The way we offer an interface for the user to be able to request this
>statistics is with the usage of private IOCTLs declared inside the same
>V4L2 capturing device driver.
>
>So, that way we have a V4L2 driver which has a private call, instead of
>having it separately from the capture driver.
>
>Regards,
>Sergio
>>
>> Which mailing list would be the most appropriate mailing list to submit
>patches for review?
>>
>> Thanks,
>> Sandeep
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: New Driver for DaVinci DM355/DM365/DM6446

[Aguirre Rodriguez, Sergio Alberto]

> From: Karicheri, Muralidharan
> Sent: Monday, June 01, 2009 9:58 PM
> To: Aguirre Rodriguez, Sergio Alberto; Paulraj, Sandeep; linux-media@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Grosen, Mark
> Subject: RE: New Driver for DaVinci DM355/DM365/DM6446
> 
> Sergio,
> 
> Is it part of the patches Vaibhav & others from TI are submitting to open source ?

Yes, currently I have been sharing this codebase with Vaibhav, which he is taking for the 3530 EVM, which uses the camera ISP to receive images from a video decoder using a parallel BT656 output.


> I know that there is an
> ongoing effort at TI India to submit the resizer driver to open source for OMAP3?

I guess this is still on hold, as the current internal approach is not acceptable in the V4L2 standards.

> As per the email
> exchanges I had with Vaibhav (TI India) on this, it is part of the ISP module.

That's correct.

> We plan to submit the
> patches to open source for H3A and was trying to see which is the right way to do it.

The ISP driver core that we are sharing, it already has the H3A driver on it, which is accessed through Private IOCTLs declared inside the driver.

> We will
> investigate the tree you mentioned below and let you know if we have additional questions.

Vaibhav should be already familiar with this codebase, so maybe it could be easier for you to talk with him about this.

> The plan is to align with OMAP3 for the implementation.

Although the current code maintenance is on hold because i've been busy with some other custormer requirements, i havent been able to continue working on the pending TODOs so far. But as this strategy on a better collaboration with the community is attempted, i'm trying ot find my way to get back wit hthe maintenance of this driver to meet at least the required changes for acceptance of the driver.

It'll be definitively good to align on this, so we can avoid rewriting the same thing over again.

Regards,
Sergio
> 
> regards,
> 
> Murali Karicheri
> email: m-karicheri2@ti.com
> 
>-----Original Message-----
>From: linux-media-owner@vger.kernel.org [mailto:linux-media-
>owner@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
>Sent: Monday, June 01, 2009 2:39 PM
>To: Paulraj, Sandeep; linux-media@vger.kernel.org
>Cc: linux-kernel@vger.kernel.org; Grosen, Mark
>Subject: RE: New Driver for DaVinci DM355/DM365/DM6446
>
>> From: linux-media-owner@vger.kernel.org [linux-media-
>owner@vger.kernel.org] On Behalf Of Paulraj, Sandeep
>> Sent: Monday, June 01, 2009 5:56 PM
>> To: linux-media@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org; Grosen, Mark
>> Subject: New Driver for DaVinci DM355/DM365/DM6446
>>
>> Hello,
>>
>> WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
>>
>> Customers require a way to collect the data required to perform the Auto
>Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as
>opposed to software. > This is primarily for performance reasons as there
>is not enough software processing MIPS (to do 3A statistics) available in
>> an imaging/video system.
>>
>> Including this block in hardware reduces the load on the processor and
>bandwidth to the memory as the data is collected on the fly from the imager.
>>
>> This modules collects statistics and we currently implement it as a
>character driver.
>
>This also exists in OMAP3 chips, and is part of the ISP module.
>
>I maintain, along with Sakari Ailus, a V4L2 camera driver, which is
>currently just shared through a gitorious repository:
>
>http://gitorious.org/omap3camera
>
>The way we offer an interface for the user to be able to request this
>statistics is with the usage of private IOCTLs declared inside the same
>V4L2 capturing device driver.
>
>So, that way we have a V4L2 driver which has a private call, instead of
>having it separately from the capture driver.
>
>Regards,
>Sergio
>>
>> Which mailing list would be the most appropriate mailing list to submit
>patches for review?
>>
>> Thanks,
>> Sandeep
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New Driver for DaVinci DM355/DM365/DM6446

[Mauro Carvalho Chehab]

Em Mon, 1 Jun 2009 13:38:37 -0500
"Aguirre Rodriguez, Sergio Alberto" <saaguirre@ti.com> escreveu:

> > From: linux-media-owner@vger.kernel.org [linux-media-owner@vger.kernel.org] On Behalf Of Paulraj, Sandeep
> > Sent: Monday, June 01, 2009 5:56 PM
> > To: linux-media@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org; Grosen, Mark
> > Subject: New Driver for DaVinci DM355/DM365/DM6446
> > 
> > Hello,
> > 
> > WE have a module(H3A) on Davinci DM6446,DM355 and DM365.
> > 
> > Customers require a way to collect the data required to perform the Auto Exposure (AE), Auto Focus(AF), and Auto White balance (AWB) in hardware as opposed to software. > This is primarily for performance reasons as there is not enough software processing MIPS (to do 3A statistics) available in
> > an imaging/video system.
> > 
> > Including this block in hardware reduces the load on the processor and bandwidth to the memory as the data is collected on the fly from the imager.
> > 
> > This modules collects statistics and we currently implement it as a character driver.
> 
> This also exists in OMAP3 chips, and is part of the ISP module.
> 
> I maintain, along with Sakari Ailus, a V4L2 camera driver, which is currently just shared through a gitorious repository:
> 
> http://gitorious.org/omap3camera
> 
> The way we offer an interface for the user to be able to request this statistics is with the usage of private IOCTLs declared inside the same V4L2 capturing device driver.
> 
> So, that way we have a V4L2 driver which has a private call, instead of having it separately from the capture driver.

This seems to be a much better approach, provided that the private IOCTL's will
be properly documented on a public document. If there are enough usage for
they, we may even add them as an optional part of V4L2 API.



Cheers,
Mauro